Smalltalk › Squeak › Squeak - Dev

[4.2] - VM <-> image release coordination

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Chris Muller-3

[4.2] - VM <-> image release coordination

Levente wrote:

> I think we should wait for the new VMs, before releasing the new images.

Hi Levente,

I did agree, but now that Eliot is on a tear with a new code
generator, the first official release might still be some weeks away.
Someone please correct me if that is a misstatement.

It seems unlikely 4.2 will be incompatible with whatever ends up being
the first official Cog release. We should consider pushing it out the
door so we can re-open the trunk to new featurey.

- Chris

David T. Lewis

Re: [4.2] - VM <-> image release coordination

On Sun, Jan 02, 2011 at 09:56:51PM -0600, Chris Muller wrote:

> Levente wrote:
>
> > I think we should wait for the new VMs, before releasing the new images.
>
> Hi Levente,
>
> I did agree, but now that Eliot is on a tear with a new code
> generator, the first official release might still be some weeks away.
> Someone please correct me if that is a misstatement.
>
> It seems unlikely 4.2 will be incompatible with whatever ends up being
> the first official Cog release. We should consider pushing it out the
> door so we can re-open the trunk to new featurey.
>
> - Chris

I agree, we should move forward with the 4.2 release. There should
be no hard dependencies between VM and image for a first time user
downloading Squeak, or for someone with an existing VM installed
who is downloading the new Squeak 4.2 image. In practical terms
that simply means making sure the release image was saved from a
standard VM immediately prior to the release.

Dave

Levente Uzonyi-2

Re: [4.2] - VM <-> image release coordination

In reply to this post by Chris Muller-3

Quoting Chris Muller <[hidden email]>:

> Levente wrote:
>
>> I think we should wait for the new VMs, before releasing the new images.
>
> Hi Levente,
>
> I did agree, but now that Eliot is on a tear with a new code
> generator, the first official release might still be some weeks away.
> Someone please correct me if that is a misstatement.
>
> It seems unlikely 4.2 will be incompatible with whatever ends up being
> the first official Cog release. We should consider pushing it out the
> door so we can re-open the trunk to new featurey.

That's right, Cog's recent improvements introduced some instability.
So I think we should release Squeak 4.2 with SqueakVM only and
postpone the multi-VM release. We can also make the release cycle of
Squeak 4.3 shorter to catch up with the two release per year policy
and deliver the VM improvements earlier. I'm also sure that a lot of
improvements will be done till April/May on both image and VM side.

Levente

>
> - Chris
>
>

Eliot Miranda-2

Re: [4.2] - VM <-> image release coordination

On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:

Quoting Chris Muller <[hidden email]>:

Levente wrote:

I think we should wait for the new VMs, before releasing the new images.

Hi Levente,

I did agree, but now that Eliot is on a tear with a new code
generator, the first official release might still be some weeks away.
Someone please correct me if that is a misstatement.

It seems unlikely 4.2 will be incompatible with whatever ends up being
the first official Cog release. We should consider pushing it out the
door so we can re-open the trunk to new featurey.

That's right, Cog's recent improvements introduced some instability. So I think we should release Squeak 4.2 with SqueakVM only and postpone the multi-VM release. We can also make the release cycle of Squeak 4.3 shorter to catch up with the two release per year policy and deliver the VM improvements earlier. I'm also sure that a lot of improvements will be done till April/May on both image and VM side.

It would be my preference to release with the Cog VM using the naive SimpleStackBasedCogit code generator. After all that's worth at least 3x over the standard VM whereas the unstable StackToregisterMappingCogit is only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to generate either; the two coexist in the same VMMaker.

best

Eliot

Levente

- Chris

Chris Muller-3

Re: [4.2] - VM <-> image release coordination

Excellent, thanks Eliot. That's been the plan for 4.2 all along, I
see no reason to abandon that now.

I am currently trying to get a 4.2 RC1 built and saved under some
interpreter VM. I will need access or assistance for uploading it to
ftp.squeak.org (preferably access, since I'd like to build the image
myself).

Then, I would like to have just under 4 more weeks, until 11:59pm,
1/30/2011, for "last call" for 4.2. We've been testing for some time
now, we seem to have a stable, worthy release. Throughout January, we
will need to test (and fix) on all platforms, document, improve
aesthetics, and update web-sites.

We will push the final release out the week of 1/31.

VM Release Manager: Does this time-frame seem doable for a final
release of the simple-stack VM?

- Chris

On Mon, Jan 3, 2011 at 1:53 PM, Eliot Miranda <[hidden email]> wrote:

>
>
> On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>> Quoting Chris Muller <[hidden email]>:
>>
>>> Levente wrote:
>>>
>>>> I think we should wait for the new VMs, before releasing the new images.
>>>
>>> Hi Levente,
>>>
>>> I did agree, but now that Eliot is on a tear with a new code
>>> generator, the first official release might still be some weeks away.
>>> Someone please correct me if that is a misstatement.
>>>
>>> It seems unlikely 4.2 will be incompatible with whatever ends up being
>>> the first official Cog release. We should consider pushing it out the
>>> door so we can re-open the trunk to new featurey.
>>
>> That's right, Cog's recent improvements introduced some instability. So I
>> think we should release Squeak 4.2 with SqueakVM only and postpone the
>> multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
>> to catch up with the two release per year policy and deliver the VM
>> improvements earlier. I'm also sure that a lot of improvements will be done
>> till April/May on both image and VM side.
>
> It would be my preference to release with the Cog VM using the naive
> SimpleStackBasedCogit code generator. After all that's worth at least 3x
> over the standard VM whereas the unstable StackToregisterMappingCogit is
> only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
> generate either; the two coexist in the same VMMaker.
> best
> Eliot
>>
>>
>> Levente
>>
>>>
>>> - Chris
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>

David T. Lewis

Re: [4.2] - VM <-> image release coordination

On Mon, Jan 03, 2011 at 02:14:56PM -0600, Chris Muller wrote:

> Excellent, thanks Eliot. That's been the plan for 4.2 all along, I
> see no reason to abandon that now.
>
> I am currently trying to get a 4.2 RC1 built and saved under some
> interpreter VM. I will need access or assistance for uploading it to
> ftp.squeak.org (preferably access, since I'd like to build the image
> myself).
>
> Then, I would like to have just under 4 more weeks, until 11:59pm,
> 1/30/2011, for "last call" for 4.2. We've been testing for some time
> now, we seem to have a stable, worthy release. Throughout January, we
> will need to test (and fix) on all platforms, document, improve
> aesthetics, and update web-sites.
>
> We will push the final release out the week of 1/31.
>
> VM Release Manager: Does this time-frame seem doable for a final
> release of the simple-stack VM?
>
> - Chris

Well I should not speak for Eliot r.e. Cog, but he has been releasing
reliable, field-tested Cog VMs for some time now, so planning to have
updated VMs for end of January seems perfectly reasonable to me.

Dave

>
> On Mon, Jan 3, 2011 at 1:53 PM, Eliot Miranda <[hidden email]> wrote:
> >
> >
> > On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
> >>
> >> Quoting Chris Muller <[hidden email]>:
> >>
> >>> Levente wrote:
> >>>
> >>>> I think we should wait for the new VMs, before releasing the new images.
> >>>
> >>> Hi Levente,
> >>>
> >>> I did agree, but now that Eliot is on a tear with a new code
> >>> generator, the first official release might still be some weeks away.
> >>> Someone please correct me if that is a misstatement.
> >>>
> >>> It seems unlikely 4.2 will be incompatible with whatever ends up being
> >>> the first official Cog release. ??We should consider pushing it out the
> >>> door so we can re-open the trunk to new featurey.
> >>
> >> That's right, Cog's recent improvements introduced some instability. So I
> >> think we should release Squeak 4.2 with SqueakVM only and postpone the
> >> multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
> >> to catch up with the two release per year policy and deliver the VM
> >> improvements earlier. I'm also sure that a lot of improvements will be done
> >> till April/May on both image and VM side.
> >
> > It would be my preference to release with the Cog VM using the naive
> > SimpleStackBasedCogit code generator. ??After all that's worth at least 3x
> > over the standard VM whereas the unstable StackToregisterMappingCogit is
> > only ~ 8% faster than SimpleStackBasedCogit. ??It's quite easy for me to
> > generate either; the two coexist in the same VMMaker.
> > best
> > Eliot
> >>
> >>
> >> Levente
> >>
> >>>
> >>> ??- Chris
> >>>

