I'm afraid, a factor of 2 is too small. If an application needs gigabytes, you'll have hard time trying to convince it to not use more than 4 gigs. Or more specifically between 2 and 4 gigs.

Your examples don't specify if those applications needed large contiguous allocations (which is another problem in itself), only a memory consumption. Actually a program can consume more memory in small allocations, because this way it can use fragmented address space to the fullest.

On Thu, 04 Apr 2013 15:10:28 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/2/2013 8:10 PM, Steven Schveighoffer wrote:
>> On Tue, 02 Apr 2013 16:32:21 -0400, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>> For example, with a signed array index, a bounds check is two comparisons
>>> rather than one.
>>
>> Why?
>>
>> struct myArr
>> {
>>     int length;
>>     int opIndex(int idx) { if(cast(uint)idx >= cast(uint)length) throw new
>> RangeError(); ...}
>> }
>
> Being able to cast to unsigned implies that the unsigned types exist. So no improvement.

The issue is the type of length, not that uints exist.  In fact, opIndex can take a uint, and then you don't need any casts, as far as I know:

int opIndex(uint idx) { if(idx >= length) throw new RangeError(); ...}

I think length will be promoted to uint (and it is always positive), so it's fine, only requires one check.

-Steve

BTW don't we already have a hungry application *with* unsigned integers?
http://d.puremagic.com/issues/show_bug.cgi?id=4236
http://d.puremagic.com/issues/show_bug.cgi?id=6498
http://d.puremagic.com/issues/show_bug.cgi?id=3719

http://d.puremagic.com/issues/show_bug.cgi?id=4984 - and who reported this?

On Thursday, April 04, 2013 21:39:35 Kagamin wrote:
> BTW don't we already have a hungry application *with* unsigned
> integers?
> http://d.puremagic.com/issues/show_bug.cgi?id=4236
> http://d.puremagic.com/issues/show_bug.cgi?id=6498
> http://d.puremagic.com/issues/show_bug.cgi?id=3719
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=4984 - and who reported this?

I wasn't arguing otherwise. Some applications need 64-bits to do what they do. My point was that with 32-bit programs, using unsigned integers gives you lengths twice as long, so it's quite possible for a 32-bit program to work with size_t being unsigned but not work if it were signed. But regardless of whether size_t is signed or unsigned, there's a limit to how much memory you can deal with in a 32-bit program, and some programs will need to go to 64- bit. It's just that if size_t is unsigned, the limit is higher.

But I would point out that the bugs that you listed are not at really related to this discussion. They're about dmd running out of memory when compiling, and it's running out of memory not because it needs 64-bit to have enough memory or because size_t is signed (because it is) but because it doesn't reuse memory like it's supposed to. It generally just eats more without releasing it properly. It should be perfectly possible for a 32-bit dmd to compile those programs without running out of memory. And if that issue has anything to do with this discussion, it would be to point out that dmd's problems would be made worse by making size_t signed, which would just underline the fact that making size_t signed on 32-bit systems would make things worse (though dmd is currently written in C++, so whether size_t is signed or unsigned in D doesn't really matter for it at the moment).

- Jonathan M Davis

On Friday, 5 April 2013 at 01:26:27 UTC, Jonathan M Davis wrote:
> But I would point out that the bugs that you listed are not at really related
> to this discussion. They're about dmd running out of memory when compiling,
> and it's running out of memory not because it needs 64-bit to have enough
> memory or because size_t is signed (because it is) but because it doesn't
> reuse memory like it's supposed to. It generally just eats more without
> releasing it properly. It should be perfectly possible for a 32-bit dmd to
> compile those programs without running out of memory. And if that issue has
> anything to do with this discussion, it would be to point out that dmd's
> problems would be made worse by making size_t signed

How is that if the problem is not in size_t? If dmd would need a large array, it won't be possible to solve by properly releasing memory: if the array is needed, no matter what you release, nothing you can do with that array. The issues show a real memory consumption mechanics: in a case, when an application needs gigabytes, it won't stop at 4 gigs just *because* there is 32-bit limit, so if uint buys you anything, it's too negligible to be considered: it's much easier to migrate to 64-bit than playing russian roulette pushing limits of 32-bit and see whether you hit them.