| Re: [AD] Color convertors |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Eric Botcazou wrote:
[about the MMX code:]
I can't believe it (2) ;-) You rewrote the MMX code from scratch ! Why ?
No I haven't, I just shifted things around. This breaks parining on the
pentiums (and K6) though :/ I get ~5% more speed on my P3 though (Thanks to
the hardware instruction reordering). I got rid of the nops, which force the
CPU to stall for one cycle (bad), and used shorter opcodes where needed (the
movl and xorl thing, and the register swap).
[snip - results]
Afaics there is no significant performance improvement for these routines on
my machine, there is rather a little loss.
It's the pairing thing again. I'll fix it up tomorrow after school.
Hopefully, WIP 38 won't be released by then :)
Given that we finally rejected a
patch for the blit() routine that showed at least some improvements on at
least some machines, I think we should have properly evaluated these
routines before scrapping a stable and relatively fast code.
Agreed. However, removing the new code will break BeOS and possibly QNX
(depending on if Angelo changed the code there or not). Did you patch the
32->24 code? If not, I'll do it tonight.
IMO the only routines that demonstrate a clear performance improvement
are the two new MMX routines (24->32 and 32->24). Here are the results for
the 32->24 routine (after the needed fix):
Yay!
In case you're wondering, it's done by reducing the amount of memory moves.
The non-MMX code had 3 reads (for 24->32 bit) or 3 writes (32->24). I've
reduced it to 1 read/write per 2 pixels (on average). This meant adding more
code, so the loops take a few cycles more, but in the end it was worth it.
The improvement will be more substantial on systems with a high cpu
clock/memory clock ratio (like the Pentium 4 :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/