> At 23:13 +0100 98/09/13, Simon Marlow wrote:
> >The plan is to use something like
> >
> > data Integer = Small Int# | Big { ... }
> The real difficulty to upper the Integer/Int ratio of 4.5 for integers
> fitting into a word is to minimize those overflow checks. So this part
> should be written in assembler, I think.
>
> I can mention that an idea for C++ I have is to write
> class Integer {
> int low; // The length for large integers.
> int* high; // 0 for small integrers.
> public:
> ...
> };
> One then ends up with the same overflow checks as above, but on the same
> time ensures that dynamic memory allocation is not used for small integers
> and that integers are packed efficiently.
It might be worthy to point out that the both ideas have been
implemented in Smalltalk for ages. Plus "double dispatching" for
mixed type arithmetic. Maybe it is worthy to glance under the hoods
of some of their virtual machines to learn something? Apparently
they had the same problem to cope with many years ago when they
decided on this and other highly criticised features then, but
generally accepted now?
Ingeneous garbage collector with cache for most recently
executed native code (called JIT compiler in Java now?), bytecode,
virtual machine, mixed type arithmetic?
One of the myths was that Smalltalk was notoriously slow for
math. I checked this last time four years ago in a context
of comparative tests between Smalltalk and Eiffel interpreter
(not compiler though!). To my surprise old-fashioned V286
(16 bit Digitalk's implementation for DOS) Smalltalk was faster
everywhere but in the straight "Int OP Int" arithmetic. Faster
for Int * Float, for example.
Time spent in Eiffel interpreter to convert Int to Float and
then multiply Float by Float was long enough to give some edge to
Smalltalk.
Obviously, the story would be different for Eiffel compiler,
where those casts take place at the compile time, but this
lesson still has some sense in the context of Hugs, hasn't it?
And then more modern ParcPlace implementation was significantly
faster than Digitalk's. I guess, partially because of the
native code cache. So there is a room for some optimizations
and improvements.
But straight Int arithmetic in Eiffel relied on C compiler, and
therefore 2^31 + 2^31 would give the notorious answer 0, not 2^32!
The same sickness as in Haskell, but with all the accompanying
claims about the safety of code.
BTW, everything in Smalltalk is an object, even SmallInteger.
But Smalltalk distinguishes between SmallIntegers and other
objects, such as LargePositiveInteger, by examining the bit next
to the sign bit, so no dynamic allocation takes place for
SmallIntegers. But since one extra bit is wasted, SmallIntegers
are shorter than Ints in other implementations.
Jan
