RAND very slow

t1=MilliSecs()
For i=1 To 2000000
pos=Rand(0,255)
'pos=(pos+7) Mod 256
Next
t2=MilliSecs()
Print t2-t1

check first time with RAND and second time with MOD (not the same, but it simulate value changing)

and now see the difference
305ms(rand) vs. 45ms(mod)

(XP-SP2)

Write a faster one then!

Source is in mod/brl.mod/random.mod/random.bmx

Would switching the modules to using superstrict help any? (I notice random.bmx doesn't use it, just strict).

lol!

Under what circumstances would you ever require two million random numbers per frame?

Mark might have taken this more seriously if you were posting a code sample that was anywhere near realistic.

Apart from that, what equates to 7 million function calls per second can never be branded 'slow'.

This:

pos=(pos+7) Mod 256

Is a pretty trivial calculation for the processor.

Algorithms to generate random numbers tend to be much more complex, e.g. to simulate RANDOM numbers.

If you are really that bothered, you could pre-generate 1 million random numbers, stick them in an array, then pull values out of that array, starting at a random point each time. (At least, that *feels* like it would be quicker, albeit not truly random).

This is one of those 'forest for the trees' threads. The speed of RAND, when looked at against your entire game/application, is irrelevant.

MOD is definitely not giving you any kind of randomness.

sorry to bug...where are those dagnabbit blitz 3d original pre-update download files...like when you first purchase B3D? Please help the lost...thanks! =)

>>>Under what circumstances would you ever require two million random numbers per frame?

Hm - do you ever need 2-mio loops? NO? psss... Mark make loops slower ;-)

I do not need, but i wrote a DLL in C++ and tested this with BlitzMax... I needed a non-liner position changing - random is perfect for this - but my DLL was slower than it should be... so that i checked BlitzMax (is the DLL access so slow or something else?). But the speed of RAND is slower than all other sources that i wrote (in the DLL) - so that i posted this... i see that rand use doubles (hell!!!!) - i will compare this with rand from c++

DLL access is always slower than using it "in code". If you have the CPP code, why not simply import - extern it. Would give you a fair comparision and easy way to have other operations if needed. (fastRand?)

PS: Above test is a little unfair anyway. MOD against a power of 2 is like testing a car with round wheels against one with some other, no mather what they are (unless the car flies) ;-)

You'll get more replies if you A) Don't hijack a completely unrelated thread, and B) Post in the appropriate forum. The Blitzmax forum (and other people's threads at that) isn't the place for Blitz3D problems.

:)

this is faster. depends on what you are trying to do but an array of pre-generated random numbers will always win the day.

Local RandArray:Int[] = New Int[10000]

For x = 0 To 9999
	RandArray[x] = Rand(0,255)
Next



t1=MilliSecs()
For i=1 To 2000000
rc:+1 If rc>9999 Then rc=0
pos=RandArray[rc]
Print pos
'pos=(pos+7) Mod 256
Next
t2=MilliSecs()
Print t2-t1

this is slightly faster

t1=MilliSecs()
For i=1 To 2000000
pos=BillRand(0,255)
'pos=(pos+7) Mod 256
Next
t2=MilliSecs()
Print t2-t1

Function BillRand( min_value,max_value=1 )
	Local delta!=Float(max_value)-Float(min_value)
	If delta>0 Return RndFloat()*(1+delta)+min_value
	Return RndFloat()*(1-delta)+max_value
End Function

this is not the point - fact is: rand IS slow.

why? -> it use doubles

workaround -> use this c sample code:


EXPORT int led_array_xxx (int min, int max)
{
return rand() % (max-min+1) + min;
}

BlitzMax Rand = ~310ms
C Rand = ~90ms


OR


Extern "C"
Function crand:Int () = "rand"
End Extern

Function fastrand:Int (start:Int, ende:Int)
Return crand() Mod (ende-start+1) + start
EndFunction

this Blitz Max code is also fast


(marksibly wrote) Write a faster one then!
look it is doable - and its much easier

This may help :P

So, what we want are a few different versions of Rand, dependent on what size variable it's being cast into.

"We" want that? This is another one of the pointless tangents that this community seems to get caught up in every few weeks or so. It doesn't matter. Move on. :)

ok, should have said you, not we. No, not *you* Warren. However, if there is a genuinely significant speed difference between an Int, Float and Double version of Rand, that seems like a reasonable thing to add.

It's reasonable if it's the primary code path slowing down your game. However, I'll eat a pony if that's the case.

doubles should be faster than ints on 64 bit systems, right?

Something I do is just do one call to Rnd() per game loop (unless its noticable during play) and then multiply when I need a range. Much faster. Like this:

SuperStrict

Local blah%
Local now%=MilliSecs()
For Local f%= 1 To 100000
	blah = Rand(0,f)
Next
now = MilliSecs()-now
Print now

now%=MilliSecs()
Local myrnd# = Rnd(0,1)
For Local f%= 1 To 100000
	blah = myrnd*f
Next
now = MilliSecs()-now
Print now

Admittedly, it's not always possible to work like this, but you can at least reduce the number of times you call Rnd/Rand.

No. Which is faster int or float depends primarilly on how many processing units you have (ALU for ints, FPU for floats) and how good you (or your compiler) can restructure a algorithm or expression to allow for out-of-order execution.

If you have a typical mid-level CPU (Celeron) you'll have 4 ALUs and only 1 FPU so if your algorithm is well suited for out-of-order processing, your ints will be processed 4 times as fast.

If you have a typical high-end CPU (proper Pentium) you'll have up to 6 ALUs and 2 FPUs, which means your ints will be processed 3 times as fast.

If you have a server grade CPU (like a Xeon or Itanium) all bets are off, as chances are you'll probably have 8 ALUs and just as many FPUs.

If your algorithm or expression isn't designed in such a way as to take advantage of out-of-order execution, it won't make any difference at all.

There isn't. Not in general anyway. It would only be useful (and then even marginally at that) to people who develop for really old computers.