Re: Annotation for unfolding wanted

Hi,

I am sorry for using the wrong terminology here. Let me ask again:
Does it sound reasonable to extend the compiler with a pragma that specifies 
that a certain function should be compiled to a loop? And if the compiler can 
not do it, it helps with some error message. 

Regards!
	Georg

On Tuesday 31 July 2007 16:20, Simon Peyton-Jones wrote:
> | However my point was more on a semantic point of view: If I write a
> | function in a recursive way, but actually do nothing else than a loop, I
> | would like a) that the compiler unrolls it to a loop and
> | b) that I can specify such a requirement, while violating it emits an
> | error.
>
> What does it mean to say "the compiler unrolls it to a loop".  If GHC sees
> a tail recursive function, it certainly compiles it to a loop!  (But that's
> not called "unrolling".)
>
> Simon

--

-- 
---- Georg Martius,  Tel: +49 177 6413311  -----
------- http://www.flexman.homeip.net ----------

_______________________________________________
Glasgow-haskell-users mailing list

Re: Annotation for unfolding wanted

On Wed, Aug 01, 2007 at 09:42:54AM +0200, Georg Martius wrote:
> Hi,
> 
> I am sorry for using the wrong terminology here. Let me ask again:
> Does it sound reasonable to extend the compiler with a pragma that specifies 
> that a certain function should be compiled to a loop? And if the compiler can 
> not do it, it helps with some error message. 

Unfortunately, that's still almost useless in the presence of laziness.
Take the following (contrived) example:

fib :: Int -> (Int,Int) -> (Int,Int)
fib 0 p = p
fib k p = fib (k-1) (snd p, fst p + snd p)

That compiles to a perfectly reasonable loop:  (minor code rearrangement
and bounds-checks deleted for clarity)

   X_zdszdwfib_info:
        Hp = Hp + 16;
        _sjD = I32[Sp + 8];
        if (_sjD == 0) goto clk;
        _sjF = _sjD - 1;
        I32[Hp - 12] = sjC_info;
        I32[Hp - 4] = I32[Sp + 4];
        I32[Hp] = I32[Sp];
        I32[Sp + 8] = _sjF;
        I32[Sp + 4] = I32[Sp];
        I32[Sp] = Hp - 12;
        jump X_zdszdwfib_info ();

RE: Annotation for unfolding wanted

If it's tail recursive it'll be compiled to a loop.  You don't need a pragma.

Of course if it does evaluation along the way, it'll have to make a call do to that evaluation.  E.g.
        f x = if x>0 then 0 else f (g x)
Here f is tail-rec but it'll have to call g inside the loop.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org
[mailto:glasgow-haskell-users-bounces <at> haskell.org] On
| Behalf Of Georg Martius
| Sent: 01 August 2007 08:43
| To: Simon Peyton-Jones; Glasgow-haskell-users <at> haskell.org
| Subject: Re: Annotation for unfolding wanted
|
| Hi,
|
| I am sorry for using the wrong terminology here. Let me ask again:
| Does it sound reasonable to extend the compiler with a pragma that specifies
| that a certain function should be compiled to a loop? And if the compiler can
| not do it, it helps with some error message.
|
| Regards!
|         Georg
|
| On Tuesday 31 July 2007 16:20, Simon Peyton-Jones wrote:
| > | However my point was more on a semantic point of view: If I write a
| > | function in a recursive way, but actually do nothing else than a loop, I
| > | would like a) that the compiler unrolls it to a loop and

Re: Annotation for unfolding wanted

>Some compilers unroll recursive functions by inlining them N times, for some fixed N (say 3 or so). 
>This reduces the loop overheads.  GHC doesn't do this, although it'd be nice, because it makes 
>repeated traversals of the code, and it's hard to spot when the function has been unrolled 3 times 
>and then stop.  If you look at the code after unrolling 3 times, from scratch, there's another call 
>just waiting to be inlined.

couldn't the number of unfoldings be encoded in the name of the function?

    f x = if p x then x else f (g x)

    f x = if p x then x else let x' = (g x) in if p x' then x' else f#1 (g x')

where f#1 would be f for all other purposes, but with one unfolding used up,
and N being the bound for the f#i.

claus

Re: Ticky Ticky profiling

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Ticky Ticky profiling

