[Haskell-cafe] An interesting toy
Greetings. I have something which you might find mildly interesting. (Please don't attempt the following unless you have some serious CPU power available, and several hundred MB of hard drive space free.) darcs get http://www.orphi.me.uk/darcs/Chaos cd Chaos ghc -O2 --make System1 ./System1 On my super-hyper-monster machine, the program takes an entire 15 minutes to run to completion. When it's done, you should have 500 images sitting in front of you. (They're in PPM format - hence the several hundred MB of disk space!) The images are the frames that make up an animation; if you can find a way to "play" this animation, you'll be treated to a truely psychedelic light show! (If not then you'll just have to admire them one at a time. The first few dozen frames are quite boring by the way...) If you want to, you can change the image size. For example, "./System1 800" will render at 800x800 pixels instead of the default 200x200. (Be prepaired for big slowdowns!) What is it? Well, it's a physical simulation of a "chaos pendulum". That is, a magnetic pendulum suspended over a set of magnets. The pendulum would just swing back and forth, but the magnets perturb its path in complex and unpredictable ways. However, rather than simulate just 1 pendulum, the program simulates 40,000 of them, all at once! For each pixel, a pendulum is initialised with a velocity of zero and an initial position corresponding to the pixel coordinates. As the pendulums swing, each pixel is coloured according to the proximity of the corresponding pendulum to the tree magnets. Help requested... Can anybody tell me how to make the program go faster? I already replaced all the lists with IOUArrays, which resulted in big, big speedups (and a large decrease in memory usage). But I don't know how to make it go any faster. I find it worrying that the process of converting pendulum positions to colours appears to take significantly longer than the much more complex task of performing the numerical integration to discover the new pendulum positions. Indeed, using GHC's profiling tools indicates that the most time is spent executing the function "quant8". This function is defined as: quant8 :: Double - Word8 quant8 = floor . (0xFF *) I can't begin to imagine how this can be the most compute-intensive part of the program when I've got all sorts of heavy metal maths going on with the numerical integration and so forth...! Anyway, if anybody can tell me how to make it run faster, I'd be most appriciative! Also, is there an easy way to make the program use both of the CPUs in my PC? (Given that the program maps two functions over two big IOUArrays...) Finally, if anybody has any random comments about the [lack of] qualify in my source code, feel free... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
Sounds like a neat program. I'm on a laptop right now but i'll check it out later. The reason I am mailling is because you can use mencoder to convert a stream of image files into a video file. http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-images.html --ryan On 5/5/07, Andrew Coppin [EMAIL PROTECTED] wrote: Greetings. I have something which you might find mildly interesting. (Please don't attempt the following unless you have some serious CPU power available, and several hundred MB of hard drive space free.) darcs get http://www.orphi.me.uk/darcs/Chaos cd Chaos ghc -O2 --make System1 ./System1 On my super-hyper-monster machine, the program takes an entire 15 minutes to run to completion. When it's done, you should have 500 images sitting in front of you. (They're in PPM format - hence the several hundred MB of disk space!) The images are the frames that make up an animation; if you can find a way to play this animation, you'll be treated to a truely psychedelic light show! (If not then you'll just have to admire them one at a time. The first few dozen frames are quite boring by the way...) If you want to, you can change the image size. For example, ./System1 800 will render at 800x800 pixels instead of the default 200x200. (Be prepaired for *big* slowdowns!) *What is it?* Well, it's a physical simulation of a chaos pendulum. That is, a magnetic pendulum suspended over a set of magnets. The pendulum would just swing back and forth, but the magnets perturb its path in complex and unpredictable ways. However, rather than simulate just 1 pendulum, the program simulates 40,000 of them, all at once! For each pixel, a pendulum is initialised with a velocity of zero and an initial position corresponding to the pixel coordinates. As the pendulums swing, each pixel is coloured according to the proximity of the corresponding pendulum to the tree magnets. *Help requested...* Can anybody tell me how to make the program go faster? I already replaced all the lists with IOUArrays, which resulted in big, big speedups (and a large decrease in memory usage). But I don't know how to make it go any faster. I find it worrying that the process of converting pendulum positions to colours appears to take significantly longer than the much more complex task of performing the numerical integration to discover the new pendulum positions. Indeed, using GHC's profiling tools indicates that the most time is spent executing the function quant8. This function is defined as: quant8 :: Double - Word8 quant8 = floor . (0xFF *) I can't begin to *imagine* how *this* can be the most compute-intensive part of the program when I've got all sorts of heavy metal maths going on with the numerical integration and so forth...! Anyway, if anybody can tell me how to make it run faster, I'd be most appriciative! Also, is there an easy way to make the program use *both* of the CPUs in my PC? (Given that the program maps two functions over two big IOUArrays...) Finally, if anybody has any random comments about the [lack of] qualify in my source code, feel free... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
Ryan Dickie wrote: Sounds like a neat program. I'm on a laptop right now but i'll check it out later. The reason I am mailling is because you can use mencoder to convert a stream of image files into a video file. Indeed, it is pretty neat. I'd post an image, but I'm not sure whether the other people on this list would appriciate a binary attachment. I'm hoping to make a DVD of various simulations - but that's kind of difficult when rendering full-size animations takes many hours! _ Hence the request for optimisation help... ;-) Mencoder works on Linux, IrfanView + VirtualDub does it nicely on Windoze, I'm sure MacOS has something that can stitch PPM images together too. Use whatever you have on your platform. :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
On Sat, May 05, 2007 at 09:17:50PM +0100, Andrew Coppin wrote: Ryan Dickie wrote: Sounds like a neat program. I'm on a laptop right now but i'll check it out later. The reason I am mailling is because you can use mencoder to convert a stream of image files into a video file. Indeed, it is pretty neat. I'd post an image, but I'm not sure whether the other people on this list would appriciate a binary attachment. I'm AFAIK, nobody cares about binaryness per se. It's merely the fact that images tend to be rather large... Is it =50kb? (typical maximum size of a 1-line patch that has been bloated by darcs' ultra low density context format) hoping to make a DVD of various simulations - but that's kind of difficult when rendering full-size animations takes many hours! _ Hence the request for optimisation help... ;-) Mencoder works on Linux, IrfanView + VirtualDub does it nicely on Windoze, I'm sure MacOS has something that can stitch PPM images together too. Use whatever you have on your platform. :-D I've had success with ffmpeg years ago (linux) Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
Andrew Coppin wrote: Greetings. I have something which you might find mildly interesting. (Please don't attempt the following unless you have some serious CPU power available, and several hundred MB of hard drive space free.) darcs get http://www.orphi.me.uk/darcs/Chaos cd Chaos ghc -O2 --make System1 ./System1 On my super-hyper-monster machine, the program takes an entire 15 minutes to run to completion. When it's done, you should have 500 images sitting in front of you. (They're in PPM format - hence the several hundred MB of disk space!) The images are the frames that make up an animation; if you can find a way to play this animation, you'll be treated to a truely psychedelic light show! (If not then you'll just have to admire them one at a time. The first few dozen frames are quite boring by the way...) If you want to, you can change the image size. For example, ./System1 800 will render at 800x800 pixels instead of the default 200x200. (Be prepaired for /big/ slowdowns!) *What is it?* Well, it's a physical simulation of a chaos pendulum. That is, a magnetic pendulum suspended over a set of magnets. The pendulum would just swing back and forth, but the magnets perturb its path in complex and unpredictable ways. However, rather than simulate just 1 pendulum, the program simulates 40,000 of them, all at once! For each pixel, a pendulum is initialised with a velocity of zero and an initial position corresponding to the pixel coordinates. As the pendulums swing, each pixel is coloured according to the proximity of the corresponding pendulum to the tree magnets. *Help requested...* Can anybody tell me how to make the program go faster? I already replaced all the lists with IOUArrays, which resulted in big, big speedups (and a large decrease in memory usage). But I don't know how to make it go any faster. I find it worrying that the process of converting pendulum positions to colours appears to take significantly longer than the much more complex task of performing the numerical integration to discover the new pendulum positions. Indeed, using GHC's profiling tools indicates that the most time is spent executing the function quant8. This function is defined as: quant8 :: Double - Word8 quant8 = floor . (0xFF *) I can't begin to /imagine/ how /this/ can be the most compute-intensive part of the program when I've got all sorts of heavy metal maths going on with the numerical integration and so forth...! Anyway, if anybody can tell me how to make it run faster, I'd be most appriciative! Also, is there an easy way to make the program use /both/ of the CPUs in my PC? (Given that the program maps two functions over two big IOUArrays...) Finally, if anybody has any random comments about the [lack of] qualify in my source code, feel free... Try adding strictness annotations to all the components of all your data structures (i.e. put a ! before the type). Not all of the need it, but I doubt any need to be lazy either. Probably the reason quant8 seems to be taking so much time is that it is where a lot of stuff finally gets forced. Certainly, for things that are primitive like Colour and Vector you want the components to be strict, in general. I did this for the program and ran System1 100 and it took maybe a couple of minutes, it seemed to be going at a decent clip. 200x200 should take 4 times longer, I assume, and I still don't see that taking 15 minutes. This is on a laptop running on a Mobile AMD Sempron 3500+. Also, you have many many superfluous parentheses and use a different naming convention from representative Haskell code (namely camelCase). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
On Sat, May 05, 2007 at 03:33:03PM -0500, Derek Elkins wrote: Try adding strictness annotations to all the components of all your data structures (i.e. put a ! before the type). Not all of the need it, but I doubt any need to be lazy either. Probably the reason quant8 seems to be taking so much time is that it is where a lot of stuff finally gets forced. Certainly, for things that are primitive like Colour and Vector you want the components to be strict, in general. (In theory at least) That would not be an issue at all - the GHC profiler uses lexical, *not dynamic*, call stacks. I did this for the program and ran System1 100 and it took maybe a couple of minutes, it seemed to be going at a decent clip. 200x200 should take 4 times longer, I assume, and I still don't see that taking 15 minutes. This is on a laptop running on a Mobile AMD Sempron 3500+. Also, you have many many superfluous parentheses and use a different naming convention from representative Haskell code (namely camelCase). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
Try adding strictness annotations to all the components of all your data structures (i.e. put a ! before the type). Not all of the need it, but I doubt any need to be lazy either. Probably the reason quant8 seems to be taking so much time is that it is where a lot of stuff finally gets forced. Certainly, for things that are primitive like Colour and Vector you want the components to be strict, in general. Yes, originally the profile was showing quant8 taking something absurd like 80% of the CPU time. When I changed the framebuffer to an IOUArray, the time spent in quant8 dropped *drastically*. (Because now the framebuffer is strict, and that's forcing the evaluation sooner.) I could certainly try making vectors, colours and arrays strict and see if that does something... (Thinking about it, the colour computation has a square root in it, and I bet that doesn't get forced until it hits quant8... Square root is an expensive operation on currentl hardware isn't it?) Also, you have many many superfluous parentheses and use a different naming convention from representative Haskell code (namely camelCase). This is a pet hate of mine. NamesLikeThis are fine. names_like_this are fine too. But for the love of God, namesLikeThis just looks stupid and annoying! So I generally use camel case for stuff which has to start uppercase, and underscores for stuff that has to start lowercase. It's a system, and it works. Unfortunately it's not the standard convention in Haskell. (And I doubt I will convince anybody to change it...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An interesting toy
Try adding strictness annotations to all the components of all your data structures (i.e. put a ! before the type). Not all of the need it, but I doubt any need to be lazy either. Probably the reason quant8 seems to be taking so much time is that it is where a lot of stuff finally gets forced. Certainly, for things that are primitive like Colour and Vector you want the components to be strict, in general. I just did that. Gives a few percent speed increase. (Turns out on my machine System1 with default options actually takes 5 minutes, not 15. And with the extra strictness, it completes about 40 seconds faster. So not a vast speedup - but worth having!) Also tried playing with GHC options. I found the following: -fexcess-precision: No measurable effect. -funbox-strict-fields: Roughly 40 seconds faster again. -fno-state-hack: Makes the program somewhat *slower*. -funfolding-update-in-place: No measurable effect. Hmm, I suppose if I get *really* desperate, I could always try compiling with GHC 6.6.1 instead of 6.6... ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
