3 ms·

You may be right in general about my take being too cynical, but I have to counter this in particular: > and typically they stay idle while waiting for IO Tha

by paol 2y ago

You may be right in general about my take being too cynical, but I have to counter this in particular: > and typically they stay idle while waiting for IO That's just not how you size servers. If most of your cores are idle you will add more work to the server, or you will have bough one with fewer cores to begin with.

lionkor 2y ago
There's plenty of work that will max out your NiC before maxing out all cores, or even one, with reasonably efficient code. At some point youre just actually pushing 10 Gbit/s through a process that is using a few 10-15% per core.
- paol 2y ago
  You're missing my point. Servers are very expensive and are sized to task. If your NICs (or whatever) bottleneck the server with 32 cores worth of load, then you buy a server with 32 cores, not one with 64 cores.
  - lionkor 2y ago
    Fair
chipdart 2y ago
> If most of your cores are idle you will add more work to the server, or you will have bough one with fewer cores to begin with. I don't think you understood the issue. It's not that cores will be idle. It's that the bulk of their workloads is not performance-oriented. They are there to context-switch while handling IO-bound tasks. You'd be wasting money if you pay a premium on high-performance cores if you're using them in IO-bound workloads. You waste money buying the processor, and you waste money powering performance-oriented cores to run workloads that do not benefit from this performance. For the same budget, you are far better off having a larger number of efficient cores than a smaller number of high-performance cores. Because you are running more efficient cores, you can cram more of them in the same package without ramping up cooling needs. Think about it for a second: where is the performance bottleneck of your server if the bulk of its load consists of IO? You should turn your conspiracy theory upside down and ask yourself how come a cloud provider is interested in running more cores in smaller spaces and in spending less energy cooling them.

by paol 2y ago

lionkor 2y ago

There's plenty of work that will max out your NiC before maxing out all cores, or even one, with reasonably efficient code. At some point youre just actually pushing 10 Gbit/s through a process that is using a few 10-15% per core.

paol 2y ago
You're missing my point. Servers are very expensive and are sized to task. If your NICs (or whatever) bottleneck the server with 32 cores worth of load, then you buy a server with 32 cores, not one with 64 cores.
- lionkor 2y ago
  Fair

chipdart 2y ago

> If most of your cores are idle you will add more work to the server, or you will have bough one with fewer cores to begin with. I don't think you understood the issue. It's not that cores will be idle. It's that the bulk of their workloads is not performance-oriented. They are there to context-switch while handling IO-bound tasks. You'd be wasting money if you pay a premium on high-performance cores if you're using them in IO-bound workloads. You waste money buying the processor, and you waste money powering performance-oriented cores to run workloads that do not benefit from this performance. For the same budget, you are far better off having a larger number of efficient cores than a smaller number of high-performance cores. Because you are running more efficient cores, you can cram more of them in the same package without ramping up cooling needs. Think about it for a second: where is the performance bottleneck of your server if the bulk of its load consists of IO? You should turn your conspiracy theory upside down and ask yourself how come a cloud provider is interested in running more cores in smaller spaces and in spending less energy cooling them.