This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?

Andrew Haley wrote:
Darryl Miles writes:
> Andrew Haley wrote:
> I'm not aware of a small memory model until now, let alone that I maybe > actually using it already and that its already what I'm making an > inquiry about.

Reading the gcc documentation would help you here.  Section 3.17.13,
Intel 386 and AMD x86-64 Options.

Its just a shame that section number related to a different CPU depending upon which version of GCCs documentation you are looking at.

Ah found it for those following:

I think the main point I was getting at was this ABI would run within a 32bit address space at runtime (just like 32bit code does). It would be possible for it to see and use the 64bit version of kernel calls however, even if the values for stuff like mmap() always returned within the bottom 4Gb address space.

The purpose of the new ABI was to make use of AMD64/EMT64 features knowing there is a runtime guarantee they are available. This would untimely end up with an entire distribution being recompiled for this ABI to see the speed benefits (if there are any to be had?).

 > I presume all the memory is eaten up dealing with 64bit issues both
 > Mozilla (using XPCom) and Eclipse (running in a Java JVM) make
 > extensive use of pointers.  Although Mozilla is a little harder for
 > me to measure comparatively but I've never gotten it over 1Gb
 > Resident Set Size (with no swap in use).

That's interesting.  I certainly have seen some increase in memory
consumption goinf from 32-bit to 64-bit applications on x86_64, but
the fact that in your case it more than doubles is come cause for
concern.  Even if pointers were 50% of the allocated memory pool,
which is a pretty extreme assumption, that would only increase memory
use by 50%.  In your case, however, memory use has increased by 150%.
This needs explanation.

There is a possibly of extra padding alignment issues (so there maybe benefits within these applications to reordering stuff to account for 64bit alignment rules).

There is increased stack size needs and increased stack usage in both these apps which make use of many threads.

I'm not sure if mmap() files that are also paged in the RSS count, as I guess in the 32bit runtime model the strategy for using mmap() to access files maybe different to 64bit. For example I had to increase the open fd limit on Eclipse to 2048 since I could easily make it break the default 1024 limit from doing a complete workspace rebuild. Most of these open files are due to mmap()s.

Maybe there are other reasons I can't think of right now.

Thats a job for someone, ensure enough information is emitted in the -g3 debug information going into the executable to reconstruct all structures/datatypes so that a tool could extract the amount of wasted padding and calculate the potential for savings to be made through reordering structure members and the like.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]