I am pretty much code complete on switching the Java runtime to use primitives for Bool, Int, and Float. I haven't done a lot of testing, but I just did a quick benchmark to compute Fibonacci to 40:
Fan 1.0.33 (old) 21.6sec
Fan 1.0.34 (new) 2.4sec
Java (using longs) 2.2sec
Primitives obviously have a huge effect on numeric performance versus keeping everything boxed. And we are pretty darn close to raw Java performance. I'm still routing operators to static methods and letting HotSpot inline for me. I suspect if we have the Java emitter more aggressively do those inlines itself then we can close the performance gap almost entirely.
andySun 16 Nov 2008
I've done the bulk of the work to convert the .NET runtime to use primitives for Bool, Int, and Float. There is still a bit of work todo till I'm synced to tip and can push my changes, but I thought I'd note the performance numbers I'm seeing:
Fan 1.0.32 (old) 25.6sec
Fan dev (new) 12.5sec
C# (using longs) 3.8sec
I know .NET is generally slower than Java, but I expected the changes to at least be linear to Java's.
brian Fri 24 Oct 2008
I am pretty much code complete on switching the Java runtime to use primitives for Bool, Int, and Float. I haven't done a lot of testing, but I just did a quick benchmark to compute Fibonacci to 40:
Primitives obviously have a huge effect on numeric performance versus keeping everything boxed. And we are pretty darn close to raw Java performance. I'm still routing operators to static methods and letting HotSpot inline for me. I suspect if we have the Java emitter more aggressively do those inlines itself then we can close the performance gap almost entirely.
andy Sun 16 Nov 2008
I've done the bulk of the work to convert the .NET runtime to use primitives for Bool, Int, and Float. There is still a bit of work todo till I'm synced to tip and can push my changes, but I thought I'd note the performance numbers I'm seeing:
I know .NET is generally slower than Java, but I expected the changes to at least be linear to Java's.