Nice jab at Emacs ;)

Posted Apr 24, 2003 2:32 UTC (Thu) by proski (subscriber, #104) [Link]

How come GCC doesn't have a "compile as lower bit-width" optimisation?

This would have to be done across the board. Not just cat, but also libc would have to be recompiled. It int is 16-bit for an application and 32-bit for libc, such application would be unable to call libc functions without some kind of conversion of all data passed to and from those functions.

Another problem is that such optimization would be quite inefective on some architectures, including i386. You can have either 32-bit code that uses 32-bit and 8-bit registers, or 16-bit code that uses 16-bit and 8-bit registers. Using a 16-bit register in 32-bit code or vice versa requires a special instruction prefix.

Finally, there are very few applications that would benefit from such optimization. cat spends most time in libc and kernel. Any large program needs to address more than 64k. Programs doing heavy calculations with little code would still benefit from 32-bit bus width, given that the modern processors have on-die cache sufficient to keep the whole program and make memory access speed a non-issue.

Now, going from 32-bit to 64-bit is different because:

1. Processors don't have 4Gb cache yet
2. There is a lot you can do in 32-bit applications
3. You can have a good 32-bit operating system

My guess is that that the transition is going to be more painful than going from 16-bit to 32-bit, and that there will be a lot of "partially 64-bit" software, including operating systems.

Posted Apr 24, 2003 2:33 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

yes there are people who have looked at things like 'cat' in 32 bit and 64 bit mode. there have been discussions on this topic on the kernel mailing list a few times, this is in part why you can run the PPC with a 64 bit kernel and 32 bit userspace (and why people want to)

it turns out that if you have 64 bit kernel support simple tasks like cat really don't get any faster if you make cat 64 bit as well, and in some conditions actually make it slower due to the cache effects of the larger code

the Opteron is even better in that it appears to allow you to run a mixed 32/64 bit userspace so programs that don't benifit from the 64 bit mode can remain small while those that do can be compiled in 64 bit mode to gain the advantages

Posted Apr 24, 2003 8:02 UTC (Thu) by decaffeinated (guest, #4787) [Link]

As I recall, that's

Eight Megs And Continuously Swapping

Posted Apr 24, 2003 9:18 UTC (Thu) by james (subscriber, #1325) [Link]

From the article:

Building "cat" as a 64-bit application can only serve to make it bigger and slower. So a processor with native 32-bit support is a good thing.

Actually, on the x86-64 architecture, the "slower" bit is dubious.

In 32 bit mode (which is designed to run existing binaries without modification), programs only have access to the x86's eight general purpose registers, and not all of these are really general purpose. In 64 bit mode, AMD have added an extra eight.

This means that x86-64 binaries have to load and store data to (usually cache) memory less often. This means that there are usually less instructions for the processor to decode.

It also means that compilers have more registers to play with when optimising. On the x86, there is often a limit to the amount of instruction-level parallelism that compliers can get out of source, simply because there aren't enough registers to spell out that several operations can happen at the same time. The extra eight registers are supposed to make this sort of optimisation a lot easier.

James.