> Parallel stupid small cores without caches are horrible unless you have a very specific load that is hugely regular (ie graphics).
And
> The only place where parallelism matters is in graphics or on the server side, where we already largely have it. Pushing it anywhere else is just pointless.
Edit: "editorialized" meaning "choosing the most extreme quote of a rant"
"The whole "let's parallelize" thing is a huge waste of everybody's time. There's this huge body of "knowledge" that parallel is somehow more efficient, and that whole huge body is pure and utter garbage."
But in a Linus rant, the most inflammatory quotes are not necessarily what he is trying to say. (That statement is also editorializing, of course)
- 3D Graphics
- 2D Graphics (Photoshop, video editing and encoding)
- Web Browsers
This is where we really use parallel computing. Maybe compilers, file compression and PAR2 on top of that. What else? So theres some truth to that.
For the other argument, that a small number of complex OoO cores is better than a huge number cores with slow single-thread performance for client PCs should be obvious, imho.
Dedicated compression/decompression threads, threads for encryption, threads for sound, threads for... well lots of things. Remove the caches and you get more consistent performance. Dedicate tasks to their own core, and they can use that cache for themselves. They don't have to swap it out every time.
- Science...
Most laptops / desktops perform much better with at least two cores than one core. Particularly if you have a CPU hogging process - your UI can't remain buttery smooth interactive. There is even some argument to be be made from going from two to four. (Background application like a render, plus another App doing something nasty killing your CPU - you can still launch activity manager and kill the errant task).
But, It's not clear to me there's any value for the client for taking a four core machine and breaking it up any further as opposed to taking the increased transistor budget and improving those existing four cores.
Remember - the tradeoff is not "Do we want more, faster, transistors" - of course we do. Rather, the tradeoff is do we make smaller, lower cache cores, or do we make larger, bigger cache cores.
The evidence tends to suggest for the near future, that bigger cache, faster cores are the way to go on your average desktop/laptop.
There is not much space for improvement left. ILP had been stagnating quite for a while, and there is no hope of improvement with the current ISAs. More OoO-friendly ISAs are being developed, but are unlikely to hit the market any time soon.
Caches are also approaching the upper limit, and for the bigger caches we need either some much smarter cache management techniques (explicit prefetching, etc.), or a totally different programming model (e.g., using a flat scratchpad memory explicitly instead of transparent caches).
Core count grows for a reason - there is not really much stuff we can put into a single core any further, not without breaking the whole architecture.
I.E. It might be still more useful to build bigger 4-core processors, simply because all the developers and code out there are designed to take advantage of them - and a theoretically better 6-core processor would just end up with 2-3 cores always idling.
In the said case of parallel compilation of, say, JS, it's only a tiny minority of the developers who need to be able to do so.
> It might be still more useful to build bigger 4-core processors
It would have been great if we could build any bigger cores. Unfortunately, there is not much scope for improvement left, not unless we ditch the existing ISAs and programming models.
If you're getting this number from Activity Monitor, then I doubt it has any relevance to the current conversation.
Activity Monitor tells me Emacs is currently using 4 "threads", and Emacs is famously non-threaded.
The "threads" mentioned by Activity Monitor probably have something to do with OS X's being implemented on a Mach microkernel rather than the kind of threads that would matter for this conversation.
But I sort of agree with you (see my long rant elsewhere in this thread).
This is really the gist of the parallelism problem: it only helps when applied to the bottlenecks. Browsers aren't really using it to layout single pages faster, or running JS faster.
Yeah, there's some work on parallelism in rendering and GC in production browsers too but it's so far nibbling at the edges. Long way to go to get even 2x speedup compared to single core.
> The whole "let's parallelize" thing is a huge waste of everybody's time.
And
> Give it up. The whole "parallel computing is the future" is a bunch of crock.
lkml in a news post is like clickbait for a certain susbet of the techy crowd. I think we need a collective understanding that if someone other than lwn is reposting lkml it's just drama-mongering, pot-stirring or muckraking.
I think it attracts people because it carries the possibility of being something significant given the crowd there and kernel itself. But it's just the mundane day to day of people working on subject matter too dry for one to subscribe to in the first place.