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

[GHC]

#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