Toward Performance Portable Programming forHeterogeneous Systems on a Chip: A Case Study

with Qualcomm Snapdragon SoCAnthony Cabrera, Seth Hitefield, Jungwon Kim, Seyong Lee, Narasinga Rao Miniskar, and Jeffrey S. Vetter

Oak Ridge National LaboratoryOak Ridge, Tennessee 37831-6173

Email: {cabreraam, hitefieldsd, kimj, lees2, miniskarnr, and vetter}@ornl.gov

Abstract—Future heterogeneous domain-specific systems ona chip (DSSoCs) will be extraordinarily complex in terms ofprocessors, memory hierarchies, and interconnection networks.To manage this complexity, architects, system software designers,and application developers need programming technologies thatare flexible, accurate, efficient, and productive. These technologiesmust be as independent of any one specific architecture asis practical because the sheer dimensionality and scale of thecomplexity will not allow porting and optimizing applicationsfor each given DSSoC. To address these issues, the authors aredeveloping Cosmic Castle, a performance portable programmingtoolchain for streaming applications on heterogeneous archi-tectures. The primary focus of Cosmic Castle is on enablingefficient and performant code generation through the smartcompiler and intelligent runtime system. This paper presentsthe preliminary evaluation of the authors’ ongoing work towardCosmic Castle. Specifically, this paper details the code-portingefforts and evaluates various benchmarks on the QualcommSnapdragon SoC using tools developed through Cosmic Castle.

I. IntroductionHeterogeneous and manycore processors are becoming the

de facto architectures for both traditional high-performancecomputing (HPC) systems and domain-specific systems on achip (DSSoCs). One critical challenge of these architecturesis programmability. Numerous active efforts are working toimprove programmability and portability, including directive-based programming models [1], [2], library application pro-gramming interfaces (APIs) [3], [4], and parallel programminglanguages [5]. However, experiences with GPUs [6], [7] andKnights Landing [8] illustrate how difficult it is to obtainperformance close to that offered by the native programmingenvironment for a given system. Rapidly changing systemarchitectures also further complicate this issue.

Several programming solutions of varying maturity andperformance have been developed to, in part, enable perfor-mance portability. Notable solutions include OpenCL [5], [9],

Notice: This manuscript has been authored by UT-Battelle, LLC, undercontract DE-AC05-00OR22725 with the US Department of Energy (DOE).The US government retains and the publisher, by accepting the article forpublication, acknowledges that the US government retains a nonexclusive, paid-up, irrevocable, worldwide license to publish or reproduce the published formof this manuscript, or allow others to do so, for US government purposes. DOEwill provide public access to these results of federally sponsored research inaccordance with the DOE Public Access Plan (http://energy.gov/downloads/doe-public-access-plan).

OpenACC [1], [6], [10], [11], and OpenMP [2], [12]–[14].Library and meta-programming solutions (e.g., cuBLAS [15],Thrust [16], Legion [3], Kokkos [4]) have also demonstratedpromise. Still, programming these systems may require signif-icant architectural expertise, and the current solutions oftenlack performance portability. Domain-specific languages areanother approach for addressing productivity, performance, andportability issues in programming modern architectures [17]–[21]. However, these approaches require that all of a givenapplication’s kernels must be rewritten with domain-specificlanguages and often focus on specific architectures that lackmature programming environments or community support.

To this end, the authors present Cosmic Castle, a softwareecosystem that provides performance portable programmingsolutions for heterogeneous and manycore processors and deepmemory hierarchies while balancing against programmability.To achieve this goal, the authors’ proposed solution leveragesexisting efforts as much as possible by integrating software toolsfrom vendors and the community into the ecosystem to find thebest portable, performant, and sustainable solutions. This is anongoing project. This paper focuses on the main programmingsystem of Cosmic Castle and evaluates its effectiveness andpotential as a performance portable programming system. TheQualcomm Snapdragon line of SoCs is used as a case study.This paper details the process of integrating the existingSnapdragon tooling with the authors’ tools in Cosmic Castle,and porting several benchmarks from various applicationdomains onto the Snapdragon SoC.

The main contributions of this paper are as follows.• This paper describes Cosmic Castle, a performance

portable programming toolchain for porting applications onheterogeneous architectures, which consists of the smart com-piler, Open Accelerator Research Compiler (OpenARC) [10],and the Intelligent Run Time System (IRIS) [22].

• This paper provides an example of using Cosmic Castleon the Qualcomm Snapdragon SoC in terms of its architecturesand their implications on programming with emphasis on theHexagon digital signal processor (DSP).

• This paper evaluates the effectiveness and potential ofthe proposed Cosmic Castle programming system by portingseveral benchmarks from different application domains ontothe Snapdragon SoC.

II. Qualcomm Snapdragon Architectureand Programming

The Qualcomm Snapdragon line of SoCs is a versatileembedded processor that includes powerful ARM CPU coresalong with accelerators such as GPU and DSPs. It has beena viable solution for developing mobile applications, suchas multimedia/vision processing, 5G networking, artificialintelligence, and Internet Protocol cameras. The Snapdragon855 and 865 chipsets are widely used in commercial mobileplatforms (e.g., smartphones and tablets) by vendors such asSamsung, LG, Motorola, OPPO, and Xiomi.

A. Architecture and ProgrammingQualcomm Snapdragon 855 and 865 provide heterogeneous

compute capability at different levels, as shown in Figure 1.They offer different variants of compute units, such as Dy-namic IQ big.LITTLE multicore ARM cores, Adreno GPU,Hexagon DSP, and Spectra 360 (480 for 865 chipset). Thesecompute elements are targeted through different programmingmodels, such as C/C++ with OpenMP for multicore ARMcores; OpenCL, OpenGL, Vulkan, and DirectX for GPU; andC/C++ and assembly language for Hexagon DSP.

Quad Little Cores (CPU 0-3)

Qualcomm System Fabric

Adreno 640/650

(384/512) x 2 ALUs

1 MB On-chip Memory250 to 600 MHz

ARM A55L1D

64 KBL1I

64 KB

L2 (128 KB)300 MHz to 1.8 GHz

3 Big Cores (CPU 4-6)

ARM A76/A77L1D

64 KBL1I

64 KB

L2 (256 KB)710 MHz to 2.4 GHz

Primary Core (CPU 7)

ARM A76/A77L1D

64 KBL1I

64 KB

L2 (512KB)825 MHz to 2.8 GHz

Hexagon 690/6981024b Vector

Units

Tensor Accelerator

576 MHz

L3 (2 / 4 MB)

LPDDR4/LPDDR5

4 Channel

2.1 GHz

6 to 16 GB

Spectra 380/480Camera

ISP

X24 +X50/X55

LTE+5GModem

CDSP ADSP MDSP

* SD 855/865

Fig. 1: Snapdragon 855 and 865 with heterogeneous compute units.

1) big.LITTLE ARM CPUsThe Snapdragon 855 and 865 chipsets include the Kryo series

