Re: Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)

[Ben Gamari]

Phyx  writes:

[snip]


Hi Phyx,

Sorry for the late reply here; Jared did a good job of summarizing the
effort. I just want to make sure that we clearly put this particular
concern to rest:

> This would be unfortunate as it would mean we would effectively stop
> tracking performance on e.g. Windows and Mac OS since the current
> implementation doesn't allow for the data to live together in the same
> repo.
>
The implementation as it stands does indeed allow data from multiple
platforms to live side-by-side. Each measurement from a given testsuite
run carries with it a "test environment" which is meant to allow us to
distinguish between various operating system/architecture/hardware
configurations. This defaults to "local" but can be overridden on the
`make test` command line. The CI builders will do this to provide with
unique, descriptive names, giving us a running history of the test
characteristics on all of our CI platforms.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Overapproximation of loopbreakers due to unfoldings

[Simon Peyton Jones via ghc-devs]

INLINE means "Inline what I wrote".   So in your example we'd have

===>

bindWith [INLINE = ]
 = bindWith_abc |> co
bindWith_abc = 

If you see a call to bindWith, we will /not/ inline bindWith_abc |> co!  We'll 
inline .  That's what the programmer asked for.

That's why self-recursive INLINE things are loop breakers.

Does that help?

Now, it's true that /in the rhs of bindWith_abc/ it might be better to inline 
(bindWith_abc |> co) in place of bindWith, rather than inlining the .  But currently GHC can carry only one unfolding for an 
Id.  We could review that, but it'd make things more complicated.

I have not yet found time to dig into the mysteries of #14211.  Thank you for 
investigating so diligently.

Simon




| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew
| Pickering
| Sent: 15 September 2017 16:46
| To: GHC developers 
| Subject: Overapproximation of loopbreakers due to unfoldings
| 
| I have been puzzling over the example presented by Harendra in #14211 for
| the last two days.
| 
| Ultimately it led me to discover that if a self-recursive definition is
| marked with an INLINE pragma then it will always be marked as a
| loopbreaker.
| 
| This is undesirable in this case as the simplifier ends up with in the
| first pass..
| 
| bindWith = ... bindWith ...
| =>
| bindWith = bindWith_abc |> co
| bindWith_abc = ... bindWith ...
| 
| So we can then inline `bindWith` into the RHS of `bindWith_abc` and
| create a single self-recursive function rather than a mutually recursive
| block. Marking `bindWith` as `INLINE` means that both `bindWith` and
| `bindWith_abc` are marked as loopbreakers.
| 
| Mutual recursive blocks are bad as they completely stop the static
| argument transformation from working.
| 
| My question is, why is it necessary to mark "bindWith" as a loopbreaker
| in the current module? Are there any tickets or notes which discuss this
| problem?
| 
| Matt
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs=02%7C01%7Csimonpj%40microsoft.com%7C2a71eb929ce24b4dcefc08d4fc5
| 0f2db%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636410871981371365
| ta=RmtbOXJcB9bzKa%2FV95pICCIyTbTfzw1%2BooD52dI%2FzE0%3D=0
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A type checker plugin for row types

[Nicolas Frisby]

Hello Simon! Thanks for taking a look.

I've attempted to address your Core question by adding a new section to the
wiki page:
https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain#SomeLightCoreSnorkeling

Regarding the necessary EvTerms, I haven't thought through that enough to
answer. I'll add it to the wiki page.

Thanks. -Nick

On Fri, Sep 15, 2017 at 7:55 AM Simon Peyton Jones 
wrote:

