Ulrich Drepper, a longtime glibc maintainer, publishes technical papers on memory, shared libraries, thread-local storage, and futexes.
Commenters call his memory paper a fantastic read despite its clickbaity title, and link his TLS write-up and his static linking views.
I think this may be just how most programming (and perhaps everything else besides science experiments) has to be done.
If you're writing assembly code, well, computers have some pretty solid low level abstractions, but do you really understand how many clock cycles that instruction there is going to take? What about all the error cases?
If you're writing for the web, it's clear you can't even try to really understand how everything works in all cases across all machines.
Few programmers really understand how computer memory works, but if everyone were to read this guide (http://www.akkadia.org/drepper/cpumemory.pdf) and really learn it throughly, the net benefit probably wouldn't be that great vs other things they could do with that time.
It's great fun to track down every last misunderstanding or bug, but it's probably not worth it over the long term. The benefit of learning the internal details of a reliable subsystem is often not worth it and it's easier to just use it and get on with the project.
That being said, when I do go to fix a bug, I try to get to the bottom of why it happens and not just stop at the first change that works. This is useful for a number of reasons:
1) If you made the bug, you probably have some misunderstanding of the system that will be fixed when you understand the bug.
2) If you're spending your time fixing an actual bug, then the misunderstanding empirically matters because this mistake has been made and actually affects someone.
3)…
snprintf_l() is not standard, but you can simulate it with uselocal() to save and restore the per-thread locale, which is standard (POSIX.1-2008) and supported by Glibc, FreeBSD, MacOS and other OSes, though Windows requires its own, different way of doing per-thread locale.
It seems it was once an explicit design choice in Glibc. Here (https://sourceware.org/bugzilla/show_bug.cgi?id=10891) a Glibc ticket refers to documentation "Thread-aware Local Model, A Proposal" of the plans for the _l() functions (https://akkadia.org/drepper/tllocale.ps.gz) long ago, which are nowadays implemented in Glibc.
It looks like snprintf_l() and other <stdio.h> functions were not part of that plan.
That plan or something like it also made its way into POSIX.1-2008, so it seems likely that the committee gave some thought to including strftime_l() and not snprintf_l().
The paper linked above includes a rationale that tiny, potentially performance-critical functions like isalpha() need a fast version that takes a local parameter, thus isalpha_l(), because of the overhead of fetching a thread-local value inside the function.
Perhaps the intent is that only those tiny functions, or even macros, whose performance would be greatly affected by the cost of fetching the thread-local locale, need a _l() version. That mostly makes sense for the functions which have _l() versions in Glibc. But with that rationale, I don't see why there is strftime_l() but not snprintf_p().
There are "stream" instructions available on some CPU. These instructions tell the CPU to store data, but not to load it into a cache line (it might actually load it into a temporary cache line that is not part of the normal cache lines, depending on architecture). This is useful is you are writing data to memory but don't read it - there's no point in loading that data to the cache line since you will not access it again.
One such instruction can be used with the _mm_stream_si128 intrinsic:
void _mm_stream_si128(__m128i *p, __m128i a);
Stores the data in a to the address p without polluting the caches. If the cache line containing address p is already in the cache, the cache will be updated. Address p must be 16 byte aligned.
Learned about it in "What every programmer should know about memory":
https://www.akkadia.org/drepper/cpumemory.pdf
It's from 2007, but still relevant and a good read.
The large pages feature (huge pages) still works the same way but the transparent huge pages patch has been integrated recently: http://www.slideshare.net/raghusiddarth/transparent-hugepages-in-rhel-6
I personally wouldn't mess with the VM settings the way the author suggests. I don't remember doing that eight years ago anyway even with less RAM on a desktop. On a server you want the working set to fit in RAM anyway and the page cache is already pretty smart.
The best resource is a general kernel book: http://www.amazon.com/Linux-Kernel-Development-3rd-Edition/dp/0672329468/ref=sr_1_1?ie=UTF8&qid=1360543016&sr=8-1&keywords=linux+kernel
in terms of the interaction between memory, the cpu, and virtual memory What every Programmer should know about memory should be required reading: http://www.akkadia.org/drepper/cpumemory.pdf
I think this, and all the other weirdness, is because usage of thread-local variables is pretty low. Probably somebody wanted to have "lightweight" threads doing work as quickly as possible accessing only local variables.
Edit: ah, see https://www.akkadia.org/drepper/tls.pdf which I was clued into by https://news.ycombinator.com/item?id=43079061
The situation is much more complicated than it sounds, because the question of where the variables are isn't known at compile time. It has to be done at link time. Which may include dynamic link time as a library is loaded. That all sounds fairly horrible.
All to handle static constructors. If you don't have thread-static variables, or they don't have constructors, it's much simpler.
If you want to read something more approachable that can serve as a gateway to this, I highly recommend Jon Stokes' Inside the Machine. It goes over microprocessor architecture in a very approachable way, and contains a good chapter on the memory/cache hierarchy that is sort of the light version of a good chunk of Drepper's paper, or at least will be a big help in making sense of it. If you've never been close to the metal, or you want to catch up on newer developments, consider checking it out.
Also, here's Drepper's paper compiled into a single PDF, which I think was edited a little later than the LWN publication and might have had some minor errata fixes: http://www.akkadia.org/drepper/cpumemory.pdf