On Tue, 22 Mar 2005 14:18:13 -0600, Aleksandar Milivojevic <amilivojevic@xxxxxx> wrote: > James Wilkinson wrote: > > Incidentally, I understand that it isn't the 64 bit wide registers that > > are the big performance enhancement in AMD64: it's the extra registers. > > Most programs (at the moment) don't need 64 bits. But 64 bit mode makes > > binaries larger, which means you can get less code into a fixed-size > > cache, slightly slowing things down. > > > > On AMD64, the other benefits (especially the extra registers) outweigh > > this (so 64 bit mode is still faster). On RISC chips with a clean 32 bit > > mode, commercial Unix has often stuck to a 32 bit userland. > > The above two paragraphs depend on sizeof(int). I don't have any AMD64 > around to test, but my guess is sizeof(int) is 8 on it? No, sizeof(int) == 4 still on x86_64. sizeof(long) == 8 == sizeof(void *). James is correct about the large portion of the performance improvement is from having twice as many registers as the x86 line. This means you use the stack less, which reduces the number of (relatively) slow memory transfers. All of the AMD64 CPUs, though have fairly substantial caches. Recently AMD has reduced cache size (L2) to 0.5 MB, but most earlier models (like my clawhammer core) have 1 MB. Granted, this does seem a little small now that Intel seems to have made 2 MB L2 caches the norm (at least on their P4s and Pentium Ms). > If the above is correct, than you are right. The code will get larger > when everything goes double, where it really doesn't need to. > > However, if the aproach was the same as in OSF/1 (alias Digital Unix, > alias Tru64) for Alpha processors and OpenBSD for 64-bit processors > (well, at least those I tried) things are different. On mentioned > operating systems, sizeof(int) is 4, sizeof(long) is 8, and sizes of > pointers and typedefs such as size_t, off_t and similar is bumped to 8 > (OSF/1 time_t is also 8 bytes long). Basically, you are using double > the memory only for storing data types that acutally benefit from being > 64-bit long. Basically, that way you enable all programs access to > large address space and correct handling of large files (even if the > program itself was not written to support them by use of open64() and > related system calls). Yes, x86_64 does do this. The code will still be a little larger due to pointers, longs, immediate constants, and some longer instructions. I think it's the pointers and the immediate constants that cause the greatest concern for code size increases. It's been a while since I looked at this stuff. I think the default data size is still 32-bits in a effort to keep code bloat to a minimum. There is a little bit of information on this at http://www.x86-64.org/ > Of course, than you have small problems with that common programming > error (assumption that sizeof(int) == sizeof(void *), which is plain > wrong). Assigning 64-bit pointer to 32-bit int doesn't really work... Yeah, that can be a problem if you get your hands on some sloppy code. Actually, sizeof(int) == 4 is not even guaranteed in the 32-bit architecture, though it is most often the case. sizeof(long) == sizeof(void *) is supposed to be guaranteed, though. > However, Alpha processors have been around for long enough for that kind > of bugs to be corrected in most of the open source. Speaking of that, I > was compiling Linux kernel couple of minutes ago, and noticed bunch of > "assigment makes pointer from int" (or the other way around?) warnings. > Seems that Linux kernel is not free from those kinds of (basic) > programming mistakes ;-) Hmm, I don't know. Making a pointer from an int shouldn't be too bad (32-bit to 64-bit). Making an int from a pointer (64 to 32) could be a big problem on 64-bit, though it could also work just fine if the pointer is below the 32-bit line in the address space. However, since my kernel runs just fine, I guess this code is not a problem : ). Jonathan
