Each programming language has its own strengths and weaknesses. But we believe in: the right tool for the right job. Heterogeneous programming is highly complex and requires a lot of programming experience when you want to do it "right". Quasar aims at simplicity (a low barrier of entry) while aiming at a high performance that is similar to handwritten C++/CUDA/OpenCL code.

Additionally, the Quasar language unifies CPU and GPU programming: one single code path is sufficient to generate optimized versions for both CPU and GPU. This considerably reduces programming effort.

In fact, the Quasar compiler can recognize and optimize sophisticated programming patterns (such as parallel reductions, prefix sums, stencil operations etc.) To be able to do so, higher-level information is extracted from the Quasar program. In other programming languages this information is often lost (e.g., because there are no built-in dynamically sized multidimensional arrays, the presence of pointers and aliasing conditions hamper compiler analysis, etc.). Quasar then uses target-specific source-to-source optimizations to generate efficient C++/CUDA or OpenCL code. For the final translation to binary, commercial or open-source compilers are used in the background. This also allows benefitting from the low-level optimizations in these compilers.

Furthermore, Quasar offers the low-level flexibility and optimization possibilities of C/C++ together with the high-level rapid testing/development of Octave/Matlab. Additionally, Quasar is user/programmer-friendly and is easy to learn. Of course, there are always certain compromises to be made (e.g., flexibility of programming versus computational cost), but this is where the compiler research and the various tools kick in.

Actually it is somewhere in the middle: in theory you can do anything that a general-purpose language can do, but in practice there is slightly more focus on domain-specific features (multi-dimensional array data processing, image and video processing algorithms and OpenGL visualization).

To have an idea about what Quasar can be used for, have a look at  https://gepura.io/demos/. The main application areas are 1) image/video processing, 2) medical imaging 3) computer vision, 4) automotive applications and 5) sensor fusion applications. In theory, Quasar is an array programming language and hardware acceleration will be obtained when the arrays are 1) sufficiently large (for example more than thousands of numbers), 2) the dimensionality is high and 3) the processing is purely parallel. Also the tasks need to be performance limited by computations (Quasar is currently not designed for I/O intensive operations such as integration in a database management system for Querying large datasets). So one good application example is the real-time processing of camera images.

Quasar can be regarded as a layer on top of CUDA/OpenCL. OpenCL programmers have experienced that a kernel written for a GPU from one manufacturer does not always offer the best performance on a GPU from another manufacturer, i.e., they are not *performance-portable*, even not across CPU/GPU. Therefore, with OpenCL, it is often necessary to provide target-specific kernels which results in different code paths and difficult maintainability. The Quasar compiler performs this kind of specialization automatically and the runtime further adjusts the kernels to the specific characteristics of the GPU being used. This does not only save a lot of development effort but also improves the future proofness of the code.

Currently, Linux and Windows are supported. We mostly test and develop with Linux (Ubuntu, Mint, Debian, CentOS distributions) and Windows. Quasar is platform-independent and also works in Mac OS X, but it has not been tested extensively. Of course, a Quasar program written in Linux will also work in Windows etc.

Quasar in the first place supports x86 and x64-based desktop/laptop systems, but can also run on ARM32 (e.g., the NVidia Jetson TK1 embedded device) and ARM64 (NVidia Jetson TX2). Quasar programs are platform-independent: they can be developed on a desktop and later deployed on an embedded device.

It is recommended to use the CUDA back-ends of Quasar, because they currently offer the best performance, by using more advanced CUDA features internally. Hence you need an Nvidia graphical card, like the Geforce GTX 900+ series, the Geforce TITAN or Tesla cards. Unless double-precision performance is important, you'll be fine with a recent Geforce GTX card.

Other GPU or accelerator devices (AMD, Intel HD graphics, Intel Xeon Phi) are supported through OpenCL 1.1/1.2, but because OpenCL 1.1/1.2 has significantly less features than e.g. CUDA 7.0, there is less flexibility: certain parts of your code will not be able to run on the GPU. Even though in this case the code will be executed automatically on your multi-core CPU, there is a certain performance loss.

Any Nvidia card starting with Geforce 430 will be fine, both the mobile (M) as the desktop series. You can find a full list on the Nvidia website.

Yes, you can. In this case, all calculations will be performed on the CPU. The code will automatically benefit from the multiple CPU cores, when available. Note that the GPU often gives performance improvements of factors 10x-100x.

Yes, you can. Although it is currently not yet documented, so you will need to contact us to obtain more information and to enable this feature.

Yes, you can, via the external interface API. For C/C++ code, you can either use Quasar in a host-mode or in a client-mode. For C# code, you can directly access the runtime library functions. Other languages need to go via either the C++ bindings or via C#. There is documentation provided in the software distribution.

At this point, there isn't. The problem is that even with such a tool, the converted Quasar programs may inherit several performance deficiences of Matlab (e.g., due to the fully dynamic typing). In general, it is more advantageous to port the Matlab code manually.

In case of an existing application, it is best to rewrite some performance critical parts of the code in Quasar, this may be seen as some additional work, but this gives the compiler the optimization options that are not available by e.g., a C++/CUDA compiler. Also porting to Quasar is due to the simplicity relatively easy. Then, an existing Quasar bridge need to be used to integrate the Quasar code in the host application. This can be achieved using the Quasar external C++ API (discussed before), using the .Net language integration (C#, F#, IronPython examples are available), or using the java bridge (developed at the Flemish Institute of Biotechnology - VIB).

Quasar has its own fully fledged integrated development environment (IDE). The IDE was written from scratch (i.e., it does not depend on existing IDEs like Eclipse) and is specialized to Quasar development. The IDE performs background compilation, syntax error checking, has extensive debugging support and a sophisticated profiler with timeline views and memory resource inspection.

When programming in Quasar, several optimization hints and warnings are displayed in the icon margin of the code editor. It is best to pay sufficient attention to this hints because they not only give suggestions on how to improve the code, they also give insight about how the Quasar compiler works and how efficient GPU code can be obtained; in this sense, the Quasar IDE also offers non-GPU novices to learn and discover how to best program GPUs.

Screenshot of the Quasar Redshift IDE

Quasar is available for download: try-quasar. You will obtain a limited time (3 months) free evaluation license. See licensing info for more information about the Quasar licenses.