Simon Marlow <[EMAIL PROTECTED]> writes:
>> So it used more than double the amount of memory.
> Is it reproducible? I expect that the -M value might be exceeeded by
> a small amount sometimes, but double is surprising.
Yes. That is, I was running multiple instances on different CentOS
computer
Ketil Malde wrote:
Ketil Malde <[EMAIL PROTECTED]> writes:
18580 ketil 18 0 1762m 945m 256 D 3.0 93.5 33:52.81 rbr
So it used more than double the amount of memory.
I can provide the source, but perhaps I should mention that the
program basically just builds a large "Map Int Int"
Ketil Malde <[EMAIL PROTECTED]> writes:
> 18580 ketil 18 0 1762m 945m 256 D 3.0 93.5 33:52.81 rbr
>
> So it used more than double the amount of memory.
I can provide the source, but perhaps I should mention that the
program basically just builds a large "Map Int Int". No tricky FFI,
a
I think I complained earlier about '+RTS -MxxxM' not being respected,
but was unable to reproduce the issue. I just saw this again, my
process was, I thought, limited to 800M heap, but, just before I gave
up and killed the process, 'top' told me:
18580 ketil 18 0 1762m 945m 256 D 3.0 9
Hello Ketil,
Wednesday, March 22, 2006, 11:02:49 AM, you wrote:
of course, any complicated algorithm can be a result of long
researches and so we are far from such algorithms. my words is more a
rhetorical point than concrete suggestion. that's real on this moment:
1) tune the ghc algorithm to k
Simon Marlow <[EMAIL PROTECTED]> writes:
> Bulat Ziganshin wrote:
>> and moreover, we should perform compaction immediately when swapping grows.
>> imagine for example algorithm that had 80 mb residency and runs on a
>> machine with 100 mb free. performing compacting GC each time when
>> memory u
Bulat Ziganshin wrote:
and moreover, we should perform compaction immediately when swapping grows.
imagine for example algorithm that had 80 mb residency and runs on a
machine with 100 mb free. performing compacting GC each time when
memory usage grows to 100 mb should be better strategy than wa
Hello John,
Thursday, March 16, 2006, 4:00:34 AM, you wrote:
JM> the best solution would be for ghc's garbage collector to periodically
JM> call getrusage(2) and look at the number of page faults and swaps it is
JM> causing and switch to compaction when it sees a jump in that.
just some more tho
Hello John,
Thursday, March 16, 2006, 4:00:34 AM, you wrote:
>> i suggest checking of AVAILABLE physical ram, that is perfectly
>> possible in windows
JM> the problem is that available physical ram is wasted ram. any good os
JM> will never let there be any available ram because it will fill it u
John Meacham wrote:
On Mon, Mar 13, 2006 at 04:06:59PM +0300, Bulat Ziganshin wrote:
SM> I think what you're suggesting is that the runtime should detect the
SM> amount of physical memory on the system and auto-tune itself to switch
SM> to compacting collection when its residency reaches that
On Mon, Mar 13, 2006 at 04:06:59PM +0300, Bulat Ziganshin wrote:
> SM> I think what you're suggesting is that the runtime should detect the
> SM> amount of physical memory on the system and auto-tune itself to switch
> SM> to compacting collection when its residency reaches that amount. This
> SM
Bulat Ziganshin wrote:
SM> I think what you're suggesting is that the runtime should detect the
SM> amount of physical memory on the system and auto-tune itself to switch
SM> to compacting collection when its residency reaches that amount. This
SM> is certainly something we could do. Bear in
Hello Simon,
Monday, March 13, 2006, 3:40:21 PM, you wrote:
>> just to check available PHYSICAL memory he answered that he don't know
>> that is physical memory, only virtual memory matters
SM> I think that's a mischaracterisation of what I said. Actually I said
SM> that I didn't understand yo
13 matches
Mail list logo
