Software für 3DNow! im Vergleich!

Bokill

Bokill

Gesperrt
Mitglied seit
18.01.2002
Beiträge
5.689
Renomée
60
Standort
Bremen
Ich hab ein Artikel (schon ein Jahr alt) gefunden, der die Seitenwagen an Zusatzinstruktionen vergleicht. Es wäre gut, wenn noch weitere Beispiele und Vergleiche genannt werden, von Software die einen echten Nutzen daraus ziehen, also keine Benchmarks, frei nach dem Motto "Meiner ist länger als Deiner"
zum Artikel, leider englisch, aber die Quelle ist für weitere gute Artikel bekannt.
http://www.digit-life.com/articles/simd1task/index.html
 
Also gelesen wurde mein Posting schon:-*, vermutlich wurde auch der X-Bit-Schwester-Artikel gelesen.
Aber keiner kann reale Optimierungen für 3DNow! nennen*traurig*.

Mir kam noch c't das Apfelmännchen-Programm in den Sinn:-*.

Hat denn wirklich keiner mal'n eigenes Programm geschrieben?

Es wäre auch mal lustig ein Programm zu zeigen, das grottenschlecht auf Intel läuft, weil:
1. Der L1 Cache auf Intel-CPU's zu klein ist*baeh*.
2. Das Programm auch nicht gut in den L2 Cache passt;D.
3. Das Programm viele Sprünge hat*chatt*.
4. Einige komplexe Befehle hat, die nicht direkt bei Intel in Hardware gegossen sind*baeh* (der K68) hat einige Befehle in Hardware;D, die auch der Athlon nicht in Hardware*kopfkratz hat!).
5. Genügsam im Umgang mit dem Speicher ist:).
 
Zuletzt bearbeitet:
Du willst weitere Beispiele für 3DNow!-optimierte Software haben? Gerne, weil da kann ich wieder Eigenwerbung machen! ;) Mein kleines Bildbearbeitungstool ST View (http://come.to/st-soft/) ist auf 3DNow! (einfachste Fassung, auch für K6-x-CPUs geeignet!) und SSE optimiert. ...und 3DNow! ist auf meinem AthlonXP immer etwas flotter als SSE... ;D
 
Vielen dank @Seemann, ich habe dich schon häufiger bemerkt, deine Antworten waren immer kompetent und hast dich gegebenerweise auch gerne belehren lassen, außerdem hast du schon häufiger dich in den "Hardcore-Themen" verbissen (CPU-Architektur, Internas etct.) und dich nicht ausgeflennt, weil dein FSB doch "nur" *lol*220Mhz *lol*ist *lol*und eigentlich der Rechner sauber laufen sollte*chatt**lol*, weil irgendwann mal einer dies doch auch geschafft hat*chatt*.
Ich schaue umgehend nach!
 
Ahha, das ist doch eine Wohltat 8) ...solche Worte... Danke!

Hehe BTW: mein FSB läuft mit moderat erhöhten 136 MHz und mein Prozzi mit ~1500 MHz.... da bin ich konservativ... ;D

Ach, was mir noch an 3DNow! optimierter SW einfällt:
* DirectX
* Quake3-Engine
* UT und UT 2003 (bin mir aber net ganz sicher...)
 
Da gebe ich dir zwar recht, aber die Dinger sind zugleich auch sehr gut auf Intel lauffähig.
Und ob DirectX wirklich gut optimiert ist, glaube ich nicht und zwar aus folgendem Grund. Intel hat Kompiler die pfeilschnell sind, MS hat zwar auch einen aber wenn ich die c't richtig gelesen habe, waren die Kompiler von MS immer Welten auseinander. Da ich aber keine Ahnung vom Softwareschreiben habe, ist das eine gefühlsmäßige Vermutung.
Id, mit derQuake3-Engine, ist da schon ein anderes Kaliber, aber auch dort sind "Hacks" im Umlauf, die dann noch schneller auf AMD laufen.
Die gleiche Laufbahn hat wohl auch UT und UT 2003, wobei dort die Zusage der Entwickler zum Opteron, doch noch einiges erwarten läßt.
Vermutlich kannst du leider keine anderen Anwendungen nennen, wenn es wirklich optimierte Versionen gäbe, dann müßte AMD es doch recht sein, eine Seite zu pflegen, auf der dann die Vorzüge gepriesen werden. Früher hatten sie mal so eine Liste, aber die war wohl unter dem Motto "lippenbekenntnisse".

