If you want to learn how to understand the performance of the whole system I can recommend Brendan Gregg's Systems Performance: Enterprise and the Cloud (https://www.brendangregg.com/blog/2020-07-15/systems-perform...). It is a good book that teaches a lot of basics and techniques and gives a good understanding of the impact different system components can have on performance.
I am so fascinated by how differently people interpreted this thread, really shows the diversity of computing and performance work. Here's a book about performance in the context of "enterprise and the cloud".
I've worked with performance optimizations for years, but never touched a network connection. Because for me it's all in the context of optimizing single player video games, which primarily leads to a focus on graphics programming and GPU performance.
"I am so fascinated by how differently people interpreted this thread, really shows the diversity of computing and performance work."
Well yeah, my first reaction to the question was: Optimize for what?
The question probably would have benefited from a bit more details about his job. Plattform, domain, etc.
I am also in the same boat as you, where I have 16 ms to do everything. So some of the general things we optimize for, also apply elsewhere, but many others not so much.
My main generic advice would be: things that happen only sometimes, can usually be slow, but things you need to do often ("hot spots") they need attention.
But of course this does not apply to a programm that checks for example whether the airbag of the car needs to fire, because some very rare condition was met. This code only runs very rarely - but if it does, there should be no garbage collector kicking in at that moment, no slow DB lookup, no waiting for a UI process to finish or alike (which should not have a connection anyway to the critical parts).
That's a great paper. I've tangled with the line fill buffer issue before, along with other hidden limits such as infinity fabric limits on AMD systems. It's one of the first big disppointments when you start doing high performance, bandwidth-limited compute work. It's also one that's almost entirely undocumented which is frustrating.
Interesting paper. I focus more on the latency than bandwidth. The paper gets a few things wrong, DDR5 is not a single 64bit channel, but 2 x 32 bit channels. So the normal Xeon is 16 x 32 bit channels, not 8x64 bit.
He talks about cache misses as 60ns, which glosses over that approximately half of that is missing through L1/L2/L3, then you enter the queue for the memory controller, for the memory channel you need. As a result you only get half the bandwidth if you only have a single request pending per channel.
Even in the US the case law around self-incrimination due to forced password disclosure does not seem to be settled. There have been multiple cases were judges have considered passwords foregone conclusions, e.g. [1]
Not a lawyer, but my understanding is that in the USA you cannot be compelled to provide your password as such, but you can be ordered to produce the decrypted content. I guess the only real distinction there is that you're allowed to keep the password itself secret.
I can recommend https://realpython.com/products/cpython-internals-book/ as a decent initial documentation of cpython. I have a copy of this book at my desk for the few cases when I need to debug GIL or memory allocator related issues in cpython.
Especially if you need x64 assembly for performance optimization or during profiling a combination of godbolt (https://godbolt.org/) and Agner Fog's incredible PDFs at https://agner.org/optimize/ (especially parts 2, 3 and 4) are helpful.
The other useful step has been to write C functions and compile the code with a good compiler (good experiences with Intel, gcc and llvm) first at -O0 and later at -O2 or -O3 to understand how high level concepts can be translated to assembly.
This requires to have at least a basic understanding of registers and basic assembly concepts but at least has helped me apply the concepts to real code.
Because before 1993, you're not comparing apples to apples: "Germany" was two separate countries, and reunification affected the economics on both sides of the border.
It's true that the recession makes this a particularly favorable starting point for Germany, but it'd be misleading to compare Germany's economy today to the economy of West Germany of the 1980s (as many comparisons do) and ignore that half of modern-day Germany was the DDR at that point.
There were two major events that make the starting point a lot lower: Recession shortly before and German reunification with its significant economic distortions.
That’s why it’s easy to deceive by starting charts a certain date. When you look at the 1980s there was also a big increase. The y axis is linear so the newer increases look much more dramatic. When you look at the chart from 1950 you see a long term upwards trend with some setbacks.
