A poor man's struct (err, MappedObject)

[HamsterofDeath]

that backed-by-float[]-floatbuffer is STILL faster than using Unsafe.

i removed the double increment. saved about 2ms (of 29). i'm at 27 now. and i'm just reading the same element 10 million times now, so there shouldn't be cache flushing, right?.
the 10mb size shouldn't matter at all. every test iterates over every element.

on my machine, your direct float buffer is slower (a few ms) than the backed one...

[Riven]

Let's not turn this thread into a benchmark frenzy, please.

The generated machine-code depends greatly on the JIT and can't really be predicted.

Sometimes FloatBuffers perform like float-arrays, sometimes they perform 10 times worse... let me show you what I mean:

Testing all 4 types of access:

1   2   3   4

float[]:               183ms unsafe:                127ms floatbuffer (direct):  1131ms floatbuffer (float[]): 1035ms

Testing 3 types of access (all minus floatbuffer (float[]) )

1   2   3   4

float[]:               194ms unsafe:                128ms floatbuffer (direct):  147ms <--------- 7.7x faster floatbuffer (float[]): 0ms

So code in other methods doing other things, affects performance in appearantly unrelated code!



When invoking this anywhere:
FloatBuffer.allocate(elements);
the code using DirectFloatBuffer drops performance by factor 7-8

Probably because the JIT notices FloatBuffer now has more than 1 active subclass, so it can't optimize the general FloatBuffer class as it would do when only having DirectFloatBuffers around.

1   2   3   4   5   6   7

benchmark(); printResults(); // floatbuffer (direct):  115ms FloatBuffer.allocate(elements); benchmark(); printResults(); // floatbuffer (direct):  971ms

* Riven learned something new today

[Spasi]

Probably because the JIT notices FloatBuffer now has more than 1 active subclass, so it can't optimize the general FloatBuffer class as it would do when only having DirectFloatBuffers around.

This situation is supposed to be better in Mustang with bimorphic call inlining.

Games published by our own members! Check 'em out!

[Riven]

Life is better after 6 

[tusaki]

Here are my results for both benchmarks. (including suggested improvements)

Benchy

1   2   3   4   5   6   7   8   9

before FloatBuffer.allocate()    float[]:               211ms    unsafe:                218ms    floatbuffer (direct):  304ms after FloatBuffer.allocate()    float[]:               249ms    unsafe:                219ms    floatbuffer (direct):  1150ms

UnsafeDemo:

1   2   3   4   5   6   7   8

Array time: 30.98215 ms x array= 1.24908006E9 unsafe time 52.641886 ms x unsafe= 1249216512 Floatbuffer time: 31.53641 ms x array= 1.24949581E9 Directbytebuffer2float time: 101.041054 ms x array= 1.14874189E9

[HamsterofDeath]

the reason for unsafedemo being slower is that i use a "naked" unsafe instance. benchy extracts it from a bytebuffer.
if i use a bytebuffer's Unsafe, unsafe.get/put & arrays are almost equally fast. Unsafe is a bit faster, but you could have trouble avoiding the "base + (index<<bytes_of_type)"-calculation when accessing the buffer. if you can avoid it, Unsafe is the way to go

[Riven]

My implementation avoids it...

[chaosdeathfish]

Does the JVM do bounds-check removal on Buffer types? I know i does on arrays..

[Riven]

1   2   3   4

float[]:               194ms unsafe:                128ms floatbuffer (direct):  147ms <--------- 7.7x faster floatbuffer (float[]): 0ms

As it is faster than float[], I'd be very surprised if it did not remove bound-checks.

[princec]

Only the server VM does bounds check hoisting, AFAIK.

Cas

Games published by our own members! Check 'em out!

[Riven]

Indeed. I run all benchmarks against the server-vm for erm.. performance-reasons

[HamsterofDeath]

Does the JVM do bounds-check removal on Buffer types? I know i does on arrays..

i'd say: no. a bytebuffer's get and put methods are always a bit slower than direct array accesses. (at least the last 10 times i looked at the results)
if i simply call a bytebuffer's private put/get-methods (jdk hack) which don't do bounds checks manually, i'm almost at array speed (50% slower). if i inline the calls and access the unsafe object directly, using (base+(offset<<2)) as the address to get an int, i'm really almost at array speed (up to 10% difference, sometimes faster, sometimes slower, which means it's pretty equal). using any precalucated value as an address speeds things up, and i'm at 200% array speed.
i assume this means:
a) java uses the same calculation to access random values in arrays
b) java doesn't do array bounds checks if the vm can be sure that no evil index will be used.