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:
Reply To:
Date:
Tue, 8 Jul 2014 19:01:13 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
On Jul 8, 2014, at 2:12 PM, Brett Viren <[log in to unmask]> wrote:

> Yasha Karant <[log in to unmask]> writes:
> 
>> how much additional RAM and hard drive space is required by this
>> X86-64 implementation?
> 
> The memory usage going from 32 to 64bit x86 really depends on the code
> you run.  My understanding is it boils down to how much of the job's
> memory is made up of pointers as compared to other data types that are
> invariant under this bit change.  This can vary a lot and of course it
> matters what the absolute memory usage is to begin with.  If you are
> concerned you should benchmark your actual code on both bit'isms.
> 
> But, I can relate a few data points.
> 
> The jobs we tend to run here are ~1-2GB to start with and I've seen ~50%
> increase in memory usage for the same code complied in 32 and 64 bits.
> These jobs come from relatively large C++ code bases and the code tends
> to be written for functionality first and size optimization later (if
> ever).  I imagine they represent a, if maybe not the, worse case.
> 

Of course, you can still compile apps 32 bit if more appropriate for your needs.

ATOM RSS1 RSS2