Anmelden

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD==SEE, Intel!=3DNow


iltis2k
2008-07-11, 00:31:24
Hallo zusammen,
mich würde mal interessieren warum AMD SEE benutzt, aber Intel kein 3DNow. Die beide haben doch so ein abkommen. Weiss jetzt nicht mehr wie genau das aussieht, aber AMD darf ja irgendwie die SEE Befehlssätze benutzen. Da stelle ich mir halt die Frage warum Intel nicht die 3DNow Befehlssätze benutzt. Ist Intel sich zu fein dafür?
Sind diese Befehle schon in SEE vorhanden? Wenn ja, wird das so auch von der Software erkannt?

Avalox
2008-07-11, 00:40:17
Hallo zusammen,
mich würde mal interessieren warum AMD SEE benutzt, aber Intel kein 3DNow. Die beide haben doch so ein abkommen.

Intel hat noch nie eine Technologie von AMD übernommen.

Bis auf !! AMD64 natürlich. Das war der Paukenschlag schlechthin.

Gast
2008-07-11, 01:15:11
Intel ist sich zu fein dafür, so kann man das ca. ausdrücken!

Früher hatte Intel den MMX Befehlssatz, diese konnte aber nur Integerberechnungen durchführen.
Darum führte AMD bei den K6 Prozessoren 3DNow! ein, welches jedoch von Intel boykottiert wurde und sich dadurch leider nicht durchsetzen konnte.
Stattdessen entwickelte Intel den SSE Befehlssatz, dieser kam aber erst später auf den Markt.
Durch die Marktmacht Intels wurde AMD gezwungen auch SSE in ihre Prozessoren zu implementieren.

iltis2k
2008-07-11, 01:15:37
Ja schon klar. Das hab ich auch mitbekommen, nutze es auch selber :). Aber warum haben die es sonst nicht? 3DNow ist doch bestimmt nicht schlecht.
Ich denke doch hoffentlich richtig, wenn ich sage das die Befehlssätze von der Software abgefragt werden und danach entschieden wird welcher benutzt wird. Würde Intel dann nicht auch von 3DNow profitieren?

iltis2k
2008-07-11, 01:18:31
Intel ist sich zu fein dafür, so kann man das ca. ausdrücken!

Früher hatte Intel den MMX Befehlssatz, diese konnte aber nur Integerberechnungen durchführen.
Darum führte AMD bei den K6 Prozessoren 3DNow! ein, welches jedoch von Intel boykottiert wurde und sich dadurch leider nicht durchsetzen konnte.
Stattdessen entwickelte Intel den SSE Befehlssatz, dieser kam aber erst später auf den Markt.
Durch die Marktmacht Intels wurde AMD gezwungen auch SSE in ihre Prozessoren zu implementieren.
Ok, aber 3DNow wurde doch auch weiter entwickelt.
Wie sieht das überhaupt mit 3DNow aus, ist das schon "tot"?

Sorkalm
2008-07-11, 01:56:24
Wie sieht das überhaupt mit 3DNow aus, ist das schon "tot"?

Hardwaremäßig wird es auch vom K10 von AMD noch unterstützt. VIA (Cyrix) hat es nur im C3 unterstützt, im C7 schon nicht mehr. Softwaremäßig sah es ja nie gut aus. ;)

ShadowXX
2008-07-11, 02:01:29
Ok, aber 3DNow wurde doch auch weiter entwickelt.
Wie sieht das überhaupt mit 3DNow aus, ist das schon "tot"?
Ja, im Prinzip ist 3DNow tot. Es gab nochmal ein 3DNow+, aber das wars dann auch.

Alle CPUs von AMD unterstützten danach dann SSE1 und SSE2 (irgendwann ab AthlonXP...natürlich auch weiterhin 3dNow+).
Das sind im Prinzip auch die (wenn überhaupt) am meisten genutzen SMID-Befehle.

Alles dannach (egal ob jetzt von AMD oder Intel) wird bisher nur sehr rudimentär und sehr spezieller SW unterstützt.

Auch bei den nächsten CPU-Generationen werden Intel und AMD wohl wieder getrennte wege gehen (wie auch schon bei C2D und Phenom) was SMID-Befehle betrifft....leider.

iltis2k
2008-07-11, 02:31:15
Auch bei den nächsten CPU-Generationen werden Intel und AMD wohl wieder getrennte wege gehen (wie auch schon bei C2D und Phenom) was SMID-Befehle betrifft....leider.
Das ist aber blöd, sowas bringt doch nichts, aber wem sage ich das :rolleyes:.
Was soll den da in Zukunft noch kommen. Kenne da bis jetzt nur SEE 4.2.

S940
2008-07-11, 08:33:26
Das ist aber blöd, sowas bringt doch nichts, aber wem sage ich das :rolleyes:.
Was soll den da in Zukunft noch kommen. Kenne da bis jetzt nur SEE 4.2.
Intel bringt nach SSE 4.2 avx:
http://softwareprojects.intel.com/avx/

AMD SSE5:
http://developer.amd.com/CPU/SSE5/Pages/default.aspx

Vorteil intel: 256bit Vektoren und ein hauseigener Compiler der alles zügig unterstützen wird
Vorteil AMD: umfangreicheres Befehlsrepertoire (z.B. Permutationen), teilweise bei Intel für AVX 2.0 vorgesehen.

AMD hat eigentlich immer die schlechteren Karten, der Markt macht meist was Intel sagt, weil Intel Marktführer ist. ~70-80% der x86 CPUs sind Intel, wieso sollten Programmierer da auf die 20-30% AMD Nutzer achten ... sowas ist teuer. Dazu kommt dann auch Intels Compiler, der unterstützt immer sofort die neuesten Erweiterungen, 3DNow! war damals nur per Assembler zugänglich. Mittlerweile unterstützt AMD den GNU Compiler gcc und den Portland Compiler, auch der Draht zu Microsoft und Visual Studio ist ganz gut, aber die Entwicklung ist natürlich nicht so verzahnt wie bei Intel :(

Einzige Ausnahme, wie schon erwähnt, war AMDs 64bit Erweiterung, die Intel zunächst nicht anbieten wollte. Mittlerweile ist aber sogar Intel stolz drauf, der offizielle Titel des Befehlssatzes wurde von EM64T auf Intel 64 geändert. Dass das eigentlich von AMD erfunden wurde, interessiert keinen.

Aja, 3DNOW! ansich ist wirklich tot, die 64bit Versionen von Windows unterstützen das offiziell schon gar nicht mehr, und alle 3DNOW! Befehle können größtenteils durch SSSE3 Befehle ersetzt werden, den Rest liefert SSE5 nach.

ciao

Alex

BlackBirdSR
2008-07-11, 09:26:43
Es gab wohl einfach nicht genug Gründe für Intel 3dnow! zu übernehmen.
Zudem hätte man den SIMD-Markt damit noch weiter segmentiert.3DNow! nutzt die x87-Register, womit Intels Initiative für die neuen XMM-Register ersteinmal ins Stocken hätte kommen können.
Es hat auch so schon lange genug gedauert, bis einigermaßen genug SSEx Code in z.B. Spielen zu finden ist (Anwendungen hatten es da schon immer etwas leichter).

Bei SSE5 und AVX könnte Ähnliches passieren. Der Markt wird segemntiert, so dass es keiner richtig nutzt. Dann einigt man sich auf einen Nenner und langsam gibt es mehr Support dafür.

Sorkalm
2008-07-11, 10:55:48
AMD hat eigentlich immer die schlechteren Karten, der Markt macht meist was Intel sagt, weil Intel Marktführer ist. ~70-80% der x86 CPUs sind Intel, wieso sollten Programmierer da auf die 20-30% AMD Nutzer achten ... sowas ist teuer.

Deswegen ist die Server-Sparte für AMD auch so wichtig. Gute Opterons bringen halt auch Server-Software die für AMD-Prozessoren optimiert wurde.
Nur sind entsprechende Produkte auf der Roadmap nicht unbedingt in Sicht...

ZZ @ work
2008-07-11, 11:04:24
3DNow ist doch bestimmt nicht schlecht.

3DNow! ist ein Zwischending zwischen MMX (integer)- und SSE (single)-Datenberechnungen, und somit gewissermaßen "stuck in the middle", weswegen 3DNow! für sich genommen 'ne tolle Sache ist, Entwickler trotzdem lieber zu SSE greifen, weil mehr Instruktionen zur Verfügung stehen und eine breitere Basis für Kompatibilität etabliert ist (AMD und Intel).


Zudem hätte man den SIMD-Markt damit noch weiter segmentiert. 3DNow! nutzt die x87-Register, womit Intels Initiative für die neuen XMM-Register ersteinmal ins Stocken hätte kommen können.

MMX nutzt (bzw. missbraucht) ebenfalls die FPU-Register, XMM-Register werden betriebssystemtransparent auf die FPU-Register abgebildet (damit ist beim Taskswitch kein Eingriff durch's Betriebssystem erforderlich, die Register werden automatisch gesichert - genial einfach, einfach genial). Erst SSE bringt eigene Register mit. Während MMX 8 (8-bit)-integers berechnen kann (oder auch 4 WORDs oder 2 DWORDs), ist 3DNow! eigentlich nur endlich das, was man von einer FPU für Gleitkommaberechnung (4 16-bit singles) erwartet, nämlich direkt ansprechbare Register, nicht mehr dieser umständliche indirekte Kram mit der FPU.

Fazit: Man muss aufpassen, wenn man MMX und 3DNow! vergleichen will. Eigentlich sind die Einsatzzwecke von beidem ziemlich unterschidlich, weil beides auch etwas ziemlich unterschiedliches macht.

Eigentlich ist die gesamte Unterstützung für neue Prozessorentechnologien absolut enttäuschend. Sämtliche SIMD-Aufsätze für CPUs (von MMX bis SSE4) sind doch ein Witz gegen die geballte parallele Rechenpower der modernen Numbercruncher namens diskrete GPUs. Intel's Larrabee ist für mich ein Zeichen, dass Intel das endlich auch einsieht. Natürlich hat man als Entwickler keine Lust, für Vektoreinheiten in irgendeiner Form zu entwickeln, wenn a) die nächste SSE-Version schon in der Pipeline steckt und b) das Ganze dann trotzdem geschwindigkeitsmäßig lächerlich wirkt im Vergleich zu GPGPU-Projekten. Direct3D11 mit seinen computational shaders wird hoffentlich dafür sorgen, dass SSE5 die letzte SSE-Version ist und man endlich mal auf ein sicheres Zugpferd setzten kann, und zwar auf GPGPU-Berechnungen losgelöst von CUDA, CTM oder dem Intel-Pendant für Larrabee, das sicher noch kommen wird. Stellt Euch eine Welt vor, in der der Entwickler SIMD-Operationen losgelöst von der Hardware einfach so implementieren kann, dank Direct3D sogar inklusive Fallback auf die CPU.
Anzuprangern ist übrigens auch, dass von AMD64 wenn überhaupt der größere Adressraum genutzt wird. Software, die echten 64-bit-Code (d.h. auch die größeren Register nebst neuer Befehle), wirklich nutzt, ist rar. Noch, könnte man hoffen, da 64-bit-Betriebssysteme nach wir vor nicht ausreichend repräsentiert sind. Aber auch da kommt möglicherweise der dedizierte Numbercruncher der wahren 64-bit-Revolution zuvor, welche noch kommen könnte, wenn - durch blanke Speicherknappheit von nur 4 GB - der Siegeszug der 64-bit-OSe doch noch ansteht.

BlackBirdSR
2008-07-11, 11:12:12
Fazit: Man muss aufpassen, wenn man MMX und 3DNow! vergleichen will.

Ging ja eigentlich um SSE und dessen neue Register und überhaupt nicht um MMX. Ansonsten stimm ich überall zu.
Es ist wohl einfach nicht genug Zeit und Geld vorhanden um alle die CPU-Möglichkeiten auszuschöpfen. Compiler schaffen das auch nicht und so bleibt eigentlich nur was du schon ansprichst.

Gast
2008-07-11, 11:17:25
Ging ja eigentlich um SSE und dessen neue Register und überhaupt nicht um MMX. Ansonsten stimm ich überall zu.


Das war auch nicht so sehr an Dich gerichtet, sondern an Post #3, welcher MMX mit eingebracht hat.

Ja, irgendwie ist das die Crux dabei, dass alles sich so schnell entwickelt: Es gibt einen deflatorischen Effekt, der dazu führt, dass letztlich gar nichts so wirklich unterstützt wird. Schade.

Coda
2008-07-11, 14:07:25
MMX nutzt (bzw. missbraucht) ebenfalls die FPU-Register, XMM-Register werden betriebssystemtransparent auf die FPU-Register abgebildet (damit ist beim Taskswitch kein Eingriff durch's Betriebssystem erforderlich, die Register werden automatisch gesichert - genial einfach, einfach genial).
MM-Register. XMM-Register sind die von SSE. Und nein sie werden nicht automatisch gesichert.

Gast
2008-07-11, 14:32:00
MM-Register. XMM-Register sind die von SSE.

Richtig.


Und nein sie werden nicht automatisch gesichert.

Falsch, siehe z.B. hier (http://de.wikipedia.org/wiki/MMX). Sieht man ja auch schon daran, dass das OS MMX nicht explizit unterstützen muss, damit man MMX nutzen kann.

Nochmal was grundsätzliches zu Dir, Coda: Merkst Du eigentlich nicht, dass Du hier im Forum mit Deinen einsilbigen Kommentaren immer wieder aneckst? So eine Antwort wie "nein" hilft niemandem. Dann muss man da auch ein wenig drauf eingehen. Bitte in Zukunft drauf achten, sonst kann man sich sowas auch sparen.

S940
2008-07-11, 18:55:17
Nochmal was grundsätzliches zu Dir, Coda: Merkst Du eigentlich nicht, dass Du hier im Forum mit Deinen einsilbigen Kommentaren immer wieder aneckst? So eine Antwort wie "nein" hilft niemandem. Dann muss man da auch ein wenig drauf eingehen. Bitte in Zukunft drauf achten, sonst kann man sich sowas auch sparen.
Könnte mir vorstellen, dass er mit seinen bald 20k Posts schon alles mal 100xxx erklärt hatte und seit dem 101 mal keine Lust mehr für lange Erklärungen hat :)

ciao

Alex

pest
2008-07-11, 19:58:12
Falsch, siehe z.B. hier (http://de.wikipedia.org/wiki/MMX). Sieht man ja auch schon daran, dass das OS MMX nicht explizit unterstützen muss, damit man MMX nutzen kann.


Coda hat Recht und wer schonmal mit MMX programmiert hat, weiß das auch
lang lebe femms :D

BAGZZlash
2008-07-11, 20:57:22
Coda hat Recht und wer schonmal mit MMX programmiert hat, weiß das auch
lang lebe femms :D

Und es ist doch falsch. Lies' doch S. 466 in "Das Assembler-Buch", Trutz Eyke Podschun, Addison-Wesley-Verlag München 2002.
Und FEMMS ist AMD-spezifisch.

pest
2008-07-11, 21:05:27
Und es ist doch falsch. Lies' doch S. 466 in "Das Assembler-Buch", Trutz Eyke Podschun, Addison-Wesley-Verlag München 2002.

hab ich nicht :rolleyes: - was steht denn da?
ohne Reseten der FPU-States kann man keine Berechnungen mehr machen

Coda
2008-07-11, 21:25:49
Ich hab in der Tat falsch gelesen. Ich hatte verstanden dass es gesichert wird wenn man zwischen FPU und MMX wechselt.