Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unlifted standard classes #418

Open
yaitskov opened this issue May 20, 2022 · 2 comments
Open

Unlifted standard classes #418

yaitskov opened this issue May 20, 2022 · 2 comments

Comments

@yaitskov
Copy link

yaitskov commented May 20, 2022

Is your feature request related to a problem? Please describe.

GHC is shipped with UnliftedDatatypes extension, but base library has similar issue like with LinearTypes extension i.e. doesn't support it well. Even basic standard classes (Show/Eq/Ord/Num) are not supported. Unlifted and Linear types are both extensions are driven by performance ghost.

There is no much action around making better support of Unlifted types.
I spot 1 semi stale discussion ghc-proposals/ghc-proposals#30 and conclusion to reimplement a library of standard classes with levity polymorphic support in 3rd party library.

https://github.com/ekmett/unboxed

I looked at linear-base it just reexports Show from Prelude.

I curious why Unlifted extension is not used in linear-base - the library already has different class hierarchy - so (e.g. how Num is defined)

Performance gain from Unlifted extension is noticable, but combining code with different levity without common classes is hard:

benchmarking Fold Lifted/Left
time                 218.2 μs   (216.1 μs .. 220.4 μs)
                     0.999 R²   (0.999 R² .. 1.000 R²)
mean                 222.1 μs   (220.4 μs .. 224.3 μs)
std dev              6.753 μs   (4.599 μs .. 11.13 μs)
variance introduced by outliers: 26% (moderately inflated)

benchmarking Fold Unlifted/Left
time                 11.63 μs   (11.50 μs .. 11.80 μs)
                     0.998 R²   (0.997 R² .. 0.999 R²)
mean                 11.82 μs   (11.67 μs .. 12.06 μs)
std dev              689.3 ns   (459.1 ns .. 1.024 μs)
variance introduced by outliers: 67% (severely inflated)

https://github.com/yaitskov/lifted-vs-unlifted-benchmark/tree/6354d13bf4e36fd1aa93ec70bf19c2b8cb583608

@aspiwack
Copy link
Member

The reason for this is simple: linear-base has existed for longer than -XUnliftedDatatypes.

I haven't thought of what it would take to have better support for unlifted datatypes. What would you like to see?

PS: does the difference in performance persists if you use foldl' instead of foldl in the lifted case?

@yaitskov
Copy link
Author

foldl' does better than just foldl, but the unlifted version keeps the lead.

benchmarking Fold Lifted Prime/Left
time                 48.69 μs   (48.18 μs .. 49.43 μs)
                     0.998 R²   (0.997 R² .. 0.999 R²)
mean                 48.32 μs   (47.86 μs .. 49.13 μs)
std dev              1.773 μs   (1.192 μs .. 2.662 μs)
variance introduced by outliers: 39% (moderately inflated)

benchmarking Fold Unlifted/Left
time                 11.47 μs   (11.25 μs .. 11.70 μs)
                     0.997 R²   (0.995 R² .. 0.999 R²)
mean                 11.48 μs   (11.34 μs .. 11.78 μs)
std dev              672.5 ns   (467.2 ns .. 1.016 μs)
variance introduced by outliers: 68% (severely inflated)

Both Unlifted and Linear features are elephants. It is logical they started in separated sandboxes, but eventually they should merge gradually. I would start with redefining basic classes such Show, Ord etc one by one in linear-base or reimporting from Unboxed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants