Re: [AD] ALLEGRO_USE_C vs ALLEGRO_NO_ASM

[Siarhei Siamashka <siarhei.siamashka@xxxxxxxxxx>]

Kalle Last wrote:

>      > It would break ABI compatibility.
>      > There are some functions that benefit from ASM code. I don't know
>      > exactly which one (some memory bitmaps rotation/stretching I
>     think), I
>      > just noticed it while profiling my game. This things really need
>     to be
>      > benchmarked.
>      >
>
>     Hm, it does break ABI? Oh well, it was badly designed then I guess.. a
>     good way would have been to hide the asm/non-asm in the driver. But
>     yeah, I faintly can remember something like this coming up before.
>
>     About benchmarking, I think there was a lot of benchmarking on
>     allegro.cc about a year ago, and non-asm clearly won.
>
>
> I don't know if you can call running allegro test program on two 
> computers under Linux "a lot of benchmarking" but that is all I can 
> remember about that. Those benchmark stats are here:
>
> P4 Northwood
> http://www.allegro.cc/forums/thread/477775#target
> P1 MMX
> http://www.allegro.cc/forums/thread/478181#target 
> <http://www.allegro.cc/forums/thread/478181#target>
>
> Unfortunately there are no benches of some functions like rotating and 
> some others.
> If I could find some time I could probably repeat those tests on a64 
> win/lin, P3 lin, athlon xp win/lin and P4 Prescott lin.

In order to get reliable results, a standard, easy to use and
non-interactive benchmarking utility needs to be developed and included
into allegro. Preferably it should cover all performance critical
allegro functions and produce a human readable table with the results.

As for ASM vs. C, assembly optimized version of clear_to_color() is
faster than its C counterpart, on the other hand C-implementation of RLE
sprites is faster than ASM.