haskell at kudling.de writes:
> Profiling says that the majority of the time is spend in "main". But i have no idea where.
> Can someone give me a hint?
Yes. Lots of them, but somehow, I suspect nobody tried your code.
> COST CENTRE MODULE no. entries %time %alloc %time %alloc
>> MAIN MAIN 1 0 0.0 0.0 100.0 100.0
> main Main 254 1 88.1 90.8 100.0 100.0
> monteCarloPi Main 255 1 0.6 1.1 11.9 9.2
> pairs Main 257 10000000 0.7 1.4 0.7 1.4
> countHits Main 256 10000001 4.2 2.9 10.6 6.7
> accumulateHit Main 258 27852236 3.0 2.3 6.4 3.8
> isInCircle Main 259 30000000 3.3 1.5 3.3 1.5
> CAF:lit_r1A7 Main 248 1 0.0 0.0 0.0 0.0
> isInCircle Main 260 0 0.0 0.0 0.0 0.0
Thomas van Noort:
> First thing I noticed, how about removing the sqrt in isInCircle:
I did this. The result was the same - the sqrt doesn't matter, and
perhaps it even gets optimized away?
> The first thing I would do is replace your
> isInCircle :: (Floating a, Ord a) => (a,a) -> Bool
> with
> isInCircle :: (Double, Double) -> Bool
Then I did that. The result was still the same - I bet GHC is smart
enought to specialize this on its own.
The intresting thing about your profile is that all the time is spent
in 'main'. Now, why would that be? I refactored a bit, and in
partiuclar wrote this function:
mkRandoms :: IO [Double]
mkRandoms = do
randomNumberGenerator <- getStdGen
return $ randoms randomNumberGenerator
Here's the new profile (10^6 iterations):
COST CENTRE MODULE %time %alloc
mkRandoms Main 96.1 96.0
accumulateHit Main 1.6 1.7
pairs Main 1.2 1.3
monteCarloPi Main 0.2 1.0
So it seems we're just tremendously lousy at generating random
Doubles. Eliminating this bottleneck, the remaining 3.9% would put it
at about 2x the C++ performance.
-k
--
If I haven't seen further, it is by standing in the footprints of giants