[Q] Project: Better performance for LargeIntegers

Stephan Rudlof stephan.rudlof at ipk.fhg.de
Mon Nov 1 21:02:21 UTC 1999


> -----Original Message-----
> From: Andrew C. Greenberg [mailto:werdna at gate.net]
> Sent: Samstag, 30. Oktober 1999 15:48
> To: squeak at cs.uiuc.edu
> Subject: RE: [Q] Project: Better performance for LargeIntegers
>
>
> > > I think building a plugin instead, particularly because a great deal
> > > of the existing code in the image can be appropriated (the preamble
> > > code needs fixing, but the rest probably can be made to work) is
> > > probably not too difficult, certainly for the innermost loops.  A
> > > profile shows that for reasonably large numbers 90-98% is presently
> > > spent inside the innermost routines.
> > >
> > > Thus, a plugin could in theory be built (without too much sweat) that
> > > wouldn't slow up the status quo much at all, and would run much
> > > faster with a plugin installed.
> >
> >Why not to use primitives? There are some free numbers (20-39) for this
> >purpose and if it's faster then everybody will want it. And I
> don't see any
> >image or sources size problem for these additions.
>
> Absolutely correct concerning image and source space.  And primitive
> number space is not an issue.  We are talking VM footprint.

That's correct.

> Right
> now, others are pluginizing many existing VM primitives so as to
> reduce space, not because they are not useful, but because not
> everyone uses them all the time and VM size seems a concern for some
> applications.
>
> Is it so clear that everyone will want to make the space-speed
> tradeoff that a VM change would require?  For many long integer
> performance is satisfactory, and even impressive.  (My only uses were
> to compute certain odds for my daughter relating to her Pokemon card
> game, lottery odds and the occasional "factorial" demo, and of
> course, behind the scenes intermediate computations from SmallInts
> that I hadn't noticed when doing 32-bit operations)
>
> Footprint of the VM on PDA's is precious for some.  Doing it as a
> plugin (almost the same mechanism, by the way) permits those who want
> it to plugin and those who don't to pass.

I agree with the goal that not everything should be implemented as a
primitive. But for LargeInteger arithmetic there are some primitive numbers
free for just that case (though probably for smaller LargeInts in previous
Smalltalks) and we are dealing with a very fundamental data type here.
In addition we would have a - very moderate - bigger VM, but at the same
time a _smaller_ image! Some methods are moved to the primitives then. So I
don't see the advantage of parallelizing the computations in methods and
Plugins.

> > > But we don't need to wait for CS, certainly for the simple
> > > undertaking to pluginize inner code for the private longInt routines
> > > for Number, if only to take the profiles to see if that is enough to
> > > make a real difference.
> >
> >I wanted to know if anybody just works on this additions to avoid
> >superfluous work and to strenghten my motivation!
>
> I had actually done this for addition (by far the easiest operation)
> when testing the new plugin compiler.  If I can find it, I'd be happy
> to send it along.

Would be very interesting for me, but first I have to install Squeak onto my
new Laptop at home with a fresh Linux ;-)

>
> > > Of course, we could just write pluggable primitive code for each
> > > primitive directly (since they presently all just fail right now)
> > > without meaningful cost (although it would likely require some
> > > fiddling with Number and some of the coercion code to make
> > > SmallInteger + Large---Integer work fast.  But why do all that just
> > > now?
> >
> >My opinion:
> >- it's worthable for many people because doing that improves fundamental
> >data types;
>
> Speed performance only -- functionality should remain identical.
> There is a need for more speed only for certain applications (like
> crypto).

--> But speed also doesn't hurt!

>
> >- I see a chance for me to be successful in not so long time;
>
> True of both approaches.  (I believe that you will find the plugin
> route a faster path.)

I don't know, but I thank you for the hint. At first it didn't seem to be
easier to understand for me than the primitive approach, but I did ignore
the compile times (see other mails)...

> >- I'm learning much about calling C-routines from Squeak, what
> can be useful
> >for more specialized purposes, too.
>
> Also true of both approaches.
>
>





More information about the Squeak-dev mailing list