Archiv verlassen und diese Seite im Standarddesign anzeigen : CPU- vs. VGA-Power
_DrillSarge]I[
2007-09-18, 18:29:45
oder warum hängt die CPU-Entwicklung der GPU-Entwicklung so hinterher?
Mir ist aufgefallen, dass bei CPUs die Entwicklung ziemlich abstinkt gegnüber des fast halbjährlichen Produktzyklusses bei Grafikchips. Warum? Es gibt zwar jetzt 2- und 4 Kernprozessoren, doch irgendwie hat sich nicht wirklich viel getan. Es gibt keine richtigen technologischen Sprünge wie beispielsweise von DX Version zur nächsten. 64bit wird nur stiefmütterlich behandelt (egal ob von den Soft-/Hardwareherstellern), es fehlen neue Instruktionssätze. Ich habe das bemerkt, da ich mit einem übertakteten Barton fast alles flüssig spielen kann. Gut modernere Prozessoren sind deutlich leistungsstärker, aber die Leistung ist nicht in dem Maße gewachsen wie bei GPU. Man stelle sich vor Athlon Xp (Barton) und Geforce5 sind ungefähr gleich erschienen und mit letzterer kann man heute wenig anfangen.
Das kann ich dir mit einem Satz beantworten.
Grafik lässt sich wunderbar automatisch parallelisieren, normale Programme nicht.
I[;5853954']
Mir ist aufgefallen, dass bei CPUs die Entwicklung ziemlich abstinkt gegnüber des fast halbjährlichen Produktzyklusses bei Grafikchips.
Das war mal.
Leider ist der G80 jetzt schon seit fast einem Jahr die Leistungspitze. Mit der Ultra gab es nur eine minimale Beschleunigung nach einem halben Jahr.
Dumm nur wer (wie ich) den G80 nicht mag...
Die CPU Entwicklung in jüngster Vergangenheit ist da viel flotter.
_DrillSarge]I[
2007-09-18, 18:42:29
Das war mal.
Leider ist der G80 jetzt schon seit fast einem Jahr die Leistungspitze. Mit der Ultra gab es nur eine minimale Beschleunigung nach einem halben Jahr.
Dumm nur wer (wie ich) den G80 nicht mag...
Die CPU Entwicklung in jüngster Vergangenheit ist da viel flotter.
den höhepunkt der cpu entwicklung (geschwindigkeit), sah ich bei erst bei athlon&duron vs. Pentium&celeron und athlonxp vs. p4 / Ghz-wahn. amd hat sich ja jetzt lange zeit auf ihren athlon64 ausgeruht und intel ledeglich den c2d nachgeschoben.
BlackBirdSR
2007-09-18, 18:48:18
I[;5854001']den höhepunkt der cpu entwicklung (geschwindigkeit), sah ich bei erst bei athlon&duron vs. Pentium&celeron und athlonxp vs. p4 / Ghz-wahn. amd hat sich ja jetzt lange zeit auf ihren athlon64 ausgeruht und intel ledeglich den c2d nachgeschoben.
Sehe ich nicht so. Gerade was Leistung und Funktionen angeht haben die µArchitekturen geradezu gigantische Sprünge nach Vorne gemacht. Auch in Sachen Leistung und Transistorzahl tut sich sehr viel. Die Richtung stimmt immernoch, und wir bewegen uns immernoch ungebrochen steil nach oben. Nur die Taktraten stagnieren seit einigen Jahren, das hat allerdings dem Wahn nach mehr Komplexität noch nicht groß geschadet.
Vielleicht merkt man als Enduser und Gamer wenig davon. Hinter den Kulissen funktioniert die Sache aber immernoch wie zu Zeiten des PentiumPro oder K7.
Der Vergleich wirkt nur so krass, da sich GPUs ungleich brutaler entwickelt haben.
_DrillSarge]I[
2007-09-18, 18:50:28
Der Vergleich wirkt nur so krass, da sich GPUs ungleich brutaler entwickelt haben.
das kann natürlich auch ein grund sein. irgendwie denke ich, das man mit der jetzigen fertigungstechnologie (strukturbreite, material) ziemlich am ende der fahnenstange ist oder?
_DrillSarge]I[
2007-09-18, 18:52:53
Das kann ich dir mit einem Satz beantworten.
Grafik lässt sich wunderbar automatisch parallelisieren, normale Programme nicht.
was ist dann mit sachen wie cell/ die drei(?) xbox 360cpu`s oder den neuen sparc`s ?
irgendwas muss ja doch zu parallelisieren sein.
I[;5854029']das kann natürlich auch ein grund sein. irgendwie denke ich, das man mit der jetzigen fertigungstechnologie (strukturbreite, material) ziemlich am ende der fahnenstange ist oder?
Nicht bei der jetztigen Intel Roadmap ;)
Es gibt auf jeden Fall in den nächsten Jahren noch einige Shrinks bis 11nm.
BlackBirdSR
2007-09-18, 18:59:06
I[;5854029']das kann natürlich auch ein grund sein. irgendwie denke ich, das man mit der jetzigen fertigungstechnologie (strukturbreite, material) ziemlich am ende der fahnenstange ist oder?
95 waren wir bei 5.5M Transistoren
Intel verkauft heute Prozessoren mit 1.3 und 1.7 Milliadren. Ich denke, dass es immernoch steil weiter geht.
Was Cell und die Sparc T1/T2 angeht: Deren Softwarebereich ist ebenfalls hoch parallelisierbar.
_DrillSarge]I[
2007-09-18, 19:01:31
95 waren wir bei 5.5M Transistoren
Intel verkauft heute Prozessoren mit 1.3 und 1.7 Milliadren. Ich denke, dass es immernoch steil weiter geht.
doch der energieverbrauch skaliert ziemlich steil mit steigender transistorzahl. sieht man an den grafikkarten. und will man das mit einem ordentlichen takt garnieren, hat man probleme und sachen wie c'n'q beheben das problem ja nicht.
I[;5854035']was ist dann mit sachen wie cell/ die drei(?) xbox 360cpu`s oder den neuen sparc`s ?
irgendwas muss ja doch zu parallelisieren sein.
Das funktioniert aber nicht automatisch wie bei GPUs und Amdahl's Law greift halt bei vielen Sachen doch. Bei GPUs bedeutet doppelter Transistorcount fast automatisch doppelte Leistung, wenn man keine Features hinzufügt. Das ist bei CPUs eben nicht gegeben.
Mehr braucht man dazu einfach nicht sagen.
I[;5854035']irgendwas muss ja doch zu parallelisieren sein.
Tja wenn man ein Rechenergebnis braucht, um das nächste zu berechnen ist nichts mit parallelisieren.
BlackBirdSR
2007-09-18, 19:27:55
I[;5854056']doch der energieverbrauch skaliert ziemlich steil mit steigender transistorzahl. sieht man an den grafikkarten. und will man das mit einem ordentlichen takt garnieren, hat man probleme und sachen wie c'n'q beheben das problem ja nicht.
das ist so falsch, wie man an der Anzahl an Transistoren sieht. Zumal Cache hier ganz anders einfließt.
Auch hier kann man GPUs und CPUs nicht! direkt vergleichen
64bit wird nur stiefmütterlich behandelt (egal ob von den Soft-/Hardwareherstellern)
Nen Core2 dürfte bei native 64Bit ziemlich alt gegen den K8/K10 aussehen.
BlackBirdSR
2007-09-18, 21:05:52
Nen Core2 dürfte bei native 64Bit ziemlich alt gegen den K8/K10 aussehen.
Und warum sollte das so sein? Da müssen schon Gründe Erklärungen her. Ich behaupte nämlich, dass dies fundamental falsch ist.
Und warum sollte das so sein? Da müssen schon Gründe Erklärungen her. Ich behaupte nämlich, dass dies fundamental falsch ist.
Also es wird schon nen Grund geben warum Intels SPEC-Ergebnisse alle @32-Bit sind :wink:
Aber so spontan fällt mir folgendes ein.
Bei 64-Bit und SSE steigt die Opcodelänge von ca. 2-3 Bytes auf durchschnittlich 4Bytes
->Core2 stärker durch Stalls betroffen weil ein Decoder mehr
MacroOP-Fusion funktioniert nur bei 32-Bit (bringt ca 5%)
Laut AMD damals vergrößert x86-64 den Code nur um 10%. Ich weiß aber nicht was dran ist.
So schlecht ist Core 2 unter 64-Bit aber nicht. Er hat ja auch den Vorteil von weniger Speicherzugriffen durch mehr Register.
BlackBirdSR
2007-09-18, 21:54:38
Hier gibts Benchmarks:
http://www.xbitlabs.com/articles/cpu/display/core2duo-64bit_2.html#sect0
Natürlich hat AMD wahrscheinlich die beste Implementation von AMD64. Allerdings ist der Vorsprung des Core2 gegenüber des K8 einfach zu hoch um einen Unterschied zu machen. Ich gehe auch davon aus, dass der K10 dadurch nicht plötzlich vorne liegt.
Von "alt aussehen lassen" kann also keine Rede sein.
Interessant ist übrigens wieviel der Prescott immer dazugewinnen kann ;)
Damit wäre das Märchen, dass ein K8 von 64bit stärker profitiert als Core2 vom Tisch. :)
ok, "alt aussehen" war übertrieben,
das die K10-Architektur mehr aus 64-Bit rausholt, wollte ich eig. schreiben
und was SiSoft Sandra bencht :tongue:
Wenn schon dann SPEC Ergebnisse. (Da schlägt nen 2x4 K10 2.0Ghz übrigens 2x4 Xeon X5365 3.0Ghz in fp_rate)
Und warum Intel als Einziger im Server-Bereich immernoch 32-Bit kompiliert, ist trotzdem ne gute Frage
Wenn schon dann SPEC Ergebnisse.
Die wenigsten hier dürften sich für Server Benches interessieren. ;)
fp_rate ist nur vollkommen uninteressant.
Die wenigsten hier dürften sich für Server Benches interessieren. ;)
Spec ist kein Server-Bench.
fp_rate ist nur vollkommen uninteressant.
:confused:
fp_rate ist viel zu künstlich, so einen Load hast du unter realen Bedingungen nicht.
ich finde die Benches zeigen ganz gut zu was MultiCore und effiziente 64-Bit Nutzung im Stande sind. Um neue Technologien ausreichend nutzen zu können
müssen halt auch die Programmierer umdenken. Es nützt eben nicht mehr als 10% den alten Code durch nen neuen Compiler zu jagen.
(del)
2007-09-18, 23:58:44
Was du nicht sagst. Momentan scheinen die Programierer aber noch nicht wirklich so recht was sie denken und wie umdenken sollten, um zB. Kollisionen sicher aus dem Weg zu gehen. du darfst von einem 'von sich behauptenden' guten Handwerker alles verlangen. gib ihm aber erstmal brauchbare Werkzeuge.
Es reicht nicht multicores auf den @home-Markt hinzuklatschen un den hier :| Richtung Programmierer zu richten.
ich finde die Benches zeigen ganz gut zu was MultiCore und effiziente 64-Bit Nutzung im Stande sind. Um neue Technologien ausreichend nutzen zu können
müssen halt auch die Programmierer umdenken. Es nützt eben nicht mehr als 10% den alten Code durch nen neuen Compiler zu jagen.
Nein du verstehst mich nicht. So einen Workload bekommst du auch unter den tollsten Bedingungen mit realen Programmen nicht.
Das ist völlig synthetisch.
Es reicht nicht multicores auf den @home-Markt hinzuklatschen un den hier :| Richtung Programmierer zu richten.
Es gibt einen Faktor "Zeit"
Kein Wunder das viele Programme schlimm verbugt sind :)
Nein du verstehst mich nicht. So einen Workload bekommst du auch unter den tollsten Bedingungen mit realen Programmen nicht.
Das ist völlig synthetisch.
Das war ja auch schon die Diskussion beim Pentium4 weswegen unter anderem HT eingeführt wurde.
Ich kann nur soviel sagen, das durch geschickte Programmierung zumindest
in rechenintensiven Loops 80-90% Auslastung erreicht werden können.
Darum ging es mir ja in meiner Argumentation auch, das ein Core2 eben
bei hoher Auslastung unverhältnismässig oft wartet bei 64-Bit.
Das hat natürlich nix mit Spielen (eher Integer) oder dergleichen zu tun.
das ein Core2 eben
bei hoher Auslastung unverhältnismässig oft wartet bei 64-Bit.
Auf was wartet er?
Beweise?
In einer CPU limitiert doch immer eine Einheit ...
del_4901
2007-09-19, 00:16:31
Ich kann nur soviel sagen, das durch geschickte Programmierung zumindest
in rechenintensiven Loops 80-90% Auslastung erreicht werden können.
Darum ging es mir ja in meiner Argumentation auch...
Ohne Beispiele ist deine Argumentation nen Scheiss wert. Also Beispiele für so einen loop bitte.
BlackBirdSR
2007-09-19, 00:35:03
Ohne Beispiele ist deine Argumentation nen Scheiss wert. Also Beispiele für so einen loop bitte.
Ein bischen freundlicher gehts schon oder? Danke.
@Gast: Gilt auch für dich!
@pest: Kann schon hinkommen. Allerdings sagst du ja selbst, dass es für Spiele und die meisten Anwendungen wenig ausmacht.
Intel wird sicher Grund haben, warum die höchsten Ergebnisse 32Bit sind. Und wenn auf diesem Planeten etwas bis zum Verrecken optimiert ist, dann der Spec-Compiler. Ich denke da widerspricht mir niemand ;)
Ich glaube niemand will sagen, dass Intel die 64-Bit Implementation perfekt hinbekommen hat. Die Benchmarks zeigen (ich ignoriere Sandra aus gutem Grund), dass es mal hin mal her geht. Aber bei normalen Programmen scheint es sich nicht zu sehr auszuwirken. Ich schätze einmal, dass Spiele das gar nicht richtig mitbekommen. Deren Workload ist meist so lächerlich unoptimiert und gugriffslimitiert, dass eine maximale Auslastung des Front- und Backends wohl sehr unwahrscheinlich ist. Wie Coda bereits sagte, ist da jeder Registerzugriff ein Segen, und davon gibt es im 64Bit Modus ja ein paar mehr für GPRs.
Die geforderten Beweise anhand von Codebeispielen kannst du gerne noch bringen. Aber ich glaube dir, und sehe die Logik darin auch. Ist ja nichts wirklich Unbekanntes bisher.
Nehmen wir an, der K10 baut auf AMDs Bestrebungen auf und macht dies und das noch etwas besser, dann erwarte ich aber auch von Intel, dass man mit Penryn, spätestens Nehalem einige Probleme abschwächt. Es dürfte sich also trotzdem nicht viel ändern. Und das "alt aussehen" war ja mein einziger Kritikpunkt ;)
Update: tecchannel hat übrigens 64Bit Benches mit Spec2006 und da liegen die neuen Xeons durch Cache und Umfeld vorne
Die geforderten Beweise anhand von Codebeispielen kannst du gerne noch bringen. Aber ich glaube dir, und sehe die Logik darin auch. Ist ja nichts wirklich Unbekanntes bisher.
geschickte Programmierung=Assembler ;-) -> wenig Praxistauglich
ich weiß nicht ob es was bringt wenn ich jetzt MMX-Code oder so poste
der C-Code um Faktor 10x beschleunigt, wir sind uns ja mittlerweile einig
hier noch ein Link der das Fehlen von MacroOP-Fusion beim Core2 64-Bit demonstriert
http://www.xcpus.com/forums/benchmarks/25-superpi.html
Update: tecchannel hat übrigens 64Bit Benches mit Spec2006 und da liegen die neuen Xeons durch Cache und Umfeld vorne
meinst du den?
http://www.tecchannel.de/schwerpunkt/SPEC-CPU2006.html
finde da leider keinen Opteron 2350 oder Xeon X5365
_DrillSarge]I[
2007-09-19, 15:06:39
das ist so falsch, wie man an der Anzahl an Transistoren sieht. Zumal Cache hier ganz anders einfließt.
Auch hier kann man GPUs und CPUs nicht! direkt vergleichen
sicher. doch der energieverbrauch wird mit den multicores rapide ansteigen. da kann man immer was erzählen von zB 30% höherer Leistung/watt o.ä., aber wenn eine cpu mit 4 kernen das 4-fache einer singlecore-cpu verbraucht (simplifiziert!), dann ists ja faktisch trotzdem ein horrender energieanstieg.
was ich meine, das man neue befehlssätze viel mehr integrieren sollte. warum nicht vieles hardwired verwenden? sowas kann in vielen situationen zu drastischen performancegewinnen führen. sicher, es kann auch null bringen, aber besser als nix. es wird sich einfach zuviel auf die "alten" befehlssätze verlassen.
BlackBirdSR
2007-09-19, 16:11:03
I[;5856435']sicher. doch der energieverbrauch wird mit den multicores rapide ansteigen. da kann man immer was erzählen von zB 30% höherer Leistung/watt o.ä., aber wenn eine cpu mit 4 kernen das 4-fache einer singlecore-cpu verbraucht (simplifiziert!), dann ists ja faktisch trotzdem ein horrender energieanstieg.
was ich meine, das man neue befehlssätze viel mehr integrieren sollte. warum nicht vieles hardwired verwenden? sowas kann in vielen situationen zu drastischen performancegewinnen führen. sicher, es kann auch null bringen, aber besser als nix. es wird sich einfach zuviel auf die "alten" befehlssätze verlassen.
Der Anstieg ist geringer als würde man den Takt steigern.
Und was mein Argument angeht, du hast nicht verstanden wie ich das meinte: Bei GPUs sind zusätzliche Transistoren fast immer Logik und bei Vollast. Bei CPUs ist das völlig anders.
@Gast:
Nein den: http://www.tecchannel.de/server/prozessoren/1729228/
_DrillSarge]I[
2007-09-19, 16:13:32
Der Anstieg ist geringer als würde man den Takt steigern.
aber mehr (viel)takt ist doch zurzeit nicht drin?
Und was mein Argument angeht, du hast nicht verstanden wie ich das meinte: Bei GPUs sind zusätzliche Transistoren fast immer Logik und bei Vollast. Bei CPUs ist das völlig anders.
das verstehe ich nicht^^
BlackBirdSR
2007-09-19, 23:31:36
I[;5856648']aber mehr (viel)takt ist doch zurzeit nicht drin?
das verstehe ich nicht^^
Viel mehr Takt wäre durchaus möglich, wenn man denn wollen würde. IBMs Power6 arbeitet auch mit 4.7GHz. Es ist nur je nach Design nicht immer vorteilhaft den Takt so hoch anzusetzen.
Gerade x86 hat hier oft mit zu hoher Abwärme für den Markt zu kämpfen. Man hätte den Pentium4 auf Biegen und Brechen weiter führen können. Das Design wäre für 10GHz geeignet, keine Frage. Allerdings hat sich gezeigt, dass momentan ein breiteres Design mit mehreren Kernen mehr Performance bringt.
Was die Sache mit den GPUs angeht: Der größte Vorteil und Grund warum die Steigerungen so extrem sind, ist die vorzügliche Parallelität. 4 statt 2 Cluster und schon hat man die Performance fast verdoppelt wenn die Speicherbandbreite stimmt. Und die ist leicht erreichbar. Fast alle eingesetzten Transistoren sind dann auch schwer mit Schalten beschäftigt. Bei 600MHz ist der statische Strom dann noch nicht so wichtig, dynamischeSchaltverluste die eigentlichen Dickmacher.
Bei CPUs ist das viel schwieriger. Viele der eingesetzten Transistoren sind nicht immer damit beschäftgt zu schalten. Statische Verluste machen bereits einen sehr großen Anteil aus. Bei höherem Takt wird dieser Effekt ungleich schlimmer. Dazu die dynamischen Verluste und der Höllenofen ist perfekt.
Allerdings sind Transistoren in CPUs nicht immer nur für Rechenwerke und Ähnliches zuständig. Der größte Anteil an Transistoren in einer CPU wird für Cache verwendet. Dieser hat ungemein niedrigere Verluste. Daher lohnt es sich fast immer, den Cache zu vergrößern. Auch wenn das teuer werden kann.
Eine Dual oder Quad-Core CPU hat also eine Unmenge mehr Transistoren als ein einzelner Kern mit hohem Takt, erreicht aber das Vielfache der Leistung.
Kurzum: Das 4- Fache der Transistoren erzeugt vielleicht die 4-fache Verlustleistung, wird aber durch kleinere Fertigung und viel Cache weiterhin bei ca 100W gehalten. Nur höherer Takt würde die Grenzen viel schneller sprengen.
GPUs dagegen setzen mit jedem Transistor weiterhin unmengen von Verlustleistung um. Deren Wert ist lange nicht mehr bei 100W und steigenden.
CPUs verdoppeln und verachtfachen also die Leistung mit mehr Transistoren und bleiben im Budget, GPUs verlassen momentan eher alle Grenzen.
Die Core2 und K10 Architekturen werden sehr gut in der aktuellen c't verglichen und auch das Thema 64bit behandelt. Der kleine Auszug unten deutet ja schon an welche Architektur in diesem Fall die Nase vorn hat, aber im Desktop-Bereich wird das Thema 64bit wohl auch die nächste Zeit noch keine große Rolle spielen.
"Die gcc-Benchmarks wurden hübsch ordentlich mit den gleichen Standard-Flags mit 64-Bit-Code vermessen, so wie es sich für Server mit 16 GByte Speicher und mehr inzwischen auch gehört. Doch Intel bevorzugt bei SPECint 32-bittigen Code - und das hat seinen Grund nicht allein im Compiler, sondern auch in kleineren 64-Bit-Schwächen der Core-Architektur, wie sie vor allem bei hochoptimiertem Code mit heftigem SSE-Einsatz zu Tage treten (mehr dazu im Architekturvergleich ab S. 170 in c't 20/07)."
_DrillSarge]I[
2007-09-21, 16:01:10
CPUs verdoppeln und verachtfachen also die Leistung mit mehr Transistoren und bleiben im Budget[...]
sicher, bloß ist der höhere transistorcount eher durch die riesigen chaches zu sehen. ich behaupte einfach mal, dass der transistorcount pro kern nur unwesentlich steigen wird (an logik) und das alles über erhöhung der kernanzahl geschieht, wo man wiederum bei thema parallelisierung ist.
Kurzum: Das 4- Fache der Transistoren erzeugt vielleicht die 4-fache Verlustleistung, wird aber durch kleinere Fertigung und viel Cache weiterhin bei ca 100W gehalten. Nur höherer Takt würde die Grenzen viel schneller sprengen.
GPUs dagegen setzen mit jedem Transistor weiterhin unmengen von Verlustleistung um. Deren Wert ist lange nicht mehr bei 100W und steigenden.
bei silizium-basierende chips ist aber in (naher?) zukunft schluss mit shrinks, siehe leckströme und phys. limits.
Palpatin
2007-09-21, 17:33:04
Ich glaub das die Zukunft in verschiedenen Kernen die unterschiedliche Aufgaben erledigen und mit unterschiedlichen Taktfrequenzen in einem Prozessor laufen liegt.
_DrillSarge]I[
2007-09-21, 17:34:12
Ich glaub das die Zukunft in verschiedenen Kernen die unterschiedliche Aufgaben erledigen und mit unterschiedlichen Taktfrequenzen in einem Prozessor laufen liegt.
das denke ich dauert noch eie weile, im mainstream ist dualcore noch nicht mal sooo verbreitet.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.