[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[manu at gcc dot gnu dot org]

------- Comment #1 from manu at gcc dot gnu dot org  2007-11-16 15:49 -------
What does -Winline say?

Have you tried with always_inline? Example:

     /* Prototype.  */
     inline void foo (const char) __attribute__((always_inline));

See 

  http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

and

  http://gcc.gnu.org/onlinedocs/gcc/Inline.html


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[laurent at ient dot rwth-aachen dot de]

------- Comment #2 from laurent at ient dot rwth-aachen dot de  2007-11-16 17:46 -------
(In reply to comment #1)
> What does -Winline say?
> 
> Have you tried with always_inline? Example:
> 
>      /* Prototype.  */
>      inline void foo (const char) __attribute__((always_inline));
> 
Whaow, I have posted this report for a while...!!!

As I posted, GCC was at version 3.x.
"Winline" said that many functions were not inlined despite of the presence of
the keyword 'inline'.
yes, I did try "__attribute__((__always_inline__))". 

But Since version 4.2, GCC seems to respect this attribute, at least!!! 
This was a great improvement for me, I have really waited for this feature.

I once found a page, where a very important person in the Linux world (cannot
remember who now, Linux Toward probably) complained about the lack of inlining
in linux-Kernel, that there were no way to force GCC, etc...
I am glad that this person was heard by GCC developers...

It improved a lot the performance of my library compiled with GCC.
But honestly ICL (Intel Compiler for Windows) is still much better in
optimisations.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2007-11-16 18:00 -------
Note that for completely inlining kernels you can use the
__attribute__((flatten))
on the *calling* function.  Usually with expression templates that is the
function
containing the loops, like

void __attribute__((flatten)) doit()
{
  for (;;)
    lots_of_calls_to_inline ();
}

and it will make sure to inline all calls done in doit (recursively, so no
calls
will be left in the final version).  Also starting with GCC 4.2 (and much
improved on trunk which will become 4.3) using profile-feedback will
improve inline performance a lot (use -fprofile-generate, run, -fprofile-use).

I'll close this bug as worksforme as it doesn't have a useful testcase and
from my experience with tramp3d-v4 performance of ICC sucks compared to
GCC because ICC inlines too little ;)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2007-11-16 18:01 -------
(In reply to comment #2)

> Whaow, I have posted this report for a while...!!!

I guess this report fell through the cracks of bugzilla. Reporting the status
on new versions of GCC would have probably helped.

> But Since version 4.2, GCC seems to respect this attribute, at least!!! 
> This was a great improvement for me, I have really waited for this feature.

OK. So this is fixed. Thanks for the report nonetheless. And sorry for the
delay.

> But honestly ICL (Intel Compiler for Windows) is still much better in
> optimisations.

But we are better in freedom. ;-)


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[pcarlini at suse dot de]

------- Comment #5 from pcarlini at suse dot de  2007-11-16 18:03 -------
(In reply to comment #2)
> I once found a page, where a very important person in the Linux world (cannot
> remember who now, Linux Toward probably) complained about the lack of inlining
> in linux-Kernel, that there were no way to force GCC, etc...
> I am glad that this person was heard by GCC developers...

I don't think all the inlining improvements (many) can be traced back to any
specific individual complaining (not even Linus Torvalds ;)

> It improved a lot the performance of my library compiled with GCC.
> But honestly ICL (Intel Compiler for Windows) is still much better in
> optimisations.

Details would be certainly welcome. Ideally, a reduced snippet, to pursue the
optimization people to take action reasonably quickly...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[laurent at ient dot rwth-aachen dot de]

------- Comment #6 from laurent at ient dot rwth-aachen dot de  2007-11-16 20:42 -------
> Note that for completely inlining kernels you can use the
> __attribute__((flatten))
> on the *calling* function.  Usually with expression templates that is the
> function
> containing the loops, like
> void __attribute__((flatten)) doit()
> {
>   for (;;)
>     lots_of_calls_to_inline ();
> }
> and it will make sure to inline all calls done in doit (recursively, so no
> calls
> will be left in the final version).  Also starting with GCC 4.2 (and much
> improved on trunk which will become 4.3) using profile-feedback will
> improve inline performance a lot (use -fprofile-generate, run, -fprofile-use).
Good to know! Thanks for the advices!

> But we are better in freedom. ;-)
Much better!

> OK. So this is fixed. Thanks for the report nonetheless. And sorry for the
> delay.
No problemo. Thank to all of you.

> I don't think all the inlining improvements (many) can be traced back to any
> specific individual complaining (not even Linus Torvalds ;)
(Ups! sorry for having misspelled the name of Linus Torvalds!)
You are most probably right. I was nevertheless happy to notice I was not alone
to complain about the problem. 

> Details would be certainly welcome. Ideally, a reduced snippet, to pursue the
> optimization people to take action reasonably quickly...
Hmm, difficult. 
I just sometimes compare execution speed of numerical calculations from
different compilers (ICL,VC2005,GCC), and ICL is often quicker by maybe 10%.
If I have more specific and easier examples, I'll post them.

I especially appreciate the way GCC notifies the compilation errors from deep
nested templates. I could not have programmed deep nested template expression
with the complicated error messages form ICL or VC2005.

I have to say that ICL has obviously not respected the __forceinline directive
any more since the version 9 and 10, this is for me a clear regression.
I do not know exactly the changes in these latest versions, but I do not want
to exchange with my good old version 8.1.

Thanks


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[laurent at ient dot rwth-aachen dot de]

------- Comment #7 from laurent at ient dot rwth-aachen dot de  2008-09-27 11:40 -------
Hello

I reopen the discussion because I noticed a problem in relation with
"__attribute__((__always_inline__))" when I tried to compile my library as a
DLL.

GCC now forces inlines well, and is now as quick as ICL for my generic
implementation of the FFT Fast Fourier Transform).
So I would like to progressively use GCC as my favorite compiler.

