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.zigans...@gmail.com
_______________________________________________
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
