Archiv verlassen und diese Seite im Standarddesign anzeigen : Dual\Quad Prozessoren und 0 Mehrleistung?
Shakti
2005-12-21, 01:45:39
Hallo,
habe mir mal Gedanken gemacht, warum Dual ( bald Quad) Prozessoren nicht so gebaut werden, das sie wie bei SLI Grafikkarten den Anwendungen oder dem Spiel wie EIN Prozessor vorkommen. Das wuerde doch richtig Freude machen. Seit Ewigkeiten gibts Dualboards und Prozessoren, aber genausolange nur eine Handvoll Anwendungen, die davon Gebrauch machen. Man koennte doch einen Quadprozessor bauen, der sich immer seine Arbeit durch 4 teilt, also nicht wie jetzt 1 arbeitet und 3 schlafen, sondern jeder arbeitet anteilig.
Ganz einfach: Das geht nicht.
Aufgaben, die an eine GPU gestellt werden, können einfach parallelisiert werden, da die GPU ja sowieso jede Zeile des Bildes rendern muß. Nimmt man nun 2 GPUs, so kann man jede GPU anweisen, nur die Hälfte des Bildes zu rendern und somit hat man seine SLI-Lösung.
Bei CPUs ist das nicht so einfach, die Aufgaben liegen nämlich nicht in einer Form vor, die einfach und effizient zu parallelisieren wäre, weil die Programme nicht entsprechend geschrieben sind ;) -- übrigens liegt der Vorteil von mehreren CPUs auf einer ganz anderen Seite wie der Vorteil mehrerer GPUs. Während man gleichzeitig nur ein Spiel spielt, ist die CPU mit einer Vielzahl von Aufgaben belastet. Selbst ohne jedwede Optimierung der Programme können so zwei CPUs das Arbeitstempo deutlich erhöhen, weil CPU-intensive Aufgaben bequem auf eine CPU geschoben werden können, während die andere die Programme ausführt, mit denen man aktuell arbeitet. Dies hat zwar nur indirekt meßbare Vorteile, sehr wohl aber spürbare.
-huha
san.salvador
2005-12-21, 03:32:05
Aufgaben, die an eine GPU gestellt werden, können einfach parallelisiert werden, da die GPU ja sowieso jede Zeile des Bildes rendern muß. Nimmt man nun 2 GPUs, so kann man jede GPU anweisen, nur die Hälfte des Bildes zu rendern und somit hat man seine SLI-Lösung.
Bei CPUs ist das nicht so einfach, die Aufgaben liegen nämlich nicht in einer Form vor, die einfach und effizient zu parallelisieren wäre, weil die Programme nicht entsprechend geschrieben sind ;) -- übrigens liegt der Vorteil von mehreren CPUs auf einer ganz anderen Seite wie der Vorteil mehrerer GPUs. Während man gleichzeitig nur ein Spiel spielt, ist die CPU mit einer Vielzahl von Aufgaben belastet. Selbst ohne jedwede Optimierung der Programme können so zwei CPUs das Arbeitstempo deutlich erhöhen, weil CPU-intensive Aufgaben bequem auf eine CPU geschoben werden können, während die andere die Programme ausführt, mit denen man aktuell arbeitet. Dies hat zwar nur indirekt meßbare Vorteile, sehr wohl aber spürbare.
-huha
Da meine CPU, die ich seit mehr als einem Jahr im Rechner habe, mit HTT arbeitet, kann ich das nur bestätigen. Man kann die Mehrleistung zwar nur schwer messen, aber es lässt sich damit wesentlich fluider arbeiten. Es muss auch nicht soviel Rücksicht auf die bereits laufenden Programme genommmen werden.
Shakti
2005-12-21, 13:39:18
Naja, nach mehreren Dualboards bin ich soweit, das ich HTT in meinem derzeitigen Board ausgeschaltet habe.
Aber wie waere es mit einem Quadprozessor, der eine Master-CPU hat, die bei Bedarf Rechenaufgaben an die anderen weitergibt, mehr oder weniger nur koordiniert.
Oder vielleicht auch einfach an den Arbeitsspeicher gebunden, alles was in den ersten 256 MB Ram ist, bearbeitet CPU1 etc.
Nochmal: Es geht nicht. Man ist bei den Prozessoren bereits fast bei der maximalen Parallelität pro Thread angekommen mit einem Core.
DavChrFen
2005-12-21, 16:10:42
Das Problem ist die Arbeitsweise der X86-Prozessoren: Das ist linear(z.B.:
1. hole VAriable von Speicheraddresse 00120
2. addiere 8 dazu
3. vergleiche das mit dem Inhalt der Speicheradresse 00128 und schreibe das größere nach Addresse 00876
4. teile es duch 4
5. Schreibe es nach 02400
)
Bei so was nützen dir mehrere Prozessoren gar nichts, da man immer das Ergebnis der Zeile davor braucht.
Bei IA64 werden hingegen immer 4 anweisungen auf einmal der CPU gegeben, die voneinander unabhängig sind. Dafür hat dann der Compiler zu sorgen.
Das was du gerade aufgeschrieben hast wird auch bei IA64 auf 5 Instructions rauslaufen, weil die 3 (!) Befehle in einer Anweisung auch immer unabhängig sein müssen.
Weiterhin führen heutige (seit Pentium Pro) x86-CPUs Code auch automatisch auf mehreren Einheiten aus wenn es geht, aber das ist auf Multi-Core-Level nicht machbar, auch nicht mit IA64.
mike49
2005-12-21, 19:29:43
Nochmal: Es geht nicht. Man ist bei den Prozessoren bereits fast bei der maximalen Parallelität pro Thread angekommen mit einem Core.
Und warum entwickelt man dann gerade bei NEC genau so etwas?:
(...)Dabei hat man laut NEC eigens einen neuen Multi-Core Prozessor entwickelt, welcher über einen so genannten integrierten „Automatic parallelizing compiler“ verfügt – eine Logik, welche vollautomatisch den auszuführenden Programmcode in mehrere Threads unterteilt, die schließlich auf die einzelnen Kerne verteilt werden können, um somit die vorhandenen Ressourcen besser ausnutzen zu können. (...)
Quelle: http://www.computerbase.de/news/hardware/prozessoren/2005/dezember/nec_multi-core-technik/
Scheint ja wohl doch was dran zu sein...
@mike49:
Du kannst hast entweder Codas Posting oder den Inhalt der Pressemitteilung nicht verstanden.
mike49
2005-12-21, 20:17:32
@Trap:
Dann erklär mir doch bitte mal den Unterschied zwischen der ursprünglichen Frage des Threaderstellers und dem, was NEC da in seiner Pressemitteilung verkündet hat... :rolleyes:
Ähm, ok, ich habe die NEC-Pressemitteilung nicht verstanden. Mal sehen was am Schluss bei rauskommt, im Moment ist das Vaporware.
Die Übersetzung von Computerbase ist ziemlich frei. In der Originalmeldung http://www.nec.co.jp/press/en/0512/1901.html steht nicht das der Prozessor diesen "automatic parallelizing compiler" enthält, sondern nur dass der Compiler zu den Zeug was sie entwickelt haben dazugehört. Ich lese das so, dass man die Anwendung zuerst so laufen lässt, dass dabei ein Profile aufgezeichnet wird. Dann füttert man das Profile in den Compiler und der erzeugt eine neue ausführbare Datei. Bzw. das Ganze on-the-fly.
Ich hätte nicht vermutet, dass man aus einem reinen Profile der laufenden Anwendung genug Daten bekommt um eine Maschinencode zu Maschinencode Transformation damit gezielt zu steuern.
Eine Parallelverbarbeitung kann aber auch so Software wie die von NEC nicht garantieren.
Das NEC-Zeug ist eh sehr komisch. Das ganze geht ja nichtmal beim Offline-Kompilieren gut, dann sehe ich nicht wie es zur Runtime auf einmal Wunder verbringen soll.
Edit: Aha Trap. Das bringt etwas Licht in die ganze Sache - Computerbase hat mal wieder Scheiße gelabert.
Avalox
2005-12-21, 20:59:20
Und warum entwickelt man dann gerade bei NEC genau so etwas?:
[i](...)Dabei hat man laut NEC eigens einen neuen Multi-Core Prozessor ...
Solche Entwicklungen werden immer auf eine zusätzliche Abstraktionsebene hinaus laufen.
Eine zusätzliche Abstraktionsebene bedeutet immer im ersten Schritt zusätzlichen Aufwand für den Rechner, welcher das Programm abarbeitet.
Natürlich versuchen heute Programmierer mit bestehenden Werkzeugen die Aufgaben so von Hand zu verteilen, dass beide Kerne einer speziellen DualCore CPU gut ausgelastet werden. Da aber der DualCore nur der erste Schritt ist in die Welt der zwangläufig folgenden CPUs mit noch mehr Kernen , muss man sich zwangläufig einen anderen Weg an die Herangehensweise der Softwareentwicklung überlegen.
Banshee18
2005-12-21, 22:09:22
Es ist doch öfter mal die Rede davon, dass es z.B. möglich wäre, dass bei Spielen eine CPU z.B. die Physik berechnet und die andere CPU den Rest.
Durch Threads müsste das doch auch zu realisieren sein, oder? Oder schreib ich gerade vollkommen am Thema vorbei?
Oder schreib ich gerade vollkommen am Thema vorbei?
Irgendwie schon. Es geht darum ob und wie man bestehende Software, die nur für einen Thread geschrieben ist parallelisieren kann. Extra für Multithreading geschriebene Anwendungen laufen natürlich parallel, aber um die gehts nicht.
Durch Threads ist das alles möglich. Wobei man IMHO von Ausdrucksweisen wie "die eine CPU berechnet das, die andere das" und ähnlichen fixierten Dingen wegkommen sollte. Die Threads werden ja optimalerweise dynamisch auf beide CPUs verteilt (ich weiß jetzt nicht, ob das Windows während der Laufzeit machen kann, gehe aber stark davon aus) und zwar so, daß beide gut ausgelastet sind. Es kann also durchaus mal vorkommen, daß eine CPU Physik und KI abkriegt, wenn die andere CPU gerade mit ganz anderen Dingen beschäftigt ist ;)
Programmieren für SMD erfordert eben die Parallelisierung der Aufgaben, was für normale Programme nicht unbedingt einfach ist; Parallelisierung heißt, daß man Kontrolle aus der Hand gibt, weil man nie weiß, wie lange ein Thread, den man quasi "ausgelagert" hat, nun brauchen wird, was die Programmierung erschwert. Oftmals sind auch neue Herangehensweisen erforderlich, um überhaupt ein linear ablaufendes Programm sinnvoll in Threads zu unterteilen, was nur dann Sinn hat, wenn die Threads auch in etwa gleich viel Performance verbrauchen (sonst ist's reichlich witzlos, außer wenn man Teile des Programms noch weiterhin bedienbar halten will und nicht will, daß alles z.B. durch eine große Rechenoperation blockiert wird-- dafür wird man dann zwar Threads benutzen, auf SMP-Systemen läuft das Programm aber dennoch nicht besser, weil die Hauptarbeit immer noch von lediglich einem Thread übernommen wird.)
-huha
mike49
2005-12-22, 19:47:15
Was ich noch nicht ganz verstanden habe: Soll diese Profil Information (= 'Programm execution history' lt. NEC) parallel zur Laufzeit generiert werden oder wird diese zunächst bei einem ersten Durchlauf generiert (und wenn ja: wo wird diese abgelegt)?
Wie auch immer scheint es jedoch Ansätze zu geben, Multicore-Support bzw. die Parallelisierung - mehr oder minder - direkt auf die CPU zu verlagern ohne explizite Anpassung der Software hin auf Multithreading. Wenn das dann auch funktioniert eine IMHO gute Entwicklung...
Wie auch immer scheint es jedoch Ansätze zu geben, Multicore-Support bzw. die Parallelisierung - mehr oder minder - direkt auf die CPU zu verlagern ohne explizite Anpassung der Software hin auf Multithreading. Wenn das dann auch funktioniert eine IMHO gute Entwicklung...
wenn das wirklich funktionieren würde bräuchte man keine multicores, dann würde es eine breitere pipeline mit mehr ausführungseinheiten (die alle von einem thread genutzt werden) auch tun.
SentinelBorg
2006-01-02, 14:01:07
Einige Leute müssen erstmal lernen, wie Multithreading eigentlich funktioniert.
Also, auf eurem Rechner laufen immer Unmengen an Threads, wie der Taskmanager auch anzeigt. Bei mir sinds gerade über 450. Pro logischer CPU läuft zu jeder Zeit immer genau ein Thread und wenns nur der berühmte Idle-Thread ist. Aller paar Nanosekunden tut das Betriebssystem (genau genommen der Scheduler) die Threads neu verteilen, sprich es entzieht den gerade laufenden Threads die CPUs und teilt wieder anderen Threads für einen gewissen Zeitraum die CPUs zu. Diese Laufzeithäppchen nennt man bei Windows z.B. Quantas.
Das passiert also alles im Hintergrund und ständig. Als Programmierer hast du da 0 Einfluss. Das einzige was du noch sagen kannst ist, dass dein Thread nur auf einer bestimmten CPU laufen mag. Das macht man aber eigentlich nur, falls es irgendwelche Probleme gibt, wie z.B. verschiedene Timer in den CPUs, die nicht ganz synchron laufen.
Aber wie auch immer, eine Aufgabe zu parallelisieren ist je nachdem einfach unmöglich. Ein mathematischer Algorithmus z.B., der iterativ läuft und jeweils den Wert der Vorrunde braucht, da gibts nix zu parallelisieren. Da kannst dich auf den Kopf stellen. Da musst du ganz an die Basis des Problems zurück und da wäre in dem Bereich dann wieder was für theoretische Mathematiker, nichts mehr für Informatiker.
Sentinel
Muh-sagt-die-Kuh
2006-01-02, 14:23:05
Einige Leute müssen erstmal lernen, wie Multithreading eigentlich funktioniert.
Also, auf eurem Rechner laufen immer Unmengen an Threads, wie der Taskmanager auch anzeigt. Bei mir sinds gerade über 450. Pro logischer CPU läuft zu jeder Zeit immer genau ein Thread und wenns nur der berühmte Idle-Thread ist. Aller paar Nanosekunden tut das Betriebssystem (genau genommen der Scheduler) die Threads neu verteilen, sprich es entzieht den gerade laufenden Threads die CPUs und teilt wieder anderen Threads für einen gewissen Zeitraum die CPUs zu. Diese Laufzeithäppchen nennt man bei Windows z.B. Quantas.
SentinelEine gute, einsteigerfreundliche Beschreibung....nur ist Quantas eine australische Fluglinie....die zu verteilende Zeiteinheit ist ein Quantum ;)
micki
2006-01-02, 15:25:35
Da musst du ganz an die Basis des Problems zurück und da wäre in dem Bereich dann wieder was für theoretische Mathematiker, nichts mehr für Informatiker.
ich dachte das wäre dann der bereich der overclocker ;)
HAL-10K
2006-01-02, 20:22:09
Einige Leute müssen erstmal lernen, wie Multithreading eigentlich funktioniert.
Also, auf eurem Rechner laufen immer Unmengen an Threads, wie der Taskmanager auch anzeigt. Bei mir sinds gerade über 450. Pro logischer CPU läuft zu jeder Zeit immer genau ein Thread und wenns nur der berühmte Idle-Thread ist. Aller paar Nanosekunden tut das Betriebssystem (genau genommen der Scheduler) die Threads neu verteilen, sprich es entzieht den gerade laufenden Threads die CPUs und teilt wieder anderen Threads für einen gewissen Zeitraum die CPUs zu. Diese Laufzeithäppchen nennt man bei Windows z.B. Quantas.
Das passiert also alles im Hintergrund und ständig. Als Programmierer hast du da 0 Einfluss.Nö, natürlich hat man Einfluss auf den scheduler.
Aber wie auch immer, eine Aufgabe zu parallelisieren ist je nachdem einfach unmöglich. Ein mathematischer Algorithmus z.B., der iterativ läuft und jeweils den Wert der Vorrunde braucht, da gibts nix zu parallelisieren. Da kannst dich auf den Kopf stellen. Da musst du ganz an die Basis des Problems zurück und da wäre in dem Bereich dann wieder was für theoretische Mathematiker, nichts mehr für Informatiker.Das stimmt so auch nicht. Speicher, und damit vorherige Rechenergebnisse können allen threads zur Verfügung gestellt werden.
Es ist jedoch mitunter technisch schwierig/aufwändig diesen Speicherbereich ausreichend schnell genug an mehreren Kernen anzubinden und die threads zu synchronisieren.
Nö, natürlich hat man Einfluss auf den scheduler.Hat man nicht. Nur indirekt über die Priorität.
Das stimmt so auch nicht.Doch tut es. Iterative Algorithmen sind nicht zu parallelisieren.
HAL-10K
2006-01-02, 20:34:48
Hat man nicht. Nur indirekt über die Priorität.Was soll denn der Quatsch mit "nur indirekt"?
Man kann den scheduler beeinflussen - Fakt.
Doch tut es. Iterative Algorithmen sind nicht zu parallelisieren.Nö, natürlich sind diese auch zu parallelisieren. Nur eben bei gewöhnlichen Architekturen nicht effizient, da es zu vielen cache misses kommt.
Wie willst du bitte einen iterativen Algorithmus parallelisieren. z.B. 1000 mal einen Wert um 1 inkrementieren?
Oder Wurzelberechnung nach Newton?
Egal mit welcher Architektur, kannst sie auch gerne mitbeschreiben.
Was soll denn der Quatsch mit "nur indirekt"?Aha. Und wie bei preemtiven Multitasking?
Nö, natürlich sind diese auch zu parallelisieren. Nur eben bei gewöhnlichen Architekturen nicht effizient, da es zu vielen cache misses kommt.Soso. Rechenschritte die immer vom letzten abhängen willst du parallelsieren. Dann hol dir mal den Nobelpreis dafür.
HAL-10K
2006-01-02, 20:45:39
Wie willst du bitte einen iterativen Algorithmus parallelisieren. z.B. 1000 mal einen Wert um 1 inkrementieren?
Oder Wurzelberechnung nach Newton?Natürlich währe so etwas z.B. bei der x86 Architektur Blödsinn, es ist aber sehr wohl möglich.
Egal mit welcher Architektur, kannst sie auch gerne mitbeschreiben.Kannste mit jedem x86 seit dem 386 machen. Wo ist denn das Problem?
Effizient währe dies etwa mit gemeinsamen caches möglich.
Das ist auch mit gemeinsamem Cache nicht möglich. Das ist einfach nur Unfug. Zumindest findet dann keine parallele Berechnung mehr statt sondern nur noch warten bis der andere Core wieder ein Ergebnis ausspuckt. Im Endeffekt wäre es nur langsamer als vorher.
Wie? Ich will Code oder etwas das als Algorithmus durchgeht, nicht blabla...
HAL-10K
2006-01-02, 21:03:35
Aha. Und wie bei preemtiven Multitasking?Das wird vom Betriebssystem zur Systembetriebssicherung benutzt.
Hat aber nichts mit dem Fakt zu tun dass man Einfluss auf den Scheduler hat.
Soso. Rechenschritte die immer vom letzten abhängen willst du parallelsieren. Dann hol dir mal den Nobelpreis dafür.Will ich doch gar nicht, da es auf x86 Systemen ineffizient währe. Es ist aber sehr wohl möglich.
Willst du etwa behaupten dass es nicht möglich währe?
HAL-10K
2006-01-02, 21:08:47
Das ist auch mit gemeinsamem Cache nicht möglich. Das ist einfach nur Unfug. Zumindest findet dann keine parallele Berechnung mehr statt sondern nur noch warten bis der andere Core wieder ein Ergebnis ausspuckt. Im Endeffekt wäre es nur langsamer als vorher."Iterative Algorithmen" bedeutet nicht "eine Iteration des Algorithmus beeinhalten eine Rechenoperation"!
Iterative Algorithmen sind sehr wohl parallelisierbar.
Das wird vom Betriebssystem zur Systembetriebssicherung benutzt.
Hat aber nichts mit dem Fakt zu tun dass man Einfluss auf den Scheduler hat.Nochmal: Wie?
Will ich doch gar nicht, da es auf x86 Systemen ineffizient währe. Es ist aber sehr wohl möglich.
Willst du etwa behaupten dass es nicht möglich währe?Es ist doch wohl offensichtlich dass etwas was bei jeder Rechenoperation schon ein Ergebnis aus der Vergangenheit braucht nicht parallelisierbar ist. Es gibt einfach keine 2 Operationen die nebeneinander berechenbar wären.
Nebenläufigkeit bezeichnet das Verhältnis von Ereignissen, die nicht kausal abhängig sind, die sich also nicht beeinflussen. Ereignisse sind nebenläufig, wenn keines eine Ursache des anderen ist. Oder anders ausgedrückt: Aktionen können nebenläufig ausgeführt werden (sie sind parallelisierbar), wenn keine das Resultat der anderen benötigt. Ein Modell, das diese Abhängigkeiten sehr gut wiedergibt, sind Petri-Netze.
HAL-10K
2006-01-02, 21:21:30
Nochmal: Wie?Sag mal macht dir dieser Blödsinn Spaß?
Man hat bei jedem einsatzfähigem Betriebssystem mit freien Programmschnittstellen Einfluss auf den scheduler.
Sonst währen threads z.B. auf einem System mit nur einer CPU quasi sinnlos!
Es ist doch wohl offensichtlich dass etwas was bei jeder Rechenoperation schon ein Ergebnis aus der Vergangenheit braucht nicht parallelisierbar ist.Bei einer Rechenoperation - da ist es selbstverständlich nicht möglich.
Es ist aber eben sehr wohl möglich iterative Algorithmen zu parallelisieren.
Und es gibt quasi keine sinnvollen/relevanten Algorithmen die nur aus einer Rechenoperation pro Iteration bestehen.
Wie? Ich will Code oder etwas das als Algorithmus durchgeht, nicht blabla...
Der Code bleibt gleich,die CPU ist aber eine andere.Eine mit X Rechencores und 1 Loop-Core(das L-Core muss,um solche Szenarien erkennen zu koennen,komplexer sein).Das L-C uebernimmt das Zaehlen und uebergibt die Inputs fuer Loop1 an das Core 1,fuer Loop2=L-C counting,C2 working,Loop3=L-C counting,C3 working usw...
Wenn es keinen Loop gibt werden die Daten einfach durchgesendet.(ohne dass das D-C irgenetwas macht)
p.s. Die Arbeitsteilung ist nicht 50:50,das soll es aber auch nicht sein.Deswegen auch X Cs und nur ein L-C.
-Beim komplexerem "Counting" wird das Verhaeltnis aber Gerechter.(obwohl es nicht immer nur einfaches Counting ist)
p.s.2 funktionier aber nicht immer!
@Hal-10:
Kannst du mal konkret schreiben was du meinst? Du stellst inhaltslose Behauptungen auf, die sich falsch anhören, aber wegen mangeldem Inhalt kaum widerlegbar sind.
@all:
Viele iterative Algorithmen sind auch innerhalb einer Iteration (fast) nicht parallelisierbar. Zum Beispiel Newton für Quadratwurzeln:
while(err>limit) {
x=(x+input/x)/2;
err = abs(x*x-input);
}
Da kann man genau nichts parallel berechnen.
Edit: doch, man kann die alten err parallel zum neuen x berechnen, in vielen Anwendungen berechnet an die err aber garnicht sondern macht eine feste Anzahl an Schritten
HAL-10K
2006-01-02, 21:50:48
@Hal-10:
Kannst du mal konkret schreiben was du meinst? Du stellst inhaltslose Behauptungen auf, die sich falsch anhören, aber wegen mangeldem Inhalt kaum widerlegbar sind.
@all:
Viele iterative Algorithmen sind auch innerhalb einer Iteration (fast) nicht parallelisierbar. Zum Beispiel Newton für Quadratwurzeln:
while(err>limit) {
x=(x+input/x)/2;
err = abs(x*x-input);
}
Da kann man genau nichts parallel berechnen.Na siehste, du sagst ja nun mittlerweile selbst dass iterative Algorithmen parallelisierbar sind. Genau dass ist wo du die ganze Zeit mir widersprichst.
Und es gibt praktisch keine sinnvollen/relevanten Algorithmen die nicht irgendwie parallelisierbar sind.
Wie bereits gesagt ist es unter üblichen Architekturen manchmal nur nicht effizient.
Da kannst du drum herum eiern wie du willst, es ist so.
Innerhalb eine Iteration parallelisierbar ist meist instruction level parallelism und das nutzen OoO-CPUs schon längst.
HAL-10K
2006-01-02, 22:08:55
Innerhalb eine Iteration parallelisierbar ist meist instruction level parallelism und das nutzen OoO-CPUs schon längst.Du meitest wohl Operation? Ja parallelisierte Instruktionsverarbeiten z.B. über Vektorisierung ist natürlich schon lange möglich.
Er meint keine Vektorisierung sondern superskalare out-of-order Abarbeitung.
Es gibt in der Informatik genug Probleme die sich nicht parallelisieren lassen, falls du das wirklich nicht akzeptieren willst dann hat die Diskussion mit dir eh keinen Sinn.
Shakti
2006-01-09, 07:11:08
Bleibt nur zu hoffen das NEC nicht auf moeglichen Patenten sitzenbleibt, sondern mit AMD oder Intel zusammen arbeitet.
Waere ja ein sehr grosser Fortschritt wenn das wie in dem NEC Artikel beschrieben klappen wuerde, obwohl mich ja wundert, das so etwas von NEC kommt und nicht von den Prozessorherstellern. Und hoffentlich nicht nur fuer ''cellular phones''.
SentinelBorg
2006-01-09, 10:34:11
Bleibt nur zu hoffen das NEC nicht auf moeglichen Patenten sitzenbleibt, sondern mit AMD oder Intel zusammen arbeitet.
Waere ja ein sehr grosser Fortschritt wenn das wie in dem NEC Artikel beschrieben klappen wuerde, obwohl mich ja wundert, das so etwas von NEC kommt und nicht von den Prozessorherstellern. Und hoffentlich nicht nur fuer ''cellular phones''.
NEC ist ein Prozessorhersteller ^^ Zumindest sagen mir das die NEC Vektor Prozessoren im Earth Simulator.
Sentinel
Hallo,
habe mir mal Gedanken gemacht, warum Dual ( bald Quad) Prozessoren nicht so gebaut werden, das sie wie bei SLI Grafikkarten den Anwendungen oder dem Spiel wie EIN Prozessor vorkommen. Das wuerde doch richtig Freude machen. Seit Ewigkeiten gibts Dualboards und Prozessoren, aber genausolange nur eine Handvoll Anwendungen, die davon Gebrauch machen. Man koennte doch einen Quadprozessor bauen, der sich immer seine Arbeit durch 4 teilt, also nicht wie jetzt 1 arbeitet und 3 schlafen, sondern jeder arbeitet anteilig.
um das problem mal simpel zu umschreiben, es ginge, rein technisch, nur:
ein thread muss eine gewisse länge (befehlszyklen) haben um seinen "rechenaufwand" (synchronisation, etc.) zu rechtfertigen, das ist bei grafikkarten (gpu's) recht einfach, da sehr sehr viel parallel abgearbeitet wird/werden kann. je nach cpu anwendung aber leider eben nicht, da werden entsprechende compiler/tools/konzepte in zukunft was bringen, aber der idealweg(vom aufwand her, für den entwickler) - lass alles den compiler oder prozessortreiber machen, wird es so schnell nicht geben. ( http://microsoft.sitestream.com/pdc05/ - mal mach "concurrency" suchen und anschauen )....
thomas
http://www.winfuture.de/news,24975.html
Guuuuuute Idee!
Ganon
2006-04-18, 11:16:47
http://www.winfuture.de/news,24975.html
DAS wäre natürlich schön.
Fragt sich nur, ob der Overhead nicht zu groß ist. Würde sich aber erst ab ner Quad-CPU lohnen, da Dual-CPU imo schon sinnvoll ist.
Pff. Die mögliche Mehrleistung würde sich im <5%-Bereich befinden.
Ganon
2006-04-18, 11:34:07
Vielleicht nach jetzigem Aufbau der CPUs. Vielleicht sind in dem Design die CPUs ja enger miteinander verbunden? Wer weiß...
Oder es sind ein oder zwei große Kerne, die sich wahlweise als eine/zwei CPUs ausgeben können, oder als 4/8 CPUs?
Wird man sehen, wenn es stimmt. ;)
Vielleicht nach jetzigem Aufbau der CPUs.
Nein, auch sonst.
Wird man sehen, wenn es stimmt. ;)
Kannst vergessen.
http://www.winfuture.de/news,24975.html
Guuuuuute Idee!
umgekehrt wäre die idee sicher besser, also ein multicore, der sich also solche ausgibt, wobei aber jeder core jede recheneinheit nutzen kann.
im prinzip also ein core mit mehr ausführungseinheiten (die von einem thread kaum genutzt werden können), der mittels hyperthreading aber mehrere aufgaben gleichzeitig bearbeiten kann.
somit hat man bei multi-threaded software die gleichen vorteile wie bei einem "normalen" multicore, kann aber theoretisch auch in einem thread alle recheneinheiten nutzen.
Neomi
2006-04-18, 15:17:28
somit hat man bei multi-threaded software die gleichen vorteile wie bei einem "normalen" multicore, kann aber theoretisch auch in einem thread alle recheneinheiten nutzen.
Multicore gibt es nur deshalb, weil mehr Rechenleistung in einem einzelnen Thread eben nicht machbar (bzw. nicht beliebig steigerbar) ist.
Nein, auch sonst.
nicht falls man die raumzeit so krümmt das das ergebniss vor der berechnung sich bereits im speicher befindet... ;)
vlt ist damit auch nur gemeint das der cpu die thread aufteilung nicht mehr dem os überlässt sondern selbst in die hand nimmt... sich "als singlecore zu erkennen gibt" (und somit sich selbst effektiver auslastet)
man bemerke das ich nicht gesagt habe das das nicht explizit unterstützt werden muss
Hallo,
habe mir mal Gedanken gemacht, warum Dual ( bald Quad) Prozessoren nicht so gebaut werden, das sie wie bei SLI Grafikkarten den Anwendungen oder dem Spiel wie EIN Prozessor vorkommen. Das wuerde doch richtig Freude machen. Seit Ewigkeiten gibts Dualboards und Prozessoren, aber genausolange nur eine Handvoll Anwendungen, die davon Gebrauch machen. Man koennte doch einen Quadprozessor bauen, der sich immer seine Arbeit durch 4 teilt, also nicht wie jetzt 1 arbeitet und 3 schlafen, sondern jeder arbeitet anteilig.
AMD und Intel planden so etwas nach www.hartware.net.
zumindest ist da geschrieben das amd versucht Anti-Hyper-Threading zu realisieren wobei mehrere CPU-Kerne zu einer logischen CPU kombiniert werden
ob es geht ist da hin gestellt aber sie versuchen es ja und ein guter weg wäre es ja sicherlich wenn es funktioniren würde
Neomi
2006-04-18, 16:48:13
vlt ist damit auch nur gemeint das der cpu die thread aufteilung nicht mehr dem os überlässt sondern selbst in die hand nimmt... sich "als singlecore zu erkennen gibt" (und somit sich selbst effektiver auslastet)
Wenn eine Instruktion B das Ergebnis der Instruktion A benötigt, dann kann kein zusätzlicher CPU-Kern Instruktion B ausführen, solange Instruktion A nicht abgeschlossen ist. Es gibt keine Technologie, die das Problem umgehen kann, weil es ein Prinzipproblem ist. Natürlich kann man auch auf einer Multicore-CPU singlethreaded rechnen, aber dann eben nur mit der Leistung eines einzelnen Cores.
AMD und Intel planden so etwas nach www.hartware.net.
zumindest ist da geschrieben das amd versucht Anti-Hyper-Threading zu realisieren wobei mehrere CPU-Kerne zu einer logischen CPU kombiniert werden
ob es geht ist da hin gestellt aber sie versuchen es ja und ein guter weg wäre es ja sicherlich wenn es funktioniren würde
Weder AMD noch Intel planen soetwas ernsthaft, weil sie wissen, daß es nicht funktionieren kann. Ich kann mir durchaus vorstellen, daß an anderen Dingen gebastelt wird, die nur völlig falsch interpretiert wurden. Was aber da durchs Netz wandert, ist einfach nur lächerlich.
Ganon
2006-04-18, 16:51:10
Und wenn man das Ganze als aufgebohrtes Out-Of-Order hinbekommt?
Neomi
2006-04-18, 16:58:33
Und wenn man das Ganze als aufgebohrtes Out-Of-Order hinbekommt?
Dann ist es immer noch etwas völlig anderes als die Verschmelzung mehrerer Cores zu einem virtuellen stärkeren Core.
Und würde eben die angesprochenen <5% Leistungssteigerung bewirken :rolleyes:
Weder AMD noch Intel planen soetwas ernsthaft, weil sie wissen, daß es nicht funktionieren kann. Ich kann mir durchaus vorstellen, daß an anderen Dingen gebastelt wird, die nur völlig falsch interpretiert wurden. Was aber da durchs Netz wandert, ist einfach nur lächerlich.
2 Dinge die mir dazu einfallen:
1. zu Intel: http://www.anandtech.com/tradeshows/showdoc.aspx?i=2507&p=7
2. Cores können sich auch Einheiten teilen (vgl. FPU bei Niagara)
1. Ja, das ginge in die Richtung, aber so wie so einfach wie es dargestellt wird, dass es "absolut automatisch" und wie ein "Singlecore" aussieht ist es nicht.
2. Ist dann ja aber eher wieder Hyperthreading und nicht Anti-Hyperthreading
1. Ja, das ginge in die Richtung, aber so wie so einfach wie es dargestellt wird, dass es "absolut automatisch" und wie ein "Singlecore" aussieht ist es nicht.
Ist mir auch klar. ;)
Aber sie arbeiten auch daran.
Hier bei Intel direkt zum leichteren Lesen:
http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm
2. Ist dann ja aber eher wieder Hyperthreading und nicht Anti-Hyperthreading
Wieso? Ein Thread blockiert die Einheit in allen Cores. :tongue:
Das was wir mitbekommen ist doch eh alles Marketing und hat oft wenig mit Logik zu tun. Allein schon der Begriff Anti-Hyperthreading.... Ich dachte schon Hyperthreading wäre schwer zu toppen. *Hyper Hyper*
Wieso? Ein Thread blockiert die Einheit in allen Cores. :tongue:
Naja wenn man das enorm zusammenschrumpft und beide Cores sich alle Einheiten teilen was hat man dann? ;)
mboeller
2006-04-20, 12:25:41
scheint so zu sein, das auch die dunkle Seite der Macht an diesem Thema arbeitet. Allerdings incl. Compiler + Software support. Das ganze heist dort spekulative Threading.
link (as found on Beyond3D): http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.