Here are some performance numbers: https://www.phoronix.com/news/Zapcc-Quick-Benchmarks

> To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.

Do you talk down to people like this IRL as well?

> I've been using ccache for years and I never had any problem getting ccache to support template code.

What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.

> if you understand how compiler caches work. Think about it.

There's no need to use "condescending asshole" as your primary mode of communication, especially when you are wrong, such as in this case.

It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.

I used to have dry eyes afterwards for quite some time (years) as well, but that seems to have gone away at some point.

Instead he tried his best to make this about race. At best that is whataboutism, and at worst he's just a racist f*ck.

Buddhism, above anything else, teaches to let go, to _not_ get stuck in the temporary sorrows of the earthly plane. If anything, you should have learned that it doesn't matter, and to not make it the core of your identity.

You blame the White man for genocide, but conveniently leave out that much of that 'genocide' was caused by disease, long before anyone even knew what caused it. You also conveniently ignore that the native Americans happily waged war on each other whenever they had the chance.

You blame the White man for slavery, but conveniently leave out that absolutely everyone practiced slavery, and that it was the White man who abolished it. You also conveniently leave out that more slaves are kept in just India _today_ than were taken by all European nations throughout history.

You blame the White man for lynching, but conveniently leave out that 'necklacing' is practiced today, in South Africa, on White people. Your viewpoint is extremely one-sided, and always to the detriment of a single race.

I can go on, but I think you can see my point: you assign blame to a single race, and are blind to the reality that nobody here are angels. You scapegoat one group based on their skin color, while willfully ignoring that pretty much everybody did the worst they could, whenever they had the opportunity.

What should we all be given, and more importantly by whom, just to make up for the endless parade of historic injustices? Does dwelling on them for all eternity make for a good future?

And here's the thing: hamas has extensive underground tunnel networks, so it actually _isn't_ needed to hide among civilians! They do it purely for the optics: every destroyed school or hospital will help sway Western opinion.

"M'am, that vase in front of your TV could be used to block ads. You are going to have to move that."

Anyway, I see a great future for adblockers that render the whole page in a back buffer, and then copy it to a front buffer where it is masked by a bitmap that just has black squares where the ads used to be. That doesn't "change the original, copyrighted document", so it should be fine. And I presume putting that vase in front of your screen is still acceptable, even in Germany.

If publishers want more control, they always have the option of downloading the entire page as a bitmap.

Moreover, Windows will request that applications that are closing provide their previously advertized clipboard data, making the feature pretty much transparent to users. And some applications ask if you will still need your previous clipboard data when they close (Excel is one, I seem to remember).

The two instances where UB allows for optimisation are as follows:

1. The 'signed overflow' UB allows for faster array indexing. By ignoring potential overflow, the compiler can generate code that doesn't check for accidental overflow (which would require masking the array index, recomputing the address on each loop iteration). I believe the better solution here would be to introduce a specific type for iterating over arrays that will never overflow; size_t would do fine, and making signed overflow at least implementation defined, if not outright fully defined, after a suitable period during which compilers warn if you use a too-small type for array indexing.

2. The 'aliasing' UB does away with the need to read/write values to/from memory each time they're used, and is extremely important to performance optimisation.

But the rest? Most of it does precisely nothing for performance. At 'best', the compiler uses detected UB to silently eliminate code branches, but that's something to be feared, not celebrated. It isn't an optimisation if it removes vital program logic, because the compiler could 'demonstrate' that it could not possibly take the removed branch, on account of it containing UB.

The claim in the linked article ("what every C programmer should know") that use of uninitialized variables allows for additional optimisation is incorrect. What it does instead is this: if the compiler see you declare a variable, and then reading from it before writing to it, it has detected UB, and since the rule is that "the compiler is allowed to assume UB does not occur", use that as 'evidence' that that code branch will never occur and can be eliminated. It does not make things go faster; it makes them go _wrong_.

Undefined behaviour, ultimately, exists for many reasons: because the standards committee forgot a case, because the underlying platforms differ too wildly, because you cannot predict in advance what the result of a bug may be, to grandfather in broken old compilers, etc. It does not, in any way, shape, or form, exist _in order to_ enable optimisation. It _allows_ it in some cases, but that is, and never was, not the goal.

Moreover, the phrasing of "the compiler is allowed to assume that UB does not occur" was originally only meant to indicate that the compiler was allowed to emit code as if all was well, without introducing additional tests (for example, to see if overflow occurred or if a pointer was valid) - clearly that would be very expensive or downright infeasible. Unfortunately, over time this has enabled a toxic attitude to grow that turns minor bugs into major disasters, all in the name of 'performance'.

The two bullet points towards the end of the article are both true: the compiler SHOULD NOT behave like an adversary, and the compiler DOES NEED license to optimize. The mistake is thinking that UB is a necessary component of such license. If that were true, a language with more UB would automatically be faster than one with less. In reality, C++ and Rust are roughly identical in performance.

Because the vast majority of failing software just means inconvenience, rather than disaster.