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