This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

link times

 

Hello,

 

I'm trying to save myself some time from experimenting around with too many different versions

of cgtools.  I'm currently using cgtools v6.1.19(COFF), because of extenuating circumstances, and I have

a large project where I have traded things off at the code generation stage via various optimization

combinations and parallel builds to get a debug build in 3 hours and a release build in 8 hours on

a 2011 4-core i7 with 8GB RAM.  At the link stage I have compression disabled, etc.  My debug

executable with symbols links up at around 600MB, but I am unable to build all modules with debug

as the linker hits the 2GB XP process limit and dies.  I can work around that by building a portion

of the modules without debug symbols, but my final link times - which I must run single threaded as

far as I know - are surpassing 30 minutes which is becoming too slow when debugging and faster

turn-around times are desired.

 

So, if I do all the work to move the project to the latest version of tools using elf, etc. will they

be efficient enough to get my link times  under 5 minutes, and possibly a full debug build, on

the machine mentioned above - or is my project simply too large for even the latest version of

this tool chain?  Any other suggestions are appreciated as well.

 

(In a non-cross environment, building natively on a 5 year old XP or linux box, link times are 1 or 2 minutes.)

 

Regards,

Jason Kalin

 

  • Does your project make use of C++ templates?

  •  

    Hi Archaeologist,

     

    Yes, there is quite extensive use of templates in some of the modules.  I have worked around the template

    issues in the optimizer, compiler etc. by option choice, splitting files, recoding and explicit instantiation, etc.

    There is no template instantiation occurring at link time at all - I have removed those recompilations through

    extensive explicit instantiation - so the times I'm citing are purely lnk6x.exe times.  Platform is DM648, BTW.

     

    A few months ago I did take a couple days with the 7.2 tools and had some other problems, but my recollections

    are that they weren't significantly faster than the 6.1.19 tools at the time.   I'm going to have to make a decision

    to move to the new tools if they can help these issues, live with the situation, or move to another platform very

    shortly.  Thank you for any advice - would you imagine your 7.2+ ARM cross tool chain would do better with these

    issues on modules I could move to it on a platform change?

     

    Regards,

    Jason Kalin

  • Please try building with either the v7.3.x (preferred) or v7.2.x (okay) compiler.  Build for EABI with option --abi=eabi.  Under EABI, different methods are used to instantiate templates and avoid duplicate type information that should result in a much faster build and link.  If you are linking with other packages such as BIOS, then you need to obtain EABI versions of those packages.

    Thanks and regards,

    -George

  •  

    Ok, I will give the 7.3 series a try.  I understand mileage may vary significantly depending on the application, but

    if the information is available:

     

    1) Are there any apples to apples performance comparison statistics available on sample applications for the

    different tools in the chain, specifically execution time and memory usage, from 6.1 through 7.3?

    2) Perhaps 50% of this project's code is more management plane and suitable for a general purpose processor

    such as the ARM on a dual-core platform - I imagine it's a different tool chain, but can I expect closer to PC-like

    execution time and memory usage for the tool chain if I move the management plane to an ARM cross environment?

    3) I had some problems with large exception tables crashing the 7.2 tool chain a few months ago - have these been

    resolved in the 7.3 series?

    4) I haven't read - Is the 7.3 series 64bit and not subject to the 2GB memory limit?

    5) Is it possible to get an extension of the 1 month trial license for the 7.2 tool chain as I try the 7.3 tool chain?

     

    Regards,

    Jason Kalin

  •  

    6) As far as I understand it, it looks like the NDK is only distributed with COFF builds?  So I will have to rebuild this from

    source with the 7.3 tools?

  • Before you try to build your own code with EABI, you need to make sure all the components you use are available in EABI versions.  I don't know much about the NDK, but it probably is not available for EABI.  This page talks about how to rebuild it.  Based on my quick look at that page, I suspect rebuilding for EABI would be a challenge.  You are welcome to try.  If it goes smoothly, great.  If not, then don't worry about it.

    For now, I presume building for EABI is not an option.

    Have you tried the linker -b option?  It is described on this page.  It might help.

    Thanks and regards,

    -George

  •  

    Hi George,

     

    I am using the -b option currently - I had many unending links and crashes earlier in the project without it.

    Unfortunately, I can't really disregard the NDK as I need a TCP/IP stack for the project so I either need an

    elf build, the ability to rebuild it myself or choose to move to another TCP/IP stack such as the linux stack for the ARM.

     

    Thanks for your help.

     

    Regards,

    Jason Kalin