HLFS 64bit again

goodoldmarty at gmail.com goodoldmarty at gmail.com
Tue Dec 11 02:45:34 PST 2007

Hash: SHA1

> Does it make sense to do that? PAE is not my favorite feature at all.
> 64gb on a 32 bit arch is really a bad kludge. Its an unpopular feature
> in linux already.
You tell me. Anyone knows data fetches from memory, even using PAE are
way faster than hitting a disk. No, the code is not efficient, but the
same trick was done when 8 bit moved to 16, and 16 to 32, and is still
done in all the 64 bit instructions today.
Abstracting 2 discrete 32 bit CPU's to make 1 64 bit CPU is also just
another kludge. The purpose is not related to performance. The purpose
is to provide a migration path for marketing the first generation of
real 64 bit processors. Without a codebase they have absolutely no
market for their new chips.
It's only about the greedy corporations getting rich using those
marketing acronyms you so humorously embrace.

> What are you using on your quad core? 32 bit linux and 32 bit userspace?
32 bit of course, and that is logical, but irrelevant. The quad is my
workstation. I have 4-32 bit processors. They have large caches. I need
'only 4G' shared memory. I run a dist on it, not HLFS. Most of my linux
apps are highly threaded. More execution units mean fewer context
switches. This is efficient use of hardware, and runs way faster than if
I was using apps compiled with any 64 bit toolchain.

Marty B

- --
Putting Microsoft in a computer is like putting screen doors in a
submarine. Hopeless.
Version: GnuPG v1.4.5 (GNU/Linux)


More information about the hlfs-dev mailing list