AMD Ryzen Full Lineup Prices, Specs and Clock Speeds Leaked(wccftech.com)
wccftech.com
AMD Ryzen Full Lineup Prices, Specs and Clock Speeds Leaked
http://wccftech.com/amd-ryzen-full-lineup-pricing-clock-speeds-leaked/
112 comments
Given the price and the feature comparison to Intel, Ryzen sounds awesome. Hopefully it will spark new innovation between AMD and Intel. And hopefully AMD will life up to where it was once when they gave name to the AMD64 architecture.
Assuming similarly low pricing, AMD's Naples chip for the servers might spark even more competition. Since it can do up to 32 cores / 64 threads in a single socket, it would compete with dual socket Xeon systems that have much higher motherboard costs, plus the cost of 2 chips.
> feature comparison
Are there interesting features that differentiate them from Intel beyond performance/cost? As in new instructions or things like that?
Are there interesting features that differentiate them from Intel beyond performance/cost? As in new instructions or things like that?
No, and as far as high end instructions then only 128bit AVX is natively supported on Zen, with 256bit AVX possible with half the throughput and no 512bit AVX support at all.
That said because Intel disables AVX2 in half its SKU's at least that will likely not to be a major impact.
As far as other features it's still TBD, virtualization works better on Intel currently, some other platform dependant issues would also probably still favor intel.
Intel makes their storage, networking and USB in house, AMD doesn't, AM3 storage and USB performance were considerably slower than Intel's solution and it's yet to be seen what AM4 will provide.
AM4 will come with USB3.0/3.1 from ASMEDIA and will only support a single NVME drive, so if you are looking for a professional workstation, need high speed storage, ECC, and can utilize quad channel low latency memory then Intel is still likely the way to go even with blue team tax.
If you need multi GPU support and NVME at the same time, as well as other peripherals that use PCIE then you also might need to look at intel still since Zen will only come with 28 PCIE lanes. Hopefully they've sorted their PCIE performance issues at least, AM3 not only had bandwidth limitation due to PCIE 2.0 support but also had a much higher PCIE latency for unexplained reasons.
AM4 will come with USB3.0/3.1 from ASMEDIA and will only support a single NVME drive, so if you are looking for a professional workstation, need high speed storage, ECC, and can utilize quad channel low latency memory then Intel is still likely the way to go even with blue team tax.
If you need multi GPU support and NVME at the same time, as well as other peripherals that use PCIE then you also might need to look at intel still since Zen will only come with 28 PCIE lanes. Hopefully they've sorted their PCIE performance issues at least, AM3 not only had bandwidth limitation due to PCIE 2.0 support but also had a much higher PCIE latency for unexplained reasons.
I think what AMD is really trying to do, or what they should do, is place emphasis on the gaming community and drop any/all enterprise related features, and let Intel keep doing that part.
Kinda, but then they should've released a 4C/8T with very high clock rate CPU at around the 200-250$ mark for that.
Intel's 7700Ks can easily hit the 5ghz mark on aftermarket air and AIO water cooling.
Games aren't optimized well beyond 2 cores, with games that are optimized for more than 4 cores being particularly unheard off.
Games aren't an application that supports parallelism that well since your sound, physics, AI and graphics threads all have to be synced within a single frame otherwise everything falls apart.
The worst case for Zen is going to be the not here and not there CPU, with price slashed 7700K mopping the floor with 8C Zen CPUs in gaming because they can clock to 5ghz and higher while it's unclear if AMD can even hit 4ghz reliably on all cores and on the other hand the Zen ecosystem not being mature enough for the prosumer and professional types due to subpar support/performance of storage, peripherals and memory.
The biggest mistake I made is getting a 2nd 5820K for my gaming rig, I got it cheap so I don't mind but performance wise I would be better off with a 6700/7700K. And I'm lucky as my 5820K hits 4.5-4.6ghz with an AIO cooler.
Intel's 7700Ks can easily hit the 5ghz mark on aftermarket air and AIO water cooling.
Games aren't optimized well beyond 2 cores, with games that are optimized for more than 4 cores being particularly unheard off.
Games aren't an application that supports parallelism that well since your sound, physics, AI and graphics threads all have to be synced within a single frame otherwise everything falls apart.
The worst case for Zen is going to be the not here and not there CPU, with price slashed 7700K mopping the floor with 8C Zen CPUs in gaming because they can clock to 5ghz and higher while it's unclear if AMD can even hit 4ghz reliably on all cores and on the other hand the Zen ecosystem not being mature enough for the prosumer and professional types due to subpar support/performance of storage, peripherals and memory.
The biggest mistake I made is getting a 2nd 5820K for my gaming rig, I got it cheap so I don't mind but performance wise I would be better off with a 6700/7700K. And I'm lucky as my 5820K hits 4.5-4.6ghz with an AIO cooler.
This is increasingly untrue. Modern consoles like the Xbox One and PS4 guarantee availability of six hardware threads with provisional access to a seventh. This combined with things like VR putting a premium on high FPS has motivated more parallel architectures.
Most game engines architectures have supported limited parallelism in the form of dedicated game simulation and render threads, as well as often having asynchronous processing of audio, network, and IO. More modern engines have task based architectures that allow for parallelism of the game simulation. This is often implemented as a fork-join model around sync points spread throughout the simulation update: pre-physics and post-physics update periods for instance. While it is true that some game logic relies on knowledge of global state and complicated dependencies between entities in the simulation, games can and do find meaningful reductions in CPU wall time.
Most game engines architectures have supported limited parallelism in the form of dedicated game simulation and render threads, as well as often having asynchronous processing of audio, network, and IO. More modern engines have task based architectures that allow for parallelism of the game simulation. This is often implemented as a fork-join model around sync points spread throughout the simulation update: pre-physics and post-physics update periods for instance. While it is true that some game logic relies on knowledge of global state and complicated dependencies between entities in the simulation, games can and do find meaningful reductions in CPU wall time.
50% of the PC gaming market is dual core, there are plenty of benchmarks that show it.
I wish this was increasingly untrue.
Running For Honor just now a new title built for consoles one CPU core is at 100% the rest are <10%
;)
I wish this was increasingly untrue.
Running For Honor just now a new title built for consoles one CPU core is at 100% the rest are <10%
;)
Sure, the Steam Hardware Survey indicates as much. Most AAA games, however, sell the vast majority of their units on console platforms that have eight cores. If you are a developer/publisher targeting the top end of the market, you are highly incentivized to take full advantage of the multi-core console architecture. Also, the trend in CPU desktop architecture for the past decade has been more cores versus higher frequencies or large IPC improvements. Might as well architect your technology for parallelism now (consoles) and the future (mainstream PC consumers moving to four, six, and eight core processors). Those technology investments and trends eventually trickle down to smaller developers who aren't developing their own proprietary engines.
Again this isn't about steam hardware survey it's about reality.
Out of the lastest 10 AAA titles only one I would call something that might be worth more than 4 cores and it's WD2.
2 cores on 100%, 2 more on 60-70% and 2 more on 20%. W/ HT it will be 2, 100% and the 10 left "cores" at about 15%.
And this is by far the best "multithreaded" game that came out in the past 8-12 months.
What devs do for consoles doesn't translates to PC, PCs come with a huge variety in hardware and unlike consoles where devs get 6-7 cores out of the 8 exclusively for their game on a PC they have to live with everything else from AV scans to Streaming.
No one is taking advantages of multicore CPUs because no one can do it right on a fragmented platform where you don't control over the runstate of the app, co-hosting and have zero knowledge about it's hardware and configuration.
Out of the lastest 10 AAA titles only one I would call something that might be worth more than 4 cores and it's WD2.
2 cores on 100%, 2 more on 60-70% and 2 more on 20%. W/ HT it will be 2, 100% and the 10 left "cores" at about 15%.
And this is by far the best "multithreaded" game that came out in the past 8-12 months.
What devs do for consoles doesn't translates to PC, PCs come with a huge variety in hardware and unlike consoles where devs get 6-7 cores out of the 8 exclusively for their game on a PC they have to live with everything else from AV scans to Streaming.
No one is taking advantages of multicore CPUs because no one can do it right on a fragmented platform where you don't control over the runstate of the app, co-hosting and have zero knowledge about it's hardware and configuration.
> Games aren't optimized well beyond 2 cores, with games that are optimized for more than 4 cores being particularly unheard off.
How much of that is a chicken-and-egg problem? Gamers buying hardware look for clock speed over core count because that's what today's games benefit from, therefore developers don't optimize for higher core counts because customers don't have them now.
> Games aren't an application that supports parallelism that well since your sound, physics, AI and graphics threads all have to be synced within a single frame otherwise everything falls apart.
I've often heard that repeated, but I'm not sure I totally understand why. I admittedly haven't looked at anything resembling a modern game codebase -- my last time in that space was eons ago in programmer years -- but my instincts would say that doesn't necessarily have to be true, or at least not for that reason.
Graphics and sound kinda make sense, in that you're trying to push out pixels/samples at a fast & regular rate and they need to be perfectly aligned. Though does anything not primarily rely on GPU (which is itself massively parallel) for most graphics work nowadays? Given that, I'd assume the CPU's part of graphics is mostly a support role moving stuff on and off the GPU.
For aspects like AI and physics, I'm not convinced they do have to be locked to frame rate like you say. Why can't they run independently and continuously and let the game take advantage of the "most recent" state of the world as often as needed to match the frame rate? There may be design/architectural reasons this isn't done, but I don't see any fundamental reasons that it couldn't.
Maybe there are factors I'm just missing or not aware of, I'd love to see a good solid analysis of why this is true, if it is.
How much of that is a chicken-and-egg problem? Gamers buying hardware look for clock speed over core count because that's what today's games benefit from, therefore developers don't optimize for higher core counts because customers don't have them now.
> Games aren't an application that supports parallelism that well since your sound, physics, AI and graphics threads all have to be synced within a single frame otherwise everything falls apart.
I've often heard that repeated, but I'm not sure I totally understand why. I admittedly haven't looked at anything resembling a modern game codebase -- my last time in that space was eons ago in programmer years -- but my instincts would say that doesn't necessarily have to be true, or at least not for that reason.
Graphics and sound kinda make sense, in that you're trying to push out pixels/samples at a fast & regular rate and they need to be perfectly aligned. Though does anything not primarily rely on GPU (which is itself massively parallel) for most graphics work nowadays? Given that, I'd assume the CPU's part of graphics is mostly a support role moving stuff on and off the GPU.
For aspects like AI and physics, I'm not convinced they do have to be locked to frame rate like you say. Why can't they run independently and continuously and let the game take advantage of the "most recent" state of the world as often as needed to match the frame rate? There may be design/architectural reasons this isn't done, but I don't see any fundamental reasons that it couldn't.
Maybe there are factors I'm just missing or not aware of, I'd love to see a good solid analysis of why this is true, if it is.
Dual Core CPUs are still 50% or so of the current gaming PC audience based on steam hardware surveys, chicken and egg or not but until 4+ core CPUs make the bulk of the market game developers will optimize their games for 2-4 cores.
>For aspects like AI and physics, I'm not convinced they do have to be locked to frame rate like you say. Why can't they run independently and continuously and let the game take advantage of the "most recent" state of the world as often as needed to match the frame rate? There may be design/architectural reasons this isn't done, but I don't see any fundamental reasons that it couldn't.
AI and Physics define what is going to be displayed on a screen if say you doing cloth physics this will change the animations of a flag weaving in the wind, if there are thread locks the animation will be breaking up and be choppy. It's even worse if the physics have actual game implication does a barrel hit a player or not if a frame is skipped? And then we get into the realm of multiplayer where you don't just need to sync things within a single computer but between multiple computers all over the world.
Everything has to be synced to make the game work, can it be split across 10 cores probably, but since most gamers don't have 10 cores you better work with 2-4 cores and make sure it works well.
>For aspects like AI and physics, I'm not convinced they do have to be locked to frame rate like you say. Why can't they run independently and continuously and let the game take advantage of the "most recent" state of the world as often as needed to match the frame rate? There may be design/architectural reasons this isn't done, but I don't see any fundamental reasons that it couldn't.
AI and Physics define what is going to be displayed on a screen if say you doing cloth physics this will change the animations of a flag weaving in the wind, if there are thread locks the animation will be breaking up and be choppy. It's even worse if the physics have actual game implication does a barrel hit a player or not if a frame is skipped? And then we get into the realm of multiplayer where you don't just need to sync things within a single computer but between multiple computers all over the world.
Everything has to be synced to make the game work, can it be split across 10 cores probably, but since most gamers don't have 10 cores you better work with 2-4 cores and make sure it works well.
If you've already optimized your game for 2-4 cores, is it that much harder to make it run well on more than 4 cores?
Yes.
People down vote this, so I will provide a bit more explanation: Parallelism is 'easy' as long as you have natural separated problems. This is the reason embarrassingly problems are so great for many-core systems. Every single sub-problem can be done without having to synchronize with other parts of the system. Unfortunately, most problems aren't that way, but instead are interlocked on multiple axes:
- Minimal granularity: You can never run more cores than you have problems at the same time, but you also cannot just split problems as long as you want or the overhead of splitting will kill all performance gains you'd had (x+y in an extra thread/process is technically possible, in reality pretty stupid)
- Synchronization points: Most problems are not completely separate from each other, so you can do part of the problem in parallel but at some point you have to converge and do something with the combined result.
- Comparable task size: In an ideal world all of your tasks would take exactly as long as the other, because if one task takes far longer than the others you have to wait for it. So, the minimal run time of your parallel problem is bound by the time of your longest sub-problem. If one of the problems takes far longer than the others (and they depend on each other) you've lost.
The last one is more of a "meta" point: Complexity doesn't scale linear for dependent problems. That's another reason embarrassingly parallel problems are so nice. You cannot only run them all in parallel, you can think about each one as a completely separate problem. The moment you have dependencies you have to think about how to bring them all together and that gets hard very fast if you have many moving parts.
So, to sum it up: Many small things conspire against just scaling something which works great for two or four cores up to eight, 16, 32 or whatever. If you happen to have an embarrassingly parallel problem you're golden, but unfortunately only a small subset of interesting problems are that way and for other problems scaling is hard.
- Minimal granularity: You can never run more cores than you have problems at the same time, but you also cannot just split problems as long as you want or the overhead of splitting will kill all performance gains you'd had (x+y in an extra thread/process is technically possible, in reality pretty stupid)
- Synchronization points: Most problems are not completely separate from each other, so you can do part of the problem in parallel but at some point you have to converge and do something with the combined result.
- Comparable task size: In an ideal world all of your tasks would take exactly as long as the other, because if one task takes far longer than the others you have to wait for it. So, the minimal run time of your parallel problem is bound by the time of your longest sub-problem. If one of the problems takes far longer than the others (and they depend on each other) you've lost.
The last one is more of a "meta" point: Complexity doesn't scale linear for dependent problems. That's another reason embarrassingly parallel problems are so nice. You cannot only run them all in parallel, you can think about each one as a completely separate problem. The moment you have dependencies you have to think about how to bring them all together and that gets hard very fast if you have many moving parts.
So, to sum it up: Many small things conspire against just scaling something which works great for two or four cores up to eight, 16, 32 or whatever. If you happen to have an embarrassingly parallel problem you're golden, but unfortunately only a small subset of interesting problems are that way and for other problems scaling is hard.
"In an ideal world all of your tasks would take exactly as long as the other, because if one task takes far longer than the others you have to wait for it. So, the minimal run time of your parallel problem is bound by the time of your longest sub-problem. If one of the problems takes far longer than the others (and they depend on each other) you've lost."
Could the cores that would otherwise be waiting for the longest sub-problem to complete start working on some new sub-problems to make the following set of sub-problems finish sooner?
Could the cores that would otherwise be waiting for the longest sub-problem to complete start working on some new sub-problems to make the following set of sub-problems finish sooner?
If you have a set left that doesn't depend on the result of the problem still in computation you can do this, yes. Though in that case you don't actually have two sets, you have one set which is bigger than your core count. I simplified a bit before, but if you have more problems than cores your longest sub-problem shouldn't run longer than the time it takes you to compute all other sub-problems (i.e. that includes computing five sub-problems on one core while another core computes one longer problem) or you'll have to wait.
Unfortunately, I had this happen to a program of mine last year. All other tasks were long done but one kept running and running. The run time of the program escalated to hours with the first few minutes being marked by high usage of the system and then only one core in use, while everything else had to wait. It sucked.
Unfortunately, I had this happen to a program of mine last year. All other tasks were long done but one kept running and running. The run time of the program escalated to hours with the first few minutes being marked by high usage of the system and then only one core in use, while everything else had to wait. It sucked.
Thanks for expanding on this. My answer of 'Yes.' deserved the downvotes.
Anecdatum, but the game I worked on (Tom Clancys The Division) will perform much better on a quad core than a dual core. We're CPU bound long before GPU bound.
Yeah the Division, AC, FC (all ubisoft games ;) and a few other games are pretty CPU demanding and will eat as much as you can give them but even those usually fizzle after 4 cores or so.
I find it hard to find a game that will use all 6c/12t on my 5820K, most of them will use 2-4 with usually 1-2 being pushed fully and 2 more between 10-25%.
I find it hard to find a game that will use all 6c/12t on my 5820K, most of them will use 2-4 with usually 1-2 being pushed fully and 2 more between 10-25%.
Doesnt really matter when even a $65 G4560 hits reliable 80fps in division
Not really a a fair point. The G4560 is extraordinary value for the money. It is a dual core, but it has hyperthreading. And as much as I was surprised by this when the i3s showed it, hyperthreading helps a lot in situations where 4, well, I'd like to say cores, are expected. The G4560 is eating the whole budget processor market right now – but that does not mean that his example doesn't show something: There are a number of games by now that rely on having a processor that can power multiple threads. And those games profit a lot from having more cores – you can play with the Pentium, and it absolutely is the best pick for a budget build, but you still get budget performance. And that means there are some games that won't run very well with it, and some min-FPS will be lower than one would want.
The pendulum has swung so far far that (some) recent games began to run good on the old FX chips, see Watchdog 2. If not looking at budget chips, having multiple cores is attractive for gamers by now. Maybe the potential of hexa-cores is not used that much yet, but it is obvious that will come, and games like Battlefield 1 do use them already. I think those Ryzen hexa-cores have a very good chance at the market, if their single thread performance is high enough.
The pendulum has swung so far far that (some) recent games began to run good on the old FX chips, see Watchdog 2. If not looking at budget chips, having multiple cores is attractive for gamers by now. Maybe the potential of hexa-cores is not used that much yet, but it is obvious that will come, and games like Battlefield 1 do use them already. I think those Ryzen hexa-cores have a very good chance at the market, if their single thread performance is high enough.
I feel that AMD forced that change in accidentally clever way by embedding itself in current generation of consoles. 8 anemic 1.6 GHz cores forced whole gaming industry to start taking multi threading seriously.
[deleted]
Dunno, I'm sure AMD is drooling at the markup Intel gets for their Xeon chips. Of course, enterprise is much harder to break into than consumer.
Given that AMD is part of the OpenCAPI consortium, they could potentially make monster HPC machines with Infiniband and GPU's connected with cache coherent OpenCAPI instead of PCIE.. But we'll see, I guess..
Given that AMD is part of the OpenCAPI consortium, they could potentially make monster HPC machines with Infiniband and GPU's connected with cache coherent OpenCAPI instead of PCIE.. But we'll see, I guess..
> and will only support a single NVME drive,
What does this mean? That it will only support booting from a NVMe device if it is plugged in to one particular PCIe port?
What does this mean? That it will only support booting from a NVMe device if it is plugged in to one particular PCIe port?
Summit Ridge only supports 1 M.2 NVME drive, Z270 supports 3 w/ RAID.
You can add additional NVME drives through the expansion slots but these are not natively supported by the platform.
You can add additional NVME drives through the expansion slots but these are not natively supported by the platform.
> You can add additional NVME drives through the expansion slots but these are not natively supported by the platform.
It's still completely unclear what the hell you mean by that. I've yet to encounter a platform that cares which PCIe lanes a NVMe SSD uses when it comes to boot support. Nobody really cares about whether the software RAID supports NVMe, and I'd count it as a benefit of AMD's platform if they don't implement Intel's obscene hacks that make their NVMe software RAID work. Do you mean that the chipsets for Ryzen will only have enough PCIe lanes or ports to provide one PCIe x4 slot?
It's still completely unclear what the hell you mean by that. I've yet to encounter a platform that cares which PCIe lanes a NVMe SSD uses when it comes to boot support. Nobody really cares about whether the software RAID supports NVMe, and I'd count it as a benefit of AMD's platform if they don't implement Intel's obscene hacks that make their NVMe software RAID work. Do you mean that the chipsets for Ryzen will only have enough PCIe lanes or ports to provide one PCIe x4 slot?
Ryzen supports upto 28 PCIE lanes.
Depending on the chipset you get 1 NVME slot which is either X2 or X4 depending on the SKU that comes from the chipset those are the lanes dedicated for NVME.
This is what the motherboards will come with if they do not want to add additional controllers and PCIE bridges.
If you want to use the PCIE lanes that are dedicated for expansion slots for NVME by buying NVME PCIE cards or using PCIE class storage you can.
Booting from those will be dependant on the UEFI and on the specific solution you buy.
Z270 comes with upto 3 NVME x4 slots (over a built in bridge in the PCH) which support IRST and the rest of the intel crap, meaning for a motherboard manufacturer to support upto 3 of them they don't need need to add anything but the physical connectors.
Z270 comes with upto 3 NVME x4 slots (over a built in bridge in the PCH) which support IRST and the rest of the intel crap, meaning for a motherboard manufacturer to support upto 3 of them they don't need need to add anything but the physical connectors.
Which Intel processors have AVX2 disabled?
Core based Pentium/Celeron and some of the ULV CPUs have had AVX disabled since Ivy Bridge.
A little overstated to say that's half their SKUs, but I see your point.
There is even more nuanced though, because Intel runs avx instructions at a different clockspeed than the main chip. So certain SKUs have avx support but have differences that don't reflect the CPU clock difference.
There is even more nuance to this as AVX low level instruction support isn't going to be universal as different CPUs will support different instruction subsets of AVX-512 and Extended AVX
https://en.wikipedia.org/wiki/AVX-512
There is also a mess in FMA support for both Intel and AMD cpus... https://en.wikipedia.org/wiki/FMA_instruction_set
This entire deal pretty much turned AVX into cancer outside of very specific circles, especially considering the wierd support for AVX and SSE in OpenCL.
There is also a mess in FMA support for both Intel and AMD cpus... https://en.wikipedia.org/wiki/FMA_instruction_set
This entire deal pretty much turned AVX into cancer outside of very specific circles, especially considering the wierd support for AVX and SSE in OpenCL.
Zen should feature instructions for full memory encryption using a ARM co-prosessor. I find that pretty interesting, considering the limitations of Intel SGX.
They are still somewhat in the domain of performance.
* ML is used for branch prediction,[1] as well as [implied] pre-fetch.
* Automatic clock and power tuning.[2] This is not per-die, but granular across the chip.
* eXtended Frequency Range,[3] unlocks the ranges that [2] is allowed to use. Essentially, the chip overclocks itself when you provide it with more cooling headroom.
[1]: https://youtu.be/X9NNOqzTbKI?t=13m53s [2]: https://youtu.be/X9NNOqzTbKI?t=14m38s [3]: https://youtu.be/X9NNOqzTbKI?t=15m22s
* ML is used for branch prediction,[1] as well as [implied] pre-fetch.
* Automatic clock and power tuning.[2] This is not per-die, but granular across the chip.
* eXtended Frequency Range,[3] unlocks the ranges that [2] is allowed to use. Essentially, the chip overclocks itself when you provide it with more cooling headroom.
[1]: https://youtu.be/X9NNOqzTbKI?t=13m53s [2]: https://youtu.be/X9NNOqzTbKI?t=14m38s [3]: https://youtu.be/X9NNOqzTbKI?t=15m22s
This would be great news indeed if AMD finally had a competitive high-end chip again. It feels like Intel has just been coasting on their success for a long time, since there was no competitive pressure from the outside they also had little incentive to add more cores/lower prices/take some engineering risks.
The CPU market could become a lot more interesting again after all this time.
The CPU market could become a lot more interesting again after all this time.
AMD Ryzen 7 1700, 8 cores, 16 threads, 65W TDP, 3.0-3.7GHz, $319.
Comparing to my current Haswell CPU, that's quite a great value for the money:
(84W TDP, 4 cores, 8 threads, $300+ price soon after launch, 3.4-3.9GHz).
I'd prefer somewhat higher frequency though, more in line with thier X series, but without major increase in TDP. But I guess +10W is tolerable for a good processing power increase.
Comparing to my current Haswell CPU, that's quite a great value for the money:
(84W TDP, 4 cores, 8 threads, $300+ price soon after launch, 3.4-3.9GHz).
I'd prefer somewhat higher frequency though, more in line with thier X series, but without major increase in TDP. But I guess +10W is tolerable for a good processing power increase.
I'd be hesitant to judge those AMD processors on the specified clock, even more than usual.
The usual argument is that clocks are not comparable, because you don't know that a 4GHz cpu A is not slower than a 1GHz cpu B in doing a specific task. That I assume is known around here, but is not what I mean. AMD is marketing the feature of those processors to overclock automatically above the specified turbo clock. Meaning 3.9GHz should be a lower bound, and it is completely possible those cpus will routinely clock much higher in practice. See http://www.kitguru.net/components/cpu/jon-martindale/amds-ex... (and it is also as XFR in the original article here).
Or maybe they won't overclock well at all. Well, we'll see after they were released.
Edit: I just realized that with regards to the specific comparison I answered to my point is moot, because according to the table in the article, the Ryzen 7 1700 does not have that feature. The Ryzen 7 1700X does. That might make picking the right processors more difficult than usual. I'll let the comment stand regardless, that feature and distinction might not be well known yet.
The usual argument is that clocks are not comparable, because you don't know that a 4GHz cpu A is not slower than a 1GHz cpu B in doing a specific task. That I assume is known around here, but is not what I mean. AMD is marketing the feature of those processors to overclock automatically above the specified turbo clock. Meaning 3.9GHz should be a lower bound, and it is completely possible those cpus will routinely clock much higher in practice. See http://www.kitguru.net/components/cpu/jon-martindale/amds-ex... (and it is also as XFR in the original article here).
Or maybe they won't overclock well at all. Well, we'll see after they were released.
Edit: I just realized that with regards to the specific comparison I answered to my point is moot, because according to the table in the article, the Ryzen 7 1700 does not have that feature. The Ryzen 7 1700X does. That might make picking the right processors more difficult than usual. I'll let the comment stand regardless, that feature and distinction might not be well known yet.
If you do any substantial overclock, meaning you are going to do a little bit of over voltage, the presence or lack of XFR matters little, and you are definitely going to go above turbo core freqs. XFR is going to be a nice-to-have unconditionally because of it being on the fly adjustments, but it does not seem to be a feature that it is going to make you buy an X version over non-X. It seems to me it will come down to the classic spend less risk more, spend more risk less in terms of overclock, just like it was for vishera 8320/8350/9370/9590 , so I don't expect many features differences between the versions.
4 cores / 16 threads?
Does clock speed matter if IPC for your workload is good at a lower frequency?
Does clock speed matter if IPC for your workload is good at a lower frequency?
I guess it matters for single core performance bottlenecks. I.e. let's say you are compiling. Higher frequency CPU will manage it in less time. More cores naturally help as well.
Most compilers should be able to handle multi-threaded compiling. I would rather go for more cores than higher frequencies
Sure, but higher frequency would speed it up on each core, right? The benefits aren't mutually exclusive.
Well, this sounds good and I'm happy I am holding out for my new machine until it comes out.
We'll have to see real world benchmarks by independent 3rd parties to validate the performance/$ but it continues to look quite impressive as long as you are staying in the sub $500 range.
We'll have to see real world benchmarks by independent 3rd parties to validate the performance/$ but it continues to look quite impressive as long as you are staying in the sub $500 range.
The next step up from those CPUs really is going to be dual xeon boxes, which is a huge jump.
Intel tried to do enough market segmentation that the curve from a Pentium all the way up to dual CPU workstations was fairly continuous in price, with zen it's not the case anymore.
Intel tried to do enough market segmentation that the curve from a Pentium all the way up to dual CPU workstations was fairly continuous in price, with zen it's not the case anymore.
Do they support ECC memory?
I have been trying to find out, for a while now. I have not been able to obtain any information on this. If they don't have ECC, Ryzen will not be an option for me. The extra cost is marginal compared to finding out you have bad RAM (by crashing and corruption).
There are huge server Zen CPUs expected a few months later. That should at least have ECC if these don't.
Hopefully not, biggest scam out there.
The biggest scam is actually the other way around. Intel pulled ECC support from desktop processors a few years ago to force datacentres to buy their Xeons instead.
It's nearly impossible to find a desktop CPU that supports ECC ram now even though 5 years ago it was commonplace.
Trying to run a NAS with some sensitive data is now impossible unless you buy their server chips
It's nearly impossible to find a desktop CPU that supports ECC ram now even though 5 years ago it was commonplace.
Trying to run a NAS with some sensitive data is now impossible unless you buy their server chips
> It's nearly impossible to find a desktop CPU that supports ECC ram now
That's not correct. All 6th Gen Core i3 have ECC support, and the 7th Gen Core i3 that have 'E' in the product name support ECC:
http://ark.intel.com/products/97130/Intel-Core-i3-7101E-Proc...
That's not correct. All 6th Gen Core i3 have ECC support, and the 7th Gen Core i3 that have 'E' in the product name support ECC:
http://ark.intel.com/products/97130/Intel-Core-i3-7101E-Proc...
To be fair i3 being the lower end offering with just 2 cores isn't really competing against any of the server products Intel offers.
Quad (and more) core i5 and i7 that do have near-equivalent Xeon parts do have ECC disabled.
Quad (and more) core i5 and i7 that do have near-equivalent Xeon parts do have ECC disabled.
Sorry, maybe not a NAS but my point stands. Almost any chip that has a server equivalent either has ECC disabled in the chip or the motherboard chipset. This was never the case until some years ago, and the only example I've ever found of Intel removing a feature from their desktop chips exclusively. I don't see any other reason for this except to force people to buy Xeons for their servers
If you going the workstation route then 2011 Xeon CPU's do support ECC and are cheaper than Desktop HEDT parts.
Getting an Intel Xeon E3 for socket 1151 isn't particularly hard or expensive either.
Getting an Intel Xeon E3 for socket 1151 isn't particularly hard or expensive either.
Yeah have fun buying the motherboard that supports it. The whole thing reeks of bullshit
I personally tested a number of low end haswell pentiums and i3s and they support ECC. I have a 4310T paired with a C222 server board for my ZFS NAS.
Xeon E3's with ECC are rather similar, and even sometimes cheaper than the i5/i7 equiv. They are the same die after all.
Why do you consider ECC the biggest scam out there?
Btw, is there any updated paper/source with some stats on bit-flip odds in modern computers?
Last I've read was this one [1] but it's been debated to death. [2] [3]
[1] http://lambda-diode.com/opinion/ecc-memory
[2] https://news.ycombinator.com/item?id=1109401
[3] https://www.reddit.com/r/programming/comments/ayleb/got_4gb_...
Btw, is there any updated paper/source with some stats on bit-flip odds in modern computers?
Last I've read was this one [1] but it's been debated to death. [2] [3]
[1] http://lambda-diode.com/opinion/ecc-memory
[2] https://news.ycombinator.com/item?id=1109401
[3] https://www.reddit.com/r/programming/comments/ayleb/got_4gb_...
Speaking as a hardware engineer, no one should ever buy non ECC-RAM.
Smartphones and laptops should also come with ECC-RAM.
It is that important for reliability.
Smartphones and laptops should also come with ECC-RAM.
It is that important for reliability.
If it is that important to reliability why isn't all software failing around us?
It's important but it's not that important outside of specific applications/use cases.
It's important but it's not that important outside of specific applications/use cases.
Speaking with data regarding failure rates and its actual impact would be even more appreciated.
Yah that's not going to happen. Lot of that is Fab trade secret.
You'll have to use your best guess or intuition on this.
You'll have to use your best guess or intuition on this.
My personal experience tells me that a bit flip is very unlikely to cause a system to fail before a bug or normal termination turns it down. My intuition tells me this is due to shorter and shorter individual program life span due to expansion of client/server architecture, higher frequency of bugs due to expansion of untyped/unstructured data, and the fact that most data manipulated by a program is not initialized/used anyway. Only in very big clusters have I ever heard of memory failure being noticable, but even there I've never seen memory corruption cited in a post mortem. Having to deal with bugs and other hardware defects forces one to work around lack of data integrity anyway.
Really? I won't use a computer without it for production work. You get one bit-flip/GB/year. With 128GB or more in most of our desktops, it's not worth the risk.
Lived under a rock for the last year? Rowhammer is a thing now.
ECC won't save you from Rowhammer. See the ECC RAM section of http://www.thirdio.com/rowhammer.pdf
On some systems, ECC is flat out broken or silently ignored. On many others ECC errors aren't reported to the OS in granular enough batches to do anything about them.
Edit: relevant portions:
> Before we begin to discuss our results, we must first discuss ECC protected systems and the fact that there are no standards on what constitutes ECC protection or ECC event reporting. At its base level, ECC protection simply means that a server can handle or correct single bit errors, although some systems advertise the ability to correct multiple bit errors. Generally, it is our belief that ECC events should be reported to the operating system so that savvy users can gauge the health of their infrastructure.
> Unfortunately, server vendors routinely use a technique called ECC threshold or the 'leaky bucket' algorithm where they count ECC errors for a period of time and report them only if they reach certain levels of failure. From what we understand, this threshold is commonly above 100 per hour, but this remains a trade secret and varies based on the server vendor. So, to see ECC errors (MCE in Linux or WHEA in Windows), there generally needs to be 100 bit flips per hour or greater. This makes “seeing” Rowhammer on server error logs more difficult.
> In addition, we have observed some server vendors will NEVER report ECC events back to the OS, although they might get logged into IPMI. Typically, users expect to see correctable ECC errors logged directly to the OS or that halt the system when they cannot be corrected. During our investigation into this phenomenon, we even encountered one server that neither reported ECC events to the OS nor halted when bit flips were not correctable. The end result was data corruption at the application level. This is something, in our opinion, that should never happen on an ECC protected server system.
> ...
> Using these advanced techniques, we were able to observe ECC events within the first 3 minutes of test time. Generally, this system would lockup or reboot within 30 minutes. Once again, this was on a Rowhammer mitigated system using both ECC and double refresh. So it follows that dual mitigations, on some systems, appear to be flawed and can be exploited as a denial of service.
On some systems, ECC is flat out broken or silently ignored. On many others ECC errors aren't reported to the OS in granular enough batches to do anything about them.
Edit: relevant portions:
> Before we begin to discuss our results, we must first discuss ECC protected systems and the fact that there are no standards on what constitutes ECC protection or ECC event reporting. At its base level, ECC protection simply means that a server can handle or correct single bit errors, although some systems advertise the ability to correct multiple bit errors. Generally, it is our belief that ECC events should be reported to the operating system so that savvy users can gauge the health of their infrastructure.
> Unfortunately, server vendors routinely use a technique called ECC threshold or the 'leaky bucket' algorithm where they count ECC errors for a period of time and report them only if they reach certain levels of failure. From what we understand, this threshold is commonly above 100 per hour, but this remains a trade secret and varies based on the server vendor. So, to see ECC errors (MCE in Linux or WHEA in Windows), there generally needs to be 100 bit flips per hour or greater. This makes “seeing” Rowhammer on server error logs more difficult.
> In addition, we have observed some server vendors will NEVER report ECC events back to the OS, although they might get logged into IPMI. Typically, users expect to see correctable ECC errors logged directly to the OS or that halt the system when they cannot be corrected. During our investigation into this phenomenon, we even encountered one server that neither reported ECC events to the OS nor halted when bit flips were not correctable. The end result was data corruption at the application level. This is something, in our opinion, that should never happen on an ECC protected server system.
> ...
> Using these advanced techniques, we were able to observe ECC events within the first 3 minutes of test time. Generally, this system would lockup or reboot within 30 minutes. Once again, this was on a Rowhammer mitigated system using both ECC and double refresh. So it follows that dual mitigations, on some systems, appear to be flawed and can be exploited as a denial of service.
Correct me if I am wrong, it won't save you, but it should detect iirc (al least most) and then you can take any required action.
On the fact that it's broken on some systems. Isn't this like complaining about air bags that have been disabled ? It however very good you report that they are broken on some systems.
On the fact that it's broken on some systems. Isn't this like complaining about air bags that have been disabled ? It however very good you report that they are broken on some systems.
It can fix single bit flips within the same ECC domain but not 2 or more bit flips.
It's also doesn't help much in the detection realm, there are some ways of using performance counters to try to identify rowhammer but it only works on the most obvious attempts.
ECC doesn't completely mitigate against rowhammer style attacks, it makes it more difficult in some cases and prevents single bit flipping attacks but multiple bit flipping attacks against a single ECC domain are still possible.
That said if you want hardware level attacks then attacks against the cachelines of the CPU are considerably more dangerous and reliable and there is very little one can do to mitigate against those.
That said if you want hardware level attacks then attacks against the cachelines of the CPU are considerably more dangerous and reliable and there is very little one can do to mitigate against those.
Thank you for taking the time to not answer the question but raising another question instead. I have serious doubts that ECC indeed is the biggest scam out there.
How does ECC compare to the fiat money ponzi scheme?
How does ECC compare to the fiat money ponzi scheme?
Does anybody know if the Ryzen CPUs support the equivalent of VT-x and VT-d?
IOMMU and AMD-V have been around for ages, I would expect so.
https://en.m.wikipedia.org/wiki/X86_virtualization#AMD_virtu...
I don't know how well its supported by software though.
I don't know how well its supported by software though.
KVM & Xen have good support for both in my experience, seems to work well. No clue about support in janky proprietary solutions, but seeing as Amazon, DO, etc all use either KVM or Xen, with the extreme budget providers on OpenVZ (where you get a glorified chroot), your probably gonna be using one of those two.
Yes, and they don't (generally) feature lock like Intel does, but we will have to see
I certainly hope that the performance/price is on par with the competition Intel used to get from AMD back in the Duron and Athlon XP days. Ryzen seems to be fairly low power consumption as well which should help with lowering the cooling requirements compared to Intel's CPUs.
I'd really like eight cores, didn't know that was going to be possible soon!
Depending on how much you want it, Intel has an E7 that has 24 cores and 48 threads. It can go up to 8 sockets with up to 12 TB of RAM.
I don't even want to know how much such a monster would cost.
I don't even want to know how much such a monster would cost.
Much less than you'd think if you are willing to go with 6TB only. The 128GB modules are awfully expensive but the other day I saw 64GB modules at $600 https://memory.net/product/s26361-f3843-e618-fujitsu-1x-64gb... here. So that's ~39K for 6TB of RAM. The relevant Supermicro server (4048B-TR4FT) with four E7 CPUs is ~14K http://www.thinkmate.com/system/superserver-4048b-tr4ft comes with 32 4GB modules which is a waste but oh well, it's a very small loss compared what it would cost to buy 6TB at a server seller like this. So you are looking ~53K for the server, CPU, 6TB RAM, you will need a little storage as well, so perhaps ~60K for a 6TB 4U server. In closing, let me remind you that a mere two decades ago, Microsoft launched the Terraserver which was a demonstration of a server with a terabyte of storage and it was very big news. Now we are here with a machine at the price of an ordinary F-150 truck or so which can hold the 5TB uncompressed data of the Terraserver in RAM.
Possible on consumer chips, or possible? Because Intel and AMD have both shipped 6+ core parts for some time now, just usually not targeting the consumer segment...
IIRC when asked, Intel folks say they haven't make a consumer 6+ core part because there's little benefit/demand, but I can't find a citation for that. [1] is a nice discussion about why we haven't gotten more than 4 cores in consumer parts yet, though.
[1] - https://news.ycombinator.com/item?id=12304046
IIRC when asked, Intel folks say they haven't make a consumer 6+ core part because there's little benefit/demand, but I can't find a citation for that. [1] is a nice discussion about why we haven't gotten more than 4 cores in consumer parts yet, though.
[1] - https://news.ycombinator.com/item?id=12304046
How long is it likely to take for Linux to support these new chips?
I need to build a new system and am trying to gauge how long I should wait after Zen comes on the market.
I need to build a new system and am trying to gauge how long I should wait after Zen comes on the market.
There's nothing specifically required by a kernel to support new processors, except maybe power saving features, arguably unimportant for desktop. If you mean compiler optimizations, those are usually sent upstream way early..
A cursory Google search shows AMD first sending Zen (now Ryzen) patches to GCC as early as 2015. So, presumably it has been in a few recent compiler releases already.
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02311.html
A cursory Google search shows AMD first sending Zen (now Ryzen) patches to GCC as early as 2015. So, presumably it has been in a few recent compiler releases already.
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02311.html
"There's nothing specifically required by a kernel to support new processors..."
Does that go for motherboards that can support these new chips too?
Does that go for motherboards that can support these new chips too?
Not specifically, if there's a new chipset or southbridge it may require kernel driver update (..perhaps as simple as new PCI IDs) or a new driver entirely, but similarly those changes are upstreamed rather quickly to increase the change of landing in a stable release.
AMD and Intel engineers have hardware quite early to work on this, long before the consumer product ships.
AMD and Intel engineers have hardware quite early to work on this, long before the consumer product ships.
Official retail prices in China and real retail prices in China are not always the same. "White"-imported i7 6900K the companies will buy is ¥8199, but most people will buy from the marketplaces, where the price is about ¥7000-7400, i.e. the same as in the US.
Then again, for cheap servers, we can get E5-2683v3 here for ¥1900 ($270), 35M cache, 14 cores.
Then again, for cheap servers, we can get E5-2683v3 here for ¥1900 ($270), 35M cache, 14 cores.
I wonder how well they will support some more advanced virtualisation. I.E. Booting a virtual machine with PCI GPU passtrough in Windows Guest with Linux host for gaming, or booting a virtual machine with PCI GPU passtrough in Linux Guest with Linux host for some deep learning with CUDA.
This should work already, hypothetically: https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardw...
But, given how flaky this can be with Intel configurations, I'd expect the AMD ones to be even flakier. Ryzen's possible popularity may improve the situation.
But, given how flaky this can be with Intel configurations, I'd expect the AMD ones to be even flakier. Ryzen's possible popularity may improve the situation.
Yes, that's my idea as well. In Intel it was already a bit of an hassle, I'm afraid that at least for quite a few months it will be an even bigger hassle on AMD.
Then again, I think this is just a very particular use case. I unfortunately have it, but for most people it shouldn't matter.
Then again, I think this is just a very particular use case. I unfortunately have it, but for most people it shouldn't matter.
That's something I'm also interested in for my next desktop computer. I've been holding off until Zen comes out to see how they compare with Intel's but I really feel like having this exact setup.
Guess, we'll have to wait until they come out to see how they behave.
Guess, we'll have to wait until they come out to see how they behave.
Why would you want to do Linux Guest with Linux host for CUDA?
Because it's (well, at least 6 months ago was, now it could have improved) the only solution to reuse the GPU without rebooting X.
With a practical example:
1 - You boot up your Linux base system.
2 - You fire up KVM with GPU PCI passthrough with a Windows guest to play some games.
3 - You shutdown windows.
Now you can't use the GPU anymore, the module was assigned by KVM and you can't - for instance - run a CUDA simulation in the Linux host. You need to reboot X (you don't need to reboot the system).
The workaround/solution is to fire up KVM with GPU PCI passthrough to another guest (This time a Linux guest) and in there you will have full access to the GPU to do CUDA computations (or whatever else you want).
With a practical example:
1 - You boot up your Linux base system.
2 - You fire up KVM with GPU PCI passthrough with a Windows guest to play some games.
3 - You shutdown windows.
Now you can't use the GPU anymore, the module was assigned by KVM and you can't - for instance - run a CUDA simulation in the Linux host. You need to reboot X (you don't need to reboot the system).
The workaround/solution is to fire up KVM with GPU PCI passthrough to another guest (This time a Linux guest) and in there you will have full access to the GPU to do CUDA computations (or whatever else you want).
>Now you can't use the GPU anymore, the module was assigned by KVM and you can't - for instance - run a CUDA simulation in the Linux host.
Maybe we had different setups, so this wouldn’t apply – I used to unbind the device with the following script, and then load the `nvidia` module; the device was then available on the host:
Maybe we had different setups, so this wouldn’t apply – I used to unbind the device with the following script, and then load the `nvidia` module; the device was then available on the host:
for dev in "0000:01:00.0" "0000:01:00.1"; do
if [ -e /sys/bus/pci/devices/${dev}/driver ]; then
echo "${dev}" > /sys/bus/pci/devices/${dev}/driver/unbind
fi
doneAh I see, that makes more sense. If you had two NVIDIA GPUs while one of them was passed through to a guest then I think that problem may still exist.
However if you only have one nvidia gpu (and have a different kind of gpu for display), then I think simply running "sudo rmmod vfio" "sudo modprobe nvidia" would work.
However if you only have one nvidia gpu (and have a different kind of gpu for display), then I think simply running "sudo rmmod vfio" "sudo modprobe nvidia" would work.
One reason is to mix AMD and NVIDIA GPUs – I experimented with running X on the integrated Radeon device, while running CUDA on a Linux guest with GPU-passthrough. Trying to have CUDA on the host system led to library conflicts.
wintermute
None of these chips are for mobile. TDP on the chips in the Macbook Pro is 47W, while lowest TDP of the leaked Ryzen chips is 65W.
What could be of great interest would be if Ryzen came with mobile chips with LPDDR4, that would really put pressure on intel. Then they could also do 50W TDP and still compete with Intel for the Macbook Pros.
What could be of great interest would be if Ryzen came with mobile chips with LPDDR4, that would really put pressure on intel. Then they could also do 50W TDP and still compete with Intel for the Macbook Pros.
There aren't any Zen chips for mobile, there aren't any Zen "APUs" which have an integrated graphics card either.
The AM4 APUs that are launching with Summit Ridge are still construction cores and they come at 65-90W TDP also.
Until low TDP Zen chips are out and until Zen APUs are out AMD is effectively forfeiting the OEM and mobile markets.
Intel has also managed to scale it's current Core based CPU's to as low as 4.5W TDP which I have a very strong feeling that AMD will not be able to do until 2019-2020 at best, not with the TDP for these chips currently.
That said if AMD does release a 40-45W 4C CPU they'll have a strong chance of being a contender for at least some workstation level laptops, lack of native USB3 and no TB might hurt them but if PCIE over USB-C beats TB then they might still have a chance.
However since the external GPU enclosures became reliable I will never buy a laptop that doesn't support one for personal use unless it's a very very small form factor device and that's unlikely. Lets see if AMD will be able to come with a similar solution to how seamless TB2/3 with Iris graphics and an external GPU work these days.
The AM4 APUs that are launching with Summit Ridge are still construction cores and they come at 65-90W TDP also.
Until low TDP Zen chips are out and until Zen APUs are out AMD is effectively forfeiting the OEM and mobile markets.
Intel has also managed to scale it's current Core based CPU's to as low as 4.5W TDP which I have a very strong feeling that AMD will not be able to do until 2019-2020 at best, not with the TDP for these chips currently.
That said if AMD does release a 40-45W 4C CPU they'll have a strong chance of being a contender for at least some workstation level laptops, lack of native USB3 and no TB might hurt them but if PCIE over USB-C beats TB then they might still have a chance.
However since the external GPU enclosures became reliable I will never buy a laptop that doesn't support one for personal use unless it's a very very small form factor device and that's unlikely. Lets see if AMD will be able to come with a similar solution to how seamless TB2/3 with Iris graphics and an external GPU work these days.
The reason these are 65W+ is they are enthusiast CPUs (to compete with Intel desktops). They will have apu versions for mobile using this architecture later in the year.
AMD already has such a solution and Raven Ridge (Zen APU) is coming 2nd half 2017 (as far as anyone is aware).
It has, it's not out yet, currently it just relaunched its construction core Bristol Ridge APUs.
Once Raven Ridge will be out we can discuss it, currently Summit Ridge is nearly unknown.
Once Raven Ridge will be out we can discuss it, currently Summit Ridge is nearly unknown.
AMD announced Ryzen supports Win7 (drivers). A few days later, they changed the marketing to Win10. If AMD wants to sell their new Ryzen make sure Win7 drivers are available (even if it's not marketed, as Microsoft is bitter about it - Win7 is still most used OS).