Meta-engineering

If you haven't already, I recommend you read these essays by Jack Reeves: http://www.developerdotstar.com/mag/articles/reeves_design_main.html They're not long, and the first essay contains most of the points; the others merely re-inforce the viewpoint. Jack Reeves' central thesis, in my opinion, is that the compiler is the thing which builds software, and is the equivalent of the whole manufacturing process in industry. And if the compiler is the thing which builds, then the source code is the design for the thing to be built. That isn't to say that there is no need for any more design than just the source code, simply that software "engineering" is more design-intensive than probably any other industry, since building software is so cheap (compilers do all the gruntwork). If you accept this thesis, I think you're forced to question the commonly posited parallels between software engineering and real engineering. When people talk about bringing engineering discipline to software architecture, what does that really mean? What does it mean to engineer designing? To engineer engineering?

On multi-core CPUs in the x86+ world

I believe that we're going to see a performance plateau with processors and raw CPU power for the next 5 years or so. The only way CPU manufacturers are going to get more *OPS in the future is with many cores, and that's going to require either slower or the same kind of speeds (GHz-wise) as things are today. To get programs to run faster under these circumstances you need some kind of explicitly parallel programming. We haven't seen the right level of parallelism yet, IMHO. Unix started out with process-level parallelism, but it looks like thread-level paralellism has beaten it, even though it is much more prone to programmer errors. On the other end of the scale, EPIC architectures like Itanium haven't been able to outcompete older architectures like x86 because the explicitly parallel can be made implicit with clever run-time analysis of code. Intel (and, of course, AMD) are their own worst enemy on the Itanium front. All the CPU h/w prediction etc. removes the benefit of the clever compiler needed for EPIC. Maybe some kind of middle ground can be reached between the two. Itanium instructions work in triples, and you can effectively view the instruction set as programming three processors working in parallel but with the same register set. This is close (but not quite the same) to what's going to be required to efficiently program multi-core CPUs, beyond simple SMP-style thread-level parallelism. Maybe we need some kind of language which has its concurrency built in (something sort of akin to Concurrent Pascal, but much more up to date), or has no data to share and can be decomposed and analyzed with complete information via lambda calculus. I'm thinking of the functional languages, like ML (consider F# that MS Research is working on), or Haskell. With a functional language, different cores can work on different branches of the overall graph, and resolve them independently, before they're tied together later on. It's hard to see the kind of mindset changes required for this kind of thinking in software development happening very quickly, though. We'll see. Interesting times.

First Post

My name is Barry Kelly, and I'm a software engineer at Avaeon Solutions Ltd, a software company focussing on financial services, in Galway, Ireland. I work chiefly in C# and software architectural design on an R&D project. Of course, nothing in this blog should be taken as reflecting the opinions of my employer.