Not the speed increase I'd hoped for....

I've recoded some old Blitz plus stuff into Bmax. Didn't use bbconv, just did it by hand. My program's a rigid body engine, but it runs a lot slower under Bmax! I ahven't tried to do anything clever with the re-write so there's little difference in the code. Narrowed time difference down to one main routine....

Function circle_constraints()
	'Attempts To move all circles out of collision
	Local c:circle 	' circle
	Local cc:circle	' circle tested For col with	
	
	c=c_list._head
	While c
		cc=c_list._head
		While cc
			If (c<>cc)
				Local coldist#=c.rad+cc.rad
				Local d#=Sqr((cc.x-c.x)^2.0+(cc.y-c.y)^2.0)
				If d<coldist
					Local mx#=(coldist-d)*(c.x-cc.x)/d
					Local my#=(coldist-d)*(c.y-cc.y)/d
					
					c.x=c.x+mx/2.0
					c.y=c.y+my/2.0
					cc.x=cc.x-mx/2.0
					cc.y=cc.y-my/2.0
					
				EndIf 
			EndIf
			cc=cc._next
		Wend
		c=c._next
	Wend
	Return
End Function

18 ms for 40 circles in bmx

Function circle_constraints()
	;Attempts to move all circles out of collision
	Local c.circle 	; circle
	Local cc.circle	; circle tested for col with	
	
	For c=Each circle
		For cc=Each circle
			If (c<>cc)
				Local coldist#=c\rad+cc\rad
				Local d#=Sqr((cc\x-c\x)^2+(cc\y-c\y)^2)
				If d<coldist
					Local mx#=(coldist-d)*(c\x-cc\x)/d
					Local my#=(coldist-d)*(c\y-cc\y)/d
					
					c\x=c\x+mx/2.
					c\y=c\y+my/2.
					cc\x=cc\x-mx/2.
					cc\y=cc\y-my/2.
					
				EndIf 
			EndIf
		Next
	Next
	Return
End Function

2ms for 40 circles in B+. Any help/suggestions appreciated.

Sqr is a double precision function now, so in your first loop, the floats are being cast to double, the sqrt is found, and this is then cast back to float. (I believe) you could speed it up considerably by changing these:

Local d#=Sqr((cc.x-c.x)^2.0+(cc.y-c.y)^2.0)
				If d<coldist

To this:

Local xdist# = ( cc.x - c.x )
Local ydist# = ( cc.y - c.y )
Local d# = ( xdist * xdist ) + ( ydist * ydist )
If d < ( coldist * coldist )

Thanks Michael -

I never said it was optimised yet - it's only the speed difference for identical code that concerns me. I'll sort out the issue with the sqr function (well spotted!!) and see if it makes the difference.

Make sure you're using FlushMem too!

Well I only posted it because it meant you weren't calling the BlitzMax Sqr function. If BlitzMax had a float Sqrt, the BlitzMax code would execute significantly faster than the Blitz3D code, because the compiler generates much more sensible assembler.

I think you'll find that with the optimisation I posted in place implemented in both versions, the BlitzMax version will totally thrash the BlitzPlus one. This raises an interesting issue though - Max needs double math functions, but they probably shouldn't be the default ones since they're not nearly as fast.

Agreed - there are relatively very few occassions where double accuracy is absolutely needed.

What happens if you use doubles throughout? I think the casting is a pretty large bottleneck, but every CPU on the market has support for fast double-precision math in some form or other (whether Max has the code to support it, I don't know).

Hi,

This is odd...

There is no casting required when a double is returned from a function as it's returned in an FP register anyway. The overhead of passing a double to a function is having to 'push' 8 bytes instead of 4.

In other words, I don't think its a float/double thing but some other weird issue. The '^2.0' is likely to be slow - perhaps I've optimized this in BP to a multiply but not in Max...

And both are of course running with debug disabled?

^2 was already a speedprob in Blitz3D where powers only were usefull if 3 or 4 upwards ... for ^2 you better wrote it out.

Think the problem is the double sqrt needs *2^32bit times longer to calculate than a float sqrt ...

perhaps there is a float sqrt function? ( will check that and edit this posting here )

Ok, I've found it: the ^ operator is absolutely killing performance!

Replacing...

Local d#=Sqr((cc.x-c.x)^2.0+(cc.y-c.y)^2.0)

...with...

Local dx#=cc.x-c.x
Local dy#=cc.y-c.y
Local d#=Sqr( dx*dx+dy*dy )

...takes execution time from 1860 down to 7!

Further good news: the BP original takes 138, and 'tuned' version 46, so Max *is* faster than BP.

Will definitely be looking at this, but in the meantime avoid ^!

Here's the mockup program I did - does this look a bit like how it might be used in the 'real world'?

Type circle

	Field _next:circle
	Field x#,y#,rad#
 
End Type

Type clist

	Field _head:circle

End type

Function clist_add( cl:clist,c:circle )

	c._next=cl._head
	cl._head=c

End Function

Global c_list:clist=New clist

Function circle_constraints()
'Attempts To move all circles out of collision
	Local c:circle ' circle
	Local cc:circle' circle tested For col with

	c=c_list._head
	While c
		cc=c_list._head
		While cc
			If (c<>cc)
				Local coldist#=c.rad+cc.rad
				Local dx#=cc.x-c.x
				Local dy#=cc.y-c.y
				Local d#=Sqr(dx*dx+dy*dy)
'				Local d#=Sqr((cc.x-c.x)^2.0+(cc.y-c.y)^2.0)
				If d<coldist
					Local mx#=(coldist-d)*(c.x-cc.x)/d
					Local my#=(coldist-d)*(c.y-cc.y)/d
					c.x=c.x+mx/2.0
					c.y=c.y+my/2.0
					cc.x=cc.x-mx/2.0
					cc.y=cc.y-my/2.0
				EndIf 
			EndIf
			cc=cc._next
		Wend
		c=c._next
	Wend
	Return
End Function

For Local i=1 To 500
	Local c:circle=New circle
	c.x=rnd(640)
	c.y=rnd(480)
	c.rad=rnd(160)
	clist_add c_list,c
Next

t=MilliSecs()
circle_constraints
t=MilliSecs()-t

Print t

Sweet as a nut - and yes that's pretty much how I'm using it. Thanks to everyone for the input. Nothing like a 'Max is slower than B+' post to get Mark's attention ; )

Merry xmas all.

Here's another oddity.

The ^2.0 test code is extremely slow. You can speed it up a little by turning Debug ON!

Woah, that one needs investigating, Floyd

Kanati said the debug version of my shader test was faster than release:


http://www.blitzbasic.com/Community/posts.php?topic=41957

Tom

Yeah, I didn't actually put it in the bugs forum because I didn't know if it was just me or not... but it looks like I might not be the only one.