Why not use bytes? Also, if the algorithms are parallel, you might consider using futures.
Robby On Thu, Jun 7, 2012 at 4:25 PM, Neil Toronto <neil.toro...@gmail.com> wrote: > On 06/06/2012 03:21 PM, Anurag Mendhekar wrote: >> >> >> I'm considering writing an H.264 encoder/decoder in Racket. Has anyone >> tried such a thing before? >> >> Codecs require a lot of bit-whacking and the h264 standard is >> particularly convoluted. Efficiencies are obtained in C in many >> different and usually complex ways. Codec experts usually recommend >> starting at C/++ and go to assembly to extract further performance. > > > The best way to get good performance currently is to write in Typed Racket > and let its optimizer convert checked code to unchecked code. For example, > it'll replace `fxand' with `unsafe-fxand'. Use the Performance Report tool > to find out exactly how the optimizer transforms your code and get > suggestions for speed improvements. > > You won't be able to operate on bytes directly, so you'll have to use > fixnums. You'll only be able to operate on 3 bytes at a time on 32-bit > platforms, or 7 bytes at a time on 64-bit platforms. (Racket avoids > allocating space for fixnums by encoding them in a pointer with a type tag, > which uses up a few bits.) If the algorithm allows operating on more bytes > at a time, try shoving them all into an integer, which can be any bit width, > and use integer bitwise ops like `bitwise-and'. > > Neil ⊥ > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
