SSE/2 Auslastung aktueller CPUs [Archiv]

Gast

2007-01-08, 15:48:02

Vielleicht ist es noch niemanden so richtig aufgefallen, aber hier scheint doch etwas im Argen zu liegen. Möglicherweise bin ich hier nicht der einzige, der den Beteuerungen der Softwareindustrie, SSE/2 umfassend zu unterstützen, keinen Glauben schenkt. Zumindest seit dem ich den Perfmonitor von http://www.cpuid.com/perfmon.php getestet habe. Leider musste ich feststellen, dass man Programme, die wirklich intensiv Gebrauch von der SSE/2... Einheit machen, Spiele hier einmal ausdrücklich ausgenommen, spärlich gesät sind. Video-Codecs benutzen z.B. oftmals nur die MMX-Einheit. Böse entäuscht war ich auch beim Cinebench. Der benutzt nämlich gar kein SSE. Wie jämmerlich. Darum ist der P4 auch so langsam. Egal.

Wie sehen eure Erfahrungen mit Software bezüglich SSE/2 aus? Der Perfmon liefert dabei wertvolle Dienste.

MfG

BlackBirdSR

2007-01-08, 16:19:18

Ich kann dir nur sagen, dass anscheinend x87-Aufrufe unter Win x64 angezeigt werden, obwohl hier nur die skalaren SSE2 Instruktionen unterwegs sein sollten. Von denen ist dann auch herzlich wenig zu sehen.

Vielleicht ein Problem im Zusammenhang mit x64.
Mein Fehler ;) x86 Programme nutzen natürlich weiterhin x87 und man sollte Perfmon eben an einen Kern binden um wahre Aussagen zu bekommen.

Die Tatsache, dass skalarer und packed SSE/2 Code nur sehr selten anzutreffen sind, ist leider viel zu oft zu spüren.
Entweder ists es dann nicht so einfach, oder man hat nicht genug Zeit/Erfahrung.
Da muss man schon auf speziell optimierte Versionen von Tools etc zurückgreifen.

Die SSE Version von Lame nutzt z.B auch intensiv SSE(skalar+packed) und die x64 Version weitet das auch noch aus.
Aber wenn man nicht gerade spezielle Builds nutzt sieht es fast immer sehr düster in den Verlaufsdiagrammen für SSE/2 aus

Gast

2007-01-08, 22:22:39

nur so als hinweis (für die die es noch nicht kennen):

http://forums.mozillazine.org/viewforum.php?f=23
http://www.firefox-browser.de/forum/viewtopic.php?t=30873

es gibt für den ff und tb eine recht grosse community die diese anwendungen auf die speziellen instruktionen einzelner cpu's optimiert. :)

generell kann man zumindest unter linux mit den sourcen recht schnell optimierten code compilieren. unter windows dauert es auch nicht recht viel länger, sofern der sourcecode dafür zur verfügung steht und der compiler es unterstützt (ist ja eigentlich nur ein flag zu setzen). firefox, thunderbird oder openoffice sind einige beispiele die man selbst optimieren kann.

meiner meinung nach wird sich an dem umstand, dass es nur wenig software gibt, die auf eine spezielle instruktion einer cpu optimierten code aufbaut, nicht recht viel ändern. man will, dass die anwendung auf allen rechnern läuft. auch auf solchen die kein sse unterstützen. die amd's haben das ja noch nicht allzu lange implementiert.

je mehr instruktionen ich aber unterstütze, desto mehr versionen muss ich veröffentlichen oder ich verzichte auf diese kunden. aber wer tut das schon freiwillig und sorgt zugleich noch für verwirrung bei den kunden.

BlackBirdSR

2007-01-08, 22:41:50

meiner meinung nach wird sich an dem umstand, dass es nur wenig software gibt, die auf eine spezielle instruktion einer cpu optimierten code aufbaut, nicht recht viel ändern. man will, dass die anwendung auf allen rechnern läuft. auch auf solchen die kein sse unterstützen. die amd's haben das ja noch nicht allzu lange implementiert.

Mit WinXP-64 und Vista-64 kommt zumindest hier ein einheitlicher Standard.
Alle x64 CPUs sind in der Lage skalaren fp-dp SSE2 Code als x87-Ersatz auszuführen und sollten x87, MMX und 3dnow links liegen lassen. Dafür kommt int SSE/2 zum Einsatz.

Eine 64-Bit Version eines Programms ist also automatisch einen Schritt weiter, man muss auch bei SIMD SSE/2 dann keine Rücksicht mehr nehmen, was eventuell ein paar mehr Programme für SIMD Code begeistern kann.

Ganon

2007-01-08, 23:00:50

nur so als hinweis (für die die es noch nicht kennen):

Gibt's da auch entsprechende (neue) Benchmarks? Weil so wie ich das noch kenne, bringen diese Builds fast gar nix und sind teilweise sogar kontraproduktiv. Und da die Oberfläche von FF eh interpretiert wird... Und für Thunderbird raff ich es gar nicht. ;)

Am Source wird da afaik gar nix umgestellt. Die nehmen sich nur den Code und hängen beim Compilieren ein -nutz-bitte-sse hinten dran.

Ist genauso wie diese Altivec-Builds für PowerPCs. GCC kann/konnte noch gar nicht wirklich automatisch für Altivec optimieren. Trotzdem gibt/gab es diese Builds.

Gast

2007-01-08, 23:03:37

nur so als hinweis (für die die es noch nicht kennen):

http://forums.mozillazine.org/viewforum.php?f=23
http://www.firefox-browser.de/forum/viewtopic.php?t=30873

... (ist ja eigentlich nur ein flag zu setzen) ...

Das ist das, was viele glauben. Ein SSE/2 Compiler Switch setzen und gut ist es? Nein! Wer SSE/2 wirklich nutzen möchte, muss schon sehr maschinennahe programmieren, da führt kein Weg vorbei. Jedenfalls noch nicht.

Ganon

2007-01-08, 23:09:26

Wer SSE/2 wirklich nutzen möchte, muss schon sehr maschinennahe programmieren, da führt kein Weg vorbei.

Ich kenn mich jetzt mit SSE nicht aus, aber gibt's da kein C-Interface?

Gast

2007-01-09, 09:52:04

When first introduced in 2000, SSE2 was not supported by software development tools. For example, to use SSE2 in a Microsoft Developer Studio project, the programmer had to either manually write inline-assembly or import object-code from an external source (such as Microsoft MASM.) Later the Visual C++ Processor Pack added SSE2 support to Visual C++ and MASM

The Intel C Compiler can automatically generate SSE/SSE2-code without the use of hand-coded assembly, letting programmers focus on algorithmic development instead of assembly-level implementation. Since its introduction, the Intel C Compiler has greatly increased adoption of SSE2 in Windows application development.

Since GCC 3, GCC can automatically generate SSE/SSE2 scalar code when the target supports those instructions. Automatic vectorization for SSE/SSE2 has been added since GCC 4.

Quelle: http://en.wikipedia.org/wiki/SSE2

Es war einmal! ;)

Gast

2007-01-09, 10:41:20

Die Frage ist hier nur, wie gut das funktioniert. Wie gut und welche Routinen können (jetzt gerade bei FF und TB) entsprechend spürbar optimiert werden, nur durch ein neues durchkompilieren?

Afaik ist die Auto-Vectorisierung in GCC 4 noch in den Kinderschuhen und erkennt nur sehr wenig Code als vektorisierbar.

Gast

2007-01-09, 11:30:23

Die Frage stellt sich doch generell. Welcher Code (welche Anwendung) ist dafür geeignet mit den SSE-Instruktionen der CPU schneller zu laufen. Klar kommt nicht die komplette Anwendung dafür in Frage. Es können immer nur Teilbereiche sein.

Inwieweit die Compiler den Code auf SSE hin optimieren steht wieder auf einem anderen Blatt und hängt in erster Linie von der "Nachfrage" einer solchen Optimierung ab und die ist ziemlich gering. Der Intel Compiler, der für kommerzielle Produkte wohl erste Wahl ist, weiss recht gut damit umzugehen. Auch der Programmierer tut gut daran sauber zu programmieren (möglichst nah an der jeweiligen Sprache).

Letztendlich bleibt nur eine Frage übrig. Nämlich ob ein Hersteller wie z. B. Adobe dazu bereit ist mehrere Versionen seiner Produkte zu veröffentlichen oder ob er auf Kunden verzichtet bzw. diese zum Umstieg auf neue Hardware zwingt.

SSE > SSE2 > SSE3 > SSSE3 > SSE4

Welche Version sollte der Hersteller verwenden? Sicher ist SSE2 da die erste Wahl. Wobei aber SS3 noch einmal einen grossen Geschwindigkeitsschub bringen würde.

BTW: Unterstützen die Prozessoren vom Apple eigentlich diese Instruktionen? Im Hinblick darauf, dass man zukünftig evtl. nur noch ein Binary für beide Plattformen veröffentlichen will? Sind ja beides x86-er. Oder ist das schon wieder zu weit weg? :D

Gast

2007-01-09, 13:50:55

robbitop

2007-01-09, 13:55:01

Die Frage stellt sich doch generell. Welcher Code (welche Anwendung) ist dafür geeignet mit den SSE-Instruktionen der CPU schneller zu laufen.

Nur parallelisierbarer Code.
Physikberechnungen, Bildkompression und -skalierung, Video En- und Decoding und irgendwelche Powershop Effekte/Filter fallen mir da ein.
Ich wette aber, dafür wird das auch schon ordentlich genutzt.

Man kann eben sehr vieles nicht parallelisieren, da eine Aufgabe das Ergebnis einer anderen oftmals voraussetzt.

Coda

2007-01-09, 14:38:19

Ich kenn mich jetzt mit SSE nicht aus, aber gibt's da kein C-Interface?

Doch es gibt ASM-Intrinsics in den ganzen neuen Compilern. AFAIK haben die x64-Compiler von Microsoft gar keinen Inline-Assembler mehr.

Viel besser ist das aber auch nicht.

Es war einmal! ;)

Autovektorisierung funktioniert leider immer noch nicht so richtig toll.

Ganon

2007-01-09, 14:49:15

Doch es gibt ASM-Intrinsics in den ganzen neuen Compilern. AFAIK haben die x64-Compiler von Microsoft gar keinen Inline-Assembler mehr.
Viel besser ist das aber auch nicht.

Ich frag nur, weil Altivec ja ein direktes C-Interface mit entsprechenden Funktionen hat. Also es wie stink normales C aussieht.

(jetzt vllt. nicht Fehlerfrei)

vector unsigned int a,b,c;
a = {1,2,3,4};
a = {5,6,7,8};
c = vec_add(a,b);

Wie würde dieses Beispiel in SSE aussehen?

Coda

2007-01-09, 15:51:44

__m128i a = _mm_setr_epi32(1,2,3,4);
__m128i b = _mm_setr_epi32(5,6,7,8);
__m128i c = _mm_add_epi32(a,b);

Ganon

2007-01-09, 17:53:44

Joahr, das geht ja noch.

Gast

2007-01-09, 19:34:39

__m128i a = _mm_setr_epi32(1,2,3,4);
__m128i b = _mm_setr_epi32(5,6,7,8);
__m128i c = _mm_add_epi32(a,b);
Kann man ja problemlos in eine eigene Vektorklasse packen und schon sieht es aus wie normaler Code.

hyperterminal

2007-01-09, 20:26:05

Letztendlich bleibt nur eine Frage übrig. Nämlich ob ein Hersteller wie z. B. Adobe dazu bereit ist mehrere Versionen seiner Produkte zu veröffentlichen oder ob er auf Kunden verzichtet bzw. diese zum Umstieg auf neue Hardware zwingt.
Gerade Adobe ist mit der derzeitigen Version der Videoschnittsoftware Premiere einen radikalen Schritt gegangen, wurden doch SSE2 faehige Prozessoren zwingend vorausgesetzt und das zu einer Zeit, wo Athlon64 Prozessoren noch kaum verbreitet waren und die breite Masse Athlon XPs hatte.

Coda

2007-01-09, 20:27:38

Kann man ja problemlos in eine eigene Vektorklasse packen und schon sieht es aus wie normaler Code.

Hab ich ja nix gegenteiliges behauptet.

Coda

2007-01-09, 20:30:18

Welche Version sollte der Hersteller verwenden? Sicher ist SSE2 da die erste Wahl. Wobei aber SS3 noch einmal einen grossen Geschwindigkeitsschub bringen würde.

SSE3 ist ein Witz. Die paar Instructions reißen bestimmt nix raus.

Novox

2007-01-09, 22:24:06

Zumal die neuen "horizontalen" Befehle (wie z.B. HADDPS bzw. _mm_hadd_ps) schnarchlangsam sind.

Coda

2007-01-09, 22:36:00

Auch auf Conroe?

Novox

2007-01-09, 22:50:07

Prescott: 13 Takte Latenz, 4 Takte Durchsatz
Conroe: 9 Takte Latenz, 3 Takte Durchsatz

Gast

2007-01-09, 22:54:58

Also laut meiner Docu hat HADDPS auf Conroe eine Latenz von 6 und einen Durchsatz von 2.

Android

2007-01-09, 23:01:16

Audioprogramme a la Nuendo machen massiven Gebrauch von diesem Befehlssatz. Hatte diesbezüglich mal einen Auslastungstest (internes Meter) in Cubase macht. Athlon Thunderbird mit 1.4GHz und ein Athlon XP 2400+.
Erst beide ohne SSE-Unterstützung (Athlon XP) getestet: Gleiche Auslastung (+-3 Punkte), obwohl der XP 600MHz mehr hatte. Danach habe ich beim XP SSE aktiviert und siehe da: knapp 30 Punkte weniger auf dem Meter. Mit SSE2 kriegt man ungefähr noch 5 bis 10 Punkte weniger. SSE3 bringt im Audiobereich fast gar nichts.

Mfg
Android

Novox

2007-01-09, 23:11:16

Also laut meiner Docu hat HADDPS auf Conroe eine Latenz von 6 und einen Durchsatz von 2.

Ja, stimmt.

jojo4u

2007-01-12, 03:21:36

diedl

2007-01-12, 04:43:59

Musste leider gerade feststellen das selbst der "moderne" und leistungsfressende Videocodec
x264 auch nur gebrauch von MMX macht. :mad:
Das bringt gerade einmal 10% gegenüber reiner FPU Berechnung.
Zumindest ergab das ein Test von mir in Verbindung mit V-DUB.
CPU war ein C2D.
1000 Bilder PAL
FPU 60 s
MMX 54 s
integer SSE 60 s
SSE 60 s
SSE 2 60 s usw.
Automatiche Erkennung 54 sec funktioniert wenigstens. :cool:

mfg diedl

BlackBirdSR

2007-01-12, 09:05:15

Also mein Merom zeigt mir beim perfmonitor keine SSE-Auslastung an. Funktionsfähig sind nur clock cycles, retired instructions, CPI, IPC. Dann gibt es noch branch prediction und cache misses, aber die sind grau und n/a.

Bei der Anzeige von CPI und IPC kann PerfMonitor die anderen Parameter nicht alle auslesen. Wenn du die beiden Funktionen nicht benutzt, ist auch der Rest erfassbar.

@diedl:
Nicht immer bringt SSE2 oder gar SSE den Nutzen den man erwartet. Daher spart man sich oft Optimierungen.
Es muss auch betrachtet werden, welche Datentypen man überhaupt benötigt.
Wenn man nicht mit 32Bit packed Vektoren arbeiten muss, muss man auch nicht gleich SSE/SSE2 bemühen

Gerade für Audio/Video ist MMX noch immer der Standard. Egal ob nun Winamp, WinDVD oder versch. Decoder.
Mit dem erscheinen der 64Bit Versionen von Vista wird sich das vielleicht ändern. MMX soll verschwinden und durch integer SSE/2 ersetzt werden.

Edit: Mein MPEG-4 Decoder für Mediaplayer, WinDVD etc nutzt MMX anscheinend nur für den Audio-Part, während für das Video zum Großteil Integer und ein wenig SSE/2 verwendet wird.
Testobjekt war ein 1920p Video.

Ein älteres Avi, auch MPEG-4 mit MP3-Ton war wieder MMX+FPU

zu Faul zum einloggen

2007-01-13, 00:52:44

läuft Perf Mon auch mit nem uralt K6? :-)

Gast

2007-01-13, 01:27:07

