Opened 13 years ago

Last modified 5 months ago

#605 new task (None)

Optimisation: strict enumerations

Reported by: simonmar Owned by:
Priority: normal Milestone: 8.4.1
Component: Compiler Version: None
Keywords: Cc: Bulat.Ziganshin@…, id@…, pho@…, hackage.haskell.org@…, tibbe, dterei, bgamari, dfeuer, michalt, tom-bop
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case: N/A
Blocked By: Blocking:
Related Tickets: #6135 Differential Rev(s):
Wiki Page:

Description (last modified by bgamari)

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

Change History (25)

comment:1 Changed 12 years ago by simonmar

Architecture: Unknown
Description: modified (diff)
difficulty: Difficult (1 week)
Operating System: Unknown

comment:2 Changed 11 years ago by igloo

Description: modified (diff)
Milestone: 6.8
Test Case: N/A

comment:3 Changed 10 years ago by guest

Cc: Bulat.Ziganshin@… added

comment:4 Changed 10 years ago by Isaac Dupree

Cc: id@… added

comment:5 Changed 10 years ago by simonmar

Milestone: 6.8 branch_|_

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 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:7 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:8 Changed 8 years ago by PHO

Cc: pho@… added

comment:9 Changed 8 years ago by simonmar

difficulty: Difficult (1 week)Difficult (2-5 days)

comment:10 Changed 8 years ago by igloo

Type of failure: Runtime performance bug

comment:11 Changed 7 years ago by liyang

Cc: hackage.haskell.org@… added

comment:12 Changed 7 years ago by simonmar

Also requested in #4936

comment:13 Changed 7 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 Changed 7 years ago by rl

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

comment:15 in reply to:  14 Changed 7 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 Changed 7 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 7 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 5 years ago by dterei

Cc: dterei added

comment:19 Changed 5 years ago by dterei

comment:20 Changed 3 years ago by bgamari

Cc: bgamari added
Description: modified (diff)

comment:21 Changed 11 months ago by osa1

FWIW we can currently store strict enumerations as Int#s with Phab:D2424.

Phab:D2436 allows returning Int# when returned enumeration is used strictly.

Another patch is needed for extending demand analysis and passing Int# for strict enumerations. I actually have most of the code ready, but it needs rebasing it on current HEAD. IIRC some parts of the demand analysis were missing, but I can't remember exactly which parts.

comment:22 Changed 11 months ago by dfeuer

Cc: dfeuer added
Milestone: 8.2.1

Setting a milestone because osa1 is working actively in this area.

comment:23 Changed 11 months ago by bgamari

Milestone: 8.2.18.4.1

I don't think this will happen for 8.2 though.

comment:24 Changed 6 months ago by michalt

Cc: michalt added

comment:25 Changed 5 months ago by tom-bop

Cc: tom-bop added
Note: See TracTickets for help on using tickets.