64 bit VM, source anyone?

> Right now I use the binary i386 VM from ftp.squeak.org/debian, it  
> seems
> to work but looks slowish to me (tinyBenchmarks):
>
> 295 million bytecods/sec
> 9.5 million sends/sec
>
> And regardless of that it seems reasonable to at least use a 64 bit  
> VM.
> :)

> On Dec 4, 2007, at 18:56 , [hidden email] wrote:
>
> > Right now I use the binary i386 VM from ftp.squeak.org/debian, it  
> > seems
> > to work but looks slowish to me (tinyBenchmarks):
> >
> > 295 million bytecods/sec
> > 9.5 million sends/sec
> >
> > And regardless of that it seems reasonable to at least use a 64 bit  
> > VM.
> > :)
>  
> For one, try to not think with your gut ;)

> On Dec 5, 2007 10:23 AM, <[hidden email]> wrote:
> > PS. The reason I said "slowish" is that... well, it is definitely not
> > much faster than my Pentium-M laptop. But after talking on IRC it became
> > clear that those numbers may very well be the expected.
>
> Why would a 64-bit VM be slower?
>
> Would it be because it's moving twice as much memory around, or because it's
> fiddling with 32-bit pointers using 64-bit registers?
>
> Gulik.

> On Tue, Dec 04, 2007 at 07:56:54PM +0200, [hidden email] wrote:
> > Ok, so I was stupid enough to pick Debian Etch 64 bit when configuring
> > my last server. I knew it would bite me :) and here I am confused about
> > where to find a 64 bit VM to compile.
> >
> > AFAIK lots of small patches have been flying around lately, but where
> > can I find a tar ball that has most of those? David, could you perhaps
> > create one?
>
> Here is my current recipe:
>
> 1) Load VMMaker from SqueakMap.
>
> 2) Load the 32/64 bit-clean change sets. Presumably these will be merged into
> VMMaker, but in the mean time John has stashed them in the SVN platform
> sources. Go to platforms/Mac OS/vm/specialChangeSets/VmUpdates-dtl/ and
> load the following change sets:
>         VmUpdates-1001-dtl.1.cs
>         VmUpdates-1002-dtl.1.cs
>         VmUpdates-1003-dtl.1.cs
>         VmUpdates-1004-dtl.1.cs
>         VmUpdates-1005-dtl.1.cs
>         VmUpdates-1006-dtl.1.cs
>         JMM-VmUpdates32bitclean.2.cs
>
> 3) Load the fix from Mantis 5688 (otherwise you cannot use SqueakMap):
>         http://bugs.squeak.org/view.php?id=5688
>
> 4) Load the fix from Mantis 5238 (needed only for 64 bit image, but you
> may as well fix it while you're updating the rest):
>         http://bugs.squeak.org/view.php?id=5238
>
> 5) Load the fix from Mantix 5403 (you don't need this, but I do):
>         http://bugs.squeak.org/view.php?id=5403
>
> 6) Load SlangBrowser (you don't need it, but you'll want it if you are
> going to look at the VM and plugin code):
>         http://bugs.squeak.org/view.php?id=5932
>         http://wiki.squeak.org/squeak/5916
>
> 7) Load the 32/64 bit updates for AsyncFilePlugin:
>         http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001675.html
>
> 8) Load the 32/64 bit updates for FileCopyPlugin:
>         http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001679.html
>
> 9) Load the 32/64 bit updates for LargeIntegersPlugin (unit tests only, the
> plugin is good as long as you have installed the Mantis 5238 patch from step 4):
>         http://lists.squeakfoundation.org/pipermail/vm-dev/2007-November/001693.html
>
> That's all for now,

