AMD Zen Features Double the Per-core Number Crunching Machinery to Predecessor

[ShintaiDK]

There are practically no commercial apps that utilize AVX256 instructions so this a non-issue for Zen.

I assume you mean AVX512

 

[Dresdenboy]

Going forward...

I would not be surprised to see Cinebench and the like adopt this.

With 4 doubles this makes sense. For games it depends on the need of accuracy. Most calculations likely can live with SP, but an 8 SP vector would be more difficult to handle as usual vector sizes are 3 or 4.

This image... I had to go to the emergency room for oxygen... couldn't stop laughing.

Hehe, so it was worth it. Sometimes images say more than words.

I assume you mean AVX512

As written above, their are common use cases for 4xDP vectors. But AVX512 is something different, but should be good for any audio/video/image processing stuff. But with HW codecs, which help with the common use case of format conversions, there is again a smaller group of media editors left. And what's the adoption rate? And how does the increased power consumption affect max clocks during processing? There's already a specific AVX-P-State.

 

[PPB]

What about the SMT implementation? How good do you think it would be for being the very first time an AMD cpu goes this road?

 

[AtenRa]

Since AMD implemented some type of SMT in the FPU of the Bulldozer architecture, they already have some experience. So i believe they may have a good utilization from the SMT design in ZEN.

 

[Dresdenboy]

What about the SMT implementation? How good do you think it would be for being the very first time an AMD cpu goes this road?

As AtenRa wrote, they have some experience (which includes test and verification). I saw one patent filing, where they take care of thread priorities in their SMT implementation. That would be interesting, if they implemented it in Zen...

 

[PPB]

My uneducated guess would indicate AMD is already going the good way with SMT as their dedicated pipelines(if they stay as earlier cpu history might indicate) should be a simpler solution and less awkward to optimize in further generations in than Intels so called execution ports.

 

[mrmt]

My uneducated guess would indicate AMD is already going the good way with SMT as their dedicated pipelines(if they stay as earlier cpu history might indicate) should be a simpler solution and less awkward to optimize in further generations in than Intels so called execution ports.

I wouldn't put much hope on AMD implementation of SMT. Intel, SUN and IBM spent a lot of money and a lot of implementations on their SMT implementations until they reached the point they are now, to expect AMD to get a home run in their first try is a pipe dream.

And going for the simpler solution doesn't necessarily indicates better performance, but possibly lack of R&D budget.

 

[PPB]

Yeah, we know Intel stockholders wont put too much faith in anything AMD, otherwise they would be AMD stockholders too.

Also, comparing IBMs SMT to Intel's just because R and D expensitures is naive at best.

 

[Arachnotronic]

Yeah, we know Intel stockholders wont put too much faith in anything AMD, otherwise they would be AMD stockholders too.

Also, comparing IBMs SMT to Intel's just because R and D expensitures is naive at best.

I think it's interesting that you resort to thinly veiled personal attacks to try to counter what is a pretty reasonable point that Intel and others have more experience in implementing SMT in high-volume commercially available architectures than AMD does.

 

[PPB]

I think it's interesting that you resort to thinly veiled personal attacks to try to counter what is a pretty reasonable point that Intel and others have more experience in implementing SMT in high-volume commercially available architectures than AMD does.

Your argument isnt the same. Intel and IBM have more experience in SMT implementations, but that experience doesnt affect AMD's result on theirs. Its plain old non sequitur which doesnt even deserves to be refuted.

His assestment was oriented from the purely R and D expenditures side (not surprising considering who is it coming from) which becomes even more of a non sequitur because this industry proved time after time that throwing more money at R and D wont make your uarch better by default, it is definetely a factor, but mind you netburst costed Intel a pretty penny too and the result is for everyone to see.

There should be a finance subsection in this subforum so the usual suspects can continue the circle jerk, the technical information provided by the 2 posters right after my first post should be the point being look at, after all this is a technical discussion subforum.

 

[Arachnotronic]

Your argument isnt the same. Intel and IBM have more experience in SMT implementations, but that experience doesnt affect AMD's result on theirs. Its plain old non sequitur which doesnt even deserves to be refuted.

OK. Would you agree, though, that AMD's first attempt at SMT may be "rougher" around the edges than Intel's/IBM's given that the latter two have more experience implementing it in commercial architectures?

His assestment was oriented from the purely R and D expenditures side (not surprising considering who is it coming from) which becomes even more of a non sequitur because this industry proved time after time that throwing more money at R and D wont make your uarch better by default, it is definetely a factor, but mind you netburst costed Intel a pretty penny too and the result is for everyone to see.

Lots of poorly deployed R&D certainly won't make your product better. However, would you agree that too little R&D has the potential to negatively impact a product in terms of scope and/or schedule?

 

[mrmt]

His assestment was oriented from the purely R and D expenditures side (not surprising considering who is it coming from) which becomes even more of a non sequitur because this industry proved time after time that throwing more money at R and D wont make your uarch better by default, it is definetely a factor, but mind you netburst costed Intel a pretty penny too and the result is for everyone to see.

We can list several examples of companies throwing R&D money and not getting good results, but I'm yet to see any example of a company *not* throwing the correct amount of R&D money and getting good results.

Maybe you could better advise AMD management team. They seem pretty keen to reassure investors every time they make new cuts that R&D activity will be spared of the cuts. Maybe they should tell investors that this R&D argument is a total non-sequitur, and no matter how deep AMD cut down their R&D budget they will still be able to develop a competitive product.

 

[Fjodor2001]

but I'm yet to see any example of a company *not* throwing the correct amount of R&D money and getting good results.

Check out the small cap tech stocks that have been rising and you'll find them. There are lots of such examples.

Having said that it's also not a bullet proof indicator. Because there can be companies who's got a simple but brilliant idea, not requiring much R&D to realize, but that bring huge profits. And companies can get good profits because they are good at marketing, or they rest on their laurels trying to achieve and capitalize on their close-to-monopoly-status (i.e. Intel style).

 

[AtenRa]

We can list several examples of companies throwing R&D money and not getting good results, but I'm yet to see any example of a company *not* throwing the correct amount of R&D money and getting good results.

Maybe you could better advise AMD management team. They seem pretty keen to reassure investors every time they make new cuts that R&D activity will be spared of the cuts. Maybe they should tell investors that this R&D argument is a total non-sequitur, and no matter how deep AMD cut down their R&D budget they will still be able to develop a competitive product.

Were you the one to tell us that ZEN will be small core CAT-based CPU because of the small R&D ???

Do you really know the R&D amount spend for the ZEN project to come to that kind of conclusions ??


news - AMD next mArchitecture ZEN.........

mrmt - ZEN will be small core cat based because AMD R&D is lower than before

news- AMD next GPU will be bigger than 500mm2........

mrmt - no way they will be able to create a large GPU chip because the R&D is lower than.......

news - AMD next .........

mrmt - No way, to low R&D. They cannot......... low R&D............. the R&D is too small.............. bla bla bla small R&D they cannot, its dooms day for AMD because the R&D........bla bla bla.


That is going on in every AMD hardware related news the last 2-3 years now.

 

[MiddleOfTheRoad]

We can list several examples of companies throwing R&D money and not getting good results, but I'm yet to see any example of a company *not* throwing the correct amount of R&D money and getting good results.

Yeah -- Compare General Motors to Tesla. GM throws a ton more money at R&D than Tesla, but the Cadillac ELR looks (and drives) like a piece of garbage if you park a Tesla Model S next to it. It's a fair comparison, too -- since they are roughly the same MSRP. The small, agile company can often outperform the larger competitor. AMD totally stomped the Pentium 4 -- likely on tiny budget compared to what it cost to develop the Pentium 4.

 

[Fjodor2001]

Were you the one to tell us that ZEN will be small core CAT-based CPU because of the small R&D ???

Do you really know the R&D amount spend for the ZEN project to come to that kind of conclusions ??


news - AMD next mArchitecture ZEN.........

mrmt - ZEN will be small core cat based because AMD R&D is lower than before

news- AMD next GPU will be bigger than 500mm2........

mrmt - no way they will be able to create a large GPU chip because the R&D is lower than.......

news - AMD next .........

mrmt - No way, to low R&D. They cannot......... low R&D............. the R&D is too small.............. bla bla bla small R&D they cannot, its dooms day for AMD because the R&D........bla bla bla.


That is going on in every AMD hardware related news the last 2-3 years now.

The rest of the Intel fanclub said that same. ShintaiDK and friends. All were dead certain as usual.

 

[MiddleOfTheRoad]

OK. Would you agree, though, that AMD's first attempt at SMT may be "rougher" around the edges than Intel's/IBM's given that the latter two have more experience implementing it in commercial architectures?

Agreed -- and since Bulldozer was AMD's first attempt at SMT (for its FPU and cache -- the integer cores were not capable of SMT), Zen will likely be a solid improvement.

https://en.wikipedia.org/wiki/Simultaneous_multithreading

 

[erunion]

I hate to get entangled in this but...

AMD is not a small, agile start up breaking into an entrenched market with complacent players.

Its one of those established players in decline. Everything has shrunk for AMD : Market share, revenue, workforce. It is more like GM than it is like Tesla. Its small size relative to Intel doesn't change that.

 

[Fjodor2001]

I hate to get entangled in this but...

AMD is not a small, agile start up breaking into an entrenched market with complacent players.

Its one of those established players in decline. Everything has shrunk for AMD : Market share, revenue, workforce. It is more like GM than it is like Tesla. Its small size relative to Intel doesn't change that.

We all know that. But what's your conclusion? Can we really draw any certain conclusions on how Zen will perform based on this?

Being established is not all bad, it also means they have a lot of knowhow and experience from before.

 

[erunion]

We all know that. But what's your conclusion? Can we really draw any certain conclusions on how Zen will perform based on this?

Being established is not all bad, it also means they have a lot of knowhow and experience from before.

I agree that we can not predict how zen will perform based on it.
And that ties in with my point. We can talk all day about what has happened to other companies and what is possible: Anything is possible.

But what's more interesting to me is what is likely to happen. If Zen performs so well as to change the competitive landscape that would be a reversal of AMDs recent situation.

So my conclusion would be that we should look at what internal factors at AMD have caused the performance deficit with intel. Then we should decide if those factors/causes have reduced or increased over time. That should give us an idea what is likely.

 

[bononos]

AMD has been badly burned by benchmark cheese for a long time.
.....
3) Poison compilers so that they don't take full advantage of AMD chips.
.....

Well the thing is AMD cpus still run faster on Intel's crippled compiler, at least on windows. If AMDs own compiler/libraries at developer.amd.com or Microsofts visual studio can't beat Intel's compiler, its harder to fault Intel for crippling its compilers if he cpuid is AMD.

 

[myocardia]

Like this?

Looks legit to me! It wouldn't be so technical, if it weren't directly from AMD.

 

[erunion]

The wider floating point unit also means that Zen will be able to process less complex instructions at double the rate of Steamroller. Which would mean a massive boost in floating point performance, an area where AMD had historically excelled in with Phenom II and other microarchitectures prior to bulldozer.
I should mention that AVX-512 support was not listed for Zen in the Linux patch that was released in March, which revealed the new instruction set extensions that Zen will support. This is slightly odd but could be explained by a possible lack of 512bit integer support in Zen, which is required for the AVX-512 extension.
There was also one particularly important improvement with Zen that Mr. Waldhauer has managed to spot in a number of patents filed by AMD CPU engineers working on Zen.

That Zen diagram was a forgery. It did not originate from AMD.

 

[Arachnotronic]

That Zen diagram was a forgery. It did not originate from AMD.

And Skylake is 5-way decode, so that table is just plain wrong. Peak decode rate is 6 uOps/cycle if there is a hit in the uOp cache.

 

[superstition]

Well the thing is AMD cpus still run faster on Intel's crippled compiler, at least on windows. If AMDs own compiler/libraries at developer.amd.com or Microsofts visual studio can't beat Intel's compiler, its harder to fault Intel for crippling its compilers if he cpuid is AMD.

The compiler crippling had a pronounced effect even long into the past, the result of which remains with us in terms of AMD's weakened position.

http://www.agner.org/optimize/blog/read.php?i=49

http://www.yeppp.info/home/yeppp-performance-numbers/

Intel’s own compilers refused to run SSE or SSE2 code on compatible AMD processors; applications would check for the “GenuineIntel” string when running these programs rather than simply checking to see if SSE2 was supported on the processor. That’s a particularly low blow considering AMD paid Intel for licenses.

In its 500-plus-page findings of fact, the European Union laid out repeated demonstrations of how Intel used predatory rebate practices to keep companies from carrying more than certain percentage of AMD hardware.

In order to compete with Intel’s rebates, AMD had to offer an equivalent price savings, but on a vastly smaller number of chips. In one situation, AMD offered to give HP a million processors, for free, if it would use them to build systems. HP responded that it couldn’t afford to do so, because the total value of a million free processors was smaller than the value of Intel’s rebates.

Intel’s systemic sabotage of its rival undermined AMD’s ability to maximize its own profits during the 2003-2006 window.

It dates to when AMD released the Athlon XP back in 2001, which was I think the first non-Intel processor that supported SSE. Back then it was discovered that Windows Movie Maker 1.1 shipped with the original RTM release of Windows XP as well as Windows Movie Encoder 7 did not use SSE on non-Intel processors. It was reported that it accounted for a dip in the Sysmark 2001 and Winstone 2002 Content Creation benchmarks.