Opened 10 years ago

Last modified 15 months ago

#605 new task (None)

Optimisation: strict enumerations

Reported by: simonmar Owned by:
Priority: normal Milestone:
Component: Compiler Version: None
Keywords: Cc: Bulat.Ziganshin@…, id@…, pho@…, hackage.haskell.org@…, tibbe, dterei
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Difficulty: Difficult (2-5 days)
Test Case: N/A Blocked By:
Blocking: Related Tickets: #6135

Description (last modified by igloo)

Strict enumeration types should be implemented by Int#, both in the strictness analyser and for constructor fields annotated with {-# UNPACK #-}.

Change History (19)

comment:1 Changed 8 years ago by simonmar

  • Architecture set to Unknown
  • Description modified (diff)
  • Difficulty set to Difficult (1 week)
  • Operating System set to Unknown

comment:2 Changed 7 years ago by igloo

  • Description modified (diff)
  • Milestone set to 6.8
  • Test Case set to N/A

comment:3 Changed 7 years ago by guest

  • Cc Bulat.Ziganshin@… added

comment:4 Changed 7 years ago by Isaac Dupree

  • Cc id@… added

comment:5 Changed 6 years ago by simonmar

  • Milestone changed from 6.8 branch to _|_

We get much of the benefit of this optimisation from pointer-tagging (in 6.8.1), so the payoff will be less. Probably still worth doing, but not as important now.

comment:6 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:7 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:8 Changed 4 years ago by PHO

  • Cc pho@… added

comment:9 Changed 4 years ago by simonmar

  • Difficulty changed from Difficult (1 week) to Difficult (2-5 days)

comment:10 Changed 4 years ago by igloo

  • Type of failure set to Runtime performance bug

comment:11 Changed 3 years ago by liyang

  • Cc hackage.haskell.org@… added

comment:12 Changed 3 years ago by simonmar

Also requested in #4936

comment:13 Changed 3 years ago by simonpj

  • Cc tibbe added

I'd still like to see a test program showing the existing setup, compared what you get with manual unboxing of enumerations. That would give us an idea of whether there's a real perf win here.

Simon

comment:14 follow-up: Changed 3 years ago by rl

Wouldn't this make boxed enumeration values (esp. Bool) larger by a word?

comment:15 in reply to: ↑ 14 Changed 3 years ago by tibbe

Replying to rl:

Wouldn't this make boxed enumeration values (esp. Bool) larger by a word?

Yes, unless they are also unpacked.

comment:16 follow-up: Changed 3 years ago by rl

I think there is actually a subtle difference between #4936 and this ticket. #4936 proposes to represent enumerations as Int which would indeed make boxed enumeration values bigger. This ticket proposes to keep the representation of boxed values as it is now but to unbox them to Int# when possible. This seems more efficient.

comment:17 in reply to: ↑ 16 Changed 3 years ago by tibbe

Replying to rl:

I think there is actually a subtle difference between #4936 and this ticket. #4936 proposes to represent enumerations as Int which would indeed make boxed enumeration values bigger. This ticket proposes to keep the representation of boxed values as it is now but to unbox them to Int# when possible. This seems more efficient.

Yes. I think only transforming strict enumerations (to an Int#) is enough. No need to change non-strict enumerations to an Int.

comment:18 Changed 15 months ago by dterei

  • Cc dterei added

comment:19 Changed 15 months ago by dterei

Note: See TracTickets for help on using tickets.