No, sizeof(int) == 4 still on x86_64. sizeof(long) == 8 == sizeof(void *).
Thanks for this info. From all the talks about increased code size I was affraid ints were 8 bytes long. Huh, happy to hear assumption I made was wrong.
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).
Yes, more registers and more cache, and things get much faster. Digital went that route many years before. Anybody remember Alpha processors with 8MB of cache a while back? Those were fast beasts. And even the basic Alphas had considerably more cache than competition of that time. Too bad Alpha never really cought on as mainstream processor. And MS even had Windows NT ported to it (however, it didn't made use of undelying 64-bit architecture). I guess it was (mostly) Digital's price tag that killed it. Or maybe it was simply too much ahead of its time. Or maybe it was simply Compaq (who was never really interested in Digital's advanced technology to start with) that totaly killed it off. Too bad, it was (IMO) about the only RISC architecture that had a chance against Intel line of processors (mostly because it was designed to use off shelf PC components). Plus it was clean 64-bit architecture, with no 32-bit past to worry about.
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/
My experience with Alpha processors and competing 32/64-bit counterparts of that time (UltraSparc for example) was that small increase of size code is mostly overrated. In real-world, it was not much of an concern. If 256 megs was enough to make 32-bit application happy on UltraSparc, 256 megs was enough to make it happy on completely 64-bit Alpha. On UltraSparc itself, running 32-bit vs 64-bit kernel has almost no performance penalty in real world applications.
So I wouldn't waste much time worrying about that. Yeah, in lab tests you might see some slowdown. But when you load your applications and start using the system in real world, you are not going to see any noticable performance degradation (even if number of registers and cache is the same). Add addtional cache and registers that you get when swtiching to AMD64's 64-bit mode, and as both you and James wrote, things get actually much faster. Add to that ability that all applications are able to handle large files without being specifically modified for that is big enough bonus on its own.
As for mixing 32/64-bit libraries on the system... I was using 32/64-bit mix of libraries under Solaris since UltraSparcs came around, and I always found it to be major pain in the ass (to the extent that you simply give up and don't use 64-bit in userland at all, unless you really really have to). I've played for couple weeks with Aurora (port of Fedora to sparc64). And found that it was also a pain in the ass there. At the end, I simply went OpenBSD route for that machine, things simply worked better (Aurora is still kind of experimental project), and there's no mixing of 32bit and 64bit userland (hip hip huray). At least not that I noticed. Hopefully the approach in Fedora AMD64 port isn't the same as in Aurora sparc64 port.
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 : ).
Well, who knows, maybe it was long and not int... On i386, int = 4, long = 4, long long = 8. As you wrote, on x86_64, int = 4, long = 8, long long = 8 (I guess?). If that was the case, or if there are ifdefs in the code for case when you compile for 64bit, this might not be an issue (not an example of clean programming, but not really an issue either).
I'll pay attention next time I need to recompile kernel. Which might not be anytime soon (I recompiled kernel to test patch for bug #151284, rather nasty NFS problem, you might not want to use NFS for anything important until it is fixed, or you might loose your data).
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
