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. 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.
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.
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).
- 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'm learning much about calling C-routines from Squeak, what can be useful
for more specialized purposes, too.
Also true of both approaches.