Gibt's da auch entsprechende (neue) Benchmarks? Weil so wie ich das noch kenne, bringen diese Builds fast gar nix und sind teilweise sogar kontraproduktivAbsolut falsch.

Und für Thunderbird raff ich es gar nicht. ;)Auch einer "Datenbank" tun Optimierungen gut. Merkt man bei 10 Mails nicht. Bei 1000 schon.

Am Source wird da afaik gar nix umgestelltAm Source wird sehr wohl was umgestellt.

Die nehmen sich nur den Code und hängen beim Compilieren ein -nutz-bitte-sse hinten dranDie nehmen sich den VC2005pro_sp1 statt Mozilla's VC6 und schalten alles an was geht. Zusätzlich zu den Optimierungen am Source.

Zugegeben, die wirklich guten. Der Rest bedient sich der GPL oder kompiliert nur das Original neu.

http://www1.plala.or.jp/tete009/en-US/software.html
http://marilab.hp.infoseek.co.jp/buildfx/index_en.html
http://www.vector64.com/ (Sachen von mmoy haben schon paar Mal den Weg in den offiziellen Build gefunden)

Das alles sollte in diesem Thread nur eine Randbemerkung sein :)

BH

Ganon

2007-01-13, 07:48:00

Ja hast du auch Benchmarks? Mit "das ist absolut falsch" überzeugst du hier keinen...

Gast

2007-01-13, 17:00:36

Ich will hier keinen überzeugen. Es ist wie es ist. Jeder kann sich selbst überzeugen. Oder nach Ergebnissen einfach suchen, Gohan. Die meisten Seiten fahren irgendwelche JavaScript Benchmarks. Weil es sich am leichtesten erfassen läßt. Ist aussagend, aber größtenteils eben nur für JavaScript. Der Web besteht aber nicht nur aus JavaScript.

Am besten man installiert Fasterfox, aktiviert die "Ladezeitanzeige", besucht seine Seiten mit 'immer leeren' Cache und testet es für sich selbst.

Ich möchte es bezweifeln, daß diese Abertausende einfach nur Massenhypnose und Autosuggestion erliegen sind.
Für mich getestet hab ich es im Januar 2006. Ich hab mir das an dem Tag auf nem Zettel geschrieben und leider nicht eingetippt. Tut mir leid.

http://forums.mozillazine.org/viewtopic.php?t=494223&sid=d99c1db1585a92cb16a45c9340b70fba

LordDeath

2007-01-13, 21:41:58

firefox third party builds sind so gut wie immer schneller als die offiziellen builds. nur wer einen halbwegs aktuellen rechner besitzt muss sich darum garnicht kümmern: den unterschied kann man nur für spezielle fälle messen aber nicht spüren.

und ältere systeme sollten statt optimierten firefox builds doch eher opera benutzten. bei <256mb ram ist firefox einfach zuviel, opera nicht.

Gast

2007-01-13, 21:46:44

firefox third party builds sind so gut wie immer schneller als die offiziellen builds. nur wer einen halbwegs aktuellen rechner besitzt muss sich darum garnicht kümmern: den unterschied kann man nur für spezielle fälle messen aber nicht spürenKommt wohl auf die Anbindung na. Bei 6mbit/s kann ich das super spüren. Mit v.90 weniger. Sonst würd ich mir das Theater selbstverständlich knicken. Ist klar oder?

Stebs

2007-01-13, 23:06:42

Bei der Anzeige von CPI und IPC kann PerfMonitor die anderen Parameter nicht alle auslesen. Wenn du die beiden Funktionen nicht benutzt, ist auch der Rest erfassbar.Hab hier einen Athlon XP 3200+ (halt nur mit SSE) und im Perfmonitor sehe ich nichts was ich mit SSE-Auslastung in Verbindung bringen würde ( Nur L1, L2, Instruction cache etc.).
Wird die Anzeige auf meinen alten Athlon nicht unterstützt, welchen Messwert betrachtet ihr?

Musste leider gerade feststellen das selbst der "moderne" und leistungsfressende Videocodec
x264 auch nur gebrauch von MMX macht
Zumindest ergab das ein Test von mir in Verbindung mit V-DUB.
Hast du SSE, SSE2 etc. nur in V-DUB aktiviert/deaktiviert?
AFAIK wirkt das nur auf V-DUB selbst (resp. evtl. auf Filter)
Der x264 Codec selbst könnte dabei sehr wohl immer automatisch die vorhandenen Einheiten erkennen und dann immer benutzen -> Dein Test _könnte_ daher fehlerhaft sein.
Z.B. kann man in ffdshow auch SSE etc. ein und ausschalten, doch libavcodec, der eh die meiste Arbeit verrichtet, schaltet immer automatisch alle vorhandenen Optimierungen ein.
Ja hast du auch Benchmarks? Mit "das ist absolut falsch" überzeugst du hier keinen...Zu Firefox und optimierten Versionen: Hab vor einiger Zeit (noch vor 1.0) relativ viel damit getestet.
Eigentlich waren die optimierten Versionen immer schneller, richtig sichtbar/spürbar war es aber nur in speziellen JS-Benchmarks oder komplizierten SVG-Bildern etc. (dort dann aber eben objektiv messbar)
Hab auch mal einen Test gelesen wo dann gegenteiliges behauptet wurde (war der Test nicht sogar von der c't ?) -jedenfalls konnte ich das überhaupt nicht nachvollziehen, gehe persönlich noch immer davon aus, dass der benutzte Build oder gar Messmethode damals fehlerhaft war (sowas kommt durchaus vor).

Ich bin aber zu dem Entschluss gekommen, dass es sich für mich nicht wirklich lohnt diese optimierten Builds zu benutzen, sobald man das mittlerweile großzügig verteilte Flash blockiert (z.B. mit Adblock Plus etc.), hat auch mein alter XP 3200+ fast nichts zu tun beim normalen browsen, ausserdem sind inoffizielle Builds eben immer "wackeliger", da ja auch meistens eigene Patches integriert werden. Hatte damals so manche unerklärliche Bugs.
(Den notwendigen "Nervenkitzel" hole ich mir dafür nun nur noch mit den offiziellen Nightly-Builds ;))

Gast

2007-01-14, 13:23:56

BlackBirdSR

2007-01-14, 13:42:18

Kann jemand erklären, warum die normale FP87 Befehle auf einem Pentium-M schnarch langsam sind und mit SSE/2 ein Pentium-M 'normal' schnell ist. Auf meinem Pentium 4 @ 2.4 Ghz gibt es keinen Unterschied zwischen FP87 und SSE/2, wenn nicht von Hand speziell optimiert. Wie gesagt, auf einem Pentuim-M verhält es sich anders. SSE/2 ist da in etwa doppelt so schnell.

Ich denke da musst du schnell posten, was du genau berechnen lässt.
Normalerweise müsste der P4 viel mehr durch SSE/2 gewinnen, da die FPU noch weniger Leistung bringt als beim P-M.

Die FPU des P-M dagegen ist fast identisch zum Pentium3, und daher vielleicht etwas langsamer. SSE/2 ist allerdings auch im P-M nicht besonders performant. Daher müsste gerade bei wenig Optimierung die FPU des P-M eigentlich gute dienste leisten, immerhin sind die P6 Optimierungen inzwischen überall zu finden.

Wie gesagt: Wenn du Beispiele postest, können wir mit Latenzen/Throughput und Bottlenecks kontern und eventuell eine Lösung finden ;)

BlackBirdSR

2007-01-14, 13:44:23

Hab hier einen Athlon XP 3200+ (halt nur mit SSE) und im Perfmonitor sehe ich nichts was ich mit SSE-Auslastung in Verbindung bringen würde ( Nur L1, L2, Instruction cache etc.).
Wird die Anzeige auf meinen alten Athlon nicht unterstützt, welchen Messwert betrachtet ihr?

Du klickst schon mit linker Maustaste auf die 4 Fenster und erhältst dann das Auswahlmenü für die versch. Counter?

Wenn ja, und trotzdem sind keine Infos für SSE etc zu finden, dann unterstützt der K7 die spezifischen Counter wohl nicht und sie können nicht von Perfmonitor ausgelesen werden :(

Beim K8 habe ich z.B MMX/3dnow, x87, scalar SSE/2, packed SSE/2

Gast

2007-01-14, 15:17:49

Wie gesagt: Wenn du Beispiele postest, können wir mit Latenzen/Throughput und Bottlenecks kontern und eventuell eine Lösung finden ;)

Danke BlackBird. Es ging dabei um Gammaberechnungen und Tone-Mapping-Algorithmen. Es ist auch nur eine Festellung, die mich nicht weiter stört, aber doch wundert. Compiliert habe ich den Code mit MINGW. Das gleiche Binary lief mit FP87 dabei auf dem Laptop mit Pentium-M @ 1.7Ghz ganz erheblich langsamer als mit SSE/2. Der Pentium 4 läuft mit SSE/2 übrigens auch einen Hauch schneller. Der Unterschied auf dem P4 mit FP87 und SSE/2 betrug aber nur 1 - 2 % nach mehrmaligem messen. Beim Pentium M betrug der Unterschied ca. 80 - 90 % nach mehrmaligem messen. Wie gesagt, habe auf beiden Platformen immer das gleiche Binary verwendet. Ich kann mir das nicht erklären.

*Hüstel*, die Software, die ich entwickelt habe, findet sich hier:
http://www.dslr-forum.de/showthread.php?t=61750
Beim Starten kann man ihr einen Schalter mitgeben (-nosse), der SSE/2 ausschaltet. Die Anwendung macht von SSE eher weniger Gebrauch. Dabei sind aber zwei Tone-Mapping Plug-Ins, die starken Gebrauch davon machen. Die Tone-Mapper verwenden übrigens auch massiv Multi-Core-CPUs.

BlackBirdSR

2007-01-14, 15:22:38

@Gast: Danke
ich sehs mir Morgen mal an ok?

Übrigens:
Laut PerfMon macht Rainbow Six: Vegas über 80% der anfallenden Gleitkommarechnungen über Skalar und SIMD SSE/2.
Die x87 Befehle sind selten anzutreffen.

Ingesamt sind Gleitkommabefehle aber nur ca zu einem 1/10 vorzutreffen. Nur so als anhaltspunkt.

BlackBirdSR

2007-01-14, 15:33:37

Danke BlackBird. Es ging dabei um Gammaberechnungen und Tone-Mapping-Algorithmen. Es ist auch nur eine Festellung, die mich nicht weiter stört, aber doch wundert. Compiliert habe ich den Code mit MINGW. Das gleiche Binary lief mit FP87 dabei auf dem Laptop mit Pentium-M @ 1.7Ghz ganz erheblich langsamer als mit SSE/2. Der Pentium 4 läuft mit SSE/2 übrigens auch einen Hauch schneller. Der Unterschied auf dem P4 mit FP87 und SSE/2 betrug aber nur 1 - 2 % nach mehrmaligem messen. Beim Pentium M betrug der Unterschied ca. 80 - 90 % nach mehrmaligem messen. Wie gesagt, habe auf beiden Platformen immer das gleiche Binary verwendet. Ich kann mir das nicht erklären.

*Hüstel*, die Software, die ich entwickelt habe, findet sich hier:
http://www.dslr-forum.de/showthread.php?t=61750
Beim Starten kann man ihr einen Schalter mitgeben (-nosse), der SSE/2 ausschaltet. Die Anwendung macht von SSE eher weniger Gebrauch. Dabei sind aber zwei Tone-Mapping Plug-Ins, die starken Gebrauch davon machen. Die Tone-Mapper verwenden übrigens auch massiv Multi-Core-CPUs.

Wie sieht der Vergleich P4 PM aus?
Läuft der Pentium-M generell sehr langsam mit x87, oder gewinnt er einfach nur extrem viel durch SSE2 während der Pentium4 generell schlechte Leistung zeigt und durch SSE2 nichts mehr gewinnen kann?

Vielleicht liegts ja an dem Bug mit SSE-missalignment den MINGW angeblich hat.

Gast

2007-01-14, 17:16:54

Wie sieht der Vergleich P4 PM aus?
Läuft der Pentium-M generell sehr langsam mit x87, oder gewinnt er einfach nur extrem viel durch SSE2 während der Pentium4 generell schlechte Leistung zeigt und durch SSE2 nichts mehr gewinnen kann?

