Page 1 of 1
RGB as a Macro
Posted: Thu May 11, 2006 4:09 pm
by 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
Posted: Thu May 11, 2006 7:25 pm
by 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)
Re: RGB as a Macro
Posted: Fri May 12, 2006 7:50 am
by horst
Franky wrote: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
Posted: Fri May 12, 2006 10:19 am
by helpy
va!n wrote: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
Posted: Fri May 12, 2006 10:58 am
by ts-soft
helpy wrote:va!n wrote: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))
Posted: Fri May 12, 2006 11:42 am
by 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.
Posted: Fri May 12, 2006 12:42 pm
by 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.
Re: RGB as a Macro
Posted: Fri May 12, 2006 12:54 pm
by 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.
Franky wrote: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!")
Posted: Fri May 12, 2006 12:57 pm
by 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?
Posted: Fri May 12, 2006 1:02 pm
by 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
Posted: Sat May 13, 2006 2:33 am
by 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).
MikeB wrote: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?.