OK, my current implementation for integers [int Erjang] is
class EInteger extends ENumber { ... }
class ESmall extends EInteger { int value; }
class EBig extends EInteger { BigInteger value; }
With this, I run the bench_tak at
MacOSX 16.3-b01-279 -server 385ms/loop
soylatte16-i386-1.0.3 -server 500ms/loop
I tried to implement your data structure, ...
class EInteger extends ENumber { int ival; BigInteger bival; ... }
MacOSX 16.3-b01-279 -server 485ms/loop
soylatte16-i386-1.0.3 -server 497ms/loop (-XX:+DoEscapeAnalysis)
soylatte16-i386-1.0.3 -server 606ms/loop (-XX:-DoEscapeAnalysis)
With escape analysis it runs more stable, i.e. it looks like there is
much less GC going on.
Kresten
Erlang test code looks like this
-----------------------------------------------------------
tak(X,Y,Z) when Y >= X ->
Z;
tak(X,Y,Z) ->
tak( tak(X-1, Y, Z),
tak(Y-1, Z, X),
tak(Z-1, X, Y) ).
main(N) ->
Body = fun() ->
Before = erlang:now(),
times(10, fun() -> tak(24,16,8) end),
After = erlang:now(),
Diff = timer:now_diff(After, Before),
io:format("run: ~pms~n", [Diff div 1000])
end,
timer:tc(?MODULE, times, [N, Body]).
-----------------------------------------------------------
So I tried to re-do it with essentially your
On May 29, 5:15 am, Per Bothner <[email protected]> wrote:
> On 05/28/2010 03:24 AM, Kresten Krab Thorup wrote:
>
>
>
>
>
>
>
> > On May 27, 1:17 am, Per Bothner<[email protected]> wrote:
> >> This is another example of where structs would be helpful. That would
> >> allow:
>
> >> struct Integer {
> >> int ivalue;
> >> int[] iwords;
>
> >> }
> > ....
>
> >> Kawa basically does this using a regular class gnu.math.Integer,
> >> and "small" Integers pre-allocated. That is one reason Kawa's
> >> arbitrary-precision handling is (mostly) noticeably faster than BigInteger.
> >> (Some of that could be achieved by further tweaking BigInteger.)
>
> > 1: I'm intrigued. How much does this give you?
>
> I don't have numbers convenient, but even with the current JVM (i.e.
> no "struct" support) the big advantage is that in most cases you
> don't allocate a "data" array, as long as the integer fits in 32 bits.
> That same you a lot of memory and gc time. It means you have to explicitly
> check for the immediate vs array modes (i.e. words==null or not), but
> once determined you have a 32-bit number the actual work is quick,
> and requires fewer memory accesses (and hence cache misses).
>
> BigInteger could (and perhaps should) do the same optimization.
> But BigInteger has a some further overheads, including some
> seldomly-used fields.
>
> > I can see that you avoid a virtual call for all math operators where
> > you can determine the integer-ness of operands; so it does not have to
> > choose between SmallInt and BigInt objects. But it comes at the
> > overhead of an extra word per integer.
>
> Right, but that is modest compared to the space used by BigInteger.
>
>
>
>
>
> > Integer arithmetic (most notably X+1, X-1, and X==<constant>) used in
> > loops is currently a noticeable performance issue in Erjang (when
> > comparing to the normal erlang implementation using tags). In many
> > such cases, I could avoid a virtual call and that does sound
> > appealing.
>
> > 2: What is the motivation in Kawa to make your own bignum
> > implementation. Why not just have
>
> > class KawaInteger {
> > int ival;
> > BigInteger bval;
>
> > ...
> > }
>
> > i.e., fall back on the standard bignum implementation?
>
> That was not an option at the time: gnu.math.IntNum was implemented
> before java.math.BigInteger was available. If I started from scratch
> that would probably have made sense to do what you're suggesting. But
> since the current implementation is faster and more space efficient
> than using BigInteger I don't see much point in ripping it out.
>
> You're free to use gnu.math.IntNum (and gnu.math in general); it has
> no dependencies on the rest of Kawa.
> --
> --Per Bothner
> [email protected] http://per.bothner.com/
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
