- Online Community Forums » Allegro Development » Re-Enabling ASM Drawing

This thread is locked; no one can reply to it. rss feed Print
Re-Enabling ASM Drawing
Member #16,714
July 2017

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
Second in Command
February 2005

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?

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Member #358
May 2000

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

"Either help out or stop whining" - Evert

Chris Katko
Member #1,881
January 2002

That's hilarious.

Modern compilers rule.

“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Member #7,827
October 2006

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Peter Hull
Member #1,136
March 2001

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
Member #2,207
April 2002

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.

Member #16,714
July 2017

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.

Go to: