How to deploy AI software to self driving cars

Brown, Gordon; Ravindran, Meenakshi; Burns, Rod; Miller, Niklas

doi:10.1145/3318170.3318184

Cited by 2 publications

(1 citation statement)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…TriSYCL 14 targets Xilinx FPGAs and neoSYCL 15 targets the NEC SX‐Aurora TSUBASA vector computer 16 . ComputeCpp 10 supports CPUs/GPUs/FPGAs, specialized processors like Renesas' R‐Car 17 system‐on‐chips (SoCs) and other commercial platforms. Various hardware and technology companies like Intel 18 and Huawei 19 provide SYCL support for custom hardware as well.…”

Section: Motivation and Backgroundmentioning

confidence: 99%

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