GCC viciously beaten by ICC in trig test!

GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Hello,

Consider the following program, compiled and run on a Pentium 4 
(Northwood) system:

     #include <math.h>
     #include <stdio.h>

     double doit(double a)
     {
         double s = sin(a);
         double c = cos(a);

         // should always be 1
         return s * s + c * c;
     }

     int main(void)
     {
         double a = 1.0, r = 0.0;

         for (int i = 0; i < 100000000; ++i)
             r += doit(a);

         printf("r = %f\n",r);
         return 0;
     }

Using both GCC 3.3.3 and Intel C++ 8.0, I compiled the above with these 
command lines:

     gcc -o sincosg -lm -std=gnu99 -O3 -march=pentium4 \
            -mfpmath=387 -ffast-math -fomit-frame-pointer sincos.c

     icc -o sincosi -lm -O3 -xN -tpp7 -ipo sincos.c

Both programs produce the correct result. The run times, measured with 
the time command, were:

     0.2s  ICC
    12.8s  GCC (!!!!!)

Very ugly, from the perspective of GCC. I also compiled with 
recently-acquired-from-CVS builds of 3.4.0 and tree-ssa, for good 
measure and with no improvement in performance.

This is a killer issue on certain applications that I run, in which 
trigonometric functions play a crucial role.

Examining the generated assembler source shows that Intel eliminates the 
  function call to "doit()" entirely, replacing it with inline code that 
calls internal functions such as vmldSin2 and vmldCos2, while it's 
actual compilation of doit() uses the SSE2 sincos instruction, whereas 
GCC generates calls to the 387 instructions fsin and fcos.

I have found taht ICC wins any contest in which trigonometric functions 
play a significant role; even in the most complex code (which can not be 
inlined), ICC wins by a factor of 3 to 1 in computational speed.

Can GCC generate faster code for trigonometric code? Options that I 
tried (with no useful effect) include:

     -mfpmath=sse
     -mfpmath=387
     -mfpmath=387,sse
     -msse	(implied by -march=pentium4, but tested anyway)
     -msse2	(implied by -march=pentium4, but tested anyway)

I look forward to illumination (or at least some bright ideas!)

..Scott

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

| Hello,
| 
| Consider the following program, compiled and run on a Pentium 4
| (Northwood) system:
| 
|      #include <math.h>
|      #include <stdio.h>
| 
|      double doit(double a)

Did you try by declaring doit() inline?
(I suppose that won't change much the outcome, but I'm curious).

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> Did you try by declaring doit() inline?
> (I suppose that won't change much the outcome, but I'm curious).

I can get it to be inlined, but that doesn't do much for the performance.

This all came up because someone recompiled a program (with ICC) I'd 
written some years ago for a client -- and they noticed that the ICC 
version was 3 times faster than the GCC version. I get the same results.

I also note that on my current benchmark suites, GCC 3.3.3 performs as 
well or better than ICC on all tests (in terms of generated code speed) 
  -- EXCEPT the ones involving trigonometry.

Which is why I was wondering if I'd missed a magic word.

I'll check this out on Sparc and AMD64 in a day or so, to see if it's 
just a problem with the Pentium 4.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Paolo Carlini]

Scott Robert Ladd wrote:

> I look forward to illumination (or at least some bright ideas!)

I don't have ready at hand tree-ssa but I have lno-branch and the below
are my numbers (P4-2400)

(-O2 -std=c99 -fomit-frame-pointer -ftree-loop-optimize -fscalar-evolutions
-funroll-loops)

paolo:~/Work> time a.out
r = 100000000.000000
0.210u 0.000s 0:00.21 100.0%    0+0k 0+0io 100pf+0w

Pretty good ;)

Paolo.

P.S. For comparison, mainline and your exact flags give here:

14.950u 0.010s 0:15.00 99.7%    0+0k 0+0io 98pf+0w

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Paolo Carlini wrote:
> I don't have ready at hand tree-ssa but I have lno-branch and the below
> are my numbers (P4-2400)
> 
> (-O2 -std=c99 -fomit-frame-pointer -ftree-loop-optimize -fscalar-evolutions
> -funroll-loops)

Hmm... I haven't tried the lno-branch compiler. Lord knows, there aren't
enough versions of GCC on my system already (12 at last count). I *am*
looking forward to vectorization.

According to the GCC docs, -ftree-loop-optimize is enabled at -O and
higher. I'm not familiar with -fscalar-evolutions.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Daniel Berlin]

On Mar 14, 2004, at 8:39 PM, Scott Robert Ladd wrote:

> Paolo Carlini wrote:
>> I don't have ready at hand tree-ssa but I have lno-branch and the 
>> below
>> are my numbers (P4-2400)
>> (-O2 -std=c99 -fomit-frame-pointer -ftree-loop-optimize 
>> -fscalar-evolutions
>> -funroll-loops)
>
> Hmm... I haven't tried the lno-branch compiler. Lord knows, there 
> aren't
> enough versions of GCC on my system already (12 at last count). I *am*
> looking forward to vectorization.
>
> According to the GCC docs, -ftree-loop-optimize is enabled at -O
?

tree-loop-optimize is new to the lno branch.

>  and
> higher. I'm not familiar with -fscalar-evolutions.
It's actually just turning on analysis.
You don't need it, as the passes that require it (linear loop 
transforms, vectorization) already turn it on automatically.

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Daniel Berlin wrote:
> On Mar 14, 2004, at 8:39 PM, Scott Robert Ladd wrote:
>> According to the GCC docs, -ftree-loop-optimize is enabled at -O
> 
> ?
> 
> tree-loop-optimize is new to the lno branch.

Well, this is what a "man gcc" says on my system, when I'm using tree-ssa:

        -ftree-loop-optimize
            Perform loop optimization on trees.  This flag is enabled by
            default at -O and higher.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Daniel Berlin]

On Mar 14, 2004, at 9:29 PM, Scott Robert Ladd wrote:

> Daniel Berlin wrote:
>> On Mar 14, 2004, at 8:39 PM, Scott Robert Ladd wrote:
>>> According to the GCC docs, -ftree-loop-optimize is enabled at -O
>> ?
>> tree-loop-optimize is new to the lno branch.
>
> Well, this is what a "man gcc" says on my system, when I'm using 
> tree-ssa:
>
>        -ftree-loop-optimize
>            Perform loop optimization on trees.  This flag is enabled by
>            default at -O and higher.

Oh, well, that one does nothing, since the optimizations were only 
implemented in the lno-branch.
:)

That flag is probably left over from before this was decided.

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Daniel Berlin wrote:
> Oh, well, that one does nothing, since the optimizations were only 
> implemented in the lno-branch.
> :)

Ah, more proof that I should never read documentation; it only confuses 
matters! :)

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Sebastian Pop]

On Sun, Mar 14, 2004 at 09:37:43PM -0500, Scott Robert Ladd wrote:
> Daniel Berlin wrote:
> >Oh, well, that one does nothing, since the optimizations were only 
> >implemented in the lno-branch.
> >:)
> 
> Ah, more proof that I should never read documentation; it only confuses 
> matters! :)
> 

Right, read the code and the comments ;-)

btw, I will probably remove the -fscalar-evolutions since it does
nothing than trying to compute for all the loops the number of
iterations, and it is used only in some testcases.  

> -- 
> Scott Robert Ladd
> Coyote Gulch Productions (http://www.coyotegulch.com)
> Software Invention for High-Performance Computing

Re: GCC beaten by ICC in stupid trig test!

[Andrew Pinski]

On Mar 14, 2004, at 15:39, Scott Robert Ladd wrote:

> Hello,
>
> Consider the following program, compiled and run on a Pentium 4 
> (Northwood) system:
>
>     #include <math.h>
>     #include <stdio.h>
>
>     double doit(double a)
>     {
>         double s = sin(a);
>         double c = cos(a);
>
>         // should always be 1
>         return s * s + c * c;
>     }
>
>     int main(void)
>     {
>         double a = 1.0, r = 0.0;
>
>         for (int i = 0; i < 100000000; ++i)
>             r += doit(a);
>
>         printf("r = %f\n",r);
>         return 0;
>     }
>

The point here if you know that it is 1.0 then just return 1.0 instead 
of trying to
play tricks with trig functions.  Yes GCC should do better for trig 
functions
but in most cases, the developer was just doing something dumb like the 
above example
which by the way is not a good benchmark anyways because you know that 
the trig
functions can be reduced to just a load of a constant (as ICC does this 
transformation
while GCC does not but could).

Actually what is happening here is that the function doit is being 
inlined and the math in the inner loop is not being pulled out of the 
loop as it is constant just like a is.
So doing the following (aka forces GCC not to inline) will at least get 
GCC to be about
the same ball park (but still nowhere near) as ICC.  The reason why 
still is that ICC will just unroll the loop to be "r = 
doit(a)*100000000.0" so that is the reasons why
ICC is better than GCC at doing this stupid trig test (note this is 
transformation
is only valid if fast-math is on as you loose precision).

Here is a much better benchmark to try, notice that we are doing more 
work now but the point is that ICC is going to be the transformation 
and it not going to see that doit
is constant so it will not pull it out of the loop and it cannot unroll 
the loop into
just being a constant.


     #include <math.h>
     #include <stdio.h>

     double doit(double a)
     {
         double s = sin(a);
         double c = cos(a);

         return s * c;
     }

     int main(void)
     {
         double a = 1.0, r = 0.0;

         for (int i = 0; i < 100000000; ++i, a++)
             r += doit(a);

         printf("r = %f\n",r);
         return 0;
     }

Re: GCC beaten by ICC in stupid trig test!

[Paolo Carlini]

Andrew Pinski wrote:

> Here is a much better benchmark to try, notice that we are doing more 
> work now but the point is that ICC is going to be the transformation 
> and it not going to see that doit
> is constant so it will not pull it out of the loop and it cannot 
> unroll the loop into
> just being a constant.

Ah! Thanks Andrew for the explanation. Now some recent developments
are much more clear to me!

Indeed, your modified testcase runs slower everywhere... ;)

Paolo.

Re: GCC beaten by ICC in stupid trig test!

[Scott Robert Ladd]

Andrew Pinski wrote:
> 
> On Mar 14, 2004, at 15:39, Scott Robert Ladd wrote:
> 
>> Hello,
>>
>> Consider the following program, compiled and run on a Pentium 4 
>> (Northwood) system:
>>
>>     #include <math.h>
>>     #include <stdio.h>
>>
>>     double doit(double a)
>>     {
>>         double s = sin(a);
>>         double c = cos(a);
>>
>>         // should always be 1
>>         return s * s + c * c;
>>     }
>>
>>     int main(void)
>>     {
>>         double a = 1.0, r = 0.0;
>>
>>         for (int i = 0; i < 100000000; ++i)
>>             r += doit(a);
>>
>>         printf("r = %f\n",r);
>>         return 0;
>>     }
>>
> 
> The point here if you know that it is 1.0 then just return 1.0 instead 
> of trying to play tricks with trig functions.

Don't be so damned insulting.

This is a simple example program meant tio demonstrate a problem in GCC 
code generation. You know -- providing a simple piece of code that 
focuses on the problem, rather than presenting a thousand-line program.

The reason doit returns 1 is so that the optimizers don't eliminate the 
code entirely. If doit() merely computes sin and cos, and returns 
nothing, it is compiled to nothing. Thus the return value to force code 
generation. By using the sine/cosine relationship, to prove that the 
function correctly computed the two values.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC beaten by ICC in stupid trig test!

[Scott Robert Ladd]

Andrew Pinski wrote:
> Here is a much better benchmark to try, notice that we are doing more
>  work now but the point is that ICC is going to be the transformation
>  and it not going to see that doit is constant so it will not pull it
>  out of the loop and it cannot unroll the loop into just being a 
> constant.

Intel does *not* unroll the original code into a constnt. To wit, the 
code generated on my system:

         .globl main
main:
..B1.1:                         # Preds ..B1.0
         pushl     %ebx                                          #14.1
         movl      %esp, %ebx                                    #14.1
         andl      $-64, %esp                                    #14.1
         pushl     %edi                                          #14.1
         subl      $60, %esp                                     #14.1
         call      __intel_proc_init_N                           #14.1
         pushl     %eax                                          #14.1
         pushl     %eax                                          #14.1
         stmxcsr   (%esp)                                        #14.1
         popl      %eax                                          #14.1
         orl       $32768, %eax                                  #14.1
         pushl     %eax                                          #14.1
         ldmxcsr   (%esp)                                        #14.1
         popl      %eax                                          #14.1
         popl      %eax                                          #14.1
         movapd    _2il0floatpacket.1, %xmm0                     #18.14
         xorl      %edi, %edi                                    #17.5
         pxor      %xmm1, %xmm1                                  #
         movapd    %xmm1, 16(%esp)                               #
         call      vmldSin2                                      #18.14
                                 # LOE ebp esi edi xmm0
..B1.7:                         # Preds ..B1.1
         movapd    %xmm0, 32(%esp)                               #18.14
         movapd    _2il0floatpacket.1, %xmm0                     #18.14
         call      vmldCos2                                      #18.14
                                 # LOE ebp esi edi xmm0
..B1.8:                         # Preds ..B1.7
         mulpd     %xmm0, %xmm0                                  #18.14
         movapd    32(%esp), %xmm1                               #18.14
         mulpd     %xmm1, %xmm1                                  #18.14
         movapd    16(%esp), %xmm2                               #18.14
         movapd    %xmm1, 32(%esp)                               #18.14
         movapd    32(%esp), %xmm1                               #18.14
         .align    4,0x90
                                 # LOE ebp esi edi xmm0 xmm1 xmm2
..B1.2:                         # Preds ..B1.8 ..B1.2
         addpd     %xmm1, %xmm2                                  #18.9
         addpd     %xmm0, %xmm2                                  #18.14
         addl      $2, %edi                                      #17.5
         cmpl      $100000000, %edi                              #17.5
         jb        ..B1.2        # Prob 100%                     #17.5
                                 # LOE ebp esi edi xmm0 xmm1 xmm2
..B1.3:                         # Preds ..B1.2
         movapd    %xmm2, 16(%esp)                               #
         movapd    16(%esp), %xmm1                               #17.5
         movapd    %xmm1, %xmm0                                  #17.5
         unpckhpd  %xmm0, %xmm0                                  #17.5
         addsd     %xmm0, %xmm1                                  #
         movl      $__STRING.0, (%esp)                           #20.12
         movsd     %xmm1, 4(%esp)                                #20.23
         call      printf                                        #20.5
                                 # LOE ebp esi
..B1.4:                         # Preds ..B1.3
         xorl      %eax, %eax                                    #21.12
         addl      $60, %esp                                     #21.12
         popl      %edi                                          #21.12
         movl      %ebx, %esp                                    #21.12
         popl      %ebx                                          #21.12
         ret                                                     #21.12


I made some minor mention of this in the original post, but it was 
likely too vague for you.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC beaten by ICC in stupid trig test!

[Paolo Carlini]

Andrew Pinski wrote:

> The reason why still is that ICC will just unroll the loop to be "r = 
> doit(a)*100000000.0" so that is the reasons why
> ICC is better than GCC at doing this stupid trig test (note this is 
> transformation
> is only valid if fast-math is on as you loose precision).

In the meanwhile we have learned that the real reason why Icc performs
better then mainline gcc is the use of an iterative SSE instruction
(see Dan Nicolaescu message).

On the other hand, gcc-lno "appear" to perform as well as Icc because of
the unrolling trick (just checked that gcc-lno transforms the loop to
the trivial:

   8048470:       40                      inc    %eax
   8048471:       d8 c1                   fadd   %st(1),%st
   8048473:       3d 00 e1 f5 05          cmp    $0x5f5e100,%eax
   8048478:       75 f6                   jne    8048470 <main+0x20>)

Now, my question is: why gcc-lno is doing that also when -ffast-math is
*not* passed???

Paolo.

Re: GCC beaten by ICC in stupid trig test!

[Paolo Carlini]

Paolo Carlini wrote:

> In the meanwhile we have learned that the real reason why Icc performs
> better then mainline gcc is the use of an iterative SSE instruction
> (see Dan Nicolaescu message).

+ the <math.h> interesting issue, of course, but the real point of my 
message
was the other one.

Paolo.

Re: GCC beaten by ICC in stupid trig test!

[Zdenek Dvorak]

Hello,

> >The reason why still is that ICC will just unroll the loop to be "r = 
> >doit(a)*100000000.0" so that is the reasons why
> >ICC is better than GCC at doing this stupid trig test (note this is 
> >transformation
> >is only valid if fast-math is on as you loose precision).
> 
> In the meanwhile we have learned that the real reason why Icc performs
> better then mainline gcc is the use of an iterative SSE instruction
> (see Dan Nicolaescu message).
> 
> On the other hand, gcc-lno "appear" to perform as well as Icc because of
> the unrolling trick (just checked that gcc-lno transforms the loop to
> the trivial:
>
>   8048470:       40                      inc    %eax
>   8048471:       d8 c1                   fadd   %st(1),%st
>   8048473:       3d 00 e1 f5 05          cmp    $0x5f5e100,%eax
>   8048478:       75 f6                   jne    8048470 <main+0x20>)
> 
> Now, my question is: why gcc-lno is doing that also when -ffast-math is
> *not* passed???

doing what? I do not see any loop related optimization here.

Zdenek

Re: GCC beaten by ICC in stupid trig test!

[Paolo Carlini]

Zdenek Dvorak wrote:

>doing what? I do not see any loop related optimization here.
>
Hi Zdenek. What is doing "the trick" (sorry for my informal words) on the
gcc-lno branch is -ftree-loop-optimize, *not* -funroll-loops.

When -ftree-loop-optimize is passed, the trigonometric computation (doit)
is moved outside of the loop, this is the complete result:

08048450 <main>:
 8048450:       55                      push   %ebp
 8048451:       d9 e8                   fld1
 8048453:       89 e5                   mov    %esp,%ebp
 8048455:       83 ec 18                sub    $0x18,%esp
 8048458:       83 e4 f0                and    $0xfffffff0,%esp
 804845b:       83 ec 10                sub    $0x10,%esp
 804845e:       dd 1c 24                fstpl  (%esp)
 8048461:       e8 aa ff ff ff          call   8048410 <doit>
 8048466:       d9 ee                   fldz
 8048468:       31 c0                   xor    %eax,%eax
 804846a:       8d b6 00 00 00 00       lea    0x0(%esi),%esi

 8048470:       40                      inc    %eax
 8048471:       d8 c1                   fadd   %st(1),%st
 8048473:       3d 00 e1 f5 05          cmp    $0x5f5e100,%eax
 8048478:       75 f6                   jne    8048470 <main+0x20>

 804847a:       dd d9                   fstp   %st(1)
 804847c:       dd 5c 24 04             fstpl  0x4(%esp)
 8048480:       c7 04 24 98 85 04 08    movl   $0x8048598,(%esp)
 8048487:       e8 a4 fe ff ff          call   8048330 <_init+0x48>
 804848c:       c9                      leave
 804848d:       31 c0                   xor    %eax,%eax
 804848f:       c3                      ret

