4 ms·

Well, you're thinking in terms of parallelising a single task. For a server, you're talking about a large number of concurrent tasks (users), so more cores are

by xienze 12y ago

Well, you're thinking in terms of parallelising a single task. For a server, you're talking about a large number of concurrent tasks (users), so more cores are better in that case.

joosters 12y ago
That's basically a truism. If you have parallelisable tasks, then they will parallelise. No surprise there. I was trying to make the point that as we step up the number of cores, the actual gain is less and less.
- deleted 12y ago
  [deleted]
- rbanffy 12y ago
  Again, as it was pointed out earlier, no. If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases (memory bottleneck excepted). It's not a processor designed to run Office or Firefox, but it may be very interesting on a server or as a competitor for the Xeon Phi. BTW, considering even my humble laptop can do 8 threads at once, it's about time we started building office suites and browsers to take advantage of these processors.
  - jallmann 12y ago
    > If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases Only if the tasks are trivially parallelizable. Any sequential dependencies among those tasks limit the effectiveness of parallelization. This is exactly what Amdahl's Law says. > my humble laptop can do 8 threads at once, it's about time we started building office suites and browsers to take advantage of these processors. Multiple browser tabs or open office documents are trivially parallelizable (eg, processes). The work within those tabs or documents is not linearly parallelizable -- running JS/macros, handling input, rendering, etc. Existing browser/office suites already do a pretty good job of splitting these tasks up, but they can't be split up arbitrarily into $core_count chunks.
    - rbanffy 12y ago
      > Only if the tasks are trivially parallelizable Which is a very common scenario on web and application servers, specially if you design your web applications to be scalable. > Multiple browser tabs or open office documents are trivially parallelizable They would be if I could pay attention to more than one tab or document at any given time. In reality, I spend most of my time with full-screen apps and there is little point to keep other tabs or documents running.
      - joosters 12y ago
        > Which is a very common scenario on web and application servers, specially if you design your web applications to be scalable. Doesn't matter. You can (and probably will) still hit horrible bottlenecks in the network stack. Another flashback to developing on the 64+ Niagara cores. We were running an embarassingly scalable web application - loads of independent concurrent requests - but the Solaris OS just couldn't keep up. Has your NIC driver been optimised to scale for tens/hundreds of CPUs, I wonder?
  - zmanian 12y ago
    There is a lots of interesting work on building office suites and browsers that can take advantage of parallelism. But the general consensus is that we need to invent new lower level tools first. See Rust + Servo and MSFT + M#
- higherpurpose 12y ago
  You're missing the point. I think everyone knows what you're saying is true for a mobile phone or even a desktop PC. Where it's NOT true is on servers, where tasks are "parallelized" since you have millions of concurrent users, so whether you have 1 million 8-core servers, or 125,000 64-core servers it doesn't matter much, because it's pretty much the same thing. But from a whole datacenter perspective, I believe having servers with more cores is more efficient than having more servers with fewer cores, since data travels faster between more of the cores.
  - jallmann 12y ago
    This whole thread is talking past each other. Servers absolutely can have sequential dependencies, especially if there is a shared resource (eg, databases, IO, etc). If your application can make full use of all your cores without any inter-dependencies, great -- but that is not always the case.
  - ethbro 12y ago
    "But from a whole datacenter perspective, I believe having servers with more cores is more efficient than having more servers with fewer cores, since data travels faster between more of the cores." How are you looking at this? From limited CompE background, my understanding was that moving data around core -> core burned a significant amount of power, even on the same die. (Using the comparison of one core vs two equally performing but separate cores)
bitL 12y ago
Actually, this holds only up to certain extent. Synchronization, locking, memory access patterns and context-switching from many threads with accompanied cache thrashing can bring the effective parallelization to very small levels. I remember from benchmarking a high performance transactional messaging system in Java I was working on seeing how it hit a flat line at some point where it didn't scale at all due to CPU/memory contention (this depended on maximal number of threads allowed). We had to look at alternative designs such as 0MQ to see how they overcame it - basically they put one working/client thread per core to achieve their 1M messages/s. We were using 10s of thousands of threads in our middleware when necessary, and that was faster than async NIO in Java 6 at that time.

by xienze 12y ago

Well, you're thinking in terms of parallelising a single task. For a server, you're talking about a large number of concurrent tasks (users), so more cores are better in that case.

joosters 12y ago

That's basically a truism. If you have parallelisable tasks, then they will parallelise. No surprise there. I was trying to make the point that as we step up the number of cores, the actual gain is less and less.

deleted 12y ago
[deleted]
rbanffy 12y ago
Again, as it was pointed out earlier, no. If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases (memory bottleneck excepted). It's not a processor designed to run Office or Firefox, but it may be very interesting on a server or as a competitor for the Xeon Phi. BTW, considering even my humble laptop can do 8 threads at once, it's about time we started building office suites and browsers to take advantage of these processors.
- jallmann 12y ago
  > If you have 48 runnable threads from 48 different tasks running on your machine, you'll get pretty much linear performance increases Only if the tasks are trivially parallelizable. Any sequential dependencies among those tasks limit the effectiveness of parallelization. This is exactly what Amdahl's Law says. > my humble laptop can do 8 threads at once, it's about time we started building office suites and browsers to take advantage of these processors. Multiple browser tabs or open office documents are trivially parallelizable (eg, processes). The work within those tabs or documents is not linearly parallelizable -- running JS/macros, handling input, rendering, etc. Existing browser/office suites already do a pretty good job of splitting these tasks up, but they can't be split up arbitrarily into $core_count chunks.
  - rbanffy 12y ago
    > Only if the tasks are trivially parallelizable Which is a very common scenario on web and application servers, specially if you design your web applications to be scalable. > Multiple browser tabs or open office documents are trivially parallelizable They would be if I could pay attention to more than one tab or document at any given time. In reality, I spend most of my time with full-screen apps and there is little point to keep other tabs or documents running.
    - joosters 12y ago
      > Which is a very common scenario on web and application servers, specially if you design your web applications to be scalable. Doesn't matter. You can (and probably will) still hit horrible bottlenecks in the network stack. Another flashback to developing on the 64+ Niagara cores. We were running an embarassingly scalable web application - loads of independent concurrent requests - but the Solaris OS just couldn't keep up. Has your NIC driver been optimised to scale for tens/hundreds of CPUs, I wonder?
- zmanian 12y ago
  There is a lots of interesting work on building office suites and browsers that can take advantage of parallelism. But the general consensus is that we need to invent new lower level tools first. See Rust + Servo and MSFT + M#
higherpurpose 12y ago
You're missing the point. I think everyone knows what you're saying is true for a mobile phone or even a desktop PC. Where it's NOT true is on servers, where tasks are "parallelized" since you have millions of concurrent users, so whether you have 1 million 8-core servers, or 125,000 64-core servers it doesn't matter much, because it's pretty much the same thing. But from a whole datacenter perspective, I believe having servers with more cores is more efficient than having more servers with fewer cores, since data travels faster between more of the cores.
- jallmann 12y ago
  This whole thread is talking past each other. Servers absolutely can have sequential dependencies, especially if there is a shared resource (eg, databases, IO, etc). If your application can make full use of all your cores without any inter-dependencies, great -- but that is not always the case.
- ethbro 12y ago
  "But from a whole datacenter perspective, I believe having servers with more cores is more efficient than having more servers with fewer cores, since data travels faster between more of the cores." How are you looking at this? From limited CompE background, my understanding was that moving data around core -> core burned a significant amount of power, even on the same die. (Using the comparison of one core vs two equally performing but separate cores)

bitL 12y ago

Actually, this holds only up to certain extent. Synchronization, locking, memory access patterns and context-switching from many threads with accompanied cache thrashing can bring the effective parallelization to very small levels. I remember from benchmarking a high performance transactional messaging system in Java I was working on seeing how it hit a flat line at some point where it didn't scale at all due to CPU/memory contention (this depended on maximal number of threads allowed). We had to look at alternative designs such as 0MQ to see how they overcame it - basically they put one working/client thread per core to achieve their 1M messages/s. We were using 10s of thousands of threads in our middleware when necessary, and that was faster than async NIO in Java 6 at that time.