Although the issue is not perfectly well defined, one can rephrase it as
follows.
1. On the average, a 64 bit executable program will contain longer
instructions than a 32 bit executable, unless specific multiple
instructions are packed into a single 64 bit word. Typically, an
instruction will be a single word (32 bits on a 32 bit ISA, 64 bits on a
64 bit ISA). An address will typically be a single word as well, so
that only non-address data (e.g., a character) will occupy less. How is
a single character C++ string stored (that is, 2 bytes -- character
followed by null terminator) -- packed or full word? I would need to
read the actual glibc and OS source code implementation, or run test
programs -- does anyone happen to know?
2. Based on (1), both more RAM and more hard drive space will be
required. In particular, for the same amount of RAM in bytes, a 64 bit
machine has half the words of a 32 bit machine.
I can do tests on my fixed workstation (64 bit) versus my present laptop
(32 bit), both SL 6x, for comparison, and will do so if needed. On the
workstations, we guessed and simply put more RAM and hard drive capacity
(16 Gbytes on a general purpose workstation -- more on a 3D
visualisation unit) and at least 1 Tbyte of total hard drive capacity
when we moved the workstations from 32 bit SL 5 to 64 bit SL 6. The
CPUs in all cases are some version of X86-64. Our typical workstation
laptop has much less of both, and will need to be upgraded. I do not
use SSD drives in general because of the relative cost, although we are
considering these for those applications that need higher throughput
hard drive access.
Again, if anyone has done measurements in a X11 GUI (e.g., Gnome)
environment running applications such as Wolfram Mathematica, Scilab,
UCSF Chimera, Oracle VirtualBox with MS Windows 7 guests, etc., for
comparison, the results would be appreciated. Otherwise, I will report
back what we find as we switch laptops to X86-64 SL 7x.
Yasha Karant
On 07/08/2014 09:25 AM, Konstantin Olchanski wrote:
On Tue, Jul 08, 2014 at 09:07:41AM -0700, Yasha Karant wrote:
As a full IA-32 environment will no longer readily be available as
an off-the-shelf EL distribution (that is, the kernel is 64 bit,
etc.), a practical question:
how much additional RAM and hard drive space is required by this
X86-64 implementation?
Your question is not well defined.
I know that 64-bit SL6 runs in 1GB RAM and 32-bit Fedora 20 (read: SL7) runs in
0.5GB RAM.
I also know that this is not useful for you.
You want to know how much RAM is "required" for interactive desktop/laptop use.
My counter question is: by "required" you mean:
a) the computer boots
b) you can login
c) the mouse does not move too slowly
d) you can watch youtube videos
e) d) but without stuttering
f) e) but while reading the New York Times web
g) the html5 video ads on the New York Times web run without stuttering
h) ...
I can split the hairs even finer, but I hope you see my meaning.
The old wisdom for memory is: required memory is "as much memory as you can
afford",
which at current RAM prices means "as much as fits into your machine".
On the storage side, you want to replace all your laptop HDDs with 120GB SSDs.
(Bigger SSDs
are too expensive *and* too small at the same time).
K.O.
This is not an issue for our fixed workstations and servers, but it
is for our laptop workstations (all of which have X86-64 CPUs of
some generation). I know that the increase is more than a
multiplier of one and less than a multiplier of two, and I know that
in most cases, a 64 bit implementation can be "shoehorned" into the
same resources as used by a 32 bit implementation, but "shoehorned"
is not the same as effective use.
I am asking for practical, observed data, not theoretical
calculations. We need to plan for the upgrade/replacement of
workstation laptops (e.g., more RAM, larger hard drives).
Yasha Karant
On 07/08/2014 01:59 AM, Stephan Wiesand wrote:
On 2014-07-08, at 10:19, Jim McCarthy <[email protected]> wrote:
On Mon, 7 Jul 2014, Connie Sieh wrote:
I note that only X86-64 is available; have I missed something about
supported ISAs, or will there also be an IA-32 port/distribution as
well?
Yasha Karant
TUV is only releasing X86-64 .
-Connie Sieh
Is this for TUV "v7 ALPHA", or is this to become 'the new normal' going
forward ?
If no more IA-32 support, what would it take to convince the binutils (?)
development powers-that-be to make available for X86-64 the ld linker option
"-taso" (truncated address space option). Back in the day [1], this option
existed on Red Hat Linux for DEC Alpha, and the net effect on that 64-bit
machine was to create an executable in which memory addresses were
restricted to the lower 32-bits of address space. Legacy source code that
used 32-bit (4-byte) integers as pointers to memory addresses could
therefore be compiled (in gcc, the "-Wl,-taso" option would pass "-taso"
along to the linker), built, and run on the 64-bit machine, albeit without
taking advantage of the additional memory address space available on the
64-bit machine (e.g., the DEC Alpha processor family).
Most unfortunately, the ia64 (Itanium) binutils ld linker never had this
feature that appears to have withered away with Linux for DEC Alpha, nor has
the X86-64 binutils ld linker had this feature either. So in my case I've
been hanging onto IA-32 as my SL platform-of-choice. But if IA-32 is no
longer going to be offered, might there be value in resuscitating the
"-taso" option for the linker in X86-64 ? From my perspective this only has
an upside, for those that want/need it ... is there a hidden downside I
don't see ?
The toolchain builds ia32 executables (gcc -m32 , ld -m elf_i386).
And unlike ia64, x86_64 runs them without performance penalty.
