Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#5272 closed bug (fixed)

Performance regression

Reported by: augustss Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.0.4
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

The code generated by ghc 7.0.4 is significantly slower than the one for ghc 6.12.4 for one of our large programs.

For a typical benchmark, with ghc-6.12.4 the compiled code ran in 110s and with ghc-7.0.4 it runs in 125s. This is 14% slower. The program was compiled with the same flags in both cases, notably -O2.

It's difficult to pin down the difference, because when compiled for profiling they run at about the same speed. And as usual the profiling information from ghc is wildly inaccurate (with both versions, but in different ways).

Change History (8)

comment:1 Changed 3 years ago by tibbe

What's the performance like with the current HEAD (soon to be 7.2)?

comment:2 Changed 3 years ago by augustss

I'll try it with the June 18 snapshot.

comment:3 follow-up: Changed 3 years ago by augustss

After spending 12 hours porting the code to ghc 7.1 (anyone who claims ghc is upwards compatible is living in a dream land), I have some figures for my benchmark. (This is running on my laptop rather than my desktop so the numbers are different.)

ghc 6.12.3: 277s
ghc 7.0.4: 299s
ghc 7.1.20110617: 270s

So it seems ghc 7.1 has recovered the loss incurred by ghc 7.0.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by igloo

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

Replying to augustss:

After spending 12 hours porting the code to ghc 7.1 (anyone who claims ghc is upwards compatible is living in a dream land)

I'd be interested to know if the problematic changes were deliberate library changes, the new haskell98/base conflict, changes in the more experimental GHC extensions, or something else.

So it seems ghc 7.1 has recovered the loss incurred by ghc 7.0.

Great, thanks for testing. I'll close the ticket then.

comment:5 Changed 3 years ago by simonpj

Lennart, there's a guide to updating to GHC 7 here http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7. If you have found anything that isn't documened there, would you consdier you adding it, to help others?

Which points caused you particular pain?

comment:6 in reply to: ↑ 4 Changed 3 years ago by simonmar

Replying to igloo:

I'd be interested to know if the problematic changes were deliberate library changes, the new haskell98/base conflict, changes in the more experimental GHC extensions, or something else.

Or the new Unicode support in withCString?

comment:7 Changed 3 years ago by augustss

First, I don't really mind if ghc is not backwards compatible.
A compiler has to move forwards and can't support old things forever.
I just want to point out that every new ghc release is a pain for people with a large code base.

Here are the things that caused pains in porting:

  • haskell98 no longer supported
  • change of type names in Typeable (that took quite a while to debug)
  • Prelude.catch deprecated (we compile with -Werror)
  • network package didn't build using Setup.hs (as usual)
  • glib package didn't build for reasons I never figured out

comment:8 Changed 3 years ago by tibbe

Lennart, I just wanted to let you know that I'm looking into the network issue. It has to do with tiresome technicalities involving differences between cabal/Setup.hs, running two preprocessors after each other (CPP and hsc2hs), and autoconf.

Note: See TracTickets for help on using tickets.