Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: nVidias "Denver" ARM-Cores sind 7fach skalar & sollen sich mit ...
Leonidas
2014-08-20, 12:58:36
Link zur News:
http://www.3dcenter.org/news/nvidias-denver-arm-cores-sind-7fach-skalar-sollen-sich-mit-haswell-anlegen-koennen
Würde euch ein ARM-Gerät als PC langen? (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=555653)
Undertaker
2014-08-20, 16:58:15
Es gibt durchaus passiv kühlbare Haswell-Prozessoren und auch entsprechende Produkte auf dem Markt. Z.B. mit dem i5-4202Y.
So riesig ist die Architektur nicht, Apples ARMv8-Arch "Cyclone" ist mit 9 Ausführungseinheiten noch größer:
http://www.elektroniknet.de/halbleiter/prozessoren/artikel/107338/
Oberst
2014-08-20, 20:59:08
Wenn man bei Notebookcheck mal die Cinebench11.5 (Multi) Werte des Celerons (1,14) mit anderen SoCs vergleicht, fällt auf, dass der AMD A10 Micro 6700T mit 1,5 Punkten fast 50% schneller als der Celeron ist.
Beim Verbrauch ist der AMD vermutlich auch nicht schlechter als der Tegra, entsprechend dürfte Tegra nicht unbedingt so überragend vor allen anderen SoCs liegen, wie NV hier hofft.
Undertaker
2014-08-20, 21:17:58
Der Celeron ist nun auch nicht gerade das Paradebeispiel für die MT-Performance (die bei einem Zweikerner eh nicht im Fokus steht). Ein Atom Z3795 kommt auf rund 1,65 Punkte, ein i5-4202Y auf 1,85 Punkte. Alles passiv in realen Endprodukten wohlgemerkt.
Beim Verbrauch ist der AMD vermutlich auch nicht schlechter als der Tegra
Der A10 fällt nach PCMark-Screenshots bei längerer CPU-Auslastung auf 1,2 GHz, das spricht für eine sehr starke TDP-Überschreitung in kürzeren Tests. Für genauere Analysen bräuchte es aber endlich mal unabhängige, tiefgehende Reviews...
Ein zweites wichtiges Feature ist die Ausweitung des Code-Cachings unter dem Featurenamen "Dynamic Code Optimization". Den vorliegenden Microcode zu analysieren, zu optimieren und zwischenzuspeichern wird von allen modernen CPUs (inklusive ARM) beherrscht, ...
Bitte?
Das macht keine heutige CPU!
Das machen bestenfalls GPU Treiber die shadercode optimieren, aber das machen CPUs nicht!
Es geht hier nicht um OoO execution, bei denen Befehle (eventuel spekulativ) im Voraus abgearbeitet werden und auch nicht um sprungvorhersagen oder desgleichen.
Es geht um PGO (profile guided optimizations), das ist was was compiler machen, siehe: http://msdn.microsoft.com/de-de/library/e7k32f4k.aspx
Dabei wird ein Program(teil) mit performance-markern bzw countern ausgestattet und nach einer gewissen Zeit kommt ein JIT dran der den Code anhand der GPO daten 're-compiliert'. das ist kein winziges OoO window wo 100 instruction in-flight sind oder jump prediction counter.
Deswegen zeigen sie als Benchmark auch sowas eigentlich unnutzes wie "memcpy", das ist trivial code den man seit 20Jahren kaum besser machen kann ausser mit CPU spezifischen instructions bzw. DMA oder desgleichen. wenn nun der JIT rausfindet dass ein teil der instruktionen einfach nur daten schiebt, kann die cpu mit idle-state operationen versorgt werden und der controller die daten verschieben.
1. kann die CPU das eh nicht schneller als der controller sie bedient
2. der controller verbrauch sehr viel weniger strom, die CPU hat ein cool down und kann die ersten paar neuen instruktionen dann mit peak turbo abarbeiten.
Es wird leider dieselben Probleme geben wie mit treibern
1. nicht triviale compile bugs beim optimieren
2. verlust der kontrolle (heisst: mal ist es schnell, mal langsam, je nachdem, ob eine stohastic im treiber den fall erkennt und als wichtiger als andere bewertet)
(lustigerweise war das auch eine geheimwaffe von javaVMs seit dem ersten tag, aber wird bis heute nicht verwendet (ausser bei einer sun server-JVM version, da der
1. PGO lauf erstmal langsammer ist und was wenn der code nie wiederverwendet wird?
2. optimierungen jittern, genau wie garbage collections oder driver threads wenn die cpu voll ist
3. wenn sich der Kontext switcht (sprich, andere Daten), bleibt das unbemerkt und die 10% optimierung kann 50% langsammer sein im neuen Kontext.
)
Das is interesant, also haben die einen Transcompiler eingebaut. Hat NVidia auch ein eigenes ISA?
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.