of CPUs, which are based on ARM-based CPUs. Althoughthere are eight ARM-based cores, they are not symmetric. TheSnapdragon chipset has four low-power Cortex-A55 cores (i.e.,LITTLE cores) and four high-performance Cortex-A77/A76cores (i.e., big cores), and one of these cores acts as the“prime” core. Moreover, the cache sizes of these cores are alsodifferent. The prime core has a dedicated 512 KB L2 cache,whereas each of the other big cores have a dedicated 256KB L2 cache. Multithreading of these cores can be exploitedthrough the OpenMP programming model or by using thepthread library.

The LITTLE cores (cores 0–3) are operable at 18 frequencyscale modes ranging from 300 MHz to 1.8 GHz. The big

cores (cores 4–6) can operate at 17 frequency scale modesranging from 710 MHz to 2.4 GHz. The prime core (core 7)can run at 20 frequency scale modes ranging from 825 MHzto 2.8 GHz. The frequency of each core can be set at run timeor through the Linux shell.

2) Adreno GPUThe Snapdragon 855 chipset also contains the Adreno 640

GPU, which is used for mobile chipsets and was developedby Qualcomm. It is used for 2D/3D graphics acceleration. TheAdreno 640 GPU has 384 × 2 arithmetic logic units (ALUs)and supports unified memory addressing. It has 1 MB on-chipgraphic memory, and its frequency can be scaled from 250to 600 MHz. However, it is unclear how its frequency can bechanged through programming.

3) Hexagon DSP, NPU, and Spectra ISPThe Spectra 360 is an image and signal processor (ISP),

which is a hardware accelerator for computer vision. HexagonDSP is used to efficiently process multimedia algorithms. Italso has a tensor accelerator and a dedicated neural processingunit (NPU) for efficiently processing deep neural networks. Thecore Hexagon DSP is a Very Large Instruction Word (VLIW)architecture and is supported with hardware multithreading.There are three variants of Hexagon DSPs available: the audioDSP (ADSP) for audio processing, compute DSP (CDSP) forcompute-intensive tasks, and modem DSP (MDSP) for X24LTE/5G modems. The CDSP has 1,024 bit vector functionalunits. The ADSP and CDSP are programmable through C/C++and assembly language. CDSP vector functional units requirespecial Hexagon Vector Extensions (HVX) instructions. Theseinstructions are either manually embedded in the hexagonkernel (C/C++) or can be generated by the auto-vectorizingcompiler feature provided by the Qualcomm Hexagon softwaredevelopment kit (SDK) toolchain. Spectra ISP, MDSP, and NPUcan be used through dedicated APIs provided by Qualcomm.

§II-B discusses optimization of the Snapdragon HexagonDSP in more detail.

B. Designing and Optimizing Applications forHexagon DSP

As described in §II-A3, the Hexagon DSPs in the SnapdragonSOC are VLIW processors equipped with a 1,024 bit vectorcoprocessor. The benefit of offloading computation to HexagonDSPs is that the hardware is significantly less complex thanthe ARM CPUs and are clocked slower. Paired with thepotential for vectorized computation, this enables the possibilityof accelerated computation relative to the CPUs while alsoconsuming less power. This is particularly beneficial forenabling heavier computation workloads at the edge.

However, the Hexagon DSPs are notoriously difficult toprogram. Although the Snapdragon CPU and GPU can betargeted by using OpenMP and OpenCL, respectively, nosuch model exists for the DSP. Additionally, the DSP is aVLIW processor, and writing efficient code to target thisprocessing paradigm requires architecture-specific knowledgeof the DSP. Finally, the documentation and example programsfor the Hexagon DSP are not as rich as other vectorized

compute solutions, such as the Intel Streaming SIMD (singleinstruction, multiple data) Extensions and Advanced VectorExtensions or the ARM Neon vector extensions. For example,Intel and ARM both have online, user-friendly documentationof their vector intrinsics for their various vector units [23],[24]. Although examples exist in the Hexagon SDK, they arenot well documented, and choices made in the source code arenot immediately obvious. Additionally, the Hexagon DSP SDKis a framework entirely separate from the native Android buildenvironment, which is required to build applications that targetthe platform. This additional framework is yet another thingthat must be learned to build applications for this platform.

This section decreases the sparsity in the literature regardinghow to program the Hexagon DSP and shows the authors’progress toward designing and optimizing applications thatleverage the Hexagon DSP.

1) Creating a Hexagon DSP ApplicationFastRPC: Fast remote procedure call (FastRPC) is the

framework that allows transparent remote calls from thehost processor to the DSP. Specifically, this is what enablesusers to offload computation to the DSP. This is done bygenerating a stub and skeleton, or skel, library that handlescommunication between the host and device. The stub andskel libraries reside on the host and DSP sides, respectively,and are autogenerated based on the user-provided interfacedefinition language (IDL) of Qualcomm Another IDL Compiler(QAIC). The file extension for this specification is .idl.Accompanying this is an implementation of rpcmem, whichallows users to allocate physically contiguous memory andphysically shared memory between the host and DSP.

Make.d Build Environment: Code for DSP kernels canbe created by using GNU Make, but the documentationthat accompanies the Hexagon SDK recommends using aQualcomm-developed GNU Make library called Make.d. Thegoal of this library is to relieve some of the difficulty oncreating a makefile from scratch. Both AArch64 and HexagonDSP codes are supported in this library.

A general makefile is supplied as part of the Make.dbuild environment that can be reused across different projects,but users are responsible for supplying .min files thatdescribe the flags, source and include paths, libraries to belinked, and so on specific to the user’s application. TheDSP and CPU are conventionally named android.min andhexagon.min, respectively. The CPU and DSP also requireandroid_deps.min and hexagon.min files. These areresponsible for listing the variants that are supported by thedesign (e.g., 32 bit or 64 bit ARM binaries) or a specificversion of the Hexagon DSP architecture. Once each of thesefiles is created, the make command must be invoked twice:once to build the Android side application code and once tobuild the Hexagon DSP code.

Obtaining a Handle to the DSP Domain: To target oneof the DSPs available on Snapdragon, users must acquire ahandle to that DSP’s domain. Users must provide the universalresource identifier, which is autogenerated by the QAIC IDLtools, and a pointer to the resulting handle.

Creating Hexagon DSP Kernels: DSP kernels can becreated using C, C++, or Hexagon assembly languages. Fora function to be called by the host processor, users mustimplement a function with a signature that matches the onespecified in the aforementioned .idl file.

It is possible to create multithreaded DSP applications, andthis is done by using functionality provided by the dspCVlibrary in the Hexagon DSP. Contrary to the name, this libraryhas more functionality outside of computer vision tasks.

Another feature is the 1,024 bit vector coprocessor. Thisprocessor implements an instruction set called HVX. Althoughit cannot execute floating-point operations, it can execute integerand fixed-point operations. One of the difficult aspects inleveraging the coprocessor is that users must specify theirdesign by using either assembly code or vector intrinsics.Crafting assembly code might allow users to extract the mostperformance possible for a given DSP design because userscan craft an instruction schedule not attainable by the suppliedcompiler. The opposite end of this spectrum is to try to makethe compiler auto-vectorize the code.

III. Cosmic Castle FrameworkIn §II, the architectural diversity and programming com-

