The random ramblings of a French programmer living in Norway...
← Performance Profiling15 years working in videogames →
  I can see the wall out there
Sat 23rd January 2010   
... yes, there is a wall.

We've been told for a while that the wall was here, and that we should prepare for it. Get the equipment ready, get the bodies and mind in good shape, this kind of thing. But well, you know how it works, we tend to wait until the very last moment before we change our habits.

But sometimes changing the habits is not enough. Sometimes you need more than that, you need to find alternatives that works... assuming they actually exist.
Some years ago our friends at Intel and AMD realized that they could not continue indefinitely to give us more power on a single thread processor. They started to create things like hyper-threading, then dual core processors, quad cores, now octo-cores, and so on so forth (not there yet, but they are just on the next corner on the left).

Since programming with multiple execution units is not the most simple thing in the universe - not that it's complex, just that it's easy to get it wrong -, developers have been continuing to do single threaded applications, running the odd thread here and there to give some reactivity to the GUI or to load stuff in the background.

Recently I had to put the hands in a heavily multi-threaded server application. The design of the application is far from excellent, but that's not the point. The point is, the application is buggy, and the tools we have suck so much that finding the bug is like a death march mission.

The bug happens that when a number of users are connected, some particular usage patterns make it to crash. And when it crashes, it's not in the location where the problem was, it crashes because the run-time heap-checker detects that the memory heap is corrupted when some random thread try to perform a memory allocation.

Some people will say that we are using the wrong language, that we should use Askel or Eiffel instead of C++. That's a possibility, sure, and I will consider it the day when Microsoft, Sony or Nintendo will make it possible to run something like that on their consoles. In my universe, if the language and libraries you use are not compatible with some of the platforms you have to develop on, they you don't use them.

Which brings me back to the C++.

Yes C++ sucks in many ways, but the worse is that the ecosystem around C++ sucks even more. The compiler have gotten better and better for a number of years, got better diagnostics, better code generations, we got Visual Assist to help refactoring or simply making it possible to navigate in a large code base, but that's about it. For few years now, the various versions of the compiler chains and associated tools have been stagnating. Things like memory leak/corruption tracking should not come from external libraries (working more or less ok on some platforms/compilers), it should be a native part of the system. Same thing for the deadlocks detection, and threading errors in general.

I was at an Intel presentation in Oslo last year, where the guy was presenting the latest set of tool Intel made to help us poor developers. Frankly that was pathetic - not the fault of the guy -, because these tools are fucking slow. Sure you can use them on a toy program with 30 lines of C++ made to show a problem. But you can't use them on a half a million lines of code program that already takes few minutes to start-up.

And the sad thing is that for what I know, these tools are the best things around. When I look at V-Tune, Boundschecker, Purify, Insure, Glowcode, I see tools designed 15 years ago, that looks like windows 3.1 or 95 applications, with dreaded GUI's, retarded ergonomics, very crash prone behaviors, complicated and unreliable licence managers. They cost a lot, and they suck.

I repeat it, they suck.

Sure, we use them, because it's the best we can find. And every single time we have a problem where we have to use such tools to solve the issue, we count the number of day we waste waiting for the tool to finish parsing, sampling, instrumenting, crashing due to out of memory, crashing due to an unexpected error, not working because the flag A is incompatible with the option B of the program C, so it did not record anything and you have to try again with different settings... which you don't want to do because in the different settings the bug does not appear at all.

We are doomed. Seriously, if Intel, Amd, Microsoft, don't seriously take the problem at hand, and give us some usable tools, perhaps some special hardware/processors/ices combos made specially for software developers, then I don't see how they can expect us to be able to deliver reliable software in any predictable amount of time.

Hear me!
comments powered by Disqus