Sunday, May 24, 2009

No need for bare metal speed?

Yesterday I saw a comment in a performance thread where someone stated that we don't need the "bare metal" speed we get with languages like C, C++, and the D programming language. I personally disagree. How many applications do you use that aren't written in some variation of C or C++? Probably not a lot. Why? Well, wouldn't you want the best possible performance when you're compressing files or working with large images?

There are two factors with performance: actual computational speed (processor-dependent) and resource usage. This person may have been focused on the first and is accurate to a degree, however, would you want to use a spreadsheet written in Python? Perhaps a browser written in Ruby? I'm guessing the answer is no, you don't. I'm sure there are power users of spreadsheets that already complain about performance, so why use a slower language? As for browsers, how many of you already complain that some sites are too slow? Imagine if your browser slowed them down even more? Personally, I'd rather have the software take full advantage of the CPU to make the experience as seamless as possible.

As for the second factor, resource usage, if you've followed several of my recent posts, you'll know exactly what I'm talking about. When you can reduce the amount of memory you use by a factor of 10, that's a very good thing. This is, I think, the more important aspect of those three languages vs. many others. Imagine if your office software used more memory...let's say 3 times more memory. On my current linux system, OpenOffice.org currently take up about 20MB of memory with a small document open. Multiply by three, now that's 60MB. Granted, thats only a small document. Imagine if you're talking MS Office with Outlook open plus several larger documents (50 pages). That's going to put a nice hurt on your memory usage.

Now, so far I have written this from the perspective of normal user applications, not specialized applications. Would you want to have a firewall programmed in Perl? Granted, you could probably do some cool things with it, but it's not exactly the most efficient language in the world. How about embedded systems in Java? Here's to hoping you can afford enough memory as some of these systems are very limited. Could you imagine doing something truly intense, like weather forcasting, in Ruby?

All in all, I think that guy was very wrong. We do need languages that are very efficient. Some things really do need as much performance as you can get out of them. If not, they won't be able to do their job as fast as needed and people are going to not want them. Granted, they may not be the most efficient for programming, but I think that's something that can be worked on as we get better libraries. For example, D has many built-in features that are very powerful and can reduce the amount of code you write.

Of course, this is coming from the person who will most likely be writing more code in D on a per-method/function basis as I'm trying to get into good habits using the language, like unit tests and design by contract, the latter of which I'm not doing so well with.

Labels: , , , , , , ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home