Moderátoři: flanker, Eddward, Baneshee
.
Doufám jen, že to nebude nakonec nějaký vtípek 
uz len samotna cena hovori o tom ze to ziadny neocakavane vysoky vykon nebudeWILLLESS píše: Navíc je vždy lepší překvapit neočekávaně vysokým výkonem než neočekávaně nízkým
When you're not able to increase the IPC on your current µarch, you must use faster clocks to increase the performance. In order to use faster clocks, you need an high throughput engine and remove all bottlenecks in your frontend. Sometimes you need to do some horrible things to achieve this like putting your L1 in Write-Through while trying to amaze ppls with "ultra high bandwidth" FP/SMD units... even if you're not able to feed them correctly with your decode/dispatch unit in all cases. Finally, you'll get a decent CPU, but only at very high frequency and with a LOT of power to dissipate. Worst of all : when your process is not able to give you high yields, you must launch it at low freq.
Say hello to Netburst....
...and Bulldozer ?
Hi guys,
Just a note to tell you I just changed some steps of the internal validation check. Now, to get your dump validated, you need a clean frequency over time ("time" is, of course, not an hour but 2-3 seconds max.). This was added in order to reject all dumps where the CPU was throttling or unable to keep its rated frequency more than some milliseconds. Some guys spammed the validation key as long as needed to get a result "validated". We don't think a quarter second frequency might be called a "validated overclocking", so I added that check.
This issue is mainly affecting AMD K10 CPU (Intel doesn't seems to be concerned). No problem found so far with the Bulldozer OC Contest currently in progress.
PS : many bogus dumps were removed from world records.
propadák to určitě nebude, pokud je v průměrném výkonu rychlejší jak Phenom II (což je) tak je mise splněnaHEAD píše:Kde berete tu jistotu, ze to bude propadak?Krom testu od obra sem nevidel zadnej jinej benchmark.
Spíše jde o to, že ten kódový název procesoru způsobil zbytečný hype ohledně výkonu. Navíc u BD ještě pořád existují rezervy v dalších revizích, v 32/28nm procesu a budoucím refresh architektury (piledriver), zatím co SB u Intelu už jde s efektivitou výkonu na jádro "na krev" a můžou už spíše jen zvedat frekvence. (výsledky SB-E nejsou moc přesvědčivé) 
(převzato z XS)...
http://twitter.com/#!/AMD_Unprocessed/s ... 5834128385 
, to je zcela irelevantní, pod LN2 spotřebu nikdo neřeší a pro informaci nejvyšší spotřebu pod Ln2 mají Gulftowny. LN2 je o rekordech a o jisté prestiži (být viděn na akcích).
What did happen is that management decided there SHOULD BE such cross-engineering ,which meant we had to stop hand-crafting our CPU designs and switch to an SoC design style. This results in giving up a lot of performance, chip area, and efficiency. The reason DEC Alphas were always much faster than anything else is they designed each transistor by hand. Intel and AMD had always done so at least for the critical parts of the chip. That changed before I left - they started to rely on synthesis tools, automatic place and route tools, etc. I had been in charge of our design flow in the years before I left, and I had tested these tools by asking the companies who sold them to design blocks (adders, multipliers, etc.) using their tools. I let them take as long as they wanted. They always came back to me with designs that were 20% bigger, and 20% slower than our hand-crafted designs, and which suffered from electromigration and other problems.
Tak to je v tom pripade ve fyzickem navrhu bug, ne?del42sa píše:v reálu se to CPU chová trochu jinak než na simulacích...
"The parasitic, umm, characterization from our foundries and the tools and the reality are simply not related. At all. We found that a major breakdown between the models, the tools and reality."
yuri: K10 sice měla 3 ALU, ale zase jen 2way L1D, takže třetí int pipe tam byla spíš jen "do počtu". Imho K10 měla ještě řadu dalších neduhů, ale nikdo už je nevylepšoval. Proč?xsecret:
The real world strange performances of BD seems to come from major changes in instructions throughput. Some of them are much (much) faster than Thuban, some other are much (much) slower. So depending on which instructions are used by the benchmark/software, you will get various results. Use FDIV and you'll see major gain, use FCOS and that will sux more than a Prescott. Something is wrong in µops decoding on many instructions.
