Warum keine "virtuellen" Singecores?

[MasterElwood]

Multicore cpu´s dümpeln bei nichtoptimierter Software immer gelangweilt herum, während Singlecore Cpus immer 100% Auslastung haben (wenn gebraucht).

Darum meine Frage (als Laie): Warum geh ich nicht zurück zur SingelCore Idee?

Warum macht Intel keinen Controlerchip, der sich dem Betriebssystem als "Singlecore" ausgibt und die Arbeit die kommt auf die 2, 4, 6 oder was auch immer vorhandernen Cores dynamisch aufteilt, so das alle immer gleich ausgelastet sind?

Die Funktion einer Cpu ist doch relativ einfach:

Hole Arbeit, Führe arbeit aus, nächster Takt
Hole Arbeit, Führe arbeit aus, nächster Takt
Hole Arbeit, Führe arbeit aus, nächster Takt
Hole Arbeit, Führe arbeit aus, nächster Takt... usw


Warum setzt ich da jetzt keinen Controlerchip dazwischen der macht:

Hole arbeit, weise Arbeit nächstem fertigen Core zu, nächster Takt... usw.


Selbst wenn ich durch verwaltung ect. ca. 10% verlieren würde, hätte ich mit dieser Methode egal bei welchen Anwendungen z.B. einen QuadCore IMMER zu 90% ausgelastet wenn gebraucht!

Wär das nicht der hammer? Das muss doch technisch machbar sein, oder?


MasterElwood

[Ganon]

Und was machst du wenn das Ergebnis der einen Arbeit für die darauffolgende Arbeit benötigt wird? ;) Vllt. erkennst du jetzt das Problem.

[ShadowXX]

Multicore cpu´s dümpeln bei nichtoptimierter Software immer gelangweilt herum, während Singlecore Cpus immer 100% Auslastung haben (wenn gebraucht).

Darum meine Frage (als Laie): Warum geh ich nicht zurück zur SingelCore Idee?

Warum macht Intel keinen Controlerchip, der sich dem Betriebssystem als "Singlecore" ausgibt und die Arbeit die kommt auf die 2, 4, 6 oder was auch immer vorhandernen Cores dynamisch aufteilt, so das alle immer gleich ausgelastet sind?

Die Funktion einer Cpu ist doch relativ einfach:

Hole Arbeit, Führe arbeit aus, nächster Takt
Hole Arbeit, Führe arbeit aus, nächster Takt
Hole Arbeit, Führe arbeit aus, nächster Takt
Hole Arbeit, Führe arbeit aus, nächster Takt... usw


Warum setzt ich da jetzt keinen Controlerchip dazwischen der macht:

Hole arbeit, weise Arbeit nächstem fertigen Core zu, nächster Takt... usw.


Selbst wenn ich durch verwaltung ect. ca. 10% verlieren würde, hätte ich mit dieser Methode egal bei welchen Anwendungen z.B. einen QuadCore IMMER zu 90% ausgelastet wenn gebraucht!

Wär das nicht der hammer? Das muss doch technisch machbar sein, oder?


MasterElwood
Ist technisch nicht machbar....der Grund ist auch ganz einfach: du kannst nicht etwas parallelisieren, was nicht parallelisierbar ist.

Ganz einfaches Beispiel:
1. A + B = C
2. D + C = E
3. F = E + C

kann man nicht parallelisieren, da in jedem Schritt Abhängigkeiten bestehen.
Leider gottes bestehen Programme zu großen Teilen aus Abschnitten die voneinander Abhängig sind, als immer das Ergebnis des Abschnitts davor brauchen.

Davon abgesehen: heutzutage können nicht mal die Compiler ohne kleine Hilfen vom Menschen automatisch (ordentlich) parallelisieren und du möchtest jetzt das das die CPU in Echtzeit nebenbei macht.

[huha]

Darum meine Frage (als Laie): Warum geh ich nicht zurück zur SingelCore Idee?

Warum macht Intel keinen Controlerchip, der sich dem Betriebssystem als "Singlecore" ausgibt und die Arbeit die kommt auf die 2, 4, 6 oder was auch immer vorhandernen Cores dynamisch aufteilt, so das alle immer gleich ausgelastet sind?d

Weil's nicht geht. Ein Beispiel:

Wir wollen ein Spiegelei machen und haben dafür fünf Köche.
Die Vorschrift, wie man ein Spiegelei macht, sieht etwa so aus:

1) Gieße Öl in eine Pfanne
2) Stelle die Pfanne auf den Herd und mache sie warm
3) Schlage ein Ei herein
4) Warte, bis das Ei angebraten ist
5) Gib das Spiegelei auf einen Teller.

Ein Koch kriegt das relativ problemlos hin, aber die anderen vier langweilen sich. Würde man jedem Koch nun jeweils einen Schritt zuweisen, hätte man nachher eine Pfanne mit Öl, eine warme Pfanne ohne Öl, ein kaltes Ei auf dem Herd, einen Koch, der darauf wartet, daß das Ei angebraten ist und einen, der mit einem Teller rumsteht und ebenfalls wartet. Durch "naive" Parallelisierung ist unser Algorithmus also völlig unbrauchbar und wertlos geworden und führt keineswegs zum erwünschten Ergebnis.

-huha

[Spasstiger]

Die heutigen CPU-Kerne sind intern schon parallel aufgebaut und haben mehrere Ausführungseinheiten und Verwaltungseinheiten, welche die Instruktionen den Ausführungseinheiten zuweisen. Aber das funktioniert eben nicht beliebig gut. Offenbar ist es günstiger, die Parallelisierung in Software durchzuführen und einfach mehrere CPU-Kerne auf einen Chip zu klatschen. Die einzelnen Kerne noch breiter zu machen, scheint nicht so effizient zu sein.

Aber es kann sein, dass bei zwei- und dreistelligen CPU-Kern-Zahlen tatsächlich noch eine weitere Verwaltungsschicht in Hardware kommt. Man kann die Kerne dann z.B. auslasten, indem man spekulativ rechnet. D.h. bei Sprüngen im Code, bei denen man noch nicht weiß, ob die Sprungbedingung erfüllt ist oder nicht (weil das Ergebnis für die Bedingung noch parallel auf einem anderen Kern berechnet wird), rechnet ein Core einfach die eine Verzweigung und ein anderer Core die andere Verzweigung. Und wenn das Ergebnis der Sprungbedingung bekannt ist, nimmt man einfach die Ergebnisse von der korrekten Verzweigung.

[PatkIllA]

@MasterElwood
Das passiert schon innerhalb eines Cores. Und da ist schon verdammt viel Gehirnschmalz reingeflossen, so dass pro Takt mehr als eine Aufgabe abgearbeitet wird.

[S940]

Warum macht Intel keinen Controlerchip, der sich dem Betriebssystem als "Singlecore" ausgibt und die Arbeit die kommt auf die 2, 4, 6 oder was auch immer vorhandernen Cores dynamisch aufteilt, so das alle immer gleich ausgelastet sind?
Such mal nach "reversed Hyperthreading" oder anti-hyperthreading. War mal vor ein paar Jahren aktuell, da AMD da ein paar Patente in die Richtung einreichte:

Pat.No:6,574,725
Gib die einfach mal in http://www.pat2pdf.org/ ein, dann kannst Dus durchlesen.


Die hier arbeiten an nem ähnlichen Ansatz:
http://pages.cs.wisc.edu/~mscalar/overview.html

Allgemein finde ich mit meinem Laienwissen, dass ein dicker, richtiger Einzelkern mit Hyperthreading der elegantere & bessere Ansatz ist. Nur blöd dass die ganzen Hyperthreading CPUs bisher nur alte Designs waren, auf die dann Hyperthreading aufgepropft wurde. Wies richtig gehen würde sieht man am Alpha EV8 Design:

Teil 1: http://www.realworldtech.com/page.cfm?ArticleID=RWT121300000000
Teil 2: http://www.realworldtech.com/page.cfm?ArticleID=RWT122600000000
Teil 3: http://www.realworldtech.com/page.cfm?ArticleID=RWT011601000000


ciao

Alex

[BlackBirdSR]

Such mal nach "reversed Hyperthreading" oder anti-hyperthreading. War mal vor ein paar Jahren aktuell, da AMD da ein paar Patente in die Richtung einreichte:

Pat.No:6,574,725
Gib die einfach mal in http://www.pat2pdf.org/ ein, dann kannst Dus durchlesen.
Alex

Das ist doch kein Reverse-SMT...

[S940]

Das ist doch kein Reverse-SMT...
Gab noch 2-3 weitere Patente, hab da aber die Links nicht mehr.
Auf alle Fälle lief das damals unter dem "reverse-HT" Schlagwort durch die Foren, bist doch auch schon lange aktiv und kannst Dich sicher daran erinnern.

Ansonsten kommts wohl darauf an, was man darunter versteht, mir reicht der Abstract für die Bezeichnung "reverse-HT"
http://www.bilder-space.de/upload/IkunPo3P3Othkv4.gif

Soll heißen, das OS sieht nur 1 CPU und der CPU-Scheduler verteilt die Datenschnippsel (nicht nur eigenständige Threads) an alle angebundenen CPUs.

ciao

Alex

[BlackBirdSR]

Auf alle Fälle lief das damals unter dem "reverse-HT" Schlagwort durch die Foren, bist doch auch schon lange aktiv und kannst Dich sicher daran erinnern.
Türlich. War damals schon Quatsch und Wunschdenken.



Soll heißen, das OS sieht nur 1 CPU und der CPU-Scheduler verteilt die Datenschnippsel (nicht nur eigenständige Threads) an alle angebundenen CPUs.

ciao

Alex

Trotzdem keine Bündelung von Multi-Core-Ressorucen zu einem Logischen Core, der an nur einem Thread arbeitet. Das wäre dann Reverse-MT.
Das hier ist einfach die Verlagerung der Schedulerfunktionen auf CPU-Logik mit Softwareunterstützung. Man verschiebt nur den Abstraction-Layer. Das ist interessant, aber kein "Reverse-HT"

[Bandolero]

denke folgendes wird sich ergeben, wenn intel mit der manycore-Strategie irgendwann mal einsieht, das sich nicht alles beliebig parallelisieren lässt und die Fertigung an ihre atomaren Grenzen gelangt:
Man baut wieder so etwas wie einen singlecore mit einigen extrem hochgetakteten Funktionseinheiten (20-30Ghz) und einigen moderat getakteten Einheiten(0,5-2Ghz), die Erfahrung zeigt, daß es meist nur einige wenige Teil-Operationen sind, die unglaublich viel CPU-Leistung fressen, die Compiler und Programmierung werden entsprechend angepasst, et'voila.
Diese CPU wird dann wieder auf dualcore bzw. manycore zusammengeklebt etc. pp. aber ich zweifle mal, daß Privatanwender jemals mehr als 8 core-cpus in ihren Heimsystemen finden werden(selbst >4 wird die Ausnahme bleiben).

[Odal]

genau das ist immer die sache wo viele auf dem holzweg sind (warum eigentlich)

viele cores = viel schneller

anwendungen sind oftmals kaum parallelisierbar (aus genannten gründen)
beim wechsel singlecore -> dualcore konnte man noch ein relativ grosses leistungsplus ermessen, eben weil diverse hintergrunddienste auf einem seperaten core laufen konnten, sobald mal eine cpu fressende anwendung gestartet wurde

solange ein rechner nicht massiv unter mehrbenutzerbetrieb steht wird sich mit erhöhung der "core anzahl" nur wenig mehrleistung herauskitzeln....

darum ist das argument das privatanwender recht wenig nutzen von stetiger "core anzahl erhöhung" haben werden, durchaus berechtigt.
Allein Quadcores auszulasten ist ja schon problematisch...ausser man encodet, kompiliert und spielt was gleichzeitig.

Die einzige Möglichkeit für den Hausgebrauch immer mehr Cores sinnvoll zu nutzen ist eben für stark parallelisierbare Anwendungen. GPUs sind intern sehr "Multicore" (Allus) darum geht Intel ja den Weg eine CPU Architektur sehr stark zu parallelisieren um diese als Grafikhardware herzunehmen.

Wenn es im CPU Geschäft noch so rosige Aussichten bzgl. Mehrkern geben würde bräuchten sie das nicht. Aber so ist es halt schwer einem Käufer einen 8-Kern und das Jahr drauf einen 16-Kern Prozessor aufzuschwatzen wovon er meist nur 2 Kerne nutzen kann.
CPU Effizienz lässt sich halt nur noch sehr langsam und mühsam steigern (Caches, integrierter Speichercontroller etc.) und bei den Taktraten kommt man bei einer effizienten und komplexen Architektur auch nicht schnell viel höher.

[BlackBirdSR]

genau das ist immer die sache wo viele auf dem holzweg sind (warum eigentlich)

viele cores = viel schneller



Für uns Homeuser ist die Sache sicherlich eine Sackgasse. Allerdings wird Intel nicht vom Gamer, sondern vom Server/HPC/Workstation-Markt angetrieben. Dort werden wir in Zukunft immer weitere Steigerungen sehen. 8-16-32-64...
Die Frage ist nun: Schwimmt der Consumer-Markt mit, ohne dass man große Vorteile daraus ziehen würde, oder bekommen wir Home-User demnächst unser eigenes Süppchen mit 4-8 Kernen und eigener Architekturentwicklung?

[pool1892]

