Am Mittwoch, 7. Januar 2004 00:53 schrieb Rüdiger Meier:
Am Montag, 5. Januar 2004 23:18 schrieb Manfred Tremmel:
Wobei gerade lame sehr viele Routinen auch als Assembler hinterlegt
Aber bessere Architektur heisst doch, daß optimierte Maschienenbefehle zur Verfügung stehen. Kann man dem Assembler auch Optimierungen mitgeben oder müsste man diese Routinen dann komplett anders schreiben?
In Assembler schreibst Du diese Maschienenbefehle (wenn auch in Menschen lesbarer Version, nicht so wie ich früher mal am C128 mit nem Maschienensprachmonitor, in den ich die Befehle hex eingetippt habe). An einem Assembler kannst prinzipbedingt nichts optimieren, wenn Du MMX haben willst, schreibst Du die MMX Befehle in den Assembler Code, spielst mit den MMX-Registern, genauso bei SSE, SSE2, 3D-Now, .... Wenn Du alles in einem Programm haben willst, musst Du die fähigkeiten der CPU abfragen und entsprechende unterroutinen anspringen. Assembler ist auch immer Prozessorspezifisch, ein Assemblerprogram läuft immer nur auf einer Prozessorplattform (und kommt mir jetzt bitte nicht mit Emulatoren), das ist auch der Grund, weshalb ich das ganze aufgegeben habe, nachdem ich mich mit den Befehlen für C128, Amiga (MC68k) und OS/390 gequält hatte.
Ich glaube Du hattest mir das mal igendwann hier (oder per PM) erklärt was nasm ist. Das war als ich lame kompilieren wollte und noch nichts von pin wusste;)
Der nasm ist ein Assembler, also sowas wie ein Compiler für Maschinensprache, der eben Assemblerbefehle in Maschinensprachenbefehle übersetzt und dabei eben Multimedia-Erweiterungen wie MMX und SSE beherrscht.
kriegst Du zwar (trotz aller optimierungen) ne langsamere Version, die ist aber komplett per gcc compiliert und sollte mehr Aussagen zu den optimierungen.
Ich glaube schon, daß die gcc-Otimierungen Sinn machen. Aber ich
Das bezweifle ich ja gar nicht, allerdings gilt auch heute noch, dass der beste Compiler gegenüber sehr gut programmiertem Assemblercode abstinkt. Was nicht heissen soll, dass ein durchschnittlicher Assemblerprogrammierer mit nem guten Compiler mithält... Lame enthält viele gut optimierte Assembler-Routinen, ist nasm nicht installiert, werden diese nicht verwendet und stattdessen C-Code für diese Funktionen verwendet. Dieser ist trotz allem gcc getrickse langsamer als der Assemblercode.
denke eben, daß es für viele Pakete (vielleicht für die meisten) keinen Sinn macht diese selbst und optimiert zu kompilieren - entweder weil in vielen Fällen die zusätzlichen cflags keinen Gewinn bringen (siehe lame) oder weil oft auch egal ist wie schnell ein Programm läuft (z.B. ps).
Naja, prinzipiell ist ne effiziente Nutzung nie verkehrt, auch wenn Rechenpower vorhanden ist, spart es vielleicht ein bisserl Akkuzeit am Notebook. Aber letztendlich ist immer noch gut programmierte Software wichtig. Eine perfekt implementierter BubleSort in Assembler wird gegen ne Java Quicksort Routine immer mächtig abstinken.
In diesen Fällen kann man also getrost fertige binarys installieren. Alles andere wäre Zeitverschwendung (auch wenns nur Rechenzeit der CPU ist!).
Jo.
Der Rechner, den ich normalerweise benutze ist mir eigentlich schnell genug. Dinge wie lame, transcode & co. können natürlich nie schnell genug sein. Deshalb habe ich testweise selbst kompiliert, nachgemessen und bin zu dem Schluss gekommen, daß ich die nächsten Versionen, doch wieder als i686-RPMs von Packman holen werde. Da weiss ich, daß die jemand gebaut hat, der mehr davon versteht als ich. Und wenn doch mal eins kaputt ist, stehts am nächsten Tag in der SuSE-Liste und ist wahrscheinlich schon gefixt noch bevor ich den Fehler selbst bemerkt habe! Besten Dank an dieser Stelle.
In der Regel wird sich das nicht negativ auswirken, wir Packager wissen ja meistens auch, was wir tun und gerade bei kritischer Software im Multimedia-Bereich sind die Entwickler meistens schon recht gut bei den gcc Optionen, die im Makefile/configure-Script vorgegeben sind. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de