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:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Tue, 8 Jul 2014 09:25:23 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
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.
> >

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2