Am 14.04.2014 02:49, schrieb Evan Laforge: > I know the question isn't for me, but I do the same kind of stuff and > the gc isn't a problem for me because latency is not a problem. I > think only time latency is relevant is when you want external input to > immediately have a reaction. So basically only if you're creating a > physical performance instrument and want that ear-to-hand feedback > cycle.
right > I'm guessing livecoding doesn't care that much, because while > you want your change to be reflected soon, it's not critical that it > happen within 4ms of your hitting enter. It's probably going to wait > until the next beat or cycle anyway. Yes, for our live sequencer we also accept a latency of 0.1 seconds. > Henning Thielemann's synthesizer work would care about GC though, > because he's making a real time instrument. He can speak for himself, > but I seem to recall he either is very careful to get allocation out > of the core loop, or he compiles down to allocation-free code via LLVM > or something. But I'm guessing that's more for performance on the > synthesis side than latency. Right, I am using LLVM mainly for increasing performance. Keeping allocations out of the core loop using LLVM would be nice, but there is still a lot of Haskell code involved in that loop. This becomes a problem with short buffers, like the standard buffer of JACK containing only 64 samples, i.e. ~1ms at 48000. > All that said, I think if you don't allocate unreasonable amounts, > even major GCs are pretty fast. I wouldn't worry about it for soft > real time like music. You might have to spend some time with the > profiler and threadscope to work out your lag/drag, is all. My early problems with the garbage collector were space leaks. The more memory the GC has to process the slower it becomes. I used lazy lists and it was very easy to produce space leaks and it was very hard to get rid of them. Since I switched to causal arrows these problems have gone. -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/4Nuakfn9O1M2c86wRVJNmW To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
