Banks

BlitzMax Forums/BlitzMax Programming/Banks

BLaBZ

(Posted 2011) [#1]

What are banks? I'm incorporating path finding into my application and I need something fast, would banks be good for this?!

Yasha

(Posted 2011) [#2]

Banks are a holdover from the era of Blitz Classic, presumably for compatibility with Blitz3D programs. They expose a non-GC'd block of untyped memory into which you can Poke any binary values you please.

In other words, they are slow, unsafe (requiring you to break both the type system and the GC), and don't offer any features you can't get from arrays or other container structures. Unless you quickly need to port B3D code without bothering to rewrite it, best not to use them.

Last edited 2011

ImaginaryHuman

(Posted 2011) [#3]

I say go ahead and use them if you want to. I find them handy sometimes.

Jesse

(Posted 2011) [#4]

I disagree with Yasha in that they are slow. Used creatively, they are even faster than Bmax arrays. For an a* algorithm it's a great option in my opinion.

Last edited 2011

*	(Posted 2011) [#5]

Banks can be very handy for other things like byte conversion work, and as Jesse suggested sometimes they can be MUCH faster than standard arrays.

ImaginaryHuman

(Posted 2011) [#6]

Using pointers with banks is fast, I would say avoid the peek/poke stuff although that's supposed to be `safer` for when you `lock` the bank to keep its memory from being reallocated or whatever.

mpmxyz

(Posted 2011) [#7]

Banks are faster than arrays?
I tested it and also found no significant speed difference between pointers and arrays.

My times in non-threaded mode without debugger with 100 iterations and 100000000 integers:

memalloc: 1 ms
memclear: 12626 ms
new array: 11617 ms
pointer set: 6144 ms
array set: 6243 ms
pointer read: 3833 ms
array read: 3843 ms
pointer copy: 4572 ms
array copy: 4554 ms
pointer resize: 21552 ms
array resize: 18433 ms
pointer free: 3222 ms
array collect: 0 ms

The same in threaded mode:

memalloc: 1 ms
memclear: 12488 ms
new array: 11531 ms
pointer set: 6047 ms
array set: 6084 ms
pointer read: 3835 ms
array read: 3840 ms
pointer copy: 4507 ms
array copy: 4498 ms
pointer resize: 21480 ms
array resize: 15269 ms
pointer free: 3132 ms
array collect: 3217 ms

Here is my code:

SuperStrict

Const ITERATIONS:Int=10
Const SIZE:Int=100000000
Local tests:String[]=["memalloc","memclear","new array","pointer set","array set","pointer read","array read","pointer copy","array copy","pointer resize","array resize","pointer free","array collect"]
Local time:Int[]=New Int[tests.length+1]
Local i:Int,j:Int,iteration:Int

For Local iteration:Int=0 Until ITERATIONS
	GCCollect()
	time[0]:+MilliSecs()
	Local pointer:Int Ptr=Int Ptr(MemAlloc(SIZE*4))
	time[1]:+MilliSecs()
	MemClear(pointer,SIZE*4)
	
	time[2]:+MilliSecs()
	Local array:Int[]=New Int[SIZE]
	
	time[3]:+MilliSecs()
	For i=0 Until SIZE
		pointer[i]=i
	Next
	time[4]:+MilliSecs()
	For i=0 Until SIZE
		array[i]=i
	Next
	
	time[5]:+MilliSecs()
	For i=0 Until SIZE
		j=pointer[i]
	Next
	time[6]:+MilliSecs()
	For i=0 Until SIZE
		j=array[i]
	Next
	
	time[7]:+MilliSecs()
	MemCopy(pointer,pointer+SIZE/2,SIZE/2*4)
	time[8]:+MilliSecs()
	MemCopy(Varptr array[0],Varptr array[SIZE/2],SIZE/2*4)
	time[9]:+MilliSecs()
	pointer=Int Ptr(MemExtend(pointer,SIZE*4,SIZE*4+100))
	MemClear(pointer+SIZE,100)
	
	time[10]:+MilliSecs()
	array=array[..SIZE+25]
	GCCollect()	'to be fair: collect the unused aray
	
	time[11]:+MilliSecs()
	MemFree(pointer)
	time[12]:+MilliSecs()
	array=Null
	GCCollect()
	time[13]:+MilliSecs()
	Print GCMemAlloced()+" bytes of memory allocated"
Next

Print "Here come the test results:"

For i=0 Until tests.length
	Print tests[i]+": "+(time[i+1]-time[i])+" ms"
Next

Last edited 2011

Jesse

(Posted 2011) [#8]

There is a tread a few months back that illustrate that. When I get a chance I'll look for it. Can't now don't have time.

col	(Posted 2011) [#9]

There have been a lot these types of arguments over the 'this is faster than that' command, but in real terms unless you're doing millions and millions of iterations then there is no 'real' conceivable difference.

I'd start out with makes the code easiest to read and intuitive for you, and of course the code must work :D and don't worry about the tiny nanosecond that you may save by making things awkward for yourself with code thats hard to understand 6 months later.

EDIT : TBH There is a well known pit-fall called 'Premature Optimization™', and most of these type of arguments qualify. I guess it makes for interesting conversation though :D

Multi-threading is for you to write multi-threaded apps, and not for BMax to make your code multi-threaded for you. If that makes sense :/

Last edited 2011

mpmxyz

(Posted 2011) [#10]

Multi-threading is for you to write multi-threaded apps, and not for BMax to make your code multi-threaded for you. If that makes sense :/

BlitzMax uses a different garbage collector when enabling threaded mode.
I just wanted to show that it doesn't change much. ;-)

Last edited 2011

col	(Posted 2011) [#11]

Ah I see :P
I thought you were expecting a significant speed increase when using the multi-thread option as the topic is about speed :D

I don't use the multi threading option hardly and I've read some forum posts about it being occasionally buggy, although that's not why I don't use it.

As for speed - of course if you 'DID' use multiple threads then it's a whole new ball game and there's been some heavy work by people here optimising certain 'classic' routines :P

Jesse

(Posted 2011) [#12]

I take it back the high level Bank instructions are probably as slow as arrays but when you get to the core of banks all they are is a stream of bytes. and when you access the bank as byte pointers they are faster than array:

http://www.blitzmax.com/Community/posts.php?topic=93727#1072860

just in case you find it useful but I do agree with col not all optimization will give you the needed results and this will probably won't either.