Opened 3 years ago

Closed 11 months ago

Last modified 4 months ago

#7068 closed bug (fixed)

Extensive Memory usage (regression)

Reported by: waldheinz Owned by: simonpj
Priority: normal Milestone: 7.8.4
Component: Compiler Version: 7.4.1
Keywords: Cc: tkn.akio@…, bjp@…, george.colpitts@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

The "bling raytracer" project [1] can not be compiled with recent GHC versions (personally tested 7.4.1 on Linux / OS X / Windows, that 7.4.2 fails in the same way was reported on IRC).

The problem is that when compiling the "Transform.hs" source file [2] GHC allocates more RAM than any of my machines can bear (8+ GB).

This does not happen with 7.0.x versions of GHC. Also, reducing the optimization level from O2 to O1 makes the problem go away. To reproduce this bug I'd recommend

hg clone -r eb0f7f91bde6 https://code.google.com/p/bling-raytracer/ cabal build

There was no consensus on IRC if this is really a GHC bug or I should simply tinker with the GHC options / source file until it works. But since the code in question does not use any obscure extensions (in fact, no extensions at all) and could be compiled with many GHC versions from 6.4 onward, I thought you might want to hear about it.

[1] http://code.google.com/p/bling-raytracer/ [2] http://code.google.com/p/bling-raytracer/source/browse/src/Graphics/Bling/Transform.hs?r=9499d979762ddcbc1ff31aea053dfcf3d4590a08

Attachments (2)

linalg3.ps (80.5 KB) - added by pcapriotti 3 years ago.
linalg4.prof (78.3 KB) - added by pcapriotti 3 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 3 years ago by simonmar

  • difficulty set to Unknown
  • Milestone set to 7.6.1
  • Priority changed from normal to high

We should at least look into this and decide whether there's something suspicious going on or not.

comment:2 Changed 3 years ago by simonpj

  • Owner set to pcapriotti

Changed 3 years ago by pcapriotti

Changed 3 years ago by pcapriotti

comment:3 Changed 3 years ago by pcapriotti

  • Owner pcapriotti deleted

The compiler is blowing up on the SpecConstr pass here. Here is how to reproduce the problem without installing any packages:

cabal unpack Vec

add a new binding to Data/Vec/LinAlg.hs:

inv :: [[Float]] -> Maybe [[Float]]
inv l = fmap matToLists (invert (matFromLists l) :: Maybe (Mat44 Float))

export it, and compile with:

ghc -fforce-recomp --make -O1 Data/Vec/LinAlg.hs -fspec-constr

The problem seems to be some sort of exponential blowup during specialization of the :. constructor. Note that all the functions in that module (and in Data.Vec.Base) are inlined.

Attaching a time and a heap profile with -fprof-auto on SpecConstr.lhs (the compiler was interrupted after a while).

comment:4 Changed 3 years ago by simonmar

  • Owner set to simonpj

Simon - it would be good to look into this before the 7.6 release since it's a regression from 7.0.

comment:5 Changed 3 years ago by simonpj

  • Milestone changed from 7.6.1 to 7.8.1

I don't think I'm going to get time to look at this before 7.6. Just use -fno-spec-constr for now. Sorry. But let's keep it as a high priority bug.

comment:6 Changed 2 years ago by bgamari

I tried to reproduce this with 7.8 but unfortunately #7574 got in the way of building utf8-string. Perhaps it would be worth trying again after this is fixed.

comment:7 Changed 23 months ago by akio

  • Cc tkn.akio@… added

comment:8 Changed 19 months ago by bjp

  • Cc bjp@… added

comment:9 Changed 17 months ago by nh2

pcapriotti's Vec example doesn't seem to blow up for me on 7.6.3 Linux.

comment:10 Changed 17 months ago by gidyn

  • Cc gideon@… added

comment:11 Changed 17 months ago by George

When I try to reproduce on ghc 7.8.1 and Vec-1.0.1 with pcapriotti's instructions above I get a compilation error:

 ghc -fforce-recomp --make -O1 Data/Vec/LinAlg.hs -fspec-constr
[1 of 3] Compiling Data.Vec.Nat     ( Data/Vec/Nat.hs, Data/Vec/Nat.o )
[2 of 3] Compiling Data.Vec.Base    ( Data/Vec/Base.hs, Data/Vec/Base.o )
[3 of 3] Compiling Data.Vec.LinAlg  ( Data/Vec/LinAlg.hs, Data/Vec/LinAlg.o )

Data/Vec/LinAlg.hs:241:10:
    Illegal instance declaration for ‘SetDiagonal v m’
      The liberal coverage condition fails in class ‘SetDiagonal’
        for functional dependency: ‘m -> v’
      Reason: lhs type ‘m’ does not determine rhs type ‘v’
    In the instance declaration for ‘SetDiagonal v m’

Data/Vec/LinAlg.hs:580:10:
    Illegal instance declaration for ‘Pivot a (() :. v)’
      The liberal coverage condition fails in class ‘Pivot’
        for functional dependency: ‘m -> a’
      Reason: lhs type ‘() :. v’ does not determine rhs type ‘a’
    In the instance declaration for ‘Pivot a (() :. v)’

comment:12 Changed 17 months ago by George

  • Cc george.colpitts@… added

comment:13 Changed 16 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.10.1

Bumping priority down (these tickets haven't been closely followed or fixed in 7.4), and moving out to 7.10 and out of 7.8.3.

comment:14 Changed 16 months ago by thoughtpolice

  • Priority changed from high to normal

Actually dropping priority. :)

comment:15 Changed 12 months ago by simonpj

  • Status changed from new to infoneeded

I believe this may be finally fixed; see #8852. Can you try now, with HEAD?

Simon

comment:16 Changed 11 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from infoneeded to closed

I remember I fiddled with this but couldn't get it to compile after a short time; but I do believe this behavior has been fixed (re: many other very similar tickets: #8852, #8980, #8941, #8960, #7898, #5550, #8836). Please re-open if you think otherwise.

comment:17 Changed 11 months ago by tibbe

  • Milestone changed from 7.10.1 to 7.8.4

comment:18 Changed 4 months ago by gidyn

  • Cc gideon@… removed
Note: See TracTickets for help on using tickets.