AMD oder Intel?

[Euklid]

Hallo Leute,

um das "Sommerloch" zu füllen, habe ich diese Umfrage gestartet.

Ich persönlich bin zugegebenermaßen ein AMD-Fan

Leider befindet sich die Firma offenbar in einer tiefen finanziellen Kriese...
http://www.heise.de/newsticker/AMD-meld ... ung/110829" onclick="window.open(this.href);return false;

wolln wir mal hoffen, dass die da wieder rauskommt. Sollte AMD pleite gehen, wird Intel sicher die Preise für seine Prozessoren verdoppeln und Innovationen halbieren.

Bin überzeugt, dass diese Kriese überwunden sein wird, wenn es AMD gelingt, das Fusion-Konzept vor dem Larabee-Konzept von Intel zum Erfolg zu bringen.

Wie sieht das bei Euch aus? Seit ihr auch hardwareinteressiert?
Gibt es hier Intel-Fans?

Was haltet Ihr von Fusion oder Larabee?

Wäre schön, einige Meinungen zu hören.

Viele Grüße, Euklid

[monta]

Ich persönlich bin zugegebenermaßen ein AMD-Fan

Ich auch.

Abgesehend davon komm ich ja aus Dresden, wie die Prozessoren auch

Musste erstmal nachlesen, was du meinst.
Die Tatsache, den Grafikchip in die CPU zu integrieren finde ich einen guten Ansatz. Warum sollten dort zwei Chips arbeiten, wo es heutzutage wenig technische Hindernisse geben dürfte, das ganze nicht zu vereinen.
Finde ich vorerst persönlich auf jeden fall nützlicher, als die Kernzahl weiter auszubauen - zumindest im Heimgebrauch. Der Limitierende Faktor dann sind ja nicht mehr die CPU-Kerne, sondern Lese und Schreibgeschwindigkeiten. Abgesehen davon, welche Software nutzt denn heute die 4 Kerne eines Phenoms wirklich aus?
Somal man ja genaugenohmen dann noch ein Speichercluster usw. benötigen würde, um ggf. 8 oder 16 Kerne auszulasten. (Und das, wo die meisten Motherboards nur 4 SATA-Anschlüsse haben )

[Christian]

Ich denke das ist zu kurzschtig, auf lange sicht gibt es keinen Unterschied zwischen CPU und GPU. Die kernzahl hochzunehen ist also längerfristig der bessere Weg denke ich. Man kann heute schon Echtzeit Raytracing auf den CPU´s ausführen. Mit steigender Paralellisierung wird das immer effizienter. Damit werden GPU´s die ja nur versuchen ein Raytracing nachzuahmen überflüssig.

[monta]

Wenn das in die CPU mit integriert wird, haben die zusätzlichen Kerne, ob sie nun GPU-Kern oder CPU-Kern heißen, auch jetzt schon ne sinnvolle Verwendung.
Nur, jetzt mehr Kerne und extra noch separate GPUs halte ich momentan für nicht sinnvoll.

[af0815]

Wenn man von der Anzahl der Kerne ausgeht, hat Intel (Quadcore) die Nase vorne. Ansonsten habe ich bis jetzt fast nur AMD gehabt.

Baüglich Auslastung habe ich schon oft eine Round-Robin (Im Kreise laufen) verhalten festellen können, es gibt immer mehr SW die mehr Kerne benuzt. Besonders bei Linux hat es immer schon gut funktioniert. Ich habe das schon die Dual-Cpu Brettern früher festgestellt. Da hat Win noch nicht mal gewusst, das es 2 CPUs geben kann, zumindest nicht am Consumer Market.

[Christian]

Naja es geht vom Takt her, nicht merh viel höher also weicht man auf viele Kerne aus. Und auf kurz oder lang wird das das Hauptziel werden. Mit vielen kleinen Kernen kann man wesentlich mehr Strom sparen als mit einem großen. Die Diskussion Pascal in dieser Richtung zu optimieren besteht ja schon lange. Drücken können wir uns davor soviel wir wollen kommen wirds doch. Ich sehe hier eigentlich ne gute Chance für Pascal. Da die Sprache viel klarer als C ist sollte der Compiler hier einfacher in diese Richtung optimieren können mit weniger Eingriffen vom Programmierer.

