Since the advent of e-commerce, POS-networking and fraud detection systems in 1990's-2000's.

User-facing and authorisation path are highly latency sensitive. It includes tap-to-pay, online checkout, issuer authorisation, fraud decisioning, and instant payment confirmation – even moreso for EFT payments.

> […] 2-5 seconds more from card presentation to getting approval back.

This is the mid-1990's level QoS when smaller merchants connected the acquirer bank via a modem connection, and larger ones via ISDN.

Today, payments are nearly instant in most cases, with longer than one-second card payment flows falling into the exceptions territory or inadequate condition of the payment infrastructure.

After doing some Google searches I realized the plants were related and eventually it sort of made sense. Peppers are almost like a very dry, very firm tomato.

In hindsight it's obvious but at the time it was very surprising.

but for some reason my fealty to potato does not extend to tomatoes and eggplant quite the same way. i feel toward potatoes sort of how gary Larson feels about cows

Neither are RISC nor modern.

I have only seen PDP-11 Assembly snippets in UNIX related books, wasn't aware of its alignment requirements.

It is quite likely that not allowing the misaligned access was also influenced by PDP-11.

Maybe other CPU's have it as well, though I do not have enough information on that.

Linux does not page out code pages into the swap. You might be conflating page reclamation with swapping instead.

In Linux, executable «.text» pages are mapped[0] as file-backed pages, not anonymous memory, so when the kernel needs to reclaim RAM it normally drops those pages and reloads them from the executable file on the next page fault once they are accessed again (i.e. on demand) rather than writing them to swap.

In this particular regard, Linux is no different from any other modern UNIX[1] kernel (*BSD, Solaris, AIX and may others).

[0] Via mmap(2) in argv[0], essentially.

[1] Modern UNIX is mid-1990's and onwards.

Actually, fork(2) was very inefficient in the 1970's and for another decade, but that changed with BSD 4.3 which shipped an entirely new VMM in 1990 in 4.3-Reno BSD, which – subsequently – allowed a CoW fork(2) to come into existence in 4.4 BSD in 1993.

Two changes sped fork (2) up dramatically, but before then it entailed copying not just process' structs but also the entire memory space upon a fork.

It is not helpful because comparing English from 1000 AD with Modern High German is the wrong premise to start off with.

The correct and more interesting comparison would be with Old High German from around the same time although it did not indicate the umlaut in the spelling at the time (which would happen 400-500 years later) – even though the i-umlaut had already developed.

So «schön» was «scōni» (or «sconi») in OHG. Also, ö and ü developed from /o/ and /u/, so juxtaposing them with English ē is likely incorrect.

I hear this premise repeated time and time again. Search the internet. I believed this premise, and actually started studying German again while waiting for my Old English textbook to arrive. It did not help.

The knowledge of Modern High German helps little to none as far as the comprehension of Old English is concerned. From a modern German speaker's perspective, Old English – with a relatively small number of exceptions – is gibberish.

Most think that it came from TeX, which had -- (for an en dash) and --- (for an em dash, although I don't think I have ever observed it out in the wild outside TeX), but in fact, the habit well predates TeX and goes all the way back to typewriters where typists habitually hit two hyphens in a row to approximate an em dash. The approximated em dash was described in hard-copy manuscript preparation rules such as The Chicago Manual of Style.

So, if you have ever used a typewriter or TeX, you can claim an even richer than 20 years’ heritage of using the em dash.

> At a certain point though, something's gotta give, the compiler can do guesswork, but it should do no more, if you have to add more metadata then so be it it's certainly less tedious than putting pragmas and _____ everywhere, some C code just looks like the writings of an insane person.

There is not even a single correct or factual statement in cited strings of words.

C optimisation is not «hacks» or «witchcraft»; it is built on decades of academic work and formal program analysis: optimisers use data-flow analysis over lattices and fixed points (abstract interpretation) and disciplined intermediate representations such as SSA, and there is academic work on proving that these transformations preserve semantics.

Modern C is also deliberately designed to permit optimisation under the as-if rule, with UB (undefined behaviour) and aliasing rules providing semantic latitude for aggressive transformations. The flip side is non-negotiable: compilers can't «guess» facts they can't prove, and many of the most valuable optimisations require guarantees about aliasing, alignment, loop independence, value ranges, and absence of UB that are often not derivable from arbitrary pointer-heavy C, especially under separate compilation.

That is why constructs such as «restrict», attributes and pragmas exist: they are not insanity, they are explicit semantic promises or cost-model steering that supply information the compiler otherwise must conservatively assume away.

«metadata instead» is the same trade-off in a different wrapper, unless you either trust it (changing the contract) or verify it (reintroducing the hard analysis problem).

Godbolt exists because these optimisations are systematic and comparable, not because optimisation is impossible.

Also, directives are not new, C-specific embarrassment: ALGOL-68 had «pragmats» (the direct ancestor of today’s «pragma» terminology), and PL/I had longstanding in-source compiler control directives, so this mechanism is decades older than and predates modern C tooling.