Toward an Analytical Performance Model to Select between GPU and CPU Execution

Chikin, Artem; Amaral, José Nelson; Ali, Karim; Tiotto, Ettore

doi:10.1109/ipdpsw.2019.00068

Cited by 6 publications

(4 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Two co-execution schemes are extensively used in the literature: data partitioning and task partitioning. Tasks partitioning has been carried out offline using performance analytical models [3] or using machine learning-based approaches [6,10,13,17]. OpenABLext [30], an extension of the OpenABL framework, carries out an online partitioning of the workload.…”

Section: Related Workmentioning

confidence: 99%

“…We based the evaluation on an extended version of OpenABL which supports generating OpenCL code. 3 Despite the fact that data transfer overhead was avoided, co-execution was not feasible for the tested applications on the iCPU-GPU system. Similarly to the MV application, this is caused by the large performance deviation between the CPU and the iGPU.…”

Section: Case Study 2: Openablmentioning

confidence: 99%

See 1 more Smart Citation

OptCL: A Middleware to Optimise Performance for High Performance Domain-Specific Languages on Heterogeneous Platforms

Xiao

Andelfinger

Cai

et al. 2022

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Programming on heterogeneous hardware architectures using OpenCL requires thorough knowledge of the hardware. Many High-Performance Domain-Specific Languages (HPDSLs) are aimed at simplifying the programming efforts by abstracting away hardware details, allowing users to program in a sequential style. However, most HPDSLs still require the users to manually map compute workloads to the best suitable hardware to achieve optimal performance. This again calls for knowledge of the underlying hardware and trial-and-error attempts. Further, very often they only consider an offloading mode where computeintensive tasks are offloaded to accelerators. During this offloading period, CPUs remain idle, leaving parts of the available computational power untapped. In this work, we propose a tool named OptCL for existing HPDSLs to enable a heterogeneous co-execution mode when capable where CPUs and accelerators can process data simultaneously. Through a static analysis of data dependencies among compute-intensive code regions and performance predictions, the tool selects the best execution schemes out of purely CPU/accelerator execution or co-execution. We show that by enabling co-execution on dedicated and integrated CPU-GPU systems up to 13× and 21× speed-ups can be achieved.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Case Study 2: Openablmentioning

confidence: 99%

OptCL: A Middleware to Optimise Performance for High Performance Domain-Specific Languages on Heterogeneous Platforms

Xiao

Andelfinger

Cai

et al. 2022

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…First, we plan to develop an approach that automatically determines the worklist size for a given program and device for ReexeStrategy. Second, it would be worth studying how to select the appropriate device for exploration [Chikin et al 2019]. Third, we plan on finding the optimal memory layout for our worklists [Franco et al 2017;Majeti et al 2016].…”

Section: Limitations and Future Workmentioning

confidence: 99%

Programming and execution models for parallel bounded exhaustive testing

Awar

Jain

Rossbach

et al. 2021

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Bounded-exhaustive testing (BET), which exercises a program under test for all inputs up to some bounds, is an effective method for detecting software bugs. Systematic property-based testing is a BET approach where developers write test generation programs that describe properties of test inputs. Hybrid test generation programs offer the most expressive way to write desired properties by freely combining declarative filters and imperative generators. However, exploring hybrid test generation programs, to obtain test inputs, is both computationally demanding and challenging to parallelize. We present the first programming and execution models, dubbed Tempo, for parallel exploration of hybrid test generation programs. We describe two different strategies for mapping the computation to parallel hardware and implement them both for GPUs and CPUs. We evaluated Tempo by generating instances of various data structures commonly used for benchmarking in the BET domain. Additionally, we generated CUDA programs to stress test CUDA compilers, finding four bugs confirmed by the developers.

show abstract

“…Here, as in other auto-parallelization the importance of augmenting static analysis with runtime values is recognised, e.g. [9]. This approach compiles parallel CPU and GPU code for the loop nest and uses a staged cost model to select what code to run.…”

Section: Related Workmentioning

confidence: 99%

Pricing Python parallelism: a dynamic language cost model for heterogeneous platforms

Jacob

Trinder

Singer

2020

Proceedings of the 16th ACM SIGPLAN International Symposium on Dynamic Languages

View full text Add to dashboard Cite

Execution times may be reduced by offloading parallel loop nests to a GPU. Auto-parallelizing compilers are common for static languages, often using a cost model to determine when the GPU execution speed will outweigh the offload overheads. Nowadays scientific software is increasingly written in dynamic languages and would benefit from compute accelerators. The ALPyNA framework analyses moderately complex Python loop nests and automatically JIT compiles code for heterogeneous CPU and GPU architectures.We present the first analytical cost model for auto-parallelizing loop nests in a dynamic language on heterogeneous architectures. Predicting execution time in a language like Python is extremely challenging, since aspects like the element types, size of the iteration space, and amenability to parallelization can only be determined at runtime. Hence the cost model must be both staged, to combine compile and run-time information, and lightweight to minimize runtime overhead. GPU execution time prediction must account for factors like data transfer, block-structured execution, and starvation.We show that a comparatively simple, staged analytical model can accurately determine during execution when it is profitable to offload a loop nest. We evaluate our model on three heterogeneous platforms across 360 experiments with 12 loop-intensive Python benchmark programs. The results show small misprediction intervals and a mean slowdown of just 13.6%, relative to the optimal (oracular) offload strategy.CCS Concepts: • Software and its engineering → Dynamic compilers; Just-in-time compilers; • Computer systems organization → Heterogeneous (hybrid) systems.

show abstract

Toward an Analytical Performance Model to Select between GPU and CPU Execution

Cited by 6 publications

References 29 publications

OptCL: A Middleware to Optimise Performance for High Performance Domain-Specific Languages on Heterogeneous Platforms

OptCL: A Middleware to Optimise Performance for High Performance Domain-Specific Languages on Heterogeneous Platforms

Programming and execution models for parallel bounded exhaustive testing

Pricing Python parallelism: a dynamic language cost model for heterogeneous platforms

Contact Info

Product

Resources

About