Re-Enabling ASM Drawing
ZoriaRPG

ASM drawing (pixel conversion, and uch) was disabled in 4.4.2 or 4.4.3.

Can any of you elaborate on the reason for this, as the end result is that all drawing on windows has a 50% performance loss.

Is there a driving reason not to reimplement this option?

Arthur Kalliokoski

Just a wild guess, but I'd say they didn't want to have both 64 bit and 32 bit versions. Can't you make your own asm files for those few things? Or were they inlines before?

Elias

The reason was that they were quite a bit slower than the C versions, from what I remember.

Chris Katko

That's hilarious.

Modern compilers rule.

SiegeLord

This is confusing, how can they be faster, yet be 50% slower as per OP? Something doesn't add up. This stuff should be platform independent, so we should be able to check out 4.2 sources, build them with and without hand assembly and verify this.

Peter Hull

I've had a bit of a poke through the [AD] archives ... the key dates seem to be end of 2007/early 2008, but I didn't find anything really clear on how the decision was made. Key people were Evert, Peter Wang and Milan Mimica. I don't know if they are still active?

I don't remember the C versions being faster, just that ASM code was not that much faster to justify the complexity of maintaining it. (it was a big mass of macros to generate all the possible variants.)

It was only ever written for i386, and only using GAS syntax, so it was no good for ARM, PPC, AMD64 or anyone using MSVC.

Also I do think that, if it did reduce performance by 50%, people would have noticed and complained at the time.

So, obviously there is a problem somewhere but I am not convinced it will be solved by re-instating the ASM code.

Oscar Giner

I guess it's old ASM code that uses only "core" x86 instructions? Any modern compiler will make use of SIMD instructions, making the generated code much faster. That's just my guess.

ZoriaRPG

Has anyone done a performance profile for allegro 4.2 along the lines that you discussed?

What we have noticed, on Windows, is a 50% performance hit in colour conversion and drawing, from ag4.2 to ag 4.4, and the major, notable change (and the change to which we have attributed the loss of performance) is the removal of the ASM option. Is there some other change that is relevant to this kind of performance hit?

I know that there were changes in the blitting and bitmap inlines.

It is certainly possible that things compile differently through DX and the Windows C compilers in a way that is less optimal than the hand ASM, but the hand ASM may also be a potential can of worms for bugs on newer Windows versions.

Thread #617008. Printed from Allegro.cc