PS. 3DNow! hat häufiger aufgebohrte Softwareversionen angepriesen, die auch 3DNow! Optimierungen hatten.
E-Mule?!
PPS Danke für die prompte Reaktion.
PPPS FSB 140 (ECS!), XP1600 auf @XP1700
 
Zuletzt bearbeitet:
Wenn ich dazu was Älteres beisteuern darf:

Es gab zur Zeit der seligen Quake 2 Engine ein Q2 Update von AMD. Zusammen mit Voodoo 2 Karten gab es da ohne Probleme kanpp 50% mehr Performance. Das ist das beste Beispiel das mir einfällt, bei dem 3dnow! wirklich sehr sehr viel gebracht hat.

Mein K6/2 333 mit Voodoo 2 Karte hat damals den P2/400 mit Voodoo 2 meines Kumpels im Q2 Benchmark zersägt. ;D ;D ;D

Das waren noch Zeiten *seufz..... :)
 
Bei Flask MPEG kann man auch deutliche Unterschiede spüren. Wenn ichs noch richtig weiß hat das angefangen als der P4 rauskam und abartig schlechte Werte mit der qualitativ hochwertigen Bearbeitung mittels FPU lieferte.
 
Seid gegrüßt Genossen der 3DNow! Bruderschaft @SirGalahad5 und mtb][sledgehammer*massa*, sicher war allen der Q2-Patch bekannt, der war damals mit K6-2 400 und VoodooII so etwas wie der Flug durch die Schallmauer. Diesen Patch konnte man sich damals von der "Lippenbekenntnisseite" herunterziehen, aber was ist heute daraus weiter erwachsen?

Werden Videoschnittprogramme oder ähnliche Anwendungen tatsächlich darauf optimiert, oder zumindest AMD als die zweite Quelle mitberücksichtigt?
Wenden heutige Programme den riesigen L1-Cache aus? Der wird noch eine geraume Zeit die Domäne von AMD bleiben!
 
Zuletzt bearbeitet:
Da gab es doch diesen Renderer, wie hieß der?? PovRay?? Der hat glaube ich enorm von der Athlonarchitektur profitiert - einerseits von den drei FPU-Einheiten, andererseits aber auch weil komplett im L1-Cache abläuft.
 
Original geschrieben von Seemann
Da gab es doch diesen Renderer, wie hieß der?? PovRay?? Der hat glaube ich enorm von der Athlonarchitektur profitiert - einerseits von den drei FPU-Einheiten, andererseits aber auch weil komplett im L1-Cache abläuft.
Zum Vergrößern anklicken....

PoVRay ist ein Raytracer und hat ausdrücklich kein 3DNow!


9.4.4 Does POV-Ray support 3DNow?

No, and most likely never will.

There are several good reasons for this:

* 3DNow uses single precision numbers while POV-Ray needs (yes, it needs) double precision numbers. Single precision is not enough (this has been tested in practice).
(To better understand the difference between single and double precision numbers, imagine that you could represent values between 0 and 1000 with single precision numbers. With double precision numbers you don't get a scale from 0 to 2000 (as one might think), but from 0 to 1000000. The difference is enormous and single precision is not precise enough for what POV-Ray does.)
* Adding support for 3DNow (or any other CPU-specific feature) to POV-Ray would make it platform-dependant and not portable. Of course one could make a separate binary for AMD supporting 3DNow, but there are only two ways of doing this:
1. Compiling POV-Ray with a compiler which automatically can make 3DNow code from C. As far as I know, no such compiler exists which converts double precision math used in POV-Ray to single precision math needed by 3DNow. I don't event know if there's any compiler that supports 3DNow at all.
2. Changing the source code by hand in order to use 3DNow instructions. This is a whole lot of work (specially because you'll probably have to use inline assembler). The source code of POV-Ray is not very small. Would it be worth the efforts?

Note: There are a few things in POV-Ray that use single precision math (such as color handling). This is one field where some optimization might be possible without degrading the image quality.
 
PoVRay ist ein Raytracer und hat ausdrücklich kein 3DNow!
Zum Vergrößern anklicken....
Ja, das weiß ich auch, sonst hätte ich das ja ausdrücklich erwähnt! Aber Bokill hatte in seinem Posting auch andere Architekturmerkmale angesprochen - nämlich den großen L1-Cache. Und AFAIK profitiert PovRay nunmal davon. Deswegen wollte ich das hier als Beispiel bringen.
 
Sorry Leute mein erstes und zweites Posting passen nicht ganz zusammen, Ich wollte schon die AMD-Spezies ansprechen, vor allem wegen des 3DNow!-Instruktionssatzes, aber AMD hat ja noch andere Stärken.
Daher war die Bemerkung von @Seemann Ok, aber auch der Einwand von *massa*Desti.
Beide Beiträge sind aber Sinnvoll, da zum einen die Programmgöße/Unterteilung angesprochen wurde, zum anderen sogar eine Herstellermeinung wiedergegeben wurde.
Genau solche Meldungen möchte ich sehen, am Ende könnte ich mir gar ein speziellen Vergleich von Software vorstellen, in der die optimierte Software grottenschlecht auf Intel läuft, da in dem speziellen Fall AMD die Entwicklerplattform war!

Das wäre mal ein Kontrastprogramm in der Intelwüste.

Ich habe aber die Befürchtung, daß Intel dennoch recht gut dasteht... mit einem P3, da die Architektur des Athlon recht robust ausgelegt wurde, im Gegensatz zum P4 der dannach schreit für ihn vorgekaute Software zu nutzen.
 
Zuletzt bearbeitet:
Bei OpenSource ist es da einfacher, man kann zumindest die automatischen Optimierungen des Compilers fast immer benutzen, manche Programme sind auch zusätzlich "voroptimiert" z.B. MPlayer:


MPlayer 0.90rc5-3.2.2 (C) 2000-2003 Arpad Gereoffy (see DOCS)

CPU: Advanced Micro Devices (Family: 6, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE
 
Isch haabe gar kein Linux!
Gehört hier dennoch hin, verdammt hatte ich echt ignoriert, daß es noch andere OS auf dieser Welt gibt!
Naja, bin ja auch eher ein Win-Mausschubser mit technischem Interesse!
 
Zuletzt bearbeitet:
Da der Vorteil des großen L1 Caches angespochen wurde: ich denke dass man auf diese Art und Weise keine extremen Nachteile für den P4 programmieren könnte. Der L1 Cache ist zwar sehr klein, dafür arbeitet der L2 Cache extrem schnell, AFAIK hat er eine höhere Bandbreite als der L2 Cache des Athlon. Was bleibt sind höhere Latenzen. Die kann der P4 aber sicherlich aufgrund seines Trace Cache und der niedrigeren Latenzen im L1 Cache ausgleichen.
 
Dieses Phänomen habe ich teilweise auch schon beobachtet, und bin immernoch am Grübeln weshalb das so ist.
Bei manchen SSE2 Benches ist es mir allerdings klar. Z.B. bei der Matrixmultiplikation, deren aufwändister Teil das Multiplizieren ist. Es dürfte allerdings klar sein, dass der opteron nur mit der FPMUL Eingheit SIMD Multiplikationen durchführen kann. Das heißt eine FPMUL Einheit kämpft mit niedrigem Takt gegen eine Einheit beim Xeon(P4 mit hohem Takt.
Ich könnte mir vorstellen, dass die Optimierung auf 3Dnow!/SSE1 dagegen für den Opteron günstiger ausfällt, indem parallel zu den Mulfunktionen auch noch Add und sonstige Instruktionen im Code folgen, sodass der Opteron seine Einheiten besser parallel nutzen kann.
 
Zitat aus dem Inquirer-Artikel:
He said that the results for the Athlon XP come from using MMX multimedia instructions, while the Opteron uses the newly supported SSE2 instructions.

He said that means that the SSE 128-bit SIMD instructions are 30% slower than the MMX 64-bit SMD int instructions. He concludes that using SSE2 on the Opteron actually drags down its multimedia integer performance.

"When he reset the SSE2 checkbox for TMPGEnc, he said, "questioning his own hypothesis", its performance far exceeded the Pentium 4-2.8GHz.

TMPGEnc Encoding Time (seconds)
Opteron 242 (1.6GHz) 424
Pentium 4-2.8GHz 295
Athlon XP-2600+ 262
Opteron 242-SSE2 OFF 291

But it's not all bad news for the Opteron. He said that well known Japanese archiving software GCA (http://www.emit.jp/gca/gca.html) compresses WAV files a staggering 50% faster than P4-2.8GHz, equivalent to a Pentium 4.4GHz chip, if such a beast existed. "

Zumindest ist ein weiteres Programm genannt worden, welche unterschiedliche Optimierungsgrade kennt.
TMPGEnc

Entweder die Programme können noch nicht so gut mit dem Opteron zusammen, oder aber AMD "vergiftet" SSE2 mit langsamer Geschwindigkeit zugunsten von 3Now! und dem alten Vorgänger SSE1. SSE1 wird ja nun auch von dem C3 genutzt, wobei dort sogar die 3DNow!-Implementation rausgekgelt wird, obwohl VIA durch Cyrix+Idt die Rechte an Classic 3DNow! erworben hat!
Ich halte beide Möglichkeiten für gleich wahrscheinlich!
 
An AMDs Wille liegt das 100% nicht. Ich habe aus diesem Grund schon ein bischen im Software Optimization Guide zum K8 gelesen. Darin empfielt AMD ausdrücklich nur noch mit SSE2 zu programmieren, die alte FPU und 3Dnow! solle man dagegen nicht mehr benutzen.

Ich kann mir im Momenta uch vorstellen, dass der Opteron manche Befehle langsamer als der P4 abarbeitet, denn dann würde AMD nicht solche Forderungen stellen.
Ich tippe daher auf mangelahaften Code. Zu meinem Beispiel der Matrixmultiplikation noch zwei Schaubilder von TecChannel:
0012586_PIC.gif
0012587_PIC.gif

Links der der absolute Wert, rechts der IPC Wert. Wie man sieht kann der Opteron, obwohl er IMHO fast ausschließlich die FPMUL UNit beansprucht(Es sind zwar gleich viele Multiplikaionen wie Additionen, allerdings müssten die Multiplikationen einiges länger brauchen) einen besseren IPC als der P4 erreichen.
 
Fängt es wieder mal an*motz*, die ganze Ratz ist auf Intel8-(8-(8-(*motz**motz*
ausgelegt.
Frei nach dem Motto Ohhh dasnnn P4*chatt*? Dann nehmmm ichn SSE2 Satz*chatt*, statt welche Varianten versteht die CPU?
Welches Stepping?
Ah ja, dann nehme ich XXX Befehlsequenz cvfg !

Jede moderne CPU kann ihre Möglichkeiten mitteilen, ist es wirklich so schwer daraufhin Programme zu schreiben*kopfkratz, die dann wirklich die Möglichkeiten der CPU ausschöpft*kopfkratz?

*chatt**chatt**zweifel*???*abgelehnt
 
Zuletzt bearbeitet:
ist es wirklich so schwer daraufhin Programme zu schreiben, die dann wirklich die Möglichkeiten der CPU ausschöpft
Zum Vergrößern anklicken....
Ja verdammt, das ist es. Als Programmierer kannst du einfach nicht für jedes Stepping das Maximalste rausholen. Da Programmierste bis du Rentner bist! Überlege mal: Da müsste allein mind. 4 AMD-Varianten schreiben (K6-x, Athlon, AthlonXP, Hammer), zusätzlich zu den 4 Intel-Varianten (Pentium2, Pentium3, Pentium4, Prescott). Das ist manuell einfach nicht zu bewerkstelligen. Und Kompiler können naturgemäß nicht das Optimum herausholen. Das Problem liegt einfach darin: Die Software prüft ab, ob z.B. SSE2 vorhanden ist. Jo, isses, dann wird ein "Zweig" für SSE2 ausgeführt, ohne zu wissen, dass der Opteron (oder irgendeine andere CPU) vielleicht ohne Optimierungen schneller läuft... Kann man ja auch nicht wissen, weil die CPUs zur Zeit der Programmierung noch nicht erhältlich waren...
 
Dann kann man also nur hoffen, daß AMD mindestens 1/3 des Marktes abdeckt, damit wenigstens in Ansätzen die Möglichkeiten ausgenutzt werden.
Oder noch krasser, der Opteron setzt sich so schnell und gut durch, daß Intel im Hintertreffen ist, und den AMD-Pfad hinterherhechelt.
 
Noch ma' kurz zum Inquirer-Artikel:
Ich halte es problematisch, die SSE2-Performance nur an Hand eines einzelnen Benchmarks zu beurteilen, da können auch noch andere Faktoren eine Rolle gespielt haben...
 
Mit der Quickmeldung an @Nero habe ich möglicherweise zu schnell geschossen. Interessant fand ich den Kommentar von @seemann, daß die Befehle für SSEX über den langsamen Vector-Pfad ausgeführt werden.
Das klingt so, als wenn AMD sparsam mit den Resourcen umgeht, und so quasi ihr 3DNow!-Funktionen wiederverwendet um dann SSEX auszuführen.
Is nur eine Vermutung, aber hier im Forum war mal ein Die eines PentiumM abgebildet, dort war der Bereich für die SSE2-Einheiten riesig, eigentlich noch größer als die klassischen Recheneinheiten vom aufgebohrten PIII, die ja die Innerreien des PentiumM bilden.
 

Ähnliche Themen

eratte
nVidia Geforce RTX 4060/4070/4080/4090 (Ti/Super) (Ada/PCIe 4.0): Tests/Meinungen im Netz. Links in Post 1
23 24 25
Antworten
610
Aufrufe
46K
eratte
eratte
eratte
Intel ARC A310/380/580/750/770 (Alchemist/PCIe 4.0): Tests/Meinungen im Netz. Links in Post 1
8 9 10
Antworten
226
Aufrufe
24K
eratte
eratte
eratte
AMD Radeon RX 7600/7700/7800/7900 (GRE/XT/XTX) (Navi3x/RDNA3/PCIe 4.0): Tests/Meinungen im Netz. Links in Post 1
40 41 42
Antworten
1K
Aufrufe
70K
eratte
eratte
S
HP Victus Gaming Knaller, mit Phoenix aus der Asche?
Antworten
17
Aufrufe
2K
NEO83
NEO83
P3D-Bot
News SETI.Germany : World Community Grid: Projekt wieder in Betrieb und Neuigkeiten zu drei Subprojekten
Antworten
0
Aufrufe
351
P3D-Bot
P3D-Bot
Zurück
Oben Unten