CogVM as official Pharo VM?

This is very good advice.

Dave

On Thu, Jul 29, 2010 at 11:15:41AM +0200, Janko Miv??ek wrote:
> Hi guys,
>
> I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to:
>
> - encourage Cog usage and discovering all bugs and side effects, which
>   will:
> - let the Cog become production ready more quickly, but it:
> - won't mislead people to consider Cog as production ready, because
>   such unintential misleading can put Cog unfairly in a bad light.
>
> Best regards
> Janko
>
> On 29. 07. 2010 10:45, Mariano Martinez Peck wrote:
> > Hi folks. Hope Eliot is reading this thread.
> >
> > It is time to think in Pharo 1.2 and we need to discuss if we want to
> > have CogVM as the standard Pharo VM.
> >
> > Most of us have tried it and found it incredible fast. So it would be
> > very good to take advantage of it.  But I think there are a couple of
> > things to be discussed:
> >
> > 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
> > "The Cog VM is a just-in-time compiler that currently supports only x86
> >
> > No effort has been made to maintain 64-bit compatibility.  Apologies,
> > this was unaffordable."
> >
> > So...how much important is this for us? do we care? and if we want to do
> > it, is it "doable" ?  is it less doable than the normal squeak VM ?
> >
> > I really would like to have 64bits VM + 64bits images in a near
> > future...but hat's just my thoguhts.
> >
> > 2) The status of the external plugins. Are they working with Cog ?  Not
> > only the "core plugings" but FFI, OSProcess (I read some problems with
> > it), TrueType, etc...
> >
> > 3) Is it stable for production use?  For example, I read that with
> > seaside there are some crashes.
> >
> > 4) Depends on heroes. I never liked this idea. It has nothing to do with
> > Eliot. He is very cool and helpful. But I wonder, do we understand the
> > new VM and the changes? are we able to handle and fix it even without
> > eliot ?
> >
> > 5) Integration to VMMaker. I saw that they started to merge cog
> > (actually, I think only stack vm?) to the trunk of VMMaker. This is
> > really good news. I hope everything is there and merged.
> >
> > 6) Binaries. It seems the official released didn't come with binaries.
> > So we should compile it for each OS.
> >
> >
> > Ok..that's all my thoughts. I would really like to have a discussion
> > here and see what to do.....grrrrrr you are all in holidays, aren't you?
> > hahah
> >
> > cheers
> >
> > Mariano
> >
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --

> Janko Miv??ek

> Svetovalec za informatiko
> Eranova d.o.o.
> Ljubljana, Slovenija
> www.eranova.si
> tel:  01 514 22 55
> faks: 01 514 22 56
> gsm: 031 674 565
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi folks. Hope Eliot is reading this thread.

It is time to think in Pharo 1.2 and we need to discuss if we want to have CogVM as the standard Pharo VM.

Most of us have tried it and found it incredible fast. So it would be very good to take advantage of it.  But I think there are a couple of things to be discussed:

1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
"The Cog VM is a just-in-time compiler that currently supports only x86

No effort has been made to maintain 64-bit compatibility.  Apologies, this was unaffordable."

So...how much important is this for us? do we care? and if we want to do it, is it "doable" ?  is it less doable than the normal squeak VM ?

I really would like to have 64bits VM + 64bits images in a near future...but hat's just my thoguhts.

2) The status of the external plugins. Are they working with Cog ?  Not only the "core plugings" but FFI, OSProcess (I read some problems with it), TrueType, etc...

3) Is it stable for production use?  For example, I read that with seaside there are some crashes.

4) Depends on heroes. I never liked this idea. It has nothing to do with Eliot. He is very cool and helpful. But I wonder, do we understand the new VM and the changes? are we able to handle and fix it even without eliot ?

5) Integration to VMMaker. I saw that they started to merge cog (actually, I think only stack vm?) to the trunk of VMMaker. This is really good news. I hope everything is there and merged.

6) Binaries. It seems the official released didn't come with binaries. So we should compile it for each OS.

Ok..that's all my thoughts. I would really like to have a discussion here and see what to do.....grrrrrr you are all in holidays, aren't you? hahah

cheers

Mariano

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi guys,

I would prepare a separate Pharo-Cog-Experimental one-clicks for now, to:

