5 ms·

> All for a pointless ~1% performance boost. With 32 bit code this was absolutely not the case. I have not looked so closely at 64 bit code, but in 32 bit lan

> All for a pointless ~1% performance boost. With 32 bit code this was absolutely not the case. I have not looked so closely at 64 bit code, but in 32 bit land -fomit-frame-pointer was often closer to a 20-30% performance boost. Of all of gcc's optimization options it was the only one that I ever found to make a significant difference in real code.

jiggawatts 4y ago
I love these "rules of thumb", "black magic sorcery", and "best practices" that grey-haired old wizards pick up. More often than not, they're invalidated by some advancement in either computer hardware or software. Not just "no longer relevant", but often counterproductive. Worse still, these internalised tricks and rules are often related to Moore's law scaling, making them exponentially wrong over time. Not in the figurative sense, but a literal one. You see this with people claiming that I'm exaggerating when I say all code should be parallel. Meanwhile AMD is about to sell a 128 core / 256 thread processor. You can have two per host for a staggering 512 hardware threads. Single threaded code is capable of utilising just 0.2% of that machine! A similar "tuning best practice" that I still see applied in the field is database servers with dedicated data, log, temp, and templog drives... on cloud VMs where this is guaranteed to have worse performance than simply pooling the same amount of disk into a single logical drive. People pick these things up and hold on to them when they're wrong by orders of magnitude. I can't think of many (any?) other industries where more experienced senior staff can be this wrong about as many things...
- cleanchit 4y ago
  I wish unzip, tar etc were multithreaded/
  - nix23 4y ago
    -https://zlib.net/pigz/ https://zlib.net/pigz/ -https://manpages.ubuntu.com/manpages/xenial/man1/pxz.1.html https://manpages.ubuntu.com/manpages/xenial/man1/pxz.1.html -https://lzip.nongnu.org/plzip.html https://lzip.nongnu.org/plzip.html And so on, however the Compression-ratio is slightly worse
    - 5e92cb50239222b 4y ago
      + tar -cf - input/ data/ | zstdmt > out.tar.zst
- skrebbel 4y ago
  I dont know man, 10 years ago I saw an alarmist talk from Martin Odersky about how 128 core computers were around the corner and we should all switch to Scala for safe&easy parallellism and now when I go to the laptop shop it’s all 8, maybe 10 cores. We’ve been promised these magical ultra parallel machines for a decade now and either they’re much harder to build than the alarmists say, or there's simply no market.
  - sharpneli 4y ago
    One reason is that they are already here. It's just called the GPU which happens to be way more parallel than puny 128 cores. That's a major reason why just bunch of low power CPUs are not really a thing, as they get trashed by GPUs. What we are seeing is a hierarchy of processing cores. It's already visible even in the desktop market. Intel has their efficiency cores. Apple has the power and efficiency cores. And the GPU on top. So we already have 3 different stages here, at the top the least amount of cores but the best single threaded performance going all the way down to, let me check how many threads, almost 10000 threads on a flagship consumer GPU running simultaneously right now.
    - nine_k 4y ago
      Indeed. MCUs are even further in this regard, combining 32-bit and 64-bit cores.
    - moonchrome 4y ago
      Except GPU cores are nothing like CPU cores, GPGPU was around 10 years ago, and whatever scala language/framework features he was shilling are probably useless for that kind of programming - so that's a failed prediction.
      - sharpneli 4y ago
        On that I fully agree. And the reason why scala approach doesn't work is because it's horrendously inefficient. What actually does work at massive scale is the GPU style workload. Intel tried with their Larrabee on what happens if they just toss in ton of traditional low performance CPU cores. It failed to perform. It's really hard to beat the modern SIMT style GPUs when it comes to massively parallel computation.
