Vadim Plessky <[EMAIL PROTECTED]> writes:
[...]
> | Two problems:
> |
> | 1. gcc does not optimize really well for this class of processors (IMHO)
>
> looks like we need gcc 3.0 for it, in any case (if you don't want to struggle
> with buggy gcc 2.96, its _experimental_ branch)
It'll be the same.
> | 2. you'll not get what you want because processor-specific opts can only
> | get 1-5% of speed, e.g. you'll never notice the difference
>
> Do you mean gcc doesn't use 3DNow! instruction set?
It does -- but do you really know the purpose of these instructions? (and
the fact that the penalty is high while using the coprocessor at the same
moment).
It's highly unprobable that any app could be "vastly" optimized using
3dnow. Same story with MMX!
It only works noticeably for very specific things, and the only one I am
aware of is MPEG uncompression. Fortunately kde supports MMX for its mpeg
routines for example.
So, you can recompile the app you'll like to see quicker for your specific
arch, but we'll not do that.
> I start to wonder if MMX is supported...
> MpegLib and QT should benefit from either 3DNow or MMX. Compression utilities
> like ARK, probably, too. Of course, it depends how they are written...
> KDE2, as it heavily uses QT, will benefit from such optimization as well.
>
> Finally Mesa3D will benefit, for sure. I have seen mail from somebody on one
> of the lists claiming he got +5FPS for software-only Mesa after recompiling.
Mesa, if used in software, will never be quick enough to be useable, due
to its general-purpose design. At least things like "gears" will have
framerate, but chromium or quake3, never.
Used with hardware acceleration, 3dnow/mmx is nearly nothing because it
competes with the hw accel which is ofcourse much quicker.
--
Guillaume Cottenceau -- Distribution Developer for MandrakeSoft
http://us.mandrakesoft.com/~gc/
