Re: [Pharo-dev] How do can we set up a crowdsourcing for pharo
Kilon wrote:
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.
Why? It takes me less than 20 minutes to run out of available ram now, even though my machine has 8 times more. On current hardware, 512GB is a more reasonable maximum size for a single app. Pharo apps have needed more than 4GB for as long as Pharo exists, nearly all Moose applications are strongly limited by it. Philippe wrote:
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to >me.
Not to me. They force me to spend time thinking about partitioning at the moment I don't want to. Current machines support more than 4G/core, so 64 bits flat is needed anyhow. Later binding, I want later binding! And Objects Spaces too. They seem like a good idea. But later :) The java GC situation is ridiculous, and only exists because Oracle wants to sell databases. Stephan
On Jun 28, 2013, at 1:40 AM, Stephan Eggermont <stephan@stack.nl> wrote:
Kilon wrote:
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.
Why? It takes me less than 20 minutes to run out of available ram now, even though my machine has 8 times more. On current hardware, 512GB is a more reasonable maximum size for a single app. Pharo apps have needed more than 4GB for as long as Pharo exists, nearly all Moose applications are strongly limited by it.
Philippe wrote:
Object Spaces with dedicated GC and possibly dedicated cpu looks like a better idea than a flat 64bit VM and OE to >me.
Not to me. They force me to spend time thinking about partitioning at the moment I don't want to. Current machines support more than 4G/core, so 64 bits flat is needed anyhow. Later binding, I want later binding! And Objects Spaces too. They seem like a good idea. But later :)
The java GC situation is ridiculous, and only exists because Oracle wants to sell databases.
not sure, it is not so easy to produce an efficient large memory manager/garbage collector. but anyway, I agree that we need to be able to handle much larger spaces than we can now. Esteban
Stephan
2013/6/27 Stephan Eggermont <stephan@stack.nl>:
Kilon wrote:
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.
Why? It takes me less than 20 minutes to run out of available ram now, even though my machine has 8 times more. On current hardware, 512GB is a more reasonable maximum size for a single app. Pharo apps have needed more than 4GB for as long as Pharo exists, nearly all Moose applications are strongly limited by it.
512 GB is "reasonable" maximum for a single threaded app? Certainly it is "reasonable" high! :-) Altough I think 4GB might be small, for me it is better to think about scaling out, instead of up. Regards,
participants (3)
-
Esteban A. Maringolo -
Esteban Lorenzano -
Stephan Eggermont