[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeak-dev
Subject:    Re: [squeak-dev] To a terabyte and... beyond
From:       "David T. Lewis" <lewis () mail ! msen ! com>
Date:       2010-10-30 21:33:37
Message-ID: 20101030213337.GA57833 () shell ! msen ! com
[Download RAW message or body]

(cc squeak-dev per Bert's suggestion)

Hi Dan,

Indeed it is "#define SQ_VI_BYTES_PER_WORD 8". This macro
is the one used in sqMemoryAccess.h, so BYTES_PER_WORD and
BASE_HEADER_SIZE are set from SQ_VI_BYTES_PER_WORD. It turned
out that it is possible to rearrange some class and instance
variables in ObjectMemory and Intepreter such that the generated
C code is the same for 32 and 64 bit object memory, controlled
at compile time by the SQ_VI_BYTES_PER_WORD macro. I'm afraid
it makes the Smalltalk source less readable, but it's nice
not to need to generate different sets of C sources for src32
and src64.

I should mention that recent versions of VMMaker can no longer
be loaded into a Squeak 3.8 image, primarily due to the use of
pragmas, e.g. "<inline: true>" rather than "self inline: true",
which in turn means that at the moment one cannot genererate a
current VM from the Squeak 3.8 based 64-bit image. I will have
a bit of time to play with this on Tuesday, so I'll see if I can
find a way to either load current VMMaker into the 3.8 image,
or to trace an up-to-date Squeak 4.1 image to 64 bits. I'll let
you know before Wednesday if I have made any progress.

Dave

On Fri, Oct 29, 2010 at 10:40:39PM -0700, Dan Ingalls wrote:
> Hi David -
> 
> Thanks for the pointers.  I'm assuming you meant BYTES_PER_WORD 8, right?
> Do let me know if you gather more infor in the next few days.  I think I'm not \
> going to have a chance at this until after next Wed. 
> All the best
> 	- Dan
> ---------------------------------------
> > On Fri, Oct 29, 2010 at 09:48:11AM +0200, Bert Freudenberg wrote:
> > > On 29.10.2010, at 06:25, Dan Ingalls wrote:
> > > 
> > > > Hi Guys ;-)
> > > > 
> > > > Anyone have experience with running super huge Squeaks?  I have the chance to \
> > > > use an absurdly big machine.  I'd appreciate advice (offline unless you think \
> > > > it would be generally useful) regarding the relative stability of, say, linux \
> > > > and windoze builds of 64-bit Squeaks known (or thought) to run with over a \
> > > > terabyte of objects, and also where there may be some pre-built 64-bit images \
> > > > (sorry if this is in an obvious place).  Finally (since I've mainly used a \
> > > > Mac for Squeak) I guess I'll have to know how to tell it how big to be, or \
> > > > would it grow gracefully if I just said "(String new: 1000000000000) size" in \
> > > > a normal image? 
> > > > Thanks
> > > > 
> > > > 	- Dan
> > > 
> > > Dave Lewis has been working on 64 bit stuff, he surely will respond (and please \
> > > keep responses on list, this is rather interesting). A recent image is here: 
> > > 	http://squeakvm.org/squeak64/sq64-dtl.zip
> > > 
> > > I think there isn't even much experience with a Gigabyte-sized image ...
> > 
> > Hi Dan,
> > 
> > The image that Bert mentions is an updated version of your original
> > 64-bit image, suitable for running on a current Squeak VM. I have
> > not tried tracing the latest Squeak trunk image (sounds like a good
> > project for this weekend though :)
> > 
> > The quickest way to get a VM running is to start with an up to
> > date Squeak image, load latest VMMaker from www.squeaksource.com/VMMaker
> > and platform sources from Subversion. The "64-bit VM" button is
> > gone from the VMMaker tool, all that is needed to build the 64 bit
> > version is to set a macro either in ./build/config.h or in
> > ./src/vm/interp.h:
> > 
> > #define SQ_VI_BYTES_PER_WORD 4
> > 
> > I use Linux for running this stuff, so I can't speak to Windows or
> > OS X. On a unix platform, if you evaluate "(String new: 1000000000000) size"
> > in sq64-dtl.image, you will get a low space notifier. I remember adding
> > some checks to the VM to prevent address overflows for allocations
> > that are "unreasonably large), and I think this notifier reflects
> > hitting that limit (sorry I can't recall the details, I'll check later).
> > It would be fun to see how big "unreasonably large" could be though :)
> > 
> > A gigabyte is no problem though. The following succeeds on a
> > 64-bit image:
> > 
> > (String new: 1000000000) size ==> 1000000000
> > 
> > For allocation requests that are within the current VM limits,
> > what you can expect to see on a unix box is that your VM will
> > cheerfully keep allocating memory from the OS until your system
> > starts swapping pages to disk, at which point everything on the
> > system slows to a crawl. It will be interesting to see what happens
> > on a really big box with lots of memory.
> > 
> > Dave


[prev in list] [next in list] [prev in thread] [next in thread]