Compare Blitz VS C++ performance on logic

Blitz3D Forums/Blitz3D Programming/Compare Blitz VS C++ performance on logic

Nikko(Posted 2004) [#1]
I've made a test to see if blitz can really compete with C++ for logic work. Here is the result and the source codes.

Blitz debug : 455
Blitz full speed : 101
C++ debug :1297
C++ full speed : 15

BLitz is 6.7 time slower than C++/C

Here is the source code

;--------------------------------------Blitz
t=MilliSecs()
For i=1 To 1000000
If i=1 Then j=2
If j=2 Then j=4 Else j=5
j=j+256
y#=y#+Cos(i)/100
Next
Print MilliSecs()-t



//-------------------------------------C++
#include "stdafx.h"
#include "math.h"
#include "time.h"
#include "stdio.h"

int _tmain(int argc, _TCHAR* argv[])
{
	int t=0,i=0,j=0,x=0;
	float y=0;
	t=clock();
	for (i=1;i<1000000;i++)
	{
		if (i==1)	j=2;
		if (j==2)  j=4; else j=5;
		j=j+256;
		y=y+acos(i)/100;
	}
	x=clock()-t;
	printf("time=%d", x);
	getchar();
	return 0;
}



slenkar(Posted 2004) [#2]
C++ is very slow on debug,
how about a rendering test?


dynaman(Posted 2004) [#3]
My C++ is a little rusty. Can this line be changed from
y=y+acos(i)/100;

to
y=+acos(i)/100;

If so that may make a difference (though I would not suspect it to be a large difference).

Having blitz do as well as it did is pretty impressive.


Gabriel(Posted 2004) [#4]
Next time I write a game with a million moving objects, I'll definitely bear this in mind.


Nikko(Posted 2004) [#5]
Following the suggestioon of someone at http://www.blitz3dfr.com forum, I've changed the acos C function to cos function.

this changes a lot!

New stats :

Blitz debug : 455
Blitz full speed : 101
C++ debug :1297
C++ full speed and acos: 15
C++ full speed and cos : 0.31

This make C++ 390 time faster than Blitz.

This is only a logic test, about 3D the difference must be close to nothing, because Blitz itself is programmed in C or C++ and because most of the work is done by the 3D hardware.

That's why doing DLL for anything that needs a lot of logic is a good idear. Particles for example uses a lot of logic, and can be too slow with Blitz.


Pinete(Posted 2004) [#6]
Interesting, but...

...we should make a new test.. this time, properly.

How many guys are needed to make an acceptable game using C++/Blitz and how much time is needed?

asking for stats...


marksibly(Posted 2004) [#7]
Hi,

What C compiler are you using? What is the CLOCKS_PER_SEC constant? Used to be 100 under Watcom years back...


AntonyWells(Posted 2004) [#8]
Just ran the tests in vc2005 and blitz,


Using the number above, vc2005 did it in less than a millisecond(returned 0) so I had to up it to 10000000

Vc did in 70milliseconds. Blitz3d took around 2500 millisecs.

Upping it to 100000000 vc takes 700ms, and blitz takes over 23000. 23x slower. Mark...hurry up with bmax eh? :)


AntonyWells(Posted 2004) [#9]
Though changing the blitz one from a for to a repat/forever(exit) thingy-me-gib makes it about 300ms faster.(than the last time.)


Koriolis(Posted 2004) [#10]
What C compiler are you using? What is the CLOCKS_PER_SEC constant? Used to be 100 under Watcom years back...

I've run the test myself, with grossly similar results. And CLOCKS_PER_SEC is 1000 here. So no bias in this area, but there sure are some other ones (though probably none that could in itself explain such a high difference; it's simply slower...it seems). [edit]Mmm, thinking about that's pretty weird to see such huge differences. Maybe there really is a huge bias somewhere.[/edit]
Of course one might not be fooled and think that the overall performance can be deduced by this test.


Dreamora(Posted 2004) [#11]
bear in mind how much stuff is done in Blitz in the background ( whole message handling ) and how nothing you are doing. put a whole messagehandling loop in if you want a real test and not this fake little tests that does not take into account what blitz is actually doing. Or do you program a app that has no message handling? want to see that especially under windows ;)

Looks like the soooo genius tests of Blitz vs DB vs PB which are actually no real tests as half of the language specific stuff is just left out or was "forgotton" to make specific languages worse.


JoshK(Posted 2004) [#12]
But logic is not your slowest step in a game loop. Logic is takes a small proportion of overall game processing time that commercial games can afford to use interpreted script for this!

Let's say you game logic takes 0.01 milliseconds per loop. The render then takes 3 milliseconds. A small change in logic processing speed will make no difference in overall framerate. Rendering speed will be dictated by your graphics card, as Blitz just passes it a vertex buffer and some values. For this reason, Blitz3D with an occlusion system is just as good as C/C++.


H&K(Posted 2006) [#13]
Hi everyone.

Sorry to Bump this.
SuperStrict
'--------------------------------------BMax
Global t:Float = MilliSecs()

For Local i:Int=1 To 1000000
	
	Local J:Int
	Local Y:Float
	
	If i=1 Then j=2
	If j=2 Then j=4 Else j=5
	j=j+256
	y=y+Cos(i)/100
Next

Print MilliSecs()-t

;--------------------------------------Blitz 3d
t=MilliSecs()
For i=1 To 1000000
If i=1 Then j=2
If j=2 Then j=4 Else j=5
j=j+256
y#=y#+Cos(i)/100
Next
Print MilliSecs()-t
B3d Debug 538
B3d 108

Bmax Debug 252
BMax 74

I dont have a C compiler sorry


Boiled Sweets(Posted 2006) [#14]
doing a "/100" is slow


you shoudl break it down into bit shifting componments then add the result...

so for example

i>>2 + i>>2 is quicker than doing a divide.


H&K(Posted 2006) [#15]
And? Its a comparison of what it is.


Curtastic(Posted 2006) [#16]
It's best to do the test a few times in the same program to get a better average, and to make sure it's not just that the *first* test per run is slower for some reason.

C++: 80 (how do I really take off debug in visual C++.net?)
C++ debug: 80
Blitz3d: 80
Blitz3d debug: 465
Max: 80
Max debug: 150

For do=1 To 4
	y#=0
	t=MilliSecs()
	For i=1 To 1000000
		If i=1 Then j=2
		If j=2 Then j=4 Else j=5
		j=j+256
		y#=y#+Cos(i)/100
	Next
	Print MilliSecs()-t
Next

WaitKey
End



In MSVC++ I clicked Debug->Start without debugging, but it was the same speed...?


Finjogi(Posted 2006) [#17]
Hmm.. I was using Code Blocks IDE for C verson And noticed that compiler might optimatize whole section of code as it's result is not used later on..

if (i==1) j=2;
if (j==2) j=4; else j=5;
j=j+256;

Anyway,(edit, acos -> cos for C) Codeblocks gives about 2ms and blitz3d gives 77ms.
Blitz3d also optimatizes those lines..

There was nice & small Mandelbrot speed test which compared fev basic languages & C code.. in that code compiled at least could not strip any code off..


Andy(Posted 2006) [#18]
I seem to recall that B3D also does some stuff before handing over control to the program, so put in a delay before the actual test, and B3D will propably be faster.


Andy


H&K(Posted 2006) [#19]
I know this is a B3d thread?

But Bmax is acctualy slower than b3d if you name the variables in the wrong order (Nomaly in the wrong scope).

You do tend to Prename all you varaiables in Bmax cos of SuperStrict, and if you do it right (Its not difficult, but its not imediatly obvious), the code is faster than b3d but do it wrong and Bmax is slower than B3d. Not loads faster or slower but often a good 15%


John Blackledge(Posted 2006) [#20]
Next time I need some cosine calculations I'll use C++.
You can be sure. ;-)

Right. Now, back to Blitz3D and carry on working on that camera path code.....


KuRiX(Posted 2006) [#21]
In my last commercial game, the full logic (including all particle stuff, handling multiplayer using dll, and all the control of the cars) toke no more than 2 ms to execute at max.

If i could optimize this to less than 1 ms in C++ would be great, but the difference is not so big to make a whole engine change...


Zmatrix(Posted 2006) [#22]
"There was nice & small Mandelbrot speed test which compared fev basic languages & C code.. in that code compiled at least could not strip any code off.."

this one?


http://www.glbasic.com/files/mandelbrot.zip

Sam


Ricky Smith(Posted 2006) [#23]
Strange - I just tried the mandelbrot on my works machine with a crappy Intel integrated graphics and I get the following results :

Blitz3d 399-479 kpix/sec
DB classic - won't run at all
DB Pro - black screen - shows 28 kpix/sec
VB 242 kpix/sec
GL 480 kpix/sec
C++ 265 kpix/sec

The Blitz3d version was the best behaved - I had to end task on most of the others in order to exit.

I don't really know what a kpix/sec is - probable thousands of pixels moved per sec.

Don't know why Blitz3d is among the fastest although it had the most variation - surprised at how poorly DBpro and C++ performed though.


Rroff(Posted 2006) [#24]
Just out of interest...

the c/c++ compiler probably took one look at your loop and cos/acos useage and pre-computed the whole 1million block set as part of the opptimisation process...

do the same by hand for blitz hehe and you get similiar performance...



without debug mode I get 14ms

not sure how valid this is without looking at specifics of the C/C++ compiler and what if any opptimisation is used.


Zmatrix(Posted 2006) [#25]
"Don't know why Blitz3d is among the fastest although it had the most variation - surprised at how poorly DBpro and C++ performed though."'

I thought this was Odd also, Ive tried this same bench in the past with very differnt results (maybe they have changed it?)

it used to be
VC++
blitz3d (was about 75% of c++ speed)
glbasic
Vb
DB
Dbpro (becuase it didnt work right...might recompile it in the latest version)


Sam


Finjogi(Posted 2006) [#26]
In that Mandelbrot test it is very possible that pixel plotting is bottleneck in C++ and some other languages..

After I get back to home I try to test c++ & blitz3d without pixel plotting to see how they compare..