On Nov 23, 2007, at 12:42 AM, Craig White wrote: > I'm not sure what you mean by 'opposite approach' - their > recommendations are based solely upon the processor in the hardware > you > are using Exactly. And the processors for which x86_64 is recommended are: "Intel Core 2 Duo, Centrino Core 2 Duo, and Xeon; AMD Athlon64/x2, Sempron64/x2, Duron64". The Pentium D used in the Optiplex is *not* on that list. However the Wikipedia entry for x86-64 says: "Intel 64 is Intel's implementation of x86-64. It is used in newer versions of Pentium 4, Pentium D, Pentium Extreme Edition, Celeron D, Xeon, and Pentium Dual-Coreprocessors, and in all versions of the Core 2 processors." So it looks like the recommendation from Fedora is oversimplified. "newer versions" of the Pentium D should be running x86_64 (The dash or the underscore get used interchangeably) > I gathered that the point Jon was trying to make was that the kernel > code loaded at boot signals the 64 bit processor to either emulate 32 > bit operations or 64 bit operations and that could not change until > reboot. I think Jon is simply mistaken here, although I did find a spec sheet on the Pentium D which was somewhat confusing but tended to support Jon's view. In any case, the x86_64 architecture does no have any trouble mixing 32-bit and 64-bit instructions, according to both Wikipedia and my own observation. > As for what may be advantages of 64 bit applications on a 32 bit > OS...I > am not aware that such a thing is possible but this is beyond my > knowledge base I am coming to see that the phrase "32 bit OS" is terribly ambiguous and has led us to mislead each other. See below. Ars Technica has a a good article on why you would want most of the operating system for a 64-bit machine to be 32-bit code. The concept is actually very simple. 32-bit code is much more compact because all the pointers and integers are only half as wide. So less 64-bit code fits in any given amount of cache. Cache misses slow down execution by roughly a factor of 1,000 between level one and level 2; 1,000 between level 2 and main memory and 10,000 between main memory and disk. A modern OS has lots of components, the scheduler, the network code, GUI libraries, that get no benefit from 64-bit code and suffer from more misses. > I almost suspect that this classroom knowledge tidbit probably was > more > specific than an overarching rule - i.e., this might be a Windows > issue > as I understand that there are still many of these issues that > continue > to plague the 64 bit Windows OS. I was long enough ago that 64-bit windows was on the near horizon and there was speculation as to whether they would get it right. No one in the class had signed the NDA to actually see their code. > > > Again, we are over my head here and I am not comfortable spouting > things > that I know so little about but I am under the general impression that > x86_64 code is actually 64 bit code. And I'm increasing under the impression that it isn't except the very small area, basically the virtual memory manager, where it needs to be to support 64-bit applications. Windows got this wrong - basically they went to an all 32-bit or all 64-bit world - and I was initially under the impression that Linux did too. But now I think that linux got it right. I don't know why Windows got it so wrong, those people aren't stupid. If I had to speculate, AI'd guess it had something to do with their ABI. Maybe you simply can't link 32-bit libraries into 64-bit code in the Windows world. Anyway, fun discussion. -- Vegetarians eat Vegetables, Humanitarians frighten me --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss