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
(text/plain)