gmane.comp.lang.haskell.glasgow.user

Don Stewart | 15 May 20:46

-optc-O2 considered useful


I discovered something today I didn't know.
gcc -O2 can optimise out the computed jumps GHC produces in tight loops.

Consider this program,

    import Data.Array.Vector
    import Data.Bits

    main = print . sumU
                 . mapU (*2)
                 . mapU (`shiftL` 2)
                 $ replicateU (100000000 :: Int) (5::Int)

Yields this core:

    $wfold :: Int# -> Int# -> Int#

    $wfold =
      \ (ww_sMp :: Int#) (ww1_sMt :: Int#) ->
        case ww1_sMt of wild_X10 {
          __DEFAULT -> $wfold (+# ww_sMp 40) (+# wild_X10 1);
          100000000 -> ww_sMp

And -O2 -fasm:

    Main_zdwfold_info:
      movq %rdi,%rax
      cmpq $100000000,%rax
      jne .LcOk

(Continue reading)

headers

Bulat Ziganshin | 15 May 21:00

Re: -optc-O2 considered useful

Hello Don,

Thursday, May 15, 2008, 10:47:20 PM, you wrote:

> I discovered something today I didn't know.
> gcc -O2 can optimise out the computed jumps GHC produces in tight loops.

seems that decision to use native backend in ghc -O2 was too early?

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com

headers

Duncan Coutts | 16 May 00:31

Re: -optc-O2 considered useful


On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote:
> Hello Don,
> 
> Thursday, May 15, 2008, 10:47:20 PM, you wrote:
> 
> > I discovered something today I didn't know.
> > gcc -O2 can optimise out the computed jumps GHC produces in tight loops.
> 
> seems that decision to use native backend in ghc -O2 was too early?

Though note that the native backend never introduced the computed jump.

I think it's clear that -fvia-C -O should imply -optc-O2 if it does not
already. gcc -O0 is for painfully obvious C translation into assembler,
-O is for quick optimisations. gcc -O2 is the "standard" optimisation
level used for building packages for most distros.

Duncan

headers

Don Stewart | 16 May 00:37

Re: -optc-O2 considered useful

duncan.coutts:
> 
> On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote:
> > Hello Don,
> > 
> > Thursday, May 15, 2008, 10:47:20 PM, you wrote:
> > 
> > > I discovered something today I didn't know.
> > > gcc -O2 can optimise out the computed jumps GHC produces in tight loops.
> > 
> > seems that decision to use native backend in ghc -O2 was too early?
> 
> Though note that the native backend never introduced the computed jump.
> 
> I think it's clear that -fvia-C -O should imply -optc-O2 if it does not
> already. gcc -O0 is for painfully obvious C translation into assembler,
> -O is for quick optimisations. gcc -O2 is the "standard" optimisation
> level used for building packages for most distros.

Another idea:

    should -fstrictness be on by default?

I run into too many users writing little tail recursive Int loops, and
not using optimisations, with the impression that compiling, e.g.

    ghc A.hs

should just work.

(Continue reading)

headers

Simon Marlow | 16 May 11:38

Re: -optc-O2 considered useful

Don Stewart wrote:
> duncan.coutts:
>> On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote:
>>> Hello Don,
>>>
>>> Thursday, May 15, 2008, 10:47:20 PM, you wrote:
>>>
>>>> I discovered something today I didn't know.
>>>> gcc -O2 can optimise out the computed jumps GHC produces in tight loops.
>>> seems that decision to use native backend in ghc -O2 was too early?
>> Though note that the native backend never introduced the computed jump.
>>
>> I think it's clear that -fvia-C -O should imply -optc-O2 if it does not
>> already. gcc -O0 is for painfully obvious C translation into assembler,
>> -O is for quick optimisations. gcc -O2 is the "standard" optimisation
>> level used for building packages for most distros.
> 
> Another idea:
> 
>     should -fstrictness be on by default?
>     
> I run into too many users writing little tail recursive Int loops, and
> not using optimisations, with the impression that compiling, e.g.
> 
>     ghc A.hs
> 
> should just work.

This is part of a larger question, namely whether we can get substantial 
benefit for doing a tiny bit of extra work in -O0.  With -O0 we're

(Continue reading)

headers

Neil Mitchell | 16 May 14:00

Re: -optc-O2 considered useful

Hi

> As for the specific issue of whether we should turn on -fstrictness with
> -O0, I suspect the answer is that the compile-time cost would be too high.

There would also be the issue that it would increase the amount of
Haskell code which works only in GHC, which is probably a bad thing.
Would the strictness still recover the loop if they turned on
hpc/profiling? I can see many reasons why making things faster is
good, but making things asymptotically faster/less space in -O0 could
bite later.

One ticket that probably makes a big difference in -O0 is:
http://hackage.haskell.org/trac/ghc/ticket/2207

Thanks

Neil

headers

Isaac Dupree | 17 May 02:17

Re: -optc-O2 considered useful

Simon Marlow wrote:
> This is part of a larger question, namely whether we can get substantial 
> benefit for doing a tiny bit of extra work in -O0.  With -O0 we're 
> optimising for compile time in preference to code speed, although we do 
> want to find a good compromise that doesn't generate abysmal code.

there's the other use of -O0, namely, debugging the compiler -- but 
then, debugging the optimizations probably requires pretty specific 
knowledge of what you're looking for, anyway, and testing on multiple 
platforms usually finds out whether a problem is with a port or with the 
compilation process.

oh, and also that profiling/debugging optimized code can be confusing, 
so it might be good to avoid optimizations that have too much of that effect

-Isaac

headers

Bernd Brassel | 20 May 11:29

Re: -optc-O2 considered useful

I think it would be nice to have some speedy optimizations turned on by
default in ghc. Might even be good to win new users.

But I also think that much hacking for and around ghc+tool support needs
a way to achieve what -O0 does today.

So, how about an -O(-1) or flag?