#3607: index variable for array traversal worker function is not unboxed
-------------------------------+--------------------------------------------
Reporter: blarsen | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.10.4 | Severity: normal
Keywords: unboxed array, Ord | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-------------------------------+--------------------------------------------
See also [http://hackage.haskell.org/trac/ghc/ticket/3606].
In an attempt to write a better comparison function for unboxed arrays, I
wrote the following code:
{{{
{-# LANGUAGE BangPatterns #-}
{-# OPTIONS -Wall #-}
module BadArrayCmp where
import Data.Array.Base
import Data.Array.Unboxed
cmpArrays :: (IArray a1 e, IArray a2 e, Ix i, Ord e)
=> a1 i e
-> a2 i e
-> Ordering
cmpArrays a1 a2 = case compare (bounds a1) (bounds a2) of
LT -> LT
EQ -> go 0
GT -> GT
where
iMaxPlusOne :: Int
iMaxPlusOne = numElements a1
go :: Int -> Ordering
go !i = if i == iMaxPlusOne
then EQ
else case compare (unsafeAt a1 i) (unsafeAt a2 i) of
LT -> LT
EQ -> go (i+1)
GT -> GT
{-# INLINE cmpArrays #-}
}}}
I have attached this code as a test case.
Examining the core generated by ghc 6.10.4 using -O2 on Ubuntu 9.04
x86_64, the code generated for 'go' uses a boxed Int for the index
variable.
Because of this boxed int (and perhaps other problems in the generated
code, I'm not sure), in a particular application of mine, ~60% of the
total time is used and %80% of the total allocation is done in
'cmpArrays'. (These percentages obtained via profiling.)
I imagine that 'go' _could_ be compiled so that the only potential
allocation done is for the Ordering value at the end. Using a boxed index
variable instead of something kept in a register really kills performance!
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3607>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
