-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow compilation #428
Comments
Hey, thanks for opening that ticket! Yeah, accelerate takes ages to compile. I have been meaning to look into it for a while but never found the time; hopefully the GHC devs will have some insight into what is causing compile times to blow up. |
I just spent some time looking into this from the GHC side of things; it seems that, at least in the We're also wondering whether, by any chance, you know whether this is a new problem, or one that's been around on older GHC releases. |
Hey @tdammers, thanks for poking on this, I've been eagerly following the ghc ticket... Honestly that module probably doesn't need all the inlining. I think I just read in the bytestring builder docs somewhere that for good performance you need to inline everything. The other problematic example listed in the ticket, |
Hmm, I think that documentation is kind of misleading then. You certainly don't need to inline everything, just the things that compose bytestring builders, and I believe the reasoning behind that is that It's actually possible that inlining does produce runtime perfomance benefits here btw.; it's just that the price we pay for this is a massive blow-up of compiler performance, and the question is whether we are willing to pay that price. A first step towards making this decision would be to do some profiling and benchmarking to get a better idea of the tradeoff. My gut feeling, however, says that the sheer size of that code is going to hurt CPU cache performance enough to melt away all the other performance benefits.
Right, I haven't actually looked at that other module - since it's only a test module, I figured it'd be less of a hindrance to users of the library, after all, most people don't run the test suite for every dependency they install. |
In the standard build the test files do get built, unfortunately. The test programs are exported so they can be used for the different backends ( Historically, when the tests were in a separate package, those tests just never got run, so I think it is important that you can Here is the ghc-8.6.1 -v3 log for click to expand:
|
Great, thanks for that! This one looks like there could actually be more going on than just literally obeying |
Just for reference, I noticed https://ghc.haskell.org/trac/ghc/ticket/15488 and I can confirm that compilation is slow.
This is for accelerate-1.2.0.0 (current from hackage) with ghc-8.4.3 on GNU/Linux-amd64
The text was updated successfully, but these errors were encountered: