September 2016 - ghc-devs

Re: Add a signaling Nans rts option to ghc?
by Carter Schonwald 16 Sep '16

16 Sep '16

IEEE standard specify infinities as distinguished from NAN. Not that the IEEE standard always makes the best choices (semantics of min and max being the naughtiest ). But to the extent that hardware supoorts toggling what values trigger failure it should be reasonably toggle -able For Intel hardware I'll presume only hardware that has sse2 and newer, and maybe a warm-up or sibling patch would be to excise x87 float support from the code gen in GHC Amusingly one intended use for the large space of nan values was to encode the nature of the computation that created the nan. And this was intended to be used by language implementors. Not sure if that will be useful. Anyways, this and the other positive response is encouraging and I'll see about making the time to dig into this stuff. Merry friday all! -Carter On Sep 16, 2016 11:40 AM, "Ben Gamari" <ben(a)smart-cactus.org> wrote: Carter Schonwald <carter.schonwald(a)gmail.com> writes: > Hello All! > I had some interesting conversations yesterday with a few folks and the > take away was that I might experiment with adding an off by default rts > flag that on applicable architectures that makes all floating point > computations that yield Nans signaling , plus mayve some HS side hooks to > enable or disable that per green thread if it doesn't harm no fib. Kinda > like the way green threads track and save / restore the state of the magic > c error tracking variable > Sounds reasonable to me; debugging floating point issues is certainly a chore and this could only help. Regarding a per-thread handling I think we'd certainly need to benchmark. Note that rts/posix/Signals.c already has some logic to handle SIGFPE, although it has been disabled for over a decade due to an infinite loop where the handler immediately threw another FPE. It would be nice to have a solution to this issue; looping is quite bad. Do you lump infinities into the class of NaN values? I'm not sure how much code would fail due to "legitimate" uses of infinity if so. Cheers, - Ben

1 0

-fno-warn lines in the lexer can be removed with Alex 3.1.5
by Ömer Sinan Ağacan 16 Sep '16

16 Sep '16

I was working on the lexer today and realized that we can now remove -fno-warn lines in the lexer if we're OK with requiring Alex >=3.1.5.

2 1

Add a signaling Nans rts option to ghc?
by Carter Schonwald 16 Sep '16

16 Sep '16

Hello All! I had some interesting conversations yesterday with a few folks and the take away was that I might experiment with adding an off by default rts flag that on applicable architectures that makes all floating point computations that yield Nans signaling , plus mayve some HS side hooks to enable or disable that per green thread if it doesn't harm no fib. Kinda like the way green threads track and save / restore the state of the magic c error tracking variable Would this be something folks would be open to adding once I hack it out? Most modern CPUs have some built in support for this, but having better rts integration might make things way nicer. Plus part of the point of the sheer diversity of Nans as per the IEEE report is to encode the nature of the source of the nan error. (There are other parts of IEEE that I think should be ignored / we should change the behavior in a way that disagrees with IEEE choices that hinder debugging and such )

3 2

Better perf?
by Simon Peyton Jones 13 Sep '16

13 Sep '16

I’m getting this perf improvement from T5837, which is type-function heavy. Is anyone else seeing this bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5837(normal) bytes allocated: 48507272 +/-10% Lower bound T5837(normal) bytes allocated: 43656544 Upper bound T5837(normal) bytes allocated: 53358000 Actual T5837(normal) bytes allocated: 42384144 Deviation T5837(normal) bytes allocated: -12.6 % Its good, but I’d quite like to know which patch made the difference. Could it be commit 03541cbae50f0d1cdf99120ab88698f29a278159 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Sep 9 17:42:42 2016 +0100 Be less picky about reporing inaccessible code Seems implausible, but possible I suppose. Simon

2 2

Re: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by George Colpitts 12 Sep '16

12 Sep '16

Thanks Ben, np. On Mon, Sep 12, 2016 at 11:33 AM GHC <ghc-devs(a)haskell.org> wrote: > #8763: forM_ [1..N] does not get fused (10 times slower than go function) > -------------------------------------+------------------------------------- > Reporter: nh2 | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 8.2.1 > Component: Compiler | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Runtime | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 8.0.2 => 8.2.1 > > > Comment: > > I'm afraid 8.0.2 is out of the question. However, 8.2.1 is a possibility. > Of course, any help that you, the reader, can offer would expedite the > process. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763#comment:25> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RE: vectorisation code?
by Simon Peyton Jones 12 Sep '16

12 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

Re: -fno-warn lines in the lexer can be removed with Alex 3.1.5
by Ryan Scott 11 Sep '16

11 Sep '16

That sounds like a reasonable suggestion to me. I'm not aware of any support window for we have for alex/happy, but since alex-3.1.5 is already about one year old, I can't imagine requiring it as a minimum would cause any problems. Ryan S.

1 0

Feature request bounty
by David Feuer 08 Sep '16

08 Sep '16

I'd like to place a small bounty on https://ghc.haskell.org/trac/ghc/wiki/NewtypeOptimizationForGADTS . If someone implements this request by GHC 8.2, I will buy them 24 bottles of high-end root beer (e.g., Maine Root) or something of similar value agreeable to both parties. (*) Thanks, David Feuer (*) Recipient responsible for customs/duty/taxes/shipping fees beyond US$10.

4 6

Thoughts on CallStack and withFrozenCallStack
by Edward Z. Yang 08 Sep '16

08 Sep '16

I've been adding CallStack to Cabal's source code, and I noticed a common pattern that doesn't seem to be supported by the GHC.Stack API. Imagine I'm writing a general purpose logging function: debug :: Verbosity -> String -> IO () I'd like this function to print out the SrcLoc of the person who called; as an additional requirement, I only want to print the top-most stack frame by default (someone can ask for the full stack if they really want to). If I look at callStack, it is going to contain a stack frame for debug itself. That's not so great; the obvious way to fix this is to pop off the irrelevant frame manually. But now suppose that I have a pprDebug which itself calls debug. I don't want pprDebug to show up in the stack frame! Declaratively, I want to say, "Please don't add me to the call stack", at the function *definition*, not the call-site (which is what withFrozenCallStack) gives me. Does this seem like a reasonable request? I have several other ways to do this: - You could just use withFrozenCallStack at the definition site. Then when pprDebug calls debug, debug will get the call stack that pprDebug had; thus, there will always only be one irrelevant frame to pop off. - One problem with using withFrozenCallStack is that you *do* lose useful trace information, which you kind of might actually want if you are being verbose. So it almost seems like, the frozen API should still *push* frames, but just not make them visible by default. - Something that does NOT work is having functions edit the call stack to remove themselves. There's no way to tell if the stack is frozen or not, and thus no way to tell if you are actually on the stack (and need to remove it.) Thanks, Edward

2 2

Restartable sequences
by Ben Gamari 07 Sep '16

07 Sep '16

While I'll admit that I'm not terribly familiar with our STM implementation, it came to mind while I was reading this article [1] on the restartable sequences mechanism that might someday land in the Linux kernel. I thought you both might be interested. Cheers, - Ben [1] http://lwn.net/Articles/697979/

1 0