Tim’s Weblog

Archives

D Postmortem

June 22, 2008 – 8:43 am

It’s been about a year and half since I started actively using D — I’ve written (and maintained) a couple of small commercial applications in it, and taken maintainership over a couple of D related open source projects, but most of my experience with the language comes from using it to write my thesis project in — around 30,000 lines of code spread over 100 source files. Not exactly a huge project, but large enough to get a good feel for the language.

First of all the good: the bottom line is, D is a great little language, and I say little because in many ways it’s a lot simpler, and less complicated than any of the other system level object-oriented languages that it competes with (C++). This doesn’t mean that D is any less valuable though — in fact much the opposite. D’s inherent simplicity is by design. It’s pretty clear by looking at the language spec that the idea was to take the best elements of some languages, throw out the rest, and add some of the missing features that we all wish we had (built in strings, optional garbage collection, modern language features, etc).

And by modern language features, this is the kind of stuff I’m talking about: mixins, lambdas, variadic templates, lazy evaluation, delegates, nested functions, anonymous unions, array slicing, contract programming, handy statements. Basically, much of C++0x’s upcoming feature set, and more.

So does D deliver? The answer yes, a resounding yes in fact. In terms of core language design and features, D provides exactly what many of us have been yearning for for years — a system level language that is on par with (or better than) modern scripting languages (such as Python, and Ruby) in terms of development speed, provides the language features we all should have by now, yet compiles to native code that can be as efficient as C++.

The panacea of programming languages? Well… no, not quite. Unfortunately the story doesn’t end there.

The first problem is a major one, and I don’t want to downplay it because as it stands it’s enough of an issue that no development house could even consider D as a prospective language, but fortunately it’s something that should get better over time. The issue: compiler bugs, and plenty of them. Some of them are small, some of them are huge, but there’s enough that they add up to a serious problem.

The bugs I ran into ranged from little things like floating point printing errors, all the way to compiler segfaults. Being that D is so young and the compilers aren’t close to maturity yet, any project complex enough is basically guaranteed to run into problems with either of the existing compilers, and my thesis project was no exception. Fortunately there are two major compilers that use separate optimization paths (a frequent culprit in the official digitalmars compiler) so one at least has a contingency option, but unfortunately, they share the same front-end, so they tend to exhibit some of the same bugs as well.

There’s also some serious performance issues with both compilers. For example, if you look at the assembler output of either of the compilers you can see them doing the same wasteful, redundant memory copies when doing something simple like returning a struct from a function. The only work around to this compiler bug is to do ugly things like return values from functions using by-reference function parameters.

Take a moment to think about the case where you can’t return values from functions — design goes out the window, along with readability and maintainability, not to mention ease of porting to other languages (should the desire arise). It extends further than that though — it means, for example, using custom foreach iterators to do a simple iteration over a collection of stack allocated structs becomes so inefficient that you end up having to put regular for loops in places where they really shouldn’t be.

Basically these “little” compiler issues make it difficult to consistently employ OO design principles, and use all of the nice modern language features that made the language so attractive in the first place. And after discovering these issues, along with their associated workarounds (wasting time discovering that your program’s poor performance is due to the compiler and not your code), you’re basically left with either a slow, inefficient executable, or ugly, unmaintainable code written in a language that was specifically designed to produce clear, concise, elegant code.

It’s a terrible shame to have a few minor problems result in such broad consequences, but these issues are all things that can be fixed, and they’re not nearly as prevalent as this post makes them seem. In fairness, given how new D is, the overall stability and quality of the available compilers is actually quite impressive. The language itself shouldn’t be judged on these compiler issues, but it’s important that people who may be considering adopting D be aware that there are problems with the compilers before forging ahead.

The next big issue isn’t technically related to the language itself, but is still a problem because it’s one of the root causes of much of what’s stopping D from living up to its potential. The heart of the matter is that D is currently going through some growing pains, and project leadership isn’t keeping up with the community.

Right now the D community is split between two incompatible standard libraries (Tango, and Phobos) that offer up different design philosophies, and although the majority of the community uses one library (Tango), it’s not the official standard library. This tends to create confusion for new users, and forces people to adopt one library or another, or library designers to write and maintain two sets of sources — neither being optimal solutions.

