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....
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.
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.
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.
AMD will have something similar even if the CPU will control most of the PCIE lanes in the system (usually GPU + high speed storage is over the CPU, the rest of the IO is over the PCH).
As PCIE3.0 is not supported on AM3+ motherboards because this requires native CPU/Chipset support so you are overloading a potentially already contested PCIE (especially if you are running multiple GPU's) bus which has overall less bandwidth to offer which can yield even worse performance than what is available on X99 chipsets currently which lack some of the same features but at least support PCIE3.0.
So you'll have to check for benchmarks for individual motherboards by make and model, not all reviews cover USB 3.1 or NVME since many of the reviewers don't even understand that those features can behave substantially differently so googling AM3+ USB 3.1 testing or something would be your best option some reviews do include those tests for example: https://nl.hardware.info/reviews/6106/5/msi-990fxa-gaming-am...
Overall considerably lower performance and that's against older intel motherboards that do not have native USB 3.1 support either, mostly because of PCIE 3.0 support and substantially better PCIE latency over both the PCH PCIE bridge and the native CPU PCIE lanes.
Based on the numbers from this benchmark I can tell you that the USB 3.1 10gig performance on newer motherboards is considerably better than that, just by comparing my X99 (which is also tested in the aforementioned benchmark) to my high end Z170 motherboards with the same storage peripherals. Overall I'm getting slightly better speeds on my X99 setup than they had (probably slightly faster storage) but the Z170 offers anywhere between 20 to 30% better performance depending on the benchmark with the same SSD based external storage.
2) I think they are actually very good at what can be done by now. How do you think they are so bad?
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.
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.
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.
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.
50% parallelizable program will run 33% faster on 2 cores (not 100%) 60% faster on 4 (not 300%).
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.
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.
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.
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.
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
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
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.