[Q] Project: Better performance for LargeIntegers

Stephan Rudlof stephan.rudlof at ipk.fhg.de
Sat Oct 30 09:29:20 UTC 1999


> 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.

> 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!

> 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;
- I see a chance for me to be successful in not so long time;
- I'm learning much about calling C-routines from Squeak, what can be useful
for more specialized purposes, too.


Stephan





More information about the Squeak-dev mailing list