clang memory usage vs. gcc (and OS X 10.8, 10.9, ...)

[Christopher Jones]

Hi,

On 16 Mar 2014, at 11:03am, René J.V. Bertin <rjvbertin at gmail.com> wrote:

> On Mar 16, 2014, at 11:51, Christopher Jones wrote:
> 
>> Any reason you are using clang 3.3 though ? Have you tried a newer clang version. Macports Clang 3.4 or 3.5 compilers ? I was unable to do this for my issue, 3.3 was the only compiler I had available, but I would be very interested to know if the issue goes away in a newer release.
> 
> For some reason I haven't been able to install MacPorts clang-3.4 yet, and when I built from source a while ago it didn't work. But the test I did under Linux was with clang-3.4, so I guess we're dealing with an issue that's inherent to clang here. It tooks about 1.5 hours to compile there, but without a comparison of the g++ numbers that's just an indication that an AMD C60 netbook is a slug :)

What OSX version are you running ? 3.4 and 3.5 install just fine for me on OSX 10.9… No idea if clang 3.4 or 3.5 are supposed to work on older OSX releases (I know the converse has problems, clang versions older than 3.3 do not install on OSX 10.9).

>> Won’t work. There are many more differences than just resolving libraries at the link step (Differences in the API of std::string classes for instance). You have to compile *and* link against libc++, using the same compiler, which means clang.
> 
> Damn. Fortunately I just learned that gmic isn't central at all to Calligra (or even to its Krita component), so the easy way out in this particular case is to disable it when clang is used. But maybe one ought to file a report with Apple or the clang project, as I'm sure there are other cases where compiler memory usage become a serious obstacle.
> Heck, it even looks as if clang uses a single process that handles all the subsequent steps for which traditional compilers use different applications (and it's my experience that -pipe is rarely a good idea for big projects with parallel building). Thus, if it's the preprocessor that needs those 20GB of memory, the footprint continues to hurt performance of all subsequent steps, which would explain why I see a clang process that's sitting at 5-15% CPU usage for such a long time. Very annoying if the rest of the machine grinds to an almost halt when it's basically doing nothing!

What does the code in question look like here ? I know the issue I have is with auto-generated code, that is frankly pretty hideous (10k+ lines of heavily ifdef’ed stuff).

There will be little point filing a bug report against clang 3.3. The first thing they will ask is if the issue is still there with a newer release. Hence my point above….

I might see if I can form a simple test case for the code I have problems with sometime…

The solution I have used so for is for the file in question, when compiling with clang to disable compiler optimisations, which seem to be the issue. i.e. use -O0 instead of -O2…

cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2030 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20140316/6be1fccf/attachment.p7s>