GCC works fine if I use "inline" as usual (but my program is slow).
But I get hundreds error messages if I use the macro "#define inline
__attribute__((__always_inline__))". For example:

obj\Release\src\copy.o:copy.cpp:(.text+0x0): first defined here
obj\Release\src\dct.o:dct.cpp:(.text+0xe): multiple definition of `_ferror'
obj\Release\src\copy.o:copy.cpp:(.text+0xe): first defined here
obj\Release\src\dct.o:dct.cpp:(.text+0x1c): multiple definition of `operator
new(unsigned int, void*)'
obj\Release\src\copy.o:copy.cpp:(.text+0x1c): first defined here

I use the CodeBlock Environnement and MinGW GCC 4.3.1 (downloaded from
http://www.tdragon.net/recentgcc/)
My problem might be related with the following bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121

Any Clue????

--------------------------------
I was asked above from Paolo if I could give a test case where ICL is quicker
than GCC. I will publish the new version 2.2 of my library in a couple of days
(http://www.ient.rwth-aachen.de/~laurent/genial/genial.html).
If you are still interested, I could give then a small test case using my
library where ICL is much quicker than GCC and VC2008 (but I don't care much
about VC2008).


-- 

laurent at ient dot rwth-aachen dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2008-09-28 02:11 -------
Try
  #define inline inline __attribute__((always_inline))
instead.  The inline keyword changes linkage, so you have to keep it.
If you keep having problems open a new bugreport please, the performance
issue seems to be still solved.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628

[Bug middle-end/21628] GCC much slower than ICL. Lack of inlining?

[laurent at ient dot rwth-aachen dot de]

------- Comment #9 from laurent at ient dot rwth-aachen dot de  2008-09-28 07:59 -------
(In reply to comment #8)
> Try
>   #define inline inline __attribute__((always_inline))
> instead.  The inline keyword changes linkage, so you have to keep it.
> If you keep having problems open a new bugreport please, the performance
> issue seems to be still solved.
> 

Thank you! It works. 
Sorry for my question.

I have still noticed before another problem with
"__attribute__((always_inline))".
I will write a bug report in a few days, as soon as I will reproduce it with a
small test case.
The bug actually accurs at a few positions in the STL with a error message
somewhat like "sorry unimplemented, could not inline". I could temporary fix it
with a few change in the STL. 

Are you interested if I post a new report for a performance issue in comparison
to ICL? This performance issue is the only one I know, that still prevents me
from prefering GCC to ICL. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21628