- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Monad transformer performance - Request to review benchmarking code + results
by Saurabh Nanda 07 Feb '17

07 Feb '17

Thanks for digging deeper, David. What exactly did you inline? Also, am I the only one losing my mind over this? It's such a straightforward use of available code structuring tools in Haskell. How come the compiler is not being smart about this OOB? -- Saurabh. On 29 Jan 2017 9:42 pm, "David Turner" <dct25-561bs(a)mythic-beasts.com> wrote: Here's the profiling summary that I got: COST CENTRE MODULE %time %alloc getOverhead Criterion.Monad 41.3 0.0 >>= Lucid.Base 19.2 41.6 makeElement.\.\ Lucid.Base 11.4 23.4 fromHtmlEscapedString Blaze.ByteString.Builder.Html.Utf8 7.9 14.9 >>= Data.Vector.Fusion.Util 2.3 1.7 return Lucid.Base 1.4 2.1 runBenchmark.loop Criterion.Measurement 1.2 0.0 with.\ Lucid.Base 1.0 2.1 foldlMapWithKey Lucid.Base 0.5 2.6 streamDecodeUtf8With.decodeChunk Data.Text.Encoding 0.0 1.7 As expected, HtmlT's bind is the expensive bit. However I've been unable to encourage it to go away using INLINE pragmas. On 29 January 2017 at 15:45, Oliver Charles <ollie(a)ocharles.org.uk> wrote: > I would start by inlining operations in the Functor, Applicative and Monad > classes for your monad and all the layers in the stack (such as HtmlT). An > un-inlining monadic bind can end up allocating a lot (as it's such a common > operation) > > On Sun, 29 Jan 2017, 3:32 pm Saurabh Nanda, <saurabhnanda(a)gmail.com> > wrote: > >> Please tell me what to INLINE. I'll update the benchmarks. >> >> Also, shouldn't this be treated as a GHC bug then? Using monad >> transformers as intended should not result in a severe performance penalty! >> Either monad transformers themselves are a problem or GHC is not doing the >> right thing. >> >> -- Saurabh. >> >> On 29 Jan 2017 7:50 pm, "Oliver Charles" <ollie(a)ocharles.org.uk> wrote: >> >> I would wager a guess that this can be solved with INLINE pragmas. We >> recently added INLINE to just about everything in transformers and got a >> significant speed up. >> >> On Sun, 29 Jan 2017, 11:18 am David Turner, < >> dct25-561bs(a)mythic-beasts.com> wrote: >> >> I would guess that the issue lies within HtmlT, which looks vaguely >> similar to a WriterT transformer but without much in the way of >> optimisation (e.g. INLINE pragmas). But that's just a guess after about 30 >> sec of glancing at https://hackage.haskell.org >> /package/lucid-2.9.7/docs/src/Lucid-Base.html so don't take it as gospel. >> >> My machine is apparently an i7-4770 of a similar vintage to yours, >> running Ubuntu in a VirtualBox VM hosted on Windows. 4GB of RAM in the VM, >> 16 in the host FWIW. >> >> >> On 29 Jan 2017 10:26, "Saurabh Nanda" <saurabhnanda(a)gmail.com> wrote: >> >> Thank you for the PR. Does your research suggest something is wrong with >> HtmlT when combined with any MonadIO, not necessarily ActionT? Is this an >> mtl issue or a lucid issue in that case? >> >> Curiously, what's your machine config? I'm on a late 2011 macbook pro >> with 10G ram and some old i5. >> >> -- Saurabh. >> >> On 29 Jan 2017 3:05 pm, "David Turner" <dct25-561bs(a)mythic-beasts.com> >> wrote: >> >> The methodology does look reasonable, although I think you should wait >> for all the scotty threads to start before starting the benchmarks, as I >> see this interleaved output: >> >> Setting phasers to stun... (port 3002) (ctrl-c to quit) >> Setting phasers to stun... (port 3003) (ctrl-c to quit) >> Setting phasers to stun... (port 3001) (ctrl-c to quit) >> benchmarking bareScotty >> Setting phasers to stun... (port 3000) (ctrl-c to quit) >> >> Your numbers are wayyy slower than the ones I see on my dev machine: >> >> benchmarking bareScotty >> Setting phasers to stun... (port 3000) (ctrl-c to quit) >> time 10.94 ms (10.36 ms .. 11.52 ms) >> 0.979 R² (0.961 R² .. 0.989 R²) >> mean 12.53 ms (11.98 ms .. 13.28 ms) >> std dev 1.702 ms (1.187 ms .. 2.589 ms) >> variance introduced by outliers: 66% (severely inflated) >> >> benchmarking bareScottyBareLucid >> time 12.95 ms (12.28 ms .. 13.95 ms) >> 0.972 R² (0.951 R² .. 0.989 R²) >> mean 12.20 ms (11.75 ms .. 12.69 ms) >> std dev 1.236 ms (991.3 μs .. 1.601 ms) >> variance introduced by outliers: 50% (severely inflated) >> >> benchmarking transScottyBareLucid >> time 12.05 ms (11.70 ms .. 12.39 ms) >> 0.992 R² (0.982 R² .. 0.996 R²) >> mean 12.43 ms (12.06 ms .. 13.01 ms) >> std dev 1.320 ms (880.5 μs .. 2.071 ms) >> variance introduced by outliers: 54% (severely inflated) >> >> benchmarking transScottyTransLucid >> time 39.73 ms (32.16 ms .. 49.45 ms) >> 0.668 R² (0.303 R² .. 0.969 R²) >> mean 42.59 ms (36.69 ms .. 54.38 ms) >> std dev 16.52 ms (8.456 ms .. 25.96 ms) >> variance introduced by outliers: 92% (severely inflated) >> >> benchmarking bareScotty >> time 11.46 ms (10.89 ms .. 12.07 ms) >> 0.986 R² (0.975 R² .. 0.994 R²) >> mean 11.73 ms (11.45 ms .. 12.07 ms) >> std dev 800.6 μs (636.8 μs .. 975.3 μs) >> variance introduced by outliers: 34% (moderately inflated) >> >> but nonetheless I do also see the one using renderTextT to be >> substantially slower than the one without. >> >> I've sent you a PR [1] that isolates Lucid from Scotty and shows that >> renderTextT is twice as slow over IO than it is over Identity, and it's >> ~10% slower over Reader too: >> >> benchmarking renderText >> time 5.529 ms (5.328 ms .. 5.709 ms) >> 0.990 R² (0.983 R² .. 0.995 R²) >> mean 5.645 ms (5.472 ms .. 5.888 ms) >> std dev 593.0 μs (352.5 μs .. 908.2 μs) >> variance introduced by outliers: 63% (severely inflated) >> >> benchmarking renderTextT Id >> time 5.439 ms (5.243 ms .. 5.640 ms) >> 0.991 R² (0.985 R² .. 0.996 R²) >> mean 5.498 ms (5.367 ms .. 5.631 ms) >> std dev 408.8 μs (323.8 μs .. 552.9 μs) >> variance introduced by outliers: 45% (moderately inflated) >> >> benchmarking renderTextT Rd >> time 6.173 ms (5.983 ms .. 6.396 ms) >> 0.990 R² (0.983 R² .. 0.995 R²) >> mean 6.284 ms (6.127 ms .. 6.527 ms) >> std dev 581.6 μs (422.9 μs .. 773.0 μs) >> variance introduced by outliers: 55% (severely inflated) >> >> benchmarking renderTextT IO >> time 12.35 ms (11.84 ms .. 12.84 ms) >> 0.989 R² (0.982 R² .. 0.995 R²) >> mean 12.22 ms (11.85 ms .. 12.76 ms) >> std dev 1.159 ms (729.5 μs .. 1.683 ms) >> variance introduced by outliers: 50% (severely inflated) >> >> I tried replacing >> >> forM [1..10000] (\_ -> div_ "hello world!") >> >> with >> >> replicateM_ 10000 (div_ "hello world!") >> >> which discards the list of 10,000 () values that the forM thing >> generates, but this made very little difference. >> >> Hope this helps, >> >> David >> >> >> [1] https://github.com/vacationlabs/monad-transformer-benchmark/pull/2 >> >> >> >> On 29 January 2017 at 07:26, Saurabh Nanda <saurabhnanda(a)gmail.com> >> wrote: >> >> Hi, >> >> I was noticing severe drop in performance when Lucid's HtmlT was being >> combined with Scotty's ActionT. I've tried putting together a minimal repro >> at https://github.com/vacationlabs/monad-transformer-benchmark Request >> someone with better knowledge of benchmarking to check if the benchmarking >> methodology is correct. >> >> Is my reading of 200ms performance penalty correct? >> >> -- Saurabh. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> >>

3 7

Cleanup obsolete stack stuff (compiler, libraries, etc.)
by Geraldus 06 Feb '17

06 Feb '17

Hi folks! I want to perform some cleanup deleting obsolete compilers located in ~/.stack folder. I know stack places them into ~/.stack/programs/<platform>/ directory, however I think there are also should be something else related, e.g. docs and libs, and especially packages that was built when I used old LTS snapshots. What is the best way to perform such cleanup?

3 3

Removing Hackage packages
by aditya siram 06 Feb '17

06 Feb '17

Hi, I'd like to remove a couple of my packages [1] from Hackage. How do I do that? Thanks! -deech [1] http://hackage.haskell.org/package/fltkhs-demos, http://hackage.haskell.org/package/fltkhs-fluid-demos

2 2

ghci, running :load on filename provided by variable
by Dennis Raddle 05 Feb '17

05 Feb '17

How do I load a file in ghci where the filename comes from a variable? So like, let f = "myfile.hs" :load f D

3 2

Getting added to the Haskell group on Github.
by aditya siram 05 Feb '17

05 Feb '17

Hi, Some time ago the maintainership of c2hs [1] was silently passed to me. However I am unable to request access to the repo because I am not on the Haskell team [2]. Apparently I have to be added by someone already on the team but I'm having trouble getting in touch with someone. If anyone reading this is on the team [2] please add me. I'm @deech on Github. Thanks! -deech [1] https://github.com/haskell/c2hs [2] https://github.com/orgs/haskell/people

2 2

Purpose of Control.Monad.Base class
by Guru Devanla 04 Feb '17

04 Feb '17

Hello, I am trying to understand the purpose of the MonadBase class. https://hackage.haskell.org/package/transformers-base-0.4.4/docs/Control-Mo… Google search did not give me any helpful answers. Please could some one help me understand the purpose of this class and also point me to any good resources. Thanks Guru

2 1

using ghci with compiled code
by Dennis Raddle 04 Feb '17

04 Feb '17

I want to use ghci to interpret parts of my program, and I would like it to pick up pre-compiled object files to speed things up in other parts. Right now whenever I launch ghci it seems to "compile" everything (I think to byte code).. what can I do? D

2 2

Best way to provide monad transformer instances in library design?
by Matt 04 Feb '17

04 Feb '17

I'm writing a wrapper around ekg which provides an MTL-style class for recording metrics [1], and now I'm trying to figure out how to make the class usable for clients. I'm conflicted on the numerous ways to approach the problem. I would like to provide the best UX for the library, and want to consider viewpoints other than my own. Currently, the class is: class MonadMetrics m where getMetrics :: m Metrics I currently don't provide any concrete transformer, instead requiring that users define it for their own stacks. I'd like to make it easier to use. I can provide a concrete transformer newtype MetricT m a = MetricT (ReaderT Metrics m a) instance Monad m => MonadMetrics (MetricT m) where getMetrics = MetricT ask and then provide a wide variety of pass through instances. This approach requires a large amount of boilerplate, and for any instances I forget to provide, will require that clients make their own orphan instances. It also incurs additional dependencies just for writing instances. I can provide a more abstract transformer and a more general Metrics class: class HasMetrics r where metrics :: Lens' r Metrics newtype MetricT2 m a = MetricT2 (m a) instance (MonadReader r m, HasMetrics r) => MonadMetrics (MetricT2 m) where getMetrics = MetricT (view metrics) but this still requires those pass through instances. Finally, I can scrap `MonadMetrics` as anything other than a class alias: class (MonadReader r m, MonadIO m, HasMetrics r) => MonadMetrics r m instance (MonadReader r m, MonadIO m, HasMetrics r) => MonadMetrics r m but now I have UndecidableInstances and a multiparam type class, and I'm not sure how well this actually plays out in the wild. What are your thoughts on this issue? Matt Parsons [1]: https://github.com/sellerlabs/monad-metrics

1 0

segfault with Hint (InterpreterT)
by Dennis Raddle 03 Feb '17

03 Feb '17

My program segfaults the second time it run runInterpreterT. Just wondering if that's not supposed to be allowed. I'm actually not sure what triggers the segfault -- it's also doing some MIDI I/O. D

3 3

is there less available support for beginners these days?
by Dennis Raddle 03 Feb '17

03 Feb '17

I'm a Haskell hobbyist enthusiast -- first learned it in 2008, struggling having come from an imperative language background, and I only get to use it in hobby projects, but I love it more each year. I still consider myself a beginner in many areas. Unfortunately it used to be much easier to get responses on the beginner's list or the #haskell channel. I've now had several posts go completely unanswered on the beginner's list, and can't get help from #haskell most of the time (by "help" I mean someone who takes just a few minutes with me). I've tried posting on Haskell cafe in the hopes I would get more responses and I'm not sure if that's going to work (or is appropriate). D

5 5