gcc behavior on memory exhaustion
Andrew Roberts
andrewm.roberts@sky.com
Fri Aug 11 03:09:00 GMT 2017
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:
aarch64
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
arm
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...
Thanks
Andrew
More information about the Gcc
mailing list