Gilles Gravier wrote:
> UTF-32 uses 32 bit words...

UTF-8 uses 8-bit bytes. MS claims or claimed that UTF-16 is the best
performance/memory trade-off. I doubt that's true for America/Europe though as
90% of their characters fit into ASCII or Latin 1. Unicode is only 21-bits
wide, so UTF-32 is almost always a waste of memory/bandwidth. It's mostly
useful for manipulation of single characters albeit a lot of that is biased by
the use of C or C-like languages as anything else would be hard to write,
optimize and maintain manually. Of course it also depends on what your
input/output encoding is. MS uses UTF-16 in a lot of places whereas Unix
systems typically use UTF-8 when it comes to Unicode. Char in Java is surely
a funny disaster because you have to put up with Surrogates nowadays.

I wonder, do you code in assembler (because you seem to think in machine code)?
Has it ever occured to you that you could handle two 32-bit items at a time in
a 64-bit machine? This has been a standard trick whenever the bitwidth was
increased.  It's awkward to do this manually but a compiler can often do this
transparently.  Do you think a high-level language has to map source code as
naively to machine code as you imply?

> Nevertheless, you have to do a compromise between the current machine 
> architectures, the current running applications and their actual 
> requirements...

That's true for every fixed bitwidth or architecture. It's also obvious that
there's always a transition period during which code will not be as optimized
as it could be.

> Today, running a 64 bit OS is not often a requirement. If you *DO* get 
> performance increases... then do use it. If you don't... get back to 32 
> bits... unless you really need to manipulate 64bit data structures...

There are already a lot of 64-bit data structures. Even your ls example has
them: off_t. I believe the burden is yours to prove that there is at least on
average a disadvantage for 64-bit. No doubt there may and will be a
disadvantage for cases in which pointers or non-compact structures are used
excessively. It's just a question whether these cases actually matter or
outweigh the advantages and whether these aren't trivially to fix then.

Actually the engineers of the AMD64 could use a lot of experience since 64-bit
computing was anything but new when it was introduced. For example, Alpha
suffers from pretty large code increase. For AMD64 this is not the case. I've
read the code overhead is as low as 10% on average and that should be easily
amortized by having more registers. Now, if AMD64 would actually offer these in
32-bit mode just like the i386 could run 32-bit code even in real-mode (albeit
with a prefix penalty), 64-bit mode would likely be less attractive.

Don't CC me, thanks.

-- 
Christian