/
adapt16.tex
889 lines (758 loc) · 32.9 KB
/
adapt16.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
% http://www.acm.org/sigs/publications/proceedings-templates
\documentclass{acm_proc_article-sp} % Tested with v3.2SP (April 2009)
\usepackage[hyphens]{url}
\usepackage{graphicx}
\usepackage{booktabs}
\usepackage{rotating}
\begin{document}
\title{{GEMMbench}: a framework for reproducible and collaborative benchmarking
of matrix multiplication}
%
\subtitle{\LARGE \url{https://github.com/dividiti/gemmbench}, \url{http://arxiv.org/abs/1511.03742}}
\numberofauthors{1}
\author{
\alignauthor
Anton Lokhmotov, {\Large \tt dividiti}\\
\email{\Large \url{anton@dividiti.com}}\\
\affaddr{ideaSpace West}\\
\affaddr{3 Charles Babbage Road}\\
\affaddr{Cambridge, CB3 0GT}\\
\affaddr{United Kingdom}\\
}
\maketitle
\begin{abstract}
The generic matrix-matrix multiplication (GEMM) is arguably the most popular
computational kernel of the 20th century.
%
Yet, surprisingly, no common methodology for evaluating GEMM performance
has been established over the many decades of using GEMM for comparing
architectures, compilers and ninja-class programmers.
We introduce GEMMbench, a framework and methodology for evaluating performance
of GEMM implementations.
%
GEMMbench is implemented on top of Collective Knowledge (CK), a lightweight
framework for reproducible and collaborative R\&D in computer systems.
%
Using CK allows the R\&D community to crowdsource hand-written and
compiler-generated GEMM implementations and to study their performance across
multiple platforms, data sizes and data types.
%
Our initial implementation supports hand-written OpenCL kernels operating on
matrices consisting of single- and double-precision floating-point values, and
producing single or multiple output elements per work-item (via thread
coarsening and vectorization).
\end{abstract}
% A category with the (minimum) three required fields
% \category{H.4}{Information Systems Applications}{Miscellaneous}
%A category including the fourth, optional field follows...
% \category{D.2.8}{Software Engineering}{Metrics}[complexity measures, performance measures]
\terms{Software}
%\keywords{ACM proceedings, \LaTeX, text tagging}
%==============================================================================
\section{Motivation}
%==============================================================================
The generic matrix-matrix multiplication (GEMM) is given by the equation:
%
\begin{displaymath} C = \alpha A \times B + \beta C \end{displaymath}
%
\noindent where $A$, $B$ and $C$ are matrices, and $\alpha$ and $\beta$ are
scalars.
GEMM is arguably the most popular computational kernel of the 20th century.
%
The apparent simplicity of GEMM has haunted generation after generation of
researchers who have evaluated its performance on generation after generation
of computer systems,\footnote{Conveniently, both for researchers and computer
systems a generation means 3--4 years.} while uncovering layer after layer of
its hidden complexity.
%
For example, discovering the beneficial effects of cache blocking on GEMM
performance~\cite{Lam:1991} has fuelled research on locality optimizations in
compilers for many years.
%
Yet, surprisingly, no common methodology for evaluating GEMM performance has
been established over the many decades of using this kernel for comparing
architectures, compilers and ninja-class programmers.
%
Consequently, the reader of a report presenting GEMM results is often left wondering:
\begin{itemize}
%
\item Was the kernel specialized, for example, to $C = A \times B$? (In other
words, $\alpha=1$ and $\beta=0$.)
%
\item Which of the data types were used: single precision (SGEMM), double
precision (DGEMM), complex single precision (CGEMM), or complex double
precision (ZGEMM)?
%
\item Which data layouts were used: normal (N) or transposed (T)?\footnote{For
matrices stored in row-major order, $C = \alpha A \times B^{T} + \beta C$
typically results in better locality, because $B^{T}$ is read row-wise.} If
transposed, did the execution time include the overhead for transposition?
%
\item Which data shapes were used: square or rectangular? If rectangular, did
the execution time depend on the ratio between the dimensions?
%
\item Which data sizes were used: small or large?
%
\item On a system with caches, did `large' result in cache thrashing; did
`small' result in good locality (no thrashing)?
%
\item On a heterogeneous system equipped with a discrete accelerator, did the
execution time include the overhead for copying the data to the accelerator and
back, or only the kernel execution time?
%
\item Did the evaluation include power or energy measurements?
%
\item If a diesel generator was used to get the system running, how many
megaflops per gallon were they
getting?\footnote{\url{http://www.hpcwire.com/2006/06/30/the_new_limits_on_high_performance_computing-1/}}
%
\item More seriously, have we achieved significant improvements in energy
efficiency of floating-point operations over the last
decade?\footnote{Manufactured in 2005 on a 130 nm process, ClearSpeed's CSX600
processor provided 25 DGEMM Gflops/s in under 10 Watts according to their
marketing materials.}
%
\item How much human effort and ingenuity was involved in writing the kernel or
in implementing the compiler that generated the kernel?
%
\item Can we compare the generators, for example, based on polyhedral
compilation~\cite{Beaugnon:2014} and functional expression
rewriting~\cite{Steuwer:2015} in a fair way (including code quality, code
generation time and robustness)?
%
\item Can we evaluate the generators against ninja-class
programmers~\cite{Goto:2008} or vendor libraries?
%
\item Have we used all the tricks up our sleeves to get the fastest GEMM
implementation for our hardware and problem at hand?
%
\item Can we {\em adapt} our GEMM implementations to work well across a range
of architectures, data types, data sizes, etc.?
%
\end{itemize}
Given that we are discussing GEMM, a simple kernel intended to
give us insights for solving more complex `real-world' problems, it is
essential to start getting some of the answers right to facilitate our learning
and knowledge sharing.
We introduce GEMMbench, a framework and methodology for evaluating performance
of GEMM implementations.
%
GEMMbench is implemented on top of Collective Knowledge (CK), a lightweight
framework for reproducible and collaborative R\&D in computer systems.%
\footnote{CK is the last in the lineage of frameworks designed by Grigori
Fursin. See \url{http://cknowledge.org}. Its immediate predecessor, Collective
Mind (CM), is described in the following articles~\cite{CollectiveMind,
CollectiveMind2}.}
Our initial implementation supports hand-written OpenCL kernels operating on
matrices consisting of single- and double-precision floating-point values, and
producing single or multiple output elements per work-item (via thread
coarsening and vectorization).
Over time, we plan to involve the community to add further hand-written and
generated kernels (e.g. from \cite{Beaugnon:2014,Steuwer:2015}), and,
importantly, to collectively study the GEMM performance across multiple
platforms, data sizes and data types.
%==============================================================================
\section{Implementation}
\label{sec:implementation}
%==============================================================================
%
The GEMMbench framework reads from a JSON file the metadata describing a
kernel.
%
The JSON file specifies the data type ({\tt S} or {\tt D}), the layout of the
matrices ({\tt N} or {\tt T}), the thread-coarsening configuration ({\tt di}
for the number of rows and {\tt dj} for the number of columns in a block
computed by a single work-item), and so on.
For example, the SGEMM kernel that assumes that $A$ is non-transposed and $B$
is transposed and outputs a single element per work-item:
%
\begin{verbatim}
kernel void gemm(
global float const * restrict A,
global float const * restrict B,
global float * restrict C,
float alpha, float beta, uint n)
{
const uint j = get_global_id(0);
const uint i = get_global_id(1);
float ABij = 0.0f;
for (uint k = 0; k < n; k += 1)
{
ABij += A[i*n + k] * B[j*n + k];
}
C[i*n + j] = alpha * ABij + beta * C[i*n + j];
}
\end{verbatim}
%
is described by the following metadata:
%
\begin{verbatim}
{
"name" : "SGEMM_NT_1x1",
"file" : "SGEMM_NT_1x1.cl",
"type" : "S",
"transA" : "N",
"transB" : "T",
"dj" : 1,
"di" : 1
}
\end{verbatim}
See further examples in the {\tt dataset} entries of the GEMMbench repository.%
\footnote{\url{https://github.com/dividiti/gemmbench/tree/master/dataset}}
%==============================================================================
\section{Installation}
\label{sec:installation}
%==============================================================================
%------------------------------------------------------------------------------
\subsection{Install Collective Knowledge}
%------------------------------------------------------------------------------
Install Collective Knowledge (CK) {\em e.g.}:\footnote{See
\url{http://github.com/ctuning/ck} for alternative instructions.}
%
\begin{verbatim}
$ export CK_REPOS=~/CK
$ mkdir $CK_REPOS
$ export CK_ROOT=$CK_REPOS/ck
$ git clone https://github.com/ctuning/ck.git $CK_ROOT
$ export PATH=$CK_ROOT/bin:$PATH
$ ck status
Your version is up-to-date: V1.6.12
\end{verbatim}
For using CK in Python scripts ({\em e.g.}\ with IPython Notebook):
\begin{verbatim}
$ cd $CK_ROOT && sudo python setup.py install
$ python -c "import ck.kernel as ck;
print ck.version({})['version_str']"
1.6.12
\end{verbatim}
%
%------------------------------------------------------------------------------
\subsection{Install GEMMbench}
%------------------------------------------------------------------------------
Install GEMMbench along with other CK repositories it depends upon: {\tt
ck-autotuning}, {\tt ck-env}, {\em etc.}
%
\begin{verbatim}
$ ck pull repo:gemmbench \
--url=https://github.com/dividiti/gemmbench
\end{verbatim}
%
%------------------------------------------------------------------------------
\subsection{Register OpenCL driver}
%------------------------------------------------------------------------------
Register an (already installed) OpenCL driver {\em e.g.}:
%
\begin{verbatim}
$ ck find soft:lib.opencl*
~/CK/ck-env/soft/lib.opencl.linux
...
$ ck setup soft:lib.opencl.linux
\end{verbatim}
Enter the OpenCL driver version (a string to identify it later). Enter the path
to \verb|libOpenCL.so| without \verb|lib| {\em e.g.} \verb|/usr| for
\verb|libOpenCL.so| in \verb|/usr/lib|.
%------------------------------------------------------------------------------
\subsection{Customize platform scripts}
%------------------------------------------------------------------------------
Take a look at one of the available scripts for disabling frequency and voltage
scaling (DVFS) and fixing the frequencies:
%
\begin{verbatim}
$ ck find platform.init:*
~/CK/ck-autotuning/platform.init/generic-android
~/CK/ck-autotuning/platform.init/chromebook-ubuntu
~/CK/ck-autotuning/platform.init/generic-odroid
~/CK/ck-autotuning/platform.init/generic-linux
\end{verbatim}
Customize the scripts called from {\tt ck-set-performance} (you may leave them
blank initially) and add them to the system path {\em e.g.}:
\begin{verbatim}
$ cp ~/CK/ck-autotuning/platform.init/generic-linux \
~/CK/ck-autotuning/platform.init/my-linux-platform
...
$ export PATH=$PATH:\
~/CK/ck-autotuning/platform.init/my-linux-platform
\end{verbatim}
(Ensure the scripts are executable.)
%------------------------------------------------------------------------------
\subsection{Compile GEMMbench}
%------------------------------------------------------------------------------
To compile GEMMbench:
%
\begin{verbatim}
$ ck compile program:gemmbench-cl-launcher-1.0
\end{verbatim}
%
(The cJSON and xOpenME libraries should be installed automatically the first
time you compile GEMMbench.)
%------------------------------------------------------------------------------
\subsection{Run GEMMbench}
%------------------------------------------------------------------------------
To run GEMMbench with the default parameters:
%
\begin{verbatim}
$ ck run program:gemmbench-cl-launcher-1.0
\end{verbatim}
Select the default command (press ``Enter''), one of the four currently
supported ``flavours'' (SGEMM NN, SGEMM NT, DGEMM NN, DGEMM NT), and finally
one of the kernel variants.
To override the default parameters, use {\em e.g.}
%
\begin{verbatim}
$ ck run program:gemmbench-cl-launcher-1.0 \
--extra_run_cmd="-p 1 -d 1 -n 512 -lws 4,16"
\end{verbatim}
%
to run on platform 1, device 1, with the matrix order of 512 and
the local work size of {\tt (4,16)}.
%------------------------------------------------------------------------------
\subsection{Run SGEMM experiments}
%------------------------------------------------------------------------------
\begin{verbatim}
$ ck find script:SGEMM*
~/CK/gemmbench/script/SGEMM_NT
$ cd ~/CK/gemmbench/script/SGEMM_NT
$ ./_clean_program_pipeline.sh
$ ./_setup_program_pipeline.sh
...
Pipeline is ready!
$ ./explore-f-n.sh
$ ./explore-n-lws.sh
\end{verbatim}
%------------------------------------------------------------------------------
\subsection{How to reproduce?}
\label{sec:reproduce}
%------------------------------------------------------------------------------
To replay our experiments, obtain our experimental data for this paper:
\begin{verbatim}
$ ck pull repo:gemmbench-adapt16 \
--url=https://github.com/dividiti/gemmbench-adapt16
$ ck find experiment:SGEMM_NT*
~/CK/gemmbench-adapt16/experiment/SGEMM_NT-explore-f-n
~/CK/gemmbench-adapt16/experiment/SGEMM_NT-explore-n-lws
\end{verbatim}
Start the CK web server:
\begin{verbatim}
$ ck start web
\end{verbatim}
Open \url{http://localhost:3344} in a web browser.
%
Select {\tt gemmbench-adapt16} in the ``Repository'' dropdown menu.
%
Open {\tt SGEMM\_NT-explore-f-n} or {\tt SGEMM\_NT-explore-n-lws}.%
%
\footnote{You can also go directly to
\url{http://localhost:3344/?wcid=bc0409fb61f0aa82:8bcbe025bd8803c2} or
\url{http://localhost:3344/?wcid=bc0409fb61f0aa82:a697f73cf4392f23}.}
%
Select {\tt gemmbench-view} in the ``Select experiment view'' menu under a QR
code.
%
The table shows one experiment (with a number of statistical repetitions) per
row.
%
Click on a ``Copy to clipboard'' button in the rightmost column to obtain a
command to replay the corresponding experiment.%
\footnote{Section~\ref{sec:evaluation} explains the meaning of most other
columns.}
%
For example, to replay the intermittently failing experiment mentioned in
Section~\ref{sec:validating}, run:
%
\begin{verbatim}
$ ck replay \
experiment:8bcbe025bd8803c2 --point=ca4a5dbe25613c7d
\end{verbatim}
%
%==============================================================================
\section{Evaluation}
\label{sec:evaluation}
%==============================================================================
We demonstrate using the GEMMbench framework for evaluating 3 SGEMM NT
OpenCL kernels on a Hardkernel Odroid~XU3 board (Table~\ref{Odroid}).%
\footnote{\url{http://www.hardkernel.com/main/products/prdt_info.php?g_code=G140448267127}}
%------------------------------------------------------------------------------
\subsection{Evaluation platform}
%------------------------------------------------------------------------------
The Odroid XU3 board has 4 integrated power consumption sensors:
%
\begin{itemize}
\item for the LPDDR3 RAM;
\item for the CPU cluster 0 comprised of 4 ARM Cortex-A7 (``LITTLE'') cores;
\item for the CPU cluster 1 comprised of 4 ARM Cortex-A15 (``big'') cores;
\item for both the GPU cluster 0 and the GPU cluster 1 comprised respectively
of 4 and 2 ARM Mali-T628 cores.
\end{itemize}
%
We reused the {\em pipeline} functionality of the underlying Collective
Knowledge framework to conduct experiments under controlled conditions.
%
We ran the SGEMM kernels on the GPU cluster 0 (OpenCL device 0); we disabled
dynamic voltage and frequency scaling (DVFS) and set the frequency to the
maximum of 600 MHz.
%
Likewise, we set the CPU governors to the performance mode and the CPU
frequencies to the maximum.
%
%------------------------------------------------------------------------------
\subsection{OpenCL kernels}
%------------------------------------------------------------------------------
The SGEMM NT kernels are contained in 3 separate files:
%
\begin{itemize}
\item \verb|SGEMM_NT_1x1.cl|: a na\"ive version shown in
Section~\ref{sec:implementation} which computes a single element of matrix $C$ per
work-item;
\item \verb|SGEMM_NT_4x1.cl|: a vectorised version which computes a vector of
four adjacent elements of matrix $C$ per work-item;
\item \verb|SGEMM_NT_4x1_barrier.cl|: a similarly vectorised version which
synchronises work-items in a work-group with a barrier to improve cache
utilisation~\cite{Gronqvist:2014}.%
\footnote{\url{http://malideveloper.arm.com/downloads/GPU_Pro_5/GronqvistLokhmotov_white_paper.pdf}}
\end{itemize}
%
\begin{table*}
\centering
\caption{\label{Odroid}Experimental platform: Hardkernel Odroid~XU3 board.}
\begin{tabular}{ll}
\toprule
{\bf Hardware} &\\
\midrule
System-on-chip (SoC) & Samsung Exynos 5422 \\
GPU cluster 0 (``device 0'') & ARM Mali-T628, 4 cores, $\le$ 600 MHz \\
GPU cluster 1 (``device 1'') & ARM Mali-T628, 2 cores, $\le$ 600 MHz \\
CPU cluster 0 (``LITTLE'') & ARM Cortex-A7, 4 cores, $\le$ 1400 MHz \\
CPU cluster 1 (``big'') & ARM Cortex-A15, 4 cores, $\le$ 2000 MHz \\
LPDDR3 RAM & 2 GiB, $\le$ 14.9 Gbytes/s \\
\midrule
{\bf Software} &\\
\midrule
Board support package (BSP) & 2015-02-25 \\
Ubuntu Linux & 14.04.1 (updated to 14.04.3) \\
Linux kernel & 3.10.69 \\
OpenCL version & 1.1 Full Profile \\
OpenCL driver & 4.0 (BSP default) \\
Host compiler & Clang++ 3.6 \\
\bottomrule
\end{tabular}
\end{table*}
%------------------------------------------------------------------------------
\subsection{Varying the matrix order}
\label{sec:order}
%------------------------------------------------------------------------------
For the first set of experiments (using the {\tt explore-f-n} script), we
varied the matrix order from 64 to 1024, {\em i.e.}\ performed experiments for
the matrix dimensions ranging from $64 \times 64$ to $1024 \times 1024$.
%
We fixed the OpenCL local work size (work-group size) to $(8,8)$, which,
depending on the register usage, supports up to four concurrently executing
work-groups per Mali-T628 core~\cite{Gronqvist:2014}.
Columns 0--3 of Table~\ref{SGEMM_NT:df} show the raw results in Gflops/s from 4
statistical repetitions (under the same experimental conditions); column 4
shows the mean for each experiment (computed using {\tt pandas.mean()}); column
5 shows the standard deviation (computed using {\tt pandas.std()}).
%
Figure~\ref{SGEMM_NT:plot} shows the means as a bar plot with the error bars
taken from the standard deviations.
Across the matrix orders, the \verb|SGEMM_NT_1x1.cl| program achieved
low but stable performance up to 3 Gflops/s.
%
The \verb|SGEMM_NT_4x1.cl| program achieved over 12 Gflops/s but its
performance dropped dramatically for the matrix orders that were a multiple of
256: 256, 512, 768 and 1024.
%
In addition, it exhibited high performance variation for the matrix orders of
256 and 896.
%
The \verb|SGEMM_NT_4x1_barrier.cl| program achieved up to 11.5
Gflops/s. Importantly, it maintained high performance of 9--10 Gflops/s
for the matrix orders above 256.
\begin{table*}
\centering
\caption{\label{SGEMM_NT:df}The performance of 3 SGEMM NT kernels.}
\input{SGEMM_NT-explore-f-n_tmp.tex}
\end{table*}
\begin{figure*}
\includegraphics[width=\textwidth]{SGEMM_NT-explore-f-n_tmp.pdf}
\caption{The performance of 3 SGEMM NT kernels.}
\label{SGEMM_NT:plot}
\end{figure*}
%------------------------------------------------------------------------------
\subsection{Varying the local work size}
\label{sec:lws}
%------------------------------------------------------------------------------
For the second set of experiments (using the {\tt explore-n-lws} script), we
varied the local work size (work-group size) for the
\verb|SGEMM_NT_4x1_barrier.cl| program and 4 values of the matrix order.
%
Table~\ref{SGEMM_NT:plot:lws} shows a bar plot with the local work size varied
from 16 to 128 work-items per work-group.
%
For page size limits, Figure~\ref{SGEMM_NT:df:lws} shows the raw data only for
the local work size of up to 64 work-items per work-group.
Overall, by exploring the local work size space we were able to achieve up to
$20\%$ performance improvement over our default of $(8,8)$.
%
But rather than using exhaustive search we could guide it from a small number
of experiments, as motivated by the following observations.
Initially, we started exploring the local work size space with the first
dimension $j \ge 2$.
%
We then noticed that using the local work size of $(s_l, s_h)$, where $s_l <
s_h$, was faster than using $(s_h, s_l)$.
%
For example, using $(2, 16)$ was $1.5--3$ times faster than using $(16, 2)$;
using $(1, 16)$ even resulted in the record $11.9$ Gflops/s for this program.
%
We run more experiments with $s_l = 1, 2$ and discerned an interesting pattern:
for small local work sizes (16 and 32), we got the best performance with $s_l =
1$; for larger local work sizes (64 and 128), we got the best performance with
$s_l = 4$.
%
We could use ``predictive analytics'' to discern at least the ``first-order''
effect of the preference for using $(s_l, s_h)$, where $s_l < s_h$, but perhaps
also the ``second-order'' effect.\footnote{This is left as an exercise for the
reader.}
\begin{sidewaysfigure*}
\includegraphics[width=\textheight]{SGEMM_NT-explore-n-lws_tmp.pdf}
\caption{The performance of {\tt SGEMM\_NT\_4x1\_barrier.cl} across work-group sizes with up to 64 work-items.}
\label{SGEMM_NT:plot:lws}
\end{sidewaysfigure*}
\begin{table*}
\centering
\caption{\label{SGEMM_NT:df:lws}The performance of {\tt SGEMM\_NT\_4x1\_barrier.cl} work-group sizes with up to 64 work-items.}
\input{SGEMM_NT-explore-n-lws_tmp.tex}
\end{table*}
%-------------------------------------------------------------------------------
\subsection{Comparing energy consumption}
%-------------------------------------------------------------------------------
Using the integrated sensors on the Odroid XU3 board, we estimated energy
consumption for the program region that launches a kernel and waits for its
completion.\footnote{We used a rather crude method of averaging the power
consumption measurements at the start and end of the region and multiplying the
average by the execution time.}
Table~\ref{SGEMM_NT:df:energy} shows the estimated GPU and memory energy
consumption in Joules across the 3 kernels and 11 matrix orders in our first
set of experiments (Section~\ref{sec:order}).
%
Figure~\ref{SGEMM_NT:plot:energy} focusses on the energy consumption for the
orders from 384 to 1024.
For the orders of 128 and 384, when the vectorised kernels match in
performance, they also match in energy consumption.
%
For the order of 1024, however, the non-cache optimised kernel is a disaster:
%
the cache-optimised vectorised kernel is $6$ times faster and $40$ times more
energy efficient both for the GPU and the RAM;
%
even the non-vectorised kernel is $75\%$ faster, $10\%$ more energy efficient
for the GPU and $5$ times for the RAM.
\begin{table*}
\centering
\caption{\label{SGEMM_NT:df:energy}The GPU \& memory energy consumption of 3 SGEMM NT kernels.}
\input{SGEMM_NT-explore-f-n-energy-gpu-mem_tmp.tex}
\end{table*}
\begin{figure*}
\includegraphics[width=\textwidth]{SGEMM_NT-explore-f-n-energy-gpu-mem_tmp.pdf}
\caption{The GPU \& memory energy consumption of 3 SGEMM NT kernels.}
\label{SGEMM_NT:plot:energy}
\end{figure*}
%-------------------------------------------------------------------------------
\subsection{Validating the results}
\label{sec:validating}
%-------------------------------------------------------------------------------
No benchmark should be complete without checking the results for correctness.
%
GEMMbench includes a reference CPU implementation that an OpenCL
implementation's results are compared against.
%
Since GEMM operates on floating-point data, the results cannot be expected to be
bit-exact.
%
Instead, the results are compared element-wise using a small {\em epsilon}
value $\epsilon$.
Initially, we chose $\epsilon = 10^{-5}$.
%
Early in the development, we accidentally used the integer \verb|abs()|
function instead of the floating-point \verb|fabs()| function.
%
As a result, element-wise discrepancies not exceeding $1.0$ would frequently go
unnoticed.
%
Once that issue was fixed, we realised that $\epsilon = 10^{-5}$ was too small
a value when operating on single-precision floating-point data.
%
Empirically, we found that $\epsilon = 0.1$ worked well in practice when the
elements of the input matrices were drawn from the uniform distribution over
the range $(-0.5, +0.5)$.
%
Table~\ref{SGEMM_NT:df:match} shows the maximum absolute difference found via
the element-wise comparison and whether the results match under the chosen
$\epsilon = 0.1$ for our first set of experiments (Section~\ref{sec:order}).
\begin{sidewaystable*}
\centering
\caption{\label{SGEMM_NT:df:match}The validation of 3 SGEMM NT kernels: {\tt pandas} DataFrame with raw results.}
\input{SGEMM_NT-explore-f-n-match_tmp.tex}
\end{sidewaystable*}
For the \verb|SGEMM_NT_1x1.cl| program and the matrix order of 64, no results
matched.
%
In fact, the maximum absolute differences suggest a possible bug in either the
OpenCL or the reference implementation. (Neither has been around for long or
code-reviewed.)
For the \verb|SGEMM_NT_4x1.cl| program and the matrix order of 64, the results
are mixed: they twice matched and twice did not.
%
The failures may be difficult to debug, since they are intermittent.
%
Luckily, replaying an experimental point under the Collective Knowledge
framework is a matter of running a single command\footnote{See the end of
Section~\ref{sec:reproduce} for the command to replay this very experiment.}
which would help investigate the failures and quickly test potential solutions.
For the \verb|SGEMM_NT_4x1_barrier.cl| program, the results show repeatable
failures for the orders of 64, 96, 192.
%
This may give us a clue to what goes wrong here.
Returning to choosing the value of $\epsilon$, we note that these results would pass
under $\epsilon = 0.2$.
%
It is likely, however, that even this $\epsilon$ would need to be changed had
the input values been drawn from a different distribution {\em e.g.}\ the
uniform distribution over the range $(-5.0, +5.0)$.
Rather than making an arbitrary choice of $\epsilon$ for an arbitrary choice of
the random distribution, we could look into defining representative datasets.
%
Ideally, they would come from real-world problems along with precision
requirements.
%
%===============================================================================
\section{Conclusion and outlook}
%===============================================================================
We have presented GEMMbench, a framework and methodology for systematically
evaluating performance of matrix multiplication implementations.
%
Our initial implementation supports hand-written OpenCL kernels, producing
single or multiple output elements per work-item (via thread coarsening and
vectorization).
%
Our goal is to involve the community to extend GEMMbench to evaluate
performance of compiler-generated OpenCL kernels, non-OpenCL implementations,
library implementations and so on, across many target platforms.
%
To this end, the underlying Collective Knowledge framework provides unique
opportunities for the community to gradually gather and share valuable
knowledge for optimizing performance of matrix multiplication and other
programs, as well as of compilers and processors.
%
We will build upon other strengths of the Collective Knowledge framework including
support for multiple operating systems (Windows, Linux, Android and MacOS),
compilers (LLVM, GCC, ICC, MSVC, {\em etc.}) and interfaces to packages for
data mining and predictive analytics.
Where do we start?
%
First, we encourage the interested reader help us investigate the failures
reported in Section~\ref{sec:validating}.
%
Eric S.\ Raymond's proposition that ``given enough eyeballs, all bugs are
shallow''\footnote{\url{https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar}}
should apply well in this case.
%
Indeed, some of the failures may have nothing to do with numerical
(in)stability.
%
Programming errors (such as tacit assumptions) may be detected with static and
dynamic analysis tools such as GPUVerify~\cite{GPUVerify} and
Oclgrind~\cite{Oclgrind}.
%
In the final version of this article, we will acknowledge those who help us
explain the existing failures and perhaps find new ones, and of course fix them.
Second, we welcome contributions in the form of experimental data in the
Collective Knowledge format.
%
The contributors should acknowledge their compliance with the terms of use of
their systems, specifically that they do not breach confidentiality.%
\footnote{Note that such terms are easy to overlook. For example, from a
vendor's click-through end-user license agreement: ``BENCHMARKING: This Licence
does not prevent you from using the Software for internal benchmarking
purposes. However, you shall treat any and all benchmarking data relating to
the Software, and any other results of your use or testing of the Software
which are indicative of its performance, efficacy, reliability or quality, as
confidential information and you shall not disclose such information to any
third party without the express written permission of VENDOR.'' Similar terms
have prevented us from sharing results from other platforms in
Section~\ref{sec:evaluation}. As far as we are aware, the standard Hardkernel
BSP is distributed without such limitations.}
%
Third, we welcome contributions in the form of improvements for the core
GEMMbench code {\em e.g.}\ support for rectangular matrices and complex
floating-point numbers.
Fourth, we welcome contributions in the form of OpenCL kernels or other
implementations.
%
The initial set of kernels optimised for the ARM Mali-T600 architecture is
intentionally small.
%
We would like to see contributed kernels optimised for different architectures.
%
The contributors should acknowledge their copyright in the source
code\footnote{No direct copying from vendors' SDKs or programming guides
please.} and specify the licensing terms.\footnote{The standard Collective
Knowledge license (3-clause BSD) is preferred.}
%
Fifth, we welcome contributions in the form of representative datasets or
their descriptions.
We envision GEMMbench to inspire community-driven development of other
representative workloads for use in performance evaluation and optimisation of
computer systems.
%===============================================================================
\section{Acknowledgments and more}
%===============================================================================
We thank Grigori Fursin, CTO of {\tt dividiti} and Chief Scientist of the
cTuning foundation, for designing and implementing the Collective
Knowledge framework, on top of which we implemented GEMMbench.
We look forward to the public discussion of this draft and hope to get useful
feedback and contributions from the community, which will be acknowledged in
the final version of this article.
%-------------------------------------------------------------------------------
\bibliographystyle{abbrv}
\bibliography{adapt16}
\appendix
%===============================================================================
\section{Sharing experimental results}
%===============================================================================
Sharing GEMMbench experimental results is easy!
First, run a GEMMbench script {\em e.g.}\ {\tt explore-f-n}, creating locally
an experiment entry in \verb|~/CK/local/experiment| {\em e.g.} {\tt
SGEMM\_NT\-explore-f-n}.
Second, create an empty Git repository on GitHub or elsewhere, and pull from
its URL {\em e.g.}\
%
\begin{verbatim}
$ ck pull repo:gemmbench-new \
--url=<new repository's URL>
\end{verbatim}
%
Third, move or copy your experiments from the local repository to the new repository {\em e.g.}\
%
\begin{verbatim}
$ ck mv experiment:SGEMM_NT-explore-f-n \
gemmbench-new:experiment:SGEMM_NT-explore-f-n
\end{verbatim}
%
Optionally, provide a license file and update further details in {\tt
.cm/info.json} and {\tt .cm/meta.json} in your experimental entries.
%
(If not provided, the standard CK license and copyright details will apply.)
Finally, commit all the files:
%
\begin{verbatim}
$ cd `ck find repo:gemmbench-new`
$ git add -A
$ git commit -m "New GEMMbench experiments."
\end{verbatim}
%
Please do not forget to send us a link to your new repository! We will maintain a list
of such repositories for the community to access, similarly to this paper's
repository (Section~\ref{sec:reproduce}).
\balancecolumns
\end{document}