Hint to GHC that indices are to be used strictly #485
Conversation
Bodigrim
force-pushed
the
indices-are-strict
branch
from
5de58ff to
9f21834
Compare
Shimuuar
left a comment
Shimuuar
left a comment
There was a problem hiding this comment.
Great find! I think slice/unsafeSlice would benefit from the same treatment as well.
P.S. Out of curiosity I looking into GHC's timing information. This change reduced allocation by simplifier by about 1e-3 when compiling unboxed vectors.
| {-# INLINE unsafeRead #-} | ||
| unsafeRead v i = checkIndex Unsafe i (length v) | ||
| unsafeRead v !i = checkIndex Unsafe i (length v) | ||
| $ stToPrim |
There was a problem hiding this comment.
I 100% agree with this change, but unfortunately it means the following lines are no longer indented correctly with respect to the =. Is that something that can be fixed as part of this PR?
| {-# INLINE unsafeWrite #-} | ||
| unsafeWrite v i x = checkIndex Unsafe i (length v) | ||
| unsafeWrite v !i x = checkIndex Unsafe i (length v) | ||
| $ stToPrim |
| {-# INLINE unsafeModify #-} | ||
| unsafeModify v f i = checkIndex Unsafe i (length v) | ||
| unsafeModify v f !i = checkIndex Unsafe i (length v) | ||
| $ stToPrim |
| {-# INLINE unsafeModifyM #-} | ||
| unsafeModifyM v f i = checkIndex Unsafe i (length v) | ||
| unsafeModifyM v f !i = checkIndex Unsafe i (length v) | ||
| $ stToPrim . basicUnsafeWrite v i =<< f =<< stToPrim (basicUnsafeRead v i) |
|
@Bodigrim I extended same treatment to If you're fine with this I'd like to merge this PR |
|
@Shimuuar sure, go ahead. |
'basicUnsafe{Read/Write/IndexM}' are class members and, unless a call site was
already specialised to a specific vector instance, GHC has no clue that the index
is most certainly to be used eagerly. Bang before the index provides
this vital for optimizer information.
We have longish comment which is referenced from multiple places in source code. GHC notes seems good option for that
Shimuuar
force-pushed
the
indices-are-strict
branch
from
96ee359 to
e13cb00
Compare
basicUnsafe{Read/Write/IndexM}are class members and, unless a call site was already specialised to a specific vector instance, GHC has no clue that the index is most certainly to be used eagerly. Bang before the index provides this vital for optimizer information.I've been recently looking at Core for programs, where vectors did not specialise to a specific instance for one reason or another. It's really horrible: even if a specific instance remains unknown, we should tell GHC that passing boxed indices around is not OK.