Dear Developers,
yesterday, there were three commits showing up at
https://perf.haskell.org/ghc/:
https://perf.haskell.org/ghc/#revision/60297486fddd5c9695e2263c2ae46fa9
0f0feb9e
60297486fddd5c9695e2263c2ae46fa90f0feb9e
Author: Ben Gamari bgamari.f...@gmail.com
Drop custom mapM impl for []
: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 17 December 2014 15:56
| To: Simon Peyton Jones
| Cc: Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| By unsubstantiated guess is that INLINEABLE would have the same effect
| as INLINE here, as GHC
] On Behalf Of
| Richard Eisenberg
| Sent: 16 December 2014 21:46
| To: Joachim Breitner
| Cc: ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| I've learned several very interesting things in this analysis.
|
| - Inlining polymorphic methods is very important. Here are some
of calls?
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Richard Eisenberg
| Sent: 16 December 2014 21:46
| To: Joachim Breitner
| Cc: ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| I've learned several very
@haskell.org
| Subject: Re: performance regressions
|
| By unsubstantiated guess is that INLINEABLE would have the same effect
| as INLINE here, as GHC doesn't see fit to actually inline the
| function, even with INLINE -- the big improvement seen between (1) and
| (2) is actually specialization
weird.
Eg way to reproduce.
Simion
| -Original Message-
| From: Richard Eisenberg [mailto:e...@cis.upenn.edu]
| Sent: 17 December 2014 15:56
| To: Simon Peyton Jones
| Cc: Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| By unsubstantiated
On 2014-12-16 at 22:45:36 +0100, Richard Eisenberg wrote:
I've learned several very interesting things in this analysis.
- Inlining polymorphic methods is very important.
otoh, there are cases where marking methods INLINE have catastrophic
effects; the following
Using this combinator instead of writing the algorithm directly cost me 30%
allocation overhead!
What does your algorithm look like when you write it directly? Something like
this:
flatten_many fmode roles tys
= unzip `liftM` mapM go (zip roles tys)
where
go (Nominal,ty) =
Hi,
Am Montag, den 15.12.2014, 23:48 -0500 schrieb Richard Eisenberg:
Can anyone tell me: why? Have I made some horrible mistake in the
implementation?
And, relatedly: how can I fix this? I want to learn from this experience how
to avoid this problem next time...
another guess (without
. Should there be so many?
S
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Richard Eisenberg
| Sent: 16 December 2014 04:49
| To: Ben Gamari
| Cc: Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: performance regressions
|
| I've made
I've learned several very interesting things in this analysis.
- Inlining polymorphic methods is very important. Here are some data points to
back up that claim:
* Original implementation using zipWithAndUnzipM:8,472,613,440 bytes
allocated in the heap
* Adding {-# INLINE #-} to the
Would specialize pragmas also have these performance improvements, or is
inline needed?
On Tue, Dec 16, 2014 at 4:45 PM, Richard Eisenberg e...@cis.upenn.edu
wrote:
I've learned several very interesting things in this analysis.
- Inlining polymorphic methods is very important. Here are some
Hi,
Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg:
Of course, I now see that it wasn't a full fix.
This is all most assuredly my fault.
I wouldn’t call it a fault. Where wood is chopped, splinters must fall.
(Hopefully correct translation of a German idiom.)
We don’t
Joachim Breitner m...@joachim-breitner.de writes:
Hi,
Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg:
snip
- Travis has not picked up on these errors.
unfortunately, travis is slighly less useful since a few weeks due to
T5681 failing (possibly due to the use of
Joachim Breitner nome...@debian.org writes:
Hi,
Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
- Travis has not picked up on these errors.
unfortunately, travis is slighly less useful since a few weeks due to
T5681 failing (possibly due to the use of LLVM-3.4), but I’m
I've made progress, but still need some help.
It turns out that a monadic combinator (that I wrote) is mostly responsible:
zipWithAndUnzipM :: Monad m
= (a - b - m (c, d)) - [a] - [b] - m ([c], [d])
zipWithAndUnzipM f (x:xs) (y:ys)
= do { (c, d) - f x y
; (cs, ds)
Hello Richard,
Can you please push the fix asap to master? This performance failures
are causing distracting false alarms (in terms of validation failures)
on each pushed commit as well as submitted code-revisions.
Thanks,
HVR
On 2014-12-13 at 16:55:40 +0100, Richard Eisenberg wrote:
Hi,
Am Samstag, den 13.12.2014, 10:55 -0500 schrieb Richard Eisenberg:
Fixed, hopefully!
Mitigated, but still a regression:
http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2base=2%2B68ben=tests%2Falloc%2FT9872aenv=1revs=50equid=on#
Is that now a level that we’ll have to live with, or is it
I pushed my supposed fix yesterday morning, as I emailed out the Fixed,
hopefully note.
Of course, I now see that it wasn't a full fix.
This is all most assuredly my fault. However, I also feel that elements of the
infrastructure failed me somewhat, making this error easier for me to commit:
-
Hi,
Am Freitag, den 12.12.2014, 21:51 -0500 schrieb Richard Eisenberg:
Phab has shown up some performance regressions in my recent commits.
See https://phabricator.haskell.org/harbormaster/build/2607/. The
failures except for haddock.base are new, and evidently my fault. They
didn't show
, 21:51 -0500 schrieb Richard Eisenberg:
Phab has shown up some performance regressions in my recent commits.
See https://phabricator.haskell.org/harbormaster/build/2607/. The
failures except for haddock.base are new, and evidently my fault. They
didn't show up on Travis. Will look
, 2014, at 8:32 AM, Joachim Breitner m...@joachim-breitner.de
wrote:
Hi,
Am Freitag, den 12.12.2014, 21:51 -0500 schrieb Richard Eisenberg:
Phab has shown up some performance regressions in my recent commits.
See https://phabricator.haskell.org/harbormaster/build/2607/. The
failures
Hi devs,
Phab has shown up some performance regressions in my recent commits. See
https://phabricator.haskell.org/harbormaster/build/2607/. The failures except
for haddock.base are new, and evidently my fault. They didn't show up on
Travis. Will look into it shortly, but I doubt over
23 matches
Mail list logo
