Thanks much! On Sat, Jan 29, 2011 at 12:01 PM, Daniel Fischer <[email protected]> wrote: > On Saturday 29 January 2011 17:29:02, Edward Amsden wrote: >> (Note that the function produced by newSinWave is the one actually >> registered as a callback: >> >> newSinWave :: Int -> Float -> IO (CFloat -> IO CFloat) >> newSinWave sampleRate freq = >> do ioref <- newIORef (0::Integer) >> let multiplier = 2 * pi * freq / >> (fromIntegral sampleRate) >> >> return (\_ -> {-# SCC "sinWave" #-} >> do t <- readIORef ioref >> modifyIORef ioref (+1) >> return $ fromRational $ >> toRational $ > > fromRational . toRational is a big no-no here. It will still be slow when > the new implementation makes it into base, but currently it's > slooooooooooooow. > If you replace it with realToFrac and compile with optimisations, it should > be rewritten to a no-op.
And suddenly I get a very reasonable 3% cpu load when I use realToFrac. Thanks! >> I profiled this since when my program registered with the jack server >> and started taking callbacks, it was using about 75% cpu >> (in contrast, the echo program included with the jack package uses >> less than 2%). The following two lines are of concern to me: >> >> "total alloc = 3,040,397,164 bytes (excludes profiling overheads)" >> My program uses 3GB of virtual memory over a 15 second run? > > Sequentially. With 44100 calls per second, you'd have 661500 calls. > Each call to toRational allocates several Integers, the calls to > fromRational even more. I wouldn't expect it to be 4k per wave call, but > see what figures you get with realToFrac instead of fromRational . > toRational. And with realToFrac and -O3, 58MB total allocation instead. Thanks for clearing that up. -- Edward Amsden Undergraduate Computer Science Rochester Institute of Technology www.edwardamsden.com _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