[Euklid]

Wenn man von der Anzahl der Kerne ausgeht, hat Intel (Quadcore) die Nase vorne.

Das halte ich für ein Gerücht - AMD stellt seit langem Vierjern-CPUs her. Die sind im Vergleich zu Intels CPUs sogar in einem zentralen Punkt fortschrittlicher:
AMD-Kerne teilen sich den noch relativ schnellen Level-3-Cache. Wenn die Intel-Kerne miteinander kommunizieren möchten, läuft das derzeit noch auf sehr umständlichen Wegen. Das ist einer der Gründe, weshalb die Effizienz von AMD-Prozessoren durch die Nutzung mehrerer Kerne stärker zunimmt als die der Intel-Konkurrenzprodukte.

Zur Zeit bekommt Intel natürlich einen hohen Takt hin - in Verbindung mit einer geringfügig niedrigeren Instructions-Per-Clock. Daher hat zur Zeit hinsichtlich der Spitzenmodelle Intel die Nase ein gutes Stück vorn.

Die Diskussion Pascal in dieser Richtung zu optimieren besteht ja schon lange. Drücken können wir uns davor soviel wir wollen kommen wirds doch. Ich sehe hier eigentlich ne gute Chance für Pascal.

Das sehe ich ganz genau so! Hieraus könnte man doch ein Thema auf dem Lazarus-Forentreffen machen?

Derzeit besteht nur durch Multithreaded-Programmierung die Möglichkeit, mehrere Kerne zugleich zu benutzen. Wäre schön, wenn der Compiler einige Optimierungen, die in diese Richtung gehen, selbst übernimmt.
Sehr hilfreich wäre es außerdem, wenn es gelingen würde, den Debugger so zu modifizieren/programmieren, dass er bei Multithreaded-Anwendungen nicht den Geist aufgibt.


Euklid

[Christian]

Wir könnten auf dem Treffen zumindest Herrn Kämpf mal darauf ansprechen wie seine Ideen in dieser Richtung sind.

[alexander]

ich bin ebenfalls ein AMD-Fan. Hauptsächlich weil, AMD vieeeeeeeeeel kleiner als Intel ist.
6 Mrd Umsatz im vergleich 38 Mrd.

Ich habe bis jetzt jeden Computer mit einem AMD ausgestattet. Außerdem war es immer ein bisschen billiger

[RSE]

Wie viele Threads ein Programm hat, sollte meiner Meinung nach immer vom Programmierer selbst gesteuert werden, und nicht vom Compiler! Außerdem wäre das Debuggen noch wesentlich schwieriger, wenn plötzlich manche Sachen unerwarteterweise echt parallel laufen (manchmal klappt´s, manchmal nicht). Meiner Meinung nach sollte man höchstens die Erstellung von multithreaded-Programmen weiter vereinfachen. Eine Anpassung des Debuggers auf mehrere Threads finde ich hingegen äußerst sinnvoll, wenn nicht gar notwendig.

Dem im 3. Post angesprochenen verschwindenden Unterschied zwischen CPU und GPU würde ich so nicht unterstützen, schließlich ist die CPU wesentlich mehr auf Logik und Integer-Arithmetik ausgerichtet als die GPU, die mehr auf Matrixoperationen optimiert ist und in diesem Bereich viel mehr Hardwareimplementierungen hat. GPU und CPU sind daher meiner Meinung nach nicht wirklich vergleichbar.

Bei der Verbindung von CPU und GPU sehe ich ein weiteres Problem: Die Kühlung. Schließlich werden dabei die 2 größten Hitzeerzeuger im Computer zusammengelegt. Das Ergebnis dürfte wieder zu fauchenden oder monströsen und schweren Kühler-Lüfter-konstruktionen führen, wie in der späten Pentium IV Ära (über 3GHz). Ich selbst habe einen PIV mit 3,2GHz, einen recht großen Turmkühler und immernoch gut Geräusch im Gehäuse.
Zudem kann man nach einer solchen Integration nur noch schlecht (falls überhaupt) nachträglich nochmal eine bessere Grafikkarte einbauen, dann ist immer gleich ein kompletter neuer PC fällig.

[Christian]

Wie viele Threads ein Programm hat, sollte meiner Meinung nach immer vom Programmierer selbst gesteuert werden, und nicht vom Compiler!

Das muss natürlich mit speziellen Statements gekapselt werden so das sich der Programmierer schon im klaren darüber ist das der compiler hier code für mehrere Threads erzeugt...

Außerdem wäre das Debuggen noch wesentlich schwieriger, wenn plötzlich manche Sachen unerwarteterweise echt parallel laufen (manchmal klappt´s, manchmal nicht). Meiner Meinung nach sollte man höchstens die Erstellung von multithreaded-Programmen weiter vereinfachen. Eine Anpassung des Debuggers auf mehrere Threads finde ich hingegen äußerst sinnvoll, wenn nicht gar notwendig.

Seit wann ist er denn nicht multithreadfähig ? GDB ists zumindest...

Zudem kann man nach einer solchen Integration nur noch schlecht (falls überhaupt) nachträglich nochmal eine bessere Grafikkarte einbauen, dann ist immer gleich ein kompletter neuer PC fällig.

Brauchst du ja in dem Fall gar nicht da es kein Gut oder schlecht dabei mehr gibt. Das ist als ob jetzt jemand sagt aber wenn Sound on board ist dann kann ich doch gar keine 16 bit Soundkarte mehr nachrüsten...

[RSE]

Ich hab keine Ahnung was da in Entwicklung/geplant ist, aber wenn es nur wie eine billige Onboard-Grafik sein soll, dann halte ich das für unsinnig. Wenn es hingegen eine CPU-nahe Unterstützung für die GPU wird, kann es durchaus sinnvoll werden. Dann kann die CPU-nahe Architektur für Geschwindigkeitsvorteile genutzt werden und schonmal ein Grundmaß an GPU-Power bereitgestellt werden. Dann könnten Grafikkartenimplementierungen entweder nur noch die Anschlüsse bereitstellen oder zusätzliche GPU-Power bereitstellen. Ich glaube aber kaum, dass so ein Standard ohne größere Probleme umgesetzt werden kann. Zudem müsste sich die GPU im CPU-Gehäuse bei Nichtbenutzung komplett abschalten, um keine überflüssige Hitze zu erzeugen.

[monta]

Was die Zusätzliche GPU-Power und zusammenarbeit mit zusätzlichen Grafikkarten angeht, ist das ja schon da...siehe SLI und AMD mit Crossfire. Nur das momentan die Grafikchips zwar im Motherboard, aber nicht in der CPU integriert sind. Aber für ArbeitsPC ist es ohnehin ausreichend. (Mal abgesehen von Autodesk-Produkten u.ä.)

[RSE]

Ich dachte SLI wäre nur zum Verbinden baugleicher (oder zumindest miteinander kompatibler) Grafikkarten untereinander... Kenne mich wohl zu wenig mit GraKa´s aus ;

[Christian]

Ich denke Intel machts mit dem larabee vor das ist der kommende Grafikchipsatz von Intel mit 32 x86 Kernen Versionen mit 16 und 64 sind auch geplant. Wozu brauch ich da nacher eine separate CPU und GPU ? Also genau das was ich eingangs gesagt hab ist fraglich ob sich das so schnell durchsetzen wird aber in die Richtung wirds gehn. Die wolln allerdings (noch) Shader auf der Karte laufen lassen was dann warscheinlich recht schnell in Raytracing geändert wird denk ich.