Mandelbrot speed test - PB shifts some

[GedB]

Wow,

Replacing DotsColor with fweil's code makes it nearly 4 times faster.

PB with fweil's code starts off at just under 1000 kpix/sec.

PB with the original code starts off at just under 280 kpix/sec.

The GL executable runs at just over 565 kpix/sec.

The same calculations are being made, so how can it make such a difference?

[fweil]

Read carefully and you will probably understand that some differences are behind ..

[Dreglor]

Dreglor,

Here is the same code using WindowOuput() instead of DirectX. Does it display OK on your PC?

Does the GL Version display OK?

well that window one works
maybe i should install diretx and my drivers
it weird because thats the only program thats seams to be messing up no other games seams to do the same...

[GedB]

hats the only program thats seams to be messing up no other games seams to do the same...

Perhaps the problem is with plot specifically, and games tend to use sprites.

The following is a modificaiton of the sprite exampe with a grid plotted behind.

Do you get both the grid and sprite OK?

Code: Select all

;
; ------------------------------------------------------------
;
;   PureBasic - Sprite example file
;
;    (c) 2001 - Fantaisie Software
;
; ------------------------------------------------------------
;

If InitSprite() = 0 Or InitKeyboard() = 0
  MessageRequester("Error", "Can't open DirectX 7 or later", 0)
  End
EndIf

;
; Now, open a 640*480 - 16 bits (65000 colours) screen
;

If OpenScreen(640, 480, 16, "Sprite")

  ; Load our 16 bit sprite (which is a 24 bit picture in fact, as BMP doesn't support 16 bit format)
  ; 
  LoadSprite(0, "Data\PureBasic.bmp", 0)
  CopySprite(0,1,0)
  
  ; Draw some red line on our sprite
  ;
  If StartDrawing(SpriteOutput(1))
    FrontColor(255, 0, 0)
    For k = 0 To SpriteHeight(1) Step 2
      Line(0, k, SpriteWidth(1), 0)
    Next
    StopDrawing()
  EndIf

  Repeat
    
    ; Inverse the buffers (the back become the front (visible)... And we can do the rendering on the back)
    
    FlipBuffers()
    
    ClearScreen(0,0,0)
    
    StartDrawing(ScreenOutput())
    For i = 1 To 640
      For j = 100 To 500 Step 100
        Plot(i, j)
        Plot(j, i)
      Next j
    Next i
    StopDrawing()
    
    ; Draw our sprite

    ClipSprite(0, 0, 0, x, x/8)
     
    DisplaySprite(0, x, 100)
    DisplaySprite(1, x, x)
    DisplaySprite(0, 600-x, x)
    x+1
    
    ExamineKeyboard()
  Until x > 500 Or KeyboardPushed(#PB_Key_Escape)
  
Else
  MessageRequester("Error", "Can't open a 640*480 - 16 bit screen !", 0)
EndIf

End   

[Dare2]

Replacing DotsColor with fweil's code makes it nearly 4 times faster.

Read carefully and you will probably understand that some differences are behind ..

It is interesting.

Using the integer "j+1" will be, what, 5 to 10 (?) clock cycles faster than the float "j=j+1" in the while loop.

Is that the entire reason? If not, what other things make it more efficient?

[GernotFrisch]

Hallo,

jetzt muss ich mich wohl auch mal melden. Das Mandelbrot bsp. ist für Geschwindigkeitstests nur bedingt zu gebrauchen. Das Problem ist, das der SETPIXEL Befehl unter Umständen übel langsam sein kann. Bei GLBasic ist er auch nicht optimiert und braucht etwa 50% der Rechenzeit (auch abhängig von der Grafikkarte). Das OpenGL/DirectX Problem ist auch noch da. Manche Karten machen dies schneller, andere das.
Das Programm sollte eigenltich zeigen, wie einfach GLBasic zu programmieren ist. Zahlen, Wörter, Punkt.
Wer PureBasic beherrscht braucht GLBasic wohl nicht. Für Anfänger (meine ich) habe ich ein echt einfaches, starkes, konsistentes Werkzeug zur Spieleentwicklung geschaffen.

Gruß,
Gernot

[Dare2]

now I must announce myself probably times. Almond bread ex. is to be used for speed tests only conditionally. The problem is, which can sometimes be badly slow the SET PIXELS instruction. With GLBasic it is also not optimized and needs about 50% of the computing time (also dependent on the diagram map). Also still there the OpenGL/DirectX problem is. Some maps make this, others faster that. The program should show eigenltich, how simply GLBasic is to be programmed. Numbers, words, point. Who pure basic controlled does not need GLBasic probably. For beginners (I mean) I created a genuinly simple, strong, consistent tool for play development

Howdy, and props on GLBasic.

Mandelbrot = Almond Bread! lol, I will never see another without getting hungry!

[GernotFrisch]

Oh dear... I didn't look close enough. This is an English forum - I appologize....

What I wanted to say is, that the Mandelbrot sample is not really a good example for speed testing. It's rather thought for comparing the languages itself than the speed of the executables. Most game programming sets have slow implementations of setpixel. Even GLBasic is slow in that thing. Also it widely depends on the graphics card you have and its driver. Then the OpenGL vs DirectX problem. Some cards do this faster other that. I found computers that have a faster implementation of DirectX, where the BlitzBasic runs faster than GLBasic - ridiculous speed test for GLBasic promoting on these computers. If you're familiar with PureBasic, stick to it. It's a good language if you know how to use it. What I wanted to show is, that GLBasic is a robust, fast and very easy to program game construction kit.

Bye,
Gernot

[GedB]

If you're familiar with PureBasic, stick to it.

Gernot,

It's always nice to see such a good attitude.

It seems that Basic programmers have never had it so good, so many excellent implentations to choose from.

[fweil]

@Dare2

Using the integer "j+1" will be, what, 5 to 10 (?) clock cycles faster than the float "j=j+1" in the while loop.

Is that the entire reason? If not, what other things make it more efficient?

If you compare the codes

Code: Select all

Procedure.f DotsColor(xval.f, yval.f) ; color value from 0.0 to 1.0 by iterations 
  DefType.f i, m, r, j
  While (j < #max) And (m < 4.0) 
    j=j+1 
    m = r * r - i * i 
    i = 2.0 * r * i + yval 
    r = m + xval 
  Wend 
  ProcedureReturn j / #max 
EndProcedure 

Procedure.f MB(xf.f, yf.f)
  fx.f = xf
  fy.f = yf
  j.l = 0
  u.f = 0.0
  v.f = 0.0
  While j <= #max And (u + v) < 4.0
    u = fx * fx
    v = fy * fy
    fy = 2.0 * fx * fy + yf
    fx = u - v + xf
    j + 1
  Wend
  ProcedureReturn j / #max
EndProcedure

you can notice first that I use integers if possible, but that does not make so much difference. On the other hand the way to calculate intermediate values is not exactly the same, and if calculation renders close to the same results, it is not exactly the same.

Try a debug trace with comparable input values, and you will see differences.

Then in my procedure (I wrote it the first time in Fortran in 1984), I know that the number of iterations is lower to reach the limit of iterations or the limit of imaginary number.

Well, the procedure I use is accurate and a bit faster even if you only use single precision floats.

When the first publications of Benoit Mandelbrot were made, I was an early reader and tester with a colleague to design programs for rendering fractals like this.

An old story, but I continue since this time to make fractals (with much more complicated adds to get really wonderful effects). This is part of my work nowadays.

Rgrds

[fweil]

Maybe just for trying to show what may be fixed somewhere in the original benchmark, I rewrite a code that shows differences between both mandelbrot walues calculation :

Code: Select all

; 
; Testing MB() vs DotsColor()
;

#max.f = 128   ; #max iterations 

#x1 = 640    ; ScreenX 
#y1 = 480    ; ScreenY 

xstart.f = -2.025 
ystart.f = -1.125 
xende.f = 0.6 
yende.f = 1.125 

xzoom.f = (xende - xstart) / #x1 
yzoom.f = (yende - ystart) / #y1 

fac.f = 0.99 

Procedure.s DotsColor(xval.f, yval.f) ; color value from 0.0 to 1.0 by iterations 
  DefType.f i, m, r, j
  iterations = 0
  While (j < #max) And (m < 4.0) 
    j=j+1 
    m = r * r - i * i 
    i = 2.0 * r * i + yval 
    r = m + xval 
    iterations + 1
  Wend 
  ProcedureReturn "DotsColor() : " + Str(iterations) + " iterations" + " value = " + StrF(j / #max)
EndProcedure 

Procedure.s MB(xf.f, yf.f)
  fx.f = xf
  fy.f = yf
  j.l = 0
  u.f = 0.0
  v.f = 0.0
  iterations = 0
  While j <= #max And (u + v) < 4.0
    u = fx * fx
    v = fy * fy
    fy = 2.0 * fx * fy + yf
    fx = u - v + xf
    j + 1
    iterations + 1
  Wend
  ProcedureReturn "MB() : " + Str(iterations) + " iterations" + " value = " + StrF(j / #max)
EndProcedure

Procedure mandelbrot(xstart.f, ystart.f, xzoom.f, yzoom.f) ; calculate all points 
  DefType.f h, old 
  Address = DrawingBuffer()
  For y = 0 To #y1 - 1 
    For x = 0 To #x1 - 1 
      Debug Str(x) + " " + Str(y) + " " + DotsColor(xstart + (xzoom * x), ystart + (yzoom * y)) + " - " + MB(xstart + (xzoom * x), ystart + (yzoom * y))
    Next 
  Next 
EndProcedure 

    xende = xende * fac 
    xstart = xstart * fac 
    ystart = ystart * fac 
    yende = yende * fac 
    xzoom = (xende - xstart) / #x1 
    yzoom = (yende - ystart) / #y1 
    timer = GetTickCount_() 
    mandelbrot(xstart.f, ystart.f, xzoom.f, yzoom.f) 
    timer = GetTickCount_() - timer 
    speed = Int(#x1*#y1 / (1+(timer))) 

The code is just adapted from original but only displays values and iterations # in the debugger window.

KRgrds

[GedB]

Fweil,

Is you avatar a fractal?

[Dare2]

Hi fweil

Thanks for that. I will examine it.

(But not right now. I am in one of those too-many-things-to-do states with End of Financial Year on, and a big business meeting coming up this week-end.)

So you do fractals, etc, as a part of your work? I am intrigued.