packete optimieren

Christian Ordig chr.ordig at gmx.net
Wed Dec 12 22:28:03 CET 2001


On Wed, Dec 12, 2001 at 09:16:18PM +0100, Jan-Benedict Glaw wrote:
> Gelten die Zahlen auch heute noch, mit gcc-3.0 und doppeltem
> Kompilieren?
soweit ich mich erinner, sind das Vergleichswerte mit 3.0. Ich kann zur
Not den iX Artikel mal raussuchen, wenn es Dich interessiert. Selber 
konnte ich das nicht pruefen, da ich gcc 3.0x nicht selber installiert
habe, da der das gleiche Problem mit der Binaerkompatibilitaet hat.

> Naja, "stimmen" ist da nicht so ganz richtig. Die Major-Versionsnummer
> sollte passen, aber zwischen zwei solchen vergeht *viel* Zeit...
ja stimmt schon.
 
> Ich brauche ein Tool (und zwar möglichst *ein* Tool), mit dem ich
> meine Arbeit verrichten kann. ...und gerade ich baue viel auf den
> "exotischen" Kisten, sowohl native auf den Rechnern, als auch mit
> Cross-Compilern. ...und wenn ich dann 2 Compiler 'rumfliegen habe,
> einen von/für Intel, einen für alles andere, dann finde ich das
> scheiße. ...oder in kurz: ich will mit einem compiler alles machen
> können.
ok. nehmen wir den Sonderfall Cross-Compiler mal raus ... dann hast Du pro
Plattform _einen_ Compiler. Und solange Du Dich an Standards haelst, geht
das auch gut.


> Naja... 2faches Bauen mit dem gcc-3.0... Ich würde gerne mal sehen,
> wie das im Ergebnis gegen ein Intel-gebautes Binary abschneidet...
aehm ... was genau meinst Du mit "2faches Bauen"? Profiling-Optimierung,
oder Global-Optimierung (ueber objekt-file Grenzen hinweg) ?

Ich hab hier leider keinen gcc 3.0x aber den icc. Wir koennten ja mal 
einige "representative" Applikationen nehmen und die fuer eine
bestimmte Hardware optimiert compilieren, und mal schaun - natuerlich
irgendwas, wo man auch tatsaechlich "messen" kann ... wuerde mich
selber auch mal interessieren. Fakt dabei ist auf _jeden_ Fall, dass 
der Intel Compiler wesentlich weniger Zeit zur Code-generierung
benoetigen wird ,-)

-- 
Christian Ordig
Germany



More information about the Linux mailing list