Irgendwann wieder Single-Core?

[rx4711]

> Irgendein Forscher hat vor einigen Jahren mal gesagt, dass man
> bis - ich glaube - 2006 die 10 GHz-Marke erreichen wird.

Nein, das hat Intel bei der Einführung des P4 und der Net(b/w)urst-Architektur
behauptet ... um dann bei 3,6GHz Schicht zu machen ...


http://en.wikipedia.org/wiki/Pentium_4:

"At the launch of the P4, Intel stated NetBurst was expected to scale to 10 GHz (over several fabrication process generations). However, the NetBurst architecture ultimately hit a frequency ceiling far below expectation—the fastest retail Pentium 4 never exceeded 4 GHz. Intel had not anticipated a rapid upward scaling of transistor power leakage that began to occur as the chip reached the 90 nm process node and smaller. This new power leakage phenomenon, along with the standard thermal output, created cooling and clock scaling problems as clock speeds increased. Reacting to these unexpected obstacles, Intel attempted several core redesigns ("Prescott" most notably) and explored new manufacturing technologies. Nothing solved their problems though and in 2005-6 Intel shifted development away from NetBurst to focus on the cooler running Pentium M architecture. In March 2006, Intel announced the Intel Core microarchitecture, which puts greater emphasis on energy efficiency and performance per clock. The final NetBurst-derived products were released in 2006, with all subsequent product families switching exclusively to the Intel Core microarchitecture."

 

[sebko]

@ Odylases:

1. es heißt "sebko"
2. stimm ich Dir nicht zu: Nur weil es nur ein Core ist heißt das ja nicht, dass er erst fertig decodieren muss bevor er das andere anfängt. Dann macht er halt erst eine Operation für den einen, dann eine Operation für den anderen. Anstatt zwei Lahme mit jeweils einer der beiden Aufgaben zu beauftragen...
Dieser Aufwand wäre ja bestimmt geringer (also erst eine Operation für den einen, dann für den anderen) als eine Aufgabe die für einen gedacht ist 'künstlich' auf zwei zu verteilen.

 

[Relict]

@sebko
Der Grund ist, wie ich schon schrieb, das es z.Z. eben die technisch einfachste und schnellste Lösung zur weiteren Leistungssteigerung ist. Man hat seine Grenzen erreicht (Leistung, TDP ect.) und musste sich auf die Dinge, welche aktuell möglich und zumutbar sind konzentrieren. Man hat doch schon die Probleme am Presskopf gut gesehen. Dennoch ist auch die CPU-Entwicklung selber nicht stehen geblieben, trotz Multicore.
Es gab aber durch die Konzentration auf MC einen noch deutlicheren Leistungsruck. Jetzt ist die Softwareindustrie gefragt, die gegebene Hardware besser auszunutzen.

PS:
X x 12 GHz werden aber schneller sein, als 1x12 Ghz. So herum kann man an die Sache herangehen.
Natürlich hat alles irgendwo auch seine Grenzen. Momentan sind die aber noch nicht erreicht, zumindest in der Core-Anzahl.

 

[Drachton]

@sebko
Software die auf multicore aufbaut, teilt die Aufgaben nicht künstlich es ist "tatsache" das geteilt wird, dies würde somit keine Zeit in Anspruch nehmen um das ganze erst zu teilen.
Es ist so das ein SC, alle Operationen hintereinander reiht, bedeutet ... eine Operation wird geblockt wenn die vorhergehende im mom ausgeführt/berechnet wird. Der MC legt sich das ganze auf unterschiedliche Cores, die zwar ich stimme dir zu langsamer sind. Aber das *mal (Anzahl der Cores) schneller macht als der SC. Somit haben wir am Ende einen Zeitvorsprung des MC vor dem SC

Zu diesem Vorteil kommen noch die zusätzlichen Punkte Stromsparender, zur Zeit realisierbar ... usw. Geschweige den einen SC mit 12GHz zu kühlen, bzw die TDP ... O_o

 

[sebko]

@ Relict:

Das glaube ich Dir ja auch. Bin ja der gleichen Ansicht. Das war einfach jetzt der schnellere Weg, um an die Leistung zu kommen. Und hat auch klar Vorteile.

