Now perhaps I'll be stepping into some lines of fire as it seems like this thread is full of them. If I get in anyone's way please kindly hold your shot ;-) That said, video codecs are the kinds of things that usually benefit greatly from vectorization and parallelization right? These are two areas that have been getting concentration recently. I'm not really familiar with all the codecs involved, but it would probably be a great test case if someone could write a video codec (perhaps not H.264 since I recall someone saying it was ridiculously complicated) in C/C++ and in Haskell using all the DPH/parallelization tricks, as a comparison benchmark to improve the performance of the compiled code coming out of GHC. Having two pieces of code that are decently optimized and should do the same thing seems like it would make finding snags in the GHC performance and fixing them that much easier. Also, hunting with your bare hands rather than with a gun is provably more bad-ass ;-) -Ross On Feb 20, 2009, at 6:52 PM, Bulat Ziganshin wrote:
Hello Peter,
Saturday, February 21, 2009, 2:36:15 AM, you wrote:
nothing should stop you from writing video games in Haskell since
video codec isn't video game :)))
but I've worked with people that wrote physics engines in C/C++, and they also had to hand optimize specifically for a certain compiler to get things fast.
that's important signal. if you need to hand-optimize your code even if you use icl to compile it, using haskell will be like hunting with a hand instead of gun
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe