Fortress is a new parallel programming language developed at Sun and maintained through an open source community driven initiative. It is designed with implicit parallelism in mind, and with transactional memory in place of standard locks.

The version 1.0 has been released, and both the runtime system and the compiler are out. It seems these are currently running on top of JVM. This somewhat limits the usefulness of the language to mere experimentations, especially in the context of parallel embedded processors, network processors and GPUs. There are some interesting features, like for e.g. ‘for loops’ are executed in parallel by default, and explicit sequential code needs to be coded through atomic transactions. The syntax is geared towards mathematical notations and may be well welcomed by some, especially for numerical calculations. It does not feel Fortress is well suited for general application developers though.

Even with the latest and greatest programming languages, the trend is clear: virtual execution environments are here to stay, and the way we work with operating systems and compilers (ie. source code directly compiled into machine code executables) may soon be a feature of the past, as intermediate languages and representations are being used to provide an additional layer of separation between the actual executed machine code and the programmer. Smart scheduling and runtime optimisations pushed by other companies (like RapidMind) and GPU vendors are making their way into the mainstream and HPC niches, too.

There is lots of space to be explored, and the problems (such as explicit vs implicit parallelism, local vs remote data/computation, memory management and garbage collection, scheduling, grid-like computing, OS, etc) are piling up, instead of being quickly resolved. I speculate that virtual parallel execution environments (VPEEs) and intermediate representations for programs are inevitable progression from the current application model. But, with the advent of more powerful VPEEs there is a tension with the traditional OS design. I think VPEEs will soon replace OS in certain areas completely, pushing the traditional OS-based model into a retro niche. The existing widespread VMs such as JVM and CIL were not thought through carefully enough with parallel processing in mind (I mean even without proper runtime support for dynamic scheduling and the like, it would be good to work with some already established single representation). This leaves a question open: will we see a converging, new single VPEE intermediate format or rather many domain-specific representations in use?

Different companies are attacking the problem on different fronts. (I’ll write more about it later…)

Leave a Reply

Your email address will not be published. Required fields are marked *