Re: [GHC] #7367: Optimiser / Linker Problem on amd64

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by wurmli): Replying to [comment:14 simonpj]:
wurmli, no I don't think it's reasonable. (Unless I'm missing something.) I have not looked very carefully, but I think this program does a lot of read/write of an imperatively-mutable `(STRef (Int,Int))`. If we could eliminate those read/write pairs altogether, that would indeed be a good thing, but that is pretty hard to do, because in principle any computation of type `(ST s a)` might mutate that reference. GHC simply doesn't have any serious optimisations for imperative code; it focuses on optimising functional code.
To put it another way, what program would you expect GHC to transform your code into?
Simon
I am sorry for not choosing my words carefully enough. As a Haskell programmer I have only limited ways to influence how the compiled program utilises the resources on a given computer architecture. Most of the time this is a great blessing as it lets me concentrate on the logic of my task. But for some tasks, e.g. numerics or simulation, raw speed often results from optimal use of the resources. So I should probably not say it is a reasonable expectation but a hope that the code generator and optimiser can do that job for me. In the same way that I might manage to write a recursive function as a tail recursive one, I would have hoped that by giving a hint with an imperative style Haskell program that the code generator / optimiser could generate what you would get from, say, an analoguous C-program. If not you and your top colleagues working on ghc, who should be able to find a solution, if one even exists? Let me look stupid: in one of the optimisation phases an analyses of dead and live variables takes place (which looks like the action of a garbage collector to me). My naive expectation would be that an optimisation is possible if and only if an analyses of dead and live variables is doable (based on the syntactic structure at that stage). Hans Peter -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7367#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC