4 ms·

Earlier today on HN there was a submission about great CPU stagnation. In the blog post was an interesting link: https://raw.githubusercontent.com/karlrupp/micr

by kpw94 3y ago

Earlier today on HN there was a submission about great CPU stagnation. In the blog post was an interesting link: https://raw.githubusercontent.com/karlrupp/microprocessor-trend-data/master/50yrs/50-years-processor-trend.png https://raw.githubusercontent.com/karlrupp/microprocessor-tr... This graph to me show that while yes technically Moore's law of doubling transistor per "thing Intel or AMD sells you" is still holding, it has ended for single threaded workloads. Moore's law is only holding due to core count increase. For everyday use of users running multiple simple programs/apps, that's fine. But for truly compute heavy workloads (think a CAD software or any other heavy processing), developers turned to GPUs to get the compute power improvements. Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law). So even if one wanted to rearchitect programs to take full advantage of the overall transistor count from ~2005 to now, they won't be able to. Compare with pre-2005, where one just had to sit & wait too see their CPU-heavy workloads improve... It's definitely a different era of compute improvements

hardware2win 3y ago
>Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law). Do you need theoretical full? Practical full is enough and still huge improvement over single core
- kaba0 3y ago
  That’s up the the program — if the non-parallelisable parts are big, then you won’t get big speedups no matter what — GPUs are used for tasks that are widely parallelisable, GUIs (as in desktop environments) won’t really benefit from a 10x faster GPU.
aaron695 3y ago
> Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law) I don't see this as true at all, using Wikipedias example - "a program needs 20 hours to complete using a single thread, but a one-hour portion of the program cannot be parallelized, therefore only the remaining 19 hours execution time can be parallelized, then regardless of how many threads the minimum execution time is always more than 1 hour" Just increase "19 hours" to "400 hours" execution time, it's possible to increase output as far as you want. If you're mind set can't get past the "one hour" matters sure or change your mind set to the "19 hours" part of the calculation is what matters. I don't fully get Gustafson's Law, but maybe it touches on this.
- thfuran 3y ago
  >Just increase "19 hours" to "400 hours" execution time, it's possible to increase output as far as you want. Yeah, sure. Just give up on the thing you wanted to do and instead do something entirely different that is more parallelizable. That'll keep your CPU utilization high, but it won't actually accomplish your goal (presuming you were using software for some purpose other than maximizing CPU utilization).
  - aaron695 3y ago
    [dead]
warrenm 3y ago
>Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law). So even if one wanted to rearchitect programs to take full advantage of the overall transistor count from ~2005 to now, they won't be able to. I don]t think that's the goal right now, though - it's about parallelizing multiple separate tasks/programs/etc: IOW, you can run 50 applications on a single 64 core CPU that used to take 50 individual servers
- thfuran 3y ago
  Not many consumers are running 50 applications at once on their home servers.
dyingkneepad 3y ago
My most CPU-intensive usage is compilation and "make -j8" is doing a pretty good job at scaling things to fully utilize my CPU. It's not about one program using all your resources.
- jdsully 3y ago
  Linking is still super slow, especially if you use link time code generation.
  - eklitzke 3y ago
    LTO basically just calls back into the compiler and is multi-threaded on lld and mold at least, and probably anything else that supports LTO. And make sure you're using ThinLTO, it's still expensive but much faster than full LTO.
  - satvikpendem 3y ago
    Have you tried the mold linker? I've been using it and it works pretty well, quite fast. https://github.com/rui314/mold https://github.com/rui314/mold
wetpaws 3y ago
[dead]

by kpw94 3y ago

hardware2win 3y ago

>Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law). Do you need theoretical full? Practical full is enough and still huge improvement over single core

kaba0 3y ago
That’s up the the program — if the non-parallelisable parts are big, then you won’t get big speedups no matter what — GPUs are used for tasks that are widely parallelisable, GUIs (as in desktop environments) won’t really benefit from a 10x faster GPU.

aaron695 3y ago

> Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law) I don't see this as true at all, using Wikipedias example - "a program needs 20 hours to complete using a single thread, but a one-hour portion of the program cannot be parallelized, therefore only the remaining 19 hours execution time can be parallelized, then regardless of how many threads the minimum execution time is always more than 1 hour" Just increase "19 hours" to "400 hours" execution time, it's possible to increase output as far as you want. If you're mind set can't get past the "one hour" matters sure or change your mind set to the "19 hours" part of the calculation is what matters. I don't fully get Gustafson's Law, but maybe it touches on this.

thfuran 3y ago
>Just increase "19 hours" to "400 hours" execution time, it's possible to increase output as far as you want. Yeah, sure. Just give up on the thing you wanted to do and instead do something entirely different that is more parallelizable. That'll keep your CPU utilization high, but it won't actually accomplish your goal (presuming you were using software for some purpose other than maximizing CPU utilization).
- aaron695 3y ago
  [dead]

warrenm 3y ago

>Writing amazing programs taking full advantage of the core count increase is simply impossible (see Amdahl's law). So even if one wanted to rearchitect programs to take full advantage of the overall transistor count from ~2005 to now, they won't be able to. I don]t think that's the goal right now, though - it's about parallelizing multiple separate tasks/programs/etc: IOW, you can run 50 applications on a single 64 core CPU that used to take 50 individual servers

thfuran 3y ago
Not many consumers are running 50 applications at once on their home servers.

dyingkneepad 3y ago

My most CPU-intensive usage is compilation and "make -j8" is doing a pretty good job at scaling things to fully utilize my CPU. It's not about one program using all your resources.

jdsully 3y ago
Linking is still super slow, especially if you use link time code generation.
- eklitzke 3y ago
  LTO basically just calls back into the compiler and is multi-threaded on lld and mold at least, and probably anything else that supports LTO. And make sure you're using ThinLTO, it's still expensive but much faster than full LTO.
- satvikpendem 3y ago
  Have you tried the mold linker? I've been using it and it works pretty well, quite fast. https://github.com/rui314/mold https://github.com/rui314/mold

wetpaws 3y ago

[dead]