how to expose
units with very
to the programmer
is an interesting
it is very difficult
to provide a single
way of determining whether an object
C and C++ have a very different
concept of mutability in the type system provided by the language: a particular reference to an object may or
may not modify it, but this does not
mean the object itself will not change.
This, combined with the deep copying
problem, makes interfacing functional and object-oriented languages a difficult problem.
Monads provide some tantalizing
possibilities for the interface. A monad
is an ordered sequence of computational steps. In an object-oriented
world, this is a series of message sends
or method invocations. Methods that
have the C++ notion of const (that is, do
not modify the state of the object) may
be invoked outside of the monad, and
so are amenable to speculative execution and backtracking, whereas other
methods should be invoked in a strict
sequence defined by the monad.
models of Parallelism
Mutability and parallelism are closely
related. The cardinal rule for writing
maintainable, scalable, parallel code
is that no object may be both mutable
and aliased. This is trivial to enforce
in a purely functional language: no object is mutable at all. Erlang makes one
concession to mutability, in the form
of a process dictionary—a mutable
dictionary that is accessible from only
the current Erlang process and so can
never be shared.
Interfacing languages with different notions of what can be shared
presents some unique problems. This
is interesting for languages intended
to target massively parallel systems
or GPUs, where the model for the language is intimately tied to the underlying hardware.
This is the issue encountered
when trying to extract portions of C/
C++/Fortran programs to turn into
OpenCL. The source languages typically have in-place modification as the
fastest way of implementing an algorithm, whereas OpenCL encourages
a model where a source buffer is processed to generate an output buffer.
This is important because each kernel
runs in parallel on many inputs; thus,
for maximum throughput they should
In C++, however, ensuring that two
pointers do not alias is nontrivial. The
restrict keyword exists to allow programmers to provide this annotation,
but it is impossible in the general case
for a compiler to check that it is correctly used.
Efficient interoperability is very important for heterogeneous multicore
systems. On a traditional single-core
or SMP (symmetric multiprocessing)
computer, there is a one-dimensional
spectrum between high-level languages that are close to the problem domain
and low-level languages that are close
to the architecture. On a heterogeneous
system, no one language is close to the
underlying architecture, as the difficulty of running arbitrary C/C++ and Fortran code on GPUs has shown.
Current interfaces—for example,
OpenCL—are a long way from ideal.
The programmer must write C code to
manage the creation of a device context
and the movement of data to and from
the device, and then write the kernel in
OpenCL C. The ability to express the
part that runs on the device in another
language is useful, but when most of
the code for simple operations is related to the boundary between the two
processing elements rather than the
work done on either side, then something is wrong.
How to expose multiple processing
units with very different abstract machine models to the programmer is an
interesting research problem. It is very
difficult to provide a single language
that efficiently captures the semantics.
Thus, this problem becomes one of interoperability between specialized languages. This is an interesting shift in
that domain-specific languages, which
are traditionally at the high-level end of
the spectrum, now have an increasing
role to play as low-level languages.
the Vm Delusion
The virtual machine is often touted
as a way of addressing the language
interoperability problem. When Java
was introduced, one of the promises
was that you would soon be able to
compile all of your legacy C or C++
code and run it in JVM alongside Java,
providing a clean migration path.
Today, Ohloh.net (which tracks the
number of lines of code available in
public open source repositories) re-