How do can we set up a crowdsourcing for pharo
Hi we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it? Esteban/igor what is your estimate for such task? Stef
honestly, depends a lot on who will do it. basically, I see 3 parts: 1) The Stack VM 64bits 2) The Pharo image 64bits. 3) NB-FFI 64 (No point on having a VM who cannot talk with the outside world) a future task could be create a JIT, but I complete ignorant on how difficult/possible is that :) To compile the stack vm in 64 bits is not difficult, but there is a lot of small tweaks to make... so I think 1 man-month should be enough . To produce a 64bits pharo image we need an objecttracer.... and Guille says with ObjectSpaces is a lot easier... but again, it has to be done... I think another month should be enough. ... and with NB-FFI 64, no idea, but AFAIK is almost there (Camillo knows more there) also, 1 and 2 are vital, and we can tune 3 with the VM+Image working. That's my (very general) opinion. Esteban On Jun 27, 2013, at 2:16 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
Stef
On 27 June 2013 14:48, Esteban Lorenzano <estebanlm@gmail.com> wrote:
honestly, depends a lot on who will do it.
basically, I see 3 parts:
1) The Stack VM 64bits 2) The Pharo image 64bits. 3) NB-FFI 64 (No point on having a VM who cannot talk with the outside world)
a future task could be create a JIT, but I complete ignorant on how difficult/possible is that :)
To compile the stack vm in 64 bits is not difficult, but there is a lot of small tweaks to make... so I think 1 man-month should be enough . To produce a 64bits pharo image we need an objecttracer.... and Guille says with ObjectSpaces is a lot easier... but again, it has to be done... I think another month should be enough.
... and with NB-FFI 64, no idea, but AFAIK is almost there (Camillo knows more there) also, 1 and 2 are vital, and we can tune 3 with the VM+Image working.
That's my (very general) opinion.
ah.. yes.. FFI too. That shouldn't be very difficult but cannot start work on it unless other two is ready. (it needs to know about object format and other stuff to generate proper code)
Esteban
On Jun 27, 2013, at 2:16 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
Stef
-- Best regards, Igor Stasenko.
On 27 June 2013 14:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
depends what you put into it: - interpreter + plugins - new object/image format (64bit) - 64-bit jit
Stef
-- Best regards, Igor Stasenko.
so much? how many men/months? Stef On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 14:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
depends what you put into it: - interpreter + plugins - new object/image format (64bit) - 64-bit jit
Stef
-- Best regards, Igor Stasenko.
I told you: 2 man/month (not taking NB-FFI into account) On Jun 27, 2013, at 6:26 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
so much? how many men/months?
Stef
On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 14:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
depends what you put into it: - interpreter + plugins - new object/image format (64bit) - 64-bit jit
Stef
-- Best regards, Igor Stasenko.
On 27 June 2013 18:32, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I told you: 2 man/month (not taking NB-FFI into account)
That is a bit optimistic :) But reasonable.
On Jun 27, 2013, at 6:26 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
so much? how many men/months?
Stef
On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 14:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
depends what you put into it: - interpreter + plugins - new object/image format (64bit) - 64-bit jit
Stef
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 27 Jun 2013, at 20:41, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 18:32, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I told you: 2 man/month (not taking NB-FFI into account)
That is a bit optimistic :) But reasonable.
Just to be clear: the goal is to make the current Cog & Stack VMs decent 64-bit apps that can operate on a 64-bit OS without needing special/extra 32-bit libs, while keeping intact the current 32-bit internal memory/pointer model, right ? And that on all 3 platforms ? Make that at least 3 months ;-)
On Jun 27, 2013, at 6:26 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
so much? how many men/months?
Stef
On Jun 27, 2013, at 3:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 14:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi
we got this discussion about the VM on 64 bits so do we try to take the opportunity to get a crowdsource donate button for it?
Esteban/igor what is your estimate for such task?
depends what you put into it: - interpreter + plugins - new object/image format (64bit) - 64-bit jit
Stef
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 27 June 2013 20:51, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 27 Jun 2013, at 20:41, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 18:32, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I told you: 2 man/month (not taking NB-FFI into account)
That is a bit optimistic :) But reasonable.
Just to be clear: the goal is to make the current Cog & Stack VMs decent 64-bit apps that can operate on a 64-bit OS without needing special/extra 32-bit libs, while keeping intact the current 32-bit internal memory/pointer model, right ?
And that on all 3 platforms ?
Make that at least 3 months ;-)
Be careful with using 'decent'. Because to my opinion, i cannot call even our today's 32-bit VMs decent. They are OK as to me. But i want more/better etc before i can call them decent. :) -- Best regards, Igor Stasenko.
Just for the notice, because I stirred up the whole discussion about 64 bit pharo. To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ? I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier. In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit. -- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2013/6/27 kilon <thekilon@yahoo.co.uk>
Just for the notice, because I stirred up the whole discussion about 64 bit pharo.
To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ?
Yeah actually the goal is to allow the user to work on Pharo without installing 32bits lib and to be able to call 64 bits external libraries instead of 32 bits ones.
I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier.
You are right, we don't care about the RAM size, even language as Java does not have a VM with a GC supporting more that much of RAM.
In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit.
-- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me. Le 27 juin 2013 21:43, "Clément Bera" <bera.clement@gmail.com> a écrit :
2013/6/27 kilon <thekilon@yahoo.co.uk>
Just for the notice, because I stirred up the whole discussion about 64 bit pharo.
To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ?
Yeah actually the goal is to allow the user to work on Pharo without installing 32bits lib and to be able to call 64 bits external libraries instead of 32 bits ones.
I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier.
You are right, we don't care about the RAM size, even language as Java does not have a VM with a GC supporting more that much of RAM.
In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit.
-- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
Am 27.06.2013 um 22:33 schrieb "phil@highoctane.be" <phil@highoctane.be>:
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me.
Can you explain what you mean? I cannot see how object spaces can solve the problem. The thing you describe sounds for me is just like starting a second image which is one way to use more than 4GB of RAM. Norbert
Le 27 juin 2013 21:43, "Clément Bera" <bera.clement@gmail.com> a écrit :
2013/6/27 kilon <thekilon@yahoo.co.uk>
Just for the notice, because I stirred up the whole discussion about 64 bit pharo.
To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ?
Yeah actually the goal is to allow the user to work on Pharo without installing 32bits lib and to be able to call 64 bits external libraries instead of 32 bits ones.
I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier.
You are right, we don't care about the RAM size, even language as Java does not have a VM with a GC supporting more that much of RAM.
In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit.
-- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
yeah, that sounds bizarre :) On Jun 28, 2013, at 7:53 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.06.2013 um 22:33 schrieb "phil@highoctane.be" <phil@highoctane.be>:
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me.
Can you explain what you mean? I cannot see how object spaces can solve the problem. The thing you describe sounds for me is just like starting a second image which is one way to use more than 4GB of RAM.
Norbert
Le 27 juin 2013 21:43, "Clément Bera" <bera.clement@gmail.com> a écrit : 2013/6/27 kilon <thekilon@yahoo.co.uk> Just for the notice, because I stirred up the whole discussion about 64 bit pharo.
To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ?
Yeah actually the goal is to allow the user to work on Pharo without installing 32bits lib and to be able to call 64 bits external libraries instead of 32 bits ones.
I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier.
You are right, we don't care about the RAM size, even language as Java does not have a VM with a GC supporting more that much of RAM.
In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit.
-- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
On 28 Jun 2013, at 07:53, Norbert Hartl <norbert@hartl.name> wrote:
Am 27.06.2013 um 22:33 schrieb "phil@highoctane.be" <phil@highoctane.be>:
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me.
Can you explain what you mean? I cannot see how object spaces can solve the problem. The thing you describe sounds for me is just like starting a second image which is one way to use more than 4GB of RAM.
I would also like to know exactly what you mean by 'Object Spaces'. Any references, articles ? Sven
On 27 June 2013 22:33, phil@highoctane.be <phil@highoctane.be> wrote:
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to me.
the only problem is that it is much longer walk to get there than the proposed in this topic.
Le 27 juin 2013 21:43, "Clément Bera" <bera.clement@gmail.com> a écrit :
2013/6/27 kilon <thekilon@yahoo.co.uk>
Just for the notice, because I stirred up the whole discussion about 64 bit pharo.
To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ?
Yeah actually the goal is to allow the user to work on Pharo without installing 32bits lib and to be able to call 64 bits external libraries instead of 32 bits ones.
I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier.
You are right, we don't care about the RAM size, even language as Java does not have a VM with a GC supporting more that much of RAM.
In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit.
-- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- Best regards, Igor Stasenko.
honestly, the unique advantage of having a 64bits vm/image is that we will stop to have the 32bits as a limit to talk with outside world libraries (not a minor thing, IMO). you may think this is not important, since with some work you can still make everything work, but it is: nowadays more and more systems come just in 64bits, and stay in 32bits will doom us in the medium term. also, we will need a better memory manager, who can manage more than 512m efficiently (in fact, it is possible to manage more now, but it system become... well, clumsy :) it is not just the GC, is all the memory manager who we need to take care about, but this is another problem. Esteban On Jun 27, 2013, at 9:32 PM, kilon <thekilon@yahoo.co.uk> wrote:
Just for the notice, because I stirred up the whole discussion about 64 bit pharo.
To my knowledge the whole point of having a 64 bit app is that so that app can access more than 4 GBs of Ram. Is that the case or I have no clue what I am talking about ?
I have read that already Pharo VM has some restrictions on how much ram an image can use. Obviously even for todays standard 4GBs for a single app is a bit excessive but if pharo apps continue to grow in complexity and we start to venture in areas of demanding ram needs , then it wont be hard to brake that 4GB barrier.
In any case maybe before you invest so much effort you must clear up what the real benefits would be for us the users of pharo if pharo goes 64 bit.
-- View this message in context: http://forum.world.st/Pharo-dev-How-do-can-we-set-up-a-crowdsourcing-for-pha... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (8)
-
Clément Bera -
Esteban Lorenzano -
Igor Stasenko -
kilon -
Norbert Hartl -
phil＠highoctane.be -
Stéphane Ducasse -
Sven Van Caekenberghe