So then I gave up on Erlang.
Then I hung out with friends. One of them was pretty frustrated trying to view some HD movies he'd downloaded. The people uploading these movies use a compressed format. The compression doesn't save much space, but most people use it anyhow. But it means that when you watch the movie, the computer needs to think pretty hard to de-compress all of that data. My friend's computer can't always keep up. He's mad at people who use this compressed format. Me, I latched onto something he mentioned in passing--his machine has two CPUs; during decompression one CPU is maxed out, but the other sits idle.
I started noodling around some ideas of how you could parallelize this task, which brought me back to thinking about concurrency. OK, Erlang didn't work. C++ threading... I dunno, there's probably some library I could use that would make C++ threading less painful than banging on my fingers with hammers. But would I be able to find that library before my head exploded?
Twisted Python sounded like it was trying to solve the parallelization problem. I set up a Twisted equivalent of the two "while true" loops. It used more than one CPU! It used... about 120% of a CPU. Nice, but less than the 200% I hoped for. Ah, I was hoping that Twisted had removed Python's "global lock" that I'd heard occasional whines about, but they hadn't. But while reading about this, I learned something...
erl -smp. Erlang uses just one CPU, unless you specifically tell it to use more, by passing the -smp flag. Why isn't that the default? Good grief. Anyhow, the "Getting Started with Erlang" tutorial, which I'd been picking my way through... it didn't mention that little detail. So now I'm back to playing with Erlang. When I'm home and alert. Which isn't often. Anyhow.
What? Oh, right, this is supposed to be a Book Report, not me whining about the sad state of parallel programming for home programmers.)
Top Down Operator Precedence / Douglas Crockford
I'm not sure what Top Down Operator Precedence is, and this essay didn't tell me. It jumped right in and showed me. Too bad I didn't follow it. This essay wasn't very useful to me, except that it made me think I should go read the original paper on Top Down Operator Precedence. Maybe if this essay had included a summary of T.D.O.P., I could have remembered that bp stood for Binding Power instead of base pointer, but I gave up on this muddle.
The Quest for an Accelerated Population Count / Henry S. Warren Jr.
Bit-counting. Oh my yes. I enjoyed this essay, but I hope I don't have much excuse to use its lessons.
Secure Communication / Ashish Gulhati
The story of a project that grew over several iterations. This essay meanders plenty. It was a fun read, but at the end, I hadn't learned anything. I wish he'd chosen one tweak to this program and dove in to more detail. The "Auditing Crypt::GPG" section seems like it would be a good one to expand.
Growing Beautiful Code in BioPerl / Lincoln Stein
When I whine about programmers who write about their own code, this is the kind of thing I'm talking about. Lincoln has his act together. There's some good stuff in this essay. But there were some stretches which seemed to talk about stuff that was kinda obvious--and I am not the smartest coder on the block.
Labels: book, programming