AMD CPU speculation... and expert conjecture

[griptwister]

So wait... you mean to tell me 8350rocks, on multiple threads, was right about a FX 6300/6350 being near i5 level performance? Well, shoot then. (Lol, This guy seems credible to me)

Also, if you look at the benchmarks that have been posted with the FX 6350 in it, I think we see how close this CPU game is about to get, Intel should be slightly worried on the enthusiast side of things. Esp if SteamRoller OC's good.

And some of you might want to check this out...

http://www.forbes.com/sites/jasonevangelho/2013/08/13/can-amds-newest-apu-play-your-favorite-games-without-a-dedicated-graphics-card-part-1/

 

[juanrga]

You are a confused and confusing guy lol

What is "DP/BD" ... double precision and ?

Double precision per BD module.

Which is wrong, 8 flops FPU can only be achieved with 128bit FMA4, and those are single precision not double.The main problem is "issue port", tough those are SIMD instruction to claim a sustainable peak flop rate you got to count the "wide" of the issue port

No. 8 FLOP (Double precision) per module using FMA4. Single precision is 16 FLOP per module = 8 FLOP per core.

"" The 8 FLOPs claimed by AMD correspond to a single (shared) FlexFPU per module. "" ... yes i doubted but not contested. But only if is 4ops per 128bit pipe, and only for 32bit FP ops. What you don't understand is that a "vector" which is like an agglomeration of simpler operations, and in this case multiply+add has to be present with up to 4 operands, and since the "issue port" is only 128bit large, for being per cycle it must correspond to 128bit FMA4 instructions, or vectors of 4x 32bit ops because if 64bit ops, then it will not fit "per cycle" trough 128bit ports(must take 2 or more cycles, or be split in halfs for 2 pipes)

Those (128bit FMA4) exist are part of the XOP package. But since intel with is cloth imposed an embargo, nobody really uses XOP outside of very very few specialized apps, so that claim is not about a pure pervasive FLOP capability but only special case. Besides vectors of 32bit FP ops is not what is most useful, better would be vectors of 64bit ops.

Did you read my posts? I already gave FLOP values for both SSE2 and FMA4 instructions. I also discussed both 32bit and 64bit.

I'm reading and answering now... what do you think ? And i don't care where you picked those values to parrot them, just give the math leading to them, don't pretend to have the authority just because you picked something from somewhere which you think is authoritative. There could be mistakes and there could be very wrong interpretations, which would make you automatically wrong not right, even if those are not your mistakes.

So your 128GFLOP can only be of a 4 module CPU, because 8 flops per FlexFPU is 32GFLOPS, and only a 4 module chip could have 128GFLOPS from the CPU side... if that is what you are stating... Flops is = number of Ops x frequency; and that case per FlexFPU is 8 x 4Ghz =32GFLOPS not 128... and yet not very useful because only in the case of 128bit FMA4 instructions. 256bit FMA4 XOP instructions uses both FMAC pipes, though they are vectors of 64bit ops, the rate is half. Got it now ?

Did you read my posts? I already gave FLOP values for both SSE2 and FMA4 instructions. I also discussed both 32bit and 64bit.

Here we go again, sounds exactly like a parrot

This is what lead me to the speculations of 256bit FMACs, that is, one single FMAC is 256bit large internally and *must* have a 256bit port... and using 2 FlexFPU per module leads up to 32 64bit ops per 4 module CPU. Now this could be very useful, for all those scientific applications.

"" The diagram of the Steamroller module has been posted here numerous times. I posted again a pair of post above: there is no "each FAMC pipe is now 256bit large ""... have you seen an actual, after all this delays, diagram of an actual Steamroller chip ?... NO!

YES, for instance in the japanese article (July this year) cited by 8350rocks. Besides that, AMD already gave (at Computex this year) the GFLOP for kaveri and the value coincides with that resulting from analysing the Steamroller module that everyone knows.

AMD gave "supposedly" the FLOP number for Kaveri, counting the GPU, which will be "single precision". You went along and extrapolated the frequencies and and DP based on your "no math" incredibly likely very wrong assumptions.

Good to know that I only needed to repeat you three or four times that 1050 GFLOP is single precision. Any bet I will need to say this to you again? LOL

Yes, I predicted the frequencies of 4Ghz for the CPU and 0.9Ghz for the GPU. If you have other frequencies that fit with the data we know, share them with us. No nonsense please.

Yes is quite possible that the APU modules only have 1 FlexFPU, after all they have a GPU, that has much more FLOP capability, and compute programing is here to stay. But a server/FX chip could very well have 2 FlexFPU per module, the decode "kind of double" and double dispatch, and other improvements could be sufficient to sustain the needed rates even with 256bit FMACs on 2 FlexFPU per module.

No. AMD only releases a single Steamroller module. Kaveri APU is 'derived' from Berlin APU. There is no steamroller server/FX chip in the roadmaps.

Nobody really knows anything concrete about Berlin yet. AMD gave an interview were it stated the intention of continuing with FX... the rest are assumptions that could be wrong (even mine).

At least i have the care to expose that 2 FlexFPU could be technically possible, not that they will have it.

With you, is how you say and thats the end of it LOL (presumptions are the mother of all F ups lol)

At contrary, we have concrete info about Berlin, including total gflop per-watt compared to Opteron.

Yes those were not revealed in any "slide presentation", but were disclosed in a "programmer guide" just google AMD FP256, probably youll go to planet3dnow... a help...

http://www.planet3dnow.de/photoplog/file.php?n=24314&w=o

256bit AVX instructions executed with full-width internal operations and "pipeline" rather than decomposing then into 128bit sub-operations ... can only mean the pipeline executing them has 256bit "issue ports" and so is 256 bit wide also, even if internally its composed of bridged 128bit sub-pipelines also suitable for other operations. Going by 2 128bit pipes working together, it would have to be in halves, or the arbitration for Register File access will be a hell and the chip will clock slower.

Now that seems to me like they are needing 256bit FMAC pipes...doesn't to you ?

No. In the first place, nothing in that manual mentions Steamroller. Some people speculates that entry is for future excavator module. I disagree. It seems related to this

http://images.bit-tech.net/content_images/2011/10/amd-fx-8150-review/bulldozer-fp-unit.jpg IMAGE

In fact your hypothetical FPU with 256bit FMAC units gives GFLOP values that disagree with those given by AMD.

The correct values are:

- Steamroller module has 2 x 128bit FMAC units.

- Each unit can do 2 DP or 4 SP.

- SSE2 => 1 op; FMA4 => 2 op

- Steamroller Kaveri performance is 4C x (4SP x 2 FMA) x 4GHz = 4C x 8 FLOPs x 4GHz = 128 GFLOP

- The GPU performance is 512C x 2 FLOPs x 0.9GHz = 922 GFLOP (SP)

- Total APU performance: 922 + 128 = 1050 GLOP. This is the value claimed by AMD officially. Moreover AMD labs has confirmed that Steamroller gives "8 FLOPs per core".

Everything else is your own misunderstanding or pure fantasy.

What an arrogant little... quite an imagination lol... but you are right (*some*) in the simple math, only mention that 4 SP per 128bit pipe only with 128bit FMA4 instructions, no other instructions could sustain that rate... and there isn't 4C APU version according to reveal, was advented the possibility of 3C, but was discarded by now.

No. 4SP can be obtained with both FMA4 or SSE2. The difference is that one set provides 2 ops and the other only provides 1 op. It is evident what set is using the above computation. unless you confound both.

You are again confounding modules with cores. Kaveri APU comes with 2C and 4C configurations. It is the possibility of 6C which was droped.

So Kaveri will be only 2 modules 2 FlexFPU and the rate is half of what you claim on the CPU side... unless there is 2 FlexFPU per module LOL ... otherwise you have to re-ẽvaluate your fantasy.

Yes, Kaveri maximum is 2M with its 2 FlexFPU. No, the rate is 128 GFLOP. It is one half in your fantasy. In fact trinity already have 121.6 GFLOP because has a freq. of 3.8Ghz instead of 4.0Ghz

If the 4C means "4 cores" like in Integer Cluster/Cores, then you are more F up than i imagine, those Integer Cluster/Cores don't do any FP calculations, and that is exactly the strong point of the design.

LOL Integer cores doing FP!!!

Those vectors/FP instructions are SIMD in nature, the same instruction can run several times with different data. 1 single core module could be enough to fill a 2 FMAC FPU (which again leads to the possibility of 2 FlexFPUs), but obviously it could tend to leave much performance on the floor, it would have to be implemented wisely. Mixing Integer cores for the FP calculations is completely F up, GPUs don't have Integer cores per say, yet is not because of that you can't calculate FLOP rates.

You are trying hard to mess it all. This is a typical tactic to hide errors, but is not working.

And no * - SSE2 => 1 op; FMA4 => 2 op *;.. SSE as well FMA4 are vector instructions, SSE have 2 or 3 operands and FMA4 have 4 operands, and of those only very few correspond to actual 1 Add+ 1Mul or 2 adds + 2 Muls in case of FMA4, usually 1 or more operands are destination registers (mem ops).

No. In fact the 2 ops provided by FMA4 are of the kind a*b+c.

And no the * IMAGE* doesn't present anything new, that is exactly how the FLexFPU deals with 256bit instructions now, it uses both FMAC pipes of the FPU.. the scheduler is/was unified since BDver1.

It was already remarked before that the FP capabilities are not changed in Steamroller.

For FP256 as revealed the issue port must be 256bit wide, and the addressing is 256bit wide in nature (not 128bit in half's) [ EDIT : and AMD could do this because they have a "load buffer" before the FP pipes, the load buffer could be 256bit wide, while the rest of the data paths remain 128bit, for not penalize clock ability]. For 128bit instructions on 256 bit pipes, those could be be packed before and interacting with the scheduler *at runtime*, like used in the schemes of "Uops fusion" either Intel or the AMD K10 ALU+AGU, or *at compile time* and so the code is transformed into AVX 256 or FMA4 256, and so no more 128bit vectors. If those are not packed or compiled for 256bit, a 128bit instruction can only be issue one at a time per pipe, wasting half the possibility of a 256bit pipe.

The same happens today for 64bit or 32bit FP ops on 128bit pipes, and since there isn't any *runtime* packing so far, that is why 8 FP ops per FlexFPU only if the code is compiled for 128bit FMA4 instructions, which is single precision.

Wrong again. The above GFLOP are the numbers claimed by Intel for the CPU. The 448 GFLOP of haswell i7 CPU are reported in several sites.

Intel likes to use DP in its technical datasheets. If you want to obtain DP values you only need to divide the above SP numbers per 2. E.g. the 224 GFLOP (SP) correspond to 112 GFLOP (DP).

You are indeed confusing and confused... you must tell from those numbers what is due to GPU and what is due to CPU cores, and what corresponds to "single precision" and "double precision" and what kind of vectors use them ... 244GFLOPS seems a little low even for a GT2, but must be single precision, since the GPU barely moves on "double precision"... but if there is magic and is only CPU side, just "present the math please" that leads to those numbers.... Flops is = number of Ops x frequency

( no way in hell could haisfail have 244GFLOPS from the CPU cores side with only 3.6Ghz... gzz.. what propaganda do to ppl heads lol (edt))

And this proves that you don't read my posts. As quoted above by yourself I am saying that the those GFLOPs are for the CPU alone. I am also saying, in the same quote, what figures are double precision (DP) and what figures are single precision (SP).

Haswell is 3.5GHz, not 3.6Ghz; besides that mistake, the above GFLOP values are given officially by Intel. It is very easy to obtain them

http://www.realworldtech.com/wp-content/uploads/2012/10/haswell-3.png?b22ba0 IMAGE

Sandy Bridge double Nehalen FP capabilities by double wide units. Ivy Bridge maintain the same architecture. From the diagram:

- ( 8SP x 1MUL ) + ( 8SP x 1ADD ) = 16 FLOP

- i7-3770k performance is 4C x 16 FLOPs x 3.5GHz = 224 GFLOP (SP). For DP the value is one-half: 112 GFLOP (DP). This is the value claimed by Intel officially in their technical datasheets.

As observed in the above diagram Haswell introduces FMA support. Therefore:

- ( 16SP x 1FMA ) = 32 FLOP

- i7-4770k performance is 4C x 32 FLOPs x 3.5GHz = 448 GFLOP (SP). For DP the value is one-half: 224 GFLOP (DP). Again this is the value claimed by Intel officially.

Now the total performance (CPU + GPU):

- i7-3770k: 224 + 294 = 518 GFLOP. This is the value claimed by Intel officially.

- i7-4770k: 448 + 400 = 848 GFLOP. This is the value claimed by Intel officially.

- Kaveri A10 APU: 922 + 128 = 1050 GLOP. This is the value claimed by AMD officially.

Now please, stop ignoring what has been said. Stop ignoring what both Intel and AMD officially claim about its products, and stop fantasizing about imaginary Steamroller modules only in your head.

What a confusion lol ... And because is (could be) 1050 GFLOPS, it doesn't mean is divided like you say... it could be only GPU (more likely), and single precision... how can one not ignore when you don't really know nothing concrete !? lol

See, my bet I would repeat to you again that 1050 GFLOP is Single Precision is confirmed.

AMD said to us that 1050 GFLOP is for the whole APU. Everyone at Earth knows that, except you. You continue living in a parallel universe or alternative reality where 1050 is only for the GPU.

And RWT is wrong, they went along to be part of the propaganda machine.

In that * IMAGE *, Port 0, Port 1 and Port 5 are 128bit wide... just tell me how you fit 8 SP (8x 32bit ops) trough a 128bit port !!?? ... they are counting only with the SIMD nature of those instructions, once issued they can run several times. But even this is quite "borged", because even RWT with a little effort (LOL), mentions that to load 256bit data trough 128bit data paths, employing a single L/S engine for the purpose, sometimes some instructions, can take up to 5 cycles. big LOL...

No.. in spite all the flash and the potentiality of those exec clusters, the reality is that 256bit rate in intel is ~ the same of BD that uses halfs, and 2 L/S engines. Intel is dropping more potential performance on the floor than AMD, because they have 3 exec pipes (3 issue ports) for FP calculation while AMD only has 2.

That is reality, and a point in favor of AMD design of separated FPUs and modules, the rest is propaganda. Intel design on the side of CPU is not really prone to "simple math" for FLOP calculations, no matter the forgetting of issues and pulling *theoretical* peak flop rates out of the arse. And worst they don't have FMA4 which makes those *theoretical* numbers very hard to swallow, specially concerning single precision.

Worst the GPU side is neither simple to extrapolate.

The 448 GFLOP bigLOL... if GPU corresponds to 20 EU, 80MADs

From
http://translate.googleusercontent.com/translate_c?depth=1&hl=pt-BR&rurl=translate.google.com&sandbox=0&sl=ja&tl=en&u=http://pc.watch.impress.co.jp/docs/column/kaigai/20130602_601851.html&usg=ALkJrhhPzMDgw2L2K6-JhljRXPUDnNtkBA

Chart images of different GPUs
http://translate.googleusercontent.com/translate_c?depth=1&hl=pt-BR&rurl=translate.google.com&sandbox=0&sl=ja&tl=en&u=http://pc.watch.impress.co.jp/img/pcw/docs/601/851/html/20.jpg.html&usg=ALkJrhiciI2SqQZM48SAolYQbJi2E0FtbQ

Now if 80 MADs if corresponding to 160 ops at 1.2Ghz, means 160x1.2 = 192 GFLOPS , meaning the CPU cores would have to have 256 GFLOPS LOL or 64 GFLOPS per core, double of AMD and that is not what benchmarks tells...

If 448 GFLOPS is Iris... then is double (160 MADs) or 384 GFLOPS for the GPU alone and 64 GFLOPS for the CPU (more like reality)... but then that is not 4770k is it ? ... too much confusion in all of intel, i've given up long ago, you can entertain yourself with this complete futile worthless pointless academic exercises.

See, another example of that you don't read. The 448 GFLOP are for the CPU. I have said that are for the CPU. I have shown you the math. And still you pretend to blur all by pretending that 448 is for the GPU Moreover, there is not Iris in the 4770k. LOL

 

[Ags1]

So wait... you mean to tell me 8350rocks, on multiple threads, was right about a FX 6300/6350 being near i5 level performance? Well, shoot then. (Lol, This guy seems credible to me)

Also, if you look at the benchmarks that have been posted with the FX 6350 in it, I think we see how close this CPU game is about to get, Intel should be slightly worried on the enthusiast side of things. Esp if SteamRoller OC's good.

Well, I hope AMD bring out 6/8 core parts in their next generation (and not just 4-core APUs)... Notably, the FX6350 scored best in the most recent games like Crysis 3 - games are defintely heading in the AMD more-cores direction. So if AMD stick with the architecture, and improve efficiency a bit, they could clean up with their next iteration.

 

[noob2222]

the PII x6 if you can find one are 250+, putting it considerably more expensive than the 8350.

I bet I would not get anything higher than ~$70 for my used 1055T And a brand new 1045T is ~$130 in Lithuania.

really? your arguement is a locked multiplier low 2.7ghz 1045T ... good luck getting that anywhere close to 4.0 ghz.

 

[gamerk316]

Ummm...wowzers if true:

http://www.extremetech.com/computing/164209-windows-8-banned-by-worlds-top-benchmarking-and-overclocking-site

tl;dr: MSFT messed up the Real Time Clock in Win 8; if you adjust BLCK in software, Windows can't properly keep time. And since benchmarks use the RTC to figure out how long they ran, HWBot is disqualifying Win 8 from all its benchmarks.

This is significant in impact: Any benchmark taken under Windows 8 is unreliable if this is true.

So...back to trusty Win 7 x64 for benchmarking I guess...

 

[hcl123]

Also here on CPU Boss, look at this!:
http://cpuboss.com/cpus/Intel-Core-i5-3570K-vs-AMD-FX-6350

The i5 won, especially in single threaded (lol), but it also beat it in overclocking by .4 points.
In the end though, there is much more props for the 6350.

Terrific!... then there is no need to upgrade, on what we can call a real benchmark, Hasfail ... err Haswell.. is only 5 % to 7 % better, and this with FMA( of AVX 2), without it it "should" be notoriously less. FMA(3) of AVX 2 brings barely any noticeable improvement.

Funny i've seen benchmarks of AMD with FMA4 over 20% improvement ... the "should" above ? ummm ...or perhaps not funny neither sarcastic, does intel have any real FMAC pipe ? ... is the design really prepared or obsolete for those real performance booster kind of code ( the same IB and past SNB and earlier) ?

http://www.realworldtech.com/forum/?threadid=135386&curpostid=135386
[deserves a big LOL]

 

[The Q6660 Inside]

Ummm...wowzers if true:

http://www.extremetech.com/computing/164209-windows-8-banned-by-worlds-top-benchmarking-and-overclocking-site

tl;dr: MSFT messed up the Real Time Clock in Win 8; if you adjust BLCK in software, Windows can't properly keep time. And since benchmarks use the RTC to figure out how long they ran, HWBot is disqualifying Win 8 from all its benchmarks.

This is significant in impact: Any benchmark taken under Windows 8 is unreliable if this is true.

So...back to trusty Win 7 x64 for benchmarking I guess...

Well, doesn't everybody OC via BIOS these days? Oh well...

 

[griptwister]

Ummm...wowzers if true:

http://www.extremetech.com/computing/164209-windows-8-banned-by-worlds-top-benchmarking-and-overclocking-site

tl;dr: MSFT messed up the Real Time Clock in Win 8; if you adjust BLCK in software, Windows can't properly keep time. And since benchmarks use the RTC to figure out how long they ran, HWBot is disqualifying Win 8 from all its benchmarks.

This is significant in impact: Any benchmark taken under Windows 8 is unreliable if this is true.

So...back to trusty Win 7 x64 for benchmarking I guess...

Win7 ftw! I just disabled Areo, and I'm loving it.

I recently saw a vid from Linus where he benched Crysis 3 in win 8 with a FX 8350 and said the minimum on the FX 8350 was better (31 FPS or something like that) compared to windows 7 (21 FPS) and the FX 8350 pretty much matched the i5.

@hcl123, LOL!

 

[The Q6660 Inside]

Ummm...wowzers if true:

http://www.extremetech.com/computing/164209-windows-8-banned-by-worlds-top-benchmarking-and-overclocking-site

tl;dr: MSFT messed up the Real Time Clock in Win 8; if you adjust BLCK in software, Windows can't properly keep time. And since benchmarks use the RTC to figure out how long they ran, HWBot is disqualifying Win 8 from all its benchmarks.

This is significant in impact: Any benchmark taken under Windows 8 is unreliable if this is true.

So...back to trusty Win 7 x64 for benchmarking I guess...

Win7 ftw! I just disabled Areo, and I'm loving it.

I recently saw a vid from Linus where he benched Crysis 3 in win 8 with a FX 8350 and said the minimum on the FX 8350 was better (31 FPS or something like that) compared to windows 7 (21 FPS) and the FX 8350 pretty much matched the i5.

@hcl123, LOL!

+1, still rocking Windows 7 Pro with Ubuntu 13.04 dual booted.

 

[hcl123]

No. 4SP can be obtained with both FMA4 or SSE2. The difference is that one set provides 2 ops and the other only provides 1 op. It is evident what set is using the above computation. unless you confound both.

You are again confounding modules with cores. Kaveri APU comes with 2C and 4C configurations. It is the possibility of 6C which was droped.

No SSE like AVX1 has up to 2 operands in the same vector instruction, AVX 2 have up to 3 (FMA3) and XOP have up to 4 (FMA4)... the "numbers" that those operations operate in the context of SIMD, is dependent of the "wide" of the vector, but be assured the number of "numbers" is not the most useful ( SSE instructions can have up to 16 byte numbers or 8 16bit short integers "numbers" per vector), but what those operations can do is ... wikipedia it...

You are confounding modules with cores is you...

Yes, Kaveri maximum is 2M with its 2 FlexFPU. No, the rate is 128 GFLOP. It is one half in your fantasy. In fact trinity already have 121.6 GFLOP because has a freq. of 3.8Ghz instead of 4.0Ghz

CHART
http://d2lupdnmi5p5au.cloudfront.net/i__src66e13e53113e26c120439c9dd826eabd_paraf0d99c20bd457d46a92c72841873c47.jpeg

Idiot use your brain. That "CHART" is for a Llano. Integer cluster/cores on AMD BD don't do FLOPS, or are you not sure ?

Here is the diagram of K10

https://pt.wikipedia.org/wiki/AMD_K10
https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/AMD_K10_Arch.svg/300px-AMD_K10_Arch.svg.png

And here are the instructions

http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

Llano have 2 128bit pipes capable of SSE (up to 4.1) per core, while BD only have 2 128bit pipes per 2 cluster/cores... this in the context of FLOPS or FP ops ... And while a SSE instruction can have up to 4x 32bit FP "numbers" its only on the context of SIMD, same instruction doing the same simple operations on those numbers, its not that terrible useful. SSE doesn't have multiply accumulate, in terms of pure logic operations is only one at a time, a mul or an add. And though theoretically Llano has double the FLOP rate of BD, because of 2 128pipes per core against 2 per 2 cores (module) of BD, is not because of that performance is better than BD. The contrary, most most of times is worst. ( the FMISC in Llano K10 is identical to one of the MMX pipes in BD, and the other MMX pipe in BD also doesn't do FP ops )

So theoretically peak rates most of times can be quite deceiving... only to entertain morons.

SSE floating point

Floating point instructions

* Memory-to-register/register-to-memory/register-to-register data movement
--- Scalar– MOVSS
--- Packed – MOVAPS, MOVUPS, MOVLPS, MOVHPS, MOVLHPS, MOVHLPS
* Arithmetic
--- Scalar – ADDSS, SUBSS, MULSS, DIVSS, RCPSS, SQRTSS, MAXSS, MINSS, RSQRTSS
--- Packed – ADDPS, SUBPS, MULPS, DIVPS, RCPPS, SQRTPS, MAXPS, MINPS, RSQRTPS
* Compare
--- Scalar – CMPSS, COMISS, UCOMISS
--- Packed – CMPPS
* Data shuffle and unpacking
--- Packed – SHUFPS, UNPCKHPS, UNPCKLPS
* Data-type conversion
--- Scalar – CVTSI2SS, CVTSS2SI, CVTTSS2SI
--- Packed – CVTPI2PS, CVTPS2PI, CVTTPS2PI
* Bitwise logical operations
--- Packed – ANDPS, ORPS, XORPS, ANDNPS (edt)

So has you can see (i hope) 128 GFLOPS at 4 Ghz is only true for a Llano and in the context of not very useful "single precision"... BD rate is half per core... but i wouldn't count to much on them(SSE), FMA4 of BD can provide quite better performance though the theoretical peak is half, more so because BD has the same number of L/S engines of Llano , but quite more advanced, and in real world performance counting real sustained data rates for those SIMDs, BD delivers a beating. Got it now ?

[ i like more to count only real logic ops per vector, so SSE 2, AVX is 2 or 3(FMA) and XOP is 4(FMA)... and count the wide of the issue ports... in that case BD can do 4 ops per 128bit pipe but only with 128bit FMA4... and in this context that Llano chart is very wrong ( the "numbers" in those vectors is not quite that useful)... but believe me THERE IS MORE THAN ONE WAY TO EXTRAPOLATE PEAK FLOP RATES, different vendors use slightly different methods with what they count... YOU ARE WASTING YOUR TIME... and mine... (edt)]

Sorry to be aggressive but this is the last time... don't bother anymore.

 

[juanrga]

Here is the issue with believing it's on bulk:

1.) Kaveri ES's have been on record at Cosmic Labs since February this year.

2.) Bulk process will reduce performance, heat, voltage properties significantly.

3.) If it isn't on SOI, why are they timing it *perfectly* to coincide with when the 28nm FD-SOI production at GF is ramping up?

It doesn't make sense at all...if they were going bulk, we could have Kaveri already in our hands...

My guesstimate here is that, after they tested Kaveri ES's on bulk process, they realized how degraded the performance would be, and how bad it would underperform. So they didn't change their official announcement *just in case* but they are likely planning kaveri to be on FD-SOI going forward because the performance drop off on bulk would be far more drastic than they initially expected.

EDIT: The Opteron roadmap earlier this year did not state that Kaveri was coming Q1 2014, it said 2H 2013 specifically...this, in my mind, means that while there has been a shift of paradigm, the delay is slight, so AMD maintains the perception of "we meant a paper launch all along".

This is all entirely feasible, but there is an alternative explanation.

1) Yes, Kaveri is ready.

2) According to some sources, GloFo has improved the bulk process and the differences with SOI are not so large now. AMD adds:

There are always tradeoff decisions. But the flexibility that we gain moving in that direction... the flexibility across foundry partners, across design tools outhweigh that by far, the benefits of SOI.

3) I am not so sure about timing. According to Glofo, volume production for 28nm SOI starts in 1H 2014. According to AMD, Kaveri will be shipped in 2013 to OEMs and to end-users in 1Q 2014.

AMD vicepresident claims that Kaveri was ready for its original early 2013 launch, and that the delay is due to "HSA's marketing not still ready". I interpret this phrase as saying us that the reason for the delay is that AMD want more HSA software ready at launch.

So wait... you mean to tell me 8350rocks, on multiple threads, was right about a FX 6300/6350 being near i5 level performance? Well, shoot then. (Lol, This guy seems credible to me)

Also, if you look at the benchmarks that have been posted with the FX 6350 in it, I think we see how close this CPU game is about to get, Intel should be slightly worried on the enthusiast side of things. Esp if SteamRoller OC's good.

And some of you might want to check this out...

http://www.forbes.com/sites/jasonevangelho/2013/08/13/can-amds-newest-apu-play-your-favorite-games-without-a-dedicated-graphics-card-part-1/

According to my own estimations the Kaveri CPU (4 Steamroller cores) will be near the performance of the FX-6300. More concretely, I obtain a 97% of the performance

Well, I hope AMD bring out 6/8 core parts in their next generation (and not just 4-core APUs)... Notably, the FX6350 scored best in the most recent games like Crysis 3 - games are defintely heading in the AMD more-cores direction. So if AMD stick with the architecture, and improve efficiency a bit, they could clean up with their next iteration.

Both Berlin and Warsaw probably confirm that there is no 6/8 Steamroller CPUs/APUs. Kaveri comes only as dual/quad.

 

[juanrga]

No. 4SP can be obtained with both FMA4 or SSE2. The difference is that one set provides 2 ops and the other only provides 1 op. It is evident what set is using the above computation. unless you confound both.

You are again confounding modules with cores. Kaveri APU comes with 2C and 4C configurations. It is the possibility of 6C which was droped.

No SSE like AVX1 has up to 2 operands in the same vector instruction, AVX 2 have up to 3 (FMA3) and XOP have up to 4 (FMA4)... the "numbers" that those operations operate in the context of SIMD, is dependent of the "wide" of the vector, but be assured the number of "numbers" is not the most useful ( SSE instructions can have up to 16 byte numbers or 8 16bit short integers "numbers" per vector), but what those operations can do is ... wikipedia it...

You are confounding modules with cores is you...

No. "op" and "ops" do not mean operands, but operations. Learn the terminology before posting more nonsense.

Yes, Kaveri maximum is 2M with its 2 FlexFPU. No, the rate is 128 GFLOP. It is one half in your fantasy. In fact trinity already have 121.6 GFLOP because has a freq. of 3.8Ghz instead of 4.0Ghz

<reintroducing the img tags>

Idiot use your brain. That "CHART" is for a Llano. Integer cluster/cores on AMD BD don't do FLOPS, or are you not sure ?

Here is the diagram of K10

https://pt.wikipedia.org/wiki/AMD_K10
https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/AMD_K10_Arch.svg/300px-AMD_K10_Arch.svg.png

LOL. You are embarrassing yourself more and more....

Good attempt to eliminate the image tags from my message to try to hide your ignorance, but I reintroduced the image tags. The A10-5800k is not Llano, it is Trinity, which is based in Piledriver.

The integer cores don't do FLOPs, Floating Operations are made in the FPU. You were corrected about this before.

Trinity A10 (Piledriver) has 121.6 GFLOP (SP) for the CPU.
Kaveri A10 (Steamrolloer) has 128 GFLOP (SP) for the CPU.

Congrats!! You achieved hafidup levels of insanity. Now go away with your nonsense, trolling, and insults.

 

[Krnt]

I bet Kaveri is going to be bulk since its not being focused for High end, and we will only see SR with over 2 modules at the end of 2014 maybe in SOI for better performance and clockrates.

 

[8350rocks]

I don't see any way that clockspeeds will hold at Vishera/Richland levels going to bulk from PD-SOI. The thermal issues alone are going to make it suffer...we'll see Intel-esque clock speeds if that's actually the case...as Intel has a massive process advantage on bulk substrate. Going away from SOI means giving up any hope they had of Steamroller actually surpassing IB.

FD-SOI is the *only* way that SR will catch IB performance levels...because they could maintain the clock speeds. Look at Jaguar architecture on bulk...anything over 3.0 GHz is a massive headache to engineer, so they simply don't do it. I simply don't see bulk substrate being in the best interests of AMD, and I would be extremely shocked if kaveri launches on bulk. The only way they could even get *close* to the performance would be to go to a FinFET on bulk, and that would be *costlier* than planar FD-SOI for them.

 

[8350rocks]

Ummm...wowzers if true:

http://www.extremetech.com/computing/164209-windows-8-banned-by-worlds-top-benchmarking-and-overclocking-site

tl;dr: MSFT messed up the Real Time Clock in Win 8; if you adjust BLCK in software, Windows can't properly keep time. And since benchmarks use the RTC to figure out how long they ran, HWBot is disqualifying Win 8 from all its benchmarks.

This is significant in impact: Any benchmark taken under Windows 8 is unreliable if this is true.

So...back to trusty Win 7 x64 for benchmarking I guess...

Wow, that's interesting...I used a NB OC on my 8350 to hit 4.4 GHz...guess my PC would be way off if I ran win8.

I hated that OS anyway...still on Win7 64

 

[Cazalan]

AMD vicepresident claims that Kaveri was ready for its original early 2013 launch, and that the delay is due to "HSA's marketing not still ready". I interpret this phrase as saying us that the reason for the delay is that AMD want more HSA software ready at launch.

That's pure marketing BS. Chicken-n-egg conundrum if you delay hardware because of software. Everyone knows you have to have the hardware out well in advance for the software to be written to take advantage of it. Look how long it took AVX/SSE/FMA to actually be used beyond a handful of applications.

I could see them delaying to allow inventories to sell off, like they've done with GPUs and Llano in the past. And possibly delaying if Kaveri requires some new Windows 7/8 patch like Bulldozer did, but purely because of HSA I don't buy it.

 

[Krnt]

Wow, that's interesting...I used a NB OC on my 8350 to hit 4.4 GHz...guess my PC would be way off if I ran win8.

I hated that OS anyway...still on Win7 64

I don't think NB OC will affect the time on W8, the article states that software overclock to the BLCK, wich I don't think many people will use, except for quick testing.

