Time to express some ignorance here and seek some answers. TTBOMK - 1) I can run 32 bit code on a 64 bit machine with a 64 bit OS. I can never run an app of greater bitwidth then the OS or the processors bitwidth (note the OR, it is not an AND) 2) You talk about 64 bit being slower and more prone to faulting because the integers are twice as large. I can program a 32bit application using 1 bit, 8 bit, 16, or 32 bit variables in Fortran, Java, and VB, so why do you assume that if I intend to store a variable with 240 logical possibilities or perform calculations on this variable I am going to run for double precision 64bit variable just because I am programming for a 64 bit environment? I only took one C class, but I remember multiple variable sizes in it as well. True, if I compile in a 32bit world I have to recompile for 64, but I would have to recompile for PPC or Sparc, so what's the big deal? After a while everyone will have their stuff precompiled for 64 bit. Now it is true that some vendors like Adobe don't have their stuff available in 64 bit yet, but it was ages before they made it available in 32 bit. There is never any love from them. 3) The advantages are in the lager datapath and in the number of registers you can play with. Everyone always complains that the next newest OS is slower then the last, and it is true, my windows 98 was a dog compared to windows 3.1 ;) Is some of this because people are getting used to 64 bit programming, are they perhaps not being efficient with their port? Perhaps, but the fact that some one is willing to do it at all for us is great. 4) I use 32 bit because I only have two needs for 64 bit; DB's moving a lot of data and games. Since I don't have my next big DB running yet and I haven't seen any good games requiring 64 bit, I run 32. But I don't hate the future just because I like to be a late adopter. So, how much of this was wrong? -----Original Message----- From: plug-discuss-bounces@lists.plug.phoenix.az.us [mailto:plug-discuss-bounces@lists.plug.phoenix.az.us] On Behalf Of Chris Gehlker Sent: Friday, November 23, 2007 7:30 AM To: Main PLUG discussion list Subject: Re: ****Re: ****Re: ****Re: ****What's up with 64 bit Linux 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 --------------------------------------------------- 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