Lol,you can't get more then 100% usage out of one core,the only way to gain from SMT is if one single thread can't use all available instructions of the core,if your single software thread looses say 20% of IPC due to cache stalls or branch misses or whatever then the SMT thread can use (up to) this 20% to run,the whole is never above 100% of what the core can do,you can only go over what the software thread is able to use.Besides Clark stipulated that in ST the thread would benefit from all ressources, because it s obvious that in SMT the first thread lose throughput but that the sum is superior to a single thread throughput, that s not documented but Intel s HT doesnt work by providing 30% higher throughput over say 100% throughput of a single thread, reality is that the second thread eat in the first thread throughput and that with HT the repartition is rather 90 + 40 and not 100 + 30.
If your "estimation" was right it would mean that AMD s SMT bring 85-90% gain in Blender, and generaly 19% more gain than Intel s HT, as you can see previsions based on wishfull thoughts end being fairy tales.
Maybe I didn't understand your point, but this is a simplistic form of my view here:It's not 40% faster,it's 40% more IPC,that's throughput not speed,it will only be 40% faster if you actually find a software that will be able to use all 10 instructions the ZEN core has available per cycle.
Especially in Blender those threads are roughly doing the same kind of work. Without any prioritization the threads would be more like 65+65 in your scenario then.Besides Clark stipulated that in ST the thread would benefit from all ressources, because it s obvious that in SMT the first thread lose throughput but that the sum is superior to a single thread throughput, that s not documented but Intel s HT doesnt work by providing 30% higher throughput over say 100% throughput of a single thread, reality is that the second thread eat in the first thread throughput and that with HT the repartition is rather 90 + 40 and not 100 + 30.
Lol,you can't get more then 100% usage out of one core,the only way to gain from SMT is if one single thread can't use all available instructions of the core,if your single software thread looses say 20% of IPC due to cache stalls or branch misses or whatever then the SMT thread can use (up to) this 20% to run,the whole is never above 100% of what the core can do,you can only go over what the software thread is able to use.
40% is the gain on a single thread if the single thread can use all 10 instructions,it's the same thing I said.
This is the throughput of one single thread running on one single core.
Without any prioritization the threads would be more like 65+65 in your scenario then.
Let's talk responsiveness.
You are talking about how code runs,where did anybody from AMD said that (all) code will run with 40% more IPC? All they said was that the core will have 40% more IPC.Maybe I didn't understand your point, but this is a simplistic form of my view here:
For ST (@iso freq):
T'put = #inst./cycle
Speed= #inst./cycle
And who said, that in real ST code XV constantly maxes out an IPC of 7.0 (2ALU+2AGU+3FP)? Why would a SW need to reach 10 ops/clock if in reality the value is more like 1.0 to 3.0, sometimes higher
SMT would bring 0% gain if there where any perfect software that would always be able to use all available instructions.Who said that it s 100% usage that i was talking about..?.
If a thread is at say 100 and SMT bring another 30 then it s obvious that in ST the core wasnt at 100%, i m talking of % relative to the first thread output, if the first thread is at 100% then it will be at 90% if a second thread is processed, there s no way that the second thread wont reduce the first thread throughput.
Lol, that s complete non sense, if that was the case there wouldnt be a single instance where they could say that it has 40% higher IPC, and even if they did as you re stating then SMT would bring 0% gain, hey, it s already fully maxed to get thoses 40% according to you, lol.
He said 40% with the first thread and SMT will come on top.
You are talking about how code runs,where did anybody from AMD said that (all) code will run with 40% more IPC? All they said was that the core will have 40% more IPC.
And that's all I'm saying too,if a thread can (could) use 10 IPC per core then it would gain 40% in execution speed.
There is nothing to be measured with applications,construction cores have 4 integer + 2 FPU instructions per core=6 IPC, zen will have 10 IPC.And you think that they measured this IPC increasement how..?.
Without using applications.?.
It is well below Broadwell since it only has 8 instructions per core while ZEN has 10.You are wrong, one more time, if what you said was right then it would mean that the max theorical throughput has increased by 40%, wich would mean that it would have been well below BDW in the Blender demo they displayed,.
Yup,just like with the FX before it,it will only be checked with distributed computing software or GPU benchmarks, both of wich are prime candidates for being able to use all available throughput making it look fast.indeed they couldnt even state 40% better IPC in the case you re stating, because what matters is the IPC improvement in real apps, and they perfectly know that this will be checked once the chip launch.
It has to be seen, whether OS thread priorities will be involved here, additionally to doing live performance metric evaluation to adjust thread execution.Indeed, but then prioritization cant be done on a cycle per cycle basis, so there will be instances where the second thread will cause the first thread to lose a few cycles here and there, as said if the first thread has a throughput of 100 and that SMT bring 30 then with two threads the respective throughputs will be something like 90 + 40, this can be seen on some games where Intel HT reduce perfs.
Of course I am. I don't know if there is much use in such a metric and in reduntantly calling it "IPC", if there are simple metrics like "issue width", "decoding rate" etc.You are talking about how code runs,where did anybody from AMD said that (all) code will run with 40% more IPC? All they said was that the core will have 40% more IPC.
Please check your definition of IPC. And I'm interested in where you are seeing something in Zen being 1.4x that of XV.And that's all I'm saying too,if a thread can (could) use 10 IPC per core then it would gain 40% in execution speed.
Don't forget that intel raised IPC for many gens without raising execution units,that's software IPC (or CPI how many cycles it takes for an instruction to finish) how much of the available IPC software can use,AMD only talked about hardware IPC how many instructions are available on the core (literally, they said 40% more IPC per core).
Exactly, there is no such SW.SMT would bring 0% gain if there where any perfect software that would always be able to use all available instructions.
Since there is no such software you often have some improvement.
If you have one thread running with real-time priority on a core then it should not loose any speed if you run a second thread through SMT with low priority.
But still it does not matter,the maximum you can get out of a core is the maximum amount of instructions it has available,it doesn't matter how you split it up.
Yup,just like with the FX before it,it will only be checked with distributed computing software or GPU benchmarks, both of wich are prime candidates for being able to use all available throughput making it look fast.
It is well below Broadwell since it only has 8 instructions per core while ZEN has 10.
Please check your definition of IPC. And I'm interested in where you are seeing something in Zen being 1.4x that of XV.
.
There is nothing to be measured with applications,construction cores have 4 integer + 2 FPU instructions per core=6 IPC, zen will have 10 IPC.
It is well below Broadwell since it only has 8 instructions per core while ZEN has 10.
.
IPC usually means measured intructions per clock over several cycles (e.g. 1M, or all cycles of an application run), not "issue width", which is kind of a peak value, as the decoders and µOp$ simply can't provide enough instructions per cycle.There is nothing to be measured with applications,construction cores have 4 integer + 2 FPU instructions per core=6 IPC, zen will have 10 IPC.
It is well below Broadwell since it only has 8 instructions per core while ZEN has 10.
In a thread, which is being read by less tech savvy people, I think, it is important not to simply leave wrong statements as they are.That 1.4x is the result of random logic, you shouldnt even waste your time asking for explanations since there s none.
Notice that we are told that Cat cores are 6 IPC while Zen is 10 IPC and hence only 66% better at best, but of course that BDW is only 8 IPC doesnt mean that it s only 30% better than the Cat cores, it s all a question of perspective and double standard since we are also told that BDW s 8 IPC is above Zen s 10 IPC...
Sometimes even smart people might run into kind of a dead end, thought-wise. Then it might help to take them out of their seat, shake them a bit, and put them back in place. Or alternatively, one might kindly ask them to step back and check their POV.If that s not trolling, then what is it..
No one knows everything, certainly.Sometimes even smart people
IPC usually means measured intructions per clock over several cycles (e.g. 1M, or all cycles of an application run), not "issue width", which is kind of a peak value, as the decoders and µOp$ simply can't provide enough instructions per cycle.
In a thread, which is being read by less tech savvy people, I think, it is important not to simply leave wrong statements as they are.
BTW, here is Jaguar's (and Bobcat's) IPC for applications (whatever they are):
Sometimes even smart people might run into kind of a dead end, thought-wise. Then it might help to take them out of their seat, shake them a bit, and put them back in place. Or alternatively, one might kindly ask them to step back and check their POV.
I took an XV @ 4.2GHz (A12-9800), multiplied all Geekbench 4 sub-scores by 1.4, and compared the subscores to a Broadwell-E 6950X @ 4.2GHz (stock L3$). Here's what I got.
I would suggest you use the Core i3 6100 instead, A12-9800 is an APU with L2 cache only at 65W TDP when BD-E 6950K is a L3 25MB at 140W TDP SKU.
Take in care something... some instructions doesn't have Excavator while Zen is supposed to have. That would change the results in some aspects.I took an XV @ 4.2GHz (A12-9800), multiplied all Geekbench 4 sub-scores by 1.4, and compared the subscores to a Broadwell-E 6950X @ 4.2GHz (stock L3$). Here's what I got.
I would suggest you use the Core i3 6100 instead, A12-9800 is an APU with L2 cache only at 65W TDP when BD-E 6950K is a L3 25MB at 140W TDP SKU.
I'd expected some ratio: % of max possible, not of all.Are the last two columns the mean percentage of gates not clocked during the time period? Are these numbers applicable on Zen (maybe even better)? If yes, these numbers are quite interesting. They say that even a power virus leaves most of the transistors off... So the clock gating has reached a very interesting efficiency. And since the leakage on 14nm FF LPP is VERY low compared to 28nm BULK, this can mean very low power consumption for Zen core, since clock gated transistors only draw leakage power...