****Re: ****Re: ****Re: ****What's up with 64 bit Linux

[Bryan O'Neal]

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 at lists.plug.phoenix.az.us
[mailto:plug-discuss-bounces at 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 at lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss