SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Tue, 8 Jul 2014 09:07:41 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
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?

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.
>

ATOM RSS1 RSS2