Chris Muller-3

Re: [4.2] - VM <-> image release coordination

> Well I should not speak for Eliot r.e. Cog, but he has been releasing
> reliable, field-tested Cog VMs for some time now, so planning to have
> updated VMs for end of January seems perfectly reasonable to me.

That's good news. There is also work to do for the actual releasing,
which the VM Release Manager person would have to do (e.g., zip and
post to squeakvm.org, etc.), so I wanted to see whether that was
doable for them too.

When Eliot provides a new (or, recommends an old) version of the Cog
VM to release with 4.2, we can perform final tests using that VM for
the three platforms.

This will be nice for 4.2 (and, for Pharo community too) to be able to
announce, "compatible with a new Cog VM downloadable over here", and
have a new stable baseline out there.

- Chris

On Mon, Jan 3, 2011 at 3:02 PM, David T. Lewis <[hidden email]> wrote:

> On Mon, Jan 03, 2011 at 02:14:56PM -0600, Chris Muller wrote:
>> Excellent, thanks Eliot. That's been the plan for 4.2 all along, I
>> see no reason to abandon that now.
>>
>> I am currently trying to get a 4.2 RC1 built and saved under some
>> interpreter VM. I will need access or assistance for uploading it to
>> ftp.squeak.org (preferably access, since I'd like to build the image
>> myself).
>>
>> Then, I would like to have just under 4 more weeks, until 11:59pm,
>> 1/30/2011, for "last call" for 4.2. We've been testing for some time
>> now, we seem to have a stable, worthy release. Throughout January, we
>> will need to test (and fix) on all platforms, document, improve
>> aesthetics, and update web-sites.
>>
>> We will push the final release out the week of 1/31.
>>
>> VM Release Manager: Does this time-frame seem doable for a final
>> release of the simple-stack VM?
>>
>> - Chris
>
> Well I should not speak for Eliot r.e. Cog, but he has been releasing
> reliable, field-tested Cog VMs for some time now, so planning to have
> updated VMs for end of January seems perfectly reasonable to me.
>
> Dave
>
>
>>
>> On Mon, Jan 3, 2011 at 1:53 PM, Eliot Miranda <[hidden email]> wrote:
>> >
>> >
>> > On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
>> >>
>> >> Quoting Chris Muller <[hidden email]>:
>> >>
>> >>> Levente wrote:
>> >>>
>> >>>> I think we should wait for the new VMs, before releasing the new images.
>> >>>
>> >>> Hi Levente,
>> >>>
>> >>> I did agree, but now that Eliot is on a tear with a new code
>> >>> generator, the first official release might still be some weeks away.
>> >>> Someone please correct me if that is a misstatement.
>> >>>
>> >>> It seems unlikely 4.2 will be incompatible with whatever ends up being
>> >>> the first official Cog release. ??We should consider pushing it out the
>> >>> door so we can re-open the trunk to new featurey.
>> >>
>> >> That's right, Cog's recent improvements introduced some instability. So I
>> >> think we should release Squeak 4.2 with SqueakVM only and postpone the
>> >> multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
>> >> to catch up with the two release per year policy and deliver the VM
>> >> improvements earlier. I'm also sure that a lot of improvements will be done
>> >> till April/May on both image and VM side.
>> >
>> > It would be my preference to release with the Cog VM using the naive
>> > SimpleStackBasedCogit code generator. ??After all that's worth at least 3x
>> > over the standard VM whereas the unstable StackToregisterMappingCogit is
>> > only ~ 8% faster than SimpleStackBasedCogit. ??It's quite easy for me to
>> > generate either; the two coexist in the same VMMaker.
>> > best
>> > Eliot
>> >>
>> >>
>> >> Levente
>> >>
>> >>>
>> >>> ??- Chris
>> >>>
>
>

Levente Uzonyi-2

Re: [4.2] - VM <-> image release coordination

In reply to this post by Eliot Miranda-2

On Mon, 3 Jan 2011, Eliot Miranda wrote:

