Opened 3 years ago

Closed 8 months ago

Last modified 3 weeks 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 20 months 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 19 months ago by akio

  • Cc tkn.akio@… added

comment:8 Changed 15 months ago by bjp

  • Cc bjp@… added

comment:9 Changed 14 months ago by nh2

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

comment:10 Changed 14 months ago by gidyn

  • Cc gideon@… added

comment:11 Changed 14 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 14 months ago by George

  • Cc george.colpitts@… added

comment:13 Changed 13 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 13 months ago by thoughtpolice

  • Priority changed from high to normal

Actually dropping priority. :)

comment:15 Changed 9 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 8 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 8 months ago by tibbe

  • Milestone changed from 7.10.1 to 7.8.4

comment:18 Changed 3 weeks ago by gidyn

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