To come back to the issue of the compiler bugs — in other projects such a situation might not be as much of an issue, but many of the compiler bugs have been sitting idle in the D bug tracker for many months, and many releases. It appears as though the project is transitioning between a small niche language, to something that might even be getting close to being considered mainstream (D is currently 12th on the programming language popularity list, and still moving up), so it’s understandable that some project leadership issues might crop up along the way.

Regardless of how understandable these growing pains may be, it’s still something that the project maintainers, and the D user community, are going to have to deal with before the language can really take the next step in terms of public acceptance.

There’s also one final problem with the language, or rather, the upcoming D2 language spec, and as big as all the other issues are this is actually the biggest thing that’s keeping me from continuing to use D on future projects. We all know that multi-core systems are the defacto standard these days, and although we’re starting to get a handle on developing tools to help programmers deal with the almost always non-trivial task of writing parallel code, we’ve barely even scratched the surface of what compilers and runtimes can do to help regular joe-six-pack-programmer effectively, and easily, design algorithms that take advantage of today’s processors.

Given the current state of affairs in terms of SMP and distributed development, and that there’s a new revision of the D language in the works, D has a great opportunity to assert its intent to be a player in the upcoming multiprogramming language war. But nothing is in the works. The D team isn’t actively working on providing any inclusion of a modern parallel programming paradigm for D2, which means it will likely be pushed back to some future release of D. This is unfortunate, because I know a great many developers are waiting for tools to help them deal with parallel programming (even if they don’t know they are).

Aside from Erlang and other more obscure functional languages, right now C++ is still one of the best choices around for parallel development. With the resounding success OpenMP has seen in the last few years, and with C++0x on the horizon and the new OpenMP 3 being recently released it looks like C++ is going to continue to be the language of choice for most system level and computationally expensive tasks.

Neither D, nor the upcoming D2 spec, give developers anything beyond raw threading (plus some critical section synchronization and resource locking type mechanisms, along with a controversial const system), but definitely nothing in the way of a modern parallel programming methodology. It’s another unfortunate oversight that takes a language that should be an ultramodern successor to nearly all current languages in its class and puts it years behind C++, and even Fortran (both of which have OpenMP at their disposal), and let’s not even try to make a comparison to other languages like Erlang, JoCaml, Parallel Haskell, and friends.

I really wish I could recommend D as a natural successor to C++, but given all the issues it’s currently facing, I just can’t. It’s simply not there yet, and I fear, given it’s current direction, that it never will be. I still think it’s a great project, and I hope that it works out because I’d like very much to see it succeed, because I think a strong competitor to the multi-paradigm system-level language would be a great boon to the software development and computer science communities.

I’ll definitely keep watching D to see what happens in the future, but I likely won’t be using it for any more projects until they can iron out the compiler stability and efficiency issues, and implement some reasonable multiprogramming method.

By Tim.|Posted in Blog, Programming|

Garbage Collection: The Joy and the Curse

March 6, 2008 – 10:09 am

Everyone knows the diatribe spouted by certain types of programming evangelists that a good garbage collector can give a program higher memory throughput than one under manual memory management (or some equivalent scheme like reference counting) — not only that but manually managing your own memory is pretty much a waste of good development time; no real programmer should have to lower him/herself to dealing with memory. So the appeal of Garbage Collection is pretty obvious. Why would anyone want to do their own memory management when you can let the computer do it for you, and at the same time have it work out to be more efficient?

The thing is, garbage collection isn’t a trivial problem, and it’s certainly not gotten to the point where it’s perfect. Cycles aren’t really an issue for modern conservative style GC’s, not like they are with reference counting schemes, but that’s not to say they don’t still cause a problem. Discovering cycles isn’t free, and generally in a complicated memory setup, even with a good fully modern GC you still end up with weak references / pointers like you would using simple reference counting.

