[squeak-dev] Re: floats

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

2009/3/15 Hans-Martin Mosner <[hidden email]>

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

Nicolas

Thanks to everyone who is contributing to this thread! I should have
been more explicit about my interest in this area: a good floating point
unit is about the same size as a reasonably compact integer core. So for
the same cost I can have twice as many processors if I am willing to
have slow floating point. The worst case would be to have both half as
many processors (with a FPU each) *and* slow floating point anyway due
to Squeak's limitations.

Squeak does have a scheme for good floating point performance: the
FloatArray. In a previous discussion about this with Bryce, he felt that
between this and being about to compile away boxing/unboxing operations
within a single method (also mentioned by Hans-Martin in this thread) we
could have essentially the same performance as immediate floats (and
Hans-Martin pointed out that the bit pattern I suggested is already in
use anyway).

Nicolas evaluated the advantages of the "64 bit everything is a float"
scheme, which I unfortunately don't remember who was the inventor. One
trick that some old mainframes used was to represent integers as
denormalized floating point numbers, so you would need no checks nor
conversions. The IEEE 754 standard doesn't seem to support this,
however.

As Bert pointed out, lack of floating point hardware was the reason
given for not choosing the ARM for the first OLPC machine. Ivan
mentioned fixed point as an alternative, and this is actually what I
have used in my projects (specially the Forth based ones) for most of
the past ten years. But for Squeak I would rather just give people what
they are used to (not counting Fractions, LargeIntegers and such, of
course). Juan gave a list of application domains where floats are
considered fundamental.

Hans-Martin and Claus asked about the availability of 64 bit hardware
for the scheme I mentioned. That is indeed a problem (only my old Sparc
machine would be able to run a 64 bit Squeak of the 14 or so computers I
have around here, for example) but it could be solved by doing some
conversions when saving/loading images. We need to do transformations
when moving between 32 and 64 images anyway and unboxing floats would be
one of the simplest.

-- Jecel

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

Hi Eliot,
AFAIK, VW does not use the nan trick, so it has to perform extra conversions on SmallDouble, doesn't it?

Nicolas

2009/3/16 Eliot Miranda <[hidden email]>

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

2009/3/16 Eliot Miranda <[hidden email]>:

>
>
> On Sun, Mar 15, 2009 at 1:57 PM, Nicolas Cellier
> <[hidden email]> wrote:
>>
>> 2009/3/15 Hans-Martin Mosner <[hidden email]>
>>>
>>> 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.

Couldn't you compress the oops? AFAIK HotSpot was the last remaining
JVM that got this.

Cheers
Philippe

Eliot Miranda wrote:
*snip*

...and SPARC is one of the worst 64-bit implementations out there.
 Question, how much bigger is a 64-bit literal load instruction vs a 32-bit
literal load in x86/x86-64 and SPARC32/SPARC64?

Interesting though off topic tidbit, therefore an OT question: is that aimed at SPARC as a (for lack of better word) architecture or do you have a specific implementation in mind? (*curious*)

On Mar 17, 2009, at 11:47 PM, Eliot Miranda wrote:

Part of my complaint is the name, Scaleable Processor ARCitecture.  The current SPARC requires 6 (reads it and weep, _6_) 32-bit instructions to synthesize an arbitrary 64-bit literal.  It hasn't scaled to 64-bits; consequently there are a range of addressing models in 64-bit SPARC compilers, 20-something-bits 40-something bits (I forget the details) and 64-bits.  By contrast there are 10-byte instructions that do 64-bit literals loads in x86-64.  So a 200% overhead vs a 25% overhead.

It doesn't seem to matter, though, for C/C++/Fortran programs.  In those benchmarks where SPARC is slower in 64-bit mode than 32-bit mode, the slowdown is due to the benchmark's data structures being larger because of 64-bit pointers.  Loading a 64 bit literal is ugly, but so what?

Is there some reason why Smalltalk would need to do more loads of 64 bit literals than C/C++/Fortran?

Iain

2009/3/16 Eliot Miranda <[hidden email]>:
>
>
> On Mon, Mar 16, 2009 at 2:15 PM, Philippe Marschall
> <[hidden email]> wrote:
>>
>> 2009/3/16 Eliot Miranda <[hidden email]>:
>> >
>> >
>> > On Sun, Mar 15, 2009 at 1:57 PM, Nicolas Cellier
>> > <[hidden email]> wrote:
>> >>
>> >> 2009/3/15 Hans-Martin Mosner <[hidden email]>
>> >>>
>> >>> 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.
>>
>> Couldn't you compress the oops? AFAIK HotSpot was the last remaining
>> JVM that got this.
>
> I don't see the point.  Memory is cheap, getting cheaper.

But memory access isn't.

> 64-bits means
> extremely cheap address space.  Why slow down the critical path to save
> space?

Because it's faster (because you have to move around fewer data) an
gets you closer to 32bit speed.

http://wikis.sun.com/display/HotSpotInternals/CompressedOops
http://blog.juma.me.uk/2008/10/14/32-bit-or-64-bit-jvm-how-about-a-hybrid/#comments
http://www.lowtek.ca/roo/2008/java-performance-in-64bit-land/
http://www.devwebsphere.com/devwebsphere/2008/10/websphere-nd-70.html
http://webspherecommunity.blogspot.com/2008/10/64-bit-performance-thoughputmemory.html

Cheers
Philippe