X10 is a strongly typed, concurrent, imperative, object-oriented programming language designed for productivity and performance on modern multi-core and clustered architectures. X10 augments the familiar class-based object-oriented programming model with constructs to support execution across multiple address spaces, including constructs for a global object model, asynchrony and atomicity.

X10 is a language designed to support programming at scale in the multicore era.

X10 is an APGAS language (Asynchronous Partitioned Global Address Space), much like Fortress, Chapel, and UPC.

X10 has been under developed as a research project at the IBM T. J. Watson Research Center since 2004, in collaboration with academic partners. The X10 effort is part of the IBM PERCS project in the DARPA program on High Productivity Computer Systems.

"X10" is meant to represent a "ten-times productivity boost."

Oops. C'est la vie. Next question, please.

X10 is especially good at distributing your application over a cluster of distributed memory machines. In particular, with X10, there is a natural migration path from a single-threaded prototype, to a version that uses multiple cores on an SMP, to a distributed memory implementation that runs across a cluster of SMPs.

Although the basic language specification is stable, X10 is in active development, so coding to X10 is still a bit of a moving target.  Notable current gaps include library support, IDE and compiler performance, and runtime performance of certain X10 idioms. Of course, we are actively working on all these issues.

X10 is released under the Eclipse Public License, v1.0.

Nothing. X10 is released under the Eclipse Public License, v1.0.

Broadly speaking, X10 should be available on most platforms that have either (1) a Java JVM or (2) a C++ compiler and a Unix-like environment. See the latest X10 Release page for the list of pre-built binary platform-specific releases.

For the moment, X10 is primarily suitable as a research vehicle, for education, and for developers willing to experiment with an emerging language.  Although fairly mature and stable for a research system, X10 is not yet a production-level programming language.

X10 does not yet ship in any IBM products. There are efforts underway to develop X10-based application frameworks and middleware that are intended for eventual production use.

There are a number of collaborators exploring X10, adding to the language, testing it, developing courses for it, writing applications in it, and providing libraries and patterns.  For more details see the X10 Community sections in the menu above.

X10 is a programming language, while Eclipse is often used to build integrated programming environments (IDEs) for programming languages, most notably Java. There is an Eclipse-based IDE for X10 called X10DT.

The X10 project uses JIRA for issue tracking. To report a bug or request an enhancement or new feature in X10 please first check to see if an entry already exists in JIRA. If it doesn't please create a new one. The more details you have in the bug report, the easier it will be for us to reproduce the problem and get it fixed.

We welcome contributions from the community! All contributions will be licensed under the Eclipse Public License and must be accompanied by a Contributor's License Agreement. See Contributing to X10 for details on the process.

Please see Performance Tuning for advice on how to get the best performance out of your X10 application.

There is a prototype debugger available for X10 2.2.  It does not support X10 2.3 or later.  See the X10 Debugger page for more information.

Yes. X10 support classes, interfaces, and inheritance, much like Java or Scala.

Like functional languages, X10 support first-class functions and closures, and encourages using immutable state. Unlike most functional languages, most X10 programs will feature some important mutable state. For this reason, X10 would not usually be called a functional language.

X10 is a higher level programming model than MPI. In general, X10 code should be much more concise than the equivalent MPI. There are at least two major philosophical differences between the MPI programming model and X10: the control flow, and the memory model.

The MPI control flow model is SPMD (Single-Program Multiple Data): the program begins with a single thread of control in each process. In contrast, an X10 program begins with a single thread of control in the root place, and an X10 program spawns more threads of control across places using async and at.

The MPI memory model is a completely distributed memory model. MPI processes communicate via message-passing. There is no shared global address space in MPI, so user code must manage the mappings between local address spaces in different processes. In contrast, X10 supports a global shared address space. While an X10 activity can only directly access memory in the local Place (address space), it can name a location in a remote place, and the system maintains the mapping between the global address space and each local address space.

The syntax for X10 allows programmers to write code where types can be elided in many cases, and the compiler automatically infers the correct types instead. It is difficult to support this with the C/C++/Java style syntax, while still preserving desirable syntactic properties (e.g. variables must be defined before use).

We're working on a couple. The most up-to-date document is A Brief Introduction to X10.  Helping us to develop a more comprehensive overview would be greatly appreciated!

No, but we would encourage any community effort in this direction.

Some small examples are included in every X10 release.  You can find information about larger benchmarks from the X10 release page as well.

Yes, there is an Eclipse-based IDE for X10 called X10DT.  Find out more about installing X10DT.

The X10 compiler uses the LPG parser generator, the Polyglot compiler framework, and WALA. The X10DT builds on the Eclipse framework.

Much of the X10 runtime is implemented in X10. The X10 runtime can be deployed as either native code (using a C++ backend), or as JVM bytecode (using the Java backend). For transport, the X10 runtime supports various options including sockets, MPI, and active messages via PAMI.

The X10 compiler can generate either C++ source code or Java source code. The two backends present different tradeoffs on different machines.

