6 ms·

Heavily editorialized title. Actual quote: > Parallel stupid small cores without caches are horrible unless you have a very specific load that is hugely regula

• plinkplonk 12y ago
  Can a mod edit the title to something less inflammatory?
• MrBuddyCasino 12y ago
  I intuitively tried to come up with more examples to counter that claim, but all I can think of on the client side is: - 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.
  • illumen 12y ago
    How many processes do most users have on their desktops? Hundreds. I have 397 on my OSX laptop, and many of them are multithreaded. Firefox alone is using 61 threads. 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...
    • dfox 12y ago
      Another thing is how many of these threads are not blocked waiting for something to happen.
    • dagw 12y ago
      His argument is that running each of those 400 threads on its own tiny simple core will be a lot slower than splitting them up over 2-4 really fast cores. Even assuming a generous power budget of 100W that leaves only 0.25W pr core and that doesn't give you much processing power. It's probably a better use of time to focus on writing better context switching and multitasking algorithms for 2-4 core CPUs.
    • vidarh 12y ago
      Most of those will be waiting on IO. But I sort of agree with you (see my long rant elsewhere in this thread).
    • hollerith 12y ago
      >Firefox alone is using 61 threads. 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.
    • ghshephard 12y ago
      And those processes and threads will run faster on a four core machine than an equivalent eight core machine. Keep in mind, going from four cores to eight cores does not buy you any extra transistors - it's the same number of transistors. What it does do is introduce extra cache contention, and likely smaller caches. It also introduces extra layout complexity. 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.
      • pwr22 12y ago
        But surely is does buy you extra transistors in practice since the number of core tends to only increase every few years - meaning the additional cores come with new technological advances and are how the new transistors are put to use
      • sklogic 12y ago
        > taking the increased transistor budget and improving those existing four cores 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.
    • arielby 12y ago
      I have 150 processes on my Linux laptop, but very rarely are more than 4 of them runnable at the same time.
  • fulafel 12y ago
    Web browsers don't belong on the list yet. They have some fits and starts in the direction, Servo is one attempt.
    • MrBuddyCasino 12y ago
      Yeah its not quite there yet, but I included them because e.g. in Chrome we have web workers, separate processes for plugins, a separate renderer process, separate processes for tabs etc., and multithreading via NaCL. Maybe a corner case.
      • fulafel 12y ago
        Chrome is using separate sandboxed processes for the security boundaries, and it actually costs some performance. Tabs get mostly suspended when they're not active. 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.
• zurn 12y ago
  Actual quotes: > 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.
  • patal 12y ago
    Actual quotes, but out of context. Make the title "Linus: Parallelize everything is a huge waste of everybody's time", and that's what he's actually talking about.
• forgottenpass 12y ago
  Heavily editorialized title. 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.
  • zurn 12y ago
    This is the forum at David Kanter's Real World Tech site where people come to discuss computer architecture (think comp.arch heir), not LKML.
    • forgottenpass 12y ago
      The site was down, the pastebin mirror was just a email message I assumed lkml. I think the point still stands though.
• ezequiel-garzon 12y ago
  As zurn pointed out, it's not taken out of context at all. Right before your excerpt comes: "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."
  • VMG 12y ago
    True, that is in there. 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)
  • patal 12y ago
    The excerpt talks about widespread beliefs about how parallelizing everything is supposed to be good. OP's title suggests parallel computing in general. How's that not out of context?