OpenCL standard reaches more wider audience due to increasing the number of devices supporting it. This situation puts developers who want performance on large range of platforms in a di cult position. To solve this problem, autotuning frameworks are deployed. But the problem of design exploration space is seriously large because of OpenCL parameters. In this work, we introduce an approach which uses constraint programming to prune the design space before employing intelligent or exhaustive techniques to explore.
The recent advances in computer architecture made heterogeneous computer systems available to not only data centers and supercomputers but also to commercial personal computers. Especially, with the advent of AMD APUs and Intel CPUs which include integrated GPUs, the heterogeneity of modern machines has increased. Furthermore, enabling discrete GPUs for general purpose computing has added another type of computation device to the system. While each system has provided di erent granularity of parallelism which needs to be properly exploited, the communication between various computation units must also be handled according to the needs of application as well.
Open Computing Language (OpenCL) which is maintained by Khronos
consortium [
One naive solution to performance portability is to develop separate kernel functions for each device the application is supposed to run. This solution makes development of application dramatically complicated when the system is heterogeneous, because of explicit management of multiple command queues and contexts in the presence of multiple vendors on the system.
Performance portability problem of OpenCL applications has been approached
either by tuning of signi cant parameters described as in [
From another perspective, it is not always possible to access these parameters
to tune if they are not being exposed by developers. The work of [
In this work, we introduce an automation of extraction of OpenCL platform
parameters and usage of the information that is gathered to aid the tuning
process described in [
The procedure of autotuning of an OpenCL application in order to get optimum performance without concerns of underlying architecture of the platform requires a set of parameters that de ne characteristics of the machine. In the case of OpenCL, these platform speci c parameters are stated by the OpenCL standard itself. Furthermore, it is possible to gather them using the querying framework which is provided by the OpenCL standard. With these information gathered, it is possible to determine the size of the exploration space and then using intelligent methods for searching optimum design space.
Outside of platform parameters, there might be also application speci c parameters that can be tightly related to platforms capabilities. An example of this situation is well-known tiled version of the matrix multiplication. Size of the tiles are considered as an application parameters and due to nature of the algorithm there is a sharing of information between work-items on the elements of the same tile. Due to OpenCL architecture design, this kind of communication requires local memory to be used. Therefore tile size is directly related to local memory usage which is a limited resource of the platforms.
There are some problems regarding with this approach; design space is larger for even simple applications, for instance, Nvidia Fermi architecture allows up to 1024 work-items for rst and second dimensions and 64 work-item for the third dimension, resulting a 226 di erent con gurations already. Most of the con gurations are not feasible in the sense that the kernel may not even launch or may fail during execution, due to illogical con gurations parameters. Moreover these failed attempts of kernel launches do not provide any information about the sample that has been taken from design space. Hence e ort and time are wasted on these ill-advised con gurations.
In order to address this issue, the work in [
Our work aims to improve the pruning phase by automating the extraction
of platform speci cations, to nd constraints that are valid for all platforms,
so that application programmer only needs to insert constraints related to
application itself. For constraint programming, we used MiniZinc [
In addition to these, a set of constraints that can be deduced from standard
[
workgroupx workgroupy workgroupz <= max total wg (1) { each global work-item dimensions must be multiple of corresponding workgroup dimension size. { total number of work-groups should be equal or greater than number of compute units. Otherwise there will be idle compute units.
globalx=workgroupx + globaly=workgroupy+ globalz=workgroupz >= num compute units globalx%workgroupx == 0 globaly%workgroupy == 0 globalz%workgroupz == 0 (2) (3) 3
In order to test our approach, we used a machine with Intel i7-2630QM which is a quad-core CPU at 2.0Ghz and Nvidia GeForce GT 550M which is a mobile GPU with 96 CUDA cores. For testing purposes, tiled version of matrix multiplication is used and tile size is given as a application parameter and it is been set the interval of [1 : 256]. Furthermore, we have taken into account that application global work size and set it to 4096x4096 matrix for this experiment.
Given this setting, the design space for CPU is 234 and for GPU it is 247. But
after the pruning of infeasible con gurations, there are only 367 con gurations
left for CPU and 421 con gurations for GPU. Considering the result of
pruning for the use case given, it is even possible to search exhaustively all possible
con gurations left to nd the optimal one. However the given example is too
elementary to deduce this conclusion for broader range of applications. Hence, the
next step is to introduce tools to at least one of the industry-proven benchmarks
like OpenDwarfs [