Speed test: Faster Plots, Lines, and Rects

BlitzMax Forums/OpenGL Module/Speed test: Faster Plots, Lines, and Rects

EOF(Posted 2010) [#1]
*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




_Skully(Posted 2010) [#2]
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


SLotman(Posted 2010) [#3]
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.


degac(Posted 2010) [#4]
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


Zeke(Posted 2010) [#5]
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:



degac(Posted 2010) [#6]
@Zeke: the RAND built-in function in BlitzMax is so slow?!? 40ms? Interesting


EOF(Posted 2010) [#7]
(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
Updated code with additional Print() output
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


Noobody(Posted 2010) [#8]
@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.