Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

Out-of-memory error when compiling a huge project for 32-bit Windows target for profile guided opts

meldaproduction
Beginner
994 Views

I have a huge project, that needs lots of optimizations, so I use profile guided stuff, which doesn't really improve performance, but smallers the executables quite a bit (from 50MB to 35MB or so). First it takes a hell of a lot of time to build the executables for generting the profile guided database (or how is it called), but my main problem is that 64-bit version works fine, but 32-bit version evetually (after hours of processing...) ends with out-of-memory error (I have enough memory). So I assume the compiler for 32-bit target is also 32-bit (how else could 64-bit compiler succeed).

Is there a way to use the 64-bit compiler to produce 32-bit binaries? Like some parameter or something? I generally don't understand why selecting a different architecture is done by selecting a different compiler.

0 Kudos
20 Replies
Judith_W_Intel
Employee
984 Views

 

Try -m32.

      -m32
      -m64
           Generate code for a 32-bit or 64-bit environment.  The 32-bit
           environment sets int, long and pointer to 32 bits and generates
           code that runs on any i386 system.  The 64-bit environment sets int
           to 32 bits and long and pointer to 64 bits and generates code for
           AMDâs x86-64 architecture. For darwin only the -m64 option turns
           off the -fno-pic and -mdynamic-no-pic options.
 

 

0 Kudos
meldaproduction
Beginner
984 Views

Thanks for the info, but I need it for Windows, not OSX / Linux.

0 Kudos
Judith_W_Intel
Employee
984 Views

 

Sorry, try:


/Qm32     generate code for IA-32 architecture

/Qm64     generate code for Intel(R) 64 architecture

 

0 Kudos
meldaproduction
Beginner
984 Views

Thank you. Tried and despite the switches are probably working, the 64-bit version compiling 32-bit executables ended with out-of-memory message as well...

0 Kudos
jimdempseyatthecove
Honored Contributor III
984 Views

I haven't experimented with POGO ...

You should try to see if it is possible to use the database from the 64-bit POGO to build your 32-bit application. IOW perform POGO on 64-bit then copy the .dyn files to the relevant place for the 32-bit .dyn files then perform the Phase 3 portion of the compile of the 32-bit application.

I do not know the appropriate option to inform the compiler to use the already existing .dyn files for final build. The option Qcov-file alone may work but there may be an additional option required as well.

Can someone here provide the additional information.

Jim Dempsey

 

0 Kudos
meldaproduction
Beginner
984 Views

Thanks Jim, but sadly that doesn't work. ICC froze just a few seconds after tryng that, I let it frozen for like an hour, but nothing...

0 Kudos
Kittur_G_Intel
Employee
984 Views

@meldaproduction:   Hi, with what I gather reading the thread it appears the compiler is running out of memory when you build using the 64 bit compiler for 32 bit target while 64-to-64 worked fine. Can you provide more details:

1)  Does the error occur during prof gen  or prof-use phase?
2)  Are you using -ipo switch? 
3) What is the system (OS, GCC version etc) you're using?
4) ICC version you're using (%icc -V) should output the values.

_Thx,
Kittur
 

0 Kudos
meldaproduction
Beginner
984 Views

Well, I already stated most of it... anyway

1) prof-gen

2) -ip

3) Windows, command line

4) 15.0.4.221

0 Kudos
Kittur_G_Intel
Employee
984 Views

Hi,
Thanks for the info. Is it possible for you to compile individual file at a time so you can isolate the particular problematic file? Once you do, you can then use /P option to generate the preprocessed file that we can use as a reproducer for investigation.  My guess is that it could be a bug or it could be that you may be stressing the system with a lot of parallel builds. You can try to reduce the number of maximum number of builds and see if it helps as well.   If you can attach the preprocessed file for that culprit file that would be ideal, thanks

_Kittur

 

0 Kudos
meldaproduction
Beginner
984 Views

Hi Kittur,

I'm afraid I cannot do that. I'm compiling just 3 source codes and these are huge, I basically include the CPPs together, it has proven to be faster and generate better code. It's all full of templates anyway. But I guess that could be the problem. I'm also not doing any parallel compiling, and the system has plenty of memory.

0 Kudos
Kittur_G_Intel
Employee
984 Views

Understood, thanks for the info.  Well, the only other thing to try out then is to not use -ip  and/or use –Ob0 on the –prof-gen step and see if it helps.

_Kittur

 

0 Kudos
meldaproduction
Beginner
984 Views

Thanks for the info, will try!

0 Kudos
Kittur_G_Intel
Employee
984 Views

Thanks, let me know if it resolves the issue - appreciate much.

_Kittur

0 Kudos
meldaproduction
Beginner
984 Views

Very well, without -ip it works! Now a different problem - on OSX I'm using ICC only for 64-bit, and then I can compile the 64-bit -prof-gen, but then the -prof-use freezes. I'll check again though.

0 Kudos
Kittur_G_Intel
Employee
984 Views

Great to know, thanks. On the freezing issue, it's the same scenario as before in that it's hard to investigate without the preprocessed file at least :-( Yes, please check again and let us know - appreciate much.

_Kittur

0 Kudos
meldaproduction
Beginner
984 Views

Ok, so on OSX it doesn't work at all! Here's the result:

dyld: Library not loaded: @loader_path/libcilkrts.5.dylib
  Referenced from: /opt/intel/composer_xe_2015.3.187/bin/intel64/profmerge
  Reason: image not found
icpc: error #10106: Fatal error in /opt/intel/composer_xe_2015.3.187/bin/intel64/profmerge, terminated by trace trap

I tried reinstalling the whole thing, no luck...

0 Kudos
meldaproduction
Beginner
984 Views

I fixed that by placing all the libs to /usr/local/lib, interestingly adding that path to PATH didn't help... Anyway then it after some time failed again with this:

": internal error: ** The compiler has encountered an unexpected problem.

** Segmentation violation signal raised. **

Access violation or stack overflow. Please contact Intel Support for assistance.

I'll try without -ip.

0 Kudos
Kittur_G_Intel
Employee
984 Views

Hi, I don't have the exact system info you're running on but wanted to point out that there was an issue with DYLD_LIBRARY_PATH setting and don't know if it could be a result of that as well. Can you please refer to the article at: https://software.intel.com/articles/os-x-1011-support-in-intel-parallel-studio-xe-2016 and the section under "Dynamic Library Dependencies" and use the workaround indicated there and see if the issue of finding/loading the dynamic lib is taken care of. Also, you'll need to ensure you're using the latest 16.0 Update 1 release as well.  Let me know what you find. Again, appreciate your patience and your feedback through this.

_Kittur

0 Kudos
meldaproduction
Beginner
984 Views

Copying it to the /usr/local/lib did the trick, but with -ip it failed with the message above. I tried without -ip and it worked, but then it didn't bring any performance nor size improvement, so I'll just stick with -ip. It's a shame, because on Windows it works and helps quite a bit (more like for size, but slightly for performance as well).

0 Kudos
Kittur_G_Intel
Employee
876 Views

Hi, I understand the concern. Since you say it did work without -ip then it could be a bug in the compiler. Unfortunately it's hard for me to file an issue with our developers without a reproducer as you can imagine. I'll bring this to their attention as well and will keep you updated, thx.

_Kittur

0 Kudos
Reply