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: gcc behavior on memory exhaustion

On 11/08/17 02:09, Pedro Alves wrote:

Meanwhile, maybe just having the driver check for SIGKILL and
enumerate likely causes would be better than the status quo.

Pedro Alves

I agree, having some indication it MIGHT be out of memory would stop people wasting a lot of time, and avoid spurious bug reports.

Meanwhile, I'm testing memory usage and compile times with my code on gcc 5.4.0, 6.4.0, 7.2.0 and 8.0.0, across x64, arm and aarch64.

I'll file a bug report on the memory-hog issue after I've narrowed down the issue. There certainly does seem to be far worse performance on aarch64 vs arm.

Here's a flavour, for a single C++ file:


GCC    CompileTime    MemoryUsed

5.4.0    4:18.24    357328

6.4.0    2:57.14    730020

7.2.0    3:03.38    735748

8.0.0    3:29.16    837316


5.4.0    3:39.20    247696

6.4.0    2:15.41    287904

7.2.0    2:22.85    294324

8.0.0    2:41.79    306032

So there has been a massive blow up in memory usage on aarch64 vs arm.

While compile times for a single file are better (and its not yet pagefaulting). For multiple files I'm getting 400+ pagefaults while building the entire project, vs none for arm.

If anybody has some suggestions for things I should test I'll give it a go. I'll also play with:

--param ggc-min-expand= --param ggc-min-heapsize=

Is there a way of getting a list of individual optimizations enabled by -O3, so I can try removing individual ones?

BTW the code is very simple and dumb. Its an automatically generated file which just populates a std::map using 2330 inserts.
I'm sure there are better ways of doing this, but never discount how dumb your users are...



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