Has Moore’s Law failed software developers?

Nine years ago I embarked on writing SimpleSync. A friend turned me on to Perl and with the help of perl2exe I was able to “compile” the code into a product. My first demo of the software was at a large customer with about 300,000 seats. I pulled out my trusty 75mhz Toshiba Libretto laptop, and fired up the software. In six hours we had managed to sync all of the records over without any issues.

In the years following, we improved the reliability and functionality of the software. Unfortunately with each new version the software got larger and slower. Fortunately we had Moore’s law on our side. Our interpretation of Moore’s Law showed that the speed of computers doubled every 18-24 months. If a client had a slow sync running we would diagnose any issue and… wait… until they updated their hardware. Suddenly SimpleSync was twice as fast! Problem solved. Computer running out of memory No problem! just wait…

About two weeks ago I was on client site and they opted to put some Directory Wizards software onto a virtual machine. I didn’t think twice about it. However they put it on one of their slower hardware boxes that was maxed out with other virtual machines running. It was like the nine year old bloated software had been put back onto the 75mhz Libretto. The light bulb came on. Virtualization in a worse case (or even standard) scenario can actually reverse Moore’s law! Computers could get slower! What is a programmer to do I did the obvious, optimize the code, trim the fat. That gained a decent performance gain but the problem still exists. So I started unwinding things further.

I, like most of my colleagues used a higher level language (Perl, java, .net, python etc) that made reading/writing/debugging code worlds easier than most of the older languages. All of this ease comes at a cost.. performance. Each of these interpreted languages compiles into a byte-code. Which is a generalized machine language. When the byte-code is run, an interpreter reads the byte-code and then executes everything at the machine level. Worse yet the machine level is virtual so it has to go through another level of interpretation before it really gets executed. The code had been smothered in so many layers of overhead that you needed faster machines just to run later versions of the code. Yes I know that byte-code interpreters have been optimized but you just can’t match machine code, the overhead layer is still there. Yes I know that new CPUs have instruction sets for virtualization but it’s still overhead.

I decided to hearken back to the days of yore. I learned C in college and hated it. It was extremely technical and EVERYTHING had to be done manually to get anything accomplished. So I started playing with some code to see what a dozen years of experience could do to take the edge of of my hatred. I was surprised! It all came back and I was up and writing code in no time. So I decided to take one of our basic utilities (RootDSE) and see if I could write it in C. Here are my observations:

Code size.

The support DLL’s for LDAP and SSL are pretty much the same size. One nice thing about Perl was that you could reference DLL’s. The shocking part was the executable size. The old was 845k the new code is 19k.

Speed

This was kinda tough to determine. I was expecting a gain measured in percentages. Instead it was measured in multipliers. (Think 100x). Even with SSL connections turned on there was no noticeable slow down in execution.

Portability

I am a Linux geek at heart but it’s the Microsoft ecosystem that pays the bills. I managed to find MinGW which is a compiler that acts like gcc but compiles natively onto the Windows 32 bit platform. Yes I know it’s 32bit code. Am I worried No. The only restriction is that the software cannot access more than roughly 4gb of memory due to addressing limitations. If I exceed that size, go ahead and shoot me now. The upside is that the code and libraries should work on anything that runs gcc (Linux, BSD, Solaris etc).

Following these revelations, I have embarked on porting our existing Perl code to C. I do expect this will take quite a while, possibly having something production ready by this time next year. We are planning on releasing a new product and since development is in it’s infancy, we’ll probably attempt it in C first.

Both SimpleSync and Profiler will continue on it’s current course until this new stuff is mature. So come back and visit the blog from time to time and I’ll try and keep everyone up to date.