Greetings I tried to compile lame 3.91 with gcc-3.0.1 and I tried to allow as much optimizations as possible while having as small result in 'make test' as possible
I have found that it doesn;t matter if I use --enable-expopt=full or not, the result is varying only because of two gcc options 'make test' result 18 is the best I am able to get, even with all optimizations off (is it possible to get smaller number?) with --enable-expopts=full I got result 413 with full expopt, but with -fno-caller-saves added to OPTIMIZE variable in configure script I got result 21 after deleting -ffast-math from the same place I got the result 18 - same as without any optimizations ----- I understand that -ffast-math may change something, but this -fno-caller-saves, may it be the compiler bug? anyway, all I wanted is, that maybe you could allow all optimizations by default and only --ffast-math and -fcaller-saves to expopt=full (because it looks they are only two which can decrease quality of output) -fcaller-saves is enabled by default with -O2 and higher -------- and one more thing, I thought that when I add -mcpu=athlon and -march=athlon to gcc-3.0.1 parameters, compiler will use 3dnow and 3dnowext when possible (vector operations or something, in fact I don't know anything about mp3 compression but I thought it could help). I have Duron 700 Result was very bad, with 'pentiumpro' I have playtime/cputime 2.5 (or near by), with 'athlon' I have playtime/cputime 0.6 (or near by). Can be compiler bug or it simply doesn't make sense to use 3dnow for mp3 encoding? ------- I don't send all this stuff to gcc creators because I don't know if this is really their problem and becuase I don't have last released version of gcc (3.0.3 is out, I think). So if you would take a look at it, it might help somehow all for now bye _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