On Thu, Aug 02, 2007 at 10:59:12AM +0200, Cristian Perfumo wrote:
> By the way... does ticky-ticky allow monitoring multithreaded programs?
> I ask this because the other way of learning data about the execution
> (compiling with -prof) is not compatible with -threaded options. In other
> words, you can't compile a Haskell program with -prof and -threaded options
> at the same time.

You don't need -threaded to run multithreaded programs.

-threaded will make them run *faster* on >1-core machines, but the
normal RTS will run multiple Haskell threads just fine on its single
OS-thread.

Stefan

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Ticky Ticky profiling

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-pkg bash completion

Hi all!

I wrote a bash completion to ghc-pkg last year, just cleaned it up a bit
and thought I should share it with you guys.

You get your copy by typing:

; darcs get http://haskell.org/~kolmodin/code/ghc-bash-completion/

Then, to load it (quick'n'dirty without proper install):

; cd ghc-bash-completion
; source ./ghc-pkg
; source ./ghci

A session could look like:

; ghc-pkg <tab><tab>  # hit the tab key twice.
                      # it gives your valid options
--auto-ghci-libs  --package-conf=   -V                hide
--define-name=    --simple-output   -f                latest
--force           --user            -g                list
--global          --version         describe          register
--global-conf=    -?                expose            unregister
--help            -D                field             update

; ghc-pkg hide <tab><tab> # gives you a list of
                          # packages and optional flags

The ghci support is very minimalistic at this point... it only completes
on packages.

That's it!

Cheers,
  Lennart

Re: Ticky Ticky profiling

On 8/2/07, Cristian Perfumo <cperfumo <at> gmail.com> wrote:
> Sorry, It looks like I haven't been precise with my question: I wanted to
> say multiple hardware (it implies OS) threads.
> In other words: are -threaded and ticky ticky compatible? Will I be able to
> run "./myProgram +RTS -N4 - rmyout.ticky" ?

I haven't tried it, but the best way to find out is to try it and see
 If you run into problems, yell.

Cheers,
Tim

--

-- 
Tim Chevalier * chevalier <at> alum.wellesley.edu * Often in error, never in doubt

Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?)

I'm forwarding this to ghc-users since nobody answered on
haskell-cafe, and I'm still curious... (The original message is at
http://www.nabble.com/Lazy-in-either-argument--t4133855.html)

---------- Forwarded message ----------
From: Tim Chevalier <catamorphism <at> gmail.com>
Date: Jul 26, 2007 4:52 PM
Subject: Re: [Haskell-cafe] Lazy in either argument?
To: Lennart Augustsson <lennart <at> augustsson.net>
Cc: Dan Weston <westondan <at> imageworks.com>, haskell-cafe
<haskell-cafe <at> haskell.org>

On 7/26/07, Lennart Augustsson <lennart <at> augustsson.net> wrote:
> The non-termination is (probably) due to the fact that you can have uninterruptible threads in ghc.
> If a thread never allocates it will never be preempted. :(
>

To elaborate on that, the different behavior between the two versions
of Dan's code, one with and one without a type signature, happens
because f compiles like so if the type signature isn't given (this is
the STG code):

f_ri5 = \u [] let-no-escape { f1_sPY = NO_CCS[] \u [] f1_sPY; } in  f1_sPY;
SRT(f_ri5): []

and like so if the type signature is given:

f_ri5 = \u srt:(0,*bitmap*) [] f_ri5;
SRT(f_ri5): [f_ri5]

If you look at the resulting asm code, the second version of f_ri5
compiles to a loop that allocates on each iteration, whereas the body
of the let in the first version of f_ri5 compiles to just:
sPY_info:
        jmp sPY_info

(Adding f to the export list so that its SRT is empty doesn't change
anything, btw.)

This is all with -Onot.

So I find this a little confusing. Why is f = let f_1 = f_1 in f_1
compiled so differently from f = f? It seems like f = f should also
compile to a loop that doesn't allocate anything. And from the user's
perspective, it seems somewhat strange that adding or removing a type
signature changes the semantics of their code (although I guess you
could make the argument that if you're dealing with threads and
nonterminating code, all bets are off.) Can someone better acquainted
with the code generator than me explain the rationale behind this?

Cheers,
Tim

--
Tim Chevalier* catamorphism.org *Often in error, never in doubt
"Religion is just a fancy word for the Stockholm Syndrome."  -- lj
user="pure_agnostic"