plexity of the Snapdragon SoC demonstrate the complexproblem on programming heterogeneous SoCs. To address theseproblems, the authors propose Cosmic Castle, a framework forperformance portable programming on heterogeneous DSSoCs.Cosmic Castle is a performance modeling-based, multilevelhardware-software integration strategy that will provide amethodology for projecting application ontologies onto pro-gramming systems, operating systems, and hardware. CosmicCastle develops solutions across areas such as performancemodeling and software tools to enable a development ecosystemthat exercises the full capability of the highly programmablesystem and intelligent scheduling to manage the set of domainresources in the context of specific applications. This isan ongoing project, and this paper focuses on the mainprogramming system of Cosmic Castle, which consists ofthe heterogeneous task run time system, IRIS, and its front-end compiler, OpenARC. This section introduces the IRISruntime and OpenARC compiler and their deployment on theSnapdragon SoCs to demonstrate the potential of Cosmic Castlefor heterogeneous DSSoC programming.

A. IRIS : Intelligent Run Time SystemAchieving functional and performance portability in het-

erogeneous programming is challenging. Programmers mustwrite the code blocks in the application to the target accel-erators by using their vendor-specific programming systems(e.g., NVIDIA CUDA, AMD HIP, Intel oneAPI, QualcommHexagon SDK). To fully exploit the power of all heterogeneouscompute elements present in a given system, programmersmust manually author and assign the code blocks/kernels toa specific accelerator and maintain them. This results in poorcode performance portability and low programmer productivity.

QualcommOpenCLRuntimeLibrary

LLVMOpenMPRuntimeLibrary

QualcommHexagonRuntimeLibrary

HexagonDSP

AdrenoGPU

KryoCPU

Task

Task

Task Task

OpenMPKernel

HexagonKernel

OpenCLKernel

Device Memory

KryoCPU

DynamicPlatformLoader

TaskScheduler

IRIS

IRIS APIHost CodeC/C++/FortranLo

wer

Le

vel

Policy

Policy

Policy

Policy

Task

Tool

chai

ns

QualcommHexagon

IDLCompiler

Stub Skel

AndroidNDK

LLVM/Clang

OMP KernelShared Lib

AndroidNDK

LLVM/Clang

ApplicationExecutable

FastRPC

OpenCL JIT Com

pilation

OpenMP Compiler

OpenMP Application

OpenACC Compiler

OpenACC ApplicationH

igh

Leve

l

Host Mem

LPDDR4

Host

Fig. 2: IRIS for Snapdragon.

Although OpenCL was one solution proposed to addressparts of this problem, not all hardware accelerators supportOpenCL. As extremely heterogeneous architectures becomemore widespread [25], this could become a serious burden toapplication programmers. Also, data transfers and synchroniza-tions among different types of accelerators remain obstaclesfor achieving easy programming and high performance.

To address these challenges, the authors designed andimplemented IRIS, a new run time system for heterogeneousarchitectures [22]. IRIS dynamically catalogs and managesall the heterogeneous hardware accelerators in the system. Atinitialization, IRIS discovers and enumerates the heterogeneouscapabilities on a node, including their preferred program-ming models (e.g., OpenMP, CUDA, HIP, oneAPI, Hexagon,OpenCL). IRIS enables programmers to write portable appli-cations across diverse heterogeneous architectures.

B. IRIS on SnapdragonFor a preliminary evaluation of the IRIS framework, the

authors designed and implemented IRIS for Snapdragon.Figure 2 shows the overview of IRIS for Snapdragon. Asexplained in §II, the target Snapdragon 855 consists of KryoCPUs, Adreno GPU, and Hexagon DSP. Qualcomm providesthe programmers with the Qualcomm OpenCL frameworkand Hexagon DSP SDK for their Adreno GPUs and Hexagon

DSPs, respectively. IRIS uses both programming frameworks tomanage the GPU and DSP devices. To target Kryo CPUs, IRISuses OpenMP. An IRIS application for Snapdragon consists ofthe host code written with the IRIS C/C++/Fortran API andthree native kernels: OpenMP for CPU, OpenCL for GPU, andHexagon for DSP.

Programmers can build the application executable fromthe host code by using the Android Native Development Kit(NDK) LLVM/Clang compiler toolchain. The OpenMP kernelis also compiled to the OpenMP kernel shared library by usingthe same toolchain. The OpenCL kernel does not need tobe compiled to the binary because the Qualcomm OpenCLframework for Adreno GPUs supports the Just-In-Time (JIT)OpenCL kernel compilation during the application execution.The Qualcomm Hexagon IDL compiler compiles the Hexagonkernel and builds the skel shared library for the DSP and thestub shared library for the CPU to enable Qualcomm FastRPC.The Qualcomm FastRPC allows tasks to be offloaded to DSPfrom CPU. The stub hides the serialization of function callparameters and the network-level communication to presenta simple invocation mechanism to the application on CPU.skel is responsible for dispatching the call to the actualremote object implementation on DSP.

When the application runs, the dynamic platform loaderin IRIS loads the Qualcomm OpenCL runtime shared library,Hexagon DSP SDK runtime shared library, and OpenMP kernelshared library at run time to execute the kernels on top of theloaded programming platforms.

Fig. 3: OpenARC System Overview.

C. OpenARC as a Front-End IRIS CompilerAs shown in §III-B, IRIS supports multiple different target-

specific native kernels (e.g., OpenMP, OpenCL, CUDA). Theprogrammer usually authors these kernels. To automaticallygenerate target-specific kernels from directive-based high-levelprogramming models (e.g., OpenACC and OpenMP) for usein IRIS, the authors leveraged OpenARC [10] as the front-endIRIS compiler. OpenARC is a research compiler frameworkdeveloped at Oak Ridge National Laboratory that compiles

and optimizes an input the OpenACC/OpenMP4 program forvarious target architectures, including CPUs, NVIDIA/AMD/In-tel GPUs, Xeon Phis, Intel field-programmable gate arrays(FPGAs), and nonvolatile memory systems (e.g., Fusion-IOioScale) [26], [27]. OpenARC offers a high-level intermediaterepresentation and extensible annotation framework, whichmakes it suitable for various source-to-source translation andinstrumentation studies. The high-level abstraction and variousdirective extensions offered by OpenARC make it easy tounderstand, access, and transform input programs so that thesame application can be adapted differently, depending on thecharacteristics of target systems [28].

D. OpenARC-IRIS IntegrationThe original implementation of OpenARC generates multiple

output programming models (e.g., CUDA, OpenCL, OpenMP,HIP), depending on the target architecture, but it only sup-ports one back-end programming model or device type ata time. To better program and concurrently support diverseheterogeneous types of devices by using directive-based high-level programming models (e.g., OpenACC, OpenMP) whereeach device could require different back-end programmingmodels (e.g., CUDA, OpenCL, OpenMP), the authors integratedOpenARC with IRIS (§ III-A). As shown in Figure 3, the newintegrated OpenARC system uses IRIS as the common deviceruntime abstraction, which allows a single application writtenvia a directive-based high-level programming model to exploitmultiple types of devices available in the target system byautomatically translating the high-level OpenACC/OpenMP4program into multiple different back-end programming modelsand intermixing them (e.g., CUDA, OpenCL, OpenMP).

In the new OpenARC/IRIS framework, all types of kernelcodes are generated during one invocation of the compiler whilestill allowing for the application of various architecture-specificoptimizations, such as: (1) exploiting device-specific memories(e.g., CUDA shared/texture memory); (2) reduction optimiza-tion to exploit FPGA-specific special hardware mechanisms,such as shift registers; and (3) sliding window optimization toavoid redundant memory accesses across loop iterations andhide memory latency using hardware buffers [11], [29]. Theauthors also optimized the OpenARC/IRIS interface in whichan additional compiler pass automatically merges IRIS tasksthat belong to the same OpenACC construct. Additionally, thenew optional runtime API can be used to automatically mergemultiple IRIS tasks across different OpenACC constructs ifusers guarantee its safety. This can reduce OpenARC/IRISinterfacing overheads.

IV. EvaluationThis section evaluates the effectiveness of the proposed

Cosmic Castle programming system by porting benchmarksfrom different application domains to heterogeneous computeunits available in the Snapdragon SoC and comparing theirperformance against other traditional HPC devices (e.g., IntelXeon E5-2683 CPU, AMD EPYC 7742 CPU, ARM Thun-derX2 CPU, NVIDIA P100 GPU). The tested device-specific

0

10000

20000

30000

40000

50000

60000

70000

OpenM

P-AR

MCD

SP

CDSP

+HVX

(Auto)

CDSP

+HVX

(Han

d-op

timize

d)

OpenC

L-Ad

rino

OpenM

P-AM

D EP

YC 774

2

OpenM

P-Int

el-Xe

on-E5-

2683

OpenC

L-Te

sla P10

0-PC

IE-12

GB

CUDA-

Tesla

P10

0-PC

IE-12

GB

OpenM

P-Th

unde

rX2

SAXPY (1M) SOBEL (1920x1080)

Exec

utio

n-Ti

me

(use

c)

ADSP /

Fig. 4: SAXPY and Sobel filter benchmarking.

kernels (e.g., OpenMP, OpenCL, CUDA), except for the hand-optimized versions, are automatically generated by OpenARCfrom the corresponding input OpenACC programs.

A. Performance Comparison of HeterogeneousCompute Units in Snapdragon SoC

The authors benchmarked SAXPY and Sobel filter kernels tocompare the effectiveness of Snapdragon compute units whencompared with Intel, AMD, ThunderX2, and NVIDIA computeresources, and the results are shown in Figure 4. The executiontime includes kernel execution time and IRIS runtime overhead.It was also compared with HPC CPU and GPU computingresources. The AMD EPYC 7742 system has two EPYC 7742processors, and each processor has 64 cores with simultaneousmultithreading enabled and 1 TB of main memory running ata maximum frequency of 2.25 GHz. The Intel Xeon E5-2683system has 32 cores in two sockets running at a maximumfrequency of 3 GHz and has 256 GB of main memory. TheARM ThunderX2 system has two CPUs, each with 28 coreswith 4 threads per core. ThunderX2 has 128 GB of mainmemory and is running at a maximum frequency of 2.5 GHz.

The authors listed the programming model (i.e., OpenMP,OpenCL, and CUDA) used for each compute resource. ForCDSP, the kernel is written in C/C++ and is interfaced throughHexagon FastRPC. The Hexagon CDSP without HVX resultsare 43% worse than those of OpenMP-ARM (with NEONthrough auto-vectorization) optimizations. The authors observedsimilar results with ADSP of the Snapdragon board. The HVXinstructions can be generated through the auto-vectorizationfeature, and the results are 40% better than those of OpenMP-ARM. The hand-optimized HVX code running on CDSP(shown only for the Sobel filter under CDSP+HVX/hand-optimized) results in a 3.2× gain compared with OpenMP-ARM. The OpenCL code running on the Adreno GPU of theSnapdragon SoC also results in performance similar to that ofCDSP with hand-optimized HVX code. The effectiveness ofSnapdragon computing resources were compared with NVIDIA,Intel, AMD, and ThunderX2 computing resources. SnapdragonAdreno/CDSP resources are 3× worse than NVIDIA Tesla

P100 GPU results. However, its performance is comparablewith that of ThunderX2.

Sobel kernel

2%

Kernel RPC

Overhead

10%

Memcpy

62%

ION

Allocations

26%

Fig. 5: Sobel filter run on hexagon DSP with run-time split.

The authors further analyzed the execution time of the Sobelfilter when executing on the Hexagon DSP. The results of thisanalysis are shown in Figure 5. The actual Sobel filter kernel onthe Hexagon CDSP takes only 2% of the overall execution time.The remaining time is consumed by FastRPC, ION memoryallocations, and data transfers to/from ION memory. Hence,there is ample opportunity for run time management of kernelsto optimize the data transfers and ION memory allocations bymaking the kernels efficiently use the memory and I/O.

Fig. 6: Comparison of CPU, GPU, DSP, and DSP auto-vectorizedIAXPY.

B. Hexagon DSP Kernel PerformanceTo further analyze the performance characteristics of the

Hexagon DSP in the Snapdragon SoC, the authors also portedthe IAXPY (integer a× x+ y) kernel by using two differentimplementation approaches: one with and one without auto-vectorization. Disassembling the two versions shows thatthe auto-vectorized disassembly has almost 10× as manyinstructions. However, Figure 6 shows that up to 2× as muchperformance can be achieved by invoking the auto-vectorizer.Although the results show that the CPU and GPU performthese computations faster than the DSP, there is a savings inpower consumption that is not displayed in this graph. Althoughthere is not a direct way to measure power consumption of theHexagon DSP, the authors plan to estimate power consumptionby architecting a performance model in future work.

C. IRIS Performance Portability on Snapdragon

0.00

0.00

0.00

0.00

0.01

0.12

1.54

17.59

116.15

0.02 0.02 0.02 0.020.05

0.09

0.42

3.62

49.13

0.01 0.010.02 0.01 0.02 0.02

0.04

0.27

2.19

0.10 0.09 0.09 0.120.18

0.41

9.14

80.06

642.61

0.11 0.12 0.120.20 0.18

0.29

4.63

37.30

304.92

0.00001

0.0001

0.001

0.01

0.1

1

10

100

1000

8 16 32 64 128 256 512 1024 2048

Exec

utio

n Ti

me

(sec

onds

)

Matrix Size (N x N)

CPU (Seq)CPU (OpenMP)GPU (OpenCL)DSP (Hexagon - 1 Thread)DSP (Hexagon - 4 Threads)

Fig. 7: SGEMM on Snapdragon.

To show the performance and portability of IRIS on Snap-dragon, the authors evaluated Single Float Precision GeneralMatrix Multiply (SGEMM) on the Snapdragon SoC, as shownin Figure 7. The SGEMM application contains host codewritten in the IRIS C API and three different kernels, includingan OpenMP kernel for CPU, OpenCL kernel for GPU, andHexagon kernel for DSP. For the Hexagon kernel, the numberof running threads were varied from 1 to 4. The sizes of thematrices in the application were varied from 8 × 8 to 2,048× 2,048 in powers of two. For the baseline performance, asequential version of SGEMM running on a single CPU coreonly was also evaluated. As the size of the matrices increases,GPU shows the best performance, and DSP show the worstperformance. This is because SGEMM is a compute-intensivekernel and good for data parallel-friendly devices (e.g., GPUs).On the other hand, DSP shows the worst performance becauseof its heavily pipelined hardware design and a small numberof concurrent hardware threads.

