Currently, ParallelAccelerator tries to compile Julia to C++, which puts some constraints on what can be successfully compiled and run:
- We only support a limited subset of Julia language features currently.
This includes basic numbers and dense array types, a subset of math
functions, and basic control flow structures. Notably, we do not support
Stringtypes and custom data types such as records and unions, since their translation to C is difficult. There is also no support for exceptions, I/O operations (only very limited
println), and arbitrary
ccall. We also do not support keyword arguments.
- We do not support calling Julia functions from C++ in the optimized
function. What this implies is that we transitively convert
every Julia function in the call chain to C++. If any of them is not
translated properly, the target function with
@accwill fail to compile.
- We do not support Julia’s
Anytype in C++, mostly to defend against erroneous translation. If the AST of a Julia function contains a variable with
Anytype, our Julia-to-C++ translator will give up compiling the function. This is indeed more limiting than it sounds, because Julia does not annotate all expressions in a typed AST with complete type information. For example, this happens for some expressions that call Julia’s own intrinsics. We are working on supporting more of them if we can derive the actual type to be not
Any, but this is still a work in progress.
At the moment ParallelAccelerator only supports the Julia-to-C++ back-end. We are working on alternatives that make use of Julia’s upcoming threading implementation that hopefully can alleviate the above mentioned restrictions, without sacrificing much of the speed brought by quality C++ compilers and parallel runtimes such as OpenMP.
Apart from the constraints imposed by Julia-to-C++ translation, our current implementation of ParallelAccelerator has some other limitations:
- We currently support a limited subset of Julia functions available in the
Baselibrary. However, not all Julia functions in
Baseare supported yet, and using them may or may not work in ParallelAccelerator. For supported functions, we rely on capturing operator names to resolve array related functions and operators to our API module. This prevents them from being inlined by Julia which helps our translation. For unsupported functions such as
mean, Julia’s typed AST for the program that contains
meanbecomes a lowered call that is basically the low-level sequential implementation which cannot be handled by ParallelAccelerator. Of course, adding support for functions like
meanis not a huge effort, and we are still in the process of expanding the coverage of supported APIs.
- ParallelAccelerator relies heavily on full type information being available
in Julia’s typed AST in order to work properly. Although we do not require
user functions to be explicitly typed, it is in general a good practice to
ensure the function that is being accelerated can pass Julia’s type inference
without leaving any arguments or internal variables with an
Anytype. There is currently no facility to help users understand whether something is being optimized or silently rejected. In the future, we plan to provide such functionality to give users better insight into what is going on under the hood.