In general, the C++ backend is currently more mature and faster, and it supports more communication protocols. In the medium term, the backends will support different models of interoperability with other languages. In particular, the Java backend will support interoperability will Java code running on JVMs; the C++ backend will support interoperability with certain libraries for hardware accelerators and GPUs.  Eventually, we would like to make these two backends compatible with each other, so that some portions of a program can run on Java and other portions run natively.

Set the environment variable X10_NTHREADS to control the number of initial workers in a place.

Note that the ForkJoin scheduler may create more workers if the current worker suspends (e.g. to execute a when).

See the runtime section of the  Performance Tuning page for more details.

By default, the X10 runtime system is not robust with respect to Place failures.  However, starting with X10 2.4.1 X10 can be run in a resilient mode.  Resiliency adds some overhead to finish/async operations but enables the program to be notified of Place failures and continue running.

In X10, variables can be declared with either the VAR keyword or the VAL keyword. If a variable X is declared with "val X = ..." then X is a value; it is immutable.

X10 supports two levels of concurrency.

The first level corresponds to concurrency within a single shared-memory process, which is represented by an X10 Place. Usually, you would use one Place per shared memory multiprocessor. The main construct for concurrency within a Place is the X10 "async" construct.

The second level of X10 concurrency supports parallelism across Places, or analogously, across processes that do not share memory. Usually, this would correspond to concurrency across nodes in a cluster of workstations. The main construct for managing such concurrency in X10 is the "at" construct.

Additionally, X10 provides various libraries and features to support particular concurrent operations and data structures, such as reductions and distributed arrays.

Clocks correspond to barriers in traditional parallel computing discussions, such as the bulk-synchronous model of parallel computation. You would use a clock when multiple activities are accessing shared storage, and need to synchronize at the end of a phase before all activities move on to the next phase.

The "atomic" keyword marks operations that will perform atomically. Note that the X10 atomic keyword is an extremely heavy hammer: it grabs a lock that serializes all atomic operations in a Place. Usually, atomic should be used for prototyping, but it will probably not scale well in highly contended code.

For better performance, the x10.util.concurrent library provides various atomic operation and locks, which are implemented more efficiently using operations such as compare-and-swap.

PGAS (Partitioned Global Address Space) is an abstract programming model, which presents an abstraction of a single shared address space, but the address space is partitioned into regions based on an underlying NUMA (non-uniform memory access) architecture. There are several PGAS languages, including X10, Fortress, Chapel, and UPC.

APGAS (Asynchronous PGAS) is a variant of PGAS that supports asynchronous operations and control flow. X10 is an APGAS language.

An X10 Place corresponds to a single operating system process. X10 activities can only directly access memory from the Place where they live; they must use constructs like "at" to access memory at remote places.

Usually, in production, you would run with one X10 Place per node in a cluster of workstations. For debugging and development, it is possible to run with multiple Places installed in a single machine.

In X10, async S asynchronous executes statement S. In the meantime, the current thread continues. You can think of async as a starting an X10 activity, which is a lightweight thread.

In X10, at(x) executes statement S at the Place where X lives; namely, X.home.

In X10, finish S is used to synchronize with all the asynchronous activities that arise during the execution of S. Specifically, the finish statement will wait until all asyncs spawned (transitively) by S finish.

Like Java, X10 is a strongly-typed object-oriented language. X10 supports references to objects, but not pointer arithmetic or unconstrained casting between types.

In general, functions and methods in X10 resemble functions and methods in Java, C++, and Scala. The following code:

class X {
def foo(x:Int) : Int { ... }
}
{toc}

defines a member function called foo on class X. foo takes one parameter of type Int, and returns a type Int. The return type specification is optional; the X10 compiler can usually infer the return type from the method body.

Like functional languages, X10 supports functions as first-class objects in the language. In X10, each function has a type, such as (x:int) => int, which denotes a function type that takes an integer parameter and returns an int.

X10 support generic types, which are types that take other types as parameters. This language construct is especially useful for collection frameworks, as the Java collections framework.

A dependent type is a type that depends on a value in the underlying programming language. X10 uses dependent types in the X10 "constraint types". Often, X10 constraint types are used to enforce safety in multi-place code.

X10 has a standard library of data structures. The x10.util package includes X10 versions of many of the standard collection classes from Java.

Additionally, X10 provides some standard libraries of distributed data structures. Currently, the main supported distributed data structure is the distributed array, in the x10.array and x10.regionarray packages.

Yes, we plan to implement additional core collection classes, and also to expand the set of distributed data structures.  This is an area where contributions from the community would be especially appreciated!

The X10 project uses JIRA for issue tracking. The JIRA interface supports searching the existing bug database.

The X10 project uses JIRA for issue tracking. To report a bug or request an enhancement or new feature in X10 please first check to see if an entry already exists in JIRA. If it doesn't please create a new one. The more details you have in the bug report, the easier it will be for us to reproduce the problem and get it fixed.