View mode: basic / threaded / horizontal-split · Log in · Help
September 24, 2005
Re: D on x86-64?
"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
Re: D on x86-64?
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
Re: D on x86-64?
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
Re: D on x86-64?
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
Re: D on x86-64?
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
Re: D on x86-64?
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
Re: D on x86-64?
[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
Re: D on x86-64?
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)
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home