Tue, 11 Aug 2009 12:58:59 +, language_fan thusly wrote:
> I even think that if your OS supports page
> files, it doesn't matter if the memory is on chip or disk - if the
> memory is split 3/1 for processes and kernel, you should be able to
> allocate 2 GB easily.
For example my system has 5GB
Mon, 10 Aug 2009 14:15:41 -0400, bearophile thusly wrote:
> Steven Schveighoffer:
>> My point is, don't count on having 2GB of usable space even if you
>> physically have 2GB of RAM, it may not be the case.
>
> I was looking for using 1.8 GB not 2.
>
>
>>Better off to not desire than to complai
Reply to Steven,
On Sun, 09 Aug 2009 15:51:46 -0400, bearophile
wrote:
grauzone:
Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array
:-)
hehe. Not necessarily.
There are often hardware/OS limitations. For example, many 32-bit
Intel c
Jeremie Pelletier:
>I can't even think of an use for such large arrays. There is always a way to
>split the allocation in smaller ones which will be easy to map in the
>available virtual memory space.<
You not being able to imagine a good use case doesn't imply there isn't one :-)
This program
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
http://www.digitalmars.com/d/archives/digitalmars/D/OPTLINK_and_LARGEADDRESSAWARE_88061.html
bearophile wrote:
> In a small program on Windows XP I have to allocate a large chunk of RAM,
> about 1847 MB of RAM. This PC has 2 GB RAM. So I use std.c.st
bearophile Wrote:
> Robert Fraser:
> > I agree it's a bug, and probably a rather major one. However in a real
> > use case, any program that needs 1800+ MB arrays should be 64-bit only.
>
> In that program there's essentially just that large array.
> What is the size of biggest array you suggest
On Mon, 10 Aug 2009 14:15:41 -0400, bearophile
wrote:
Steven Schveighoffer:
My point is, don't count on having 2GB of usable space even if you
physically have 2GB of RAM, it may not be the case.
I was looking for using 1.8 GB not 2.
Better off to not desire than to complain about edge co
Steven Schveighoffer:
> My point is, don't count on having 2GB of usable space even if you
> physically have 2GB of RAM, it may not be the case.
I was looking for using 1.8 GB not 2.
>Better off to not desire than to complain about edge conditions based on
>hardware limitations.<
With C I ca
On Sun, 09 Aug 2009 15:51:46 -0400, bearophile
wrote:
grauzone:
Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array :-)
hehe. Not necessarily.
There are often hardware/OS limitations. For example, many 32-bit Intel
chipsets support 4G
Robert Fraser:
> I agree it's a bug, and probably a rather major one. However in a real
> use case, any program that needs 1800+ MB arrays should be 64-bit only.
In that program there's essentially just that large array.
What is the size of biggest array you suggest to use in a D/C program on a 3
bearophile wrote:
grauzone:
Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array :-)
I agree it's a bug, and probably a rather major one. However in a real
use case, any program that needs 1800+ MB arrays should be 64-bit only.
grauzone:
>Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array :-)
>You know you must check return values.<
In real programs I check the return value of malloc, of course.
>The D allocation probably fails due to memory fragmentation (just a gue
bearophile wrote:
Frank Benoit:
Is it the malloc that fails (returning null) or the handling of the block?<
It's the filling of the memory block. malloc by itself doesn't crash.
Then what is there to complain? You know you must check return values.
The D allocation probably fails due to mem
Frank Benoit:
>Is it the malloc that fails (returning null) or the handling of the block?<
It's the filling of the memory block. malloc by itself doesn't crash.
-
Robert Fraser:
> Have you tried with DMC?<
I have done a test with MDC too now.
// D code
import std.c.stdlib:
bearophile wrote:
I don't think so, I am running a 32 bit GCC on a 32 bit XP operating system.
I think the bug is elsewhere (in DMD).
Have you tried with DMC?
Frank Benoit:
>Is it the malloc that fails (returning null) or the handling of the block?<
The malloc, as I have written. But only when used by DMD.
Jeremie Pelletier:
> Your C program probably compiled in 64bit, which has MUCH more room for
> virtual memory.
I don't thi
bearophile schrieb:
> In a small program on Windows XP I have to allocate a large chunk of
> RAM, about 1847 MB of RAM. This PC has 2 GB RAM. So I use
> std.c.stdio.malloc(), with DMD v1.042 (or v2.031). But it's not able
> to allocate it, and produces at runtime: Error: Access Violation
>
> An eq
bearophile Wrote:
> In a small program on Windows XP I have to allocate a large chunk of RAM,
> about 1847 MB of RAM. This PC has 2 GB RAM. So I use std.c.stdio.malloc(),
> with DMD v1.042 (or v2.031). But it's not able to allocate it, and produces
> at runtime:
> Error: Access Violation
>
> A
In a small program on Windows XP I have to allocate a large chunk of RAM, about
1847 MB of RAM. This PC has 2 GB RAM. So I use std.c.stdio.malloc(), with DMD
v1.042 (or v2.031). But it's not able to allocate it, and produces at runtime:
Error: Access Violation
An equal program written in C and c
19 matches
Mail list logo
