SCIENTIFIC-LINUX-USERS Archives

April 2010

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:
Stephan Wiesand <[log in to unmask]>
Reply To:
Stephan Wiesand <[log in to unmask]>
Date:
Wed, 28 Apr 2010 18:58:04 +0200
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2135 bytes) , smime.p7s (2302 bytes)

On Apr 27, 2010, at 00:15 , Brett Viren wrote:

> We recently started running our C++ analysis code on 64bit SL5.3 and
> have been surprised to find the memory usage is about 2x what we are
> used when running it on 32 bits.  Comparing a few basic applications
> like sleep(1) show similar memory usage.  Others, like sshd, show only a
> 30% size increase (maybe that is subject to configuration differences
> between the two hosts).
> 
> I understand that pointers must double in size but the bulk of our
> objects are made of ints and floats and these are 32/64 bit-invariant.
> I found[1] that poorly defined structs containing pointers can bloat
> even on non-pointer data members due the padding needed to keep
> everything properly aligned.  It would kind of surprise me if this is
> what is behind what we see.
> 
> Does anyone have experience in understanding or maybe even combating
> this increase in a program's memory footprint when going to 64 bits?

Is it real or virtual memory usage that's increasing beyond expectations?

Example: glibc's locale handling code will behave quite differently in the 64-bit case. In 32-bit mode, even virtual address space is a scarce resource, while in 64-bit mode it isn't. So in the latter case, they simply mmap the whole file providing the info for the locale in use, while in the former they use a small address window they slide to the appropriate position. The 64-bit case is simpler and thus probably less code, more robust and easier to maintain. And it's probably faster. The 32-bit case uses less *virtual* memory - but *real* memory usage is about the same, since only those pages actually read will ever be paged in. This has a dramatic effect on the VSZ of "hello world in python". It does not on anything that really matters - in particular, checking the memory footprints of sleep & co. is not very useful because they're really small compared to typical HEP analysis apps anyway.

What are your actual figures?

> Thanks,
> -Brett.
> 
> [1] http://www.codeproject.com/KB/winsdk/Optimization_64_bit.aspx#IDAJLKNC

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany



ATOM RSS1 RSS2