V. ConclusionContemporary heterogeneous systems provide mechanisms

to manage different types of accelerators in heterogeneousarchitectures. However, achieving functional and performanceportability in heterogeneous programming is a challengingproblem. This paper presents Cosmic Castle, a softwareecosystem for performance portable programming on theheterogeneous DSSoCs. Cosmic Castle is an on-going project,and this paper provides a preliminary evaluation of theCosmic Castle programming toolchain, which comprises thesmart compiler OpenARC and the intelligent runtime systemIRIS, by porting and evaluating various benchmarks on theSnapdragon SoC as an example heterogeneous DSSoC. Theresults show that Cosmic Castle allows users to programDSSoCs by using directive-based high-level programmingmodels while exploiting and intermixing different device-specific programming models preferred by each heterogeneousdevice. However, the initial performance comparison againstmanual low-level implementations and other traditional HPCdevices shows the need for exploring further optimizationopportunities to achieve better performance portability.

AcknowledgmentsThis research used resources of the Experimental Computing

Laboratory (ExCL) at Oak Ridge National Laboratory, whichis supported by the US Department of Energy (DOE) Officeof Science under contract no. DE-AC05-00OR22725.

This research was supported by the following sources: (1)the Defense Advanced Research Projects Agency MicrosystemsTechnology Office Domain-Specific System-on-Chip Programand (2) DOE Office of Science, Office of Advanced ScientificComputing Research, Scientific Discovery through AdvancedComputing program.

References

[1] OpenACC, “OpenACC: Directives for accelerators,” 2015.[2] OpenMP, “OpenMP reference,” 1999.[3] M. Bauer, S. Treichler, E. Slaughter, and A. Aiken, “Legion: Expressing

locality and independence with logical regions,” International Conferencefor High Performance Computing, Networking, Storage and Analysis,SC, 2012.

[4] Kokkos, “The C++ Performance Portability Programming Model,”[Online]. Available: https://github.com/kokkos/kokkos, 2014.

[5] J. E. Stone, D. Gohara, and G. Shi, “OpenCL: A parallel programmingstandard for heterogeneous computing systems,” Computing in Scienceand Engineering, vol. 12, no. 3, pp. 66–73, 2010.

[6] A. Sabne, P. Sakdhnagool, S. Lee, and J. S. Vetter, “Understanding porta-bility of a high-level programming model on contemporary heterogeneousarchitectures,” Micro, IEEE, vol. 35, no. 4, pp. 48–58, 2015.

[7] S. Lee and J. S. Vetter, “Early evaluation of directive-based GPUprogramming models for productive exascale computing,” in SC12:ACM/IEEE International Conference for High Performance Computing,Networking, Storage, and Analysis. Salt Lake City, Utah, USA: IEEEpress, 2012.

[8] S. Ramos and T. Hoefler, “Capability models for manycore memorysystems: A case-study with xeon phi KNL,” in Parallel and DistributedProcessing Symposium (IPDPS), 2017 IEEE International. IEEE, 2017,pp. 297–306.

[9] A. Danalis, G. Marin, C. McCurdy, J. S. Meredith, P. C. Roth, K. Spafford,V. Tipparaju, and J. S. Vetter, “The scalable heterogeneous computing(SHOC) benchmark suite,” in ACM Workshop on General-PurposeComputation on Graphics Processing Units (GPGPU). Pittsburgh,Pennsylvania: ACM, 2010, pp. 63–74.

[10] S. Lee and J. S. Vetter, “OpenARC: Open accelerator research compilerfor directive-based, efficient heterogeneous computing,” in ACM Sympo-sium on High-Performance Parallel and Distributed Computing (HPDC).Vancouver: ACM, 2014.

[11] S. Lee, J. Kim, and J. S. Vetter, “OpenACC to FPGA: A framework fordirective-based high-performance reconfigurable computing,” in IEEEInternational Parallel & Distributed Processing Symposium (IPDPS).Chicago: IEEE, 2016.

[12] S. Lee, S.-J. Min, and R. Eigenmann, “OpenMP to GPGPU: a compilerframework for automatic translation and optimization,” in 14th ACMSIGPLAN symposium on Principles and practice of parallel programming.Raleigh, NC, USA: ACM, 2009.

[13] S. Lee and R. Eigenmann, “OpenMPC: Extended openMP programmingand tuning for GPUs,” in 2010 ACM/IEEE International Conference forHigh Performance Computing, Networking, Storage and Analysis. IEEEComputer Society, 2010, pp. 1–11.

[14] M. Martineau, J. Price, S. McIntosh-Smith, and W. Gaudin,Pragmatic Performance Portability with OpenMP 4.x. Cham: SpringerInternational Publishing, October 2016, pp. 253–267. [Online]. Available:http://dx.doi.org/10.1007/978-3-319-45550-1_18

