-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Sep 30, 2005 at 10:13:34AM +0800, James wrote:
> tick-tock-tick-tock-bing! 64 bit ints are touted as being an easier fix than
> re-org'ing the epoch, so 64bit ints WILL happen and 64bit machines are better
> equipped to handle this
>
> Explains: in 2039 the clock (32 bit) will overflow. This is Y2K bug with a
> vengance and a certainty.
Not everyone codes so that time_t is equivalent to int so there's nothing
wrong with time_t being a long (and fix the code that can't handle it).
Furthermore, most people don't hard-code the epoch calculations anyhow;
they just use a library routine. The epoch could move without much breaking.
Finally, by far the most common usage of the unix clock is to subtract
two time_t in order to get a time delta and this will still work correctly
even when you overflow the register (the magic of 2's compliment).
> Will 64 bit ints waste the cache. This is deep dark art, but I believe NOT:
> cache is for speed. speed = 1 access to get the data so ...
> c....... a char in cache
> ss...... a short in cache
> iiii.... a 32int in cache
> llllllll a 64int in cache
I believe that intel already uses larger chunks in cache than that.
The Xeon uses 64 byte chunks for L1 cache and 128 byte chunks for L2 & L3
cache. I'm not an expert on caching algorithms but my understanding
is that reading any part of the chunk will still read from the same
cache entry. Any cache system which forces you to keep multiple copies
of the same data on the same chip is going to be very inefficient.
Cache memory costs a lot in terms of space on the silicon and power
consumption, you really want to make that space count.
Then again, not all programs will have their data conveniently small
so that it fits in cache. Sometimes people want to work with decently
large hash tables.
And to cap off, there are cases where you are going to invalidate your
cache and need a reload... it ain't pretty but it happens sometimes.
Small data is fast data.
- Tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQIVAwUBQz/S68fOVl0KFTApAQIVvw/+NDemLGW3hfOMlsE8rjFa/aTzRJxpx7FH
OJaqZAK3oAJwT3WIW9SJiEklLo/vmi0H8W5SSZPUxAJogVyxN8AaQ1n0r2M8vs5z
A0ckg4mIOrOOUBJj0Jf8HQhWtrklIZWrMJ9GapnAniwoSYfLT6D2zuusutVCNWH5
TakIZiA6AcSx8pD758p4iSfZ5VTDVhXCwTomfzbF39oCaC++e8BLO5xyZRnqEYv4
oFm+xNmCssLM9p/Syhe7f08aYd0IVBsTwZBVTSd81F5UzQ5DOfDm+uDh62t3/Tm4
KIrz10+gyMTLzDxFZCVXtg366OYps20tBKxPGF8VKPNGuZHO7wlQUrjFjLoOdCXN
d1nUqUFreHQsQ9ftsWHa78vOBYhoogJ8wo7k00+6X4IQPFVYYCclyMIk33y7yCsw
ZdIidjEE8U5GYbGzp9oN9QUafkex+5HEB47NMWzexsUEZDvcSLDjJPiVhkug9HSz
vltldirhoa0wnyGME+wSWr1tIj/a0+RT+0TW0lGVfJM4XeICv1adR6EQPhxEB1E+
x1Qp9z2AbYj8HUIqZF3/9pGcvfmiNeXr1JVqH5gf+WVqfuuxw0nwZlfgW14Q+7o1
SsnIlbluMoD8BS0Pw0xWjpUqx67WA2ReJ3dcst4A4rZ2zNJmR1bc3OvRHb8aj3u+
JO3WF0f8xZA=
=Ri52
-----END PGP SIGNATURE-----
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