> Nick
>
>
>
> Good work!
>
>
>
> You ask some questions about the constraint solver – I hope that the
> answer from others have helped. If not, do re-ask.
>
>
>
> My main comment is: what does Core look like?  I think your answer is “No
> change to Core, but there are lots of unsafe coerces littered around”.
> But even then I’m not sure.  Even
>
>
>
> f :: Lacks r “f” => V (Row (r .& (“f” .= Int))) -> V (Row (r .& (“f” .=
> Int)))
>
> f n x = ???
>
>
>
> Somehow in the ??? I have to update field n of a tuple x.  How do I do
> that?
>
>
>
> And I’m also very uncomfortable having Core littered with unsafeCoerces.
> I like Core being statically typed.  What is the simplest primitive(s) we
> could add to Core to make it possible to express this stuff type-safely?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Nicolas
> Frisby
> *Sent:* 10 September 2017 23:25
> *To:* ghc-devs@haskell.org
> *Cc:* Andres Löh ; Adam Gundry ;
> Richard Eisenberg 
> *Subject:* A type checker plugin for row types
>
>
>
> Hi all. I've been spending my free time for the last couple months on a
> type checker plugin for row types. The free time waxes and wanes; sending
> an email like this one was my primary goal for the past couple weeks.
>
>
>
> At the very least, I hoped this project would let me finally get some
> hands on experience with OutsideIn. And I definitely have. But I've also
> made more progress than I anticipated, and I think the plugin is starting
> to have legs!
>
>
>
> I haven't uploaded the code yet to github -- it's not quite ready to
> share. But I did do a write up on the dev wiki.
>
>
>
>
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain
>
>
>
> I would really appreciate and questions, comments, and --- boy, oh boy ---
> answers.
>
>
>
> I hope to upload within a week or so, and I'll update that wiki page and
> reply to this email when I do.
>
>
>
> Thanks very much. -Nick
>
>
>
> P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically
> interested in this (e.g. plugins, row types, etc). Please feel free to
> forward to others that come to mind; I know some inboxes abjectly can't
> afford default list traffic.
>
>
>
> P.P.S. -- One hold up for the upload is: which license? I intend to
> release under BSD3, mainly to match GHC since one ideal scenario would
> involve being packaged with/integrated into GHC. But my brief recent
> research suggests that the Apache license might be more conducive to
> eventual widespread adoption. If you'd be willing to advise or even just
> refer me to other write ups, please feel free to email me directly or to
> start a separate thread on a more appropriate distribution list (CC'ing me,
> please). Thanks again.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Overapproximation of loopbreakers due to unfoldings

[Matthew Pickering]

I have been puzzling over the example presented by Harendra in #14211
for the last two days.

Ultimately it led me to discover that if a self-recursive definition
is marked with an INLINE pragma then it will always be marked as a
loopbreaker.

This is undesirable in this case as the simplifier ends up with in the
first pass..

bindWith = ... bindWith ...
=>
bindWith = bindWith_abc |> co
bindWith_abc = ... bindWith ...

So we can then inline `bindWith` into the RHS of `bindWith_abc` and
create a single self-recursive function rather than a mutually
recursive block. Marking `bindWith` as `INLINE` means that both
`bindWith` and `bindWith_abc` are marked as loopbreakers.

Mutual recursive blocks are bad as they completely stop the static
argument transformation from working.

My question is, why is it necessary to mark "bindWith" as a
loopbreaker in the current module? Are there any tickets or notes
which discuss this problem?

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: A type checker plugin for row types

[Simon Peyton Jones via ghc-devs]

Nick

Good work!

You ask some questions about the constraint solver – I hope that the answer 
from others have helped. If not, do re-ask.

My main comment is: what does Core look like?  I think your answer is “No 
change to Core, but there are lots of unsafe coerces littered around”.   But 
even then I’m not sure.  Even

f :: Lacks r “f” => V (Row (r .& (“f” .= Int))) -> V (Row (r .& (“f” .= Int)))
f n x = ???

Somehow in the ??? I have to update field n of a tuple x.  How do I do that?

And I’m also very uncomfortable having Core littered with unsafeCoerces.   I 
like Core being statically typed.  What is the simplest primitive(s) we could 
add to Core to make it possible to express this stuff type-safely?

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Nicolas Frisby
Sent: 10 September 2017 23:25
To: ghc-devs@haskell.org
Cc: Andres Löh ; Adam Gundry ; 
Richard Eisenberg 
Subject: A type checker plugin for row types

Hi all. I've been spending my free time for the last couple months on a type 
checker plugin for row types. The free time waxes and wanes; sending an email 
like this one was my primary goal for the past couple weeks.

At the very least, I hoped this project would let me finally get some hands on 
experience with OutsideIn. And I definitely have. But I've also made more 
progress than I anticipated, and I think the plugin is starting to have legs!

I haven't uploaded the code yet to github -- it's not quite ready to share. But 
I did do a write up on the dev wiki.

  https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain

I would really appreciate and questions, comments, and --- boy, oh boy --- 
answers.

I hope to upload within a week or so, and I'll update that wiki page and reply 
to this email when I do.

Thanks very much. -Nick

P.S. -- I've CC'd and BCC'd people who I anticipate would be specifically 
interested in this (e.g. plugins, row types, etc). Please feel free to forward 
to others that come to mind; I know some inboxes abjectly can't afford default 
list traffic.

P.P.S. -- One hold up for the upload is: which license? I intend to release 
under BSD3, mainly to match GHC since one ideal scenario would involve being 
packaged with/integrated into GHC. But my brief recent research suggests that 
the Apache license might be more conducive to eventual widespread adoption. If 
you'd be willing to advise or even just refer me to other write ups, please 
feel free to email me directly or to start a separate thread on a more 
appropriate distribution list (CC'ing me, please). Thanks again.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs