llvm dev - May 2012 - [LLVMdev] Linking times

Hi,

Just a brief follow-up on my link time issue: It was caused by excessive
trashing; I tried rebuilding on a box with 8 gigs of RAM and observed the
memory load while linking clang.exe: It peaked at 5 gigabytes memory, so
now I've written this piece of info into the LLVM/Windows document that I
posted earlier (I have already made a substantial number of corrections in
the document).  All in all, it took the 2 gig box about 5 hours to link
clang.exe :-)

I must say that I am once again surprised about GNU tools.  I'd expect the
linker to use perhaps 100 megabytes of memory as it only needs to record
where the BLOBs are in the input files and then, during one of the final
passes, copy each binary block to the output file - without caching it in
memory.  I do suspect that GNU ld indiscriminantly reads in everything
under the assumption that people never link that large files.


Cheers,
Mikael
-- Love Thy Frog!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120527/ed47d942/attachment.html>

Do you specify CMAKE_BUILD_TYPE
if you are using cmake?
2012/05/27 18:21 "Mikael Lyngvig" <mikael at lyngvig.org>:
> Hi,
>
> Just a brief follow-up on my link time issue: It was caused by excessive
> trashing; I tried rebuilding on a box with 8 gigs of RAM and observed the
> memory load while linking clang.exe: It peaked at 5 gigabytes memory, so
> now I've written this piece of info into the LLVM/Windows document that
I
> posted earlier (I have already made a substantial number of corrections in
> the document).  All in all, it took the 2 gig box about 5 hours to link
> clang.exe :-)
>
> I must say that I am once again surprised about GNU tools.  I'd expect
the
> linker to use perhaps 100 megabytes of memory as it only needs to record
> where the BLOBs are in the input files and then, during one of the final
> passes, copy each binary block to the output file - without caching it in
> memory.  I do suspect that GNU ld indiscriminantly reads in everything
> under the assumption that people never link that large files.
>
>
> Cheers,
> Mikael
> -- Love Thy Frog!
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120527/edc99356/attachment.html>

No, I use the command:

    cmake -G "MinGW Makefiles" ..\llvm


Cheers,
Mikael
-- Love Thy Frog!

2012/5/27 NAKAMURA Takumi <geek4civic at gmail.com>
> Do you specify CMAKE_BUILD_TYPE
> if you are using cmake?
> 2012/05/27 18:21 "Mikael Lyngvig" <mikael at lyngvig.org>:
>
>> Hi,
>>
>> Just a brief follow-up on my link time issue: It was caused by
excessive
>> trashing; I tried rebuilding on a box with 8 gigs of RAM and observed
the
>> memory load while linking clang.exe: It peaked at 5 gigabytes memory,
so
>> now I've written this piece of info into the LLVM/Windows document
that I
>> posted earlier (I have already made a substantial number of corrections
in
>> the document).  All in all, it took the 2 gig box about 5 hours to link
>> clang.exe :-)
>>
>> I must say that I am once again surprised about GNU tools.  I'd
expect
>> the linker to use perhaps 100 megabytes of memory as it only needs to
>> record where the BLOBs are in the input files and then, during one of
the
>> final passes, copy each binary block to the output file - without
caching
>> it in memory.  I do suspect that GNU ld indiscriminantly reads in
>> everything under the assumption that people never link that large
files.
>>
>>
>> Cheers,
>> Mikael
>> -- Love Thy Frog!
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120527/a13537c5/attachment.html>