Archiv verlassen und diese Seite im Standarddesign anzeigen : Dual Core, Quad Core usw der richtige Weg?
KinGGoliAth
2006-04-09, 16:47:37
falls es so ein thema schon gibt dann bitte closen aber das thema ging mir doch die letzte zeit vermehrt durch den kopf, da immer mehr vom zukünftigen quad core die rede ist und ich mich mit diesem zeug noch nicht so richtig anfreunden kann.
ist das ganze wirklich so sinnvoll? sollte man nicht lieber auf die leistung der einzelnen prozessoren verbessern anstatt einfach 2 , 4 , 8 , 16 oder 32 ;) cpus auf einen träger zu klatschen?
die heutigen dual cpus profitieren ja eigentlich auch nur von ihrer power, wenn man anwendungen hat, die mit mehreren cpus bzw kernen etwas anfangen können. für alle anderen programme (und das dürfte sicherlich bei mindestens 90% liegen) ist die mehrleistung durch einen oder mehrere zusätzliche kerne gleich 0.
bei quad core wird das genau so sein. ein kern hat immer zu tun und die anderen kommen nur ins spiel, wenn eine anwendung diese ausdrücklich unterstützt. alles andere läuft trotz quad core (mehr oder weniger) elendig langsam, da die zusätzlichen kerne nicht eingebunden werden können. man gibt also wahnsinnig geld für etwas aus, was man in 90% aller fälle garnicht (aus)nutzen kann, weil mehrere kerne nicht unterstützt werden. mit einem einzelnen, schnelleren prozessor wäre man dann bedeutend besser bedient als mit 4 "gleich langsamen kernen" von denen man 3 nicht nutzen kann.
natürlich wird es in zukunft dann auch vermehrt programme geben, die auf dual core, quad core usw geschrieben wurden und damit mehr anfangen können als heutige aber bis dahin wird es sicherlich noch eine weile dauern und die "alten" programme werden auch in zukunft genau wie in der vergangenheit langsam laufen solange dafür kein patch oder ähnliches rauskommt, die sie multicore-fähig macht (was wohl sicherlich nicht passieren wird, schließlich kann man mit einem "neuen" (das alte nur multicore-fähig :rolleyes: ) programm mehr geld verdienen als mit einem patch)
kurzfristig wird multicore also eigentlich nur marketing hype und rausgeblasenes geld sein, da man damit garnichts anfangen kann. wirklich brauchbar wird es erst werden, wenn es flächendeckend programme gibt, die damit auch etwas anfangen können. und das wird -wie erwähnt- sicherlich noch das eine oder andere jahr dauern. und bis dahin gibt es schon dual quad deluxe cpus ;)
ist das ganze wirklich so sinnvoll? sollte man nicht lieber auf die leistung der einzelnen prozessoren verbessern anstatt einfach 2 , 4 , 8 , 16 oder 32 ;) cpus auf einen träger zu klatschen?
Das Problem ist dass das immer schwieriger wird ohne Takterhöhung - und diese stagniert nunmal.
KinGGoliAth
2006-04-09, 16:52:07
Das Problem ist dass das immer schwieriger wird ohne Takterhöhung - und diese stagniert nunmal.
das ist natürlich vollkommen richtig. dann geht es aber darum neue und effizientere architekturen und verfahren zu entwickeln anstatt "den alten schrott" zu vervielfältigen.
was intel und amd in der entwicklerstube haben ist natürlich wieder eine ganz andere frage. vielleicht sind dual und quad core auch nur lückenfüller bis zum großen wurf. bis dahin kann man mit dem unsinn aber ne menge geld scheffeln.
svenw
2006-04-09, 16:55:39
Multi threading ist die Zukunft in dem Bereich der diese Rechenpower braucht: Multimedia (Video, Spiele etc). Diese Systeme eigenen sich fast perfekt für Multithreading, wenn die Progger sich erst mal darauf einstellen.
Bisher hat sich kaum einer die Mühe gemacht, das es nicht wirklich viel gebracht hat. Im Multimedia Bereich haben die Doppelkerne bei optimierten Anwendungen fast 100% mehr Rechenleistung als Einzelkerne. Einzelkerne sind aus verschiedenen Gründen praktisch ausgereizt. Die Wärmeentwicklung ist nicht mehr in den Griff zu bekommen. Für alles außer Multimedia sind sämtliche am Markt erhältlichen CPUs schon jetzt massiv überdimensioniert.
PatkIllA
2006-04-09, 16:58:46
Du kannst vorhandene Programme aber nicht beliebig per Out-Of-Order Execution beschleunigen und viel anderes bleibt neben Takterhöhung nicht übrig.
Eine völlig neue Archtitektur könnte da schon noch was bringen, aber dann ist man halt nicht mehr x86 kompatibel. Und selbst dann bringt Parallelität durch Mutlicore immer noch Vorteile.
svenw
2006-04-09, 16:59:22
das ist natürlich vollkommen richtig. dann geht es aber darum neue und effizientere architekturen und verfahren zu entwickeln anstatt "den alten schrott" zu vervielfältigen.
Das haben sie doch, nennt sich Multicore. :biggrin:
Das Steigerungspotential ohne Taktsteigerung ist, wie Coda sagte, nicht da und Taktsteigerungen bringen uns in die finsteren Niederungen der Abwärmeproblematik. Die heutigen Single Core Prozssoren sind schon sehr effektiv. Intel hat mit dem neuen Design ca 20% mehr herrausgeholt, nen 2ter Kern bringt bis zu 100%. Singelcore ist noch nicht ganz tot, riecht aber schon etwas komisch. :tongue:
KinGGoliAth
2006-04-09, 17:04:41
Das haben sie doch, nennt sich Multicore. :biggrin:
nein. das nennt sich "den alten schrott" zu vervielfältigen.
PatkIllA
2006-04-09, 17:08:41
Dann sag uns doch mal, wie du ohne Multicore die Geschwindigkeit nennenswert steigern willst.
Da wird schon enormer Aufwand betrieben, um die Einheiten ordentlich mit Befehlen zu füttern.
svenw
2006-04-09, 17:18:29
Nicht böse sein King, aber wenn du eine gute Idee hast, behalt sie für dich. Laß sie dir patentieren und du hättest ausgesorgt.
An dem Problem haben sich so alle Entwickler bei AMD/Intel die Zähne ausgebissen. Denn jede Steigerung in dem Bereich würde sich über Multicore vervielfachen. Wenn es ne Möglichkeit gäbe eine Einzel CPU doppelt so schnell zu machen, würde das auch für jede Multicore CPU gelten (bei eh schon verdoppelter Leistung da 2 Kerne)..
Neomi
2006-04-09, 17:20:40
dann geht es aber darum neue und effizientere architekturen und verfahren zu entwickeln anstatt "den alten schrott" zu vervielfältigen... bis dahin kann man mit dem unsinn aber ne menge geld scheffeln.
Wenn du schon so abwertend vom x86 sprichst, dann mach doch einen besseren Vorschlag. Wie soll aus einem einzelnen Core noch deutlich mehr Leistung herausgeholt werden? Architekturverbesserungen (wie z.B. der Conroe) können nicht bis in alle Ewigkeit fortgeführt werden, Takterhöhungen sind auch ein Problem. Natürlich bringen mehrere Cores keinen echten Vorteil für bisherige Software, die nur einen Core nutzt, aber warum sollte man sich immer an der alten Software orientieren?
Mehrere Cores sind keine Zwischenlösung bis neue Singlecore-CPUs erscheinen, sondern nur ein Zwischenschritt hin zu noch mehr Cores. Und danach kommen nochmal mehr Cores. Nur darüber kann man die Leistung quasi beliebig skalieren.
svenw
2006-04-09, 17:50:22
Nur so ein Gedanke nebenbei: multithreading ist der normale Weg etwas zu tun.
Schau dir mal an welche Probleme Roboter mit dem Laufen haben und wir mit unseren mager getakteten Gehirnzellen können: laufen, die Umgebung wahrnehmen inklusive Mustererkennung(Gesichter, Gegenstände), gleichzeitig unseren ultrakomplexen Körper am Laufen halten und so nebenbei reden und komplex denken. Jede dieser Tätigkeiten für sich würde bei der von Menschen Erreichten Leistungen einen heutigen Computer überfordern und trotzdem schlagen wir mit unserer mit unserer lahmen Wetware jeden Computer um Längen. Das schaffen wir nur, weil wir massivst "multithreaded" sind. Ein Teil unseres Gehirns ist fürs sehen, der anderen für die Motorik, der nächste für reden etc zuständig.
Lokadamus
2006-04-09, 18:08:36
falls es so ein thema schon gibt dann bitte closen aber das thema ging mir doch die letzte zeit vermehrt durch den kopf, da immer mehr vom zukünftigen quad core die rede ist und ich mich mit diesem zeug noch nicht so richtig anfreunden kann.
ist das ganze wirklich so sinnvoll? sollte man nicht lieber auf die leistung der einzelnen prozessoren verbessern anstatt einfach 2 , 4 , 8 , 16 oder 32 ;) cpus auf einen träger zu klatschen?
die heutigen dual cpus profitieren ja eigentlich auch nur von ihrer power, wenn man anwendungen hat, die mit mehreren cpus bzw kernen etwas anfangen können. für alle anderen programme (und das dürfte sicherlich bei mindestens 90% liegen) ist die mehrleistung durch einen oder mehrere zusätzliche kerne gleich 0.mmm...
HyperThreading Technologie von Intel hat eigentlich schon gezeigt, dass die Zukunft mehreren Kernen gehört. Du kannst vielleicht nicht die eine Anwendung beschleunigen, aber du kannst 2 Anwendungen parallel laufen lassen, woduch beide am Ende schneller arbeiten.
Der Vorteil ist, dass dem System die Puste nicht mehr so schnell ausgeht und da Windows die Anwendungen im schlimmsten Fall an eine CPU hängt, ist immernoch die andere frei.
Durch Multicore verlierst du nichts, erst recht nicht, wenn die Anwendungen parallelisiert, also mit Multithreading arbeiten. Die Frage ist höchsten, was willst du zur Zeit haben und trenne dich gleich von der aktuellen Software. Die ist grösstenteils nicht auf multithreading ausgelegt und darum nur beschränkt einsetzbar. In 1 oder 2 Jahren wird es genug Software geben, wodurch Tests ala "Single, Dual, Quadcore" interessant werden, aber momentan nicht.
Nur so ein Gedanke nebenbei: multithreading ist der normale Weg etwas zu tun.
Ja, aber nicht der normale bzw. einfache Weg eines Programmierers etwas zu entwickeln.
Wenn man diese x-core Entwicklung zuende durchdenkt kommt man bei FPGAs an. Mit allen Vorteilen, aber auch mit allen Nachteilen davon.
BlackBirdSR
2006-04-09, 19:13:47
das ist natürlich vollkommen richtig. dann geht es aber darum neue und effizientere architekturen und verfahren zu entwickeln anstatt "den alten schrott" zu vervielfältigen.
Dabei steht man nur vor einem großen Problem.
Man nähert sich wieder einer CISC ähnlichen Philosophie an.
Intel geht mit Core schon in einigen Bereichen diesen Weg. Alles wird wieder komplexer und schwerer zu überschauen.
Das mag jetzt gerade super toll sein. Auf Dauer will man dann aber wohl doch wieder zurück zu simpleren Strukturen.
Und bei denen ergibt sich die Leistung dann wieder über den Takt und die Anzahl an Kernen.
So etwas wie Core kann man nicht beliebig weiter treiben. Irgendwann sitzt man wieder auf einem Logikmonster, bei dem jeder Eingriff in Schwerstarbeit endet um minimale Performancesteigerungen zu erhalten.
Demirug
2006-04-09, 19:20:24
Ja, aber nicht der normale bzw. einfache Weg eines Programmierers etwas zu entwickeln.
Weil wir es alle so gelernt haben...
Weil wir es alle so gelernt haben...
Das ist nur ein Teil der Wahrheit und das weißt du auch...
Es ist wohl in allen Fällen einfacher einen Algorithmus seriell statt parallel zu programmieren.
HellHorse
2006-04-09, 21:49:35
Nur so ein Gedanke nebenbei: multithreading ist der normale Weg etwas zu tun.
Schau dir mal an welche Probleme Roboter mit dem Laufen haben und wir mit unseren mager getakteten Gehirnzellen können: laufen, die Umgebung wahrnehmen inklusive Mustererkennung(Gesichter, Gegenstände), gleichzeitig unseren ultrakomplexen Körper am Laufen halten und so nebenbei reden und komplex denken. Jede dieser Tätigkeiten für sich würde bei der von Menschen Erreichten Leistungen einen heutigen Computer überfordern und trotzdem schlagen wir mit unserer mit unserer lahmen Wetware jeden Computer um Längen. Das schaffen wir nur, weil wir massivst "multithreaded" sind. Ein Teil unseres Gehirns ist fürs sehen, der anderen für die Motorik, der nächste für reden etc zuständig.
Nein, multithreading ist nicht der normale Weg wie Menschen denken oder Probleme lösen.
Das sieht man schon, wenn Männer versuchen zu kochen ;) , von etwas anderes daneben machen wollen war nicht erst reden. Und das ist der ideale Fall, von unabhängigen Tasks wie er meist nicht existiert. In der Realität bringen 9 Frauen ein Kind nicht in einem Monat zur Welt.
Die Software Welt ist nicht so weit und wird es auch in 10 Jahren nicht sein. Man hat schon so genug Probleme ohne Multithreading. Sicher es gibt immer spez. Anwedungsgebiete in denen es gut geht, aber allgeimen ist es schwer, war schwer und wird auch schwer bleiben.
PatkIllA
2006-04-09, 21:57:16
Ich glaube schon, dass sich da immer mehr Algorithmen entwickeln werden und auch immer mehr Tools den Entwicklern unter die Arme greifen werden.
Vielleicht gehört das dann in 10 Jahren auch in die Standvorlesung zum Programmieren.
Eigentlich kann man bei den meisten komplexen Anwendungen Teile finden, die praktisch unabhängig voneinander sind.
Gibt in der Tat aber ein paar "lustige" Fehler und wenn etwas nur in 1 von 10 Fällen auftritt macht es die Fehlersuche auch nicht grade einfach.
Das schlimmste sind eigentlich Race-Conditions und dergleichen. Da kommt man selbst mit Debuggern nicht mehr bei.
grandmasterw
2006-04-09, 22:23:26
Tja, viel kannst eh nicht machen. Mir fiele grad noch ein, mehr spezialisierte Chips einzusetzen. Der Qualitätssprung von Software-3D zu Hardware-3D war extrem, der von Software-Geometrie zu Hardware-Geometrie auch ganz gut (vergleich mal Gothic 2 und Morrowind).
Das ganze macht imho mehr Sinn, als die CPU weiter aufzublasen. Vielleicht reißen diese Physik-Chips in Zukunft noch was raus. Genauso wie Hardware-MPEG-Encoder, Soundkarten, die 3D-Sound beschleunigen, usw.
Demirug
2006-04-09, 22:40:10
Tja, viel kannst eh nicht machen. Mir fiele grad noch ein, mehr spezialisierte Chips einzusetzen. Der Qualitätssprung von Software-3D zu Hardware-3D war extrem, der von Software-Geometrie zu Hardware-Geometrie auch ganz gut (vergleich mal Gothic 2 und Morrowind).
Das ganze macht imho mehr Sinn, als die CPU weiter aufzublasen. Vielleicht reißen diese Physik-Chips in Zukunft noch was raus. Genauso wie Hardware-MPEG-Encoder, Soundkarten, die 3D-Sound beschleunigen, usw.
Wenn du genügend Cores hast kannst du aber diese funktionen auch auf dieses verteilen.
OBrian
2006-04-09, 23:59:35
Nur einfach immer weiter die Cores zu verdoppeln, vervierfachen usw. wird nicht so schnell gehen. Erstens kostet es eine Menge Platz auf dem Wafer (statt einem Dual-Core könnte man auch zwei CPUs auf der Siliziumfläche bauen), außerdem muß die Software auch erstmal in breiter Front passiv parallelisiert werden. Mit der ersten Verdoppelung ist der Vorteil, mehrere single-threaded Programme flüssiger gleichzeitig laufenlassen zu können, auch schon verbraucht, der Schritt von 2 auf 4 Core wird viel weniger bringen. Im Serverbereich ist das anders, da gibts entsprechende Software schon lange, deswegen werden die QuadCores da auch auf fruchtbaren Boden fallen.
Aber es gibt ja noch genug Möglichkeiten der Leistungssteigerung mit diversen Tweaks an der Architektur. Seht Euch z.B. an, was Intel mit dem Conroe bringt, da werden bestimmte Befehle zusammengefaßt und beschleunigt ausgeführt, das soll allein ca. +10% bringen. AMD bastelt ja offenbar auch weiter, die Ausführungseinheiten auf den kürzlich aufgetauchten 65nm-Die-Foto sehen auch einigermaßen verändert aus. Also ich seh da noch nicht total schwarz in der Steigerbarkeit der IPC-Leistung (instructions per clock), im Gegenteil.
Und die Frequenz kann man auch immer noch ein Stück anheben. Nur weil Intel es mit dem P4 extrem übertrieben hat, bedeutet das ja jetzt nicht die totale Abkehr davon. Der Conroe wird wohl locker bis 3,5GHz gehen, in 45nm ohne große Veränderungen auch über 4GHz. Bei AMD wird es mit entsprechenden Strukturgrößen und ein paar Anpassungen wohl auch nicht anders aussehen. Das geht dann eben nicht mehr so schnell, daß Stromverbraucht und Wärmeabgabe durch die Decke schießen, aber langsam aber sicher wird es mehr.
Nur einfach immer weiter die Cores zu verdoppeln, vervierfachen usw. wird nicht so schnell gehen. Erstens kostet es eine Menge Platz auf dem Wafer (statt einem Dual-Core könnte man auch zwei CPUs auf der Siliziumfläche bauen)
Mit jedem Die-Shrink hat man i.d.R. doppelt so viel Platz bei gleicher Die-Fläche zur Verfügung. Yonah ist z.B. nicht größer als Dothan.
Also ich seh da noch nicht total schwarz in der Steigerbarkeit der IPC-Leistung (instructions per clock), im Gegenteil.
Ich schon. Man muss geradezu unglaublichen Aufwand treiben um diese 10% noch rauszukitzeln.
Neomi
2006-04-10, 00:23:01
Mit jedem Die-Shrink hat man i.d.R. doppelt so viel Platz bei gleicher Die-Fläche zur Verfügung. Yonah ist z.B. nicht größer als Dothan.
Nicht zu vergessen, daß ein Core nur ein (nicht mal besonders großer) Teil der CPU ist. Wenn sich die Cores den Cache teilen (zumindest L2 und potentiell L3), sollte einiges an Platz zur Verfügung stehen.
Ich schon. Man muss geradezu unglaublichen Aufwand treiben um diese 10% noch rauszukitzeln.
Jep, das sehe ich auch so.
PS: ich werde mir wahrscheinlich innerhalb der ersten 2 Monate ab Marktverfügbarkeit einen Quadcore gönnen. Obwohl... der Opteron 265 ist ja inzwischen schon fast attraktiv günstig geworden. Und das passende Mainboard dazu (K8WE) ist auch für knapp 400 zu haben.
Bokill
2006-04-10, 00:24:57
Gut möglich, dass wir gar 2 Wege zugleich sehen.
Weg 1 mit einem sehr komplexen Kern (bzw. einem wenig Multicore), sowie Weg 2 mit ganz, ganz vielen Multicores, aber dafür deutlich weniger komplexe Kerne.
Auch wenn der Weg noch nicht so klar ist. Die Tendenzen sind ja sichtbar. Cell auf der einen Seite, Conroe auf der anderen Seite.
Im Embeddedbereich ist zudem auch die Integration der Northbridge auf dem CPU Kern sehr weit fortgeschritten. Gegebenenfalls rückt der Trend auch in die ganz dicken Universal CPUs.
Wichtig scheint mir, dass die CPU Hersteller immer mehr Arbeit auf den internen Datenverkehr richten müssen. IBM hat sich da für Rambus (mit einem Ringbus) in der Cellarchitektur entschieden. Andere haben sehr früh an internen Fabrics (Sun) gearbeitet. Viele integrieren so etwas in den Kern. Nur Intel hat sich da vergleichsweise zurückgehalten (was nicht bedeutet, dass sie da nichts haben).
@OBrian
Willst du nun hier häufiger posten? :D
Denk dran, ich werde nie wieder (http://www.planet3dnow.de/vbulletin/member.php?u=6136) [p3d] so fette Threads wie auch P3D machen. Und eigene Threads hier habe ich praktisch nicht auf 3DC.
MFG Bobo(2006)
Ich schon. Man muss geradezu unglaublichen Aufwand treiben um diese 10% noch rauszukitzeln.
und wieviel aufwand muss man treiben um aus einer multicore-cpu wirklich viel leistung zu gewinnen?
bei dual-core mag das ja noch ganz gut gehen wenn man die software von beginn an auf multi-core-cpus auslegt sagen wir mal 50-70% leistung zu bekommen.
bei quad-core ist dann vielleicht auch noch ein sprung von 50% drinnen, aber was soll dann mit 8/16 usw. cores kommen?
selbst wenn wir davon ausgehen dass die software mit jeder verdoppelung der cores 70% gewinnen kann, sind es bei 4 cores nur mehr 289% gegenüber einem, bei 8 cores gar nur mehr ~500%.
wir sind also verdammt schnell auf einem sehr ineffizienten weg.
und wenn man sich den logikaufwand im prescott, K8 und yonah anschaut fällt eher auf dass dieser bei deutlich höherem IPC trotzdem deutlich niedriger ist. da ist also noch einiges an platz für zukünftige optimierungen ;)
Neomi
2006-04-10, 00:44:11
bei dual-core mag das ja noch ganz gut gehen wenn man die software von beginn an auf multi-core-cpus auslegt sagen wir mal 50-70% leistung zu bekommen.
Auch beim Sprung von 8192 auf 16384 Cores wird man noch eine Verdopplung der Leistung bekommen, wenn man die richtige Software zum Vergleich heranzieht. Irgendwann wird das sogar für Spiele gelten.
Man braucht sich doch nur mal die Roadmap der Hersteller angucken.
Es wird nicht nur in die Breite (mehr Kerne) gehen, sondern auch in die Höhe (mehr Takt).
Fangen wir doch mal mit dem Conroe an: Dieser soll mit 2 Kernen starten, die anfangs mit maximal 2,67 GHz getaktet sind.
Laut bisherigen Vorabinformationen leistet selbst ein Core deutlich mehr, als alle bisherigen Desktop-CPUs.
Dadurch werden auf jeden Fall schonmal alle Anwendungen erheblich schneller, die nur einen Core nutzen.
Dann geht es weiter: Die Taktrate soll im Laufe der Zeit auf 3,2 / 3,33 GHz gesteigert werden (Q4). Da jeder Kern mit dem höheren Takt arbeitet, werden wir im Vergleich zu heutigen CPUs mindestens 30-50% mehr CPU-Power haben.
Dann geht es nächstes Jahr weiter: Die ersten Quad Cores sollen kommen. Ich gehe davon aus, das diese anfangs mit geringeren Taktraten an den Start gehen, wie z.B. 4x2,4 GHz.
Da sich aber auch die Fertigungtechnologie ständig verbessert (45nm soll schon im 2 Hj. 2007 bei Intel in Serie gehen), steht einem Upgrade auf z.B. 4x3,2 GHz nichts mehr im Wege. Und das wäre innerhalb der nächsten 18 Monate machbar!
Berücksichtigt man den weiteren Fortschritt auf 45, 32nm, 25nm oder was auch immer danach noch kommt, dann wird es eigentlich nie ein Ende geben!
Außerdem werden früher oder später alle Anwendungen, von mehreren Kernen profitieren - ganz einfach deshalb, weil die Entwickler davon ausgehen können, das in ein paar Jahren jeder mindestens einen Dual Core Prozessor haben wird. Das wird Multithreading-Anwendungen stark fördern. Ich bin mir sogar ziemlich sicher, das in 10 Jahren alle Anwendungen, bei denen es möglich ist, von mehreren Cores profitieren - ganz einfach weil die Hardwarebasis breitflächig vorhanden sein wird.
Dazu kommt, das auch andere Komponenten wesentlich schneller werden. Die Speicherbandbreite wird stark steigen, was auch allen Anwendungen zugute kommt, selbst wenn sie nicht von mehreren Cores profitieren können.
Wie man am Conroe sieht, ist Takt nicht alles, was wichtig ist. Wer weiß schon, wie der Conroenachfolger aussehen wird. Vielleicht arbeitet dieser beim gleichen Takt nochmal deutlich schneller, weil mehr Funktionseinheiten hinzugefügt oder andere Optimierungen vorgenommen wurden!?
Die Möglichkeiten sind, zumindest in den nächsten 10 Jahren lange nicht ausgeschöpft.
bei dual-core mag das ja noch ganz gut gehen wenn man die software von beginn an auf multi-core-cpus auslegt sagen wir mal 50-70% leistung zu bekommen.
bei quad-core ist dann vielleicht auch noch ein sprung von 50% drinnen, aber was soll dann mit 8/16 usw. cores kommen?
Du gehst von der heutigen Situation aus.
Ich bin mir sicher, das die Hersteller früher oder später nicht nur die Anzahl der Cores erhöhen, sondern auch die Effizienz jeden Cores steigern werden.
Beispielweise könnte Intel früher oder später einen integrierten Speichercontroller einsetzen um den einschränkenden FSB abzuschaffen.
Dazu wird die Speicherbandbreite stark ansteigen. Während heute fast noch DDR400 im Dual Channel standard ist (6,4 GB/s), sind es in Zukunft DDR2/800 (12,8 GB/s) und später gar DDR3 mit über 17 GB/s.
Das wird natürlich auch heutigen Dual und bald anstehenden Quad Cores zugute kommen.
Du gehst von der heutigen Situation aus.
Ich bin mir sicher, das die Hersteller früher oder später nicht nur die Anzahl der Cores erhöhen, sondern auch die Effizienz jeden Cores steigern werden.
da bin ich mir nicht so sicher, bei konsolen beispielsweise geht der trend in eine komplett andere richtung, relativ viele cores, dafür simpel und mit relativ geringer leistung.
auch sprach intel davon in zukunft cpus mit über 100 cores zu entwickeln, wovon jeder einzelne weit unter 1W strom verbraucht.
ich kann mir nicht vorstellen dass diese cores noch die leistung eines conroe-core erreichen.
Beispielweise könnte Intel früher oder später einen integrierten Speichercontroller einsetzen um den einschränkenden FSB abzuschaffen.
Dazu wird die Speicherbandbreite stark ansteigen. Während heute fast noch DDR400 im Dual Channel standard ist (6,4 GB/s), sind es in Zukunft DDR2/800 (12,8 GB/s) und später gar DDR3 mit über 17 GB/s.
Das wird natürlich auch heutigen Dual und bald anstehenden Quad Cores zugute kommen.
das ist wieder ein ganz anderes thema. wenn die anwendung speicherlimitiert ist hilfen natürlich weder mehr cores, noch ein core mit höherer IPC-leistung.
dann muss man natürlich versuchen die speicherlimitierung so gut wie möglich mit caches, befehlsumsortierungen oder wie auch immer zu eliminieren.
dass ändert aber nichts daran dass es in fast jedem programm anteile gibt die sich nicht parallelisieren lassen. selbst wenn diese wie bei meiner obigen (imo optimistischen) annahme nur 30% betragen, sind bereits bei 8 kernen starke ineffizienzen bemerkbar, die mit jedem weiteren kern noch schlimmer werden. irgendwelchen overhead durch synchronisierungen sind da noch nicht mal eingerechnet.
es wird natürlich immer anwendungen, wie beispielsweise encoder geben die sich fast vollständig parallelisieren lassen und damit jeden weiteren kern fast vollständig in leistung umwandeln können.
der großteil der anwendungen wird sich aber nicht so gut parallelisieren lassen, und da wird das ganze verdammt schnell sehr ineffizient.
Die Frage ist doch, ob es überhaupt Anwendungen gibt, die für uns Homeuser interessant sind, die sich nicht auf "unendlich viele Cores" verteilen lassen.
Bei Games gibt es fast immer mehrere Aufgaben zu bewältigen: Physik, KI, Sound, Grafik etc.
Bei solch sachen wie email programmen, mp3 player usw. braucht es keine höhere rohpower, wozu? Ist doch schon schnell genug. :)
Sachen wie Videoencoding oder dergleichen lassen sich bereits durch multicores erheblich beschleunigen, genauso wie ein Betriebssystem, welche dynamisch von mehreren Cores gebrauch machen kann (wenn nicht Vista schon darauf optimiert ist, dann der nachfolger).
Mir fiele spontan keine wichtige Anwendung ein, die sich im homebereich nicht erheblich beschleunigen lässt.
Davon mal abgesehen: Kann man eigentlich unterschiedlich taktende Cores auf einem einzigen Prozessor unterbringen?
Wenn das nicht geht, bliebe ja immer noch Möglichkeit im Jahre 2010 beispielweise, neben einem Octa-Core mit 8x4 GHz auch noch einen weiteren Prozessor auf dem Mainboard zu setzen, der nur zwei Kerne hat, aber halt mit 2x10 GHz taktet - genau für solche Anwendungen, die sich nicht paralellisieren lassen.
Lokadamus - nixBock
2006-04-10, 07:30:12
Das ist nur ein Teil der Wahrheit und das weißt du auch...
Es ist wohl in allen Fällen einfacher einen Algorithmus seriell statt parallel zu programmieren.mmm...
Das ist doch das Dilemma. Die Frage ist, wer wann wo es wie gelernt hat. Ist so ähnlich wie OOP gegenüber dem alten Verfahren (komme nicht auf den Namen, funktionsorientiert). Jeder, der zuerst gelernt hat, mit Funktionen die Probleme zu lösen, hat ein Problem damit, die Sache als Objekt anzugehen und es so zu lösen. Wer häufig genug programmiert und fähige Kollegen hat, wird es auch schnell lernen, aber ansonsten ...und wieviel aufwand muss man treiben um aus einer multicore-cpu wirklich viel leistung zu gewinnen?
bei dual-core mag das ja noch ganz gut gehen wenn man die software von beginn an auf multi-core-cpus auslegt sagen wir mal 50-70% leistung zu bekommen.
bei quad-core ist dann vielleicht auch noch ein sprung von 50% drinnen, aber was soll dann mit 8/16 usw. cores kommen?
selbst wenn wir davon ausgehen dass die software mit jeder verdoppelung der cores 70% gewinnen kann, sind es bei 4 cores nur mehr 289% gegenüber einem, bei 8 cores gar nur mehr ~500%.
wir sind also verdammt schnell auf einem sehr ineffizienten weg.1.) Woher hast du diese Zahlen?
2.) Da hier gerne Spiele als Grundlage herangezogen wird, hast du schonmal daran gedacht, dass die KI meistens eingeschränkt wird, nur damit das Spiel noch flüssig läuft? Da die KI ausgelagert werden kann (und sie selber in mehreren Teilen aufgeteilt werden kann), kann ein fähiger Programmierer damit locker nen Quadcore beschäftigen, nur um XYZ Objekte berechnen zu lassen. Das willst du gleich wieder einschränken?Davon mal abgesehen: Kann man eigentlich unterschiedlich taktende Cores auf einem einzigen Prozessor unterbringen?
Wenn das nicht geht, bliebe ja immer noch Möglichkeit im Jahre 2010 beispielweise, neben einem Octa-Core mit 8x4 GHz auch noch einen weiteren Prozessor auf dem Mainboard zu setzen, der nur zwei Kerne hat, aber halt mit 2x10 GHz taktet - genau für solche Anwendungen, die sich nicht paralellisieren lassen.Nein, das macht auch keinen Sinn.
Und was erhoffst du dir vom 2x10GHz Teil? Ich hab irgendwie das Gefühl, dass du entweder von Programmieren keine Ahnung hast oder den Sinn von mehreren Kernen nicht verstehst ...
KinGGoliAth
2006-04-10, 10:02:15
mal abgesehen von den anfänglichen "mach's doch besser, wenn du kannst :tongue: " wird es jetzt richtig interessant hier.
Meine Wunschcomputer der Zukunft hat 2 leistungsoptimierte Kerne und ein größeres FPGA auf einem Die und einen automatischen JIT-Schaltungscompiler der hotspots im Programm automatisch durch optimierte Schaltungen auf dem FPGA ersetzt.
Der komplizierteste Teil davon ist der Compiler. Der ist ähnlich kompliziert wie der automatische Multithreading-Compiler den NEC vor ein paar Monaten in der Pressemeldung hatte. Mich würde es überraschen wenn jemand sowas in den nächsten 10 Jahren hinbekommt.
Expandable
2006-04-10, 12:52:13
Berücksichtigt man den weiteren Fortschritt auf 45, 32nm, 25nm oder was auch immer danach noch kommt, dann wird es eigentlich nie ein Ende geben!
Doch. Nämlich genau dann, wenn die Quanteneffekte überwiegen und die klassische Physik nicht mehr "funktioniert", d.h., wenn die Strukturen in der Größenordnung von Atomen sind. So bei 10 bis spätestens 1nm dürfte dann wohl endgültig Schluss sein mit den heutigen Verfahren.
Falls man Quantenrechner hinbekäme, DAS wäre dann ein gigantischer Leistungssprung.
Das ist doch das Dilemma. Die Frage ist, wer wann wo es wie gelernt hat. Ist so ähnlich wie OOP gegenüber dem alten Verfahren (komme nicht auf den Namen, funktionsorientiert). Jeder, der zuerst gelernt hat, mit Funktionen die Probleme zu lösen, hat ein Problem damit, die Sache als Objekt anzugehen und es so zu lösen. Wer häufig genug programmiert und fähige Kollegen hat, wird es auch schnell lernen, aber ansonsten ...
Nein das ist eben kein guter Vergleich, da ein Algorithmus parallel immer aufwändiger ist egal welches Programmierparadigma man dafür verwendet.
Das hat nichts mit "wir sind alle zu blöd" zu tun, sondern es ist einfach ein immens gesteigerter Aufwand.
Lokadamus - nixBock
2006-04-10, 13:26:31
Nein das ist eben kein guter Vergleich, da ein Algorithmus parallel immer aufwändiger ist egal welches Programmierparadigma man dafür verwendet.
Das hat nichts mit "wir sind alle zu blöd" zu tun, sondern es ist einfach ein immens gesteigerter Aufwand.mmm...
Ich stimme dir zwar zu, dass ein Algorithmus schwer zu parallisieren ist, aber du wirst doch wohl nicht ein ganzes Program ala FarCry an nur einem Algorithmus festmachen, oder? :| ...
Der_Donnervogel
2006-04-10, 13:49:00
Ich glaub nicht, daß das mit der Paralellisierung, so schnell, so effzient umgesetzt wird, daß die MultiCores wirklich gut ausgenutzt werden können. Schließlich muß man Programme ja nicht nur programmieren sondern auch testen und debuggen. Das ist bei paralellen Programmen alles andere als ein Spaß. Wenn ich denke wie bugverseucht manche Spiele schon rausgekommen sind, wage ich garn nicht erst daran zu denken, wie das sein wird, wenn sich die Programmierer noch um Bugs kümmern müssen, die nur in irgendwelchen nicht reproduzierbaren Konstellationen von Threads auftreten.
Ich stimme dir zwar zu, dass ein Algorithmus schwer zu parallisieren ist, aber du wirst doch wohl nicht ein ganzes Program ala FarCry an nur einem Algorithmus festmachen, oder? :| ...
Nö, das nicht. Aber du must F (Anteil an sequentiellem Code) klein halten, sonst bringt dir die ganze Soße eh fast nix.
http://upload.wikimedia.org/wikipedia/en/7/7a/Amdahl-law.jpg
0.5 (dunkelrote Linie) = 50% serieller Code (ja das konvergiert wirklich gegen 2). Schön, nicht? ;)
Und selbst bei 10% seriellem Code ist das schon übel wie man sieht. Die Kurven sollten sich manche Leute mal verinnerlichen.
Die frage ist ja ob es für den Desktop bereich sinnvoll ist mehr als 4 cores zu verwenden (vlt auch 8) da eben sequentieller code mc-cpu´s u.U. schlecht bis sehr schlecht skalieren lässt...
aber fragen wir mal in die andere richtung? mit welchem prog laste ich 4 x 3.2 ghz aus? gut... der videobearbeitungssektor lässt da sicher einige andwendungen zu... das ist aber schon sehr speziell und nicht das was jeder braucht...
im games bereich wird es immer möglich sein die aktuelle hw auszureizen... aber gerade bei ner mc cpu wirds dann schon schwierig, da diese jede menge ungenutzter leistung bietet (wenn 1 core schon ausreicht um ein spiel zum laufen zu bringen...siehe jedes bisherige game ;)) also sprintet hier die hw der softwareentwicklung davon... denn bis ein auf quadcore ausgelegtes spiel einen solchen wirklich 100% ausnutzt (overhang, sequentieller code usw schon mit einberechnet(denn wirklich jedes quäntchen möglicher leistung kann man mit einem game nicht aus mehreren kernen rausholen)) wird es auch noch länger dauern... gerade wenn sich ppus durchsetzt sollten (oder das ganze von ner graka berechnet werden kann)
und das für office & co schon längst genug rechenleistung da ist bezweifelt wohl auch keiner...
daher lohnen sich mehrere cores gerade wenn man spezielle dinge (u.a: videobearbeitung, oder auch programme zum pw knacken (die sollten auch recht arg von mehreren cores (und viel speicher) profitieren)) mit dem pc vorhat kann es nützlich sein... für einen 08/15 arbeitspc ist es sinnlos...
und für einen gamerpc wird man wohl schon mit einem dc die nächsten jahre gut fahren
@CODA du meintest doch sequentiell am ende deines statements und nicht seriell... oder?
Und selbst bei 10% seriellem Code ist das schon übel wie man sieht. Die Kurven sollten sich manche Leute mal verinnerlichen.
Wenn ich mir anschaue, wie ein Spiel funktioniert, würde ich aber sagen, dass der Anteil an parallelisierbarem Code immer weiter zunimmt. Grafik, Physik, KI - das ist alles quasi komplett parallelisierbar und was dann noch übrig bleibt wird wohl nie die Leistung heutiger SingleCores beanspruchen.
Meiner Erfahrung nach (und das was ich bisher an Source-Code, Algorithmen und anderem Zeug gesehen habe) ist das ganz und gar nicht der Fall. Nur 10% serieller Code wäre schon verdammt gut bei einem Spiel.
Außerdem geht dieser Graph ja von perfekter Paralellisierbarkeit aus. In der Realität must du dauernd synchronisieren über Mutexes, Semaphores usw. und das ist auch serielle Laufzeit.
@CODA du meintest doch sequentiell am ende deines statements und nicht seriell... oder?
Das ist austauschbar.
AMD schlägt fork-join für multithreading in Spielen vor:
http://developer.amd.com/assets/AMD_GDC_2006_talk.pdf
Davon gehe ich die ganze Zeit schon aus. Anders ist es ja nur noch dämlich..
Aber selbst mit diesem Konzept kannst du es vergessen den sequentiellen Codeanteil unter 10-20% zu bekommen.
aylano
2006-04-10, 15:08:31
Wenn das nicht geht, bliebe ja immer noch Möglichkeit im Jahre 2010 beispielweise, neben einem Octa-Core mit 8x4 GHz auch noch einen weiteren Prozessor auf dem Mainboard zu setzen, der nur zwei Kerne hat, aber halt mit 2x10 GHz taktet - genau für solche Anwendungen, die sich nicht paralellisieren lassen.
Momentan siehts nicht so aus, sonst hätte man ja jetzt noch hochgetakte Singel-Cores vorallem im Gamer-Bereich.
Meiner Erfahrung nach (und das was ich bisher an Source-Code, Algorithmen und anderem Zeug gesehen habe) ist das ganz und gar nicht der Fall.
Nur 10% serieller Code wäre schon verdammt gut bei einem Spiel.
Wieviel Prozent des sequentiellen Codes verlangt als Nebenbedingung, dass garnichts anderes mehr zu dieser Zeit berechnet werden darf? Wieviel Rechenzeit verbraucht dann noch dieser Code?
Selbst für Scriptsprachen wie LUA gibts MT-Erweiterungen. Auch kann man unabhängige Skripte verteilen.
Außerdem geht dieser Graph ja von perfekter Paralellisierbarkeit aus. In der Realität must du dauernd synchronisieren über Mutexes, Semaphores usw. und das ist auch serielle Laufzeit.
Die Synchronisation ist wohl eins der schwierigeren Probleme. Aber bei entsprechender Planung auch nicht sooo schlimm.
Hauptproblem bei Spielen ist wohl eher, dass man von jedem vorherigen Projekt den alten Quellcode übernimmt. Das führt zu verherrendem Code, den teilweise niemand mehr erklären kann, weil der entsprechende Mitarbeiter seit über 10 Jahren nicht in der Firma arbeitet und Kommentare überflüssig sind. :mad: ("Ob die Funktion noch genutzt wird? Setz nen Breakpoint rein und spiel mal 10 Minuten")
Und solchen Code müßte man nun auf Multithreading umstellen. Das ist ziemlich unmöglich und wird wegen der fehlenden Hardwarebasis auch bei neueren Projekten kaum gemacht. Wenn es doch gemacht wird, pfuscht man meistens nur etwas mit OpenMP rum. Stattdessen verlässt man sich darauf, dass der neulizenzierte Code (Physikengine etc.) von anderen Firmen Multithreading unterstützt. Mit Dual- oder Quadcore ist das imo noch vertretbar, aber alles andere als optimal.
Wieviel Prozent des sequentiellen Codes verlangt als Nebenbedingung, dass garnichts anderes mehr zu dieser Zeit berechnet werden darf?
Jeder, das ist ja die Definition davon ;)
Aber selbst mit diesem Konzept kannst du es vergessen den sequentiellen Codeanteil unter 10-20% zu bekommen.
Du betrachtest das falschrum, man muss einfach nur den parallelen Anteil soweit erhöhen, dass man über 90% kommt, schon hat man automatisch den sequentiellen Anteil unter 10% :cool:
Jeder, das ist ja die Definition davon ;)
Man kann auch sequentiellen Code in einem Modul haben, der aber andere Module nicht berührt.
Nenn doch einfach mal Beispiele, an welcher Stelle man keine anderen Berechnung durchführen darf.
Es geht nicht darum, dass irgendwas zwangsläufig einzeln laufen muss, sondern dass es eine praktische Grenze gibt wieviele parallele Berechnungen man gleichzeitig machen kann.
Wenn die Zahl der CPUs größer ist als die Zahl der parallelen Berechnungen hat man sequentiellen Code. Bei Anzahl CPUs gegen unendlich wird das immer mehr.
Es geht nicht darum, dass irgendwas zwangsläufig einzeln laufen muss, sondern dass es eine praktische Grenze gibt wieviele parallele Berechnungen man gleichzeitig machen kann.
Diese Grenze liegt aber imo deutlich höher für Spiele als hier manche Glauben machen wollen.
Wenn die Zahl der CPUs größer ist als die Zahl der parallelen Berechnungen hat man sequentiellen Code. Bei Anzahl CPUs gegen unendlich wird das immer mehr.
Bei sowas kann man aber auch leicht in die Theoriefalle tappen.
Solange ich genug parallele Berechnungen habe, ist so eine Grenze immer noch theoretischer Natur. Und zumindest mittelfristig wird man nicht an diese Grenze kommen.
Voraussetzung ist halt ein Redesign bisheriger Strukturen.
Solange ich genug parallele Berechnungen habe, ist so eine Grenze immer noch theoretischer Natur. Und zumindest mittelfristig wird man nicht an diese Grenze kommen.
Voraussetzung ist halt ein Redesign bisheriger Strukturen.
Das ist sehr stark eine Frage der Kosten. fork-join Parallelisierung ist relativ billig, Parallelisierung die Hardwaredesign gleicht ist extrem teuer.
Demirug
2006-04-10, 17:23:48
Diese Grenze liegt aber imo deutlich höher für Spiele als hier manche Glauben machen wollen.
Die Grenze liget höher weil sämtliche theoretische Betrachtungen zu diesem Thema immer von einem Problem das zu lösen ist ausgehen. Spiele müssen aber für jeden Frame eine Vielzahl von Problemen lössen. IMHO kann man das ganze daher auch gut mit der Automatisierung einer beliebigen Industrieanlage vergleichen. Um ein Produkt zu fertigen sind viele einzelne Schritte notwendig und dort ist es üblich mehrer CPUs zu nutzen.
Aqualon
2006-04-10, 17:31:24
Nö, das nicht. Aber du must F (Anteil an sequentiellem Code) klein halten[...]Müsste das nicht klarer formuliert lauten, dass F der Anteil des sequentiellen Codes an der Ausführungszeit ist?
Aqua
Die Grenze liget höher weil sämtliche theoretische Betrachtungen zu diesem Thema immer von einem Problem das zu lösen ist ausgehen. Spiele müssen aber für jeden Frame eine Vielzahl von Problemen lössen.
Darauf wollte ich eigentlich raus.
Man kann ein Spiel ja auch als ein einziges Problem betrachten. Dann würde ich aber gerne die >10% performancekritischen Stellen sehen, die das gesamte Spiel zu einer rein sequentiellen Abarbeitung zwingen.
Solange in einem Spiel mehr rechenintensive "Baustellen"/Module existieren als der Prozessor Kerne hat, ist das Heraufbeschwören von Auslastungsproblemen schwachsinnig.
10% der Zeit in sequentiellem Code ist nichts ungewöhnliches in einer Multithreaded App.
Time will tell.
10% der Zeit in sequentiellem Code ist nichts ungewöhnliches in einer Multithreaded App.
Time will tell.
Es gibt auch Anwendungen die skalieren fast linear mit Anzahl der Prozessoren.
Bei Spielen sehe ich keinen Grund, warum sie das, entsprechendes Enginedesign vorausgesetzt, nicht bis zu einem gewissen Grad tun sollten.
Amdahl's Law geht davon aus, dass x Prozent der Zeit nur ein einziger Prozessor ausgelastet werden kann. Bei Spielen wohl kaum der Fall. Wenn dir etwas einfällt, wo dies auftreten könnte, nur her damit. :)
Es kommt bei Spielen auf Latenz an, nicht auf Durchsatz, da muss man analog zum Hardwaredesign kritische Pfadbetrachtungen anstellen wenn man Beschleunigung durch Parallelisierung bewerten will.
svenw
2006-04-10, 20:40:31
Man kann aber ein Spiel in fast unendlich viele Häppchen zerlegen. Ein KI Thread/Gegner, physikalische Berechnungen, Füttererung der Graka, Game voice. Bei dem von Coda genannten Problem muß eben zu einem bestimmten Zeitpunkt alles "fertig" sein, damit seriell weiter gerechnet werden kann. Die KI der GEgner ist aber nicht an die Frames gebunden, physikalische Berechnungen schon. Ich vermute mal, das sich Spiele besser als bei Codas Grafik durch Cores beschleunigen lassen, Linearität aber bei weitem nicht erreicht wird.
Beliebig kleine Häppchen machen aber keinen Sinn. Ab einer bestimmten Granularität ist der Overhead den man durch das erzeugen und synchronisieren bekommt so groß, dass man keine Performance mehr gewinnt.
Neomi
2006-04-10, 23:14:29
Beliebig kleine Häppchen machen aber keinen Sinn. Ab einer bestimmten Granularität ist der Overhead den man durch das erzeugen und synchronisieren bekommt so groß, dass man keine Performance mehr gewinnt.
Die einzelnen Aufgaben sollten so klein wie nötig, aber so groß wie möglich sein. Der Synchronisierungsaufwand wird meiner Meinung nach zwar allgemein überschätzt, aber vernachlässigen darf man ihn wirklich nicht.
Man muß aber auch nicht unbedingt die gleiche Arbeit auf doppelt so viele Pakete halber Größe aufteilen, um die doppelte Anzahl an Cores zu nutzen. Man kann stattdessen auch die doppelte Arbeit auf doppelt so viele Pakete gleicher Größe verteilen. Für die Sachen, die mir da vorschweben, sind 4 Cores aber noch deutlich zu wenig.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.