Hi Philipe,

On Mon, Mar 16, 2009 at 10:52 PM, Philippe Marschall <
philippe.marschall at gmail.com> wrote:

> 2009/3/16 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> > On Mon, Mar 16, 2009 at 2:15 PM, Philippe Marschall
> > <philippe.marschall at gmail.com> wrote:
> >>
> >> 2009/3/16 Eliot Miranda <eliot.miranda at gmail.com>:
> >> >
> >> >
> >> > 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.
> >>
> >> 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
>

OK, and this is a reasonable stop-gap until machines catch up with the
potential of the 64-bit address space.  It reminds me of segmented
approaches to 16-bit limits on PDP-11s, 8086s et al.  Basically these guys
are scaling 32-bit oops by 8, allowing a maximum heap size of 32Gb and 4G
small objects.  There are other approaches like using an indirection table
for intra-segment object references and using 32-bit oops within a segment,
which would fit well with a Train algorithm.

My gut feels like these stop gaps are a temporary thing.  After all if speed
was so compelling we'd see lots of small 16-bit apps in places like Windows
where there used to be good support for 16-bit code until quite recently.
 But in fact 16-bit apps have died the death and we favour the regularity of
32-bit code.  Somewhat analogously Smalltalk trades perofrmance for
regularity.  So I don't find these approaches particularly compelling.  In
any case they require engineering teams that can afford to support multiple
memory models in the VM, something I'm not going to assume in Cog :)

Thanks for the links.

Best
Eliot


> Cheers
> Philippe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090319/5210d3be/attachment.htm