4 ms·

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

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's suck at multithreading: IO interrupts are normally handled on 1 core. While you process data on any core. This causes some non-trivial caching issues. Furthermore putting 2 10GBE nic's on the same core can prevent you from actually using all 20GBE of bandwidth you have because the processor literally isn't fast enough. Then you need to set affinity for epoll thread, etc. etc. 3) Amdahl's Law: https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law Every time you double the number of execution units, even if your calculation gets twice as fast, the improvement factor constantly decreases. Take for example a 60 second calculation that can be fully parallelized 1 units: 60sec 2 units: 30sec 4 units: 15sec 8 units: 7.5s 16 unit: 3.75s 32 unit: 1.87s The transitions between 8-16-32 really show you the effect coming into play. Yes the calculation is being done faster. But the overall change from 8 to 32 units saves you ~5.63seconds, while using 4x the resources.

BatFastard 10y ago
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.
- valarauca1 10y ago
  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.
  - ccrngd1 10y ago
    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.
    - valarauca1 10y ago
      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.
    - lucian1900 10y ago
      All of those other things are significantly cheaper than graphics.
countryqt30 10y ago
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?
- valarauca1 10y ago
  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.
- pjc50 10y ago
  Most people have a single, important foreground app which is the only one they care about latency of. The others are ticking over in the background, but because they don't have window focus the user doesn't care about their responsiveness so much.
difftest 10y ago
3: Amdahl's law says that partially parallelizable applications don't see much improvement. 50% parallelizable program will run 33% faster on 2 cores (not 100%) 60% faster on 4 (not 300%).
melling 10y ago
Silicon is cheap, my time isn't. i'd rather the task finish in under 2 seconds.
mtgx 10y ago
That's an issue yes, but it's not the main reason why Intel isn't offering more cores for decent prices, otherwise we would've never even moved to two cores or four cores. The main reason is Intel doesn't feel like it needs to because AMD doesn't offer much competition with its current architecture, even with twice as many cores. But that will change when Zen chips arrive. http://www.extremetech.com/computing/233453-amd-zen-benchmarks-leak-point-to-potent-performance-against-intel-huge-gains-over-piledriver http://www.extremetech.com/computing/233453-amd-zen-benchmar... So wait until AMD launches Zen-based chips with twice as many cores and competitive single-thread performance, for only slightly higher price. Then you'll see Intel suddenly being interested in increasing the number of cores for decent prices. Intel does offer more cores right now, too. They've just launched a 10-core chip this year for consumers, but because they think they have no competition, they sell it for ridiculous amounts like $1,700. https://www.engadget.com/2016/05/31/intel-debuts-its-first-1.. https://www.engadget.com/2016/05/31/intel-debuts-its-first-1.... No sane person should ever pay that much for it. Not when AMD is going to offer 8-10 core chips for less than half that price soon, with similar performance.
- dogma1138 10y ago
  >Not when AMD is going to offer 8-10 core chips for less than half that price soon, with similar performance. This has been touted every year since the initial Athlon 64 came out and knocked intel's teeth out until it came back with the pentium pro based Yona and Nehalem chips and buried netburst. It's still yet to be determined of Zen has anywhere near the SCP IPC that Skylake/Haswell based CPU's do so far there was only one leaked benchmark of a game in which it scored anywhere from pretty low to close to what a Haswell-E CPU brings to the table. The pricing on Zen, especially big Zen which was the only CPU that was close to Intel's Haswell-E lineup is also unlikely to be a <200-250$ card, it's likely to cost just under what the 6800K costs which might not make it very competitive. Also it's yet to be seen what chipset we are getting, atm you shouldn't buy AMD not because the CPU's are utter garbage, but the chipset is utter trash. No PCIE 3.0 support, no USB 3.0/3.1, no NVME, no M.2 no many other things. Intel's chipsets are and always were the golden standard (ever since NVIDIA stopped making Nforce 2:)) and AMD really needs to not only be competitive but to match them or beat them as far as peripherals go. AMD is in a disadvantage out of the bat for no Thunderbolt support but it needs to come strong with low latency PCIE, a lot of PCIE interconnects, 10 gig USB 3.1 and native displayport and many other things. If that will be a standard and the performance are at least in the 90th percentile compared to Intel AMD stands a chance, anything below that people again would not even bother.
imtringued 10y ago
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.
- valarauca1 10y ago
  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. When your talking about spinning up a MASSIVE number compute threads/servers >128 instances. This also takes a non-trivial time. You really aren't seeing the forest though the trees. What I'm saying is it is a trade off. Time gain: 1/2^x Resource spending: 2^x Figure out where the intercept based on cost.
netheril96 10y ago
> 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.
- herge 10y ago
  Are they actually processing in parallel, or just spawning threads to do IO?

BatFastard 10y ago

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.

valarauca1 10y ago
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.
- ccrngd1 10y ago
  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.
  - valarauca1 10y ago
    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.
  - lucian1900 10y ago
    All of those other things are significantly cheaper than graphics.

countryqt30 10y ago

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?

valarauca1 10y ago
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.
pjc50 10y ago
Most people have a single, important foreground app which is the only one they care about latency of. The others are ticking over in the background, but because they don't have window focus the user doesn't care about their responsiveness so much.

difftest 10y ago

3: Amdahl's law says that partially parallelizable applications don't see much improvement. 50% parallelizable program will run 33% faster on 2 cores (not 100%) 60% faster on 4 (not 300%).

melling 10y ago

Silicon is cheap, my time isn't. i'd rather the task finish in under 2 seconds.

mtgx 10y ago

That's an issue yes, but it's not the main reason why Intel isn't offering more cores for decent prices, otherwise we would've never even moved to two cores or four cores. The main reason is Intel doesn't feel like it needs to because AMD doesn't offer much competition with its current architecture, even with twice as many cores. But that will change when Zen chips arrive. http://www.extremetech.com/computing/233453-amd-zen-benchmarks-leak-point-to-potent-performance-against-intel-huge-gains-over-piledriver http://www.extremetech.com/computing/233453-amd-zen-benchmar... So wait until AMD launches Zen-based chips with twice as many cores and competitive single-thread performance, for only slightly higher price. Then you'll see Intel suddenly being interested in increasing the number of cores for decent prices. Intel does offer more cores right now, too. They've just launched a 10-core chip this year for consumers, but because they think they have no competition, they sell it for ridiculous amounts like $1,700. https://www.engadget.com/2016/05/31/intel-debuts-its-first-1.. https://www.engadget.com/2016/05/31/intel-debuts-its-first-1.... No sane person should ever pay that much for it. Not when AMD is going to offer 8-10 core chips for less than half that price soon, with similar performance.

dogma1138 10y ago
>Not when AMD is going to offer 8-10 core chips for less than half that price soon, with similar performance. This has been touted every year since the initial Athlon 64 came out and knocked intel's teeth out until it came back with the pentium pro based Yona and Nehalem chips and buried netburst. It's still yet to be determined of Zen has anywhere near the SCP IPC that Skylake/Haswell based CPU's do so far there was only one leaked benchmark of a game in which it scored anywhere from pretty low to close to what a Haswell-E CPU brings to the table. The pricing on Zen, especially big Zen which was the only CPU that was close to Intel's Haswell-E lineup is also unlikely to be a <200-250$ card, it's likely to cost just under what the 6800K costs which might not make it very competitive. Also it's yet to be seen what chipset we are getting, atm you shouldn't buy AMD not because the CPU's are utter garbage, but the chipset is utter trash. No PCIE 3.0 support, no USB 3.0/3.1, no NVME, no M.2 no many other things. Intel's chipsets are and always were the golden standard (ever since NVIDIA stopped making Nforce 2:)) and AMD really needs to not only be competitive but to match them or beat them as far as peripherals go. AMD is in a disadvantage out of the bat for no Thunderbolt support but it needs to come strong with low latency PCIE, a lot of PCIE interconnects, 10 gig USB 3.1 and native displayport and many other things. If that will be a standard and the performance are at least in the 90th percentile compared to Intel AMD stands a chance, anything below that people again would not even bother.

imtringued 10y ago

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.

valarauca1 10y ago
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. When your talking about spinning up a MASSIVE number compute threads/servers >128 instances. This also takes a non-trivial time. You really aren't seeing the forest though the trees. What I'm saying is it is a trade off. Time gain: 1/2^x Resource spending: 2^x Figure out where the intercept based on cost.

netheril96 10y ago

> 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.

herge 10y ago
Are they actually processing in parallel, or just spawning threads to do IO?