haskell@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