- encourage Cog usage and discovering all bugs and side effects, which
 will:
- let the Cog become production ready more quickly, but it:
- won't mislead people to consider Cog as production ready, because
 such unintential misleading can put Cog unfairly in a bad light.

Best regards
Janko

On 29. 07. 2010 10:45, Mariano Martinez Peck wrote:
> Hi folks. Hope Eliot is reading this thread.
>
> It is time to think in Pharo 1.2 and we need to discuss if we want to
> have CogVM as the standard Pharo VM.
>
> Most of us have tried it and found it incredible fast. So it would be
> very good to take advantage of it.  But I think there are a couple of
> things to be discussed:
>
> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
> "The Cog VM is a just-in-time compiler that currently supports only x86
>
> No effort has been made to maintain 64-bit compatibility.  Apologies,
> this was unaffordable."
>
> So...how much important is this for us? do we care? and if we want to do
> it, is it "doable" ?  is it less doable than the normal squeak VM ?
>
> I really would like to have 64bits VM + 64bits images in a near
> future...but hat's just my thoguhts.
>
> 2) The status of the external plugins. Are they working with Cog ?  Not
> only the "core plugings" but FFI, OSProcess (I read some problems with
> it), TrueType, etc...
>
> 3) Is it stable for production use?  For example, I read that with
> seaside there are some crashes.
>
> 4) Depends on heroes. I never liked this idea. It has nothing to do with
> Eliot. He is very cool and helpful. But I wonder, do we understand the
> new VM and the changes? are we able to handle and fix it even without
> eliot ?
>
> 5) Integration to VMMaker. I saw that they started to merge cog
> (actually, I think only stack vm?) to the trunk of VMMaker. This is
> really good news. I hope everything is there and merged.
>
> 6) Binaries. It seems the official released didn't come with binaries.
> So we should compile it for each OS.
>
>
> Ok..that's all my thoughts. I would really like to have a discussion
> here and see what to do.....grrrrrr you are all in holidays, aren't you?
> hahah
>
> cheers
>
> Mariano
>
>
>

> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
> "The Cog VM is a just-in-time compiler that currently supports only x86

So far I never felt the need for 64-bit images.

> 3) Is it stable for production use?  For example, I read that with seaside
> there are some crashes.

Seaside itself is not the problem, Eliot quickly fixed the remaining
issues with Continuations shortly after the open-source release of
Cog.

The problem are the sockets, they cause frequent random crashes
of the VM.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/7/29 Mariano Martinez Peck <[hidden email]>

Hi folks. Hope Eliot is reading this thread.

Yes, I'm reading :)

 

It is time to think in Pharo 1.2 and we need to discuss if we want to have CogVM as the standard Pharo VM.

Most of us have tried it and found it incredible fast. So it would be very good to take advantage of it.  But I think there are a couple of things to be discussed:

1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
"The Cog VM is a just-in-time compiler that currently supports only x86

It is only initially aimed at x86.  That's the most important platform by far from Teleplace's perspective and I suspect the majority of the community is on x86.  But Cog was designed form the outset to be portable.  The Cogit is architected to support other ISAs.  See CogAbstractInstruction and its one subclass CogIA32Compiler.  To port to another ISA you should subclass CogAbstractInstruction and implement the same protocol as CogIA32Compiler.

I would love to see a CogARMCompiler and a CogPPCCompiler and encourage anyone with low-level expertise on those platforms to have a go.  I'm always here to answer questions.

No effort has been made to maintain 64-bit compatibility.  Apologies, this was unaffordable."

So...how much important is this for us? do we care? and if we want to do it, is it "doable" ?  is it less doable than the normal squeak VM ?

I really would like to have 64bits VM + 64bits images in a near future...but hat's just my thoguhts.

I'm also thinking abut 64-bits but want to do 64-bits with a new object representation based on my 64-bit objrep for VisualWorks, which would include SmallFloat.  Realistically this is a year out, because the 32-bit version of the new objrep and the pinning GC need to be implemented before I'll be able to do a 64-bit VM.  But it's an obvious and logical direction to go in.

2) The status of the external plugins. Are they working with Cog ?  Not only the "core plugings" but FFI, OSProcess (I read some problems with it), TrueType, etc...

ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) should work.  But people need to build and test.

3) Is it stable for production use?  For example, I read that with seaside there are some crashes.

Well, it is the production VM at Teleplace so at least for one context the answer is certainly yes.  There must be something obviously broken with sockets (is it all platforms or only linux?) because we use sockets intensively at Teleplace and only see problems on a single customer's machine which looks to be to do with virus protection.  I'm on holiday next week and am rather busy right now, but perhaps later in August I can work with Lukas to try and sort out the socket issues.

4) Depends on heroes. I never liked this idea. It has nothing to do with Eliot. He is very cool and helpful. But I wonder, do we understand the new VM and the changes? are we able to handle and fix it even without eliot ?

THis is a serious issue.  I need to be nagged to document the system on my blog.  I mean to get to this (perhaps in September?).  Alas a Smalltalk JIT is a complex beast, significantly more complex than the interpreter, and is not the easiest thing to understand or debug.  So even if it is well documented it'll be more difficult to fix than the interpreter, but that's a price one has to pay for this kind of performance.

 

5) Integration to VMMaker. I saw that they started to merge cog (actually, I think only stack vm?) to the trunk of VMMaker. This is really good news. I hope everything is there and merged.

Cog is a fork of VMMaker.  We may be able to merge at some stage, and Cog's Slang should still work with the old Interpreter.  But for now, inevitably, it's a fork.  I needed to add a lot of functionality to Slang to write Cog, and I didn't have the cycles to keep Interpreter up to date.  That's life :)

6) Binaries. It seems the official released didn't come with binaries. So we should compile it for each OS.

There is /no/ official release.   Until Cog has stabilized and the VM maintainers have taken it up it's definitely unoffficial :)

Ok..that's all my thoughts. I would really like to have a discussion here and see what to do.....grrrrrr you are all in holidays, aren't you? hahah

two days to go :)

 

cheers

Mariano

best

Eliot

 

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Lukas,

On Thu, Jul 29, 2010 at 2:00 AM, Lukas Renggli <[hidden email]> wrote:

> 1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
> "The Cog VM is a just-in-time compiler that currently supports only x86

So far I never felt the need for 64-bit images.

> 3) Is it stable for production use?  For example, I read that with seaside
> there are some crashes.

Seaside itself is not the problem, Eliot quickly fixed the remaining
issues with Continuations shortly after the open-source release of
Cog.

and I still need to fix objects-as-methods but have no time right now.  That's probably two to five days work to do right :/

 

The problem are the sockets, they cause frequent random crashes
of the VM.

Do we have any more specific information on these socket-related crashes?  (platform, crash reports, test cases, etc?)

best

Eliot

 

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/7/29 Eliot Miranda <[hidden email]>

2010/7/29 Mariano Martinez Peck <[hidden email]>

Hi folks. Hope Eliot is reading this thread.

Yes, I'm reading :)

THanks Eliot for all the answers. It seems they are all good news :)
 

 

It is time to think in Pharo 1.2 and we need to discuss if we want to have CogVM as the standard Pharo VM.

Most of us have tried it and found it incredible fast. So it would be very good to take advantage of it.  But I think there are a couple of things to be discussed:

1) Cog VM seems to be aimed for x86 and 32 bits. You can read Eliot quotes:
"The Cog VM is a just-in-time compiler that currently supports only x86

It is only initially aimed at x86.  That's the most important platform by far from Teleplace's perspective and I suspect the majority of the community is on x86.  But Cog was designed form the outset to be portable.  The Cogit is architected to support other ISAs.  See CogAbstractInstruction and its one subclass CogIA32Compiler.  To port to another ISA you should subclass CogAbstractInstruction and implement the same protocol as CogIA32Compiler.

I would love to see a CogARMCompiler and a CogPPCCompiler and encourage anyone with low-level expertise on those platforms to have a go.  I'm always here to answer questions.

This is great Eliot.  I thought that Cog was completly aimed to x86 and that would be difficult to port. That was my concern, but now with what you said it is much clear :)


 

No effort has been made to maintain 64-bit compatibility.  Apologies, this was unaffordable."

So...how much important is this for us? do we care? and if we want to do it, is it "doable" ?  is it less doable than the normal squeak VM ?

I really would like to have 64bits VM + 64bits images in a near future...but hat's just my thoguhts.

I'm also thinking abut 64-bits but want to do 64-bits with a new object representation based on my 64-bit objrep for VisualWorks, which would include SmallFloat.  Realistically this is a year out, because the 32-bit version of the new objrep and the pinning GC need to be implemented before I'll be able to do a 64-bit VM.  But it's an obvious and logical direction to go in.

Excellent!!   Just by curious, your idea, or what you did in VW, was to be able to put SmallFloats directly inside the address ? just like we do nowadays with SmallInteger ?

2) The status of the external plugins. Are they working with Cog ?  Not only the "core plugings" but FFI, OSProcess (I read some problems with it), TrueType, etc...

ReentrantFFIPlugin (a.k.a. src/plugins/SqueakFFIPrims/SqueakFFIPrims.c) should work.  But people need to build and test.

3) Is it stable for production use?  For example, I read that with seaside there are some crashes.

Well, it is the production VM at Teleplace so at least for one context the answer is certainly yes.  There must be something obviously broken with sockets (is it all platforms or only linux?) because we use sockets intensively at Teleplace and only see problems on a single customer's machine which looks to be to do with virus protection.  I'm on holiday next week and am rather busy right now, but perhaps later in August I can work with Lukas to try and sort out the socket issues.

ok...
 

4) Depends on heroes. I never liked this idea. It has nothing to do with Eliot. He is very cool and helpful. But I wonder, do we understand the new VM and the changes? are we able to handle and fix it even without eliot ?

THis is a serious issue.  I need to be nagged to document the system on my blog.  I mean to get to this (perhaps in September?).  Alas a Smalltalk JIT is a complex beast, significantly more complex than the interpreter, and is not the easiest thing to understand or debug.  So even if it is well documented it'll be more difficult to fix than the interpreter, but that's a price one has to pay for this kind of performance.

 

I agree. That's why my concern.

 

5) Integration to VMMaker. I saw that they started to merge cog (actually, I think only stack vm?) to the trunk of VMMaker. This is really good news. I hope everything is there and merged.

Cog is a fork of VMMaker.  We may be able to merge at some stage, and Cog's Slang should still work with the old Interpreter.  But for now, inevitably, it's a fork.  I needed to add a lot of functionality to Slang to write Cog, and I didn't have the cycles to keep Interpreter up to date.  That's life :)

 

ok

 

6) Binaries. It seems the official released didn't come with binaries. So we should compile it for each OS.

There is /no/ official release.   Until Cog has stabilized and the VM maintainers have taken it up it's definitely unoffficial :)

Ok...forget the "official" word....where should we get the sources (svn) and the VMMaker code in order to compile the latest and build binaries?

 

Ok..that's all my thoughts. I would really like to have a discussion here and see what to do.....grrrrrr you are all in holidays, aren't you? hahah

two days to go :)

enjoy ;)

 

 

cheers

Mariano

best

Eliot

 

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 07/30/2010 11:28 AM, Eliot Miranda wrote:

[...]

   Excellent!!   Just by curious, your idea, or what you did in VW, was
   to be able to put SmallFloats directly inside the address ? just
   like we do nowadays with SmallInteger ?


Yes.  The scheme provides IEEE double precision but with a smaller
exponent so the range is the same as the 32-bit single-precision range.
 i.e. 3 bits are used as tag bits to distinguish SmallInteger
SmallFloat Character and objects.  That leaves 1 bit for sign, 52 bits
for the mantissa and 8 bits for the exponent.  The use of 3 tag bits
comes from 64-bit pointers being 8-byte aligned and so having the least
significant 3 bits 0.  I don't want to defend that choice now just to
give you a flavour of the representation:

| 8-bit exponent | 52 bit mantissa | sign | tags |

A few more words on the VW SmallDouble implementation: We also use this representation in GemStone; it works very well.

This representation exactly represents a subset of the possible IEEE doubles. It's the "common" 1/8th of the total range, with the addition of +-0.0. Non-zero numbers very close to zero or very far from zero overflow to normal Float objects in a manner very similar to the way SmallInteger/LargeInteger work. The infinities and NaNs also must be represented as normal Floats.

Because between SmallDouble and Float all IEEE doubles can be represented, all floating-point computations give the correct (per IEEE) result, but you save memory and computation is generally faster because you don't access as many bytes in main memory.

Regards,

-Martin