Am Montag, 5. Januar 2004 05:25 schrieb David Haller:
Jep. i586 ist Pentium mit MMX (IIRC), und damit ist der Gewinn
Nö, i586 ist bereits der stinknormale Pentium ohne MMX, ebenso wie die AMD K6 CPUs, die auch kein MMX verwenden. Der Pentium mit MMX ist bereits ein i686er. Wobei Dir aber ein -march=i686 und nicht mal ein -march=pentium4 mmx von allein generiert. Das ist auch der Grund, warum es die meisten Packman Multimedia-Pakete als i586 und i686 Version gibt (wobei zumindestens ich die i686er auch mit -mmmx Option backe, von meinen xine CVS Builds mal abgesehen, die brauchen nen PIII als minimum ;-) ).
besonders hoch. SSE[2] lohnt sich eigentlich nur bei Multimedia Kram wie xine/mplayer bzw. den dort verwendeten codecs, und da sind (ausser den ffmpeg codecs) die meisten ja sowieso leider nur als windows dlls verfuegbar...
Naja, die ffmpeg die ja für beide Player die meisten Codecs zur Verfügung stellt, läst die Win32Codecs immer überflüssiger werden. Die üblichen Codecs von MPEG 1-4 (inclusive DivX und XVid) über Sorenson (SVQ1 und 3) über WMA/WMV (zumindestens bis 7) ist alles schon drin, RealMedia binden sowohl xine, als auch MPlayer per linux libs vom RealPlayer ein. Seit ich den Endian-Bug aus dem OGM-Demuxer zwischen libxine 1-rc3 und 1-rc3a gefunden hab, fehlt mir auf meinem PowerBook (natürlich ohne Win-DLLs) eigentlich nichts mehr, was ich auf der Intel-Kiste abspielen könnte. Neuere WMA/WMV Dateien werden uns künftig wohl eh primär DRM gesichert vorgegeben und das funktioniert weder mit, noch ohne Win32Codecs. Ach ja, die ffmpeg lib hat die kritischen Teile auch Grosteils in optimiertem Assembler mit Multimedie-Extension-Support zur Verfügung, da hilft ein optimierender gcc auch so gut wie nichts.
Ausserdem lohnt sich offenbar C++ Kram (QT, KDE v.a.) mit nem g++ >= 3.2 zu kompilieren, da hab ich aber mangels passendem gcc/g++ keine Erfahrungen mit.
Auf jeden Fall. gerade bei C++ lohnt sich aber noch mehr der Einsatz einer glibc >= 2.3. Ansonsten kann je nach Plattform auch ein gcc 2.95.x auf 3.2.x schon Wunder wirken. Wieder mein PowerBook heranziehend, lag die Steigerung der Framerate bei xine danach etwa 20% höher, bei 266 MHz sind das Welten. Wieviel der neue gcc 3.3.1, den ich jetzt fahre und die recompilierte SuSE 8.2 brachten und wie viel auf kosten der in den letzten Monaten durchgeführten Optimierung in xine selbst zurückzuführen sind, kann ich jetzt nicht in Zahlen sagen, aber bei ca. 500x300 DivX5 Files bin ich die letzten Ruckler los und die CPU hat in der Regel noch ein paar Prozent Reserver für kritische Stellen.
IMO nein. Der Unterschied i686 / athlon ist bei den Funktionen, die von der glibc verwendet werden AFAIK praktisch irrelevant, denn die glibc verwendet kein SSE[2] bzw. 3dnow etc.
Wenn Du dem gcc ein '-mmmx -msse -mfpmath=sse' oder '-m3dnow' mitgibst, wird sie das aber ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de