Vielleicht liegts ja an dem Bug mit SSE-missalignment den MINGW angeblich hat.

Also der P-M@1.7 Ghz ist schneller als der P4@2.4 Ghz. Allerdings liegt der Unterschied nur im einstelligen Prozentbereich. Mit SSE/2 ist der P-M auch schneller als der P4.

Der MINGW hat definitiv diesen Bug. Das Missalignment tritt aber nur bei Stack-Variablen auf. Das Programm wurde so gemacht, dass dieser Bug berücksichtigt wird. Ansonsten würde das Programm gnadenlos abstürzen, keinesfalls aber langsamer werden. Ein movups Befehl sollte ja zudem auf beiden Plattformen gleich langsam laufen.

Übrigens gibt es einen Trick diesen Bug zu umgehen ;-)

Stebs

2007-01-14, 18:11:39

Du klickst schon mit linker Maustaste auf die 4 Fenster und erhältst dann das Auswahlmenü für die versch. Counter?
Jepp

...dann unterstützt der K7 die spezifischen Counter wohl nicht und sie können nicht von Perfmonitor ausgelesen werden :(
Beim K8 habe ich z.B MMX/3dnow, x87, scalar SSE/2, packed SSE/2Scheint leider so zu sein dass das mit dem K7 nicht klappt.

Gast

2007-01-14, 19:39:04

Hallo,
Meines Wissens stand in mehreren älteren c't Artikeln etwas von wegen Perfomance-Countern in P4, PM und, ganz interessant, Itanium.
In Bezug auf K7 habe ich sowas nie gelesen, auch an anderen Stellen nicht, was darauf schließen lässt, dass die entweder nicht oder nur sehr spärlich vorhanden sind.
Eine andere Möglichkeit wäre eine sparsame Dokumentierung von den Teilen, da ich mir nicht vorstellen kann, dass AMD sowas garnicht verbaut...für interne Performance-Tests ist das sicherlich auch da ein gern genutztes Mittel.
MfG
B1u3

BlackBirdSR

2007-01-14, 22:51:08

Also der P-M@1.7 Ghz ist schneller als der P4@2.4 Ghz. Allerdings liegt der Unterschied nur im einstelligen Prozentbereich. Mit SSE/2 ist der P-M auch schneller als der P4.

Der MINGW hat definitiv diesen Bug. Das Missalignment tritt aber nur bei Stack-Variablen auf. Das Programm wurde so gemacht, dass dieser Bug berücksichtigt wird. Ansonsten würde das Programm gnadenlos abstürzen, keinesfalls aber langsamer werden. Ein movups Befehl sollte ja zudem auf beiden Plattformen gleich langsam laufen.

Übrigens gibt es einen Trick diesen Bug zu umgehen ;-)

Wäre es möglich, dass du auf einen Fall getoßen bist, wo der Pentium-M einfach mehr Nutzen aus SSE/2 ziehen kann, während der Pentium4 aufgrund eines Problems das nicht kann?

Immerhin ist der P-M ja etwas schneller als der Pentium4. Und dieser ist ja auch nicht so langsam bei Imaging. Also funktioniert beim P-M vielleicht alles korrekt, beim P4 aber nicht?!?

Ich kann dir anbieten die Sache einmal mit einem K8 gegen zu testen, wenn du mir die Testbilder und das Benchscript/Vorgang zukommen lässt. Vielleicht kommen wir auf eine Lösung :)

Gast

2007-01-15, 11:45:35

Medieval 2 nutzt auch SSE2, das erste Demo setzte es sogar vorraus.

Gast

2007-01-15, 19:06:14

Ich kann dir anbieten die Sache einmal mit einem K8 gegen zu testen, wenn du mir die Testbilder und das Benchscript/Vorgang zukommen lässt. Vielleicht kommen wir auf eine Lösung :)

Vielen Dank für das Angebot BlackBird. Ich werde allerdings sobald nicht dazu kommen dir das zuzuschicken. Erstens müßte ich den Fall wieder aufrollen und zweitens und wie immer wichtiges Problem ist, dass ich kaum Zeit habe ;) Dennoch kann es sein, dass ich wieder auf dich zukommen werde. Danke nochmal.