Frequently Asked Questions

Why are you designing a new programming language?

Soon, chips will only get "wider", not faster, because of power consumption problems. Already, Sun sells single CPU chips that provide 64 threads of execution. It's easy to use this much parallelism with embarrassingly, obviously parallel problems (like running web servers, or Monte Carlo simulations), but for general computing, programmed by ordinary programmers, using that much parallelism effectively is difficult with today's languages, even the Java Programming Language^TM, which is the best of the bunch.

Fortress aims to make parallelism more tractable in several ways. First, parallelism is the default. This is intended to push tool design, library design, and programmer skills in the direction of parallelism. Second, we're designing the language to be more friendly to parallelism. Side-effects are discouraged because side-effects require synchronization to avoid bugs. Fortress provides transactions, so that programmers are not faced with the task of determining lock orders, or tuning their locking code so that there is enough for correctness, but not so much that performance is impeded. The Fortress looping constructions, together with the library, turns "iteration" inside out; instead of the loop specifying how the data is accessed, the data structures specify how the loop is run, and aggregate data structures are designed to break into large parts that can be effectively scheduled for parallel execution. Fortress also includes features from other languages intended to generally help productivity -- test code and methods, tied to the code under test; contracts that can optionally be checked when the code is run; and properties, that might be too expensive to run, but can be fed to a theorem prover or model checker. In addition, Fortress includes safe-language features like checked array bounds, type checking, and garbage collection that have been proven-useful in Java. Fortress syntax is designed to resemble mathematical syntax as much as possible, so that anyone solving a problem with math in its specification can write a program that can be more easily related to its original specification.

What is Fortress?

Fortress is a new programming language designed for high-performance computing (HPC) with high programmability. In order to explore breakaway approaches to improving programmability, the Fortress design has not been tied to legacy language syntax or semantics; all aspects of HPC language design have been rethought from the ground up. As a result, we are able to support features in Fortress such as transactions, specification of locality, and implicit parallel computation, as integral features built into the core of the language. Features such as the Fortress component system and test framework facilitate program assembly and testing, and enable powerful compiler optimizations across library boundaries. Even the syntax and type system of Fortress are custom-tailored to modern HPC programming, supporting mathematical notation and static checking of properties such as physical units and dimensions, static type checking of multidimensional arrays and matrices, and definitions of domain-specific language syntax in libraries. Moreover, Fortress has been designed with the intent that it be a "growable" language, gracefully supporting the addition of future language features. In fact, much of the Fortress language itself (even the definition of arrays and other basic types) is encoded in libraries atop a relatively small core language.

Is Fortress a language intended only for high-performance computing?

No. Fortress is a general-purpose programming language. Its support for large-scale parallelism and management of data locality, its use of mathematical notation for syntax, and its static checking of units and dimensions (among other things) make it particularly well suited to high-performance computing.

Is Fortress an extension of the Java(TM) programming language? What about Fortran?

Fortress is a new language. Although many of its features are inspired by existing languages, it isn't an extension of any of them. Syntactically, many Fortress expressions closely resemble mathematical notation.

Is Fortress designed to replace the Java programming language?

No. Although Fortress and the Java programming language are both general-purpose programming languages, the design tradeoffs are significantly different. The Java programming language is designed to use a familiar syntax and class system while providing as much portability as possible. As a result, it is well suited for network and embedded programming. In contrast, Fortress uses many novel language features in an attempt to alleviate the tension between modern software engineering principles and high performance computing. Fortress is well suited to programming on massively parallel computers, as well as on smaller systems.

How does Fortress compare to Chapel? How does it compare to X10?

Fortress is one of three languages for high-performance computing developed as part of the DARPA HPCS Program. The others are X10 (from IBM) and Chapel (from Cray). X10 is an extension to the Java(TM) programming language that supports high performance computing with a message-passing-based protocol for thread-to-thread communication. Chapel is a parallel language based on a shared memory model. Fortress differs from both of these languages in several respects. In an attempt to improve programmability for high-performance computing, Fortress syntax emulates mathematical notation as closely as possible. It has a novel type system to better integrate functional and object-oriented programming, it allows for specification of data distribution through the use of distribution" data structures, it supports static checking of physical units and dimensions, it supports embedding of domain-specific language syntax in programs, and it includes a component system to facilitate the process of compiling, linking, and deploying programs.

In what ways does Fortress syntax resemble mathematical notation?

The NAS (NASA Advanced Supercomputing) Conjugate Gradient Parallel Benchmark is a small program used in high-performance computing to evaluate and compare performance of parallel supercomputers. A description of this benchmark can be found at:  http://www.nas.nasa.gov/Resources/Software/npb.html Here is its implementation in Fortress.

Note the use of subscripts and superscripts, the fact that multiplication is represented simply by writing the operands side by side (placing spaces in between them), the rendering of rational expressions, and the use of Unicode symbols for variables and operators.

What support does Fortress provide for parallelism and locality?

Fortress is designed to make parallel programming as painless as possible. Many of the core language constructs in Fortress, including function argument evaluation and for" loops, are parallel by default. Threads can synchronize using atomic code blocks. Fortress supplements this implicit fork-join threading model with explicit futures, and provides programmers with ways to control where particular threads are run and how large objects are laid out in memory.

Where can I download the code?

A preliminary, open source, interpreter implementing a small core of Fortress language features is available here. This interpreter runs on the JVM. To try out the code, you can check out our Subversion repository and follow the build instructions in the included README file. You can also download a pre-build zip file of the Project Fortress distribution, though it is not always up to date. Our intention is to grow this implementation over time, with the help of university partners and other interested third parties. We expect that many parts of this interpreter will be used as components of a complete Fortress compiler, which is our long term goal.

How far along are you?

We have released a series of draft specifications of the language and we have published formal calculi and soundness proofs of several of the core language features. We've presented a demo showing parallel Fortress execution on a number of small programs at Sun Open House 2006 in Menlo Park CA. Look for source code, tutorials, and other supporting materials to be released at:  http://research.sun.com/projects/plrg

See also the ProjectStatus page for information on what Fortess features are implemented and which features you should not yet try.

What platforms will Fortress run on?

Fortress has been designed to run well on a variety of platforms, including supercomputers with large stores of addressable memory, commodity clusters, workstations, etc. Many aspects of the language have been designed to be as portable as possible. Our initial implementation effort targets the JVM.

How do you plan to convince programmers to use your language?

Fortress uses a widely known syntax that has evolved over thousands of years: mathematical notation. It allows programmers to reason in their problem domain without translating entities such as quantities and physical units into unfamiliar abstractions. We expect these features will help to keep the learning curve down for new programmers. We are also soliciting feedback on the language design from HPC programmers, in government, academia, and industry, in order to improve the design and to get more buy-in. But our primary strategy for getting programmers to adopt our language is to design the best language we can. We aren't tying our hands behind our back by attempting to support legacy and obsolete language features.

Why is it difficult to solve (my problem) in Fortress?

If you're running into problems writing a Fortress program, your best first recourse is to  join the language mailing list and ask your question there. It may be that you can't find the library you are looking for, or that there's a different way to do it that is a better fit for the language. We are also building a compendium of examples we'd like to do better.

Does Fortress support some form of static effects tracking to prevent using side effects within parallel constructs?

No. To our knowledge there is no system of static effects tracking that deals gracefully with large shared arrays, the bread and butter of parallel computing. There are systems that attack the problem in a limited way--for example by allowing computations to access only a single array element in an individual parallel computation, or by partitioning an array into disjoint pieces--but Fortress is designed for general-purpose parallel programming.

Will Fortress support nested data parallelism for fine-grained parallelism a la NESL and Haskell NDP?

There is nothing preventing the implementation of such a system within Fortress, and we already have code submitted to provide prefix-style operations for certain Generators. Our goal is to desugar comprehensions in such a way that NESL-style treatment of comprehensions ought to be efficient. We're not specifically implementing NESL or NDP-style arrays at present, though we may do so once we have more of the basic language constructs in place.

Does Fortress support multi-node environments such as clusters and grids, and if so, does it support each node as a separate processing unit?

Fortress was designed with the goal of eventually executing a single program on multiple nodes (such as a cluster or grid), but that support is not presently being developed by the team at Sun. Fortress will generally view each node not as a single processing unit, but as a Region encompassing multiple processing units (the multiple cores on any modern CPU). Our hope is that the Fortress model of computation and load balancing is sufficient not only to run programs on multiple physical machines, but also to permit the resources available to the program to vary dynamically over time.

The Fortress language specification includes a formalization of basic Fortress. Where do I find the sources? Where is the PLT Redex mechanization of the formalization? Where are the up-to-date proofs?

Neither the LaTeX sources of the Fortress language specification nor the PLT Redex implementation of the formalization has been publicly released. The type soundness proof of the Basic Core Fortress was included in the Fortress language specification  version 0.707 but it has not been included in the specification since the language specification version 0.785.

It is my understanding that Fortress has been implemented using the Rats compiler generator. Why was Rats chosen over other competing systems? Does it work well for this project?

Yes, the Fortress parser is implemented by the Rats! parser generator.

Parsing the Fortress syntax is nontrivial due to its support for mathematical syntax and growable syntax. Mathematical syntax is highly ambiguous and growable syntax allows a program itself to define how it is parsed. We have tried several parsing technologies for Fortress: JavaCC (LL(k)), CUP (LALR(1)), a hand-written recursive descent parser, Elkhound (GLR(1)), and finally Rats! (Packrat). Rats! was the first tool that allowed us to parse the entire Fortress syntax. Elkhound was very close to parsing the entire Fortress syntax but it was not scalable enough to parse 64 by 32 arrays, for example.

Rats! has been very useful for us especially thanks to its module system and the nice and diligent developer, Robert Grimm at NYU. However, its error reporting is very limited mostly due to its support for unlimited lookahead. We devised a pre-parser delimiter checker, which checks unmatched delimiters, and a post-parser syntax checker, which checks various syntactic constraints.

What code editors are available for Fortress? (ie render fortress code correctly)

Will the JVM support SIMD at some point? Or will the JVM be the reference backend, with no performance concerns?

Depends, yes, and no.

That is: it depends upon what you mean by "support SIMD". There's at least three ways to interpret that. It could mean exposing SIMD hardware at a pretty low level in the source language; or it could mean, to expose SIMD operations through special library routines; or it could mean, to support SIMD by detecting opportunities to use it with an optimizing compiler. And nowadays, with fancier and fancier GPUs, SIMD itself has a pretty broad range. Running code on GPUs is a bit trickier because (as I understand it) the communication costs to the GPU are non-trivial; the problem to solve, instead of pattern recognition, is where to carve up your computation and ship it to the GPU. And of these, it's unlikely that the hardware will be exposed in a low-level form, but Fortress is an extensible language, so of course it can be added to the library. In the short run, that means going through the JVM, which you might think gets in your way.

There's a crucial step that many people miss here, which is that both fast (wired to hardware) and slow (your code still runs when the hardware is missing) implementations need to be provided. For example, we (Guy) coded up a pure Java implementation of arithmetic with rounding modes; there's also code available that implements unsigned arithmetic and conversions in pure Java. In some future system, either the JVM specially recognizes those library calls and "does the right thing" (just as it does with Math.log and Math.sqrt on many architectures), or perhaps Fortress is targeted to some platform in addition to the JVM, or perhaps it turns out that a JNI-based implementation is good enough. Writing JNI code to glue the JVM to a GPU is probably more practical than using it to target old-style coprocessor SIMD, because the granularity of the interaction with the GPU is a better match for the costs of the JNI round-trip (which often includes memory synchronization).

Your question "will the JVM be the reference backend" is difficult to answer as posed. For a reference platform, the JVM is a superb choice; it's widely available with reliable semantics, it's exactly what you want in a reference platform. But, if you mean today's 1.6 JVM, then the answer is surely "no". The JVM is going to change over time (disclaimer: this is not a statement of Sun policy, but if you look to the past, if you look at  John Rose's blog, you can see that the JVM is cast in stiff putty, not concrete.), perhaps in ways that will remove (or allow workarounds for) some of today's performance concerns. I assume that there will always be a JVM-targeted Fortress compiler -- we work for Sun, the JVM is enormously widespread, and it provides solutions for quite a few tricky runtime issues (classloading, threads, garbage collection) as well as a huge library of useful stuff. It also makes sense, for Sun, for Java users, and for us, to always first ask whether we could solve a performance problem in the JVM if we thought about it a little longer, rather than setting off on our own whenever things got the least bit sticky. Plus (or perhaps, minus), if we decided to roll our own high-performance Fortress-oriented VM (with special knowledge of our type system, work-stealing issues, GC, general threads, plus access to SIMD hardware), we would be busy hacking for years before it ran at all. Very often, it would be much less work to add features to the JVM (plus the discussion and diplomacy tax required to get the rest of the JVM community to buy in to our Great Ideas) or to improve its implementation in clever ways.

There will always be performance concerns, but there are other concerns as well. Just for example, how good are the error messages?

Is there interoperability between Fortress and Java similar to that of Scala and Java?

For example, is it possible to

• implement a Java interface in Fortress and then use it back from Java?
• call Java methods from Fortress?

Insert Your Questions, here