Whereas, without -ftree-loop-optimize, we have:

08048450 <main>:
 8048450:       55                      push   %ebp
 8048451:       d9 ee                   fldz
 8048453:       89 e5                   mov    %esp,%ebp
 8048455:       53                      push   %ebx
 8048456:       83 ec 24                sub    $0x24,%esp
 8048459:       bb ff e0 f5 05          mov    $0x5f5e0ff,%ebx
 804845e:       dd 5d f0                fstpl  0xfffffff0(%ebp)
 8048461:       83 e4 f0                and    $0xfffffff0,%esp
 8048464:       83 ec 10                sub    $0x10,%esp
 8048467:       eb 09                   jmp    8048472 <main+0x22>
 8048469:       8d b4 26 00 00 00 00    lea    0x0(%esi),%esi

 8048470:       dd d8                   fstp   %st(0)
 8048472:       c7 04 24 00 00 00 00    movl   $0x0,(%esp)
 8048479:       b8 00 00 f0 3f          mov    $0x3ff00000,%eax
 804847e:       89 44 24 04             mov    %eax,0x4(%esp)
 8048482:       e8 89 ff ff ff          call   8048410 <doit>
 8048487:       dc 45 f0                faddl  0xfffffff0(%ebp)
 804848a:       4b                      dec    %ebx
 804848b:       dd 55 f0                fstl   0xfffffff0(%ebp)
 804848e:       79 e0                   jns    8048470 <main+0x20>

 8048490:       dd 5c 24 04             fstpl  0x4(%esp)
 8048494:       c7 04 24 b8 85 04 08    movl   $0x80485b8,(%esp)
 804849b:       e8 90 fe ff ff          call   8048330 <_init+0x48>
 80484a0:       8b 5d fc                mov    0xfffffffc(%ebp),%ebx
 80484a3:       31 c0                   xor    %eax,%eax
 80484a5:       c9                      leave
 80484a6:       c3                      ret

Perhaps it's ok moving doit even when -ffast-math is not passed, I don't
know for sure, honestly...

Thanks for your feedback,
Paolo.

Re: GCC beaten by ICC in stupid trig test!

[Zdenek Dvorak]

Hello,

> >doing what? I do not see any loop related optimization here.
> >
> Hi Zdenek. What is doing "the trick" (sorry for my informal words) on the
> gcc-lno branch is -ftree-loop-optimize, *not* -funroll-loops.
> 
> When -ftree-loop-optimize is passed, the trigonometric computation (doit)
> is moved outside of the loop, this is the complete result:

[snip]

> Perhaps it's ok moving doit even when -ffast-math is not passed, I don't
> know for sure, honestly...

it should be -- it is just an invariant motion (the value returned by
doit obviously is always the same, since we invoke it with the same
argument).

Zdenek

Re: GCC beaten by ICC in stupid trig test!

[Paolo Carlini]

Zdenek Dvorak wrote:

>>Perhaps it's ok moving doit even when -ffast-math is not passed, I don't
>>know for sure, honestly...
>>    
>>
>it should be -- it is just an invariant motion (the value returned by
>doit obviously is always the same, since we invoke it with the same
>argument).
>  
>
Ah, ok! On the other hand, it wouldn't be ok collapsing in a second step 
the whole
loop to a constant, right?

Paolo.

Re: GCC beaten by ICC in stupid trig test!

[Zdenek Dvorak]

Hello,

> >>Perhaps it's ok moving doit even when -ffast-math is not passed, I don't
> >>know for sure, honestly...
> >>   
> >>
> >it should be -- it is just an invariant motion (the value returned by
> >doit obviously is always the same, since we invoke it with the same
> >argument).
> > 
> >
> Ah, ok! On the other hand, it wouldn't be ok collapsing in a second step 
> the whole
> loop to a constant, right?

right.

Zdenek

Re: GCC beaten by ICC in stupid trig test!

[Joseph S. Myers]

On Mon, 15 Mar 2004, Zdenek Dvorak wrote:

> > Perhaps it's ok moving doit even when -ffast-math is not passed, I don't
> > know for sure, honestly...
> 
> it should be -- it is just an invariant motion (the value returned by
> doit obviously is always the same, since we invoke it with the same
> argument).

You need to allow for the possibility of doit trapping, but moving it
should still be OK in this case by virtue of C99 F.8.1#3: you don't need
to keep the same number of traps as implied by the source code.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: GCC beaten by ICC in stupid trig test!

[Paolo Carlini]

Joseph S. Myers wrote:

>You need to allow for the possibility of doit trapping, but moving it
>should still be OK in this case by virtue of C99 F.8.1#3: you don't need
>to keep the same number of traps as implied by the source code.
>  
>
Ah! Today I'm learning *too* much, thanks to everyone!

Now, I have another question: when -ffast-math is passed, should we even 
collapse
the loop to a single integer to be multiplied by the return value of doit?

Currently, on the gcc-lno branch we don't do that... or we don't *want* 
to do that? ;)

Naively, seems something really tricky to attempt because the sum 
involving the loop
index i may overflow in the process.

Paolo.

Re: GCC beaten by ICC in stupid trig test!

[Zdenek Dvorak]

Hello,

> >You need to allow for the possibility of doit trapping, but moving it
> >should still be OK in this case by virtue of C99 F.8.1#3: you don't need
> >to keep the same number of traps as implied by the source code.
> > 
> >
> Ah! Today I'm learning *too* much, thanks to everyone!
> 
> Now, I have another question: when -ffast-math is passed, should we even 
> collapse
> the loop to a single integer to be multiplied by the return value of doit?
> 
> Currently, on the gcc-lno branch we don't do that... or we don't *want* 
> to do that? ;)

we do not do that currently.  Something similar is on my todo list --
replacement of the final value of an eliminated induction variable,
as in

for (i = 0; i < 100; i++)
  a = 10 * i;
foo (a);

to

for (i = 0; i < 100; i++);
a = 1000;
foo (a);

but I am not sure whether to do it for non-integer variables as
well, due to reasons you mention below.

Zdenek

> Naively, seems something really tricky to attempt because the sum 
> involving the loop
> index i may overflow in the process.

Re: GCC beaten by ICC in stupid trig test!

[Segher Boessenkool]

> we do not do that currently.  Something similar is on my todo list --
> replacement of the final value of an eliminated induction variable,
> as in
>
> for (i = 0; i < 100; i++)
>   a = 10 * i;
> foo (a);
>
> to
>
> for (i = 0; i < 100; i++);
> a = 1000;
> foo (a);
>
> but I am not sure whether to do it for non-integer variables as
> well, due to reasons you mention below.

a = 990?  You don't need floats to do rounding errors ;-)


Segher

Re: GCC beaten by ICC in stupid trig test!

[Joseph S. Myers]

On Mon, 15 Mar 2004, Paolo Carlini wrote:

> Now, I have another question: when -ffast-math is passed, should we even 
> collapse
> the loop to a single integer to be multiplied by the return value of doit?

I don't know whether this will occur in real code (and so whether it is
worth doing), but replacing repeated addition with multiplication seems
like the sort of thing -ffast-math can do.  (The default for the
FP_CONTRACT pragma is implementation-defined, but that would only allow
contraction within a single expression, e.g. x+x+x+x --> 4*x, not in loops
like this.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: GCC viciously beaten by ICC in trig test!

[Roger Sayle]

On Sun, 14 Mar 2004, Scott Robert Ladd wrote:
> Consider the following program, compiled and run on a Pentium 4
> (Northwood) system:
>
>      #include <math.h>

For a number of benchmarks, just this first line of source code above
is enough to loose the race for GCC against Intel when compiling on Linux.

Consider the following:

	#include <math.h>

	double doit(double a)
	{
	  return sin(a) * sin(a);
	}


Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
significantly slower than Intel's compiler output.  However, commenting
out the "#include <math.h>" corrects the situation and GCC can then
generate *exactly* the same sequence as icc.


The issue is that glibc's headers provide inline implementations for sin
and cos, and thereby override all of GCC's internal builtin processing.
Once this is done, there's nothing tree-ssa, the middle-end or the i386
can do to improve the code.  If GCC is to have a hope of using "sincos"
or SSE2 specific instruction sequences, the "best intentions" of glibc's
headers (will) have to be neutralized first.  Perhaps fixincludes :>


For the interested with "#include <math.h>" GCC 3.3.3 generates

foo:    fldl    4(%esp)
        fld     %st(0)
#APP
        fsin
#NO_APP
        fxch    %st(1)
#APP
        fsin
#NO_APP
        fmulp   %st, %st(1)
        ret

without it, the same "-O2 -ffast-math -fomit-frame-pointer" options'
output is identical to the output from Intel v7.0 (and presumably later).

foo:    fldl    4(%esp)
        fsin
        fmul    %st(0), %st
        ret


Just another data point.  Avoiding <math.h> may improve your performance
and influence the results of your "command line option" experiments.

Roger
--

Re: GCC viciously beaten by ICC in trig test!

[Dan Nicolaescu]

Roger Sayle <roger@eyesopen.com> writes:

  > without it, the same "-O2 -ffast-math -fomit-frame-pointer" options'
  > output is identical to the output from Intel v7.0 (and presumably later).
>
  > foo:    fldl    4(%esp)
  >         fsin
  >         fmul    %st(0), %st
  >         ret

Intel 8.0 (that was used in the original test) generates something
very different:

# parameter 1: 8 + %ebx
..B1.1:                         # Preds ..B1.0
        pushl     %ebx                                          #5.1
        movl      %esp, %ebx                                    #5.1
        andl      $-8, %esp                                     #5.1
        subl      $8, %esp                                      #5.1
        movsd     8(%ebx), %xmm0                                #7.15
        call      __libm_sse2_sincos                            #7.15
                                # LOE ebp esi edi xmm0 xmm1
..B1.4:                         # Preds ..B1.1
        mulsd     %xmm1, %xmm1                                  #10.25
        mulsd     %xmm0, %xmm0                                  #10.15
        addsd     %xmm1, %xmm0                                  #10.25
        movsd     %xmm0, (%esp)                                 #10.25
        fldl      (%esp)                                        #10.25
        movl      %ebx, %esp                                    #10.25
        popl      %ebx                                          #10.25
        ret                                                     #10.25

 __libm_sse2_sincos seems to be an iterative SSE function. 

I guess the mystery is solved now. 

Re: GCC viciously beaten by ICC in trig test!

[Stelios Xanthakis]

On Sun, 14 Mar 2004, Dan Nicolaescu wrote:

> Roger Sayle <roger@eyesopen.com> writes:
>   >         fsin
>   >         fmul    %st(0), %st
> 
> Intel 8.0 (that was used in the original test) generates something
> very different:
> 
>         mulsd     %xmm1, %xmm1                                  #10.25
>         mulsd     %xmm0, %xmm0                                  #10.15
>         addsd     %xmm1, %xmm0                                  #10.25
>         movsd     %xmm0, (%esp)                                 #10.25
>         fldl      (%esp)                                        #10.25
> 

Does --fpmath=sse fix this?
Can the processor in question do sse for doubles?

In my experience, "--fpmath=sse --fsingle-precision-constants"
generates much faster code for a raytracer I have here.

Re: GCC viciously beaten by ICC in trig test!

[Dan Nicolaescu]

Stelios Xanthakis <sxanth@ceid.upatras.gr> writes:

  > On Sun, 14 Mar 2004, Dan Nicolaescu wrote:
  > 
  > > Roger Sayle <roger@eyesopen.com> writes:
  > >   >         fsin
  > >   >         fmul    %st(0), %st
  > > 
  > > Intel 8.0 (that was used in the original test) generates something
  > > very different:

Please be careful when snipping, the essential part that you deleted
is this: 


        call      __libm_sse2_sincos                            #7.15
                                # LOE ebp esi edi xmm0 xmm1
..B1.4:                         # Preds ..B1.1

i.e. ICC 8 generates a call to an SSE library function instead of
using the fsin instruction. Given that this changed from ICC 7 to ICC
8, the library function is probably faster. 

  > >         mulsd     %xmm1, %xmm1                                  #10.25
  > >         mulsd     %xmm0, %xmm0                                  #10.15
  > >         addsd     %xmm1, %xmm0                                  #10.25
  > >         movsd     %xmm0, (%esp)                                 #10.25
  > >         fldl      (%esp)                                        #10.25
  > > 
  > 
  > Does --fpmath=sse fix this?
  > Can the processor in question do sse for doubles?
  > 
  > In my experience, "--fpmath=sse --fsingle-precision-constants"
  > generates much faster code for a raytracer I have here.

See above. 

Re: GCC viciously beaten by ICC in trig test!

[Kaveh R. Ghazi]

 > The issue is that glibc's headers provide inline implementations for
 > sin and cos, and thereby override all of GCC's internal builtin
 > processing.  Once this is done, there's nothing tree-ssa, the
 > middle-end or the i386 can do to improve the code.  If GCC is to have
 > a hope of using "sincos" or SSE2 specific instruction sequences, the
 > "best intentions" of glibc's headers (will) have to be neutralized
 > first.  Perhaps fixincludes :>


Or you can pass -D__NO_INLINE__ on the command line.  I'm of the
opinion that we should add that to GCC's specs for all glibc systems.

We already do something analogous during bootstrap for GCC itself to
disable all of the glibc string inlines.  I don't see why the rest of
the world has to suffer through them when these things belong in the
compiler anyway.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: GCC viciously beaten by ICC in trig test!

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

>  > The issue is that glibc's headers provide inline implementations for
>  > sin and cos, and thereby override all of GCC's internal builtin
>  > processing.  Once this is done, there's nothing tree-ssa, the
>  > middle-end or the i386 can do to improve the code.  If GCC is to have
>  > a hope of using "sincos" or SSE2 specific instruction sequences, the
>  > "best intentions" of glibc's headers (will) have to be neutralized
>  > first.  Perhaps fixincludes :>
>
>
> Or you can pass -D__NO_INLINE__ on the command line.  I'm of the
> opinion that we should add that to GCC's specs for all glibc systems.
>
> We already do something analogous during bootstrap for GCC itself to
> disable all of the glibc string inlines.  I don't see why the rest of
> the world has to suffer through them when these things belong in the
> compiler anyway.

If all functions that glibc's header provide are implemented in GCC
(remember there was a time GCC didn't include any of these
optimizations and only glibc did), then I propose to get even rid of
them in glibc.  But for now there should still be a few functions
missing...

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Andreas Jaeger <aj@suse.de> writes:

| "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
| 
| >  > The issue is that glibc's headers provide inline implementations for
| >  > sin and cos, and thereby override all of GCC's internal builtin
| >  > processing.  Once this is done, there's nothing tree-ssa, the
| >  > middle-end or the i386 can do to improve the code.  If GCC is to have
| >  > a hope of using "sincos" or SSE2 specific instruction sequences, the
| >  > "best intentions" of glibc's headers (will) have to be neutralized
| >  > first.  Perhaps fixincludes :>
| >
| >
| > Or you can pass -D__NO_INLINE__ on the command line.  I'm of the
| > opinion that we should add that to GCC's specs for all glibc systems.
| >
| > We already do something analogous during bootstrap for GCC itself to
| > disable all of the glibc string inlines.  I don't see why the rest of
| > the world has to suffer through them when these things belong in the
| > compiler anyway.
| 
| If all functions that glibc's header provide are implemented in GCC
| (remember there was a time GCC didn't include any of these
| optimizations and only glibc did), then I propose to get even rid of
| them in glibc.

Agreed.  However, GCC emits native instructions which may be bogus for
some of them -- where Glibc do actual computations.  So when removing
the inlines from Glibc, we should be cautious about some of the native
instructions.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Roger Sayle wrote:
> Consider the following:
> 
> #include <math.h>
> 
> double doit(double a) { return sin(a) * sin(a); }
> 
> 
> Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
>  significantly slower than Intel's compiler output.  However,
> commenting out the "#include <math.h>" corrects the situation and GCC
> can then generate *exactly* the same sequence as icc.

Wonderful! This is *exactly* the insight I was looking for...

> The issue is that glibc's headers provide inline implementations for
> sin and cos, and thereby override all of GCC's internal builtin
> processing.

I should have thought of this; I've had some past problems with glibc
headers causing problems in my code.

> Once this is done, there's nothing tree-ssa, the middle-end or the
> i386 can do to improve the code.  If GCC is to have a hope of using
> "sincos" or SSE2 specific instruction sequences, the "best
> intentions" of glibc's headers (will) have to be neutralized first.
> Perhaps fixincludes :>

Sometimes, I wonder if GCC should ship its own Standard C library, just
as it ships a Standard C++ template library. However, I suspect the
suggesting such a move might be a bit controversial... ;)

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

| Roger Sayle wrote:
| > Consider the following:
| > #include <math.h>
| > double doit(double a) { return sin(a) * sin(a); }
| > Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
| >  significantly slower than Intel's compiler output.  However,
| > commenting out the "#include <math.h>" corrects the situation and GCC
| > can then generate *exactly* the same sequence as icc.
| 
| Wonderful! This is *exactly* the insight I was looking for...

Note that it has been reported in the past the the x86 native
instruction fsin yields incorrect results for values outside or a
certain interval (I can't remember which exactly). 

[...]

| Sometimes, I wonder if GCC should ship its own Standard C library, just
| as it ships a Standard C++ template library. However, I suspect the
| suggesting such a move might be a bit controversial... ;)

Yep, but it would make V3 happy ;-)

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Segher Boessenkool]

> Note that it has been reported in the past the the x86 native
> instruction fsin yields incorrect results for values outside or a
> certain interval (I can't remember which exactly).
>

+/- 2**63, on i387.  Original pentium is supposed to be 1 ulp
accurate for all valid inputs (no idea if it actually is).

Don't know for other chips.


Segher

Re: GCC viciously beaten by ICC in trig test!

[Geert Bosch]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]


On Mar 15, 2004, at 09:34, Segher Boessenkool wrote:
> +/- 2**63, on i387.  Original pentium is supposed to be 1 ulp
> accurate for all valid inputs (no idea if it actually is).
>
> Don't know for other chips.

It's not. The argument reduction uses a 68-bit approximation
of pi, which means that for sin (pi) the argument retains
only about 4 significant bits and in this case results in
about 4 bits of precision in the output. We recently became
aware of this issue for Ada and are working on fixing this.

   -Geert

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 532 bytes --]

Re: GCC viciously beaten by ICC in trig test!

[Geert Bosch]

Apologies for the junk signature on my previous email.

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

| On Sun, 14 Mar 2004, Scott Robert Ladd wrote:
| > Consider the following program, compiled and run on a Pentium 4
| > (Northwood) system:
| >
| >      #include <math.h>
| 
| For a number of benchmarks, just this first line of source code above
| is enough to loose the race for GCC against Intel when compiling on Linux.
| 
| Consider the following:
| 
| 	#include <math.h>
| 
| 	double doit(double a)
| 	{
| 	  return sin(a) * sin(a);
| 	}
| 
| 
| Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
| significantly slower than Intel's compiler output.  However, commenting
| out the "#include <math.h>" corrects the situation and GCC can then
| generate *exactly* the same sequence as icc.

In summary,  in order to get decent codes from GCC on Linux, nobody
should be including standard headers supposed to bring appropriate
declarations for names used in codes.  Oh well.

[...]

| Just another data point.  Avoiding <math.h> may improve your performance

That is a joke ;-)

In real world, people have to include standard headers in order to get
appropriate declarations.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> In summary,  in order to get decent codes from GCC on Linux, nobody
> should be including standard headers supposed to bring appropriate
> declarations for names used in codes.  Oh well.

And the other solution -- using -D__NO_INLINE__ -- is counterintuitive 
(though effective on my "doit" example, according to a quick test I just 
ran.) Why would someone seeking to generate fast code use a definition 
that disables inline functions?

It appears that two generalized, portable solutions (glibc and gcc) 
cancel each other out, resulting in poor code generation.

Perhaps GCC can be modified to automatically use the -D__NO_INLINE__ 
switch on glibc platforms -- although using that switch may not always 
be wise. I compiled one of my "big" applications with -D__NO_INLINE__, 
and it's run-time was reduced substantially -- to ZERO. I'm too tired 
tonight to figure out why; I'll look into it tomorrow.

> In real world, people have to include standard headers in order to get
> appropriate declarations.

Exactly. The provided solution isn't really a solution, given that 
portable code is going to use ANSI standard headers by definition.


-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[James Morrison]

Roger Sayle <roger@eyesopen.com> writes:

> On Sun, 14 Mar 2004, Scott Robert Ladd wrote:
> > Consider the following program, compiled and run on a Pentium 4
> > (Northwood) system:
> >
> >      #include <math.h>
> 
> For a number of benchmarks, just this first line of source code above
> is enough to loose the race for GCC against Intel when compiling on Linux.
> 
> Consider the following:
> 
> 	#include <math.h>
> 
> 	double doit(double a)
> 	{
> 	  return sin(a) * sin(a);
> 	}
> 
> 
> Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
> significantly slower than Intel's compiler output.  However, commenting
> out the "#include <math.h>" corrects the situation and GCC can then
> generate *exactly* the same sequence as icc.

 You probably want to bring this up on libc-alpha to see if Ulrich will
remove the inline math functions then.

Jim

Re: GCC viciously beaten by ICC in trig test!

[Jakub Jelinek]

On Mon, Mar 15, 2004 at 12:15:31AM -0500, James Morrison wrote:
> > For a number of benchmarks, just this first line of source code above
> > is enough to loose the race for GCC against Intel when compiling on Linux.
> > 
> > Consider the following:
> > 
> > 	#include <math.h>
> > 
> > 	double doit(double a)
> > 	{
> > 	  return sin(a) * sin(a);
> > 	}
> > 
> > 
> > Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
> > significantly slower than Intel's compiler output.  However, commenting
> > out the "#include <math.h>" corrects the situation and GCC can then
> > generate *exactly* the same sequence as icc.
> 
>  You probably want to bring this up on libc-alpha to see if Ulrich will
> remove the inline math functions then.

Well, the inlines shouldn't be removed, but guarded with
# if !__GNUC_PREREQ (MAJOR,MINOR)
...
# endif
where MAJOR, MINOR is the first __GNUC__ and __GNUC_MINOR__ of GCC which
can handle all cases the same or better than the glibc inline.
This is true for both math inlines and stringops (the latter is harded,
because for some functions, GCC generates better code for some testcases
and GLIBC for others).
So GCC and GLIBC need to cooperate in testing/benchmarking to create the
list of MAJOR,MINOR when sufficiently good builtin was introduced in GCC.

	Jakub

Re: GCC viciously beaten by ICC in trig test!

[Joe Buck]

On Mon, Mar 15, 2004 at 07:11:04AM +0100, Jakub Jelinek wrote:
> Well, the inlines shouldn't be removed, but guarded with
> # if !__GNUC_PREREQ (MAJOR,MINOR)
> ...
> # endif
> where MAJOR, MINOR is the first __GNUC__ and __GNUC_MINOR__ of GCC which
> can handle all cases the same or better than the glibc inline.

Is the proper requirement "all cases"?  What if the glibc inline is
sometimes better, but sometimes far worse?

Also, that method means that the glibc people have to maintain crufty
inline assembler forever for the sake of producing slightly better code
on some ancient GCC version.  Speed is important, but so is
maintainability, so this might be worth doing only if the speed gain is
substantial.

Re: GCC viciously beaten by ICC in trig test!

[Jakub Jelinek]

On Mon, Mar 15, 2004 at 10:13:13AM -0800, Joe Buck wrote:
> On Mon, Mar 15, 2004 at 07:11:04AM +0100, Jakub Jelinek wrote:
> > Well, the inlines shouldn't be removed, but guarded with
> > # if !__GNUC_PREREQ (MAJOR,MINOR)
> > ...
> > # endif
> > where MAJOR, MINOR is the first __GNUC__ and __GNUC_MINOR__ of GCC which
> > can handle all cases the same or better than the glibc inline.
> 
> Is the proper requirement "all cases"?  What if the glibc inline is
> sometimes better, but sometimes far worse?

Ok, all cases is not necessary, but good judgement needs to be applied.
I've tried to look at a few inlines today, e.g. signbit in GCC is as good
as glibc builtin, which means __builtin_signbit should be used,
but already on IA-32 __builtin_signbitl is worse.
Although GCC 3.5 has really many math builtins, most of them do nothing
and thus are usually worse than what GLIBC provides (tried e.g. exp, tan).

	Jakub

Re: GCC viciously beaten by ICC in trig test!

[Ranjit Mathew]

Roger Sayle wrote:
> Compiling with gcc -O2 -ffast-math on Linux generates x86 code that's
> significantly slower than Intel's compiler output.  However, commenting
> out the "#include <math.h>" corrects the situation and GCC can then
> generate *exactly* the same sequence as icc.

Thank you *so much* for that insight!

Looking at the glibc 2.3.2 headers (bits/mathinline.h)
on my RHEL3 system, a simple workaround might be to
add -D__NO_MATH_INLINES to the compiler command line.

Depending on when we started to do magic with trig.
functions, perhaps the glibc maintainers ought to \
modify that "#if __GNU_PREREQ (2, 8)" guard for
the inlined trig. functions appropriately.

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/

Re: GCC viciously beaten by ICC in trig test!

[Toon Moene]

Roger Sayle wrote:

> On Sun, 14 Mar 2004, Scott Robert Ladd wrote:
> 
>>Consider the following program, compiled and run on a Pentium 4
>>(Northwood) system:
>>
>>     #include <math.h>
> 
> For a number of benchmarks, just this first line of source code above
> is enough to loose the race for GCC against Intel when compiling on Linux.

Indeed - and that's the basic reason why you should write this kind of 
software in Fortran: No pesky header files destroying your carefully 
optimized code ....

[ OK, I couldn't resist :-) :-) ]

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Re: GCC viciously beaten by ICC in trig test!

[Laurent GUERBY]

On Mon, 2004-03-15 at 20:05, Toon Moene wrote:
> Roger Sayle wrote:
> > On Sun, 14 Mar 2004, Scott Robert Ladd wrote:
> >>Consider the following program, compiled and run on a Pentium 4
> >>(Northwood) system:
> >>
> >>     #include <math.h>
> > 
> > For a number of benchmarks, just this first line of source code above
> > is enough to loose the race for GCC against Intel when compiling on Linux.
> 
> Indeed - and that's the basic reason why you should write this kind of 
> software in Fortran: No pesky header files destroying your carefully 
> optimized code ....
> 
> [ OK, I couldn't resist :-) :-) ]

Arghhh tempting... or Ada? With GCC 3.3.2 from Fedora Core 1, the do_it
call is removed from the loop at -O1 (the curious can check pragma Pure
in the Ada Reference Manual).

:)

Laurent


with Ada.Numerics.Long_Elementary_Functions;
with Ada.Text_IO;

procedure P1 is
   use Ada.Numerics.Long_Elementary_Functions;
   use Ada.Text_IO;

   subtype Num is Long_Float;

   function Do_It (A : in Num) return Num is
      C : constant Num := Cos (A);
      S : constant Num := Sin (A);
   begin
      return S * S + C * C;
   end Do_It;

   A : Num := 1.0;
   R : Num := 0.0;

begin
   for I in 1 .. 100_000_000 loop
      R := R + Do_It (A);
   end loop;

   Put_Line (Num'Image (R));
end P1;

Re: GCC viciously beaten by ICC in trig test!

[Stephan T. Lavavej]

[Scott Robert Ladd]
> Sometimes, I wonder if GCC should ship its own Standard C
> library, just as it ships a Standard C++ template library.
> However, I suspect the suggesting such a move might be a bit
> controversial... ;)

Why doesn't it?

On MinGW, you can't use %lld with printf(), because MSVCRT doesn't
understand it properly.  If GCC provided its own Standard C library, that'd
be awesome.

Stephan T. Lavavej
http://nuwen.net

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

"Stephan T. Lavavej" <stl@caltech.edu> writes:

| [Scott Robert Ladd]
| > Sometimes, I wonder if GCC should ship its own Standard C
| > library, just as it ships a Standard C++ template library.
| > However, I suspect the suggesting such a move might be a bit
| > controversial... ;)
| 
| Why doesn't it?

This is a tricky issue. Some standards (e.g. POSIX) make conflicting
requirements to that of ISO C standard, and as a matter of fact
demand that the C standard headers be modified.  If GCC/gcc had to
come with its own C headers, then it would have to implement those
standards too -- in order to comply with user expectations.
That is a mess and GCC has better not drive into that.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> This is a tricky issue. Some standards (e.g. POSIX) make conflicting
> requirements to that of ISO C standard, and as a matter of fact
> demand that the C standard headers be modified.  If GCC/gcc had to
> come with its own C headers, then it would have to implement those
> standards too -- in order to comply with user expectations.
> That is a mess and GCC has better not drive into that.

Perhaps GCC could provide a clean ISO C library that is enabled with the 
-std=c99 switch? After all, GCC does include an ISO C++ library, and a 
Fortran 95 library (in tree-ssa).

The compiler could link against the system C library, except when the 
user explicitly declares that they wish to use the GCC-supplied library.

I've also noticed a couple of alternative libraries for embedded systems 
(uClib and newlib). I may experiment with these...

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

| Gabriel Dos Reis wrote:
| > This is a tricky issue. Some standards (e.g. POSIX) make conflicting
| > requirements to that of ISO C standard, and as a matter of fact
| > demand that the C standard headers be modified.  If GCC/gcc had to
| > come with its own C headers, then it would have to implement those
| > standards too -- in order to comply with user expectations.
| > That is a mess and GCC has better not drive into that.
| 
| Perhaps GCC could provide a clean ISO C library that is enabled with
| the -std=c99 switch? After all, GCC does include an ISO C++ library,
| and a Fortran 95 library (in tree-ssa).

I don't know.  Surely, that would help V3 but I'm not sure it would be
a global gain.

I don't know the situation for Fortran 95 users, but my experience is
that C++ users find it quite annoying when other standards hijack
C++ standard headers rather than defining new ones for their purposes.
So, the issue there (in C++ land) is radically different from that in C
land.  [First, have C users include standard headers instead of
prototyping "by hand" :-)]

| The compiler could link against the system C library, except when the
| user explicitly declares that they wish to use the GCC-supplied
| library.
| 
| I've also noticed a couple of alternative libraries for embedded
| systems (uClib and newlib). I may experiment with these...

Sure.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Gabriel Dos Reis wrote:
> I don't know the situation for Fortran 95 users, but my experience is
>  that C++ users find it quite annoying when other standards hijack 
> C++ standard headers rather than defining new ones for their 
> purposes.

Reality (POSIX, et al mucking in C headers) is never as good as fantasy
(neatly and individually-packaged standards). Vendors are equally guilt,
sticking their own "stuff" into standard headers. The whole idea of a
"standard" is portability!

Arrgghh. Yes, this is a pet peeve of mine. Well fed, too. ;)

> So, the issue there (in C++ land) is radically different from that in
>  C land.  [First, have C users include standard headers instead of 
> prototyping "by hand" :-)]

Oh, some of us old C jockeys (I started on the PDP-8) think poorly of
header pollution. By the time C became a standard, every vendor had
their own "thing" going, and this evolved into a lack of respect for
standards integrity.

..Scott

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Ian Lance Taylor]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

> Perhaps GCC could provide a clean ISO C library that is enabled with
> the -std=c99 switch? After all, GCC does include an ISO C++ library,
> and a Fortran 95 library (in tree-ssa).

The subset of programs which can work using only the ISO C standard
functions is relatively small.  And the GNU project is already
supporting a standard library--glibc.  I think the set of people who
could benefit from such an effort is small.

> I've also noticed a couple of alternative libraries for embedded
> systems (uClib and newlib). I may experiment with these...

newlib is indeed a more or less ISO C compliant library for embedded
systems.  It has some POSIX.1 stuff.  There has been some effort to
keep the headers ISO C namespace clean in the presence of
__STRICT_ANSI__.  I don't think anything has been done for any new c99
functions.  There are assembler versions of a few functions.

I haven't used uClib.

Ian

RE: GCC viciously beaten by ICC in trig test!

[Stephan T. Lavavej]

[Ian Lance Taylor]
> The subset of programs which can work using only the ISO C
> standard functions is relatively small.

On the other hand, basically all programs use the ISO C standard functions.
Consistency in the standard functions would be nice.

And if this helps libstdc++, as Gabriel Dos Reis says, all the better.

> And the GNU project is already supporting a standard library
> --glibc.

Which, as far as I know, doesn't work on Windows.

As a user, I don't get why the C++ Standard Library gets to be in GCC, but
the C Standard Library doesn't.  There are crazy extensions in C++ land too,
aren't there?  If the situation with C++ were the same as the situation with
C, wouldn't everyone have to go forage for their own STL implementations?
Isn't that what people /did/ in the days of STLport and that nonsense?

And if this POSIX stuff causes problems, why can't two versions be
implemented - one pure 9899 1999, the other with all of the POSIX gunk that
users "expect".

I recently found that math.h (on GNU/Linux and MinGW, no less) was
prototyping some fool function named y1, which is not ISO.  I didn't want
that gunk, but couldn't avoid it.

Quoth IRC...

<ithil> I say I can understand aversion to stupid standards, but for Pham's
sake, they're implementing /14882/
<ithil> The translation is none of the developers want to touch POSIX with a
ten-foot pole
<STL> Yeah, but /someone/ has to, ithil
<STL> It should be centralized to gcc, even though they don't want to do it
^_^
<ithil> write a patch ;p
<STL> Ha, now you're thinking like a gcc developer

Stephan T. Lavavej
http://nuwen.net

Re: GCC viciously beaten by ICC in trig test!

[Jakub Jelinek]

On Mon, Mar 15, 2004 at 08:25:31AM -0800, Stephan T. Lavavej wrote:
> I recently found that math.h (on GNU/Linux and MinGW, no less) was
> prototyping some fool function named y1, which is not ISO.  I didn't want

y1 is indeed just Unix 95, Unix 98, Unix 2003, SVID3 and 4.3BSD function.
In glibc, you get y1 prototyped in math.h if you request BSD, SVID or XOPEN
standards.  BSD and SVID are the defaults if you don't choose any standards.
If you want say strict ISO C99 (or ISO C90), just compile with gcc -std=c99,
gcc -D_ISOC99_SOURCE or gcc -std=c89, gcc -ansi and y1 will not be prototyped.

	Jakub

Re: GCC viciously beaten by ICC in trig test!

[Ian Lance Taylor]

"Stephan T. Lavavej" <stl@caltech.edu> writes:

> As a user, I don't get why the C++ Standard Library gets to be in GCC, but
> the C Standard Library doesn't.  There are crazy extensions in C++ land too,
> aren't there?  If the situation with C++ were the same as the situation with
> C, wouldn't everyone have to go forage for their own STL implementations?
> Isn't that what people /did/ in the days of STLport and that nonsense?

I see two reasons.  First, it's historical.  Second, C++ libraries are
often tied to the details of the compiler as the compiler evolves and
adds features.  Remember that the C++ standard is relatively new, and
that very few (I think only one) C++ compiler is fully standard
compliant.  The C++ library relies on the details of the C++ compiler
far more than the C library relies on the details of the C compiler.
Even today libstdc++-v3 uses at least one g++ extension--
attribute((strong)).  G++ has always been distributed with a C++
library--it used to be called libg++, then libstdc++, and now
libstdc++-v3.

Also, as others have noted, operating systems, not to mention POSIX
itself, have traditionally overloaded the ISO C header files with
additional declarations.  If gcc provided its own ISO C header files,
it still could not ignore those operating system extensions, because
real programs on those operating systems rely on them.  For example,
the glibc stdio.h defines functions like fmemopen, and those functions
are presumably implemented using internal details of FILE, which means
that fmemopen isn't going to interoperate with the gcc implementation
of getchar/fread, etc.  This leads you down the road of only using the
ISO C library for programs compiled with -ansi or -std=..., but then
we're back to the fact that relatively few programs can work in that
environment.

I don't think that any of these problems are insoluble, by the way.
But somebody would really have to word hard to develop a solution.

And first that person has to get buyin from the steering committee, of
course.

> And if this POSIX stuff causes problems, why can't two versions be
> implemented - one pure 9899 1999, the other with all of the POSIX gunk that
> users "expect".

Since you mentioned Windows, I'll note that doing a Windows port of
the POSIX API (without using the broken Windows Posix services) is
quite a pain.  Starting along that path basically led to the cygwin
project.

Ian

Re: GCC viciously beaten by ICC in trig test!

[Paolo Carlini]

Ian Lance Taylor wrote:

>The C++ library relies on the details of the C++ compiler
>far more than the C library relies on the details of the C compiler.
>Even today libstdc++-v3 uses at least one g++ extension--
>attribute((strong)).
>
All in all I'm not sure to fully agree...

Actually, attribute((strong)) is a *recent* entry, only to support debug
mode, which I find really great! but not part of the core functionalities,
those mandated by the standard.

Otherwise, a bunch of builtin_expect (glibc also uses that, right?... and we
don't even agree that they are always so beneficial in our case), a bunch of
builtin_alloca, quite useful I admit, what else?

Paolo.

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@suse.de> writes:

| Ian Lance Taylor wrote:
| 
| >The C++ library relies on the details of the C++ compiler
| >far more than the C library relies on the details of the C compiler.
| >Even today libstdc++-v3 uses at least one g++ extension--
| >attribute((strong)).
| >
| All in all I'm not sure to fully agree...
| 
| Actually, attribute((strong)) is a *recent* entry, only to support debug
| mode, which I find really great! but not part of the core functionalities,
| those mandated by the standard.

Agreed.

| Otherwise, a bunch of builtin_expect (glibc also uses that, right?... and we
| don't even agree that they are always so beneficial in our case), a bunch of
| builtin_alloca, quite useful I admit, what else?

The primary reasons we're using the mojority of __builtin_xxx stuff in
V3 is precisely because we don't have control over the C library so we
use those in the hope that the compiler will forward them to the "right"
functions. The optimization argument is secondary.  The use of
__builtin_expect() is largely (early) optimization based on speculation and
could be removed without damaging the library.  __builtin_alloca is
used as a *convienient* allocation routine on the stack.  It could be
replaced with malloc/free pair. (I don't suggest that though).

The real part tied to the compiler is libsupc++, but that is precisely
the part required in any freestanding implementation -- just like the
C standard requires part of its library to be included in freestanding
implementations.   The rest of the library is much much larger.

-- Gaby
 

Re: GCC viciously beaten by ICC in trig test!

[Paolo Carlini]

Gabriel Dos Reis wrote:

>The primary reasons we're using the mojority of __builtin_xxx stuff in
>V3 is precisely because we don't have control over the C library so we
>use those in the hope that the compiler will forward them to the "right"
>functions. The optimization argument is secondary.  The use of
>__builtin_expect() is largely (early) optimization based on speculation and
>could be removed without damaging the library.  __builtin_alloca is
>used as a *convienient* allocation routine on the stack.  It could be
>replaced with malloc/free pair. (I don't suggest that though).
>  
>
Thanks for explaining those points.

In my previous message, however, I forgot one important extension and 
you are
the best person to shed light on it: extern template. What's that? Could we
renounce to it?

Paolo.

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@suse.de> writes:

| In my previous message, however, I forgot one important extension and
| you are
| the best person to shed light on it: extern template. What's that? Could we
| renounce to it?

There are two points of history here:
  (1) in the dark ages, "extern template" was supposed to provide a
      form of separate compilation of templates -- in fact, 
      that syntax was rumored along with "export"; there were long,
      "heated" debates, and in final, "export" syntax won.  Note too,
      that "export" or "extern template" can in only after some "radical"
      positions were operated (some implementors adopted to replace
      the kind of separate compilation provided by CFront with the
      inclusion model championed in the Borland implementation.  I was
      told recently that it would be an MS extension actually).

  (2) In the current proposal for "extern template", it is just a way
      to tell the compiler not to instantiate right now from an
      arbitraty template definition that would be around.  It is
      essentially a mean to forward declare an explicit instantiation.

We use "extern templates" only as code-size optimization.  It could be
removed without damage.

There are cases where a form of "extern template" is needed, we don't
have those cases in the library as currently implemented.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

| "Stephan T. Lavavej" <stl@caltech.edu> writes:
| 
| > As a user, I don't get why the C++ Standard Library gets to be in GCC, but
| > the C Standard Library doesn't.  There are crazy extensions in C++ land too,
| > aren't there?  If the situation with C++ were the same as the situation with
| > C, wouldn't everyone have to go forage for their own STL implementations?
| > Isn't that what people /did/ in the days of STLport and that nonsense?
| 
| I see two reasons.  First, it's historical.  Second, C++ libraries are

I agree on the historical part.  But I do not agree on the rest.

| often tied to the details of the compiler as the compiler evolves and
| adds features.

They are no more than C libraries are tied to compilers.  In fact, in
the old days, libg++ used to come in a separate package.  More to the
point, you have a huge amount of C++ libraries out there that are no
more tied to the details of compilers.

| Remember that the C++ standard is relatively new, and
| that very few (I think only one) C++ compiler is fully standard
| compliant.

And before we got ISO C++, there used to be de facto standard for C++: 
TC++PL1, ARM, TC++PL2. Still, the situation is less chaotic.

| The C++ library relies on the details of the C++ compiler
| far more than the C library relies on the details of the C compiler.
| Even today libstdc++-v3 uses at least one g++ extension--
| attribute((strong)).

That is a non-argument.  The GNU extension attribute(strong))
is *not* needed to implement the C++ standard library.  It is a
helpful tool to support *different versions* of  the library
source co-existing at the same time.  

There are competitors out there that sell implementations of the C++
standard library only.

| G++ has always been distributed with a C++
| library--it used to be called libg++, then libstdc++, and now
| libstdc++-v3.

No.  The package libg++ was distributed separately.  Only with EGCS,
did we stop that separation.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Ian Lance Taylor]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> They are no more than C libraries are tied to compilers.  In fact, in
> the old days, libg++ used to come in a separate package.  More to the
> point, you have a huge amount of C++ libraries out there that are no
> more tied to the details of compilers.

OK, noted.

Should we spin off libstdc++-v3?  Why or why not?

> | G++ has always been distributed with a C++
> | library--it used to be called libg++, then libstdc++, and now
> | libstdc++-v3.
> 
> No.  The package libg++ was distributed separately.  Only with EGCS,
> did we stop that separation.

libg++ was distributed separately, but my recollection is that it was
pretty closely tied to the g++ release cycle.  After all, g++ used to
be released separately too, but that didn't mean that it wasn't
closely tied to gcc.

But I admit that I may be wrong, and that these details are
unimportant today.

Ian

Re: GCC viciously beaten by ICC in trig test!

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

| Should we spin off libstdc++-v3?  Why or why not?


I don't see any immediate reason why V3 should be released
separately.   I far more appreciate the easy and integrated build we
have now than what we had in the old days with libg++.

-- Gaby

Re: GCC viciously beaten by ICC in trig test!

[Joe Buck]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> > They are no more than C libraries are tied to compilers.  In fact, in
> > the old days, libg++ used to come in a separate package.  More to the
> > point, you have a huge amount of C++ libraries out there that are no
> > more tied to the details of compilers.

On Mon, Mar 15, 2004 at 12:27:54PM -0500, Ian Lance Taylor wrote:
> OK, noted.
> 
> Should we spin off libstdc++-v3?  Why or why not?

As the saying goes, if it ain't broke, don't fix it.  Our current C++
development process seems to be working well; there are still more bugs
than I'd like, but we are making huge progress.

> libg++ was distributed separately, but my recollection is that it was
> pretty closely tied to the g++ release cycle.  After all, g++ used to
> be released separately too, but that didn't mean that it wasn't
> closely tied to gcc.

The old libg++ model allowed for looser coupling: bug fix versions of
libg++ could be released at a different pace than bug fix versions of the
compiler, but the first two digits of version numbers had to match.
This gave the ability to release bug fixes for one without doing a new
release of the other.

Re: GCC viciously beaten by ICC in trig test!

[Phil Edwards]

On Mon, Mar 15, 2004 at 12:27:54PM -0500, Ian Lance Taylor wrote:
> 
> Should we spin off libstdc++-v3?  Why or why not?

It used to be its own package.  Now it's tied very tightly to specific
versions of the compiler, much like libg++ was.


> > | G++ has always been distributed with a C++
> > | library--it used to be called libg++, then libstdc++, and now
> > | libstdc++-v3.
> > 
> > No.  The package libg++ was distributed separately.  Only with EGCS,
> > did we stop that separation.
> 
> libg++ was distributed separately, but my recollection is that it was
> pretty closely tied to the g++ release cycle.  After all, g++ used to
> be released separately too, but that didn't mean that it wasn't
> closely tied to gcc.

Yep.  libg++ had the same set of version numbers as g++.  You had to
install matching versions or things would break, sometimes silently.
If we were to package libstdc++-v3 separately, the same would be true,
so there's no real advantage in doing so.

-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: GCC viciously beaten by ICC in trig test!

[Joe Buck]

On Mon, Mar 15, 2004 at 07:38:43AM -0500, Scott Robert Ladd wrote:
> Gabriel Dos Reis wrote:
> > This is a tricky issue. Some standards (e.g. POSIX) make conflicting
> > requirements to that of ISO C standard, and as a matter of fact
> > demand that the C standard headers be modified.  If GCC/gcc had to
> > come with its own C headers, then it would have to implement those
> > standards too -- in order to comply with user expectations.
> > That is a mess and GCC has better not drive into that.
> 
> Perhaps GCC could provide a clean ISO C library that is enabled with the 
> -std=c99 switch?

You are talking to the wrong people.  If we get poor performance because
of glibc, the glibc people should fix it.

> After all, GCC does include an ISO C++ library, and a 
> Fortran 95 library (in tree-ssa).

Yes, and the GCC ISO C++ library has its own group of developers and its
own development list; it's just that they work much more closely with the
compiler team than the GNU C library people do.  This, in my view, is a
bug; we need to figure out ways of improving our relationships with the
glibc developers.

Re: GCC viciously beaten by ICC in trig test!

[Scott Robert Ladd]

Joe Buck wrote:
> You are talking to the wrong people.  If we get poor performance because
> of glibc, the glibc people should fix it.

I completely agree. I guess I need to go pester another mailing list... :)

> Yes, and the GCC ISO C++ library has its own group of developers and its
> own development list; it's just that they work much more closely with the
> compiler team than the GNU C library people do.  This, in my view, is a
> bug; we need to figure out ways of improving our relationships with the
> glibc developers.

That, I suspect, is an issue for respective steering committees.


-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: GCC viciously beaten by ICC in trig test!

[Zack Weinberg]

Scott Robert Ladd <coyote@coyotegulch.com> writes:

> Perhaps GCC could provide a clean ISO C library that is enabled with
> the -std=c99 switch? After all, GCC does include an ISO C++ library,
> and a Fortran 95 library (in tree-ssa).

My opinion of this notion is summed up by this excerpt of a message I
posted to a private news hierarchy back near the end of 2003.

=====
| I can't work out whether you're of the opinion that a deeply
| incestuous relationship between a C compiler project and a C 
| library project is a good thing or a bad thing.

[...]
In the abstract, I think that *if* the "C language runtime" part of a
C library were disentangled from the "low-level operating system
interface" part, the "useful but nonstandard utility routines" part,
and the "shared object loader" part, then it would be good to have a
close relationship between the language runtime project and the
compiler project.  The other projects, however, ought to be prohibited
from communicating with the language runtime and compiler teams except
via standards committees.  (They don't have to be formal and 
ISO-recognized or anything; an IETFish process would be fine.)

This, however, will never happen (disentanglement would require
redesigning the entire C library and bits of the language), and so I
am in favor of generally distant relations between compiler and
library teams.
=====

zw

Re: GCC viciously beaten by ICC in trig test!

[Kai Henningsen]

zack@codesourcery.com (Zack Weinberg)  wrote on 15.03.04 in <87y8q1a9nc.fsf@egil.codesourcery.com>:

> In the abstract, I think that *if* the "C language runtime" part of a
> C library were disentangled from the "low-level operating system
> interface" part, the "useful but nonstandard utility routines" part,
> and the "shared object loader" part, then it would be good to have a
> close relationship between the language runtime project and the
> compiler project.  The other projects, however, ought to be prohibited
> from communicating with the language runtime and compiler teams except
> via standards committees.  (They don't have to be formal and
> ISO-recognized or anything; an IETFish process would be fine.)
>
> This, however, will never happen (disentanglement would require
> redesigning the entire C library and bits of the language), and so I
> am in favor of generally distant relations between compiler and
> library teams.

Well, maybe it won't happen with glibc. OTOH, glibc doesn't seem to get  
ported outside the Linux/Hurd universe anyway.

For the rest of the world, if someone wanted to create a "portable C  
library", this seems like the path to take. (Specifically, if you want to  
be able to cope with such diverse OSes as Unix, VMS, and Windows, then  
anything else seems insane.)

