[Pharo-project] CogVM as official Pharo VM?
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
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
Hi Lukas, On Thu, Jul 29, 2010 at 2:00 AM, Lukas Renggli <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/29 Eliot Miranda <eliot.miranda@gmail.com>
Hi Lukas,
On Thu, Jul 29, 2010 at 2:00 AM, Lukas Renggli <renggli@gmail.com> 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 :/
Although it is very important for us, it is not that we needed right NOW. Take all the time you need. It is good to see you want to fix it :)
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?)
That's the idea of the Pharo OneClick with Cog. We can distribute that so that everybody can start to play with it and report problem. But for that, we need to know where to get all Cog sources, and how to compile it. In addition, what kind of flags in configure would help you to debug problems and get as much information as possible. With this we can distribute a VM + image that logs as much as possible. This one click would be experimental, not production. Thus, it shouldn't care if it is a little slower (because of the logging). Cheers Mariano
best Eliot
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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
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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I also agree with Janko idea. Image required changes where integrated in PharoCore 1.2. We can start soon to build Dev images using that core, and, most importantly, build a one click with Cog. Now the problem is.. 1) where to get the latest code from both, SVN and VMMaker. 2) Compile and generate binaries for each platform Who can help us with this? The only binary I saw was the one Lukas did for Mac OS but I guess it should be updated with latests fixes? Cheers Mariano On Thu, Jul 29, 2010 at 3:15 PM, David T. Lewis <lewis@mail.msen.com> wrote:
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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 29, 2010, at 3:20 PM, Mariano Martinez Peck wrote:
I also agree with Janko idea. Image required changes where integrated in PharoCore 1.2.
not really I have to go over them once more but I'm busy with other simple fixes (= that other people could do but nobody dare to/have time to...) stef
We can start soon to build Dev images using that core, and, most importantly, build a one click with Cog.
Now the problem is..
1) where to get the latest code from both, SVN and VMMaker. 2) Compile and generate binaries for each platform
Who can help us with this?
The only binary I saw was the one Lukas did for Mac OS but I guess it should be updated with latests fixes?
Cheers
Mariano
On Thu, Jul 29, 2010 at 3:15 PM, David T. Lewis <lewis@mail.msen.com> wrote: 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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/29 Janko Mivšek <janko.mivsek@eranova.si>
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.
that a great approach Janko. thanks, Eliot
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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/29 Mariano Martinez Peck <marianopeck@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/29 Eliot Miranda <eliot.miranda@gmail.com>
2010/7/29 Mariano Martinez Peck <marianopeck@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/30 Mariano Martinez Peck <marianopeck@gmail.com>
2010/7/29 Eliot Miranda <eliot.miranda@gmail.com>
2010/7/29 Mariano Martinez Peck <marianopeck@gmail.com>
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 ?
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 |
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
On Fri, Jul 30, 2010 at 11:55 AM, Martin McClure <martin@hand2mouse.com>wrote:
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.
and I should say that while I came up with the scheme it was Martin who very patiently debugged it. Without Martin's help it would have been a train wreck. Thanks again, Martin!
Regards,
-Martin
2010/7/29 Mariano Martinez Peck <marianopeck@gmail.com>:
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.
Thank you Mariano this important issue for the future of Pharo.
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.
For crashed related to socket, i know that Noury and Luc are working on a new implementation of sockets, so maybe if it is ready it could be included in 1.2 version.
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.
I think both binaries should be provided for 1.2 and also OneClick images with standard and Cog VM, in order to maximize the number of tests for the new VM. If we really want to push this, someone should take care of all of this. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Hi, I can give a hand in testing on Mac as I am using it everyday. Cheers, Doru On 30 Jul 2010, at 05:26, Serge Stinckwich wrote:
2010/7/29 Mariano Martinez Peck <marianopeck@gmail.com>:
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.
Thank you Mariano this important issue for the future of Pharo.
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.
For crashed related to socket, i know that Noury and Luc are working on a new implementation of sockets, so maybe if it is ready it could be included in 1.2 version.
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.
I think both binaries should be provided for 1.2 and also OneClick images with standard and Cog VM, in order to maximize the number of tests for the new VM. If we really want to push this, someone should take care of all of this.
Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Don't give to get. Just give."
participants (9)
-
David T. Lewis -
Eliot Miranda -
Janko Mivšek -
Lukas Renggli -
Mariano Martinez Peck -
Martin McClure -
Serge Stinckwich -
Stéphane Ducasse -
Tudor Girba