<html><body><div style="color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:12pt"><div><span><br></span></div><div>Thanks for all the helpful suggestions. </div><div><br></div><div>1. Full agreement on using macros to make things efficient. Ramakrishnan Muthukrishnan pointed me to an excellent paper on Bit-Comprehensions (think set/list comprehensions for bits) in Erlang and we are trying to use similar metaphors for h264 (the bit comprehensions don't directly translate due to context sensitivity of the h264 bit stream), but we will definitely be exploiting the power of macros for efficiency. </div><div><br></div><div>2. Typed racket is also something we will explore. Are there any benchmarks out there for typed v. untyped racket? Also, I'm assuming we can restrict ourselves to typed racket only where it really matters so that we can move back-and-forth between typed and untyped
racket. </div><div><br></div><div>Best,</div><div><br></div><div>A. </div> <div style="font-size: 12pt; font-family: tahoma, 'new york', times, serif; "> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Eli Barzilay <eli@barzilay.org><br> <b><span style="font-weight: bold;">To:</span></b> Anurag Mendhekar <mendhekar@yahoo.com> <br><b><span style="font-weight: bold;">Cc:</span></b> "users@racket-lang.org" <users@racket-lang.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, June 14, 2012 7:26 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [racket] H264 Codec in Racket<br> </font> </div> <br>
More than a week ago, Anurag Mendhekar wrote:<br>> I'm considering writing an H.264 encoder/decoder in Racket. Has<br>> anyone tried such a thing before?<br>> <br>> Codecs require a lot of bit-whacking and the h264 standard is<br>> particularly convoluted. Efficiencies are obtained in C in many<br>> different and usually complex ways. Codec experts usually recommend<br>> starting at C/++ and go to assembly to extract further performance.<br>> <br>> Does any one have thoughts on this? Would someone be interested in<br>> working with me on an open-source project for this? I expect an<br>> exercise like this will also push the Racket implementation to<br>> deliver higher performance, or will establish a proof point about<br>> how good the implementations is.<br><br>You've got a bunch of suggestions -- and many of them focus on<br>traditional aspects of these problems (like using TR to make the code<br>run faster, the
problem of dealing with 32-bit numbers etc). But one<br>thing that wasn't mentioned is that Racket has the advantage of<br>macros, which can often be used in such bit-whacking (nice term)<br>situations. It can be used to easily pre-generate some code that<br>would otherwise be too complicated to write. When you say<br><br> Efficiencies are obtained in C in many different and usually<br> complex ways.<br><br>then my guess is that that's a perfect case for doing these kind of<br>things.<br><br>-- <br> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:<br> http://barzilay.org/ Maze is Life!<br><br><br> </div> </div> </div></body></html>