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

GHC ghc-devs at haskell.org
Wed Aug 28 22:45:46 UTC 2013


#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 rwbarton):

 wurmli, what's the matter with it?

 "800,100,272 bytes allocated in the heap" means that the total size of all
 the allocations done over the course of the program is 800,100,272 bytes.
 That's the expected size of 20 million (Int, Int) pairs which share their
 second field (`n`), plus a small amount of other stuff.  It doesn't have
 anything to do with the size of the heap at any given time.  The maximum
 heap size is shown separately: "50,520 bytes maximum residency" which is
 quite reasonable.

 Similarly your original program does not ever occupy 10 GB of heap at a
 time.  If you look at the process in top you will see a memory usage close
 to "47,184 bytes maximum residency" (well probably more like a couple MB,
 to hold the program image, but not anything near 10 GB).

 I have no idea why the original program timed out on the language
 benchmark machines, but it wasn't due to it allocating 10 GB sequentially.
 Allocation of short-lived objects is very cheap.  But it is not free, and
 this discussion has been about why current GHC produces a program that
 allocates a lot when GHC 7.4 did not.  Eliminating the large amount of
 allocation might reduce the runtime by a few percent or so.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler




More information about the ghc-tickets mailing list