blitzmax much slower than blitzplus in calculation

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?

There was a problem with the ^ operator... I believe this'll be fixed for the next release.

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.

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.

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

Except it isn't.

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

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 :)

Will mark be making compiler optimisations to Blitz3D? It would be nice if he can do a few hacks to speed stuff up :)

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.

@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.

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.

sin/cos etc.. use doubles - and they are slow
mark fix this soon (i think)

Why not sqrt(x)?

sqrt() does not exist in max

sqr() does though

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.

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

yeah, i mean CURRENTLY its a bottle neck

^ is fairly slow anyway afaik, and using multiplication where possible will be much faster - ie distance routines.

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!

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.