I’m writing this because I’ve recently fallen onto the GC bandwagon as I’ve been using D quite a bit lately. Prior to D my only experience with GC was some time spent with Objective-C, and 4 years of undergrad cursing using Java — but that doesn’t really count ;), and of course a myriad of interpreted languages like Python, PHP, lua, Ruby, etc. I have used the Hans Boehm GC with C and C++ a few times as well, but that was for select cases where the scenarios were a good match for a garbage collected system.

After spending some time really working with a GC language (under situations that are less than an ideal use for a GC system — ie a real-time interactive simulation), I’ve come up with a more rounded opinion of garbage collection, and I thought I ought to share some of the things I’ve discovered that the GC pundits don’t seem to want you to know:

  • Managing memory using GC, in complex data structure situations, where weak ref’s and cyclical dependencies are required (pretty much every largish program every written), can be more complicated and time consuming than manual memory management. If someone tells you GC is all about “new and forget”, while it is true much of the time, you’re still okay to give them a good kidney punch because they’ve never really used GC.
  • Memory leaks are not impossible with GC. It doesn’t take much to fool a GC system into believing memory should be retained when it shouldn’t. This is a continuation of the above point, as it generally only happens in complicated situations, but nevertheless GC is not the panacea-all-hail-the-mother-of-memory-leak-free-programming that the pundits claim it to be. If programmers can’t be trusted to manage their own memory, and GC systems are easy to fool, what makes us think that programmers should be trusted to manage GC memory either?
  • Using GC is slow. “What?! Didn’t you say using GC is more efficient and leads to higher memory throughput?” I did, but I was baiting a bit, because that’s what the propaganda says. Yes using a good, modern, GC leads to higher throughput of memory allocs and frees, this is true. What the GC evangelists don’t remind you of is that most [well designed] programs allocate a bunch of memory, use the same memory over and over again, and then release the memory, so most of a program’s time [usually] isn’t spent allocating and deleting. If your GC app needs to run for a lengthy period of time, chances are the GC’s sweep phase is going to use up more processing power than would have been “wasted” on manually allocating your own memory. Which leads me to the next point.
  • GC makes it easy to fall into bad programming habits. This is a bit subjective, and obviously not true in all cases. But in using a GC language I’ve noticed a tendency in myself to new things that shouldn’t necessarily be newed. Since I don’t have to worry about memory management the odd new here or there doesn’t really matter, right? In a non-GC language I would certainly have created a temporary on the stack rather than allocate memory on the heap (which as we all know is orders of magnitude slower than a stack alloc — and it’s even worse in a GC scenario). Basically think of any Java code you’ve ever seen… how many times have you seen something like: GridCell.setPosition(new Position(x, y)) inside a loop? Ack! Granted this is sort of unavoidable in Java, but especially for people who are still learning, this is a terrible habit to pick up.

So given all of this, it sounds like I’m saying GC is complicated, slow, and makes you dumb. But I’m not. I still hold true to the notion that memory management is something a programmer shouldn’t often have to explicitly deal with. GC is a good thing!

But getting the whole story with garbage collection is important. Like any tool, it’s one of those things that has good use cases and bad, and knowing where and when to use it is key. Fortunately, in D’s case, it’s ridiculously easy to mix manual and GC memory management, so for me, it’s not that much of an issue. I just get sick and tired of hearing the all-pro GC arguments, because in reality GC makes life for a programmer a little bit tougher. And by tougher I mean that more knowledge is required to complete a task.

In the end though it’s definitely worth it. GC might not get rid of memory leaks, and it’s probably going to make your program slightly less efficient, and it might even introduce a few “bad” habits, but in some cases these are reasonable trade offs. If you know a temporary heap allocation is going to get collected right away, and you’re not in a tight loop or something, then why not let the GC do some work for you! If using GC ends up leading to some complicated weak reference scheme, do it manually!

Basically it comes down to the age old adage of: know your tools. Garbage collection can save valuable development time by freeing a programmer from having to deal with the bulk of an application’s memory management, thus leaving more time to focus on those situations where you do need to get dirty with some mallocs and frees (or hopefully on things more interesting than memory management). But, if used improperly, or in the wrong situation, it’s pretty easy for GC to end up causing more problems than it solves.

By Tim.|Posted in Blog, Programming|