Compute Aorta

Murray, Alastair; Crawford, Ewan

doi:10.1145/3388333.3388652

Cited by 6 publications

(10 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…When other OpenCL implementations are not available, for example on ARM based architectures, we compare our performance with ComputeAorta. 27 ComputeAorta is a product from Codeplay which provides OpenCL API implementations on hardware ranging from DSPs to large machine learning accelerators. For AMD architecture, we compare against POCL, 34 a portable open source implementation of the OpenCL standard.…”

Section: Experimental Setup and Resultsmentioning

confidence: 99%

“…This offline compilation is performed for example by the ComputeAorta offline compilation target. 27 Other targets also require or benefit from compiling the device code statically. For example, for running SYCL kernels on FPGAs, the device code is compiled statically into the FPGA binary which is embedded into the SYCL application (for example using an integration header) and loaded at run-time to configure the FPGA.…”

Section: Sycl and Need For A Cpu-specific Compilation Flowmentioning

confidence: 99%

“…In order to avoid the run-time overhead of compiling/finalizing the SPIR/SPIR-V kernel code by the OpenCL driver, the device code could also be statically compiled off-line. 27 This option is attractive when the platform targeted by the SYCL application is known and fixed, that is, where the flexibility of targeting the same code to several different devices is not needed. This way the device code can be statically compiled using the best possible optimizations and code generation techniques for a platform.…”

Section: Cpu Compilationmentioning

confidence: 99%

“…For this project we have integrated the CA VECZ whole function vectorizer. 27 Using any clang-based compiler (or ComputeCpp itself) as host compiler allows to emit the intermediate representation of the host code as LLVM IR. These two modules can then be linked together using the llvm-link tool.…”

Section: Sycl Host Compilation Flowmentioning

confidence: 99%

“…Most of the existing SYCL applications and SYCL ecosystem libraries have been written mainly for heterogeneous systems with accelerators such as GPUs, but, there are multiple reasons for targeting this code to CPUs. When running SYCL applications on OpenCL or other backend implementations such as Vulkan Compute 13 or “Mux,” 27 all targets for example GPU and CPU typically follow the same flow (see Figure 1) described in Section 2.4 where the device code is passed to the OpenCL (or another backend) device compiler for finalization at run‐time. In situations or systems where only one particular platform needs to be targeted by SYCL, for example, CPU (host and device code are compiled for the same CPU), such run‐time compilation overhead could be avoided by compiling the kernel/device code statically.…”

Section: Motivation and Backgroundmentioning

confidence: 99%

See 4 more Smart Citations

Improving performance of SYCL applications on CPU architectures using LLVM‐directed compilation flow

Ghiglio

Dolinsky

Goli

et al. 2023

Concurrency and Computation

View full text Add to dashboard Cite

SummaryThe wide adoption of SYCL as an open‐standard API for accelerating C++ software in domains such as HPC, automotive, artificial intelligence, machine learning, and other areas necessitates efficient compiler and runtime support for a growing number of different platforms. Existing SYCL implementations provide support for various devices like CPUs, GPUs, DSPs, FPGAs and so forth, typically via OpenCL or CUDA backends. While accelerators have increased the performance of user applications significantly, employing CPU devices for further performance improvement is beneficial due to the significant presence of CPUs in existing data‐centers. SYCL applications on CPUs, currently go through an OpenCL backend. Though an OpenCL backend is valuable in supporting accelerators, it may introduce additional overhead for CPUs since the host and device are the same. Overheads like a run‐time compilation of the kernel, transferring of input/output memory to/from the OpenCL device, invoking the OpenCL kernel and so forth, may not be necessary when running on the CPU. While some of these overheads (such as data transfer) can be avoided by modifying the application, it can introduce disparity in the SYCL application's ability to achieve performance portability on other devices. In this article, we propose an alternate approach to running SYCL applications on CPUs. We bypass OpenCL and use a CPU‐directed compilation flow, along with the integration of whole function vectorization to generate optimized host and device code together in the same translation unit. We compare the performance of our approach—the CPU‐directed compilation flow, with an OpenCL backend for existing SYCL‐based applications, with no code modification for BabelStream benchmark, Matmul from the ComputeCpp SDK, N‐body simulation benchmarks and SYCL‐BLAS (Aliaga et al. Proceedings of the 5th International Workshop on OpenCL; 2017.), on CPUs from different vendors and architectures. We report a performance improvement of up to on BabelStream benchmarks, up to on Matmul, up to on the N‐body simulation benchmark and up to 16% on SYCL‐BLAS.

show abstract

Section: Experimental Setup and Resultsmentioning

confidence: 99%

Section: Sycl and Need For A Cpu-specific Compilation Flowmentioning

confidence: 99%

Section: Cpu Compilationmentioning

confidence: 99%

Section: Sycl Host Compilation Flowmentioning

confidence: 99%

Section: Motivation and Backgroundmentioning

confidence: 99%

See 3 more Smart Citations