Man kann zeigen, dass es bei vielen komplexeren Workloads ein lokales Minimum gibt, so dass der der Verwaltungsaufwand stärker als der Speedup wächst, ziemlich genau bei 16 Kernen liegt da die Grenze. Wirklichen Speedup für diese Applikationen gibt es dann erst wieder ab etwa 100 Kernen, wo man feingranularer zerlegen kann.
Apple arbeitet an Grand Central, das womöglich so etwas wie der vom OP vorgeschlagene Steuerchip nur ohne Chip sein könnte.
EPIC im Itanium ist auf Compilerlevel so was ähnliches - äh, ganz grob gesprochen...
Im allgemeinen gilt, dass der meiste Gewinn für echte nichtparallelisierbare Probleme durch Sprungvorhersage erzielt werden kann und durch Raten von ERgebnissen und Vorberechnen aller möglichen Lösungen. Letzteres ermöglicht natürlich bei naiver Betrachtung unendliche Zugewinne - also eine unendlich breite unendlich tiefe Maschine berechnet alles in einem Schritt...aber der Aufwand wächst viel schneller als der Speedup.
Die Komplexitätstheorie beschreibt diese Ratespiele anschaulich, zum Beispiel als Orakel oder Nichtdeterminismus. Es ist im Allgemeinen ungeklärt, ob das Raten "wirklich" was bringt, also ob die lösbaren Probleme echt schwerer sind (wenn die sonstigen Ressourcen gleich bleiben). Es könnte sein, dass es gar keine relevanten nichtparallelisierbaren Probleme gibt, wenn man praxisnahe Beschreibungen wählt. (Stark übertrieben gesprochen)

Im Moment gilt allerdings, dass intrakernig 4-fach Parallelität zählt und 5 Einheiten schon nicht mehr effektiv genutzt werden können, ohne die Vorhersageeinheit zu vergrößern.

[S940]

Trotzdem keine Bündelung von Multi-Core-Ressorucen zu einem Logischen Core, der an nur einem Thread arbeitet. Das wäre dann Reverse-MT.
Das hier ist einfach die Verlagerung der Schedulerfunktionen auf CPU-Logik mit Softwareunterstützung. Man verschiebt nur den Abstraction-Layer. Das ist interessant, aber kein "Reverse-HT"
Ist die Frage was das jetzt ist, die reden da ja von "shorter segments of code", das ist für mich kleiner als ein thread, wie siehst Du das ?

Die Frage ist nun: Schwimmt der Consumer-Markt mit, ohne dass man große Vorteile daraus ziehen würde, oder bekommen wir Home-User demnächst unser eigenes Süppchen mit 4-8 Kernen und eigener Architekturentwicklung?Der Cunsumermarkt wird mitschwimmen, durch die CPU+GPU Integration, siehe Larrabee, Fusion und OpenCL (und dessen M$ Gegenpart).

@pool1892:
Was meinst du mit 4-fach Parallelität ? Superskalar ? So ein Kern ist etwas komplizierter aufgebaut:
Aus nem Core2 <> K10 Vergleich

1. Instruction decode (in micro-ops): 10 vs. 6
2. Execution pipeline (in micro-ops): 6 vs. 9
3. Instruction retire (in fused micro-ops/macro-ops): 4 vs. 6

Who is the winner? The answer is: we really don't know!
http://abinstein.blogspot.com/2008/09/two-sides-of-mirror-on-k10-vs-core2.html

ciao

Alex

[pool1892]

ja, s940, ich mein einfach nur superskalarität. das ist die anzahl an x86-instructions, die pro takt maximal verarbeitet werden, also genau das, was die software erwarten kann - somit wohl die einzig verlässliche größe, wenn man global draufschaut.
core ist 4fach superskalar, k8 3-fach (k10 auch, glaub ich).
die interne repräsentation und weitere zerlegung und das rescheduling und sogar die fusion von microops zu neuen macroops, die keine abhängigkeiten haben: das sind alles interne tricks, von denen keiner sonst was sieht, zumindest meistens (außer auf powerpoints).
das ganze ist ein wenig anders bei den vektoreinheiten (sse) und anderen x86 erweiterungen.

ich geh da jetzt von nem vereinfachten modell aus, natürlich stecken noch ganz viele tricks in so nem kern. ich denk eher grobarchitekturell, ich bin halt mathematiker und kümmer mich um die prinzipien^^

cooler link, btw

[S940]

somit wohl die einzig verlässliche größe, wenn man global draufschaut. Jein, die Sache mit der Superskalarität ist immer so ne Sache, hab mich mal vor nem Jahr schlau gemacht, und festgestellt, dass die ganzen Seiten das nur in der Bedeutung von 4 gleichzeitig verwertbaren INT Instruktionen verwenden. FPU und SSE/Vector oder sonstige Einheiten interessiert irgendwie keinen.

Von daher hab ich mir abgewöhnt mit dem Superskalar zu hantieren, und schau immer das Trio aus Decode-Exec-Retire an, was auch der Blogkollege von oben gepostet hat. Damit kann man nix falsch machen ;)

Der Blog gefällt mir auch ganz gut, hier ist z.B. interessant, wie er schreibt, dass der 4te Dekoder des Core2 nicht viel bringt:
The real "weapon" the Core 2 Duo has against this branch-related inefficiency is not the 4-wide decoder, but a pre-decoded instruction queue of up to 18-deep x86 instructions. Refer to Part 1 article's first diagram on P6's Instruction Fetch Unit. There is a 16-byte wide, instruction boundary aligned Instruction Buffer sitting in-between the IFU and the decoders. Replacing this buffer with an 18 instruction-deep queue (probably 24 to 36 bytes in size) that can detect loops among the containing instructions, we get Core 2 Duo's biggest advantage with respect to x86 decode: ability to sustain continuous decode stream on short loops.
http://abinstein.blogspot.com/2007/06/decoding-x86-from-p6-to-core-2-part-3.html

Könnte mir vorstellen, dass da auch ein Teil der SuperPi Performance auf den angesprochenen Loop Detektor geht, was andres kanns (ausser dem großen L2 Cache) bei dem alten 586er Code eigentlich gar nicht sein.

Irgendwo im Netz hatte ich auch mal ne Kurve von 1-2-3-4 Decodes gesehen. Der Sprung von 1->2 bringt ziemlich viel, von 2->3 .. naja ... und danach kann mans eigentlich vergessen, da die Kurve katastrophal abflacht. Vom Aussehen her wie ne Art Ln Funktion.

ciao

Alex

[pool1892]

braucht denn der superpi algo nicht quadratwurzeln an zentraler stelle? die lassen sich doch nicht soeben mal loopen auf microopebene, oder? und hinter den dingern hängt die pipeline, weil ja alles davon abhängt.
puh, hab gerad mal schnell die intel cpu optimization guides durchgesehen, ich würde sagen, dass die verbesserung bei so einem algo tatsächlich stark am cache liegt und an der verbesserten prefetch- und predictionlogik auf allen ebenen. ich schätze, core wird tatsächlich nahezu saturiert von so nem algo.

aber um auf den OP zurückzukommen: ob jetzt bei 3 oder 4 oder 5 oder 7 - da ist offenbar eine harte grenze für die effizienz auf der seite der instruction level parallelität. die prefetchlogiken wachsen schneller als die eigentlichen rechenwerke und der speedup für die wirklich selbstabhängigen codestellen ist gering.
man kann die prefetch und predictioneinheiten(ppe) als so was wie den vom OP vorgeschlagenen chip denken (sie versuchen, dinge zu parallelisieren und rechenwerke auszulasten), es gibt also sowas auch innerhalb eines kerns. und schon jetzt ist bei nehalem etwa doppelt so viel fläche von den ppe belegt wie von den eigentlichen rechenwerken.

[BlackBirdSR]

Ist die Frage was das jetzt ist, die reden da ja von "shorter segments of code", das ist für mich kleiner als ein thread, wie siehst Du das ?

Threads die pro Slice nur sehr wenig Code ausführen müssen, aufgrund der Latenzen und Wartezeiten durch Thread-Scheduling aber mehr aufgehalten als ausgeführt werden. Sprich: In der Zeit wo der Scheduler verteilen will, wäre dieser Teil des Threads schon verarbeitet und Platz für den nächsten. Kleinste Einheut bleibt trotzdem der Thread.

[FlashBFE]

Wobei ich auch glaube, dass der Rechenbedarf für guten alten Spaghetticode ziemlich stagniert. Der Code, der immer mehr Rechenarbeit kosten wird, wird hauptsächlich auch parallelisierbar sein. Dass das zur Zeit noch nicht so ist, liegt auch an den bescheidenen Mitteln, die wir Softwareentwickler in die Hände kriegen. Wenn ich sehe, was im .NET Framework das Standardprozedere ist, um zwischen zwei Threads bidirektional Daten austauschen zu können und der Hilfeschreiber das auchnoch als "Einfach" deklariert, kann ich nurnoch hoffen, dass sich die Programmiersprachen (und nicht nur die Klassenbibliotheken!) möglichst schnell weiterentwickeln, um soetwas auch einfach und verständlich abzubilden.

[PatkIllA]

Wenn ich sehe, was im .NET Framework das Standardprozedere ist, um zwischen zwei Threads bidirektional Daten austauschen zu können und der Hilfeschreiber das auchnoch als "Einfach" deklariert, kann ich nurnoch hoffen, dass sich die Programmiersprachen (und nicht nur die Klassenbibliotheken!) möglichst schnell weiterentwickeln, um soetwas auch einfach und verständlich abzubilden.
Was findest du denn daran so schwierig. Und was meinst du mit bidirektional Daten austauschen? Für einfach nur austauschen kannst du doch genauso Variablen verwenden oder Methoden aufrufen wie bei Singlethreaded anwendungen. Zumindest wenn du nicht großartig synchronisieren musst.

[S940]

braucht denn der superpi algo nicht quadratwurzeln an zentraler stelle? die lassen sich doch nicht soeben mal loopen auf microopebene, oder? Aufpassen, was geloopt / gespeichert sind nur die x86 Instruktionen, nicht die Befehlsverarbeitung später, das machen dann ja die Funktionseinheiten.
Durch den Loop Detektor wird also das FrontEnd entlastet. man spart sich die ganzen Fetch Operationen für jede einzelnen Schleifendurchlauf und der Decoder wird "vollgeknallt".