The interesting point is, in fact, defining useful interfaces between  
those parts.

(A few asides:

"useful but nonstandard utility routines"
        libg (in analogy to libg++)?
"shared object loader"
        libgcc+binutils+ld.so ... really, binutils belongs with gcc more
        than glibc does.
Do not forget "locale and charset system" - that's neither low-level OS
        interface, nor should it be part of "C language runtime" (because
        there are OS-specific implementations), nor is it really "useful
        but nonstandard utility routines". In fact, there may be more such
        stuff than this ... maybe "high-level OS interface".

)

MfG Kai

Re: GCC viciously beaten by ICC in trig test!

[Kai Henningsen]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 15.03.04 in <m3llm2ssp9.fsf@uniton.integrable-solutions.net>:

> "Stephan T. Lavavej" <stl@caltech.edu> writes:
>
> | [Scott Robert Ladd]
> | > Sometimes, I wonder if GCC should ship its own Standard C
> | > library, just as it ships a Standard C++ template library.
> | > However, I suspect the suggesting such a move might be a bit
> | > controversial... ;)
> |
> | Why doesn't it?
>
> This is a tricky issue. Some standards (e.g. POSIX) make conflicting
> requirements to that of ISO C standard,

Actually, POSIX takes great pains to *NOT* do that.

> and as a matter of fact
> demand that the C standard headers be modified.

Actually, POSIX says that any differences are dependant on prior  
definition of a preprocessor symbol in the implementation namespace. I  
believe this strategy was chosen with advice from the C standards  
committee.

>  If GCC/gcc had to
> come with its own C headers, then it would have to implement those
> standards too -- in order to comply with user expectations.
> That is a mess and GCC has better not drive into that.

Actually, it seems that would be vastly cleaner than the contortions  
libstdc++ goes through. (And it would many such contortions unnecessary,  
as libstdc++ could count on support from libc.)

The *real* problem is that available infrastructure between different OSes  
can differ just as much as different CPUs do, meaning you need a libc  
backend like you need the gcc backend. That is nontrivial.

MfG Kai

Re: GCC viciously beaten by ICC in trig test!

[Ian Lance Taylor]

kaih@khms.westfalen.de (Kai Henningsen) writes:

> > This is a tricky issue. Some standards (e.g. POSIX) make conflicting
> > requirements to that of ISO C standard,
> 
> Actually, POSIX takes great pains to *NOT* do that.

It is true, as you say, that POSIX requires that a symbol be defined
to make the header files non-ISO C.  But that doesn't really help from
the perspective of having gcc provide those header files.  If gcc
provides the ISO C standard header files, then it more or less follows
that the gcc version of those files will not contain the POSIX
definitions which are appropriate for the current host.  This would
require a lot of fixincludes/#include_next hackery to get right.

Ian

Re: GCC viciously beaten by ICC in trig test!

[Joe Buck]

On Sun, Mar 14, 2004 at 07:19:18PM -0800, Stephan T. Lavavej wrote:
> [Scott Robert Ladd]
> > Sometimes, I wonder if GCC should ship its own Standard C
> > library, just as it ships a Standard C++ template library.
> > However, I suspect the suggesting such a move might be a bit
> > controversial... ;)
> 
> Why doesn't it?

If glibc and gcc don't work and play well together, it is a bug.
glibc is supposed to be the GNU C library and GCC is supposed to be
the GNU compiler suite.

If glibc's inline assembly is worse code than GCC produces itself,
this is a glibc bug and should be reported as such.  Let's not assume
we get pushback from the glibc people until we actually do.

Re: GCC viciously beaten by ICC in trig test!

[Stephan T. Lavavej]

[Scott Robert Ladd]
> Sometimes, I wonder if GCC should ship its own Standard C
> library, just as it ships a Standard C++ template library.
> However, I suspect the suggesting such a move might be a bit
> controversial... ;)

[Stephan T. Lavavej]
> Why doesn't it?

[Gabriel Dos Reis]
> This is a tricky issue. Some standards (e.g. POSIX) make
> conflicting requirements to that of ISO C standard,

[Kai Henningsen]
> Actually, POSIX takes great pains to *NOT* do that.

[Gabriel Dos Reis]
> and as a matter of fact demand that the C standard headers be
> modified.

[Kai Henningsen]
> Actually, POSIX says that any differences are dependant on
> prior definition of a preprocessor symbol in the
> implementation namespace. I believe this strategy was chosen
> with advice from the C standards committee.

[Gabriel Dos Reis]
> If GCC/gcc had to come with its own C headers, then it would
> have to implement those standards too -- in order to comply
> with user expectations.
> That is a mess and GCC has better not drive into that.

[Kai Henningsen]
> Actually, it seems that would be vastly cleaner than the
> contortions libstdc++ goes through. (And it would many such
> contortions unnecessary, as libstdc++ could count on support
> from libc.)

Great!

> The *real* problem is that available infrastructure between
> different OSes can differ just as much as different CPUs do,
> meaning you need a libc backend like you need the gcc
> backend. That is nontrivial.

Well, of course there would have to be vastly different implementations for
Windows versus GNU/Linux versus whatever other horrible operating systems
gcc runs on.  But gcc already uses the "separate implementation for
everything" approach with different processors.

If gcc were unified with a C library, it seems like things would be a lot
simpler, not only for libstdc++ and the rest of the compiler, but for users
with lousy C libraries supplied by their vendors.

[Kai Henningsen]
> really, binutils belongs with gcc more than glibc does.

And why isn't binutils part of gcc, for that matter?

Stephan T. Lavavej
http://nuwen.net

Re: GCC viciously beaten by ICC in trig test!

[Ian Lance Taylor]

"Stephan T. Lavavej" <stl@caltech.edu> writes:

> [Kai Henningsen]
> > really, binutils belongs with gcc more than glibc does.
> 
> And why isn't binutils part of gcc, for that matter?

gcc works on a number of systems on which the GNU binutils do not
work.

If you leave out a few minor details, gcc is simply a translator of
text files from C/C++/whatever text to assembly text.

The binutils are a different matter, as they must interact closely
with binary formats which are, all too often, rather ill-defined.

That said, there would be some obvious speed advantages to including
the assembler in the compiler backend, to avoid the current
translation from RTL to text to object file format, and instead
translate directly from RTL to object file format.  It might be an
interesting project.  For somebody else.

Ian