> On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> Quoting Chris Muller <[hidden email]>:
>>
>> Levente wrote:
>>>
>>> I think we should wait for the new VMs, before releasing the new images.
>>>>
>>>
>>> Hi Levente,
>>>
>>> I did agree, but now that Eliot is on a tear with a new code
>>> generator, the first official release might still be some weeks away.
>>> Someone please correct me if that is a misstatement.
>>>
>>> It seems unlikely 4.2 will be incompatible with whatever ends up being
>>> the first official Cog release. We should consider pushing it out the
>>> door so we can re-open the trunk to new featurey.
>>>
>>
>> That's right, Cog's recent improvements introduced some instability. So I
>> think we should release Squeak 4.2 with SqueakVM only and postpone the
>> multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
>> to catch up with the two release per year policy and deliver the VM
>> improvements earlier. I'm also sure that a lot of improvements will be done
>> till April/May on both image and VM side.
>>
>
> It would be my preference to release with the Cog VM using the naive
> SimpleStackBasedCogit code generator. After all that's worth at least 3x
> over the standard VM whereas the unstable StackToregisterMappingCogit is
> only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
> generate either; the two coexist in the same VMMaker.

Okay, then I guess we should make sure that the two VMs (SqueakVM and
CogVM with SimpleStackBasedCogit) behave the same way in most cases.
Here's an incomplete list of VM differences:
- CogVM does compile the FloatMathPlugin properly (no crash), but SqueakVM
doesn't or it does without optimizing the code. Wwe can apply some
optimization for most methods, see the makefiles of Cog.
- CogVM doesn't support the new finalization scheme
- there's no SoundPlugin in CogVM on windows
- the SocketPlugin of CogVM seems to be missing the new primitives
- AllocationTest >> #testOneGigAllocation is still failing with CogVM
- I'm not sure if SqueakVM has all of the mirror primitives

Levente

P.S.: does the ~8% speedup come from the recompilation benchmark? Is the
code for the Computer Language Benchmarks Game available somewhere? It
would be good to test the new stdio support with it.

>
> best
> Eliot
>
>
>>
>> Levente
>>
>>
>>> - Chris
>>>
>>>
>>>
>>
>>
>>
>>
>

David T. Lewis

Re: [4.2] - VM <-> image release coordination

On Tue, Jan 04, 2011 at 08:45:12AM +0100, Levente Uzonyi wrote:

> On Mon, 3 Jan 2011, Eliot Miranda wrote:
>
> >On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
> >
> >>Quoting Chris Muller <[hidden email]>:
> >>
> >> Levente wrote:
> >>>
> >>> I think we should wait for the new VMs, before releasing the new images.
> >>>>
> >>>
> >>>Hi Levente,
> >>>
> >>>I did agree, but now that Eliot is on a tear with a new code
> >>>generator, the first official release might still be some weeks away.
> >>>Someone please correct me if that is a misstatement.
> >>>
> >>>It seems unlikely 4.2 will be incompatible with whatever ends up being
> >>>the first official Cog release. We should consider pushing it out the
> >>>door so we can re-open the trunk to new featurey.
> >>>
> >>
> >>That's right, Cog's recent improvements introduced some instability. So I
> >>think we should release Squeak 4.2 with SqueakVM only and postpone the
> >>multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
> >>to catch up with the two release per year policy and deliver the VM
> >>improvements earlier. I'm also sure that a lot of improvements will be
> >>done
> >>till April/May on both image and VM side.
> >>
> >
> >It would be my preference to release with the Cog VM using the naive
> >SimpleStackBasedCogit code generator. After all that's worth at least 3x
> >over the standard VM whereas the unstable StackToregisterMappingCogit is
> >only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
> >generate either; the two coexist in the same VMMaker.
>
> Okay, then I guess we should make sure that the two VMs (SqueakVM and
> CogVM with SimpleStackBasedCogit) behave the same way in most cases.
> Here's an incomplete list of VM differences:
> - CogVM does compile the FloatMathPlugin properly (no crash), but SqueakVM
> doesn't or it does without optimizing the code. Wwe can apply some
> optimization for most methods, see the makefiles of Cog.

This is already done, so no issue for the new VMs.

> - CogVM doesn't support the new finalization scheme
> - there's no SoundPlugin in CogVM on windows
> - the SocketPlugin of CogVM seems to be missing the new primitives
> - AllocationTest >> #testOneGigAllocation is still failing with CogVM

There are definitely differences, as the Cog and standard VMs are
currently built from separate code bases for both the support
code and the generated code (VMMaker).

> - I'm not sure if SqueakVM has all of the mirror primitives

It does not. I have been looked at this over the past week myself,
but I'm afraid it's a bit beyond my abilities to incorporate.
Possibly Eliot can coach me a bit to get it done, but for planning
purposes you should assume that the standard VM does not have
mirror primitive support.

Dave

Levente Uzonyi-2

Re: [4.2] - VM <-> image release coordination

On Tue, 4 Jan 2011, David T. Lewis wrote:

> On Tue, Jan 04, 2011 at 08:45:12AM +0100, Levente Uzonyi wrote:
>> On Mon, 3 Jan 2011, Eliot Miranda wrote:
>>
>>> On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
>>>
>>>> Quoting Chris Muller <[hidden email]>:
>>>>
>>>> Levente wrote:
>>>>>
>>>>> I think we should wait for the new VMs, before releasing the new images.
>>>>>>
>>>>>
>>>>> Hi Levente,
>>>>>
>>>>> I did agree, but now that Eliot is on a tear with a new code
>>>>> generator, the first official release might still be some weeks away.
>>>>> Someone please correct me if that is a misstatement.
>>>>>
>>>>> It seems unlikely 4.2 will be incompatible with whatever ends up being
>>>>> the first official Cog release. We should consider pushing it out the
>>>>> door so we can re-open the trunk to new featurey.
>>>>>
>>>>
>>>> That's right, Cog's recent improvements introduced some instability. So I
>>>> think we should release Squeak 4.2 with SqueakVM only and postpone the
>>>> multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
>>>> to catch up with the two release per year policy and deliver the VM
>>>> improvements earlier. I'm also sure that a lot of improvements will be
>>>> done
>>>> till April/May on both image and VM side.
>>>>
>>>
>>> It would be my preference to release with the Cog VM using the naive
>>> SimpleStackBasedCogit code generator. After all that's worth at least 3x
>>> over the standard VM whereas the unstable StackToregisterMappingCogit is
>>> only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
>>> generate either; the two coexist in the same VMMaker.
>>
>> Okay, then I guess we should make sure that the two VMs (SqueakVM and
>> CogVM with SimpleStackBasedCogit) behave the same way in most cases.
>> Here's an incomplete list of VM differences:
>> - CogVM does compile the FloatMathPlugin properly (no crash), but SqueakVM
>> doesn't or it does without optimizing the code. Wwe can apply some
>> optimization for most methods, see the makefiles of Cog.
>
> This is already done, so no issue for the new VMs.

IIRC Cog only uses -O0 for three functions, others are optimized with -O.

Levente

>
>> - CogVM doesn't support the new finalization scheme
>> - there's no SoundPlugin in CogVM on windows
>> - the SocketPlugin of CogVM seems to be missing the new primitives
>> - AllocationTest >> #testOneGigAllocation is still failing with CogVM
>
> There are definitely differences, as the Cog and standard VMs are
> currently built from separate code bases for both the support
> code and the generated code (VMMaker).
>
>> - I'm not sure if SqueakVM has all of the mirror primitives
>
> It does not. I have been looked at this over the past week myself,
> but I'm afraid it's a bit beyond my abilities to incorporate.
> Possibly Eliot can coach me a bit to get it done, but for planning
> purposes you should assume that the standard VM does not have
> mirror primitive support.
>
> Dave
>
>
>

Igor Stasenko

Re: [4.2] - VM <-> image release coordination

In reply to this post by Levente Uzonyi-2

On 4 January 2011 08:45, Levente Uzonyi <[hidden email]> wrote:

> On Mon, 3 Jan 2011, Eliot Miranda wrote:
>
>> On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>>> Quoting Chris Muller <[hidden email]>:
>>>
>>> Levente wrote:
>>>>
>>>> I think we should wait for the new VMs, before releasing the new
>>>> images.
>>>>>
>>>>
>>>> Hi Levente,
>>>>
>>>> I did agree, but now that Eliot is on a tear with a new code
>>>> generator, the first official release might still be some weeks away.
>>>> Someone please correct me if that is a misstatement.
>>>>
>>>> It seems unlikely 4.2 will be incompatible with whatever ends up being
>>>> the first official Cog release. We should consider pushing it out the
>>>> door so we can re-open the trunk to new featurey.
>>>>
>>>
>>> That's right, Cog's recent improvements introduced some instability. So I
>>> think we should release Squeak 4.2 with SqueakVM only and postpone the
>>> multi-VM release. We can also make the release cycle of Squeak 4.3
>>> shorter
>>> to catch up with the two release per year policy and deliver the VM
>>> improvements earlier. I'm also sure that a lot of improvements will be
>>> done
>>> till April/May on both image and VM side.
>>>
>>
>> It would be my preference to release with the Cog VM using the naive
>> SimpleStackBasedCogit code generator. After all that's worth at least 3x
>> over the standard VM whereas the unstable StackToregisterMappingCogit is
>> only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
>> generate either; the two coexist in the same VMMaker.
>
> Okay, then I guess we should make sure that the two VMs (SqueakVM and
> CogVM with SimpleStackBasedCogit) behave the same way in most cases. Here's
> an incomplete list of VM differences:
> - CogVM does compile the FloatMathPlugin properly (no crash), but SqueakVM
> doesn't or it does without optimizing the code. Wwe can apply some
> optimization for most methods, see the makefiles of Cog.
> - CogVM doesn't support the new finalization scheme

this is easy to fix, if Eliot would merge my changes to VMMaker,
like VMMaker-oscog-Igor.Stasenko.43 and build new VM's using merged version.

> - there's no SoundPlugin in CogVM on windows
> - the SocketPlugin of CogVM seems to be missing the new primitives
> - AllocationTest >> #testOneGigAllocation is still failing with CogVM
> - I'm not sure if SqueakVM has all of the mirror primitives
>
>
> Levente
>
> P.S.: does the ~8% speedup come from the recompilation benchmark? Is the
> code for the Computer Language Benchmarks Game available somewhere? It
> would be good to test the new stdio support with it.
>

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

Re: [4.2] - VM <-> image release coordination

In reply to this post by Levente Uzonyi-2

Hi Levente,

On Mon, Jan 3, 2011 at 11:45 PM, Levente Uzonyi <[hidden email]> wrote:

On Mon, 3 Jan 2011, Eliot Miranda wrote:

On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:

Quoting Chris Muller <[hidden email]>:

Levente wrote:

I think we should wait for the new VMs, before releasing the new images.

Hi Levente,

I did agree, but now that Eliot is on a tear with a new code
generator, the first official release might still be some weeks away.
Someone please correct me if that is a misstatement.

It seems unlikely 4.2 will be incompatible with whatever ends up being
the first official Cog release. We should consider pushing it out the
door so we can re-open the trunk to new featurey.

That's right, Cog's recent improvements introduced some instability. So I
think we should release Squeak 4.2 with SqueakVM only and postpone the
multi-VM release. We can also make the release cycle of Squeak 4.3 shorter
to catch up with the two release per year policy and deliver the VM
improvements earlier. I'm also sure that a lot of improvements will be done
till April/May on both image and VM side.

It would be my preference to release with the Cog VM using the naive
SimpleStackBasedCogit code generator. After all that's worth at least 3x
over the standard VM whereas the unstable StackToregisterMappingCogit is
only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
generate either; the two coexist in the same VMMaker.

Okay, then I guess we should make sure that the two VMs (SqueakVM and
CogVM with SimpleStackBasedCogit) behave the same way in most cases. Here's an incomplete list of VM differences:
- CogVM does compile the FloatMathPlugin properly (no crash), but SqueakVM doesn't or it does without optimizing the code. Wwe can apply some optimization for most methods, see the makefiles of Cog.
- CogVM doesn't support the new finalization scheme
- there's no SoundPlugin in CogVM on windows
- the SocketPlugin of CogVM seems to be missing the new primitives
- AllocationTest >> #testOneGigAllocation is still failing with CogVM
- I'm not sure if SqueakVM has all of the mirror primitives