[15] cuBLAS, “Dense Linear Algebra on GPUs,” [Online]. Available: https://developer.nvidia.com/cublas, 2012.

[16] Thrust, “A Parallel Algorithm Library,” [Online]. Available: https://developer.nvidia.com/thrust, 2012.

[17] N. Maruyama, T. Nomura, K. Sato, and S. Matsuoka, “Physis:An implicitly parallel programming model for stencil computationson large-scale gpu-accelerated supercomputers,” in Proceedings of2011 International Conference for High Performance Computing,Networking, Storage and Analysis, ser. SC ’11. New York,NY, USA: ACM, 2011, pp. 11:1–11:12. [Online]. Available:http://doi.acm.org/10.1145/2063384.2063398

[18] C. LengauerSven, A. Bolten, A. Größlinger, F. Hannig, H. Köstler,U. Rüde, J. Teich, A. Grebhahn, S. Kronawitter, S. Kuckuk, H. Rittich,and C. Schmitt, “Exastencils: Advanced stencil-code engineering,” inEuro-Par 2014: Parallel Processing Workshops, 2014, pp. 553–564.

[19] R. Membarth, O. Reiche, F. Hannig, J. Teich, M. Korner, and W. Eckert,“Hipacc: A domain-specific language and compiler for image processing,”IEEE Trans. Parallel Distrib. Syst., vol. 27, no. 1, pp. 210–224, Jan.2016. [Online]. Available: http://dx.doi.org/10.1109/TPDS.2015.2394802

[20] J. Hegarty, J. Brunhaver, Z. DeVito, J. Ragan-Kelley, N. Cohen, S. Bell,A. Vasilyev, M. Horowitz, and P. Hanrahan, “Darkroom: Compilinghigh-level image processing code into hardware pipelines,” ACM Trans.Graph., vol. 33, no. 4, pp. 144:1–144:11, Jul. 2014. [Online]. Available:http://doi.acm.org/10.1145/2601097.2601174

[21] J. Hegarty, R. Daly, Z. DeVito, J. Ragan-Kelley, M. Horowitz, andP. Hanrahan, “Rigel: Flexible multi-rate image processing hardware,”ACM Trans. Graph., vol. 35, no. 4, pp. 85:1–85:11, Jul. 2016. [Online].Available: http://doi.acm.org/10.1145/2897824.2925892

[22] J. Kim, S. Lee, B. Johnston, and J. S. Vetter, “IRIS: A portable runtimesystem exploiting multiple heterogeneous programming systems,” inIEEE High Performance Extreme Computing (HPEC), 2021.

[23] Intel, “Intel Intrinsics Guide,” [Online]. Available: https://software.intel.com/sites/landingpage/IntrinsicsGuide/.

[24] ARM, “ARM Developer: Neon Intrinsics Reference,” [Online]. Avail-able: https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics.

[25] J. S. Vetter, R. Brightwell, M. Gokhale, P. McCormick, R. Ross, J. Shalf,K. Antypas, D. Donofrio, A. Dubey, T. Humble, C. Schuman, B. V. Essen,S. Yoo, A. Aiken, D. Bernholdt, S. Byna, K. Cameron, F. Cappello,B. Chapman, A. Chien, M. Hall, R. Hartman-Baker, Z. Lan, M. Lang,J. Leidel, S. Li, R. Lucas, J. Mellor-Crummey, J. P. Peltz, T. Peterka,M. Strout, and J. Wilke, “Extreme heterogeneity 2018: DOE ASCR basicresearch needs workshop on extreme heterogeneity,” 2018.

[26] J. E. Denny, S. Lee, and J. S. Vetter, “NVL-C: Static analysis techniquesfor efficient, correct programming of non-volatile main memory systems,”in Proceedings of the 25th ACM International Symposium on High-Performance Parallel and Distributed Computing. Kyoto, Japan: ACM,2016, pp. 125–136.

[27] S. Lee and J. S. Vetter, “OpenARC: extensible openACC compilerframework for directive-based accelerator programming study,” inProceedings of the First Workshop on Accelerator Programming usingDirectives (with SC14). New Orleans: IEEE Press, 2014, pp. 1–11.

[28] J. Lambert, S. Lee, J. Vetter, and A. Malony, “CCAMP: An IntegratedTranslation and Optimization Framework for OpenACC and OpenMP,” in2020 SC20: International Conference for High Performance Computing,Networking, Storage and Analysis (SC). Los Alamitos, CA, USA:IEEE Computer Society, nov 2020, pp. 1387–1400. [Online]. Available:https://doi.ieeecomputersociety.org/10.1109/SC41405.2020.00102

[29] J. Lambert, S. Lee, J. Kim, J. S. Vetter, and A. D. Malony, “Directive-based, high-level programming and optimizations for high-performancecomputing with FPGAs,” in ACM International Conference on Super-computing (ICS). Beijing: ACM, 2018.