blitzmax much slower than blitzplus in calculation

BlitzMax Forums/BlitzMax Beginners Area/blitzmax much slower than blitzplus in calculation

Najdorf(Posted 2005) [#1]
I bought blitzmax and am playing with the windows beta, it's graphically awesome however I have a problem:

looks like max is much slower than plus in calculations !!!

take this code in both max and plus:


a=MilliSecs()
y#=0
For i= 1 To 1000000
y=y+i^0.5
Next
Print y
Print (MilliSecs()-a)



Max finds the answer in 3731 milliseconds

Same thing in Plus takes 190 millisecs!!

However Max is MUCH faster than plus in drawing (about 10 times?) and draws much better (no flickering at all...)

I really need speed for computationally intensive physics simulations, and I would like to compute at least as fast as in blitzplus! (which is actually almost as fast as C, in C it takes about 140 millisecs[believe me or not it took me an hour to write the C program :P])

Some ideas?


BlitzSupport(Posted 2005) [#2]
There was a problem with the ^ operator... I believe this'll be fixed for the next release.


ImaginaryHuman(Posted 2005) [#3]
In BlitzMax, you will find there are two places where variables can be stored, either in memory or in CPU registers. Whenever you use a regular variable or you define one as a Global, it puts it in main memory. The way you have it set up right now all your variables are working from memory. The alternative is to use the "Local" keyword which, while at the same time confines the scope of the variable to with a block of code (ie inside a function, inside a for-next loop, etc) is also puts the variables in CPU registers (or tells the compiler to create code that works that way), which is MUCH faster.

So instead, try this code in BlitzMax and see what kind of result you get:

Local a=MilliSecs() 
Local y#=0 
For Local i#= 1.0 To 1000000.0 step 1.0 
   y=y+i^0.5 
Next 
Print y 
Print (MilliSecs()-a)

What result does this give you? (not saying I know that Max is faster, just that you need to use Locals for fastest results). Also not sure whether to go with a float or int for the loopcounter there.

[EDIT] - And as James said, there may be a bug with the ^ operation.


Dreamora(Posted 2005) [#4]
bug is relative.
It is bound to the actual implementation of math which always casts to double and does double maths instead of floats or even integer where possible.


Najdorf(Posted 2005) [#5]
hmmm... your probably right about the ^ bug...

This:

a=MilliSecs()
y#=0
For i= 1 To 100000000
y=y+i*i
Next
Print y
Print (MilliSecs()-a)

runs 5 times faster on MAX...

but this:

a=MilliSecs()
y#=0
For i= 1 To 1000000
y=y+Sin(i)
Next
Print y
Print MilliSecs()-a

runs 3 times faster on PLUS...

So there definetely is a bug with the ^ operator (20 times faster on plus!), but also the trigonometric functions should be checked (3 times faster on plus), and thats about it (is it?), oh well since were talking about it maybe check also log and everything else...

thx,

Matteo

Edit: I checked the "if" operator and its 3 times faster in MAX


FlameDuck(Posted 2005) [#6]
It is bound to the actual implementation of math which always casts to double and does double maths instead of floats or even integer where possible.
Except it isn't.


DNielsen(Posted 2005) [#7]
Is it just me or can this be considered a MAJOR bug??


Dreamora(Posted 2005) [#8]
It was mentioned to be solved, from what I get out of the fix list of 1.02 I think it might already be fixed in the "real" version :)


flying willy(Posted 2005) [#9]
Will mark be making compiler optimisations to Blitz3D? It would be nice if he can do a few hacks to speed stuff up :)


BlitzSupport(Posted 2005) [#10]

Is it just me or can this be considered a MAJOR bug??


It is... but it's been updated in the OS X release version, 1.02. You should expect to find bugs in the beta versions! They'll then be fixed for the release.


DNielsen(Posted 2005) [#11]
@BlitzSupport
Of course, and I agree. A BETA does have bugs! (all final products too) And thank goodness this one was found :-) It was MASSIVE! Excellent support as usual.


Najdorf(Posted 2005) [#12]
Thank you, thank you, it was easy...

crazy thing that my simulation app. DOUBLED in speed after I replaced two x^2 with x*x... however it still has an x^0.5 that slows it down (cant avoid that one...)

Oh, I checked "log()", and its 5 times faster in PLUS... another thing to check out definetely..

Looks like many of the low level math functions have to be checked out (definetely trig. functs, ^ and log, probably others).

BTW for other stuff MAX is really fast (sums, products), and the 2D drawing routines are perfect.


MrCredo(Posted 2005) [#13]
sin/cos etc.. use doubles - and they are slow
mark fix this soon (i think)


LeisureSuitLurie(Posted 2005) [#14]
however it still has an x^0.5 that slows it down (cant avoid that one...)



Why not sqrt(x)?


Najdorf(Posted 2005) [#15]
sqrt() does not exist in max


Perturbatio(Posted 2005) [#16]
sqr() does though


Najdorf(Posted 2005) [#17]
awesome!

I had ONE ^0.5 in my code, now that I replaced it with sqr the whole thing runs 15(!!!!!!) times faster! Looks as ^ is a terrible bottle neck.


tonyg(Posted 2005) [#18]

Looks as ^ is a terrible bottle neck.


... or has a bug which is due to be fixed in the next release.


Najdorf(Posted 2005) [#19]
yeah, i mean CURRENTLY its a bottle neck


flying willy(Posted 2005) [#20]
^ is fairly slow anyway afaik, and using multiplication where possible will be much faster - ie distance routines.


Eole(Posted 2005) [#21]
All the calculation are made with Double ... Just try a simple calculation with cos are sin ...

I already post about this here :
http://www.blitzbasic.com/Community/posts.php?topic=41987


This is the answer of Mark:
marksibly (Posted 2004-12-28 20:14:19)

Eole,

Please be aware that this is a *beta version*!!!!!

As it turns out, there are quite a few problems with the math funcs. Many of these problem are in the process of being fixed so don't panic just yet!


FlameDuck(Posted 2005) [#22]
sin/cos etc.. use doubles - and they are slow
No they aren't. The FPU uses a much higher accuracy for calculations, so whether you chose to cast that result to a double or a float is the same difference.