Ich wollte nur was zu der These mit der "Parallelisierung" sagen. Die ist nämlich bestimmt kein Grund, weshalb man LIEBER die Anzahl Cores erhöht als die Taktfrequenz.
Du schreibst ja selber genug andere Gründe dafür, die ich voll und ganz teile.

@ Drachton:

Ja klar, wenn das mal soweit ist. Und dann kommt aber das Problem hinzu: 1 Core bei 100 % der zweite bei 50 %... Da wär der Single Core, trotz blocken wieder schneller, weil er ja auch auf 100 % laufen könnte. Du beschreibst ja einen Idealfall.
Außerdem: "Parallelisierung" von der ich spreche, bedeutet, etwas nicht paralleles parallel zu machen. Ist also kein Widerspruch zu dem, was Du sagst.

 

[rx4711]

> @sebko
> Software die auf multicore aufbaut, teilt die Aufgaben nicht künstlich es ist "tatsache" das
> geteilt wird, dies würde somit keine Zeit in Anspruch nehmen um das ganze erst zu teilen.

Das stimmt so einfach leider nicht.
Es gibt nämlich beides. Wenn zwei Tasks unabhängig voneinander sind, dann laufen sie
auf zwei Cores sehr effizient.
Aber in den allermeisten Fällen müssen Aufgaben aufgeteilt werden und die Cores
arbeiten dann zusammen, um eine Aufgabe zu erfüllen ... und hier hat sebko recht.
Ein SingleCore wäre oft effizienter.



> Es ist so das ein SC, alle Operationen hintereinander reiht, bedeutet ... eine Operation
> wird geblockt wenn die vorhergehende im mom ausgeführt/berechnet wird. Der MC legt
> sich das ganze auf unterschiedliche Cores, die zwar ich stimme dir zu langsamer sind.
> Aber das *mal (Anzahl der Cores) schneller macht als der SC

Wie oben geschrieben stimmt das nur, wenn man über voneinander unabhängige Aufgaben redet.
In den allermeisten Fällen ist das aber nicht gegeben und ein SC 4GHz wäre bei einer Aufgabe,
die aufgeteilt werden muss, schneller.


Aber das Ganze spekulieren nützt nix, denn man kann den Takt nicht beliebig weit steigern.
Irgendwann treten physikalische Grenzen (Leckströme, Wärmestau, Laufzeiten der Signale
auf dem Chip, ...) verstärkt zutage, die eine weitere Taktsteigerung unmöglich machen.

Siehe auch den Wikipedia-Link zum Pentium4, den ich oben gepostet habe ...

 

[iKantholz]

ich denk auch, bei x86 wirds irgendwo bei quad oder okta bleiben - zumindest bis 2010/12

Wenn man über den Tellerrand guckt, siehts bereits heute ganz anderst aus!

Der Cell besitzt schon heterogene Kenre, die auf unterschiedliches spezialisiert sind. In die Richtung könnts in ein paar jahren auch bei x86 gehen. CPUs mit Grafikcore sind ja schon in Planung.

Anderst macht es IBM im Moment beim Power6. Der ist zwar auch Dual Core, aber auf 6GHz hochgejubelt und verbläst deshalb aktuelle Intels um weiten.

Den radikalsten (und sehr erfolgreichen) Ansatz verfolgt SUN mit dem Niagara2:
Hier teilen sich acht Cores den L2 Cache, den Memory Controller und sogar sämtliche ALUs und FPUs.
Das heißt der Prozessor konfiguriert sich zur Laufzeit um: Wenn ein Prozess viele Berechnungen macht bekommt er einfach die Rechenwerke des gesamten Prozessors.
Nebenbei sind PciE sowie zwei 10GBit NICs schon
auf dem Die integriert. Und in zwei Jahren gibts das Ding wohl dann mit 32 Cores!

 

[Mike Lowrey]

@ rx4711

Stimmt Intel hat dies genannt, allerdings sollte man vielleicht auch bedenken, dass die Architektur theoretisch für höchst Taktraten gemacht ist die Pipeline ist glaube ich 32 stufig die des C2D glaube ich 14 und die des AMD Barcelona nur 12 stufig.

Insofern war die Grundlage wohl da, dass es letztlich an zu hoher Hitze gescheitert ist steht auf einem anderen Blatt.

Ach ja ich bin kein Intel Fanboy

@ sebko

Ich versuche mal zu erklären, warum ich denke das MC effektiver zu nutzen ist als SC.

Wenn man davon aus geht, dass ein Programm viele Aufgaben hat die alle von einander abhängen, so kann ein MC pro Kern eine dieser Aufgaben bewältigen nach Schritt eins wird abgeglichen danach gehts weiter sagen wir alle Aufgaben brauchen 9 Sekunden wir haben 3 Cores und wir haben 3 Aufgaben (pro Schritt) ein Core kann braucht also pro Aufgabe 9 Sekunden ein SC braucht pro Aufgabe nur 3 Sekunden.

In diesem Rechenbeispiel ist der SC dem MC nicht überlegen andersherum genauso. Jetzt erhöhen wir das ganze um den Faktor 10 der MC wird gleich bleiben allerdings müsste der SC jetzt alles in 3/10 Sekunden schaffen und hier sind die physikalischen Grenzen eher problematisch als 90 Kerne zu bauen.

 

[Odylases]

@ sebko

sorry, name korrigiert :-)

gut, zugegeben, das Beispiel war nicht sooo toll gewählt, denn der Single machts ja auch so das er von der einen Aufgabe auf die andere switcht und wieder zurück. Aber starte mal ne codierung und gleichzeitig nen Spiel mit nem SingleCore. Da kannst das spielen vergessen.
Bei nem Multi mit gleicher Leistung hingegen sieht das ganz anders aus.

Wobei sich mir der Sinn eines Multicores auch erst bei mehreren verschiedenen Anwendungen erschließt.
Bei einer Anwendung ist es wohl die technische momentan Machbarkeit und das physikalische Limit was hierbei zum Multi treibt.

 

[sebko]

>


Aber das Ganze spekulieren nützt nix, denn man kann den Takt nicht beliebig weit steigern.
Irgendwann treten physikalische Grenzen (Leckströme, Wärmestau, Laufzeiten der Signale
auf dem Chip, ...) verstärkt zutage, die eine weitere Taktsteigerung unmöglich machen.

Solche Aussagen sind IMO zu pauschal. Wie oft haben wir sowas in der Elektronik schon gehört? Sei es mit Arbeitsspeicher oder mit HDDs (es ist physikalisch nicht mehr möglich, noch mehr Daten magnetisch zu speicher, weil die Dichte schon so hoch ist bla bla bla...nur noch mehr Platten bla bla bla...)

Also MÖGLICH ist grundsätzlich immer alles. Die Frage ist, was ist vom jetztigen Standpunkt aus schneller und effizienter zu erreichen? Wo muss erst noch geforscht und entdeckt werden?

@ Mike Lowrey:

Ja klar müsste er dann 10 mal schneller sein. Aber das war doch genau meine Prämisse??! Und was nun leichter zu erreichen ist, darüber mache ich gar keine Aussage. Bin ja selber davon überzeugt, dass mehr Kerne erstmal leichter zu "bauen" sind. Ist ja auch alles gut so...

 

[Spock37]

Der Singlecore ist tot ... daran wird sich auch nix mehr ändern
Egal wieviel GHz ein Singlecore hat, bei Aufgaben die gleichzeitig ausgeführt werden bekommt er seine Probleme; das liegt nicht an seinem Speed, sondern vielmehr an der gleichzeitigen Bearbeitung von Anfragen. Das kann er eben viel schlechter als eine Multicore-CPU

Das stimmt nicht unbedingt. Ein Scheduler, der Aufgaben auf zwei Kerne verteilen muss, braucht erstmal mehr Overhead als einer, der nur Threads für einen Kern sortiert.

Das Problem ist nur, daß der Windows-NT-Scheduler so schlecht ist. Ohne die Weigerung von Microsoft, den Scheduler zu verbessern, hätte es keine Notwendigkeit für Multi-Core-CPUs in Consumer-PCs gegeben. Aber nachdem Intel mit der Taktfrequenz-Strategie gescheitert war und ausschließlich noch den Vorteil des Fertigungsvorsprungs verbuchen konnte, spielte das Multi-Core-Konzept durch den doppelten Platzverbrauch Intel natürlich in die Hände.

Im Linux-Kernel hat es in den vergangenen Jahren mehrere Wechsel des Schedulers gegeben um Verbesserungen zu erzielen, mit der Konsequenz, daß man problemlos Desktop-Multitasking machen kann OHNE eine Multicore-CPU besitzen zu müssen. Kompilieren, Webseiten lesen, nebenbei DivX-Filme ansehen - all das ging schon problemlos auf meiner alter 433 MHz-CPU mit Kernel 2.4.

 

[Relict]

@sebko
Aber auch Dein letztes Argument kann ich nicht ganz teilen.

Nur weil es nur ein Core ist heißt das ja nicht, dass er erst fertig decodieren muss bevor er das andere anfängt. Dann macht er halt erst eine Operation für den einen, dann eine Operation für den anderen. Anstatt zwei Lahme mit jeweils einer der beiden Aufgaben zu beauftragen...
Dieser Aufwand wäre ja bestimmt geringer (also erst eine Operation für den einen, dann für den anderen) als eine Aufgabe die für einen gedacht ist 'künstlich' auf zwei zu verteilen.

Die Aufgabe wird ja in keinem Falle schneller erledigt, nur weil ich sie unterbreche und in der Zeit eine andere Aufgabe mache. Am Ende bleiben beide Aufgaben nur halb so schnell oder eine zieht eben immer den kürzeren. Bei einer weiteren CPU kann jede Aufgabe quasi auf die volle Leistung der CPU durchgehend zurückgreifen, sofern sie nicht voneinander stark abhängig sind.
Das mit den 2 lahmen CPUs finde ich auch etwas weit hergeholt. Auch ein Dualcore mit nur einem Kern wäre nicht merklich schneller. Der Verwaltungsaufwand zwischen den CPUs steigt auch erst bei viel mehr Kernen merklich an, bei 2-4 ist dass nicht erwähnenswert . Das ist also auch kein großartiges Argument für SC. Selbst wenn ab einer bestimmten Anzahl Cores 1 CPU nur für die Verwaltung zuständig wäre, hätte man ja immer noch die Mehrleistung der restlichen.

Dem Wunsch nach schneller und deutlicher Mehr-Leistung wurde durch MC begegnet. Die Geschwindigkeitssteigerung für jeden einzelnen Kern bleibt natürlich weiterhin eine technische Herausforderung. Man ist daher erstmal einen Schritt (GHz) zurückgegangen, um anschliessend 3 Schritte voranzukommen.

 

[Mike Lowrey]

@ sebko

Stimmt das war sie, ich habe auch nichts anderes gesagt, ich habe ja als Fazit genannt, dass nur durch die leichtere Erweiterbarkeit der Vorteil für MC da ist.(und man sollte bedenken auch ein MC kann theoretisch hohe Taktraten erreichen.)

 

[sebko]

Die Aufgabe wird ja in keinem Falle schneller erledigt, nur weil ich sie unterbreche und in der Zeit eine andere Aufgabe mache. Am Ende bleiben beide Aufgaben nur halb so schnell oder eine zieht eben immer den kürzeren. Bei einer weiteren CPU kann jede Aufgabe quasi auf die volle Leistung der CPU durchgehend zurückgreifen, sofern sie nicht voneinander stark abhängig sind.

Doch wird sie, weil ich sage, dass der eine Core doppelt so schnell ist wie jeweils einer der Dualcores.

Aber irgendwie glaub ich, ich werden hier missverstanden Ich bin doch kein MultiCore Gegner, will doch nur sagen, dass theoretisch ein doppelt so schneller Kern besser ist, als 2 "lahme"...

 

[Drachton]

@rx4711
Wo haben wir größtenteils gleiche Aufgaben? ... Word, Excel, Nero ...? Das kann auch auf einem Core laufen. Ich denke wir haben vorwiegend unterschiedliche Aufgaben für die CPU, daher ja auch der Vorteil für den MC. Was würde es bringen Word auf multicore zu optimieren, eben gar nix ..
Oder ich verstehe deinen Post nich, ...

@Spock37
Dein Einwand ist gut, .. das stimmt --> Zwickmühle

 

[Enigma]

Ich find eure komplette Argumentation falsch. Es geht hier nicht um die Frage 12 GHz vs. 4x3 GHz sondern eher um: 1x 12 GHz vs. 4x 10 GHz. Die Taktlimitierung hat fertigungstechische Gründe welche auf physikalischen Eigenschaften basieren. Da sich Single und Moulticore Prozessoren nicht von ihrer Architektur unterscheiden werden, wird nicht passieren, dass man einen Single-Core-Prozessor um welten höher Takten kann als einen Multicore-Prozessor.

 

[Relict]

Eine weitere Leistungssteigerung erreicht man natürlich auch durch die Software. Die hinkt ja bislang sowohl für SC, als auch MC hinterher und könnte effizienter sein. Da wird nicht unerhebliches Potenzial verschenkt. Der Trend läuft aber seit Jahren eher in die andere, ressourcenverschwende Richtung. Da kann dann auch die Hardware nicht mehr viel richten bzw. das Verhältnis stimmt einfach nicht. Beide müssen also zusammenarbeiten. Einseitig nur immer mehr GHz zu fordern kann daher garnicht aufgehen.

 

[sebko]

Natürlich geht es nicht um diese Frage. Man muss ja sehen, was man auf dem Markt bekommt und was am schnellsten zur Leistungssteigerung führt.
Es geht ja darum, wenn man die WAHL hätte, was würde man bevorzugen, 1 x 12 oder 4 x 3? Ganz abgesehen davon, dass die Parallelisierung, wie ich das sehen, IMMER limitiert ist. Der Takt ist theoretisch nicht limitiert. Heute vielleicht schon, nächstes Jahr wird was neues erfunden ...

@ Relict:

Sehr guter Punkt. Wenn die heute noch so aufwendig Grafik programmieren würden, wie damals mit dem C64 bräuchten wir keine 3D-Beschleuniger sondern hätte auch so geniale Grafik und Crysis würde flüssig laufen

Nee, mal im Ernst: Klar hast Du Recht. Der Ressourcenhunger der heutigen Software ist manchmal nichtmehr feierlich...

 

[Enigma]

Dann kann ich dir nur nochmal ans Herz legen, dich genauer mit dem Thema zu beschäftigen, dann weisst du dass die Frage hinfällig ist. Du wirst dich diesem Problem nie stellen müssen, dass du niemals die Wahl zwischen beiden Optionen haben wirst.

Und wenn du dir die Benchmarks mal genauer ankuckst, merkst du dass ein Dualcore mit gleicher Taktrate mehr als doppelt so schnell sein kann wie ein Single Core. Zwar nicht von der rohen Rechenleistung, aber das Betriebssytem könnte die Arbeiten etwas bequemer verwalten. Das ganze Multicorethema ist extrem komplex. Ob und wieviel das Betriebssystem da rausholen kann, kann ich dir leider nicht kompetent beantworten.

 

[sebko]

Ich sagte, wenn man eine Wahl hätte... Das man sie nicht hat, ist mir auch klar.

Und wenn du dir die Benchmarks mal genauer ankuckst, merkst du dass ein Dualcore mit gleicher Taktrate mehr als doppelt so schnell sein kann wie ein Single Core. Zwar nicht von der rohen Rechenleistung, aber das Betriebssytem könnte die Arbeiten etwas bequemer verwalten.

Willst Du mich nicht verstehen? Ich sage nicht "gleiche Taktrate", sonder DualCore mit "halber Taktrate". Darum geht es mir.

Gehen wir es doch mal etwas lockerer und mit etwas mehr Humor an:

Jeder der für DualCore mit halber Taktrate ist hebe jetzt die Hand! .... sehr schön.
Ihr bekommt also 2 x eine 8600 GT im SLI

Alle anderen bekommen eine 8800 GTX.

Jetzt starten wir mal Crysis auf High und schauen, was passiert...