C ++优化级别是否会影响Swig Python模块的性能

Question

I have a large Swig Python module. The C++ wrapper ends up being about 320,000 LoC (including headers I guess). I currently compile this with -O1, and g++ produces a binary that is 44MiB in size, and takes about 3 minutes to compile it.

If I turn off optimisation (-O0), the binary comes out at 40MiB, and it takes 44s to compile.

Is compiling the wrapper with -O0 going to hurt the performance of the python module significantly? Before I go and profile the performance of the module at different optimisation levels, has anyone done this sort of analysis before or have any insight into whether it matters?

Answer 1

-O0 deactivates all the optimizations performed by gcc. And optimizations matter.

So, without a lot of knowledge in your application, I could suggest that this will hurt the performance of your application.

A usually safe optimization level to use is -O2.

You can check the kind of optimizations performed by GCC in: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html .

But at the end, if you want to know exactly you should compile at different levels and profile.

Answer 2

This is bad irrespective of SWIG modules or not. There are many optimisations that happen even with gcc -O1 which you will miss if you prevent them happening.

You can check the difference by inspecting the asm generated by your compiler of choice. Of these the ones I trivially know will be detrimental to SWIG's generated wrapper:

1. Dead code elimination:

    void foo() { int a = 1; a = 0; } 

   With -O1 this entirely pointless code gets totally removed:

    foo: pushl %ebp movl %esp, %ebp popl %ebp ret 

   whereas with -O0 it becomes:

    foo: pushl %ebp movl %esp, %ebp subl $16, %esp movl $1, -4(%ebp) movl $0, -4(%ebp) leave ret 

2. Register allocation will be detrimentally impacted in functions with lots of local variables - most SWIG wrapper functions will see a hit from this. It's hard to show a concise example of this though.

3. Another example, the output from gcc compiling the SWIG wrapper for the prototype:

    int foo(unsigned int a, unsigned int b, unsigned int c, unsigned int d); 

   Generates with -O0 :

    Java_testJNI_foo: pushl %ebp movl %esp, %ebp subl $88, %esp movl 16(%ebp), %eax movl %eax, -48(%ebp) movl 20(%ebp), %eax movl %eax, -44(%ebp) movl 24(%ebp), %eax movl %eax, -56(%ebp) movl 28(%ebp), %eax movl %eax, -52(%ebp) movl 32(%ebp), %eax movl %eax, -64(%ebp) movl 36(%ebp), %eax movl %eax, -60(%ebp) movl 40(%ebp), %eax movl %eax, -72(%ebp) movl 44(%ebp), %eax movl %eax, -68(%ebp) movl $0, -32(%ebp) movl -48(%ebp), %eax movl %eax, -28(%ebp) movl -56(%ebp), %eax movl %eax, -24(%ebp) movl -64(%ebp), %eax movl %eax, -20(%ebp) movl -72(%ebp), %eax movl %eax, -16(%ebp) movl -16(%ebp), %eax movl %eax, 12(%esp) movl -20(%ebp), %eax movl %eax, 8(%esp) movl -24(%ebp), %eax movl %eax, 4(%esp) movl -28(%ebp), %eax movl %eax, (%esp) call foo movl %eax, -12(%ebp) movl -12(%ebp), %eax movl %eax, -32(%ebp) movl -32(%ebp), %eax leave ret 

   Compared to -O1 which generates just:

    Java_testJNI_foo: pushl %ebp movl %esp, %ebp subl $24, %esp movl 40(%ebp), %eax movl %eax, 12(%esp) movl 32(%ebp), %eax movl %eax, 8(%esp) movl 24(%ebp), %eax movl %eax, 4(%esp) movl 16(%ebp), %eax movl %eax, (%esp) call foo leave ret 

4. With -O1 g++ can generate far smarter code for:

    %module test %{ int value() { return 100; } %} %feature("compactdefaultargs") foo; %inline %{ int foo(int a=value(), int b=value(), int c=value()) { return 0; } %} 

The short answer is with optimisations disabled completely GCC generates extremely naive code - this is true of SWIG wrappers as much as any other program, if not more given the style of the automatically generated code.