Hacker News Reader

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

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

Zen is going to have an integrated memory controller/PCIe root complex on dye. So this should help with IO concerns (no north bridge). Ofc this is gen 1 tech so who knows it could be crippled for certain tasks.

Intel does the same, there is still a "north/south bridge" (AMD had on die memory controller since the Athlon 64 days IIRC) which adds "additional" (via a bridge, you aren't getting additional bandwidth unless you are using QPI with multiple CPU's) PCIE lanes and centralizes I/O in Intel's case it's the PCH. https://en.wikipedia.org/wiki/Platform_Controller_Hub

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

There was a launch of some more modern AM3+ boards. Like https://www.asus.com/Motherboards/970-PRO-GAMING-AURA/specif..., those boards support USB 3.1 Gen2, they bring M.2 slots and NVMe (on PCI-E 2.0 of course).

Those aren't supported natively via the chipset, these are implemented using extensions which result in poorer performance and eating quite a bit of the PCIE bandwidth available. The lack of USB 3.1 support is also the problem I have with Haswell-E, I have an X99 motherboard for my Broadwell-E setup and USB 3.1/TB is only available via the ASUS extension card which eats up 4 PCIE lanes and doesn't perform nearly as well as the "native" Skylake Z170 series chipsets.

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.

That's correct of course. But, do you know of some benchmarks showing the real world problems those AM3+ boards can have? I'd really be interested in a proper source.

There aren't any "universal" benchmark since each motherboard will implement those features differently, different chipset, differently bandwidth allocated to it (USB 3.1 supports from 1 to 8 or 16 PCIE lanes IIRC) even things like the length of the traces can affect the performance.

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.

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.

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.

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.

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.

All of those other things are significantly cheaper than graphics.

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

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.

     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.

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

Are they actually processing in parallel, or just spawning threads to do IO?

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