2015
DOI: 10.1016/j.procs.2015.05.316
|View full text |Cite
|
Sign up to set email alerts
|

OpenCL vs OpenACC: Lessons from Development of Lattice QCD Simulation Code

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
3
1
1

Citation Types

0
5
0

Year Published

2015
2015
2022
2022

Publication Types

Select...
5
2
2

Relationship

0
9

Authors

Journals

citations
Cited by 13 publications
(5 citation statements)
references
References 4 publications
0
5
0
Order By: Relevance
“…This is an update of the result reported in Ref. [10,11]. The run-time parameters for thread grouping are adjusted for each device.…”
Section: Performancementioning
confidence: 96%
See 1 more Smart Citation
“…This is an update of the result reported in Ref. [10,11]. The run-time parameters for thread grouping are adjusted for each device.…”
Section: Performancementioning
confidence: 96%
“…Among available frameworks, OpenCL and OpenACC are attractive because of their portability. Application of OpenCL [7,8,9,10,11] and OpenACC [12,11] to lattice QCD have been started. We note these two frameworks have contrasting features: OpenCL uses explicit API-based controls of the device, while OpenACC is directive-based and a compiler generates procedures to use the device.…”
Section: Introductionmentioning
confidence: 99%
“…the linear equation solver, while keeping the framework and measurement codes of Bridge++ available. This strategy was previously adopted to use GPUs with OpenCL and Ope-nACC [6,7]. We apply this extended-Bridge++ approach to KNL with modifications proper to the many-core and SIMD architecture.…”
Section: Implementation Detailsmentioning
confidence: 99%
“…Recent supercomputers, however, adopt a variety of architecture: multi-core parallel machines with wide SIMD (A64FX and Intel processors), and clusters with accelerator devices such as GPUs, PEZY-SC, and vector processors (NEC SX-Aurora). Soon after the first public release of Bridge++ in 2012 [2], we had started to investigate possible extensions of our code to exploit these new architectures while keeping the readability and portability, as well as to develop tuning techniques for them [3,4,5,6,7,8]. Recently we have constructed a framework to incorporate the tuned codes as an alternative part to the previously developed Bridge++ code, and decided to release it as version 2.0.…”
Section: Introductionmentioning
confidence: 99%