Live data from Hacker News

Ask HN: Why are modern Intel CPUs not getting a lot more cores?

news.ycombinator.com

31–40 of 71 posts

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#31

I agree with the "less core but faster processors are what is most useful on desktops". But I ask, has anyone one or any language made the number of processors/hyperthreads transparent? Ideally I would just create a thread and some load balancing system would distribute it to the correct processor. Am I just behind the times?

Uh, that's what happens...? In Windows 2012, the new feature is actually that you can explicitly stop the OS doing that, by forcing specific processes to specific cores only.

The issue people have, usually, is about which process should have priority when (inevitably) more than one are competing for the same processor -- a question that has different answers depending on your particular type of workload.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#32

Earlier quoted context omitted.

Game engines really benefit from more processors if designed appropriately. And I think a lot of people play games. This will be even more true when VR/AR spreads to the masses.

Yes/No. Only game engines made in DX12, and Vulkan. And still there is the major road block that Nvidia (>70% market share) only offers 1 compute thread in async-compute mode, and no parallel rendering/compute work so using DX12/Vulkan means your game will work WORSE for 70% of your consumers.

Except that graphics rendering is the last step of the game engine.

Computing world changes, updating model locations, handling network traffic, sampling user input, saving game state for autosaves, preloading resources from the disk for transitions, all need cpu time.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#33

1) Nobody writes multi-threaded code For user applications multi-threading is overkill. It's hard to write, and there are very little benefits the average user will see. Good concurrency isn't even that important on servers. You can trash your cache and interrupt tables but you'll still handle 10million clients per node so nobody cares. Great concurrency is really only practiced in HFT and HPC. 2) Modern hardware/OS'…

1) I think this argument is plain wrong. It is incorrect that EVERY APP should use ALL CPUS. Rather, different apps use different cpus --> less interrupts --> speed up. 2) I think they are actually very good at what can be done by now. How do you think they are so bad?

1)

Yes, but then you need to manage IO thread affinity, this isn't commonly done. Also you need to manage what is running on which NUMA node as often on 2 node systems 1 is almost never interrupted except for cross CPU conversation.

Facebook moved to Single Socket Xeon-D's rather then bake task affinity to their HHVM run time. So yeah, people still screw this up a lot.

2)

The main answer to concurrency these days is to just swap thread stacks in userland when ever something blocks. Yeah this works fine, but it's no different then what the kernel does for you. The stack is just smaller, the swapping is baked into the user land program. So you end up breaking most debuggers, and your C-FFI gets very slow.

This isn't any faster then what the kernel is doing. It's just the language run-time limits stack size so the swapping happens faster. Setting smaller stack sizes and using Thread Groups yields similar performance.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#34

1) Nobody writes multi-threaded code For user applications multi-threading is overkill. It's hard to write, and there are very little benefits the average user will see. Good concurrency isn't even that important on servers. You can trash your cache and interrupt tables but you'll still handle 10million clients per node so nobody cares. Great concurrency is really only practiced in HFT and HPC. 2) Modern hardware/OS'…

3) Depends on the scale. If the task was running for 60 minutes then you would only have to wait 1.87 minutes which is a massive difference.

You are also forgetting the psychological impact that a few seconds can make. After 3 seconds of waiting without any progress indicator you've generally lost the attention of the user and they will do something else in the meantime.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#35
post #32

Earlier quoted context omitted.

Yes/No. Only game engines made in DX12, and Vulkan. And still there is the major road block that Nvidia (>70% market share) only offers 1 compute thread in async-compute mode, and no parallel rendering/compute work so using DX12/Vulkan means your game will work WORSE for 70% of your consumers.

Except that graphics rendering is the last step of the game engine. Computing world changes, updating model locations, handling network traffic, sampling user input, saving game state for autosaves, preloading resources from the disk for transitions, all need cpu time.

Most of these compute heavy tasks boil down to that game engines are very fast C++ programs, but the game itself is an embedded LUA script.

If you are using C++ all the way down event based IO is way more efficient for this. Having compute threads is useful depending how much physics/calculations you are doing.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#36

I agree with the "less core but faster processors are what is most useful on desktops". But I ask, has anyone one or any language made the number of processors/hyperthreads transparent? Ideally I would just create a thread and some load balancing system would distribute it to the correct processor. Am I just behind the times?

9 women still can't have 1 baby in 1 month.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#37

Memory bandwidth is another issue. What people forget in the recent deep learning pissing match between Intel and nvidia is that memory bandwidth limits mean the difference between optimized CPU, GPU and FPGA systems is not that much.

Memory bandwidth is the issue for scaling CPU cores. Very, very few problems can saturate 32 cores worth of computational work with the N-channel DDR memory, so there's no reason to design a Xeon or Opteron with more than that many. There may be challenges related to N-way cache coherency too.

> memory bandwidth limits mean the difference between optimized CPU, GPU and FPGA systems is not that much.

Well, not really -- the enormous memory throughput of GDDRx is much of what's fueled the growth in the GPGPU market over the last decade.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#38
post #2

Because common desktop applications still don't do much with multiple cores, and thus a few fast cores are better (and techniques like TurboBoost are useful, where cores sleep to free the energy budget to allow a single core to clock even higher). And for many things, CPUs have been fast enough for quite a while now. So the common CPUs have only a few cores, people who really want more get to pay the premium for the…

You can get full blown Xeon chips with 22 cores per socket nowadays. You don't have to go ARM or Xeon-D to get a ton of cores. http://ark.intel.com/products/91317/Intel-Xeon-Processor-E5-...

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#39

Memory bandwidth is another issue. What people forget in the recent deep learning pissing match between Intel and nvidia is that memory bandwidth limits mean the difference between optimized CPU, GPU and FPGA systems is not that much.

It totally depends on your algo. If you play to the GPUs strengths it will own CPU through pure additional grunt, but you have to design for it.

Re: Ask HN: Why are modern Intel CPUs not getting a lot more cores?

#40

1) Nobody writes multi-threaded code For user applications multi-threading is overkill. It's hard to write, and there are very little benefits the average user will see. Good concurrency isn't even that important on servers. You can trash your cache and interrupt tables but you'll still handle 10million clients per node so nobody cares. Great concurrency is really only practiced in HFT and HPC. 2) Modern hardware/OS'…

> Nobody writes multi-threaded code

Fires up your activity monitor or task manager and you can see that most applications have much more than one thread. Many even have tens or several tens of threads.

Post reply on HN