|
So the MPAA seems to be reaching new heights of stupidity. They would like to sue people that they haven't proven to be guilty.
There's a reason most countries say that you're innocent until you're proven guilty. That's because the cost of falsely accusing someone honest is much higher than the cost of letting a guilty party go free. Honest people tend to be the people that keep society going, and if you start locking them up, well, society starts falling apart. And it's one of those things that self-reinforcing, too: honest people are less likely to be honest if they see that they might get locked up for crimes they didn't commit anyway.
It's all downhill from here.
[ 0 Comments... ]
I recently got around to reading Systemantics (which was recommended by Raymond Chen), and I really liked it. It's pretty short (only 100 pages or so) and written with a very tongue-in-cheek tone. Made me laugh out loud in a couple of places, which not a lot of books do. It basically describes certain "laws" of system behavior, most of which are proved by example (i.e. non-rigorously). Despite that, it does provoke some interesting thoughts about how stuff works (or doesn't work, as the case may be) in general, so it's a good book to read. And it's not a technical book either, so it should appeal to anybody who doesn't take it too seriously. Highly recommended.
[ 1 Comment... ]
Important life lesson* #2: if you get a bunch of green bananas and leave them inside a tightly-closed plastic bag, they tend not to ripen. However, if you take them out of the bag, they will ripen to a yummy yellow pretty fast. Either that, or my timing was just right.
*Not really an important life lesson.
[ 1 Comment... ]
After reading about how governments seem to be becoming ever more oppressive lately, ideas like this are beginning to sound better and better. Waterworld, anyone?
[ 11 Comments... ]
So this post isn't so much about how to go about optimizing code, but rather why it's important to optimize code, even if it doesn't seem like performance matters. The short version is: performance always matters. Sooner or later, any significant piece of code turns into a platform for other code, and basically turns into a library. As a library, it gets used a lot more than it did before, and any performance problems present will get multiplied.
I think that in an ideal world, direct interaction with computers would be pretty limited. They would just sort of exist in the background and do what we needed them to do, without having us to ask them directly. Instead of having to go online and search for flights for your next vacation and find the cheapest fare, you'd just block off two weeks on your calendar and label them "vacation". Some computer somewhere would look at this and go find you some vacation packages you'd be interested in, and maybe even just pick one based on your preferences. However, in order for this to work, the "searching for flights" part of travel websites/databases would have to be turned into a library that can be invoked programmatically lots of times. And that's just for vacations. There might be hundreds of things you do every day that the "background computers" would do travel searches for, just in case you needed it.
As of the last time I checked, searching for flights is, by internet standards, horrendously slow. You actually have to stare at a "please wait" page while they do the search. If it takes 10 seconds for a beefed-up server to search the database for matching flights, there's almost no way that those background computers would be able to finish the millions of travel searches they'd need to do. Not in the current state, anyway. This is where optimization is essential. By bringing down the time required to conduct a flight search, that search can be invoked many more times, enabling it to be used as a building block for something better.
There are probably lots of flaws in the travel example above, but I think the general point stands. Just about any standalone app that requires user interaction can be turned into a library to be invoked by background computers. But in order to do so, that code should be able to complete its task within a reasonable period of time. Of course, that period of time depends on the task, but the faster it can be done, the more useful the code will be as a component of a much larger system.
[ 0 Comments... ]
An interesting article got Slashdotted today. Interesting to me, anyway, since I've been thinking a lot about different means of communication recently and how they all suck in various ways. There are basically four major methods of communication that I use - face-to-face conversations, email, instant messaging, and phone. The article above mentions Twitter as another, but I don't use that. I guess Facebook status messages are similar in concept, but off by an order of magnitude.
Face and phone conversations usually have very low latency; responses are basically instant. IM is next, with average response times of probably a minute or so, and email can be minutes to hours (or with some people, days). IM is the broken one here, because if the IM chat is the only thing you're doing, then minute-long gaps are long times to be twiddling your thumbs. On the other hand, if it's not the only thing you're doing, then minute-long gaps aren't long enough (for me, anyway) to be able to focus on something else. Like the author of that article, I suck at multitasking and much prefer focusing on a single thing at a time, which is impossible in the average IM conversation. If I'm actually trying to be productive, I usually just turn off my IM client altogether. And if I'm chatting on IM, then the odds are pretty good that I'm twiddling my thumbs and staring blankly at the chat window between replies.
Face/phone conversations usually require dedicated time from all participants. Some people can multitask well enough that they can be on the phone while doing other things, but most don't seem to. As a result, I end up wasting less on the phone than I do on IM. Email usually has a high enough latency that it's asynchronous and people don't expect an immediate response. This isn't always true though; for example, you have a BlackBerry and work at RIM, email is considered to be closer to IM. But for the most part, a delay of minutes to hours is par for email.
The other property of communication channels is bandwidth: how easy it is to communicate an idea. Here I find face conversations are the clear winner. When you're talking to somebody in person, not only can you hear their words, but you can see their gestures along with a whole ton of body language that helps you understand exactly what they mean. Even if they mis-speak, it's usually quite easy to auto-correct what they said just based on the momentum of their speech and their gestures. Every other method of communication pales in comparison to face conversation when it comes to bandwidth, but some are worse than others.
I have a pretty lousy phone voice, and so I generally dislike talking on the phone because I often end up having to repeat myself. The other problem is that phone conversations have low latency (see above). This means a response is expected pretty much instantaneously, but you don't have the same amount of information that you do in a face conversation. All that body language gets stripped out and all you're left with is the person's choice of words and intonation. From that data alone, you have to reconstruct the full depth of the message they were trying to convey. Some people can do this easily, but for me it takes time to think about the various possible meanings and choose the right one. Of course, since the response is expected right away, I can't take the time to explore all the meanings and end up having to guess, which often works out poorly.
Email is much better than phone when it comes to bandwidth, because even though you have even less information, you have plenty of time. If you get an email with poorly chosen words or ambiguous tone, you can take a few hours to think about what the person really meant before you reply (and with some of the emails I've received, it actually does take hours before I am able to figure out which missing word or grammatical correction is the key to reconstructing the message). In that respect, it is much better than a phone conversation. IM falls in the middle here. I would consider IM to have higher bandwidth than email simply because the people conversing over IM tend to be roughly in sync since it's an ongoing conversation. Context about the participants moods is lost over email, but is preserved over IM.
It's hard to simply rank the four channels in order of preference, because it also depends on the person I'm communicating with. Some people have horrible typos that make reading emails or IMs from them near impossible. Others tend to drone on and on, making phone and face conversations with them really difficult (although thankfully these people also don't seem to mind if you fall asleep while they're talking). For the vast majority of conversations face conversations seem to be best, and for me, email probably sneaks into second place.
[ 2 Comments... ]
Having to write software for an embedded platform with limited resources means I have to spend a good chunk of time optimizing code. After thinking about it for a while, I've noticed that performance optimizations usually fall into three categories, two of which are good and one of which is bad.
The first good kind of optimization is using or coming up with more efficient data structures and algorithms. If you're doing something which takes O(n^2) time, and you reduce that to O(n) using a different algorithm, that's obviously good. Similarly, using a custom-built data structure instead of patching together one from pre-built hashtables/lists/arrays/etc. can also change the runtime of your algorithm by orders of magnitude. All software developers are probably aware of this kind of optimization, even if they don't necessarily use it. It may require a lot of thought to actually come up with better algorithms and data structures, and in some cases there may be none, but still, this is one well-known avenue for optimization so I'm not going to dwell on it.
When the above optimization doesn't result in enough performance gains, most software developers (and I'm guilty of this too) will start resorting to the bad kind of optimization. The bad kind of optimization is the one where you start "packing" the code and taking shortcuts. One example is changing private instance variables to be more visible (protected, package, public in Java, may vary for your language of choice) and accessing them directly rather than using an accessor method. Another example is (in C++) changing a virtual method to be non-virtual to avoid the vtable lookup when invoking it. Optimizations like these can have an beneficial impact on performance, specially if those methods are invoked lots of times in an inner loop somewhere, but they also have a detrimental impact on code maintainability. (Note: I've seen both of these examples used in practice and can attest to the fact that they did in fact help performance noticeably).
The reason I called this method of optimization "packing" is because I find it conceptually similar to compression. If you take a text file and zip it, you still have the same data, but in a packed format. It is possible to edit the zip file in a binary editor such that you change that data, but it is much harder to do. The same applies to the code - after you do packing optimizations, the code is that much harder to debug and edit. If you need to change a member variable that is directly accessed from a dozen classes, those dozen classes will have to change too, just like how editing a line of text in the zipped file will require you to adjust everything following it, as well as any checksums and header info. It's possible, but it's incredibly error-prone and is always turns out to be a bad idea in the long run.
When Hoare said that premature optimization is the root of all evil, I believe these are the kinds of "small efficiencies" he was talking about. The packing optimizations are acceptable if that code never needs to be modified again. But if it does, then such optimizations are premature and yes, they are the root of all evil. And really, when does code get written that never needs to be modified again? I don't think I've ever come across any code so perfect that it doesn't ever need to change.
The third kind of optimization is the one that requires the most work, but also provides the most benefit. It's the one that most developers don't even consider simply because it's so much work. But if you're really serious about squeezing every ounce of performance out of the code, as well as keeping it maintainable for the long run, it's the only solution that I can think of. This category of optimization involves going down a layer in the software stack. Go down to the code that's running your code, and make it run your code faster. Make the compiler smarter. Make the VM smarter. Make it detect those cases where the vtable lookup isn't needed and optimize them out. Why should you have to do it manually at the expense of code maintainability when the compiler can do it for you? That's what it's there for, after all. The more intelligence you add to those lower layers, the faster your code will run, and without the need for ugly hacks.
The benefits of this approach are obviously many. It speeds up not just your code, but anything else running on top of it too. The techniques you use will likely be reusable and portable in other places. It's also different from the first two kinds of optimization in that you can think of it as simply adding features to the compiler rather than "optimization" in the traditional sense. But it does have an optimizing effect. Going back to the analogy of the zipped text file, the packing method is similar to manually zipping the text file one byte at a time, whereas a smarter compiler is like having a compression engine to do it for you. Since the compression is automated, it's easily repeatable, and far more useful. You can change the original text file/code all you want, and then just re-run the compression engine/compiler on it again to regenerate the binary.
Most of the opposition to using this third method boils down to "it's not worth it". I think that in 99% of the cases, it is worth it. Code that's worth optimizing to this extent will likely be around for a very very long time (just ask those people getting paid millions of dollars to keep 30-year-old mainframes going) and if you add up the benefits over the entire life of the software, it's well worth it. But more on that in another post :)
[ 2 Comments... ]
The Globe and Mail has an article up about how concerns about the US government's snooping is becoming a roadblock to adoption of Google Apps. Thanks to the US government for making part of my predictions true. I still think Google's eventually going to allow entities to store their data locally and use Google's software (either hosted by Google or locally as well) to manipulate it. It was interesting to see them release their AJAX Language API a few days ago (I tried using it to provide a translation option for this website, but it still has a few bugs that need to be worked out first). Like with their other APIs, the code is hosted at Google and you just include it into your web page and invoke it on your data. I imagine a similar setup for Google Apps.
[ Add comment here ] And while we're on the topic of the US government, there's this amusing article about how some government agency is scanning for dirty nukes and picked up a cat with cancer instead. The part that made me slap my forehead (figuratively speaking) was this quote:
Giuliano says the point really is to catch terrorists. He says it's true that the odds of catching one here may be "a billion to one. But despite that, we have caught two."
Way. To. Go. After spending billions and billions of dollars, wrongfully arresting tens, if not hundreds, of people, getting embroiled in a pointless war, and inciting large amounts of useless panic and fear, you managed to catch two real terrorists. I would like to take this opportunity to point out that while almost 3,000 people died as a result of the September 11 attacks, over 200,000 have died since then in traffic fatalities alone.
[ 0 Comments... ]
This article came up in my fishing net of RSS feeds, and I thought it was interesting to see how prevalent this business of satellite campuses is. When UW announced something resembling a plan for a campus in the UAE, I remember thinking it was a pretty strange thing to do. So was that random office in Manhattan, for that matter. But it appears that financial considerations may be (at least in part) to blame, since oil-rich countries in the middle east are practically bleeding money.
[ 1 Comment... ]
Never thought I'd say this, but thank you, Microsoft. (Also thanks to Stockwell for sending me the link, which seems conspicuously absent from the likes of Slashdot. Only CNet seems to have picked it up so far.)
[ 8 Comments... ]
|