Wie wird sich die Taktfrequenz von CPUs in Zukunft entwickeln?

[phil99]

Wie wir alle wissen, stagniert die Taktfrequenz der Prozessoren schon seit einigen Jahren. Augenblicklich geht der Trend ja zu immer mehr Kernen. Aber auch der Takt hat in letzter Zeit wieder zugenommen. Intel schafft momentan über 4ghz und auch AMD geht jetzt in die Richtung.
Was meint ihr. Welchen Takt werden Prozessoren in 5 Jahren haben. Vielleicht findet man neue Materialien mit mehr Potential.
Schliesslich ist ein schneller Thread auch wichtig, nicht alles lässt sich parallelisieren.
Werden wir die 8 ghz sehen ?
Wird in 32 mm die 4ghz+ Standard und bekommen wir in 22nm mehr als 5 ghz.
Inwieweit lässt sich die Performance pro Takt und Kern noch steigern. Wieviel schneller wäre eine heutige CPU mit 1GB Cache ?
Kann jemand ausrechen, wieviel schneller ein solcher Prozessor wäre, eventuell durch Vergleiche.

[tombman]

Ohne Glaskugel geht da gar nix :rolleyes:

[Aquaschaf]

Wird in 32 mm die 4ghz+ Standard und bekommen wir in 22nm mehr als 5 ghz.
Inwieweit lässt sich die Performance pro Takt und Kern noch steigern. Wieviel schneller wäre eine heutige CPU mit 1GB Cache ?

Mit ähnlicher Leistung pro Takt: vielleicht etwas im Rahmen von 5 bis 6GHZ. Mehr wahrscheinlich nicht. Den Cache viel weiter zu vergrößern hätte meistens keinen nennenswerten Effekt. Wirklich in die Zukunft schauen kann man natürlich nicht. Aber ich würde nicht mehr alzu viel erwarten, bevor es zu irgendeinem grundlegenden Technologiewechsel kommt.

[=Floi=]

5ghz sollten noch machbar sein und dann dürfte so ziemlich die vertretbare grenze erreicht sein. (ende 2010)

wenn ich von einer steigerung von 20% bei der architektur ausgehe, dazu noch 5ghz und 8core mit 16 threads dann komme ich auf:
1,2x5x16=96
1x4x4=16 (Intel Q9XXX)
das entspricht einer theoretischen versechsfachnung der leistung.
man könnte auch die gflop ausrechnen, aber das läuft auf das gleiche hinaus.

[GeneralHanno]

wenn man sich CPUs und GPUs anschaut, dann sieht man, dass die taktfrequenzen nicht exponentiell (kurve mit linkskrümmung) (so wie intel es noch zu netburst zeiten vorausgesagt hatte), sondern einer art sättigungsfunktion (kurve mit rechtskrümmung) folgt. sprich: zwar steigen die taktfrequenzen von generation zu generation, die prozentuale steigerung wird aber immer geringer! die aktuellen chiparchitekturen werden im takt also vll noch ~20-30%, vll 50% zulegen: alles andere ist illusorisch.

was aber die NEUEN architekturen in 5-10 jahren bringen, weis keiner zu sagen ;) vll ja 10000kerne@100MHz ;D

PS: auch die kernzahl wird bei AKTUELLEN architekturen nich exponentiell steigen, sondern einer sättigung bei etwa 16 kernen entgegen laufen (stichwort verwaltungsaufwand)

[Aquaschaf]

was aber die NEUEN architekturen in 5-10 jahren bringen, weis keiner zu sagen ;) vll ja 10000kerne@100MHz ;D

Das sicher auch nicht. Sequentielle Leistung braucht man auch. Ein paar general purpose cores wie man sie heute hat werden bleiben.

[_DrillSarge]I[]

Was meint ihr. Welchen Takt werden Prozessoren in 5 Jahren haben. Vielleicht findet man neue Materialien mit mehr Potential.
Schliesslich ist ein schneller Thread auch wichtig, nicht alles lässt sich parallelisieren.
falls man bei cpus bleibt, wie wir sie heute kennen, wird sich da nichts großartiges tun. also keine sprünge mehr wie beim pentium 3 zum pentium 4 (1,4 -> 3.8 Ghz; ja, ich weiss es sind anders konzipierte architekturen). in zukunft wird man einfach aufpassen müssen, innerhalb von thermischen grenzen zu bleiben. wenn man bedenkt, hatte frühere cpus mit einem kern und einer geringeren ipc bspw. 130w tdp, heute haben cpus mit einer höheren leistung pro kern und 4 kernen etwa die selbe.

Wieviel schneller wäre eine heutige CPU mit 1GB Cache ?
das wird bei jetzigen fertigung und materialien nie passieren. ;D

das problem ist halt das "silikon" :biggrin:. dort sind die grenzen nicht mehr weit und die hersteller biegen ja überall schon dran rum mit soi und high-k etc.. für die zukunft müsste da sicher ein anderer werkstoff her, aber welcher? silizium ist eigentlich ideal, da es das in massen gibt und realativ easy abzubauen ist.

[Botcruscher]

wenn ich von einer steigerung von 20% bei der architektur ausgehe, dazu noch 5ghz und 8core mit 16 threads dann komme ich auf:
1,2x5x16=96
1x4x4=16 (Intel Q9XXX)


Stellt sich mir die Frage ob zwei Cores mit nur einem Thread jeweils einem Core mit zwei Threads von der Leistung her nicht zum Teil deutlich überlegen sind. HT kann eben nur nutzen was übrig bleibt.

PS: Die Frage hat sogar Potential für für ein eigenes Thema. Was sagen die Tester dazu?


PSS: WiKi sagt:

Laut Aussage von Intel kann Hyper-Threading im Multitasking-Betrieb normale Programme um 10 bis 20 %, optimierte Programme um bis zu 33 % beschleunigen.

Also hätte ich mit einem I7 schon das Problem herauszufinden ob die Anwendung jetzt die "physikalischen" Cores voll nutzt oder auf einem "HT-Core" rumdümpelt.

[=Floi=]

an das dachte ich auch schon, aber bei 5ghz muß der core auch mehr ausgelastet sein und eine andere architektur könnte da noch mehr darauf optimiert sein.
http://www.computerbase.de/artikel/hardware/prozessoren/2008/test_intel_core_i7_920_940_965_extreme_edition/3/#abschnitt_simultaneous_multithreading_smt

du kannst ja ruhig ein neues thema aufmachen, aber dann sollte man auch beim nehalem oder p4 bleiben und nicht spekulieren.

[RLZ]

Ich vermute, dass die Taktfrequenzen sowohl innerhalb als auch zwischen den Kernen immer weiter auseinanderlaufen werden.
Die einzelnen Bereiche innerhalb eines Kerns werden an ihr Maximum getrieben um die Latenz zu minimieren. Ansätze dafür sieht man heutzutage schon.
Taktunterschiede zwischen Kernen ergeben sich schon rein automatisch durch den Plan unterschiedliche Kerne auf ein Die zu platzieren. Man kann also Kerne bauen, die den rein seriellen Code gut abarbeiten können, Kerne, die mit Highlevel Parallisierung gut zurechtkommen (vgl. aktuelle Kerne), als auch Kerne, die auf Lowlevel Parallelisierung angewiesen sind (GPU ähnlich). Natürlich jeweils mit eigenen Taktraten...

[BlackBirdSR]

IBM hat ja mit Power bereits gezeigt, dass an auch 5GHz und selbst 6GHz erreichen kann. Allerdings ist das natürlich immer von der Designentscheidung abhängig.

Wenn sich in Zukunft wieder simplere Kerne durchsetzen, dann können wir durchaus wieder steigende Taktraten sehen. Bleiben die Kerne fett und groß, dann sehen wir eher das Gegenteil. So richtig entscheien kann sich aktuell wohl keiner ;)

Was aber logisch erscheint: Taktdomänen, wie es Intel, IBM und Nvidia demonstriert haben. Relativ simple Bereiche, die hohen Durchsatz erreichen sollen, werden mit hohem Takt betrieben - Support-Logik und weniger kritische Bereiche mit niedrigerem Takt.

[GeneralHanno]

zum thema nachfolger von silikon (ähh silizium ;)). da hab ich vor kurzem was drüber gelesen. Das zeug heißt graphen und basiert auf kohlenstoff. in 10 jahren könnte es silizium ablösen.
http://de.wikipedia.org/wiki/Graphen

ansonsten gilt ja: taktraten sind schall und rauch, entscheident ist die leistung und die wird sich gemäß moore etwa alle 1,5 jahre verdoppeln.

[BlackBirdSR]

entscheident ist die leistung und die wird sich gemäß moore etwa alle 1,5 jahre verdoppeln.


The complexity for minimum component costs has increased at a rate of roughly a factor of two per year ... Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years. That means by 1975, the number of components per integrated circuit for minimum cost will be 65,000. I believe that such a large circuit can be built on a single wafer.[2] (http://en.wikipedia.org/wiki/Moore%27s_law#cite_note-Moore1965paper-1)


Von Performance steht da (leider) nichts.

[AnarchX]

Bei Intel wird man vor allem in Richtung dynamischer Taktraten gehen, welche von Kühlung und Thread-Anzahl abhängig sein wird.

http://img411.imageshack.us/img411/7572/kaigai412035572333og4.gif
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6743623&postcount=10
...ausgehend von >3GHz Takt bei Sandy Bridge, sind das dann mal ~5GHz für den Dynamic Turbo Mode.

Wenn das dann noch auf verschiedene Domains übertragen wird, dann können wir uns wohl bald von "der Taktfrequenz" verabschieden.

[BlackBirdSR]

Bei Intel wird man vor allem in Richtung dynamischer Taktraten gehen, welche von Kühlung und Thread-Anzahl abhängig sein wird.

http://img411.imageshack.us/img411/7572/kaigai412035572333og4.gif
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6743623&postcount=10
...ausgehend von >3GHz Takt bei Sandy Bridge, sind das dann mal ~5GHz für den Dynamic Turbo Mode.

Wenn das dann noch auf verschiedene Domains übertragen wird, dann können wir uns wohl bald von "der Taktfrequenz" verabschieden.#

max 37% für maximal 1 Minute, wenn das System nicht aufgeheizt ist.
Da allerdings selbst bei guter Wasserkühlung die Wärme On-Die nicht schnell genug abgeführt wird, halte ich das für keine realistische Projektion für einen betriebsrelevanten Zustand.

[reunion]

Hoher Takt ist ineffizient. Ich glaube nicht das es hier zu großartigen Steigerungen kommt, denn die Leistungsaufnahme wird immer wichtiger.

[Gast]

Die Leistung pro Takt und Core muss weiter ansteigen, mehr Befehle pro Takt und eine effizientere Cache Logik. Das sind Kernelemente die sich zwischen der Core1 und der Core2 verbessert haben und das spürt man auch deutlich.

[BlackBirdSR]

Die Leistung pro Takt und Core muss weiter ansteigen, mehr Befehle pro Takt und eine effizientere Cache Logik. Das sind Kernelemente die sich zwischen der Core1 und der Core2 verbessert haben und das spürt man auch deutlich.

Nur irgendwann ist schluss:
Irgendwann kann man die Divisionsalgorithmen nicht mehr schneller hinbiegen, irgendwann sinkt der Ertrag durch noch breitere Register ins Bodenlose, sackt der Nutzen von noch mehr Logik für OOO-Scheduling ins nutzlose...

Irgendwann muss man sich fragen, ob 1% Gewinn die 5 Millionen´+ Transistoren wert sind?

Aktuell scheint P3-PentiumM-Core2-I7 der richtige weg zu sein. Aber irgendwann gehen einem die Tricks aus, dann muss man das Konzept anpassen. Würde mich nicht wundern, wenn wir irgendwann zum "Konzept" ähnlich dem P4 (nicht dessen Implementation) zurückkehren.

[Gast]

Nun gibt es mit der übernächsten Architektur wohl erhebliche Verbesserungen beim Cache. Wenn 8MB mit nur 5 Prozessor-Takte Latenz angebunden werden könnten, so würde das einen deutlichen Sprung bei den IPC bewirken!

[Aquaschaf]

Nun gibt es mit der übernächsten Architektur wohl erhebliche Verbesserungen beim Cache. Wenn 8MB mit nur 5 Prozessor-Takte Latenz angebunden werden könnten, so würde das einen deutlichen Sprung bei den IPC bewirken!

Wie kommst du darauf? Sicher gibt es Anwendungen die davon profitieren würden, aber viele wiederum auch fast überhaupt nicht.

[Fritte mit Zwiebeln]

Die Taktfrequenz wird sich in der nächsten Zeit kaum erhöhen. Damals als ich noch ein AT Rechner mit 12Hz hatte und kurz danach die 386er Gen. kam, war es der startschuß für die CPU-frequenz. Jetzt seit 6-7 Jahren ist es zu stehen gekommen, siehe meinen vor 7 Jahren gekauften PC mit 2,53 Mhz an.
Frage an die non gamer unter euch, warum sollte ich mir jetzt einen neuen PC kaufen? Natürlich hab ich auch einen NB und einen Netbook, aber das alte Teil läuft einfach saustabil und sehr sehr schnell. Hat übrigens gerade mal 512MB-ram.

[phil99]

Da es ja in letzter Zeit vermehrt den Cache für alle Kerne gibt, sind die 1GB doch gar nicht so utopisch.Das wären bei den aktuellen 16MB beim Quadcore noch 6 Verdoppelungen also von 44nm ausgehend wären wir bei 11nm schon bei 256MB.
Die Frage ist, ob dieser langsame Cache wirklich viel bringt. Oben wurde ja was von dem schnelleren Core-i7 Cache erwähnt.
Dynamische Prozessoren, die ihre Leistung den Anforderungen anpassen (unterschiedliche Kerne, Taktdomains, Turbomode etc) wird sich wohl mit den Manycores langsam durchsetzten.
Meine Frage bezog sich allerdings auf einen nicht teilbaren Thread und erstmal simpel auf die Taktfrequenzen der 33nm, 22nm Corenachfolger, bzw der AMD,s).
Intel würde jetzt schon höhere Taktfrequenzen verkaufen, wenn sie denn Konkurenz hätten.
Es würde dann sicher einen Quadcore S775 mit 3.4 ghz oder sogar 3.8 ghz geben.
Und vielleicht bekommen wir irgendwann wirklich wieder einen "Pentium 4", also eine Architektur, die sich gut nach oben takten lässt.f
Kann natürlich auch passieren, dass man das Paralellisierungsproblem löst (Weiss nicht, ob es praktische Fälle gibt, wo sich nicht parallelisieren lässt, mathematisch lässt sich so einer natürlich leicht erzeugen) und die Takte und Vcores werden nach unten getrieben und dafür die Architekturen extrem verbreitert, um möglichst viel GFlops pro Watt zu erzielen.
Rein von der Verlusleistung gilt halt (Takt * Spannung), sogesehen möglichst niedrige Spannung. 1 V wird wohl nicht mehr lange angelegt werden.

[AnarchX]

