Fast floating-point random numbers

[meynaf]

Originally Posted by Thorham

Seems a little weak. It's really easy to write something simple and think it's okay, while the output is really bad. Randomness is a topic that must not be underestimated.

Originally Posted by Mrs Beanbag

true but i really don't think it needs to pass all of these rigorous statistical tests to be good enough to decide which item an enemy drops when you kill it.

Games do not really need top notch random... But a single register read is indeed a little weak.

Originally Posted by Thorham

Sounds good, but I'd test it using the full suite. Shouldn't take that long on your laptop.

Maybe one day. I tried the toughest tests i could find, from many different suites so i'm quite confident.

Originally Posted by Thorham

Indeed. Xorshift is nice for when you need something simple and reasonable that's also fast. I prefer Xorgens4096, because it's pretty fast, has a huge period and passes all of Big Crush.

TestU01 isn't necessarily the strongest, even in big crunch mode. Have you checked with the NIST randomness test suite ?

Originally Posted by Thorham

Yeah, I know. The hardware registers don't behave in the same way as on hardware.

I wish we had faster counters, they would provide better quality. CIAs are damned slow. Wouldn't solve the problem on emulators, though.

[Thorham]

Originally Posted by Mrs Beanbag

true but i really don't think it needs to pass all of these rigorous statistical tests to be good enough to decide which item an enemy drops when you kill it.

Originally Posted by meynaf

Games do not really need top notch random...

Why use a crappy generator when you can use a good one?

Originally Posted by meynaf

TestU01 isn't necessarily the strongest, even in big crunch mode. Have you checked with the NIST randomness test suite ?

No, I haven't, but if it passes BigGrush, then it's certainly not crap

Originally Posted by meynaf

CIAs are damned slow.

My biggest problem is the slow read speed. I think reading a byte from a CIA register takes 200+ cycles!

Originally Posted by meynaf

Wouldn't solve the problem on emulators, though.

Would be great if Tony solved that problem.

[meynaf]

Originally Posted by Thorham

Why use a crappy generator when you can use a good one?

Because crappy generators are simpler, easier to find, and not everyone is willing to run random quality tests.
That said, now that my generator has been tested ok and is inside my main includes, i don't care anymore

Originally Posted by Thorham

My biggest problem is the slow read speed. I think reading a byte from a CIA register takes 200+ cycles!

I would say it takes around 70c @50Mhz (a bit more than 1µs).
Then again, random stuff rarely has to be real fast. I'm using a big MUL (long mul routine if assembled for 68000) and never had speed issues.

[Toni Wilen]

Originally Posted by Thorham

Would be great if Tony solved that problem.

What problem? Sounds like normal fastest possible CPU mode behavior. It won't and can't wait for chips and you can (more like will) get same result if you read same CIA timer or horizontal position register in a loop.

[Thorham]

Originally Posted by Toni Wilen

What problem? Sounds like normal fastest possible CPU mode behavior. It won't and can't wait for chips and you can (more like will) get same result if you read same CIA timer or horizontal position register in a loop.

Yeah, it's the fastest CPU mode behavior. It's a pity that the behavior is different, though. Perhaps a simple detection routine can be written for it.

[Toni Wilen]

Originally Posted by Thorham

Yeah, it's the fastest CPU mode behavior. It's a pity that the behavior is different, though. Perhaps a simple detection routine can be written for it.

In non-jit fastest possible it should be possible to emulate this more accurately but I can't make it the default because it would only mean bug reports ("when I do this and that, new version is much slower.".)

[meynaf]

Originally Posted by Toni Wilen

In non-jit fastest possible it should be possible to emulate this more accurately but I can't make it the default because it would only mean bug reports ("when I do this and that, new version is much slower.".)

What about giving some kind of access to hardware counters of the host ? The routine would then detect it is running on emulation and adapt accordingly.

[Thorham]

The sulution to the WinUae problem turned out to be very simple. Just poll:

    move.b  $bfe601,d0
.loop
    cmp.b   $bfe601,d0
    beq     .loop

After this you can read the rest of the registers. Tested on hardware as well, and works great.

Try this with AsmOne or AsmPro, or something like that, under WinUae with the fastest setting, and watch it generate fabulous gibberish ready for mixing:

a
    lea b,a0

    lea $bfe001,a1
    lea $bfd000,a2
    lea $dff000,a3

    move.l  #1024,d7
.loopa
    move.b  $bfe601,d0
.loopb
    cmp.b   $bfe601,d0
    beq     .loopb

    clr.b   d1

    move.l  a1,a4
    move.l  a2,a5
    move.l  a3,a6

    moveq   #16-1,d6
.loopc
    move.b  (a4),d0
    add.w   #256,a4
    eor.b   d0,d1

    move.b  (a6)+,d0
    eor.b   d0,d1

    move.b  (a5),d0
    add.w   #256,a5
    eor.b   d0,d1

    move.b  (a6)+,d0
    eor.b   d0,d1

    dbra    d6,.loopc

    move.b  d1,(a0)+

    subq.l  #1,d7
    bne     .loopa

    rts

    section data,data_f
b
    dcb.b   100*1024