>
> Hi!
>
> "Michael van der Gulik" <[hidden email]> wrote:
> > On Dec 5, 2007 10:23 AM, <[hidden email]> wrote:
> > > PS. The reason I said "slowish" is that... well, it is definitely not
> > > much faster than my Pentium-M laptop. But after talking on IRC it became
> > > clear that those numbers may very well be the expected.
> >
> > Why would a 64-bit VM be slower?
> >
> > Would it be because it's moving twice as much memory around, or because it's
> > fiddling with 32-bit pointers using 64-bit registers?
> >
> > Gulik.
>
> Ok, some clarifications:
>
> 1. My numbers were for the 32-bit binary VM, not a 64 bit VM.
>
> 2. There are reasons going both ways regarding speed. On the AMD64
> architecture (see some details here: http://www.debian.org/ports/amd64)
> there is potential for higher speed through better abilities for the
> compiler BUT... there are also things slowing it down (8 bytes instead
> of 4 in lots of situations). Also, I don't know how/if the gnuifier is
> affected by this (perhaps not).
>
> As Phillipe's post suggests - the 32 bit VM is actually a tad faster on
> his box. It might be interesting to know if he has toyed with
> optimization flags.

> > I am considering creating two Mercurial repos:
> >
> > - One mirroring Ian's SVN.
> > - One that I push all the above into and make available for write to
> > people asking. :)
> > - And a VMMaker repo.
>
> I don't know anything about Mercurial, but IMHO the only real
> missing piece is that it would be helpful to get a copy of the
> VMMaker Montecello files copied over to a SqueakSource repository.

> > Why? Because:
> >
> > 1. I would like to see if that works technically.
> > 2. I would like to see if there is enough interest from others in a more
> > distributed and open "experimental" approach to maintaining the VM.
>
> It would be an interesting experiment, but speaking just for myself
> I'm more interested in making best use of existing resources (people
> plus tools) and I really do not have enough free time to keep track
> of more development repositories.

> Great, thank you! Now for some stupid questions:
>
> - You use this recipe together with the current trunk in SVN or?
> - ...eh, ok, perhaps that was my only question. :)
>
> I am considering creating two Mercurial repos:
>
> - One mirroring Ian's SVN.
> - One that I push all the above into and make available for write to
> people asking. :)
> - And a VMMaker repo.
>
> Why? Because:
>
> 1. I would like to see if that works technically.
> 2. I would like to see if there is enough interest from others in a more
> distributed and open "experimental" approach to maintaining the VM.
>
>  
>> Dave
>>    
>
> regards, Göran
>
>  

> On Wed, Dec 05, 2007 at 10:26:44AM +0200, [hidden email] wrote:
>> I am considering creating two Mercurial repos:
>>
>> - One mirroring Ian's SVN.
>> - One that I push all the above into and make available for write to
>> people asking. :)
>> - And a VMMaker repo.
>
> I don't know anything about Mercurial, but IMHO the only real
> missing piece is that it would be helpful to get a copy of the
> VMMaker Montecello files copied over to a SqueakSource repository.
> That's not a tools problem, it's just a matter of convincing Tim
> to do it.

>> Why? Because:
>>
>> 1. I would like to see if that works technically.
>> 2. I would like to see if there is enough interest from others in  
>> a more
>> distributed and open "experimental" approach to maintaining the VM.
>
> It would be an interesting experiment, but speaking just for myself
> I'm more interested in making best use of existing resources (people
> plus tools) and I really do not have enough free time to keep track
> of more development repositories. Shucks, I can't even keep up with
> all the different Squeak images, never mind tracking any more VM
> projects ;)

> It's unbelievably hard to reproduce an official VM from first  
> principles, let alone doing serious VM development on your own in a  
> way that can be easily integrated back into the main line by the  
> maintainers. We must find a way that lets them evaluate and integrate  
> proposed changes without much effort. The current setup requires too  
> much energy on both maintainers and developers, leading to stagnation.
>
> The official maintainers carry a great responsibility, if something  
> breaks, *they* are going to get blamed. So they are conservative, for  
> a good reason. Other developers are maintaining their own VMs,  
> without being able to effectively share. A de-centralized environment  
> with a pull model a la Mercurial or git could help this a lot, as it  
> allows independent development as well as easy cherry-picking for the  
> official versions.