#5539: GHC panic - Simplifier ticks exhausted
---------------------------------+------------------------------------------
Reporter: hvr | Owner: simonpj
Type: bug | Status: new
Priority: high | Milestone: 7.4.1
Component: Compiler | Version: 7.3
Resolution: | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Compile-time crash | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: | Related:
---------------------------------+------------------------------------------
Comment(by dolio):
I haven't done extensive testing, but I think I fiddled a bit a while
back, and got the impression it wasn't.
And I suspect the reason is exactly what you mention. Specialization to
the comparison function is huge, because it's in every inner loop.
Inlining the whole sort should allow the comparison to be turned into an
unpacked version.
Making {{{sort}}} {{{INLINABLE}}} might work, if that specializes to the
dictionary, resulting in a statically known comparison that can be
unboxed. But I suspect {{{sortBy}}} needs to be {{{INLINE}}} unless
there's a good way to specialize to arbitrary statically known
''arguments''.
Speaking more generally, the performance of vector-algorithms tends to
rely a lot on getting GHC to optimize all my code down to using stuff like
{{{Int#}}} ({{{Word#}}}, ...) everywhere. When most of the code was
written, the only reliable way I could find to do this was inlining
everything. Even splitting out auxiliary functions and not inlining them
tended to result in superfluous boxing, which kills performance.
I'll do some experiments with INLINABLE to see if I can get it to generate
specialized verisons without code bloat. But I suspect a lot of cases will
see the same problems as sortBy: most of the core logic needs to be
specialized to particular parameters (comparisons, radix functions, etc.),
and dictionaries are only used as a convenient wrapper.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5539#comment:39>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
