Speed test: Faster Plots, Lines, and Rects
BlitzMax Forums/OpenGL Module/Speed test: Faster Plots, Lines, and Rects
| ||
*EDIT: Code demo now with additional standard IO printout and Fast Rand (From Zeke) GL coders Can you run the code below and let me know if you see much of a speed difference between regular BlitzMax Plot, DrawLine, DrawRect vs the batch-processed versions in the demo? What I mean by batch-processed is, drawing is done within a BEGIN2D .. END2D block to cut out a little overhead In my testing I typically see the Line routine to be somewhere like twice as fast but the Plotting and quads, although faster, aren't significantly so BTW I don't know much about OpenGL so feel free to comment about the commands used. Especially if you know even quicker methods |
| ||
Number of dots = 250000 Fast plot (m/secs)= 532 Normal plot (m/secs)= 640 --- Number of lines = 150000 Fast line (m/secs)= 403 Normal line (m/secs)= 534 --- Number of rects = 80000 Fast rect (m/secs)= 287 Normal rect (m/secs)= 252 |
| ||
DebugLog:Number of dots = 250000 DebugLog: Fast plot (m/secs)= 440 DebugLog:Normal plot (m/secs)= 596 DebugLog:--- DebugLog:Number of lines = 150000 DebugLog: Fast line (m/secs)= 395 DebugLog:Normal line (m/secs)= 535 DebugLog:--- DebugLog:Number of rects = 80000 DebugLog: Fast rect (m/secs)= 262 DebugLog:Normal rect (m/secs)= 247 (I changed the code to output on debug window, easier to copy results here) Here rects are marginally slower with your code, dots a little bit faster and lines faster. |
| ||
Debug on Number of dots = 250000 Fast plot (m/secs)= 482 Normal plot (m/secs)= 654 --- Number of lines = 150000 Fast line (m/secs)= 357 Normal line (m/secs)= 646 --- Number of rects = 80000 Fast rect (m/secs)= 386 Normal rect (m/secs)= 203 Debug OFF Number of dots = 250000 Fast plot (m/secs)= 156 Normal plot (m/secs)= 268 --- Number of lines = 150000 Fast line (m/secs)= 155 Normal line (m/secs)= 293 --- Number of rects = 80000 Fast rect (m/secs)= 79 Normal rect (m/secs)= 109 Hardware specs in sig |
| ||
Blitz rand: fast Plot = 164 normal Plot = 360 fast line = 145 normal line = 353 fast rect = 84 normal rect = 147 FastRand: fast Plot = 84 normal Plot = 306 fast line = 69 normal line = 305 fast rect = 47 normal rect = 107 FastRand version: |
| ||
@Zeke: the RAND built-in function in BlitzMax is so slow?!? 40ms? Interesting |
| ||
(I changed the code to output on debug window, easier to copy results here) Updated code with additional Print() outputHere rects are marginally slower with your code, dots a little bit faster and lines faster Yes, I find the standard Rect sometimes reports a faster time but upon re-running the code several times the FastRect wins out (marginally) It's interesting how the Line drawing seems to be the big winner here |
| ||
@Zeke: the RAND built-in function in BlitzMax is so slow?!? 40ms? Interesting Rand in BMax uses RndDouble(), maps the result to the interval (min, max) and casts it to Int. This means that a call to Rand() involves a call to a normal random generator, a double division, a double multiplication and a cast from double to int. This is of course much slower than rand in C/++, which will most probably only use integers. However, there's a problem with both functions. RndDouble() divides by 2^29 at the end (to map the integer value in range 0.0!-1.0!). This implies that the random number generated is only in range 0-2^29. If I were to call Rand( 2^31 ), only a fourth of the numbers in range can be actually generated. This is pretty bad. On the other hand, the quality of rand in the cstdlib greatly depends on the implementation, but in a lot of cases the quality is poor. It will also only generate numbers in range of 0-RANGE_MAX. The value of RANGE_MAX depends on the implementation, but it is granted to be at least 32767 (and you shouldn't bet on more than that). 32767 is only 2^15, not enough for a lot of cases. That's why I propose reimplementing BRL.Random with something faster and more exact (=covering all 32 bits). It doesn't have to be a fancy Mersenne Twister; a simple Multiply-with-carry would suffice, which is really easy to implement. |