------- Comment #11 from michaelni at gmx dot at 2006-02-11 13:54 ------- (In reply to comment #9) > Re. comment #8: > "exponential decaying performance which it has so accurately followed since > 2.95" > > Can you back this up with numbers, or are you just trolling? If the latter, > please don't do that, you are insulting the work of a dedicated few. Maybe > you > should help out instead of trolling, if you think you're so good. If you > continue to make this kind of unhelpful comments, I will ask to have you > blocked from our bugzilla.
the benchmark was unhelpfull? anyway, compiling dsputil.c from libavcodec takes gcc 2.95 0m26.530s gcc 3.4 0m46.839s gcc 4.0 1m 1.515s (time /usr/bin/gcc-4.0 -O3 -g -DHAVE_AV_CONFIG_H -I.. -I'/home/michael/ffmpeg-write2/ffmpeg'/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o dsputil.o dsputil.c) and runtime performance, just try the recommanded way of writing asm/mmx code for gcc 2.95 vs gcc 3/4.*, handwritten asm code is quite a bit faster then what gcc creates from these intrinsics sometimes sure saying gcc gets exponentially slower in general isnt true but in some specific and common cases there is a big speedloss ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
