
Greetings. Using GHC 6.0 on Mac OS X (10.2.6), I'm trying to do some timing tests of something that doesn't take very long. So, I want to call a function repeatedly (1000s of times). It appears, however, that the compiler is figuring out that there's no need to call the function more than once since it's pure. Is there anything simple I can do to get the compiler to call a function repeatedly? Here is a snippet of code showing what I am trying right now: main = do t0 <- getClockTime times 1000 t1 <- getClockTime . . . times :: Int -> IO () times 0 = return () times n = do let [a,b,c,d] = take 4 (myFunction) Control.Exception.evaluate a Control.Exception.evaluate b Control.Exception.evaluate c Control.Exception.evaluate d times $! n - 1 myFunction :: [Int] myFunction = . . . (There may be some absurd stuff in this code; I've left in the remnants of several failed attempts.) Regards, Jeff Scofield

"Jeffrey A. Scofield"
Using GHC 6.0 on Mac OS X (10.2.6), I'm trying to do some timing tests of something that doesn't take very long. So, I want to call a function repeatedly (1000s of times).
No chance you could call it with different parameters each time? Another question is why you want to do this. If you're worried your function will consume too much time in some application, surely profiling will get you better and more accurate information? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

Ketil Z. Malde wrote:
Using GHC 6.0 on Mac OS X (10.2.6), I'm trying to do some timing tests of something that doesn't take very long. So, I want to call a function repeatedly (1000s of times).
No chance you could call it with different parameters each time?
I will try this--thanks very much for the suggestion. (However, the parameters won't have any effect, and I worry that the compiler will figure this out!)
Another question is why you want to do this. If you're worried your function will consume too much time in some application, surely profiling will get you better and more accurate information?
I'm not worried about speed per se, rather I'm trying to validate my (rough) complexity analysis for the function and, if it works, to make some projections for how long it would take to calculate various things. Unfortunately, the time grows fairly fast with n, so I would like to have good measurements for small n where the time is quite small (hundredths of a second per call). In my past life (imperative programmer), the way to do this is to call the function lots of times. (If anyone is interested, I can show my code. What it does is search for perfect numbers by calculating prime factors for all integers up to a chosen maximum. The problem is that the size of the nth perfect number increases amazingly fast with n.) Jeff

"Jeffrey A. Scofield"
I'm not worried about speed per se, rather I'm trying to validate my (rough) complexity analysis for the function and, if it works, to make some projections for how long it would take to calculate various things.
Since you aren't interested in absolute timings, just the algorithmic complexity, then you could try using a less smart compiler (e.g. nhc98) which will not automatically optimise away the repeated calls. Regards, Malcolm

Malcom Wallace wrote:
Since you aren't interested in absolute timings, just the algorithmic complexity, then you could try using a less smart compiler (e.g. nhc98) which will not automatically optimise away the repeated calls.
Thanks very much, I will try this. I'm seriously interested in using Haskell in a commercial venture, and this kind of discussion helps me see what techniques we would have in our toolkit. In the past (20 years of imperative programming) I have occasionally found it useful to be able to get timings for some little function that is in the inner loops of an application. I would be very interested to hear if there are any theoretically pure ways to get timing measurements for a very short-running function. The problem, I think, is that you want to apply the function to the same arguments repeatedly so as not to spend all your time creating arguments. Jeff
participants (3)
-
Jeffrey A. Scofield
-
ketil@ii.uib.no
-
Malcolm Wallace