Beim Nehalem hat intel den Detektor noch nach dem Dekoder eingebaut, das sollte v.a. für exotische Befehle, die über den µCode Decoder gehen müssen was bringen:
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3382&p=4

@BlackBirdSR:
Alles klar, mal schauen, ob ich noch die andren beiden Patente finde :)

ciao

Alex

[FlashBFE]

Was findest du denn daran so schwierig. Und was meinst du mit bidirektional Daten austauschen? Für einfach nur austauschen kannst du doch genauso Variablen verwenden oder Methoden aufrufen wie bei Singlethreaded anwendungen. Zumindest wenn du nicht großartig synchronisieren musst.

Die Synchronisierung ist ja der Witz dadran. Es soll ja eine sichere Methode sein. Logisch hab ich auch schon einfachere Konstrukte verwendet, die auch schon ne Weile im Produktiveinsatz laufen. Aber theoretisch kann man da nicht sicher sein, dass irgendwann doch mal das Programm wegen Deadlock/Race abkackt. Wenn ich wirklich völlig voneinander unabhängige Aufgaben habe, die nur eine Eingabe beim Start und eine Ausgabe beim Ende haben, dann ists Kindergartenkram. Leider passiert das eher selten.
Ich meinte diesen Schriebs hier im MSDN (ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.NETDEV.v10.en/dnforms/html/winforms01232003.htm).

Und im .NET 3.5 wirds dann noch besser, dann scheint jedes Objekt seinen Besitzer-Thread zu haben und wenn man mit einem anderen drauf will...Exception.

[Gast]

Hi;

sucht auch mal nach "Intel speculative Threading" oder "Intel Mitosis Compiler". Das neue System (CPU + Compiler) soll es angeblich erlauben Single Threads auf mehrere CPUs aufzuteilen.

+

siehe hier (bin mir aber nicht sicher): http://pages.cs.wisc.edu/~mscalar/overview.html

[Skinner]

Habe von Programmieren zwar nicht mehr wirklich ahnung, aber was MasterElwood da im ersten posting beschreibt, ist in meinen augen Multithreading.

[Nakai]

Habe von Programmieren zwar nicht mehr wirklich ahnung, aber was MasterElwood da im ersten posting beschreibt, ist in meinen augen Multithreading.

Für mich sieht es eher so aus, als will er einen X86er-Cell vorschlagen.


mfg Nakai

[haifisch1896]

Allgemein finde ich mit meinem Laienwissen, dass ein dicker, richtiger Einzelkern mit Hyperthreading der elegantere & bessere Ansatz ist.

So ähnlich ohne HT gibt es das bereits. Z.B. in der XBox 360, der PS3 und in IBM-Servern.
Eine PowerPC-CPU mit bis zu 8 Sklaven-Arbeitern.

[PatkIllA]

So ähnlich ohne HT gibt es das bereits. Z.B. in der XBox 360, der PS3 und in IBM-Servern.
Eine PowerPC-CPU mit bis zu 8 Sklaven-Arbeitern.
Aber nicht bei der XBox 360.
Und der Cell ist nicht gerade einfach zu programmieren und der PowerPC Part ist vergleichsweise langsam.

[S940]

So ähnlich ohne HT gibt es das bereits. Z.B. in der XBox 360, der PS3 und in IBM-Servern.
Eine PowerPC-CPU mit bis zu 8 Sklaven-Arbeitern.
Öhm .. also die beiden Chips haben nix mit dem Alpha EV8 zu tun, eher das genaue Gegenteil ;-)

ciao

Alex

[haifisch1896]

Öhm... also auf EV8 habe ich das auch nicht bezogen. ;-)

Du hast von einem dicken Einkerner mit HT geschrieben.
Und ich brachte da CELL ins Spiel, welches ein Einkerner mit Sklaven ist, wobei die PPC-CPU m.W.n. nur die Aufgaben an die SPEs verteilt.

[S940]

Du hast von einem dicken Einkerner mit HT geschrieben.
Jupp dicker Einkerner == EV8.
Cell ist kein Einkerner, das ist ein einigermaßen komplexer Kern plus 6-8 simple Kernchen (kein HT/SMT).

Gegen den EV8 Kern schaut der Cell Hauptkern aber ebenfalls ziemlich primitiv aus :-)

Vorteil für den EV8: Es laufen auch "normale" single threaded Applikationen schneller (so denn alle FUs genützt werden können ^^), das Hyperthreading / SMT muss man ja nicht nutzen. Das ist nur Bonus.

Bei Cell dagegen *muss* man die SPUs beschäftigen, ansonsten gewinnt man nichts.

ciao

Alex

[Gast]

Soll heißen, das OS sieht nur 1 CPU und der CPU-Scheduler verteilt die Datenschnippsel (nicht nur eigenständige Threads) an alle angebundenen CPUs.
Quark, das minimiert nur den Overhead, welcher bei einem Contextwechsel auftritt. Die Threads muss der Programmierer dabei immernoch selber syncronisieren.

[Gast]

Wobei ich auch glaube, dass der Rechenbedarf für guten alten Spaghetticode ziemlich stagniert. Der Code, der immer mehr Rechenarbeit kosten wird, wird hauptsächlich auch parallelisierbar sein. Dass das zur Zeit noch nicht so ist, liegt auch an den bescheidenen Mitteln, die wir Softwareentwickler in die Hände kriegen. Wenn ich sehe, was im .NET Framework das Standardprozedere ist, um zwischen zwei Threads bidirektional Daten austauschen zu können und der Hilfeschreiber das auchnoch als "Einfach" deklariert, kann ich nurnoch hoffen, dass sich die Programmiersprachen (und nicht nur die Klassenbibliotheken!) möglichst schnell weiterentwickeln, um soetwas auch einfach und verständlich abzubilden.
Genau so siehts aus, jeh mehr workload man hat, umso mehr gibs auch zu parallelisieren! Mit firlefanz Datenbankanwendungen/ SuperPi etc. kann man natürlich nichts weiter raushohlen.

[Sentionline]

Zu Singlecore wird kein Hersteller "zurück" gehen, da sonst die Threadaufteilung im Boden versinken würde seitens der Softwareschmieden. Und das will keiner, das ist auch gut so.

An dem "Hardware-Parallelisierungschip" arbeitet Intel noch, der auch Singlethreads in Hardware nochmal zerstückelt. Laut einem Bericht im Computerclub2 anfang des Jahres, wird der Chip frühestens im Jahr 2012 starten.

greetings

[Pirx]

Wobei man natürlich mit mehrstimmigen Singecores und wenn es auch nur virtuelle sind, einen richtigen Singechor zusammenstellen könnte.:cool:
:sneak:

[Gast]

Weil's nicht geht. Ein Beispiel:

Wir wollen ein Spiegelei machen und haben dafür fünf Köche.
Die Vorschrift, wie man ein Spiegelei macht, sieht etwa so aus:

1) Gieße Öl in eine Pfanne
2) Stelle die Pfanne auf den Herd und mache sie warm
3) Schlage ein Ei herein
4) Warte, bis das Ei angebraten ist
5) Gib das Spiegelei auf einen Teller.

Ein Koch kriegt das relativ problemlos hin, aber die anderen vier langweilen sich. Würde man jedem Koch nun jeweils einen Schritt zuweisen, hätte man nachher eine Pfanne mit Öl, eine warme Pfanne ohne Öl, ein kaltes Ei auf dem Herd, einen Koch, der darauf wartet, daß das Ei angebraten ist und einen, der mit einem Teller rumsteht und ebenfalls wartet. Durch "naive" Parallelisierung ist unser Algorithmus also völlig unbrauchbar und wertlos geworden und führt keineswegs zum erwünschten Ergebnis.

-huha

Das Beispiel stimmt zwar, liegt aber daran, weil es eben ein zu einfach gestrickter Prozess ist. Was ist aber wenn ich ein ganzes Menü zaubern will ?(Spiegelei mit Kartoffelsalat und Spinat und als Nachlag gibts Schokopudding).

Jetzt kann ich locker 5 Köche beschäftigen und warten muss eigenbtlich nur einer, nämlich derjenige der das Menü serviert.

Genauso kann ich es in vielen Games handhaben. Warum nicht ein Core der nur für die UI zuständig ist, ein weitere nur die Landschaft, ein weiterer mögliche Himmeldarstellung und wieder einer die Charakter. Und dann noch einen für die "starren" aber interagierbaren Objekten.

Klar wird es zu Prozessen kommen, bei dem einige auf die anderen Warten, aber man hat doch nicht ständig Interaktionen die in 1ns aufeinander folgen müssen. Die UI kann z.b. verschmerzt locker Delays von 50ms usw.

[Grestorn]

@Gast: Aber genau diese Aufteilung, wer was machen kann um eine möglichst gute Parallelisierung hinzubekommen, muss der Programmierer machen. Der Prozessor oder das Betriebssystem hat keine Chance das zu erkennen und zu automatisieren.

[BlackBirdSR]

@Gast: Aber genau diese Aufteilung, wer was machen kann um eine möglichst gute Parallelisierung hinzubekommen, muss der Programmierer machen. Der Prozessor oder das Betriebssystem hat keine Chance das zu erkennen und zu automatisieren.

Und selbst dann bleibt immer die Frage:
Kostet die Aufteilung und Synchronisation ncht mehr Leistung als ich bekomme? Das GUI in einen extra Thread auszulagern, stelle ich mir nach allen Abzügen z.B nicht als sehr gewinnbringend vor.
Und dann vergessen wir mal nicht den Arbeitsaufwand den das alles kostet. Wer kann sich das leisten?

[Grestorn]

Das UI in einen eigenen Thread zu verfrachten hat vor allem den Vorteil, dass das UI immer funktioniert und sofort reagiert, auch wenn das Programm gerade beschäftigt ist.

Bei Programmen, die immer auch mal länger rechnen ist das deswegen eine sehr gute Praxis. Und natürlich hat das auch nichts mit Multicore-Systemen zu tun, denn diesen Vorteil bekommt man dank Multitasking auch mit einem Kern.

[Maniac007]

Profitiert eigentlich jedes Programm, welches mehrere Threads nutzt automatisch von einem Mehrkern-Prozessor?

[PatkIllA]

Profitiert eigentlich jedes Programm, welches mehrere Threads nutzt automatisch von einem Mehrkern-Prozessor?
Wenn mehr als ein Thread wirklich nenenswert was macht schon.
Multithreaded ist praktisch jedes Programm aber meist macht ein Thread die ganze Arbeit und die anderen warten z.B. auf Benutzereingaben oder sonstige Ereignisse.

[Rooter]

Im allgemeinen gilt, dass der meiste Gewinn für echte nichtparallelisierbare Probleme durch Sprungvorhersage erzielt werden kann und durch Raten von ERgebnissen und Vorberechnen aller möglichen Lösungen.
Wäre das denn keine Aufgabe für "sich langweilende" Cores!? So ähnlich wie HT brachliegende Pipelinestufen auslastet, kein heiliger Gral aber besser als nix:

Core1 erreicht einen Sprung, er rechnet mit einem Ergebnis weiter während die Daten an Core2 weitergereicht werden, der das andere Ergebnis berechnet
Der Core, dessen Ergebnis sich als korrekt herausstellt, setzt die Arbeit fort und gibt dem Anderen das Signal zum Abbruch

Wenn durch Sprünge wirklich so viel Leistung verloren geht würde das doch die Effizienz enorm steigern!

MfG
Rooter

[PatkIllA]

Wäre das denn keine Aufgabe für "sich langweilende" Cores!? So ähnlich wie HT brachliegende Pipelinestufen auslastet, kein heiliger Gral aber besser als nix:

Core1 erreicht einen Sprung, er rechnet mit einem Ergebnis weiter während die Daten an Core2 weitergereicht werden, der das andere Ergebnis berechnet
Der Core, dessen Ergebnis sich als korrekt herausstellt, setzt die Arbeit fort und gibt dem Anderen das Signal zum Abbruch

Wenn durch Sprünge wirklich so viel Leistung verloren geht würde das doch die Effizienz enorm steigern!
Sowas gibt es schon Kernintern. Ich weiß nur nicht ob auch bei x86. Jedenfalls braucht man da keinen zweiten Kern für.
Die Latenz der beiden Cores zueinander ist auch viel zu groß und so schlecht sind die Sprungvorhersagen auch nicht.

[RavenTS]

Sowas gibt es schon Kernintern. Ich weiß nur nicht ob auch bei x86. Jedenfalls braucht man da keinen zweiten Kern für.
Die Latenz der beiden Cores zueinander ist auch viel zu groß und so schlecht sind die Sprungvorhersagen auch nicht.

Zudem dürfte es meist ja sehr viele mögliche Sprünge geben, da bräuchte man dann schon viele Kerne um eine gewisse wahrscheinliche Ergebnisbandbreite überhaipt brauchbar abdecken zu können...

[Gast]

Wäre das denn keine Aufgabe für "sich langweilende" Cores!? So ähnlich wie HT brachliegende Pipelinestufen auslastet, kein heiliger Gral aber besser als nix:

Core1 erreicht einen Sprung, er rechnet mit einem Ergebnis weiter während die Daten an Core2 weitergereicht werden, der das andere Ergebnis berechnet
Der Core, dessen Ergebnis sich als korrekt herausstellt, setzt die Arbeit fort und gibt dem Anderen das Signal zum Abbruch

Wenn durch Sprünge wirklich so viel Leistung verloren geht würde das doch die Effizienz enorm steigern!

MfG
Rooter


siehe mein posting auf der letzten Seite:

Hi;

sucht auch mal nach "Intel speculative Threading" oder "Intel Mitosis Compiler". Das neue System (CPU + Compiler) soll es angeblich erlauben Single Threads auf mehrere CPUs aufzuteilen.

+

siehe hier (bin mir aber nicht sicher): http://pages.cs.wisc.edu/~mscalar/overview.html