So far all the products launched with Zen have aimed at the upper echelons of the PC market, covering mainstream, enthusiasts and enterprise customers – areas with high average selling prices to which a significant number of column inches are written. But the volume segment, key for metrics such as market share, are in the entry level products. So far the AMD Zen core, and the octo-core Zeppelin silicon design, has been battling on the high-end. With Ryzen 3, it comes to play in the budget market.
AnandTech’s review and benchmarks of the new low-end Ryzen 3 processors.
I find quite remarquable that all the RYZEN 3/5/7 chips are made from the same die, iirc “Zeppelin”, with different binning, disabled cores or multithreading.
The production cost of the lowest end R3 is the same as the highest performance R7, except for the bundled cooler.
Well, it’s well-known practice to do this either for marketing reasons but also for practical reasons. Intel has always done this at least as far back as differentiating CeLeron SKUs from Pentiums. If one of the cache modules has a flaw but the rest of the chip is fine, sell it as a feature-reduced chip for less money. The same with multiple cores and heat-related failures in certain CPU modules.
At least in the old days, most of the time the flaws are in the cache, so reduce cache and turn off HyperThreading. I wonder what AMD’s official word is on this practice for modern ryzen CPUs.
I seem to recall the 486SX was a 486DX that failed QC, so they burned out the links to the Floating Point Unit.
Motorola wouldn’t even burn out the links – if an FPU or MMU failed, they sold the chip AS-IS with a different label and told programmers to simply not use FPU or MMU instructions. There was no way in code to tell if the FPU or MMU was working or not.
AMD has done this for years, for example the Zosma Phenom quad was a Phenom hexacore with 2 cores turned off and there are Athlon X4s that you can attempt to reactivate the cache on which turns them into Phenoms.
And IIRC the FX chips are all a single chip…the FX-8350. They are either binned faster or slower or have some cores disabled but they are all just 8350s, even the “e” series were just “gold binned” FX-8350s that would run at 95w with just a slightly lower clock speed.
You really have to give AMD credit for doing that, their yields must be insane by just making one chip and then disabling cores/cache to fit different markets, no wasted chips, no need for multiple lines, quite smart.
bassbeast,
I once bought two athlon XP desktop processors and used conductive ink to repair the broken traces that differentiated them from athlon MP that could be used in dual CPU boards.
You can see those tiny traces in these pictures:
http://www.cpu-world.com/CPUs/K7/TYPE-Athlon%20MP.html
Edited 2017-07-29 08:30 UTC
Hah.I did that to unlock the multiplier on my 700MHz Duron.
Was able to get that processor up to 1Ghz and keep it stable.
Car makers have being doing the same thing with their engines for a century. They deliberately downgrade performance (lower compression, rev limiting, smaller displacement etc) on cheaper models to encourage buyers to upgrade. Now that turbo engines are common they can tweak the engine management software to alter the power output by a huge margin for almost zero cost.
unclefester,
This is probably also why they lobby for the DMCA to apply to cars.
http://www.autoblog.com/2015/04/20/automakers-gearheads-car-repairs…
In any other “legit” copyright case I’d say making your own changes to your own legal copy would not reasonably be construed as an infringement, but the DMCA made it illegal merely to circumvent copyright protections even if you aren’t otherwise violating any copyrights. And this is why manufacturers became fond of the DMCA, but the fact that this keeps happening just highlights how this was always just bad legislation, we should be repealing that!
Much more remarkable is why would you call something your company makes “Zeppelin”. They didn’t have the best name in the past.
Especially for a company (AMD) which is known for having had products which heating problems.
I just want intel to make significantly faster processors for each generation again, like in the Nehalem days
raom,
I’d like that too, but unfortunately it seems we’ve reached the point of diminishing returns. The problem is that while having X times more speed is more useful than having X times as many cores, a tiny increase in speed will require exponential increases in costs, which consumers are reluctant to pay for. This is why chip vendors have shifted towards pushing more cores instead.
At the higher price points CPUs would have to compete with other technologies like FPGAs that are both faster and more efficient, so that’s probably the direction the industry will be moving in once the scales of economy for those alternatives kick in.
Edited 2017-07-29 02:02 UTC
You mean x86 has been optimized close to as much as it can be done already? Is it not just intel being lazy due to no competition?
I think Centaur/VIA and NexGen would argue with that statement. In the case of Centaur/VIA, they had both directly running x86 instructions on CISC cores and emulated x86 instructions on RISC cores. The latter has won out.
Think of all the energy we could save by not emulating x86 and x86-64 on RISC cores. We’re talking ARM-level energy savings and reducing your physical footprint by more than a third. Think if Itanium succeeded.
But, backward compatibility, fam.
Hi,
Yes; backward compatibility is far more important than insignificant theoretical gains that don’t actually exist in practice. It’s the reason 80×86 managed to push every other CPU out of “mainstream desktop/server” (including Intel’s own Itanium), become dominant (despite IBM designing “PC” as short-term thing), and remain dominant for “multiple decades and still counting”.
ARM actually started out in home computers (Acorn), and like all of the others (Commodore, BBC, Tandy, Apricot, …) that were around in the 1980s got beaten severely by 80×86 PCs. The CPU part got spun off (becoming “ARM Holdings”) and continued in the embedded market (where the major deciding factor is price and not quality, performance or power consumption) for a few decades because they couldn’t compete otherwise. It’s only recently (due to smartphones, and especially with ARMv8) that they’ve started being more than “bargain basement”; and that’s mostly only because ARM CPUs have grown to become significantly more complex than “CISC” originally was.
Mostly, RISC was guaranteed to fail from the beginning. “Let’s do twice as many instructions where every instruction does half as much work” hits the clock frequency and TDP constraints (and instruction fetch problems) much sooner than CISC; and (unless the only thing you care about is design costs) only really seemed to make sense for a brief period in the early 1990s (during the “clock frequency wars” of 80×86, that ended when Intel released Pentium 4/Netburst and everyone finally realised clock frequency alone is worthless if you can’t sustain “effective work done per cycle”).
– Brendan
Then why is EVERY x86/x86-64 internally a RISC processor? Because RISC WON the processor war, but businesses still demand backwards compatibility.
RISC makes pipelining and super-scalar FAR easier to accomplish than CISC, and THAT is what makes modern processors so much faster.
JLF65,
Yes, it depends very much how we use the terms. The RISC cores have won out, but I think maybe you and brendon might agree that by converting to CISC into RISC microcode, the runtime performance CISC and RISC become very similar and in this sense the overhead for having complex instructions is minimized. Of course it’s still there in an absolute sense, but those transisters are operating in parallel and are not the main CPU bottleneck, although it could account for more power consumption.
Out-of-order execution and hyper-threading also really improved things.
Yes, the CISC to RISC translation layer gives the processor a chance to optimize the instruction sequence in a way that can’t be matched by any existing compiler. It tailors the instructions to the hardware in a way that is nearly impossible outside the processor. Out-of-order execution, fully utilizing parallel execution units, etc. It’s kind of the best of both worlds. I just wish they did this with the 680×0 instead of the x86 – I don’t know ANYONE who likes the x86 ISA. AMD did a good job in making the 64-bit spec, but it’s still just polishing a turd.
Done :
http://www.apollo-accelerators.com/#features
http://www.apollo-accelerators.com/files/ChangeLog
http://www.majsta.com/
Yes, I’ve seen that, and it does go a ways to disproving those old notions that the 680×0 line is impossible to accelerate like the x86. I think they’ll gather more interest once they get an ASIC version out as that will be much faster than the FPGA.
There are a few issues in MC68000 family that makes it arguably worse for high performance.
Most of x86 issues can be solved by more microcode : Call gates, segmentation, … and the lack of registers was solved by OoO renaming and AMD64. Most x86 instructions are actually not very complex and can be easily executed in 1 or 2 cycles. There very little of indirect, autoincrement or other advanced addressing modes.
The MC68020 has crazy indirect instructions which can trap while being partially executed (and saving the execution context of extremely complex CPUs is an issue when looking for high performance), it updates the flags for every instruction which reduce the efficiency of speculative execution, various other issues… Motorola actually discarded many silly parts in later models : The discrete MMU with many useless features, lesser used FPU instructions such as “Hyperbolic Cosine”, etc.
(but, of course, it could have been possible, flying pigs, etc. )
You don’t know a single person who likes x86 assembler? The issue could be you needing to expand your circle of acquaintances to include people who actually work on compilers, or write assembly professionally, perhaps?
This is a very old cliche which has been moot since the 386 (which I think it was released 30 years ago). 32bit and 64bit x86 ISA is pretty straightforward and vanilla.
tylerduren,
Haha, everyone has their own opinions, I’ve always been fond of intel assembly syntax much more than ATT syntax used by most unix compilers like GNU, ugh.
I’ve never had a problem with x86 assembly language, although many have had problems with specific legacy modes of it, and lately intel’s SSE mnemonics are making it much uglier, grr. It’s also very difficult to predict how the modern CPU pipeline will handle it. Everything you think you know can change every generation. I’d say the early pentiums were the last x86 CPUs that one could reasonably predict the pipeline behavior for. I wish they would have skipped MMX entirely, the floating point unit for x86 was always a terrible hack. With my P4 I learned to my dismay that the SSE instructions were not always as highly optimized as the non-SSE pipeline, but on newer CPUs… who knows? In the past instruction clock counts were straitforward, but these days you really have to benchmark everything and the results can be counter-intuitive. Still, it can still be useful to program in assembly to manually optimize the cache lines or to use instructions/features that are lacking in higher level languages.
In general I think art and knowledge of assembly programming is largely dying with us – we’re becoming the mainframe guys, haha.
I did say LIKE. Yes, the current x86-64 has never been easier to use (like that’s a high bar
), and I have no problems in programming in x86, but who actually LIKES programming in x86 assembly? No one. Programming in 680×0 or PowerPC was fun… there’s simply no way to call programming in x86 “fun”.
I’m getting tired of this nonsense.
There is no “internal RISC processor”. There is microcode. Microinstructions do not make an instruction set, Intel CPUs used to execute micro-ops sequentially (8086…80386), now it is pipelined, out of order, speculative, … but this do not make a RISC.
RISC/CISC is about instruction sets, and one of the ideas behind RISC was discarding the microcode and replacing it with a straightforward instruction decoder.
I think part of the confusion also comes from the fact that originally there were many research teams working on RISC designs, and each team had a different defintion for what the term meant.
Some RISC projects were indeed about exposing both the microcode and pipeline thus passing the programming complexity on to the compiler. Ironically, most RISC designs originally were not intended to be programmed by hand…
Treza,
The problem is that “RISC” is associated with different meanings, and whether we like it or not we now have to be more concise than just saying “RISC” and automatically expecting everyone to be on the same track. And before you disagree with me, I want you to take note that your own post used two of the differing meanings:
1) “RISC/CISC is about instruction sets”
and
2) “one of the ideas behind RISC was discarding the microcode and replacing it with a straightforward instruction decoder.”
I’m personally not at all bothered by this, but some posters do become frustrated when “RISC” is associated with this idea of a simple implementation even though it’s commonly used in that context. Many of the arguments in years past have started with semantic differences, so I’m hoping maybe we can all explicitly move beyond that and steer the discussion to something more substantive instead
With that in mind, I found this paper on the topic quite interesting:
http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-s…
Edited 2017-07-30 00:33 UTC
That’s a common misconception. The reality is not that modern CISC processors are RISC internally, but rather than both CISC and RISC processor families ended up converging into the same micro architectural principles (e.g. pipelining, superscalar, out-of-order, simultaneous multithreading, decoupling, aggressive prediction, etc) to achieve high performance.
All modern out-of-order PowerPC, SPARC, and ARM designs do break their “RISC” instructions into simpler sub instructions internally, just like a modern out-of-order x86 does.
RISC basically means 2 things; fixed instruction length, and register-to-register operations. A lot of stuff has been erroneously assigned as being “RISC” because many people keep confusing ISA with microarchiteture.
Yes, and no. Yes, the internals are not TECHNICALLY a RISC processor as such, but it DOES meet your definition – those micro-ops are all the same length, and internally they only do (shadow) register to register operations. The micro-architecture has standardized around RISC principles, which is why so many call it RISC internally – it’s closer to the truth than calling it CISC internally.
The internal decoupled out of order engines also meet the criteria of old CISC architectures; some modern RISC processors could be said to be internally microcoded.
That’s the point I was trying to make: the CISC/RISC architectural distinction has been meaningless since the turn of the century.
I’m just fascinated by how much people are still hung up on that terminology, which has been rendered meaningless for a looong while. The computer architecture crowd moved on from that debate eons ago.
The decode overhead in a modern x86 machine is in the single digit percetage of the total, close to rounding error at this point.
It is not much of an issue at this point, and in some cases CISC instructions end up being more power efficient (instruction memory access).
I keep repeating this in this site, since most people don’t seem to understand computer architecture: ISA and microarchitecture have been decoupled concepts for eons. Most of the power efficiency of ARM is due to microarchitecture characteristics, not to it’s ISA (except for extreme cases, like Thumb parts for deeply embedded markets).
raom,
I don’t believe it has so much to do with intel as it does with the easy engineering being behind us and the costs of moving forward are greater than ever.
But I do agree with you about there not being enough competition, one of the reasons could be that the costs of modern semiconductor facilities are absurdly high.
https://www.technologyreview.com/s/418576/the-high-cost-of-upholding…
http://www.economist.com/news/21589080-golden-rule-microchips-appea…
This resulted in mass consolidation with most companies exiting the chip fabrication business (ie AMD outsourcing it’s CPUs).
Also, any would-be competitors would likely have to contend with many billions of dollars worth of patent lawsuits and/or royalties, which obviously favors the old incumbents and protects them from new competition.
Another reality is that the consumer PC market is steadily shrinking year over year.
http://www.idc.com/getdoc.jsp?containerId=prUS42214417
This is not to say people don’t want faster computers, but the economic realities of building even more expensive fabs may be difficult to justify given the weak market.
Prices generally went up due to data centers that grew like mushrooms as soon as cloudops became a thing.
Funny thing is that everyone lured customers with “unlimited” plans for storing and processing data but now that they started gaining momentum they’re removing this option starting with individual accounts.
As for consumers, there is no secret that everything was supposed to run via web at some point.
Smartphones will share the same market stagnation as PC’s for very much the same reasons.
Sidux,
Yea, I agree smartphones will stagnate as well.
Although they have more planned obsolescence going for them (unlike my ancient PCs, I can’t update or fix my damn phone!)
FPGAs are not more efficient, at least not in such a way that one can state that without qualifying. FPGAs generally are less efficient as they have a lot of redundant hardware, hence why some will prototype on those to then develop ASICs. The advantage of an FPGA is the ability to retarget and massive parallelism.
Edited 2017-07-29 04:34 UTC
_txf_,
I don’t quite understand your critisism since CPUs have lots of redundancy too, with many features going unused for various use cases. Anyways it’s like saying a graphics card is not more efficient than CPU because it has lots of redundant hardware. When you factor in the nature of the work your computing, the value of parallel processors can make a lot of sense. Massively parallel processing is becoming more relevant to all aspects of computing: graphics/compression/ai/gaming/etc. Most FPGAs come with a traditional processor to program and control the FPGA and the heavy work gets done by the FPGA.
Of course the technologies aren’t directly compatible, but still, in terms of energy and performance this is generally true:
ASICS > FPGA > CPU.
Take bitcoin mining as a well studied example:
https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison
https://en.bitcoin.it/wiki/Mining_hardware_comparison
I tried to take a few fair examples from various categories for illustration…
Intel:
Core i7 3930k 66.6mhash/s 190watts = 0.35mhash/s/w
Arm:
Cortex-A9 0.57mhash/s .5watts = 1.14mhash/s/w
Amd:
2x Opteron 6172 55mhash/s 230watts = 0.24mhash/s/w
Nvidia:
GTX570 157mhash/s 219watts = 0.72mhash/s/w
FPGA:
X6500 FPGA Miner 400mhash/s 17watts = 23.53mhash/s/w
ASIC:
AntMiner S9 14000000mhash/s 1375watts = 10181.82mhash/s/w
BFL Monarch 700GH/s 700000mhash/s 490watts = 1428.57mhash/s/w
Obviously the FPGA and ASIC solutions have been optimized for this purpose, whereas a generic PC is not. But an efficient ARM processor does not (and can not) match the efficiency of an FPGA, much less an ASIC because CPUs fundamentally have to go through many more steps (ie transistors) to compute an algorithm. This is both slower, and takes more energy.
Note that the core i7 processor above had the benefit of a 32nm fab process whereas the Spartan 6 FPGA used a 45nm fab process, so the FPGA would have been even more efficient if it had the benefit of a 32nm fab. Intel CPUs have traditionally benefited from better fabs and not necessarily better architectures.
You and I can agree that the ASIC is better still, however ASIC chips are obviously hardcoded and cannot be reprogrammed, which is why I think FPGAs would make more sense in CPU evolution. This may be a bit controversial today, but to me it seems inevitable as we hit the performance boundaries of traditional CPU architectures.
Edited 2017-07-29 06:20 UTC
A CPU is like a Swiss Army Knife – it does most things badly and nothing particularly well.
Edited 2017-07-30 02:20 UTC
Is this sarcasm?
OzTalksHW did a series of benches placing the FX-8 against the Ryzen 3, result? If you have an FX-8 its a side upgrade at best.
https://www.youtube.com/watch?v=azX4Qs7n2_Q
This is why I’m gonna stick with my FX-8320e and why I’ve been saying for ages that hardware is frankly OP compared to the software we have to run on it as he’s getting very good framerates even on the latest games with a chip that came out in…what? 2012? And that was with strictly stock clocks on the FX-8370, I can attest with good cooling you can usually get a full Ghz or more OC with an FX-8 series CPU.
So while I’m happy we have competition again (just waiting for Intel to put out a “super cripple” compiler or start bribing OEMs again like they did when Netburst was stinking up the place) and to see prices going down and cores going up until I can actually find a job I do that the FX-8 cannot do? I’ll stick with what I have and I have a feeling the same is gonna be true of a lot of folks because if their software runs just fine on what they have why buy a new system?