September 24, 2005
"Thomas Kühne" <thomas-dloop@kuehne.cn> wrote in message news:dh39av$6ic$1@digitaldaemon.com...
> The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
>
> 1) array indexes
> Changes:
> int -> size_t
> (32 bit systems: uint; 64 bit systems: ulong)
> Consequence:
> maximum array length changed from (int.max) to
> (size_t.max-1) bytes
> Hint:
> use (size_t.max) instead of (-1) to indicate an
> invalid array index

Yes.

> 2) Object
> Changes:
> int Object.toHash() -> size_t Object.toHash()
> Consequences:
> updated your .toHash function signatures

I don't think that one is necessary. The low 32 bits of an address will do fine as a hash.

> 3) TypeInfo
> Changes:
> int Interface.offset() -> ptrdiff_t Interface.offset()
> int TypeInfo.tsize() -> size_t TypeInfo.tsize()
> Consequences:
> check code that uses reflection

Yes.


September 25, 2005

Walter Bright wrote:
> "Thomas Kühne" <thomas-dloop@kuehne.cn> wrote in message
> news:dh39av$6ic$1@digitaldaemon.com...
> 
>>The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
> 
>>2) Object
>>Changes:
>>int Object.toHash() -> size_t Object.toHash()
>>Consequences:
>>updated your .toHash function signatures
> 
> I don't think that one is necessary. The low 32 bits of an address will do
> fine as a hash.

At first I thought staying with 32b hashing is daring. Then I thought, well, (a theoretical upper limit of) 4 billion buckets ought to be plenty.

But consider:

32b hashing, some years from now, would be exactly the same as if we had 16b hashing now. (I assume we all agree on this.)

One would think that 65 thousand buckets ought to be enough for anything today.

Now, if the allocator aligns to ceil(log2(size)), as I think it does, then objects of size 10kB never get to use the 14 lowest bits? That would leave us with 2 bits (equalling 4 buckets), with the 16b hash I'm using as example.

So 16b hashing would be pathetic today. Analogically, 32b hashing has to be equally pathetic on D day.

------------

Totally separate from this, we should promise not to use fixed sizes in things related to architecture. Painting ourselves in the corner now is bad, but the day we get 128b machines, it'll be a disaster. Changing fundamental signatures that day is plain impossible.

(I hear folks crying 64b will last for the next 20 years. I feel I agree. But then I felt like this when we got 32b. And when the PC came with 16b. At that time I was totally comfortable with 8b machines doing text processing, databases, spreadsheets, and accounting.)

What's 20 years in a language's life? Nothing. (Ahhh: unless we think small now!)

------------

Before anybody else gets smart and proposes a genius workaround for 64b architectures, here it is:

int Object.toHash could return its position shifted to right ceil(log2(mySize)) bits.

Cute as this may seem, it's a kludge. And returning int still won't grow with architecture -- only pushing the snow in front of us further ahead, slowly becoming a mountain.
September 25, 2005
In article <4336A712.7060305@nospam.org>, Georg Wrede says...
>
>Walter Bright wrote:
>> "Thomas Kühne" <thomas-dloop@kuehne.cn> wrote in message news:dh39av$6ic$1@digitaldaemon.com...
>> 
>>>The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
>> 
>>>2) Object
>>>Changes:
>>>int Object.toHash() -> size_t Object.toHash()
>>>Consequences:
>>>updated your .toHash function signatures
>> 
>> I don't think that one is necessary. The low 32 bits of an address will do fine as a hash.
>
>At first I thought staying with 32b hashing is daring. Then I thought, well, (a theoretical upper limit of) 4 billion buckets ought to be plenty.

Not necessarily.  Implementors tend to use probing hash tables in instances where memory is at a premium (ie. when they expect the hash table to be extremely large) and this approach necessitates N buckets.  So while I agree that it's unlikely, I'm not sure I'd be willing to assert that no one would ever want to store more than 4 billion elements at once.  After all, arrays have size_t length.


Sean


September 25, 2005
In article <dh39av$6ic$1@digitaldaemon.com>, =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>> I'll start the lazy route by trying to clean up the size_t/uint and ptrdiff_t/int issues in Phobos.
>
>The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
>
>1) array indexes
>	Changes:
>		int -> size_t
>		(32 bit systems: uint; 64 bit systems: ulong)
>	Consequence:
>		maximum array length changed from (int.max) to
>		(size_t.max-1) bytes
>	Hint:
>		use (size_t.max) instead of (-1) to indicate an
>		invalid array index
>
>2) Object
>	Changes:
>		int Object.toHash() -> size_t Object.toHash()
>	Consequences:
>		updated your .toHash function signatures
>
>3) TypeInfo
>	Changes:
>		int Interface.offset() -> ptrdiff_t Interface.offset()
>		int TypeInfo.tsize() -> size_t TypeInfo.tsize()
>	Consequences:
>		check code that uses reflection
>
>Thomas
>

First off - thanks for putting the time into this.

Just wondering though - might it not be better to do this on the latest version of phobos that comes with DMD, so Walter can apply the patch to that (and then the next version of GDC will inherit that anyhow)?

Or will the patch file apply equally well to the latest version as-is?

Thanks,

- Dave

>
>-----BEGIN PGP SIGNATURE-----
>
>iD8DBQFDNSlL3w+/yD4P9tIRAkOIAJkBlfW+XqvdlKfTn9V4rOgUwrMzgQCdGCfN
>FHeDq2KCr8ksp7ZD7AsWpzg=
>=QSOi
>-----END PGP SIGNATURE-----


September 26, 2005
Dave schrieb:
> Just wondering though - might it not be better to do this on the latest version of phobos that comes with DMD, so Walter can apply the patch to that (and then the next version of GDC will inherit that anyhow)?
>
> Or will the patch file apply equally well to the latest version as-is?

I did start with Phobos but realized soon that GPhobos is much easier to port. One of the testing platforms is Win32 compiled with dmc, dmd and win32.mak, so you can use GPhobos with "pure" DMD.

Featurewise GPhpobos-0.15 and Phobos-0.133 aren't that far apart, thus updating the application visibile features is manageable.

Thomas
September 26, 2005
Georg Wrede schrieb:
> 
> 
> Walter Bright wrote:
> 
>> "Thomas Kühne" <thomas-dloop@kuehne.cn> wrote in message news:dh39av$6ic$1@digitaldaemon.com...
>>
>>> The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
>>
>>
>>> 2) Object
>>> Changes:
>>> int Object.toHash() -> size_t Object.toHash()
>>> Consequences:
>>> updated your .toHash function signatures
>>
>>
>> I don't think that one is necessary. The low 32 bits of an address
>> will do
>> fine as a hash.

> Totally separate from this, we should promise not to use fixed sizes in things related to architecture. Painting ourselves in the corner now is bad, but the day we get 128b machines, it'll be a disaster. Changing fundamental signatures that day is plain impossible.

> Before anybody else gets smart and proposes a genius workaround for 64b architectures, here it is:
> 
> int Object.toHash could return its position shifted to right
> ceil(log2(mySize)) bits.
> 
> Cute as this may seem, it's a kludge. And returning int still won't grow with architecture -- only pushing the snow in front of us further ahead, slowly becoming a mountain.

Thanks George for the nice summary.

Thomas
September 27, 2005
[Follow up set to D.gnu]

Here comes a first try to clean up Phobos' 32bit-ism.
The code is based on GDC-0.15's GPhobos and should be featurewise - with
the exception of std.math - behave identical to DMD-0.133's Phobos.

As I haven't yet figured out the nasty bug during module initialization on Linux systems, I can only post a precompiled phobos.lib for 32bit Windows.

If you have a bit time, please relink your applications with this patched Phobpos to help locate all those porting bugs, thanks.

WARNING: this is a very alpha stage and not save for production Especially std.regex and opApply haven't yet been dealt with.

precompiled:
http://gphobos64.kuehne.cn/lib32/

sources: (subversion)
http://gphobos64.kuehne.cn/phobos/

Thomas
September 30, 2005
Has anybody an Idea why
    Object[] o = new Object[1];
could result in
    _d_new(length:4, size:134813823)

Thomas


GC log for GPhobos and DMD 0.134 on Linux below:


_d_newclass(ci = 0x80a00b4, name= Object)

************Gcx::newPool(npages = 1)****************
 p = 0x401c8ff0
p = 0x401c8ff0
ci = 0x80a00b4, ci.init = 0x8, len = 134811439
vptr = 0x8090f3f
vtbl[0] = 0x80a00b4
vtbl[1] = 0x805495c
init[0] = 8090f3f
init[1] = 0
init[2] = 656a624f
init[3] = 7463
init[4] = 80a00b4

_d_newclass(ci = 0x80a5ef0, name= Thread)
 p = 0x401c9fc0
p = 0x401c9fc0
ci = 0x80a5ef0, ci.init = 0x30, len = 134869136
vptr = 0x809f0c8
vtbl[0] = 0x80a5ef0
vtbl[1] = 0x805495c
init[0] = 809f0c8
init[1] = 0
init[2] = 0
init[3] = 0
init[4] = 0

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Object[] o = new Object[1]; // Object.sizeof:4

_d_new(length:4, size:134813823)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

************Gcx::newPool(npages = 131655)****************

_d_newclass(ci = 0x80a5c68, name= AssertError)
 p = 0x401cafe0
p = 0x401cafe0
ci = 0x80a5c68, ci.init = 0x20, len = 134867734
vptr = 0x809eb42
vtbl[0] = 0x80a5c68
vtbl[1] = 0x8055654
init[0] = 809eb42
init[1] = 0
init[2] = 0
init[3] = 0
init[4] = 0

Error: AssertError Failure gcx(1218)


1 2
Next ›   Last »