Zwischen normalen Arbeitsspeicher und dem höchsten CPU-internen Cache-Level dürfte wohl in Zukunft eine weitere Ebene eingeführt werden - Fast-RAM.

Dieser wird wohl unter die CPU "geklebt" werden:
http://pc.watch.impress.co.jp/docs/2008/1226/kaigai_7.jpg
http://pc.watch.impress.co.jp/docs/2008/1226/kaigai483.htm

Bei Sandy Bridge (ehemals Gesher) gab es eine Projektion die bis zu 512MiB mit ~64GB/s vorsah:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6746541&postcount=18

Wobei das für Single-Thread-Aufgaben nicht wirklich relevant sein sollte und eher in die Richtung von AVX bzw. den Co-Vektorprozessoren bei Haswell geht.

[GeneralHanno]

es gab mal bei intel eine pressefolie auf dem der konzern seine "prioritätenliste" zur leistungssteigerung zukünftiger porzessoren gezeigt hat.
ich meine ganz oben standen "neue befehle" und ganz am ende "mehr takt" ... ich werd mal auf die suche gehen ;)

[Gast]

Wie kommst du darauf? Sicher gibt es Anwendungen die davon profitieren würden, aber viele wiederum auch fast überhaupt nicht.Und wie kommst du darauf? Das ist ja wohl mindestens ebenso spekulativ deinerseits!

OK, vielleicht habe ich das nicht einleuchtend genug ausgedrückt: Wenn wir 8MB Cache mit der Geschwindigkeit des aktuellen 1st Level Cache hätten, dann würden sehr viele Anwendungen Performance-Sprünge zeigen. Die wenigsten leistungshungrigen Anwendungen passen in die 64 KB 1st Level Cache des CoreI7. Ich Diese Aussage ist sicher nicht zu spekulativ. Pipe-Stall auf Grund von Wartecyclen (auf z.B. Daten) sollten deutlich seltener auftreten. Das ist gerade der Sinn und Zweck eines Cache-Zwischenspeicher, der nie schnell und groß genug sein kann. Intel möchte doch in der übernächsten Generation am Cache erhebliche Verbessungen einführen.

[BlackBirdSR]

OK, vielleicht habe ich das nicht einleuchtend genug ausgedrückt: Wenn wir 8MB Cache mit der Geschwindigkeit des aktuellen 1st Level Cache hätten, dann würden sehr viele Anwendungen Performance-Sprünge zeigen.

[...]Intel möchte doch in der übernächsten Generation am Cache erhebliche Verbessungen einführen.

8MB-L1 Cache sind allerdings nicht so schnell anzusprechen. Schon jetzt haben Pentium4 und Nehalem die Latenz auf 4 Takte angehoben.
8MB-L1 langsam anzusprechen hat viel weniger Sinn, also wenig schnell und viel langsam. Zumal die L1-Caches richtige Transistorfresser sind.

[Spasstiger]

Ist es eigentlich möglich, über zusätzliche Taktdomänen die Leistung weiter zu steigern?
Einen simplen Addierer könnte man ja z.B. deutlich höher takten als einen komplexen Dividierer. Und man könnte so auch Pipelinestufen einsparen. Der Dividierer muss dann z.B. nicht mehr unterteilt werden, um den kritischen Pfad zu verkürzen.
Natürlich müsste man die Daten synchronisieren, was wieder Leistung kostet.

[GeneralHanno]

es wird wohl unmöglich sein, im inneren kern verschiedene assynkrone taktraten anzulegen. wenn wir aber in 5 oder 10 jahren in richtung manycore gehen, dann werden einige kerne mehr können als andere und (vermutlich) auch verschieden getaktet sein. aber bis wir da sind, werden noch einige jahre verstreichen!

[BlackBirdSR]

Ist es eigentlich möglich, über zusätzliche Taktdomänen die Leistung weiter zu steigern?
Einen simplen Addierer könnte man ja z.B. deutlich höher takten als einen komplexen Dividierer. Und man könnte so auch Pipelinestufen einsparen. Der Dividierer muss dann z.B. nicht mehr unterteilt werden, um den kritischen Pfad zu verkürzen.
Natürlich müsste man die Daten synchronisieren, was wieder Leistung kostet.

Der Pentium4 hatte Addierer, die mit doppelter Taktflanke angesprochen wurden (also in unter einem halbem Takt fertig addiert hatten). Die waren allerdings jeweils nur in der Lage an einer Hälfte des Registers zu arbeiten (16Bit). Neben der nötigen Support-Logik hat das die Anzahl möglicher Befehlskombinationen aber stark eingeschränkt. Daher der weitaus geringere Vorteil als auf den ersten Blick vielleicht gedacht.
Auf der anderen Seite lief z.B der Trace-Cache nur mit halbem Prozessortakt. jaja.. Pentium4...

[phil99]

Kann hier jemand ausrechnen, wieviel schneller ein moderner Prozessor mit unbegrenzter Bandbreite wäre, also alle Daten im L1 Cache.
Machen Manycores eigentlich ausserhalb von perfekt parallelisierbaren Anwendungen (Bild rendern, Dateien entpacken etc) Sinn.
Ich meine jetzt mehr als 100 oder so. Und ausser bei Servern natürlich, die zigtausende Threads ausführen.

[Coda]

Die waren allerdings jeweils nur in der Lage an einer Hälfte des Registers zu arbeiten (16Bit).
Bist du dir da sicher? Das habe ich anders im Kopf.

[Hammer des Thor]

Das Problem ist hier die Lichtgeschwindigkeit, diese ist einfach zu langsam ( ja ehrlich :wink: ) für noch höhere Taktraten. Ich habe mir vor 10 Jahren schon ausgerechnet, dass bei etwa 4 GHZ Schluss sein muss, weil darüber der neue Takt schon initialisiert wird bevor der letzte durch den ganzen Chip durch ist ( eventuell auch noch zurück muss ) Ich bin kein CPU-Techniker, jedenfalls soll man CPU auch so bauen können, dass höher getaktet werden kann und immer nur ein Register ohne Überlagerung sein darf. Auch die Register haben aber eine Größe. Eine Möglichkeit könnte sich m.E. durch stapeln ergeben, man teilt z.B. den Chip in 16 Teile und lagert diese wie bei Flash-Bausteinen übereinander an. Problem dürfte hier wieder die Kühlung sein.
Auch wurden schon vor Jahren taktlose Chips vorgeschlagen, wo einfach jede Aufgabe so schnell erledigt wird wie es geht.
Übrigens : Dass man heute dazu übergeht, anstatt immer komplexerer CPUs Mehrkerne zu fertigen, das habe ich mir vor 10 Jahren auch schon ausgedacht, lange bevor der erste X86-Prozessor mit Dualcore raus kam. Auch damit löst man das Problem Signallaufzeiten im Prozessor. Die einzelnen werden dann immer kleiner mir kürzeren Signallaufzeiten. Für die Kommunikation der Kerne untereinander können ja geringere Taktraten genommen werden.


Gruß, HdT

[BlackBirdSR]

Bist du dir da sicher? Das habe ich anders im Kopf.

Carry Save?
Bin mir jetzt nicht mehr sicher und finde das Dokument nicht, das ich von damals im Kopf habe. Ging davon aus, dass die Hälften zeitversetzt anfangen.. aber auf der anderen Seite...

wie gesagt: Bin Dokumentlos ;)

[phil99]

Das löst aber nicht das Problem einer nicht parallelisierbaren Aufgabe. Die Lichtgeschwindigkeit hat aber nix mit den Problemen zu tun, die bei der Netburstarchitektur zuerst aufgetreten sind. Die Leckströme und die stark zunehmende Verlustleistung, die entstanden ist bei hohen Taktfrequenzen. Oder glaubst du, dass Intels Ingenieure sich keine Gedanken gemacht haben.
Ausserdem werden die Wege ja auch immer kürzer durch die Strukturverkleinerung. 3D-Chips werden sicher kommen, aber das ist Glaskugel hinter der Glaskugel. Es geht um die nächste Zukunft und die Frage, wieviel Leistung ein einzelner Kern bringen kann.
5ghz und 30% mehr pro Takt Leistung tippe ich mal für 22nm.Dazu wohl 16 Kerne und 64 MB L3-Cache. Spätestens wenn die physikalischen Grenzen erreicht werden, wird es in Richtung neue Materialien und mehreren Schichten (3D) gehen.
Aber wie gesagt, dass ist die Glaskugel hinter der Glaskugel.

[Coda]

Das Problem ist hier die Lichtgeschwindigkeit, diese ist einfach zu langsam ( ja ehrlich :wink: ) für noch höhere Taktraten. Ich habe mir vor 10 Jahren schon ausgerechnet, dass bei etwa 4 GHZ Schluss sein muss, weil darüber der neue Takt schon initialisiert wird bevor der letzte durch den ganzen Chip durch ist ( eventuell auch noch zurück muss )
Es gibt jetzt schon mehrere Clockdomains und auch die Clock-Distribution ist sehr ausgefeilt.

Die Signale müssen ja nicht jeden Takt quer über den ganzen Chip. P4 Cedar Mill liefen ja tatsächlich auch mit >8Ghz mit entsprechender Kühlung.

[Hammer des Thor]

Das löst aber nicht das Problem einer nicht parallelisierbaren Aufgabe.

Ich habe ehrlich gesagt da keine wirkliche Ahnung. Mir ist jedenfalls keine Anwendung bekannt, die sehr rechenintensiv ist und gleichzeitig nicht oder kaum parallelisierbar ist. Extrem Rechen- und Daten-Intensiv ist z.B. die Wetterberechnung. Da ist es z.B sehr logisch, dass diese verdammt gut parallelisierbar ist. Beim PC sind es vor allem Spiele und Multimedia welche sehr rechenintensiv sind. Bei Spielen wäre es m.E. gar kein Problem 1000de Polygone parallel zu berechnen. Ähnlich sollte es bei der Physik sein. Unzählige Gegenstände im Spiel könnte man entsprechend " unzählig " parallelisieren. Bei Photos kann man verschiedene Teile des Bildes parallel bearbeiten , bei Videos auch. Kennst Du eine Anwendung die nicht parallelisierbar ist, die so rechenintensiv ist, dass sagen wir mal ein 2 GHZ-Prozessor ( Core2 oder Athlon )
problematisch zu langsam wäre ? Mal abgesehen von irgendwelchen abstrakten mathematischen Anwendungen, die in der Realwelt nicht gebraucht werden.
Könnte vielleicht ein Quantenprozessor hier helfen ? Kein Digitaler Quantenpunktcomputer, sondern einer der die Quanteneffekte ( die bei Digitalrechnern stören ) gezielt nutzt ?


Gruß, HdT

[Coda]

Das Problem dabei ist, dass selbst geringe Anteile an seriellem Code bereits die Skalierbarkeit sehr stark einschränken.

[SavageX]

Das Problem dabei ist, dass selbst geringe Anteile an seriellem Code bereits die Skalierbarkeit sehr stark einschränken.

Beispielsweise ist bei nur 5% nicht parallelisierbarem Codeanteil der maximal durch Parallelisierung erreichbare Speedup 20. Und das ist die theoretische Obergrenze.

[Coda]

Jepp. Und das hat man sehr schnell mit nur ein paar Critical Sections.

[GeneralHanno]

*grübel* wie heiß nochmal das gesetzt (so ne formel) zwischen threadzahl und verwaltungsaufwand?

[Hammer des Thor]

Das Problem dabei ist, dass selbst geringe Anteile an seriellem Code bereits die Skalierbarkeit sehr stark einschränken.


Wie lösen die es dann z.B. bei der Wetterberechnung mit 1000den Prozessoren oder gar bei Teilchenbeschleunigern. Auch beim Wetter müssen die Daten ab und zu mit den Ergebnissen der Nachbarzellen abgeglichen werden, ist also auch nicht komplett parallelisierbar . M.E. könnte man ( habe da keine Ahnung ) z.B. beim Wetter auch solche Daten die bedingt parallelisieren. Z.B. in dem beim Abgleichen der Daten nicht gleich alle mit allen abgeglichen werden, sondern erst mal nur mit den Nachbarzellen, da könnte man ja ein Stufensystem aufbauen.
Ich bin kein Programmierer, aber sollte man nicht SF o entwickeln, dass alles was parallelisierbar ist auch parallelisiert und wenn Operation die nicht parallelisierbar sind ausgeführt werden müssen eben der Rest mal nicht rechnet ? Wie gesagt, m.E. dürften Operationen die nicht parallelisierbar sind in der Regel nicht sehr rechenintensiv sein, womit sich die Zeit wo nicht parallelisiert werden kann in Grenzen halten sollte.

HdT

[Coda]

Wie lösen die es dann z.B. bei der Wetterberechnung mit 1000den Prozessoren oder gar bei Teilchenbeschleunigern.
Da gibt es keinen seriellen Code. Ganz einfach. Das ist aber ein äußerst gutmütiger Fall den man in der Praxis sehr selten hat.

Auch beim Wetter müssen die Daten ab und zu mit den Ergebnissen der Nachbarzellen abgeglichen werden, ist also auch nicht komplett parallelisierbar.
Man rechnet zuerst die Derivate pro Gitterpunkt aus vor einem Schritt und operiert dann weiter. Das geht beides ohne Locks.

Ich bin kein Programmierer, aber sollte man nicht SF o entwickeln, dass alles was parallelisierbar ist auch parallelisiert und wenn Operation die nicht parallelisierbar sind ausgeführt werden müssen eben der Rest mal nicht rechnet ? Wie gesagt, m.E. dürften Operationen die nicht parallelisierbar sind in der Regel nicht sehr rechenintensiv sein, womit sich die Zeit wo nicht parallelisiert werden kann in Grenzen halten sollte.
Du kannst mir glauben, dass es für "normalen" Code sehr schwierig ist überhaupt einen Quadcore auszunutzen.

[Hammer des Thor]

Du kannst mir glauben, dass es für "normalen" Code sehr schwierig ist überhaupt einen Quadcore auszunutzen.

Glaube ich Dir auch !
Lass mich raten, ein Problem liegt an der Abwärtskompatiblität beim PC. Solche SW ist in der Regel keine Spezial-SW für Multi-Prozessor-Systeme. Bei einen Wetter-Computer wird die SW speziell für Systeme mit 1000 Prozzis oder mehr geschrieben. Bein PC muss man aber " normal " programmieren. Kann es sein, dass eine sagen wir mal H.264-Full-HD-Anwendung die für 256 parallele Prozzis programmiert wurde de-fakto nicht mehr kompatibel wäre für Dual-oder gar Single-CPU-Systeme, selbst wenn die so hoch getaktet wären, dass diese auf etwa sich gleiche theoretische Rechenleistung kommen ?
Wäre es in diesem Falle nicht besser anstatt immer mehr gleiche Kerne auf einen Multicore-Chip nur 2 oder max. 4 Kerne plus Zusatz-Chips für Prozesse die sich gut parallelisieren lassen zu bauen, wie es z.B beim Cell-Chip schon ist ? AMD hat ja sowas für die Nachfolger ihrer Quad-Cores schon angekündigt.
Falls es ein Problem wäre, dass z.B. der Parallel-Code erst die Ergebnisse des sequentiellen Codes abwarten müsste, könnte man die parallelen Teile doch spekulativ schon mal weiterrechnen lassen.

Gruß, HdT

[pest]

Da gibt es keinen seriellen Code. Ganz einfach. Das ist aber ein äußerst gutmütiger Fall den man in der Praxis sehr selten hat.


hängt vom modell ab

Glaube ich Dir auch !
Lass mich raten, ein Problem liegt an der Abwärtskompatiblität beim PC.


nein, es liegt an den algorithmen die man verwendet
auch ein h.264 kodierer ist nicht perfekt parallelisierbar nur bestimmte schritte
d.h. die laufzeit hat immer eine einfache untere schranke die sich an einer (logisch oder physisch) vorhandenen bearbeitungseinheit orientiert

[Hammer des Thor]

hängt vom modell ab



nein, es liegt an den algorithmen die man verwendet
auch ein h.264 kodierer ist nicht perfekt parallelisierbar nur bestimmte schritte
d.h. die laufzeit hat immer eine einfache untere schranke die sich an einer (logisch oder physisch) vorhandenen bearbeitungseinheit orientiert

Trotzdem scheinen ja die nicht parallelisierbaren Schritte dort nicht allzu arg zu bremsen. Bei H.264 kann viel auf die Graka ausgelagert werden und die arbeitet nun mal parallel. Die Graka beim Encodieren mit zu benützen soll das Encoden um ein vielfaches schneller machen. Geht also doch und ist offenbar sehr effektiv trotz einen Teil nicht parallelisierbarer Prozesse. Gut, vielleicht wäre das ohne seriellen Code noch 3 mal so schnell oder noch schneller. Trotzdem ist eine Beschleunigung vom Faktor 7 durch eine Mittelklasse-Graka doch schon sehr erfolgreich.

[pest]

Die Graka beim Encodieren mit zu benützen soll das Encoden um ein vielfaches schneller machen.
...
Geht also doch und ist offenbar sehr effektiv trotz einen Teil nicht parallelisierbarer Prozesse.


also erst stellst du eine vermutung auf...die du im nächsten satz als bestätigt siehst...hm...

das was ich bisher von kodierern mit starker auslastung auf die grafikkarte gesehen habe, hat mich qualitätstechnisch überhaupt nicht überzeugt.
wenn man nun versucht die qualität wieder anzugleichen wird sich der zuwachs imo stark verringern, da eben genau diese codeteile viel abhängigen code enthalten.

[Hammer des Thor]

das was ich bisher von kodierern mit starker auslastung auf die grafikkarte gesehen habe, hat mich qualitätstechnisch überhaupt nicht überzeugt.


Wenn ich mir jetzt nen neuen PC anschaffe, also beim H.264-Encoder dann lieber nicht die Graka dafür benützen ? Wusste nicht, dass die Qualität darunter leidet, habe das bei Heise-Online und in der CT gelesen, da kann ich mich nicht erinnern, dass das was von eine Qualitätsverschlechterung stand. Ich kann mir bei 1080 mal 1920 Pixeln nicht gut vorstellen, dass sich vieles dort nicht parallelisieren lässt. Je größer das Bild um so mehr müsste sich parallelisieren lassen. Generell müsste sich m.E. auch bei der Bildbearbeitung fast alles massiv parallelisieren lassen. Selbst wenn vieles von der CPU bei guter Quali abhängen sollte : Eine Vierfach-Parellelisierung auf Quad-Core dürfte bei dem großen Bild eher ein Witz sein. 4 Objekte die man z.B. parallel vektoriesieren könnte dürften wohl in nahezu jeder Szene drin sein. Wenn es etwas gibt beim PC was gut parallel geht, dann dürfte das Multimedia sein, Textverarbeitung vielleicht nicht so, diese braucht aber keine riesen Rechenleistung.

[Hammer des Thor]

Nicht nur Wettercomputer, sondern Groß/Super-Rechner im Allgemeinen basieren ja auf Massiv-Parallelität. Die Dinge die diese Maschinen , sie zum Teil 2 Handball-Turnhallen füllen müssen sich ja auch gut parallelisieren lassen. Mal ne Frage: Warum sollte ein PC hier unbedingt mehr können müssen, als ein zig-Millionen Dollar teurer Super-Rechner der für die Stromversorgung ein eig. Kraftwerk hat ?
Selbst wenn es im PC-Bereich Aufgaben gibt die sich nicht so gut parallelisieren lassen wegen eben dem Anteil auf sequentiellen Code : Dann ist das eben technisch nicht machbar, vieles ist technisch nicht machbar, na und ? 3 GHZ o dürften für die meisten Aufgaben die nicht parallelisierbar sind,schnell genug sein. Bei H.264-Full-HD Encodierung sollte es ausreichen, dass in " Echtzeit " encodiert werden kann ( also so schnell wie der Film abläuft ). Alles was schnell dafür genug ist, sehe ich nicht als " Problem ".

Gruß, HdT

[Coda]

Falls es ein Problem wäre, dass z.B. der Parallel-Code erst die Ergebnisse des sequentiellen Codes abwarten müsste, könnte man die parallelen Teile doch spekulativ schon mal weiterrechnen lassen.
Nein könnte man nicht :|

[robbitop@work]

Nein könnte man nicht :|
Hat der Itanium nicht mal sowas gemacht?

[Coda]

Ja, aber das hat mit Multithreading nichts zu tun.

Wie willst du denn "spekulativ weiterrechnen", wenn du eben einen bestimmten Funktionswert benötigst? Irgend eine Zahl einsetzen?

[mrt]

Weiterrechnen kann man schon, man nimmt halt irgendeinen Wert an, das Ergebnis wird man halt verwerfen müssen (1:2^64 Chnace einen Treffer zu haben bei 64Bit Int).

Itanium macht das nur bei Sprüngen und nicht bei Funktionswerten.

[robbitop@work]

Ja, aber das hat mit Multithreading nichts zu tun.

Wie willst du denn "spekulativ weiterrechnen", wenn du eben einen bestimmten Funktionswert benötigst? Irgend eine Zahl einsetzen?
Nein das ging nur bei Branchning-Fällen.

[Coda]

Ich weiß was Itanium macht. Das hat aber nichts mit dem Thema zu tun.

[HOT]

Die Zukunft wird sein, die Kernbarrieren aufzubrechen, sodass man zwar MT weiterhin nutzen wird, aber die Einheiten, die damit gefüttert werden, nicht mehr für jeden Kern einzeln angewendet werden, sondern, genau wie Cache, geteilt werden können (das sogenannte CMT-Konzept). Dabei wird man sich vorher ungefähr ausrechenen, wie breit eine solche Einheit sein muss, ob sie geteilt wird oder nicht usw. Man wird versuchen MT so effizient wie möglich zu machen, also 16 Threads-CPUs zu bauen, die pro Thread beliebig kraftvoll sind. Vom Takt her wird man nicht viel höher gehen. Eine Steigerung von 2-3 GHz ist 1/3. Um nochmal 1/3 rauszuholen braucht man schon 4,5(!) GHz. Das ist nicht effektiv. Zwar wird man die 4,5GHz erreichen, aber um da nochmal 1/3 mehr rauszuholen braucht man schon 6,75GHz, das ist schlicht utopisch, selbst mit 11nm. Takt ist schon seit Jahren ne Sackgasse. Seit 90nm sind keine wirklich überragenden Taktsteigerungen in der Praxis mehr drin. Von 90 bis 32nm keine 4GHz zu erreichen spricht mMn schon für sich. In 32nm werden die 4GHz zwar fallen, aber nur knapp und auch für 22nm ist nicht mehr als 4,5GHz zu erwarten, alles andere wäre utopisch. Der Turbomode ist übrigens eine totale Sackgasse, genau wie dynamischer Takt. Das klappt nicht, weil das Silizium eine feste Grenze hat. Man muss einen gewissen Takt garantieren können, oder man kann keine CPUs innerhalb einer Serie mehr bauen. Deshalb gibt es den Turbomode auch nur bei XEs. Turbomode/dynamischer Takt ist wirtschaftlicher Selbstmord und ein Quell von Instabilitäten.

Im Moment werden QuadCores noch wie 4 einzelne CPUs mit eigenem Cache oder shared-Cache pro 2 Kerne oder SMT pro Kern behandelt. Das wird schon sehr sehr sicher mit Bulldozer, wahrscheinlich auch mit Sandy-Bridge, aber nicht mehr so sein, da steckt eine Menge brachliegendes Potenzial.

[Gast]

Spin-Computer könnten die Taktfrequenz drastisch steigern, allerdings dauert das wohl noch 10-20 Jahre.

[Nevermore4ever]

Da mir die Wahrsagerei ebenfalls Spaß macht, gebe ich meinen halb-qualifizierten Senf auch mal dazu: :cool:

Vielleicht gelingt es, CPUs in 3D zu bauen, und zwar nicht als Sandwich, sondern einfach bspw. Cache einfach senkrecht wo drauf zu setzen. Dann hat man einen Teil des Die als "Boden" und ein paar "Wände". In den Raum dazwischen baut man Heatpipes und löst damit ein thermisches Problem. :wink:

Da die Frage die nach der Taktfrequenz war, kümmere ich mich jetzt auch mal nicht ausführlich um Stromsparen durch totale Kernabschaltung und anderen Firlefanz.

Um die Taktfrequenzen weiter hochzutreiben, bedarf es geschickter Kühlung, denn mit flüssigem Stickstoff kann auch ein Phenom II zwischen 5 und 6 GHz erreichen. Selbst Enthusiasten werden aber selten ein Dewar-Gefäß auf die CPU schrauben wollen, nebst Kondenswasser-Abführung versteht sich.;D

Evtl. werden aber verbesserte Kühltechnologien im High-End-Bereich Einzug halten, sei es über Ionenwind, Thermoelemente oder Kompressoren. Da vor allem letztere Methoden aber einen hohen Energieverbrauch mit sich bringen, gehe ich davon aus, dass die Taktfrequenzen unterhalb des High-End-Marktes so gut wie gar nicht mehr steigen.

[Gast]

Takt ist schon seit Jahren ne Sackgasse. Seit 90nm sind keine wirklich überragenden Taktsteigerungen in der Praxis mehr drin. Von 90 bis 32nm keine 4GHz zu erreichen spricht mMn schon für sich.

Du betrachtest das bloß aus einem falschen Blickwinkel und wirfst vieles durcheinander!!

Das es keine weiteren großartigen Taktsteigerungen gegeben hat, ist ganz einfach mit einem Architekturwechseln zu begründen und NICHT, das dort bereits ein Ende erreicht wurde.
Intel hätte ganz sicher noch Modelle mit mehr Takt nachschieben können, warum sie es nicht gemacht haben, ist genauso klar: Um die neue Architektur zu pushen, schließlich mussten die Entwicklungskosten erst wieder rein.
Sicher hätte der P4, genauso wie der Athlon64 irgendwann sein Limit erreicht, aber noch längst nicht bei 3,8 GHz. ;) in 45 oder 32nm wäre der auch noch höher gegangen, schon die 65nm Modelle wiesen eine gute Taktbarbeit auf.
Man erinnere sich nur an den 4,26 GHz Prozessor den Dell vermarktet hat. Das hätte Intel genauso machen können, aber wozu, wenn eine neue, bessere Architektur kurz vorm Release steht.
Außerdem darf nicht vergessen werden, das die Konstruktionspläne dieser CPUs schon ziemlich alt waren. Im Jahre 2000!! und davor (Entwicklungsphase) hat man sicher noch nicht all das einplanen können, was heute möglich und nützlich gewesen wäre. Eine CPU im nachhinein grundlegend ist nicht ganz zu einfach.
Ich bin mir sehr sicher, das eine Architektur auf den Erfahrungen der letzten Jahre und mit heutiger Technik einen ganz anderen Standpunkt hätte - das heißt nicht, das sie besser sein muss, als die jetzigen Architekturen, aber sie wäre sicher effektiver als die alte.
Siehe auch: IBM - http://www.computerbase.de/news/hardware/prozessoren/ibm/2008/juli/ibm_power7_acht_kerne_40_ghz/

Auch jetzt könnte Intel Modelle mit mehr Takt nachschieben und tut das auch, im Serverbereich gibts Modelle mit mehr FSB oder höheren Takt. Wegen der schwachen Konkurrenz schöpfen sie zur Zeit nicht alle Limits aus. Warum sollten sie auch, je früher sie ihr Potential ausschöpfen, desto weniger $$$ lässt sich machen. ;)
Es gibt sogar einen 3,33 GHz Quad für Server, bei den Core2Quads gibts den nicht.

Der Turbomode ist übrigens eine totale Sackgasse, genau wie dynamischer Takt.

Das ist doch Unsinn.
Wenn du es mal von der anderen Seite betrachtest, nennst du z.B. Stromsparmaßnahmen Unsinn. Da wird das nämlich schon seit Jahren gemacht und ist vorallem bei Notebooks einer der wichtigsten Faktoren, um die Akkulaufzeit zu verlängern.

Das wechseln zwischen verschiedenen Taktraten ist durchaus sinnvoll, man bräuchte auch keine 8-Kern CPU mit voller Taktrate um eine Anwendung wie Microsoft Word zu bedienen, da reichte theoretisch einer, maximal zwei Kerne aus, während die anderen Funktionseinheiten abgeschaltet werden.

Das klappt nicht, weil das Silizium eine feste Grenze hat.

Eine Grenze hat jeder Prozessor und jedes Material. Du kannst genauso wenig unendlich lang in die Breite bauen, irgendwann wird es ineffektiv.
Nicht umsonst gibt es diese Intel Designstudie, sie versuchen herauszufinden, wie sich so viele Cores am besten miteinander verbinden lassen. Dir bringen 80 Cores überhaupt nichts, wenn du nicht in der Lage bist, sie an der gleichen oder einer ähnlichen Aufgabe rechnen zu lassen.

Deshalb gibt es den Turbomode auch nur bei XEs. Turbomode/dynamischer Takt ist wirtschaftlicher Selbstmord und ein Quell von Instabilitäten.

Stimmt doch beides nicht: Der kleinste Prozessor Core i7-920 wird durch den Turbo Mode fast dauerhaft von 2,66 auf 2,8 GHz gestuft, das gleiche Prozedere gilt für das Modell 940, das von 2,93 auf 3,06 GHz springt. Das Flaggschiff ist in diesem Sinne also eigentlich ein 3,33 GHz schneller Quad-Core-Prozessor, was in vielen Benchmarks den Vorsprung gegenüber bisherigen Modellen erklärt.

Ich sehe das ganz anders, es gibt zwei Ansätze und diese lassen sich auch mixen:
Man geht in die Breite und setzt auf möglich viele Cores und versucht einen Weg zu finden, die Arbeit intelligent untereinander aufzuteilen (das könnten weitere integrierte Chips übernehmen).

Oder man geht nur ein wenig in die Breite und versucht sich zu spezialisieren. Ich bin mir ziemlich sicher, das zukünftige Prozessoren nicht mehr einheitlich takten werden, die ersten Bausteine sind gelegt (siehe AMD + TurboMode).

Dadurch widerum wäre es möglich, simple Cores bei extrem hoher Taktrate zu bauen und diese zu nutzen, wenn es darauf ankommt und gleichzeitig die anderen abzuschalten. Man kann könnte umgekehrt auch bei komplexeren Aufgaben die simplen Cores abschalten und stattdessen mehrere, wesentlich komplexere rechnen lassen.
Beim Pentium4 ist das alles noch nicht eingeflossen, wirklich simpel aufgebaut war der ja nicht.

[paul.muad.dib]

Ich kann mir bei 1080 mal 1920 Pixeln nicht gut vorstellen, dass sich vieles dort nicht parallelisieren lässt. Je größer das Bild um so mehr müsste sich parallelisieren lassen.

Das hat rein gar nichts mit der Auflösung zu tun. Der Sinn von Videocodecs ist ja gerade NICHT jedes Pixel einzeln zu speichern, sondern einen Datenstrom zu erzeugen, aus dem die einzelnen Pixel dann vom Dekoder errechnet werden.
Dafür wird erstmal grundsätzlich der einzelne Frame komprimiert, ähnlich jpeg vs. bmp. Vollständige Bilder, sogenannte Keyframes gibt es aber ohnehin nur alle 2-10 Sekunden, dazwischen werden nur Änderungen gespeichert.
Dadurch ist der Abschnitt von einem Keyframe zum nächsten nicht paralellisierbar, weil hier alle Ergebnisse von einander abhängen. Das ist erstmal nicht schlimm, weil es ja immer noch genug einzelne Schnipsel gibt. Weiterhin wird aber erst beim Durchlauf festgelegt, wo der nächste Schnitt gemacht wird und ein neuer Keyframe erzeugt wird.

Dadruch ist er schwer festzulegen, wo der nächste Kern mit der Arbeit beginnen soll. Bei 16 Threads halte ich das noch für gut durchführbar, aber bei einer GPU glaube ich nicht, dass man ohne Qualitätsverlust ex ante die nächsten 1000 Keyframes bestimmen kann.

[Spasstiger]

Man kann ja die Videos einfach zeitlich unterteilen. Wenn man z.B. 32 Prozessorkerne hat, teilt man das Video einfach in 32 gleichlange Abschnitte auf. Wenn ein Abschnitt fertig ist, kann ein anderer Abschnitt unterteilt werden, damit wieder alle Cores beschäftigt sind.
Wenn einige Keyframes durch das Splitten suboptimal platziert wurden, kann man diese immer noch im Nachhinein ändern. Dabei kann man die Arbeit auch wieder unter allen Prozessoren aufteilen.

[Mugen]

Ich hoffe der Thread-Ersteller ist nicht böse, wenn ich eine kleine Offtopic-Anmerkung zur Taktsteigerung von CPU´s anbringe, aber es passt weitestgehend zum Thema:

Als Spieler kommen mir Taktsteigerungen immer recht, aber der heutige PC
hat andere Flaschenhälse, die es zu beheben gilt:

-Problemfall Software:
Erstens sehe ich definitv die Software-Entwickler zur Zeit in der Bringschuld,
die Erfolge in der Pro-Mhz-Effizienzsteigerung und der Entwicklung der Mehrkern-CPU endlich in für den Normalanwender spürbare Leistung
umzuwandeln.

Denn seit meinem Umstieg von Athlon XP auf den Athlon X2 habe ich keinen deutlich spürbaren Leistungssprung erlebt, auch nicht nach dem Umstieg auf eine 3 Ghz Quadcore-CPU.
Und meiner Meinung nach liegt das an der mangelnden Flexibilität der Software-Entwickler zur Aufgaben-Parallelisierung in Ihren Produkten. Es mag gute Gründe dafür geben, aber dennoch sehe ich die Softwareentwickler unter Zugzwang. Das ist meine Sicht auf die Dinge als Allround-Anwender, der keine spezialisieren Anforderung an den PC wie z.B. bei Video/Bild/Ton-Bearbeitung stellt.

-Problemfall Festplatte:
Zweitens erhoffe ich mir den nächsten PC-Evolutionssprung durch die Masseneinführung der SSD in 2010, von der ich Ähnliches erwarte wie von dem Durchbruch der 1000 Mhz-Marke (durch bezahlbare CPU´s), die passenderweise vor ziemlich genau 10 Jahren stattgefunden hat.

Davon erhoffe ich mir deutlich mehr, spürbare Leistungssteigerung als durch den Sprung von 3 auf 4 oder 5 GHz beim Takt im CPU-Bereich. Die derzeitige Entwicklung deutet ja darauf hin.

[phil99]

Erwarte jetzt nicht von Softwareentwicklern, dass sie schnelle maschinennahe Codes produzieren.
Programmiersprachen, insbesondere die Hohen, sollen eine mathematische Logik aufbauen, die leicht zu programmieren ist und plattformübergreifend funktioniert.
Sie soll auch leicht nach Fehlern durchschaubar sien und erweiterbar.
Bei den riesen Datenmengen gilt es den Überblick zu behalten und einigermassen kostengünstig zu produzieren.
Bei grossen Projekten geht es auch gar nicht anders, weil sonst irgendwann niemand mehr wüsste, wo er was findet.
Es werden also immer mehr Programme entstehen, die erst zur Laufzeit in Maschinencode umgewandelt werden (bsp Java).
Nichtsdestotrotz wird es immer einen Bedarf nach schnelleren computer geben.

[Gast]

Hier mal der Link zu einer Seite die ich gestern gefunden habe:

http://www.zettaflops.org/

Die Artikel gehen ein wenig weit in die Zukunft (Zetaflops!!) sind aber imho ziemlich gut obwohl es sich um Sachen für Supercomputer handelt.

[Gast]

-Problemfall Software:
Erstens sehe ich definitv die Software-Entwickler zur Zeit in der Bringschuld,
die Erfolge in der Pro-Mhz-Effizienzsteigerung und der Entwicklung der Mehrkern-CPU endlich in für den Normalanwender spürbare Leistung
umzuwandeln.Wenn der Anwender keinen spürbaren Mehrwert durch die Anschaffung einer deutlich leistungsstärkeren CPU erfährt, sollte man eventuell auch in Betracht ziehen, dass er eine solche überhaupt nicht benötigt. Wieso sind die Softwareentwickler schuld, wenn Otto-Normal-DAU nicht schnell genug tippen kann, damit Word seine CPU aus dem Energiesparmodus holt? Etwas übertrieben vielleicht, aber dort, wo die Leistung wirklich benötigt wird, kann die Software meist auch das Potenzial der vorhandenen Resourcen nutzen. Außer es tritt eben der Fall ein, dass sich die Lösung eines Problems nicht weiter parallelisieren lässt. Daran ist aber in aller Regel nicht die Bequemlichkeit der Entwickler schuld und machen kann man da eigentlich auch nicht viel.
Denn seit meinem Umstieg von Athlon XP auf den Athlon X2 habe ich keinen deutlich spürbaren Leistungssprung erlebt, auch nicht nach dem Umstieg auf eine 3 Ghz Quadcore-CPU.
Und meiner Meinung nach liegt das an der mangelnden Flexibilität der Software-Entwickler zur Aufgaben-Parallelisierung in Ihren Produkten. Es mag gute Gründe dafür geben, aber dennoch sehe ich die Softwareentwickler unter Zugzwang. Das ist meine Sicht auf die Dinge als Allround-Anwender, der keine spezialisieren Anforderung an den PC wie z.B. bei Video/Bild/Ton-Bearbeitung stellt.Tja, wenn du da keinen Unterschied wahrnimmst, brauchst auch du derartige CPUs einfach nicht. Den Großteil der Zeit verbringt eine moderne CPU in einem Desktopsystem nunmal im Idle-Betrieb. Auch bei mir ist das so, z.B. während ich diesen Beitrag hier verfasse. Dennoch weiß ich nicht, was die Entwickler meiner gerade laufenden Software hier falsch gemacht haben sollen, da doch eher meine Reaktionsfähigkeit die Bremse darstellt. Dennoch bin ich froh, eine leistungsfähige CPU zu haben, sobald ich die Leistung dann benötige. Was genau bringt dich denn zu der Auffassung, dass dir aufgrund der fehlenden Flexibilität der Entwickler Leistung vorenthalten wird?
-Problemfall Festplatte:
Zweitens erhoffe ich mir den nächsten PC-Evolutionssprung durch die Masseneinführung der SSD in 2010, von der ich Ähnliches erwarte wie von dem Durchbruch der 1000 Mhz-Marke (durch bezahlbare CPU´s), die passenderweise vor ziemlich genau 10 Jahren stattgefunden hat.Hmm, gerade bei 1 GHz eine Grenze ziehen zu wollen, kommt mir doch ein wenig künstlich vor. Unter Verwendung eines halbwegs resourcenschonenden Browsers und Desktopumgebung kann ich auf meinem Thinkpad mit P3M (800 MHz) und 512 MiB SDRAM ebenso gut im 3D-Center stöbern wie hier am Desktoprechner mit einem hochmodernen Quadcore mit gut 3 GHz und 6 GiB DDR3-SDRAM. Sobald Leistung gebraucht wird, möchte man aber bestimmt nicht mehr vorm alten Notebook sitzen. Allein den Sprung zwischen meinem vorherigen Toledo-Dualcore mit 2,2 GHz und meinem jetzigen Core i7 mit über 3 GHz empfinde ich schon als riesig.

Andere Sache: 2010 halte ich für etwas früh für eine Einführung brauchbarer (!) Solid-State-Disks im Massenmarkt. Massenmarkt bedeutet günstige Preise. Wirf einen Blick auf die Preise leistungfähiger SSDs Anfang 2009 und es sollte klar werden, dass derartige Hardware nicht schon nächstes Jahr mit deutlich höheren Kapazitäten im Blödmarkt-Fertigrechner stecken wird.

[phil99]

Um mal von der ghz-Zahl wegzukommen. Wie ein Vorredner schon erwähnt hat, ist die GHZ auch deswegen stagniert, weil andere Architekturen, die bessere Leistung mit weniger Takt brachten, diese ablösten. Dier A64 war anfangs bei 2.00 ghz und ist jetzt bei 4 * 3 ghz. Wisst ihr noch, was die Athlons und ersten A64 für OC-Krücken waren. Damals war es schon gut, wenn man 20% geschafft hat. Heute sind 50% bei den kleinen Modellen keine Seltenheit.
Mich würde mal interssieren, was ein Kern bei gleicher Taktfrequenz noch an Steigerungen bringen kann.
Wie schnell wäre bsp ein Core des Quadcores mit 1 GB L1-Cache ?
Bringen da Verbreiterungen noch irgendwas, bsp mehrere Berechnungen hintereinander in einem Takt.
Und dann natürlich noch die Befehlserweiterungen, die geschickt programmiert ja auch enorm viel bringen SSE und Consorten.
Ich geh mal davon aus, dass die ständige Kernverdoppelung spätestestens bei 22 nm aufhören wird. Für 32nm sind ja meines Wissens auch nur 6 Kerne geplant. Vielleicht kann man die Transistoren einfach auch irgendwie puffern, so dass weniger Hitze entsteht.
Ich meine z.B. einen Kern, der in 32 nm genausogross ist wie in 45 nm, nur eben mit irgendwas dazwischen, vielleicht auch Cache. Dann wird die Wärme besser verteilt.
Irgendwann wird doch sicher der Bedarf nach einem sehr schnellen Thread steigen. Spätestens wenn wir irgendwann 128 Kerne im Desktoprechner haben, die man nur noch für ganz spezielle Aufgaben auslasten kann.
Was Festplatten betrifft; das ist wieder ein ganz anderes Thema. Auf jeden Fall werden wir in ein paar Jahren Officerechner zu Kleinstpreisen sehen, ähnlich wie heute Taschenrecher.
Also einfach ein kompakter Computer vom Fliessband mit der Leistung eines heutigen Hig-End REchners.

[Gast]

Wisst ihr noch, was die Athlons und ersten A64 für OC-Krücken waren. Damals war es schon gut, wenn man 20% geschafft hat.Ich hab meinen Slot1 Athlon damals von 500Mhz auf 950Mhz gebracht. Das war ok ;)

Heute sind 50% bei den kleinen Modellen keine Seltenheit.Sowas geht erst mit dem Core2 und wird sich mit dem i7 wieder schnell legen.

Ich geh mal davon aus, dass die ständige Kernverdoppelung spätestestens bei 22 nm aufhören wird.Die Kernverdopplung hat bis jetzt nur in wenigen Fällen etwas mit einer Leistungssteigerung zu tun.

Für 32nm sind ja meines Wissens auch nur 6 Kerne geplant.Dafür mit zweifach SMT, also 12 Threads. Das muß man erstmal beschäftigen KÖNNEN.

Ich denke bis 8 Ghz at stock werden wir es auch mit out of order noch schaffen. Das ist aber sowieso nicht das ausschlaggebende, weil diese muß noch mit Daten auch entsprechend schnell beliefert werden und die Ergebnisse auch entsprechend schnell speichern können.
Das wird die Effizienz bis dahin vielleicht auch noch verdoppeln.

Nehmen wir einen QX9770 mit 3.2Ghz als Vergleich. 8 Ghz und schnellere Anbindung zum Hauptspeicher machen dann mit Verschnitt eine 4x schnellere CPU pro Thread.

Mit den dann aktuellen GPUs hast du bei 30% der Rechenaufgaben noch eine Steigerung um das 5fache und mit VXT eine im Schnitt 3fache Steigerung bei ~35% der heute üblichen Rechenaufgaben. In einigen Fällen auch viel mehr. Pi mal Daumen und mit Verschnitt machts dann zusätzlich 30% des wie gesagt 4x schnelleren 1-Thread-Kodes nochmals 4x schneller.
Mit 6 Kernen hast du dann 12 Threads "gleichzeitig" in der CPU, also 8 mehr als beim QX9770.

Wie weit mußt du gehen um einen Desktop-Intel zu finden der nur halb so schnell war wie ein Kern eines QX9770? Welches Jahr war das?

Soweit zufrieden? Ich mir vorerst keine weiteren Gedanken darüber und vergeude die Rechenzeit meines 3.7 Ghz Wolfdale auch nicht weiter mit Fantasien, um mich für die kommenden Jahre vorzugeilen ;)
Hauptsache wir bleiben unter 100W pro Sockel :up:

Ich werde mich noch eine längere Zeit erstmal damit beschäftigen wer denn alles nun vernünftig MMX, SSE2 und wundersamerweise SSE4 einsetzt und für i686 mit -O2 kompiliert und dabei Profiling nutzt. Und warum es so wenige tun.

Dieser ganze "Was kommt denn noch alles nach 32nm? (strul ins Höschen)"-Kram ist angesichts dessen nur nervig.