RGB as a Macro

[Franky]

Code updated for 5.20+

Hi people, this is an small and easy one

PB doesn´t say anything against if you create a macro with the same name as a PBfunction, so it ´s possible to replace some functions with macros.
First Example: RGB (here RGB2, because else both lines had been replaced)

Code: Select all

Macro RGB2(mpr,mpg,mpb)
  mpr+mpg<<8+mpb<<16
EndMacro   

k=GetTickCount_()
For a=1 To 100000
  For b=1 To 20000
    farbe=RGB(255,0,255)
  Next
Next

p=GetTickCount_()
For a=1 To 100000
  For b=1 To 20000
    farbe=RGB2(255,0,255)
  Next
Next
l=GetTickCount_()
MessageRequester("Ergebnis:","Ohne Macro: "+Str(p-k)+Chr(13)+"Mit Macro: "+Str(l-p))

As you can see, it´s 3 times as fast as the function, because RGB is only a small function, so that CALL is a big thing in compare.

An other good thing is, that by using the Macro PB finds out, that the value is constant:
Procedure:

; farbe.l=RGB(255,0,255)
PUSH dword 255
PUSH dword 0
MOV eax,255
CALL PB_RGB
MOV dword [v_farbe],eax

Macro:

; farbe.l=RGB2(255,0,255)
MOV dword [v_farbe],16711935

[va!n]

this means, macros will be gernall a lot faster as procedures but on the other site when using a procedure, this routine is only one time on your exe and when using macros the routine will be insert each section of our exe where you call it, right? (macro = filesize will be bigger when using it often)

thanks for the tip. still wonder why does PB does not optimize this internally for speed reasons ^^ (also the loop stuff = ASM)

[horst]

Code: Select all

Macro RGB2(mpr,mpg,mpb)
    mpr+mpg<<8+mpb<<16
EndMacro 

I suggest:

Code: Select all

Macro RGBvalue(red,green,blue)
    ((blue<<8+green)<<8)+red
EndMacro  

If the parameters are not constants, this produces six assembler instructions (instead of eight).
BTW: rgb(r,g,b) produces 5 assembler instructions including a call.
edited

[helpy]

this means, macros will be gernall a lot faster as procedures

NO! I think that is not right!

The PB functions are optimized code!!!! It is not possible to write PB code that is as optimized as the PB functions. you would have to use assembler in this case ... but then you can program in pure assembler too

cu, helpy

[ts-soft]

this means, macros will be gernall a lot faster as procedures

NO! I think that is not right!

The PB functions are optimized code!!!! It is not possible to write PB code that is as optimized as the PB functions. you would have to use assembler in this case ... but then you can program in pure assembler too

cu, helpy

Please test it

Code: Select all

time1 = ElapsedMilliseconds()

For R = 0 To 255
  For G = 0 To 255
    For B = 0 To 255
      a = RGB(R, G, B)
    Next
  Next
Next
time2 = ElapsedMilliseconds() - time1


Macro RGB2(red,green,blue)
    ((blue<<8+green)<<8)+red
EndMacro 

time3 = ElapsedMilliseconds()

For R = 0 To 255
  For G = 0 To 255
    For B = 0 To 255
      a = RGB2(R, G, B)
    Next
  Next
Next
time4 = ElapsedMilliseconds() - time3

MessageRequester("Test", "PB-Function: " + Str(time2) + Chr(10) + "Macro-Function: " + Str(time4))

[netmaestro]

I did the speed test posted above and this one too. I find the macro version to be approx. 10% faster than the native command, but I'm not getting results anywhere close to the claim above that it's 3 times faster. Nowhere near that, but yes, a bit quicker here.

[MikeB]

I get a 65% increase once I turn the debugger off, if you don't turn it off the increase is very small as the debugger slows everything down so much.

[Dare2]

As to why the above RGB macro outperforms the purebasic function, would it be because the function has to make a call, whereas the macro is doing effectively the same thing inline (no call).

But that is trivial.

PB doesn´t say anything against if you create a macro with the same name as a PBfunction, so it ´s possible to replace some functions with macros.

IMHO, that is the real information - and an eye-opener for me, I hadn't realised this.

This can be magic in the right circumstances. And dangerous in the wrong ones! (* Reviews own macros to make sure there isn't a PureBasic keyword hidden in there somewhere* )

Code: Select all

Macro MessageRequester(msg)
  Debug msg
EndMacro

MessageRequester("Hijacked!")

[inc.]

Imho long.l = rgb(r,g,b) produces a rgb24 alignment in the long variable?

So its stored as

$b.$g.$r.$00 ? as that is also rgb32 (BRGA)

What about parsing these? I ve read in here about the bit operand approach and the PB commands but isnt there a hughe diff. when trying to get r g b values out of rgb24 an rgb32?

[MikeB]

After my last post on this topic, I wondered if compiling the code to a ".exe" file would make any difference to "compile run" with the debugger off. It does, now I get an improvement 1.4 - 1.55 times which is not as good as before

[dagcrack]

I've been converting my RGB into hex in that way since years... And ended up with lots of spaguetti code in my filtering routines just to avoid PB's proc


Yes with a macro you'll have bigger PEs but obviously you'll gain speed on some/most cases.

I don't see why you look at macros like if they were "wow" it's just a parsing stage as far as I know, you parse a macro and put its contents on every place its called. (its a little more complicated than that because of the variables, etc but thats the concept of a macro).



If we put it in a simple way: I suggest you to study some ASM regarding proc so you can see how many calls are made when you call the said proc-edure, because thats when you lose speed... Also, theres nothing faster than direct code execution, which is what a macro lets you do...

However, if your macro is itself slow, then its as good as a helper for a lazy programmer. (But, you'll still be saving on the extra calls).

After my last post on this topic, I wondered if compiling the code to a ".exe" file would make any difference to "compile run" with the debugger off. It does, now I get an improvement 1.4 - 1.55 times which is not as good as before

Might this be because when you compile you are not waiting a little before you perform your test?, this slowdown might occur when the PB compiler is still running or your IDE is saving or w/e .. Just a guess. Since compile-run should itself create a temporary exe and execute it, no?.