[squeak-dev] Re: floats

Eliot Miranda eliot.miranda at gmail.com
Mon Mar 16 17:37:45 UTC 2009


On Sun, Mar 15, 2009 at 1:57 PM, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 2009/3/15 Hans-Martin Mosner <hmm at heeg.de>
>
> nicolas cellier schrieb:
>> > Hans,
>> > Tagging/untagging could be very fast! See my other post
>> >
>> > 1) UnTagging a double= No op
>> > 2) Tagging a double= a isnan test (so as to have a representable nan
>> > in Smalltalk)
>> > 3) This trick does not had any extra cost to tagging/untagging of
>> > other oops
>> That's true for a 64-bit processor, and on such hardware I see the
>> advantages of this scheme.
>> For 32-bit hardware, it won't work.
>> Hopefully we'll all have suitable hardware in the near future...
>> But for example, I'm running 32-bit linux here on my 64-bit AMD
>> processor just because the WLAN card I'm using only has a 32-bit Windows
>> driver, and ndiswrapper on 64-bit linux would require a 64-bit driver to
>> work correctly (which is somewhat stupid IMHO but I'm not going to hack
>> ndiswrapper).
>> In the real world, there are tons of silly constraints like this which
>> still prevent people from fully using 64-bit hardware.
>>
>> Cheers,
>> Hans-Martin
>>
>
> Of course, most of the nice properties come from the 64 bits adressing...
> Hey, wait, I don't even have a 64 processor in my house!
> For the fun I imagine we could emulate by spanning each oop over two int32
> typedef struct {int32 high,low;} oop;
> I would expect a slower VM by roughly a factor 2 - except for double
> arithmetic...
>

In theory, but only for memory-limited symbolic applications.  If you have
an application that fits entirely in cache then I would expect parity.  The
argument for symbolic applications is that a 64-bit symbolic app has to move
twice the data as a 32-bit symbolic app because each symbolic object is
twice the size.

Many Smalltalk applications are large and hence more in the memory-limited
range, but many Smalltalk objects are byte data and so a) they are not
moving twice the data all the time and b) images do not double in size.
 There are also opportunities for optimization in a 64-bit implementation.
 In particular in 64-bit VW/HPS I was able to store the number of fixed
fields in an object in its header instead of only in the class format word.
 Hence 64-bit HPS has much faster at:[put:] than 32-bit.

So the experience with my 64-bit VW implementation was that
    - typical large symbolic benchmarks (e.g. all senders) were 15% to 20%
slower in 64-bits than in 32-bits.
    - immediate double arithmetic is about 3 times faster at about half the
speed of immediate integer operations
    - images are about 55% larger when converted from 32-bit to 64-bit


Eliot


>
> Nicolas
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090316/e9a9bd88/attachment.htm


More information about the Squeak-dev mailing list