Opened 2 years ago

Closed 2 years ago

#13566 closed bug (invalid)

Bigger core size in ghc8 compared to ghc7

Reported by: pacak Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.2.1-rc2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Generated core size (as reported by ghc -v) is much bigger in ghc 8.0.2 compared to ghc 7.10.1. Things are slightly better in ghc 8.2.0rc2, but not as good as in ghc7

I think that results in a slight runtime performance problem.

steps to reproduce:

ghc -O A.hs

Result size of CorePrep  = {terms: 5,016, types: 9,813, coercions: 1,443} -- ghc8
Result size of CorePrep  = {terms: 975, types: 2,375, coercions: 150} -- ghc7
Result size of CorePrep  = {terms: 1,342, types: 2,838, coercions: 320, joins: 0/66} -- ghc8.2

Attachments (1)

sample.zip (3.6 KB) - added by pacak 2 years ago.
(right sample)

Download all attachments as: .zip

Change History (11)

Changed 2 years ago by pacak

Attachment: sample.zip added

(right sample)

comment:1 Changed 2 years ago by pacak

If you comment out

    {-# SPECIALISE instance AdditiveGroup (Piecewise IntOfLogPoly4 Double) #-}

in Numeric/Polynomial/Piecewise.hs

ghc7 version starts behaving similar to ghc8, at the same time AdditiveGroup instance is not used at all anywhere.

comment:2 Changed 2 years ago by mpickering

pacak also says on IRC that inlining any of the three files into each other leads to smaller core. Also the INLINE and INLINABLE pragmas are necessary in A.hs.

comment:3 Changed 2 years ago by rwbarton

This reproducer depends on vector. What version? With vector-0.11.0.0 and ghc-8.0.1 I got these numbers:

Result size of CorePrep  = {terms: 1,227, types: 2,667, coercions: 256}

comment:4 Changed 2 years ago by pacak

I was able to reproduce this vector-0.10.12.3 for ghc7 and ghc8 and with vector-0.12.0.1

comment:5 Changed 2 years ago by simonpj

From 975 in GHC 7.10 to 1,342 in GHC 8.2 doesn't sound terrible.

comment:6 Changed 2 years ago by pacak

From 975 in GHC 7.10 to 1,342 in GHC 8.2 doesn't sound terrible.

When I was stripping down the example I was looking at sizes for ghc7 and ghc8. I can try to check ghc8.2 on original code, but it'll take time.

comment:7 Changed 2 years ago by pacak

GHC 8.2 on original code:

Result size of Demand analysis
  = {terms: 5,548, types: 10,236, coercions: 2,752, joins: 10/79}
!!! Demand analysis [A]: finished in 198.43 milliseconds, allocated 43.533 megabytes
*** CoreTidy [A]:
Result size of Tidy Core
  = {terms: 1,150, types: 2,274, coercions: 320, joins: 0/14}
!!! CoreTidy [A]: finished in 6.72 milliseconds, allocated 6.210 megabytes
writeBinIface: 149 Names
writeBinIface: 279 dict entries
writeBinIface: 149 Names
writeBinIface: 279 dict entries
*** CorePrep [A]:
Result size of CorePrep
  = {terms: 1,342, types: 2,838, coercions: 320, joins: 0/66}

Looks like ghc 8.2 also produces similar sized core and manages to clean it up later.

comment:8 Changed 2 years ago by bgamari

Status: newinfoneeded

I'm a bit lost here. Am I to understand from comment:7 that this was an issue in GHC 8.0 that is fixed in 8.2.1-rc1?

comment:9 Changed 2 years ago by pacak

I'm a bit lost here. Am I to understand from comment:7 that this was an issue in GHC 8.0 that is fixed in 8.2.1-rc1?

It can probably be closed for now. The problem is this sample is very fragile - for example if I remove AdditiveGroup instance which is not used at all or even specialization pragma - it suddenly works as expected in ghc 8.0. There are more code using generics in our project. If I find a way to reproduce it for ghc 8.2 - I can reopen it again with new data.

comment:10 Changed 2 years ago by bgamari

Resolution: invalid
Status: infoneededclosed

Alright, do let us know if you manage to get a clean reproducer.

Note: See TracTickets for help on using tickets.