Code:
Code
While studying the GNU Objective-C runtime, I wondered if it might be possible to address one of the most common complaints leveled at Objective-C: that its dynamic nature makes it too slow to be used for time-critical applications, such as a game engine. The most obvious place to look for this loss of speed is in the messaging code, since unlike traditional object-oriented languages, method calls are not linked to method implementations until runtime.
The use of sparse arrays in the GNU runtime is inspired, particularly when compared to the hacks and workarounds that Apple implemented in order to speed up their hashtable-based implementation. In considering whether or not the runtime could be made faster, I knew I wanted to keep the sparse array idea. I also identified a few places where I thought the runtime library itself might be made more efficient. For example, the GNU runtime builds an entire class hierarchy in order to ensure that +load is run in the correct order -- that is, that the method of a superclass is executed before the method of its subclasses. I thought there might be simpler ways to approach the problem.
Three years later, the result of my studies and tinkering is the Polar Objective-C runtime.
I’ve mentioned before that, of all of the C dialects available, Objective-C appeals most to me from the standpoint of simplicity and elegance. The language isn’t perfect but, prior to version 2.0, I found the syntax to be relatively clean and intuitive, unlike that of C++.
When examining the syntax of the language, particularly the use of bracketed statements to indicate method calls (messaging), it's easy to see that Smalltalk features were imposed on the underlying C syntax rather than being added as a natural evolution of the language -- but I’d guess that this was because the initial "compiler" for Objective-C was something closer to a pre-processor than a full-blown parser. Nevertheless, the syntax does make method calls easy to recognize in long stretches of code; and the ability to "tag" parameters also helps to clarify the purpose and use of each object.
Unfortunately, Objective-C never really caught on as a mainstream language, and Apple seems to have abandoned it in favor of a language with semantics that are closer to C++ (read: uglier, in my opinion). Much of the reluctance to use the language seems to revolve around the idea that Objective-C code can never compete with C and C++ in terms of performance: Objective-C resolves method calls (messages) to their implementations at runtime, while traditional compilers do so at compile time. In general, the former approach is supposed to provide the most flexibility in implementing of a given method, while the latter approach will provide the greatest speed. But does the flexibility offered by Objective-C actually actually penalize code execution times?
For the Apple implementation of the Objective-C runtime, the answer would appear to be "yes" -- at least, this was the case in 2003. But that was more than twenty years ago, and with the traditional Apple runtime. The question is whether the Objective-C runtime implementation presently offered by GCC suffers from the same speed penalty.
Note: This article is a work in progress.
I'm partial to C for its simplicity and power, but I prefer to work in an object-oriented mindset when I write code. I'm no fan of the hot mess is C++, however. So I was quite excited when I found Objective C a few years ago. Although from a syntactical standpoint, the language is clearly an imposition on the underlying C syntax, I think the overall effect is more intuitive and elegant than the Arcane Wizard Scrawl(TM) that C++ has become. I'd hoped to start using Objective C, by way of GCC, as my main programming language -- but their desire to keep pace with Apple's slow destruction of the language ruined those plans.
In an effort to find an alternative, I stumbled across the Portable Object Compiler. The basic syntax is the same as what Apple brought out of NeXT, except that protocols (interfaces) are not supported -- though there are ways to live without this -- and categories have to be implemented in a different fashion, albeit one that makes sense.
Intrigued, I downloaded the bootstrap compiler and compiler sources and...they didn't compile on my Linux box. Continue reading...
Note: I cannot guarantee that any of the links to Microsoft documents which appear in the following article will continue to work, only that they worked when this article was written. Microsoft's documentation pages appear to move around entirely at the whims of madmen, and a link that works today may result in a 404 error tomorrow. Now you know what your favorite search engine is for.
I was recently asked to determine why a group of machines at work were running slowly. The machines in question exist in a shared environment and are used by multiple individuals throughout the course of a given day. There were a few things causing them to malfunction, but one of the more interesting issues I found was that the users were not logging off when they were finished with the machines; instead, they would walk away and the next person would simply hit "Switch User" to log into them. Therefore multiple disconnected user sessions remained in memory, many with programs still running -- and collectively, these abandoned sessions served as an anchor which weighed down the performance of the machines.
...you run into compiler bugs that prevent successfully compiling your library...
While testing some advanced features of the parsing library in preparation for the next step toward building causerie, this is exactly what happened: an obscure bug with the Free Pascal runtime that seems to defy debugging with GDB and which crashes the program every time it runs. (If you're really interested to know, it seems to have something to do with the way that TObject handles memory allocation).
It's proven to be a rather large setback for causerie, but it isn't the end of the world. I was already developing a C interface for the libraries, to make them as portable as possible, and if all else fails I can expand upon that to take the whole thing into C. I'll have more information here soon.
