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
smime.p7s
Description: S/MIME cryptographic signature