FD-SOI is the *only* way that SR will catch IB performance levels...because they could maintain the clock speeds. Look at Jaguar architecture on bulk...anything over 3.0 GHz is a massive headache to engineer, so they simply don't do it. I simply don't see bulk substrate being in the best interests of AMD, and I would be extremely shocked if kaveri launches on bulk. The only way they could even get *close* to the performance would be to go to a FinFET on bulk, and that would be *costlier* than planar FD-SOI for them.

Well maybe you are aright but for mobile and mid-range it doesn't seem like a bad idea if it can achieve K10 clocks and its IPC matches or even is a little better than K10, it can be good enough for the job.

I don't think we are not going to see any AMD good performer until late 2014 when its more possible that SR on FD-SOI arrives.

 

[rmpumper]

Yes, the first time that you said that Phenom II is better than Piledriver was an anti AMD rant. You repeating it, after being corrected and educated shows that you are here for trolling against AMD.

That's nice. One thing though:

Suddenly your anti-AMD rant does not look that good now...

Saying that Phenom II is better than Piledriver is anti AMD rant? That nice. Go home, troll, you're drunk.

Because of the modular design of BD/PD, they are setup entirely differently.

The STARS architecture is not really on the same playing field. Though you might have a higher maximum IPC per core on STARS (1 FPU per 2 cores with PD and 1 FPU per core with STARS, plus 3 ALUs per core STARS and 2 per core PD)...the reality is the process tweaks on PD allow that architecture to actually accomplish more in the same time frame.

Even 8350rocks agrees that PII has better IPC than Piledriver - I guess he is Intel shill ranting on AMD as well.

 

[de5_Roy]

I don't see any way that clockspeeds will hold at Vishera/Richland levels going to bulk from PD-SOI. The thermal issues alone are going to make it suffer...we'll see Intel-esque clock speeds if that's actually the case...as Intel has a massive process advantage on bulk substrate. Going away from SOI means giving up any hope they had of Steamroller actually surpassing IB.

FD-SOI is the *only* way that SR will catch IB performance levels...because they could maintain the clock speeds. Look at Jaguar architecture on bulk...anything over 3.0 GHz is a massive headache to engineer, so they simply don't do it. I simply don't see bulk substrate being in the best interests of AMD, and I would be extremely shocked if kaveri launches on bulk. The only way they could even get *close* to the performance would be to go to a FinFET on bulk, and that would be *costlier* than planar FD-SOI for them.

oh-kaay... it's bad when amd favorers start posting depressing stuff. kaveri-on-bulk is beneficial for mobile, laptops - where the apus have been aiming from the very begining. i dunno much about bulk vs soi, never paid attention before. but going by the pros and cons discussed by the more knowledgeable ones here, i'd say amd is making the right move. only people miffed by this would be amd dt enthusiasts. who, btw, drive less than 5% of the market.
to repeat, there is no giving up, no dire need to catch up to intel high end, no high perf race.
you all seem to conveniently forget amd's success comes from cheap apus, not FX. making them on bulk helps amd (according to what you guys have discussed, i don't have personal opinion in this).

to experts: afaik, jaguar is designed to be process-portable. is it possible to fab kabini apus on SOI or FD-SOI? if yes, isn't it moot to lament over apus being made on bulk substrate? assuming future apus will be process-portable and anyone from common platform alliance can make them on any of their process and silicon.
who knows, may be this is amd's new mantra: 'since we couldn't beat intel, may as well join them in making apus on bulk silicon. we still got better igpus, woohoo!'

AMD vicepresident claims that Kaveri was ready for its original early 2013 launch, and that the delay is due to "HSA's marketing not still ready". I interpret this phrase as saying us that the reason for the delay is that AMD want more HSA software ready at launch.

That's pure marketing BS. Chicken-n-egg conundrum if you delay hardware because of software. Everyone knows you have to have the hardware out well in advance for the software to be written to take advantage of it. Look how long it took AVX/SSE/FMA to actually be used beyond a handful of applications.

I could see them delaying to allow inventories to sell off, like they've done with GPUs and Llano in the past. And possibly delaying if Kaveri requires some new Windows 7/8 patch like Bulldozer did, but purely because of HSA I don't buy it.

may be the reality is that glofo has screwed up yet again. kaveri moved from 2012 to q1 2014 in the name of 'getting it right'... could be anything from amd clearing unsold pd/trinity/richland to glofo's failure to glofo allocating and prioritizing fab resources for arm socs to amd not being able to prepare software support for hsa and kaveri in time for launch. or all of the above.

 

[noob2222]

Something to think about, when all this talk of AMD abandoning SOI in 2012, GF wasn't planning on doing a 28nm SOI node.

Now they are, so who are they making the fab for? some unkown customer that may want to use some SOI silicon someday?

or a proven customer that knows how to use it already and quite possibly requested it, a customer that paid to get out of a "contract" when you told them you didn't have plans to make 28nm SOI. IE "If your not doing SOI, then what reason do we have to use your fabs?"

originally GF was going to re-do SOI at 20 and 14nm, skipping 28nm. So what happened to make them change their mind?

Here is some of what we actually know:

BSN article publiched in may 2012 stated no SOI.
~ June 2012, STMicro liscenced FD-SOI tech to GF.
jan 2013 ST-Ericsson successfully tested their "prototype" 28nm FD-SOI phone chip @ 2.5ghz.
Aug 2013, ST-Ericsson split up and go their seperate ways.

So ... GF has a 28nm FD-SOI tech node ... and ??? customer(s). This is what speculation is about, seeing what has changed since some "AMD IS ABANDONING SOI" article.

Who wants to bet that AMD would rather have FD-SOI over bulk if its available?

 

[juanrga]

I don't see any way that clockspeeds will hold at Vishera/Richland levels going to bulk from PD-SOI. The thermal issues alone are going to make it suffer...we'll see Intel-esque clock speeds if that's actually the case...as Intel has a massive process advantage on bulk substrate. Going away from SOI means giving up any hope they had of Steamroller actually surpassing IB.

FD-SOI is the *only* way that SR will catch IB performance levels...because they could maintain the clock speeds. Look at Jaguar architecture on bulk...anything over 3.0 GHz is a massive headache to engineer, so they simply don't do it. I simply don't see bulk substrate being in the best interests of AMD, and I would be extremely shocked if kaveri launches on bulk. The only way they could even get *close* to the performance would be to go to a FinFET on bulk, and that would be *costlier* than planar FD-SOI for them.

I think that 4-core Kaveri will be at i5 SB performance level. In some specific benchmark, it could surpass an i5 IB (#), and with HSA software it could surpass an i7 HW, but, in general, the CPU will be at i5 SB level.


# According to my simulations the 4C Kaveri would outperform an i5-3470 in the test John The Ripper.

AMD vicepresident claims that Kaveri was ready for its original early 2013 launch, and that the delay is due to "HSA's marketing not still ready". I interpret this phrase as saying us that the reason for the delay is that AMD want more HSA software ready at launch.

That's pure marketing BS. Chicken-n-egg conundrum if you delay hardware because of software. Everyone knows you have to have the hardware out well in advance for the software to be written to take advantage of it. Look how long it took AVX/SSE/FMA to actually be used beyond a handful of applications.

I could see them delaying to allow inventories to sell off, like they've done with GPUs and Llano in the past. And possibly delaying if Kaveri requires some new Windows 7/8 patch like Bulldozer did, but purely because of HSA I don't buy it.

Disagree. Consoles are an example that show how developers can have the software ready before the hardware starts to ship to final consumers. In fact, AMD is copying this partnership model for the PC.

In my opinion, AMD is trying to correct the mistakes that did when released AMD64. This time, AMD has created a foundation for HSA with the biggest members in the industry (except Intel) joined, and are developing HSA software before the hardware is shipped to final consumers.

This is one example

http://www.pcper.com/news/General-Tech/AMD-HSA-LibreOffice-and-you

http://blog.documentfoundation.org/2013/07/03/amd-joins-the-document-foundation-advisory-board-to-accelerate-libreoffice/

“It is great to work on LibreOffice with The Document Foundation to expose the raw power of AMD GPUs and APUs, initially to spreadsheet users,” said Manju Hegde, corporate vice president, Heterogeneous Solutions at AMD. “Bringing the parallelism and performance of our technology to traditional, mainstream business software users will be a welcome innovation for heavy duty spreadsheet users, particularly when combined with the compute capabilities of the upcoming generation of AMD Heterogeneous System Architecture (HSA) based products.”

“It is exciting to work together with AMD and their ecosystem to take advantage of AMD’s cutting edge innovation right inside LibreOffice,” said Michael Meeks, SUSE Distinguished Engineer and TDF Board Member, “The growth in performance and parallelism available in the GPUs of today, and particularly with AMD’s revolutionary APUs of tomorrow, is something we’re eager to expose to LibreOffice users.”

I bolded the relevant parts that prove my point that AMD and developers are preparing HSA software before Kaveri is in customers hands.

 

[juanrga]

Yes, the first time that you said that Phenom II is better than Piledriver was an anti AMD rant. You repeating it, after being corrected and educated shows that you are here for trolling against AMD.

That's nice. One thing though:

Suddenly your anti-AMD rant does not look that good now...

Saying that Phenom II is better than Piledriver is anti AMD rant? That nice. Go home, troll, you're drunk.

Because of the modular design of BD/PD, they are setup entirely differently.

The STARS architecture is not really on the same playing field. Though you might have a higher maximum IPC per core on STARS (1 FPU per 2 cores with PD and 1 FPU per core with STARS, plus 3 ALUs per core STARS and 2 per core PD)...the reality is the process tweaks on PD allow that architecture to actually accomplish more in the same time frame.

Even 8350rocks agrees that PII has better IPC than Piledriver - I guess he is Intel shill ranting on AMD as well.

No, in the part that you bolded he refers to hypothetical maximum IPC per core. I don't. My point must be similar to the part that you didn't bold, when he writes about the "reality".

Once again, if the Piledriver-based FX, at same clock and number of cores, gives the same performance than Phenom II, and if Piledriver has a 20% penalty due to the shared front-end, then the rest of the chip in the FX is offering about a 20% more performance to compensate.

In any case, Steamroller eliminates the 20% penalty with the improved front-end and this discussion is useless: there is no way that AMD will abandon the good modules design and will release new Phenoms; it doesn't make any sense.

 

[etayorius]

There is yet another rumor stating that AMD MAY have abandoned AM3+ and release a High End CPU in FM2+ socket, if this is true i will surely get and FM2+ board:

http://www.bitsandchips.it/9-hardware/3234-il-socket-am3-sembra-sia-giunto-al-capolinea

This is just another rumor, but GOD i hope it is true!

 

[sarinaide]

I thought we are in the know that AMD are not making an enthusiast level chip ala FX or Phenom again, put simply there is no market for it and if Kaveri is strong enough you don't need more. Looks like end of the line for AM3+ and about time, 4-5 year old tech expect 4-5 year old performance.

 

[8350rocks]

I thought we are in the know that AMD are not making an enthusiast level chip ala FX or Phenom again, put simply there is no market for it and if Kaveri is strong enough you don't need more. Looks like end of the line for AM3+ and about time, 4-5 year old tech expect 4-5 year old performance.

Well, the platform is officially supported through 2015...so they must be doing something with it...