
On 21 November 2005 14:57, Matt wrote:
I was doing some work with Word64 and noticed that it was about 3 times slower than Int64. The reason appears to be expensive conversions from Int64# to Word64# and vice versa. I modified the libraries to remove the conversion overhead, and the result is that Int64# and Word64# now have equal performance, at least on the domain that I tested (==, +, -).
I can't check into the tree, so I was told to send my changes to this list. Could someone else check them in? I have attached a patch file representing my changes.
Thanks for the patch - but could you try this instead? int64ToWord64# = unsafeCoerce# word64ToInt64# = unsafeCoerce# this should reduce the cost of the conversions to zero, which is a simpler way to fix the performance bug (if it works). If you confirm that this also improves performance, I'll commit it. If not, I'll commit your patch instead. Cheers, Simon

Hello Simon, Wednesday, November 23, 2005, 2:28:26 PM, you wrote: SM> int64ToWord64# = unsafeCoerce# SM> word64ToInt64# = unsafeCoerce# SM> this should reduce the cost of the conversions to zero, which is a SM> simpler way to fix the performance bug (if it works). SM> If you confirm that this also improves performance, I'll commit it. If SM> not, I'll commit your patch instead. please don't forget about: int32ToWord32# word32ToInt32# intToInt32# int32ToInt# wordToWord32# word32ToWord# int2Word# word2Int# -- Best regards, Bulat mailto:bulatz@HotPOP.com

Bulat Ziganshin wrote:
Hello Simon,
Wednesday, November 23, 2005, 2:28:26 PM, you wrote:
int64ToWord64# = unsafeCoerce# word64ToInt64# = unsafeCoerce#
this should reduce the cost of the conversions to zero, which is a simpler way to fix the performance bug (if it works).
If you confirm that this also improves performance, I'll commit it. If not, I'll commit your patch instead.
please don't forget about:
int32ToWord32# word32ToInt32# intToInt32# int32ToInt# wordToWord32# word32ToWord# int2Word# word2Int#
These are already free, as I understand. When I compare Int, Word, Int#, Word#, Int32 (same thing as Int), and Word32 (same thing as Word), they have identical performance. It is Int64/Word64/Int64#/Word64# that are abysmal. I will continue as time allows and make the suggested changes, but I thought that the original patch also makes sense. Compare these definitions from the original Word.hs file: (W# x#) + (W# y#) = W# (x# `plusWord#` y#) (W8# x#) + (W8# y#) = W8# (narrow8Word# (x# `plusWord#` y#)) (W16# x#) + (W16# y#) = W16# (narrow16Word# (x# `plusWord#` y#)) (W32# x#) + (W32# y#) = W32# (narrow32Word# (x# `plusWord#` y#)) (W64# x#) + (W64# y#) = W64# (int64ToWord64# (word64ToInt64# x# `plusInt64#` word64ToInt64# y#)) The definitions are those used on a 32-bit architecture. So, when it is cheap the plusWord# function is used, but when it is "relatively expensive" then extra conversions are added. Wouldn't it make sense to avoid the conversions in all cases, regardless of whether they are free or not? If so, then I will keep the old changes in the next patch I submit. If not, then I will discard them. -Matt or [ricebowl, wearkilts, soysauce] on #haskell on Freenode

Hello Matt, Thursday, November 24, 2005, 7:52:23 AM, you wrote:
int64ToWord64# = unsafeCoerce# word64ToInt64# = unsafeCoerce#
M> (W32# x#) + (W32# y#) = W32# (narrow32Word# (x# `plusWord#` y#)) M> (W64# x#) + (W64# y#) = W64# (int64ToWord64# (word64ToInt64# x# M> `plusInt64#` word64ToInt64# y#)) M> The definitions are those used on a 32-bit architecture. So, when it is M> cheap the plusWord# function is used, but when it is "relatively expensive" M> then extra conversions are added. Wouldn't it make sense to avoid the M> conversions in all cases, regardless of whether they are free or not? i'm agree that code simplification you already done is anyway Right Thing. so it's better to apply your patch AND add abovementioned definitions to help any other operations. about int32ToWord32# and so on - they are defined through stg primitives, so anyway defining them as unsafeCoerce# must make things a little faster -- Best regards, Bulat mailto:bulatz@HotPOP.com
participants (3)
-
Bulat Ziganshin
-
Matt
-
Simon Marlow