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 <[log in to unmask]> 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.
>>>