Comment by kpw94 | Hacker News Reader

Comment by kpw94 | Hacker News Reader

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-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

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.

Linking is still super slow, especially if you use link time code generation.

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.

Have you tried the mold linker? I've been using it and it works pretty well, quite fast.

https://github.com/rui314/mold

>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

Not many consumers are running 50 applications at once on their home servers.

>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

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.

> 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.

>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).

Reply on news.ycombinator.com