yes, this looks at least close to the complete list.

Levente

P.S.: does the ~8% speedup come from the recompilation benchmark? Is the code for the Computer Language Benchmarks Game available somewhere? It
would be good to test the new stdio support with it.

I see about 8% in a couple of things, one is Compiler recompileAll with no transcript (all the logging to the open transcript reduces the speedup by a couple of percent), another is in the geometric mean of the four computer language shootout tests I use (these because they don't depend on external plugins etc, and stress generic VM performance). SO I expect about an 8% speedup in most macro pure Smalltalk code, and would expect significantly larger speedups in low-level arithmetic and loop code (as evinced by the ~ x2 speedups in the tinyBenchmark scores). But I've not measured much yet. I'm attaching my Shootout benchmarks. And of course anyone who wants to add to these I'd be grateful of the code. Also if anyone has Richards, DeltaBlue or a RayTracer to hand I'd like that code too.

cheers

Eliot

best
Eliot

Levente

- Chris

Cog-Benchmarks.st (40K) Download Attachment

Eliot Miranda-2

Re: [4.2] - VM <-> image release coordination

In reply to this post by Igor Stasenko

On Tue, Jan 4, 2011 at 10:20 AM, Igor Stasenko <[hidden email]> wrote:

On 4 January 2011 08:45, Levente Uzonyi <[hidden email]> wrote:
> On Mon, 3 Jan 2011, Eliot Miranda wrote:
>
>> On Sun, Jan 2, 2011 at 11:38 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>>> Quoting Chris Muller <[hidden email]>:
>>>
>>> Levente wrote:
>>>>
>>>> I think we should wait for the new VMs, before releasing the new
>>>> images.
>>>>>
>>>>
>>>> Hi Levente,
>>>>
>>>> I did agree, but now that Eliot is on a tear with a new code
>>>> generator, the first official release might still be some weeks away.
>>>> Someone please correct me if that is a misstatement.
>>>>
>>>> It seems unlikely 4.2 will be incompatible with whatever ends up being
>>>> the first official Cog release. We should consider pushing it out the
>>>> door so we can re-open the trunk to new featurey.
>>>>
>>>
>>> That's right, Cog's recent improvements introduced some instability. So I
>>> think we should release Squeak 4.2 with SqueakVM only and postpone the
>>> multi-VM release. We can also make the release cycle of Squeak 4.3
>>> shorter
>>> to catch up with the two release per year policy and deliver the VM
>>> improvements earlier. I'm also sure that a lot of improvements will be
>>> done
>>> till April/May on both image and VM side.
>>>
>>
>> It would be my preference to release with the Cog VM using the naive
>> SimpleStackBasedCogit code generator. After all that's worth at least 3x
>> over the standard VM whereas the unstable StackToregisterMappingCogit is
>> only ~ 8% faster than SimpleStackBasedCogit. It's quite easy for me to
>> generate either; the two coexist in the same VMMaker.
>
> Okay, then I guess we should make sure that the two VMs (SqueakVM and
> CogVM with SimpleStackBasedCogit) behave the same way in most cases. Here's
> an incomplete list of VM differences:
> - CogVM does compile the FloatMathPlugin properly (no crash), but SqueakVM
> doesn't or it does without optimizing the code. Wwe can apply some
> optimization for most methods, see the makefiles of Cog.
> - CogVM doesn't support the new finalization scheme

this is easy to fix, if Eliot would merge my changes to VMMaker,
like VMMaker-oscog-Igor.Stasenko.43 and build new VM's using merged version.

Soon :)

> - there's no SoundPlugin in CogVM on windows
> - the SocketPlugin of CogVM seems to be missing the new primitives
> - AllocationTest >> #testOneGigAllocation is still failing with CogVM
> - I'm not sure if SqueakVM has all of the mirror primitives
>
>
> Levente
>
> P.S.: does the ~8% speedup come from the recompilation benchmark? Is the
> code for the Computer Language Benchmarks Game available somewhere? It
> would be good to test the new stdio support with it.
>

--
Best regards,
Igor Stasenko AKA sig.