- rwmj 4y ago
  No swap is another one. For everyone who believes you should turn off swap, please read: https://chrisdown.name/2018/01/02/in-defence-of-swap.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html Edit to clarify: SwapPING bad, having swap space good.
  - shakow 4y ago
    I don't know, the only thing I ever noticed whne using swap was : > Disabling swap doesn't prevent pathological behaviour at near-OOM, although it's true that having swap may prolong it. Basically, the memory manager will just bulldoze through moving all the other applications to the swap to let the leaking program pursue its leak. > you are left with a system in an unpredictable state. Having no swap doesn't avoid this. Yes, it does: the program that leaked my 16GB is killed at the very beginning of the situation, and I don't have to either wait dozens of minutes for it to fill the swap on top of that to finally be killed, or just hard reboot the machine and lose the whole state.
    - tsimionescu 4y ago
      > Yes, it does: the program that leaked my 16GB is killed at the very beginning of the situation How, and by whom? In a situation where you are running out of memory, it is programs that allocate the most often that have the highest chance of seeing an OOM, not those that allocate the most total amount. Also, on Linux, just because you don't have a swap partition doesn't mean things won't get swapped out to disk. Any memory mapped files will be swapped back to disk before issuing OOM problems - and the most common case of memory mapped files is executables and libraries. Which is of course the very thing that leads to a kind of livelock of swapless Linux systems that live close to 100% memory utilization: every time a thread is woken up, the instruction pipeline stalls until the next CPU instruction can be read from disk, slowing everything to a crawl.
      - shakow 4y ago
        > How, and by whom? By the kernel OOM killer? Is that supposed to be a trick question? > In a situation where you are running out of memory, it is programs that allocate the most often that have the highest chance of seeing an OOM, not those that allocate the most total amount. I don't really care; it still beats the machine being unresponsive for hours, especially if it's a remote one I dont have access to. > Also, on Linux, just because you don't have a swap partition doesn't mean things won't get swapped out to disk. Any memory mapped files will be swapped back to disk before issuing OOM problems That's not what is commonly understood by swapping though; that's a cache purge. > every time a thread is woken up, the instruction pipeline stalls until the next CPU instruction can be read from disk, slowing everything to a crawl. When you have swap enabled, yes; that the whole problem. However, IME, OoM just leads to the problematic program being quickly killed, then the user being able to go back to work.
- ilyt 4y ago
  > Single threaded code is capable of utilising just 0.2% of that machine! You can still server 512 different clients at once and still utilize 100% of the CPU. The parallelism is only a requirement if you want to compute one thing faster, not a bunch of things at once. Very much the desirable property for databases (although even that can be worked around with sharding if you're stubborn enough) but many developers code could be painfully serial yet still be perfectly fine to scale.
- m463 4y ago
  I remember many years ago when self-modifying code was fairly common.
- public_defender 4y ago
  > I can't think of many (any?) other industries where more experienced senior staff can be this wrong about as many things... Lawyer enters the thread. It's more common than you think. When complex work is done within power structures, it's just not enough to be "right" about something. You also have to be able to sell your solution to people who are wrong and powerful, which is sometimes not possible.
  - jiggawatts 4y ago
    The knowledge a lawyer acquires about the law doesn't go stale very fast. Many laws have been on the books for a century or more, and precedent is also established slowly and incrementally. A lawyer from 10 years ago that memorised some good "rules of thumb" about generic matters such as liability or court procedure won't have to throw out everything they know to be relevant today or another decade into the future. Meanwhile in IT, I regularly see network engineers upgrading links from 500 megabits to 1 gibabit when they should be looking at upgrading to 100 or even 200 gigabits. Their mental model of what's fast, relevant, or desirable is "off" by two orders of magnitude. Their knowledge was accurate just a decade ago, but is hilariously wrong now. I can't think of any other mainstream profession where institutional knowledge is deprecated as quickly.
- anarazel 4y ago
  > A similar "tuning best practice" that I still see applied in the field is database servers with dedicated data, log, temp, and templog drives... on cloud VMs where this is guaranteed to have worse performance than simply pooling the same amount of disk into a single logical drive. It's not guaranteed to be worse. For latency sensitive OLTP workloads dedicated, smaller, disks for the journal can result in substantially lower & predictable latency. Random reads for the data exhausting iops, causing stalls of journal writes isn't fun. There's also per-disk queuing on a bunch of levels, and avoiding intermingling data and journal writes can be quite beneficial. That's not to say it's always better, at all. But making it out to be a stupid thing one should never do isn't wise either.
- msm_ 4y ago
  > You see this with people claiming that I'm exaggerating when I say all code should be parallel. I mean, you're clearly exaggerating. My ad-hoc Python scripts don't have to be parallel.
- tjoff 4y ago
  >Single threaded code is capable of utilising just 0.2% of that machine! Promise? That's fantastic! Because few things deserve to use more than 0.2% percent of that machine. Sure, you could parallel it, and now it takes 0.3% to do what could easily be done quicker and saner by 0.1%.
  - jiggawatts 4y ago
    > deserve I too like to anthropomorphize scripts and punish them for their transgressions by constraining their resources.
- codeflo 4y ago
  Some of the things you claim are very context-specific and not true in general, which I find jars a bit with the (perceived by me to be) authoritative tone of your post. > I love these "rules of thumb", "black magic sorcery", and "best practices" that grey-haired old wizards pick up. Just quoting this to point out what I mean by addressing your tone. It's fine to disagree, but this feels like you're setting up that everyone who disagrees with you must be condescending and stuck in the past. Yes, performance advice is often tied to the specific situation, but that's also true for the things you state. > Worse still, these internalised tricks and rules are often related to Moore's law scaling, making them exponentially wrong over time. Not in the figurative sense, but a literal one. Implying that Moore's Law makes anything exponentially faster is an anachronism (talk about old knowledge!), it only makes things exponentially more parallel nowadays. See next point why that's relevant. As others have already clarified, -fomit-frame-pointer was sometimes 20% on x86. For some applications, people would kill for a 20% boost in single-threaded performance, even today! And importantly, that this specific optimization has become useless on x64 says nothing about the value of optimizations in general. Different ones are still useful, to give an example let's say SIMD (where it applies). > You see this with people claiming that I'm exaggerating when I say all code should be parallel. Meanwhile AMD is about to sell a 128 core / 256 thread processor. You can have two per host for a staggering 512 hardware threads. Single threaded code is capable of utilising just 0.2% of that machine! I'm not sure which strawman "grey-haired" developer you have in mind that buys a 512-thread server to run single-threaded code on it and then needs you to explain to them that they should parallelize it. Maybe you've met that person. But in general: Doesn't most code live in web servers nowadays anyway? If so, it's either already running in parallel, or can be made to do so with very little effort. BTW, parallelizing code in a web server can be harmful (!) to total throughput due to communication overheads. This is something that I find people don't always realize when they naively parallelize something, and is also sometimes missed by benchmarks that don't put the server under heavy load. > A similar "tuning best practice" that I still see applied in the field is database servers with dedicated data, log, temp, and templog drives... on cloud VMs where this is guaranteed to have worse performance than simply pooling the same amount of disk into a single logical drive. A statement like this depends on many concrete details about the specific cloud infrastructure (you didn't say AWS, you said "cloud"), and cloud VMs are usually not the best performing way to run a database anyway. So again, this is very context-specific. Also, if database performance is critical enough that you consider tuning these things, then renting bare metal should at least be a consideration as well. People who have never measured it are sometimes surprised by how large the virtualization overhead is (and how cheap it is to rent physical servers). On actual hardware, this advice might still be relevant. > I can't think of many (any?) other industries where more experienced senior staff can be this wrong about as many things... The actual point is that you should measure things in concrete cases, not make general claims. In that sense, I unfortunately don't find your "updated" way to state what supposedly is and isn't relevant not much of an improvement to the "outdated" claims you argue against so vehemently.
- LarryMullins 4y ago
  > You see this with people claiming that I'm exaggerating when I say all code should be parallel. Meanwhile AMD is about to sell a 128 core / 256 thread processor. You can have two per host for a staggering 512 hardware threads. Single threaded code is capable of utilising just 0.2% of that machine! Whether or not this argument holds water depends entirely on the context of the situation; what is the relationship between the program being considered and the computer? If the program is the reason for that hardware to exist, then obviously you want to use that hardware to it's fullest potential. If you've bought a 256 core machine specifically to run this program, then obviously you want to use all those cores. Some sort of threaded or multiprocess architecture should be an easy sell in this sort of circumstance. It shouldn't even be a discussion. But on the other hand, what if the program under consideration is ancillary? In that case, the program should use the bare minimum resources necessary, so as to not get in the way of whatever the primary program may be. If you have say.. a music playing daemon, then odds are your program should not be trying to use the host machine to it's fullest because that hardware actually exists to get some other job done. Ancillary programs should be designed to survive on leftover scraps, not with the assumption that they'll have first dibs on the use of the hardware.
  - jiggawatts 4y ago
    These are kinds of generic recommendations you listed are precisely the type that go out-of-date. Even on a laptop, I now have 16 threads and almost never see more than 1 utilised even when I'm waiting. Any time a human waits for a computer that is just 6% utilised, a developer screwed up. Just this minute, I downloaded a program installer using a 10 Gbps Internet link. Yes. Ten gigabits, dedicated to me, personally! Your idea of "what is a fast Internet link" is wrong. I downloaded a 600 MB software package in less than a second, and then had to wait for 30 seconds while the anti-malware tools scanned it... with a single thread. Extracting the file was 10 seconds because 'zip' is by default single threaded. Installing it took a solid minute during which my CPU usage never peaked above 2 cores because the installer is also single threaded. The only reason it uses more than 1 core is because the anti-malware scans it... again... on a second thread. Similarly, any time I see anyone manipulating ~1 GB of data, invariably they do it with GUI or CLI tools that are single threaded. This was desirable in an era when everyone had a single mechanical HHD. Multiple read or write threads would have caused disk head seeks, slowing down the process. These days when everyone has NVMe SSDs, the only way to fully utilise the 500K IOPS available from a $150 device is by throwing dozens of parallel threads at it!
- kristopolous 4y ago
  There's no practical way to avail yourself to all the latest advancements that find their way into your work in computers. Even as someone who tries to actively question assumptions that may no longer hold I still find myself constantly flat-footed. I can't pretend like I know all the various advancements in processor architecture of the past 5 years (since 2018) or how modern compilers exploit them and also the latest techniques in GPU computing. Heck even old rules of thumb like the speed of platter drives are being challenged - mechanical drives with 500M/s throughput are hitting the shelves this year. I just upgraded a platter RAID where I'm getting ~1000M/s. The SSD delta has changed (that's of course assuming SSD hasn't moved which I'm sure is also false). I'm sure there's new advancement in material science and manufacturing that I'm also not privy too which has made this possible. Storage alone is another vast world. I don't know all the features of ext4, xfs, zfs, hammer, and btrfs or how to competently compare and tune them for various workloads or how that analysis has changed in say the past 24 months. This is something I became intimately aware of when upgrading the array. I didn't know any of the modern tools or approaches. All knowledge in this space eventually becomes vestigial and outdated and it's physically impossible to keep up. I haven't even kept up with the latest C features. Then there's Go, Rust, Typescript and countless other languages that each require at minimum, a hundred hours a year each to competently follow. The best we can do is have humility and continually approach things as a student because we never know what table leg has been knocked out underneath us without our noticing.
masklinn 4y ago
> With 32 bit code X86. No other 32b architecture is that register-starved even if the larger number of registers is somewhat mitigated by being load-store.
- sharpneli 4y ago
  Not just X86, the older X86. Before Pentium Pro there was not even register renaming. So one was both register starved and the registers you saw where actually the registers you got. Even after that it was still somewhat starved but it alleviated the problem greatly. Nowadays X64 has a decent amounts of registers + the HW internally has several times more the registers, so saving one is almost meaningless.
saagarjha 4y ago
Definitely not 20-30%. Maybe 10% on certain workloads.
- jandrese 4y ago
  It was. The amount of improvement varied by application, but this was testing with real world applications like JPEG libraries, MP3 libraries, compression, etc... Of course this was back in the 90s and early 2000s so back in the dinosaur ages by computer standards. Almost certainly using gcc 2.95 on a Pentium 75. It was the only optimization flag that made more than a couple percent difference.

jiggawatts 4y ago

I love these "rules of thumb", "black magic sorcery", and "best practices" that grey-haired old wizards pick up. More often than not, they're invalidated by some advancement in either computer hardware or software. Not just "no longer relevant", but often counterproductive. Worse still, these internalised tricks and rules are often related to Moore's law scaling, making them exponentially wrong over time. Not in the figurative sense, but a literal one. You see this with people claiming that I'm exaggerating when I say all code should be parallel. Meanwhile AMD is about to sell a 128 core / 256 thread processor. You can have two per host for a staggering 512 hardware threads. Single threaded code is capable of utilising just 0.2% of that machine! A similar "tuning best practice" that I still see applied in the field is database servers with dedicated data, log, temp, and templog drives... on cloud VMs where this is guaranteed to have worse performance than simply pooling the same amount of disk into a single logical drive. People pick these things up and hold on to them when they're wrong by orders of magnitude. I can't think of many (any?) other industries where more experienced senior staff can be this wrong about as many things...

cleanchit 4y ago
I wish unzip, tar etc were multithreaded/
- nix23 4y ago
  -https://zlib.net/pigz/ https://zlib.net/pigz/ -https://manpages.ubuntu.com/manpages/xenial/man1/pxz.1.html https://manpages.ubuntu.com/manpages/xenial/man1/pxz.1.html -https://lzip.nongnu.org/plzip.html https://lzip.nongnu.org/plzip.html And so on, however the Compression-ratio is slightly worse
  - 5e92cb50239222b 4y ago
    + tar -cf - input/ data/ | zstdmt > out.tar.zst
skrebbel 4y ago
I dont know man, 10 years ago I saw an alarmist talk from Martin Odersky about how 128 core computers were around the corner and we should all switch to Scala for safe&easy parallellism and now when I go to the laptop shop it’s all 8, maybe 10 cores. We’ve been promised these magical ultra parallel machines for a decade now and either they’re much harder to build than the alarmists say, or there's simply no market.
- sharpneli 4y ago
  One reason is that they are already here. It's just called the GPU which happens to be way more parallel than puny 128 cores. That's a major reason why just bunch of low power CPUs are not really a thing, as they get trashed by GPUs. What we are seeing is a hierarchy of processing cores. It's already visible even in the desktop market. Intel has their efficiency cores. Apple has the power and efficiency cores. And the GPU on top. So we already have 3 different stages here, at the top the least amount of cores but the best single threaded performance going all the way down to, let me check how many threads, almost 10000 threads on a flagship consumer GPU running simultaneously right now.
  - nine_k 4y ago
    Indeed. MCUs are even further in this regard, combining 32-bit and 64-bit cores.
  - moonchrome 4y ago
    Except GPU cores are nothing like CPU cores, GPGPU was around 10 years ago, and whatever scala language/framework features he was shilling are probably useless for that kind of programming - so that's a failed prediction.
    - sharpneli 4y ago
      On that I fully agree. And the reason why scala approach doesn't work is because it's horrendously inefficient. What actually does work at massive scale is the GPU style workload. Intel tried with their Larrabee on what happens if they just toss in ton of traditional low performance CPU cores. It failed to perform. It's really hard to beat the modern SIMT style GPUs when it comes to massively parallel computation.
rwmj 4y ago
No swap is another one. For everyone who believes you should turn off swap, please read: https://chrisdown.name/2018/01/02/in-defence-of-swap.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html Edit to clarify: SwapPING bad, having swap space good.
- shakow 4y ago
  I don't know, the only thing I ever noticed whne using swap was : > Disabling swap doesn't prevent pathological behaviour at near-OOM, although it's true that having swap may prolong it. Basically, the memory manager will just bulldoze through moving all the other applications to the swap to let the leaking program pursue its leak. > you are left with a system in an unpredictable state. Having no swap doesn't avoid this. Yes, it does: the program that leaked my 16GB is killed at the very beginning of the situation, and I don't have to either wait dozens of minutes for it to fill the swap on top of that to finally be killed, or just hard reboot the machine and lose the whole state.
  - tsimionescu 4y ago
    > Yes, it does: the program that leaked my 16GB is killed at the very beginning of the situation How, and by whom? In a situation where you are running out of memory, it is programs that allocate the most often that have the highest chance of seeing an OOM, not those that allocate the most total amount. Also, on Linux, just because you don't have a swap partition doesn't mean things won't get swapped out to disk. Any memory mapped files will be swapped back to disk before issuing OOM problems - and the most common case of memory mapped files is executables and libraries. Which is of course the very thing that leads to a kind of livelock of swapless Linux systems that live close to 100% memory utilization: every time a thread is woken up, the instruction pipeline stalls until the next CPU instruction can be read from disk, slowing everything to a crawl.
    - shakow 4y ago
      > How, and by whom? By the kernel OOM killer? Is that supposed to be a trick question? > In a situation where you are running out of memory, it is programs that allocate the most often that have the highest chance of seeing an OOM, not those that allocate the most total amount. I don't really care; it still beats the machine being unresponsive for hours, especially if it's a remote one I dont have access to. > Also, on Linux, just because you don't have a swap partition doesn't mean things won't get swapped out to disk. Any memory mapped files will be swapped back to disk before issuing OOM problems That's not what is commonly understood by swapping though; that's a cache purge. > every time a thread is woken up, the instruction pipeline stalls until the next CPU instruction can be read from disk, slowing everything to a crawl. When you have swap enabled, yes; that the whole problem. However, IME, OoM just leads to the problematic program being quickly killed, then the user being able to go back to work.
ilyt 4y ago
> Single threaded code is capable of utilising just 0.2% of that machine! You can still server 512 different clients at once and still utilize 100% of the CPU. The parallelism is only a requirement if you want to compute one thing faster, not a bunch of things at once. Very much the desirable property for databases (although even that can be worked around with sharding if you're stubborn enough) but many developers code could be painfully serial yet still be perfectly fine to scale.
m463 4y ago
I remember many years ago when self-modifying code was fairly common.
public_defender 4y ago
> I can't think of many (any?) other industries where more experienced senior staff can be this wrong about as many things... Lawyer enters the thread. It's more common than you think. When complex work is done within power structures, it's just not enough to be "right" about something. You also have to be able to sell your solution to people who are wrong and powerful, which is sometimes not possible.
- jiggawatts 4y ago
  The knowledge a lawyer acquires about the law doesn't go stale very fast. Many laws have been on the books for a century or more, and precedent is also established slowly and incrementally. A lawyer from 10 years ago that memorised some good "rules of thumb" about generic matters such as liability or court procedure won't have to throw out everything they know to be relevant today or another decade into the future. Meanwhile in IT, I regularly see network engineers upgrading links from 500 megabits to 1 gibabit when they should be looking at upgrading to 100 or even 200 gigabits. Their mental model of what's fast, relevant, or desirable is "off" by two orders of magnitude. Their knowledge was accurate just a decade ago, but is hilariously wrong now. I can't think of any other mainstream profession where institutional knowledge is deprecated as quickly.
anarazel 4y ago
> A similar "tuning best practice" that I still see applied in the field is database servers with dedicated data, log, temp, and templog drives... on cloud VMs where this is guaranteed to have worse performance than simply pooling the same amount of disk into a single logical drive. It's not guaranteed to be worse. For latency sensitive OLTP workloads dedicated, smaller, disks for the journal can result in substantially lower & predictable latency. Random reads for the data exhausting iops, causing stalls of journal writes isn't fun. There's also per-disk queuing on a bunch of levels, and avoiding intermingling data and journal writes can be quite beneficial. That's not to say it's always better, at all. But making it out to be a stupid thing one should never do isn't wise either.
msm_ 4y ago
> You see this with people claiming that I'm exaggerating when I say all code should be parallel. I mean, you're clearly exaggerating. My ad-hoc Python scripts don't have to be parallel.
tjoff 4y ago
>Single threaded code is capable of utilising just 0.2% of that machine! Promise? That's fantastic! Because few things deserve to use more than 0.2% percent of that machine. Sure, you could parallel it, and now it takes 0.3% to do what could easily be done quicker and saner by 0.1%.
- jiggawatts 4y ago
  > deserve I too like to anthropomorphize scripts and punish them for their transgressions by constraining their resources.
codeflo 4y ago
Some of the things you claim are very context-specific and not true in general, which I find jars a bit with the (perceived by me to be) authoritative tone of your post. > I love these "rules of thumb", "black magic sorcery", and "best practices" that grey-haired old wizards pick up. Just quoting this to point out what I mean by addressing your tone. It's fine to disagree, but this feels like you're setting up that everyone who disagrees with you must be condescending and stuck in the past. Yes, performance advice is often tied to the specific situation, but that's also true for the things you state. > Worse still, these internalised tricks and rules are often related to Moore's law scaling, making them exponentially wrong over time. Not in the figurative sense, but a literal one. Implying that Moore's Law makes anything exponentially faster is an anachronism (talk about old knowledge!), it only makes things exponentially more parallel nowadays. See next point why that's relevant. As others have already clarified, -fomit-frame-pointer was sometimes 20% on x86. For some applications, people would kill for a 20% boost in single-threaded performance, even today! And importantly, that this specific optimization has become useless on x64 says nothing about the value of optimizations in general. Different ones are still useful, to give an example let's say SIMD (where it applies). > You see this with people claiming that I'm exaggerating when I say all code should be parallel. Meanwhile AMD is about to sell a 128 core / 256 thread processor. You can have two per host for a staggering 512 hardware threads. Single threaded code is capable of utilising just 0.2% of that machine! I'm not sure which strawman "grey-haired" developer you have in mind that buys a 512-thread server to run single-threaded code on it and then needs you to explain to them that they should parallelize it. Maybe you've met that person. But in general: Doesn't most code live in web servers nowadays anyway? If so, it's either already running in parallel, or can be made to do so with very little effort. BTW, parallelizing code in a web server can be harmful (!) to total throughput due to communication overheads. This is something that I find people don't always realize when they naively parallelize something, and is also sometimes missed by benchmarks that don't put the server under heavy load. > A similar "tuning best practice" that I still see applied in the field is database servers with dedicated data, log, temp, and templog drives... on cloud VMs where this is guaranteed to have worse performance than simply pooling the same amount of disk into a single logical drive. A statement like this depends on many concrete details about the specific cloud infrastructure (you didn't say AWS, you said "cloud"), and cloud VMs are usually not the best performing way to run a database anyway. So again, this is very context-specific. Also, if database performance is critical enough that you consider tuning these things, then renting bare metal should at least be a consideration as well. People who have never measured it are sometimes surprised by how large the virtualization overhead is (and how cheap it is to rent physical servers). On actual hardware, this advice might still be relevant. > I can't think of many (any?) other industries where more experienced senior staff can be this wrong about as many things... The actual point is that you should measure things in concrete cases, not make general claims. In that sense, I unfortunately don't find your "updated" way to state what supposedly is and isn't relevant not much of an improvement to the "outdated" claims you argue against so vehemently.
LarryMullins 4y ago
> You see this with people claiming that I'm exaggerating when I say all code should be parallel. Meanwhile AMD is about to sell a 128 core / 256 thread processor. You can have two per host for a staggering 512 hardware threads. Single threaded code is capable of utilising just 0.2% of that machine! Whether or not this argument holds water depends entirely on the context of the situation; what is the relationship between the program being considered and the computer? If the program is the reason for that hardware to exist, then obviously you want to use that hardware to it's fullest potential. If you've bought a 256 core machine specifically to run this program, then obviously you want to use all those cores. Some sort of threaded or multiprocess architecture should be an easy sell in this sort of circumstance. It shouldn't even be a discussion. But on the other hand, what if the program under consideration is ancillary? In that case, the program should use the bare minimum resources necessary, so as to not get in the way of whatever the primary program may be. If you have say.. a music playing daemon, then odds are your program should not be trying to use the host machine to it's fullest because that hardware actually exists to get some other job done. Ancillary programs should be designed to survive on leftover scraps, not with the assumption that they'll have first dibs on the use of the hardware.
- jiggawatts 4y ago
  These are kinds of generic recommendations you listed are precisely the type that go out-of-date. Even on a laptop, I now have 16 threads and almost never see more than 1 utilised even when I'm waiting. Any time a human waits for a computer that is just 6% utilised, a developer screwed up. Just this minute, I downloaded a program installer using a 10 Gbps Internet link. Yes. Ten gigabits, dedicated to me, personally! Your idea of "what is a fast Internet link" is wrong. I downloaded a 600 MB software package in less than a second, and then had to wait for 30 seconds while the anti-malware tools scanned it... with a single thread. Extracting the file was 10 seconds because 'zip' is by default single threaded. Installing it took a solid minute during which my CPU usage never peaked above 2 cores because the installer is also single threaded. The only reason it uses more than 1 core is because the anti-malware scans it... again... on a second thread. Similarly, any time I see anyone manipulating ~1 GB of data, invariably they do it with GUI or CLI tools that are single threaded. This was desirable in an era when everyone had a single mechanical HHD. Multiple read or write threads would have caused disk head seeks, slowing down the process. These days when everyone has NVMe SSDs, the only way to fully utilise the 500K IOPS available from a $150 device is by throwing dozens of parallel threads at it!
kristopolous 4y ago
There's no practical way to avail yourself to all the latest advancements that find their way into your work in computers. Even as someone who tries to actively question assumptions that may no longer hold I still find myself constantly flat-footed. I can't pretend like I know all the various advancements in processor architecture of the past 5 years (since 2018) or how modern compilers exploit them and also the latest techniques in GPU computing. Heck even old rules of thumb like the speed of platter drives are being challenged - mechanical drives with 500M/s throughput are hitting the shelves this year. I just upgraded a platter RAID where I'm getting ~1000M/s. The SSD delta has changed (that's of course assuming SSD hasn't moved which I'm sure is also false). I'm sure there's new advancement in material science and manufacturing that I'm also not privy too which has made this possible. Storage alone is another vast world. I don't know all the features of ext4, xfs, zfs, hammer, and btrfs or how to competently compare and tune them for various workloads or how that analysis has changed in say the past 24 months. This is something I became intimately aware of when upgrading the array. I didn't know any of the modern tools or approaches. All knowledge in this space eventually becomes vestigial and outdated and it's physically impossible to keep up. I haven't even kept up with the latest C features. Then there's Go, Rust, Typescript and countless other languages that each require at minimum, a hundred hours a year each to competently follow. The best we can do is have humility and continually approach things as a student because we never know what table leg has been knocked out underneath us without our noticing.

masklinn 4y ago

> With 32 bit code X86. No other 32b architecture is that register-starved even if the larger number of registers is somewhat mitigated by being load-store.

sharpneli 4y ago
Not just X86, the older X86. Before Pentium Pro there was not even register renaming. So one was both register starved and the registers you saw where actually the registers you got. Even after that it was still somewhat starved but it alleviated the problem greatly. Nowadays X64 has a decent amounts of registers + the HW internally has several times more the registers, so saving one is almost meaningless.

saagarjha 4y ago

Definitely not 20-30%. Maybe 10% on certain workloads.

jandrese 4y ago
It was. The amount of improvement varied by application, but this was testing with real world applications like JPEG libraries, MP3 libraries, compression, etc... Of course this was back in the 90s and early 2000s so back in the dinosaur ages by computer standards. Almost certainly using gcc 2.95 on a Pentium 75. It was the only optimization flag that made more than a couple percent difference.