Re: [Mingw-users] Known performance bottlenecks on C++ applications?

[Óscar F. <of...@wa...>]

Óscar Fuentes <of...@wa...> writes:

> On a CPU-intensive C++ application, I found a 3x slowdown on executables
> compiled with MinGW compared with Visual Studio.
>
> It is not the core compiler, because the same g++ version on Linux does
> a job as good as VS, if not better. It is not exception handling code
> either, because disabling exceptions makes just a bit of a difference.
> Finally, I also discarded memory handling as a cause. There is no
> multithreading nor any OS-intensive work.
>
> The C++ application is a JIT compiler. The compilation part is slower
> than VC by a 1.1 factor. That is acceptable. But while executing the
> generated bytecode the slowdown factor is larger than 3. The compiler
> creates an array of funcion pointers and the interpreter just walks the
> array calling those functions. Each function does a fairly simple job
> (like "take 2 numbers from the stack, add them and put the result on the
> stack".)
>
> The obvious suspect is some Windows-specific compiler intrinsic that
> could be implemented on a suboptimal way.
>
> Which areas are known to be performance sinks?

A look at the assembler output shows that g++ is not inlining lots of
trivial methods. For instance:

	movl	4(%esp), %ecx
	call	__ZN3lp012ExecutionEnv12NextIsReturnEb.constprop.282

The called function is only one machine instruction:

LFE4955:
	.align 2
	.p2align 2,,3
	.def	__ZN3lp012ExecutionEnv12NextIsReturnEb.constprop.282;	.scl	3;	.type	32;	.endef
__ZN3lp012ExecutionEnv12NextIsReturnEb.constprop.282:
LFB4954:
	.cfi_startproc
	movb	$1, 20(%ecx)
	ret
	.cfi_endproc

I'm using MinGW g++ 4.7.2 and generating the assembler output with:

 g++ -O2 -S -std=gnu++0x -c commands.cpp

(same result with -O3)

On Linux, with g++ 4.7.3 and the same options, all those functions are
inlined. I'm pretty sure that the same applies to previous Linux g++
versions.

What could be preventing the compiler from inlining all those tiny
methods?