forked from graph500/graph500
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathGraph500.html
1162 lines (1050 loc) · 38.2 KB
/
Graph500.html
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
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Graph 500 Benchmark 1 ("Search")</title>
<!-- 2015-07-27 Mon 01:20 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="generator" content="Org-mode" />
<meta name="author" content="Graph 500 Steering Committee" />
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
.title { text-align: center; }
.todo { font-family: monospace; color: red; }
.done { color: green; }
.tag { background-color: #eee; font-family: monospace;
padding: 2px; font-size: 80%; font-weight: normal; }
.timestamp { color: #bebebe; }
.timestamp-kwd { color: #5f9ea0; }
.right { margin-left: auto; margin-right: 0px; text-align: right; }
.left { margin-left: 0px; margin-right: auto; text-align: left; }
.center { margin-left: auto; margin-right: auto; text-align: center; }
.underline { text-decoration: underline; }
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
p.verse { margin-left: 3%; }
pre {
border: 1px solid #ccc;
box-shadow: 3px 3px 3px #eee;
padding: 8pt;
font-family: monospace;
overflow: auto;
margin: 1.2em;
}
pre.src {
position: relative;
overflow: visible;
padding-top: 1.2em;
}
pre.src:before {
display: none;
position: absolute;
background-color: white;
top: -10px;
right: 10px;
padding: 3px;
border: 1px solid black;
}
pre.src:hover:before { display: inline;}
pre.src-sh:before { content: 'sh'; }
pre.src-bash:before { content: 'sh'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-R:before { content: 'R'; }
pre.src-perl:before { content: 'Perl'; }
pre.src-java:before { content: 'Java'; }
pre.src-sql:before { content: 'SQL'; }
table { border-collapse:collapse; }
caption.t-above { caption-side: top; }
caption.t-bottom { caption-side: bottom; }
td, th { vertical-align:top; }
th.right { text-align: center; }
th.left { text-align: center; }
th.center { text-align: center; }
td.right { text-align: right; }
td.left { text-align: left; }
td.center { text-align: center; }
dt { font-weight: bold; }
.footpara:nth-child(2) { display: inline; }
.footpara { display: block; }
.footdef { margin-bottom: 1em; }
.figure { padding: 1em; }
.figure p { text-align: center; }
.inlinetask {
padding: 10px;
border: 2px solid gray;
margin: 10px;
background: #ffffcc;
}
#org-div-home-and-up
{ text-align: right; font-size: 70%; white-space: nowrap; }
textarea { overflow-x: auto; }
.linenr { font-size: smaller }
.code-highlighted { background-color: #ffff00; }
.org-info-js_info-navigation { border-style: none; }
#org-info-js_console-label
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
.org-info-js_search-highlight
{ background-color: #ffff00; color: #000000; font-weight: bold; }
/*]]>*/-->
</style>
<script type="text/javascript">
/*
@licstart The following is the entire license notice for the
JavaScript code in this tag.
Copyright (C) 2012-2013 Free Software Foundation, Inc.
The JavaScript code in this tag is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
@licend The above is the entire license notice
for the JavaScript code in this tag.
*/
<!--/*--><![CDATA[/*><!--*/
function CodeHighlightOn(elem, id)
{
var target = document.getElementById(id);
if(null != target) {
elem.cacheClassElem = elem.className;
elem.cacheClassTarget = target.className;
target.className = "code-highlighted";
elem.className = "code-highlighted";
}
}
function CodeHighlightOff(elem, id)
{
var target = document.getElementById(id);
if(elem.cacheClassElem)
elem.className = elem.cacheClassElem;
if(elem.cacheClassTarget)
target.className = elem.cacheClassTarget;
}
/*]]>*///-->
</script>
</head>
<body>
<div id="content">
<h1 class="title">Graph 500 Benchmark 1 ("Search")</h1>
<div id="table-of-contents">
<h2>Table of Contents</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#sec-1">1. Brief Description of the Graph 500 Benchmark</a>
<ul>
<li><a href="#sec-1-1">1.1. References</a></li>
</ul>
</li>
<li><a href="#sec-2">2. Overall Benchmark</a></li>
<li><a href="#sec-3">3. Generating the Edge List</a>
<ul>
<li><a href="#sec-3-1">3.1. Brief Description</a></li>
<li><a href="#sec-3-2">3.2. Detailed Text Description</a></li>
<li><a href="#sec-3-3">3.3. Sample High-Level Implementation of the Kronecker Generator</a></li>
<li><a href="#sec-3-4">3.4. Parameter Settings</a></li>
<li><a href="#sec-3-5">3.5. References</a></li>
</ul>
</li>
<li><a href="#sec-4">4. Kernel 1 – Graph Construction</a>
<ul>
<li><a href="#sec-4-1">4.1. Description</a></li>
<li><a href="#sec-4-2">4.2. References</a></li>
</ul>
</li>
<li><a href="#sec-5">5. Sampling 64 Search Keys</a></li>
<li><a href="#sec-6">6. Kernel 2 – Breadth-First Search</a>
<ul>
<li><a href="#sec-6-1">6.1. Description</a></li>
<li><a href="#sec-6-2">6.2. Kernel 2 Output</a></li>
</ul>
</li>
<li><a href="#sec-7">7. Validation</a></li>
<li><a href="#sec-8">8. Computing and Outputting Performance Information</a>
<ul>
<li><a href="#sec-8-1">8.1. Timing</a></li>
<li><a href="#sec-8-2">8.2. Performance Metric (TEPS)</a></li>
<li><a href="#sec-8-3">8.3. Output</a></li>
<li><a href="#sec-8-4">8.4. References</a></li>
</ul>
</li>
<li><a href="#sec-9">9. Sample Driver</a></li>
<li><a href="#sec-10">10. Evaluation Criteria</a></li>
</ul>
</div>
</div>
<p>
Contributors: David A. Bader (Georgia Institute of Technology),
Jonathan Berry (Sandia National Laboratories), Simon Kahan (Pacific
Northwest National Laboratory and University of Washington), Richard
Murphy (Micron Technology), E. Jason Riedy (Georgia
Institute of Technology), and Jeremiah Willcock (Indiana University).
</p>
<p>
Version History:
</p>
<dl class="org-dl">
<dt> V0.1 </dt><dd>Draft, created 28 July 2010
</dd>
<dt> V0.2 </dt><dd>Draft, created 29 September 2010
</dd>
<dt> V0.3 </dt><dd>Draft, created 30 September 2010
</dd>
<dt> V1.0 </dt><dd>Created 1 October 2010
</dd>
<dt> V1.1 </dt><dd>Created 3 October 2010
</dd>
<dt> V1.2 </dt><dd>Created 15 September 2011
</dd>
</dl>
<p>
Version 0.1 of this document was part of the Graph 500 community
benchmark effort, led by Richard Murphy (Micron Technology). The
intent is that there will be at least three variants of
implementations, on shared memory and threaded systems, on distributed
memory clusters, and on external memory map-reduce clouds. This
specification is for the first of potentially several benchmark
problems.
</p>
<p>
References: "Introducing the Graph 500," Richard C. Murphy, Kyle
B. Wheeler, Brian W. Barrett, James A. Ang, Cray User's Group (CUG),
May 5, 2010.
</p>
<p>
"DFS: A Simple to Write Yet Difficult to Execute Benchmark," Richard
C. Murphy, Jonathan Berry, William McLendon, Bruce Hendrickson,
Douglas Gregor, Andrew Lumsdaine, IEEE International Symposium on
Workload Characterizations 2006 (IISWC06), San Jose, CA, 25-27 October
</p>
<ol class="org-ol">
<li></li>
</ol>
<div id="outline-container-sec-1" class="outline-2">
<h2 id="sec-1"><span class="section-number-2">1</span> Brief Description of the Graph 500 Benchmark</h2>
<div class="outline-text-2" id="text-1">
<p>
Data-intensive supercomputer applications are an increasingly
important workload, but are ill-suited for platforms designed for 3D
physics simulations. Application performance cannot be improved
without a meaningful benchmark. Graphs are a core part of most
analytics workloads. Backed by a steering committee of over 30
international HPC experts from academia, industry, and national
laboratories, this specification establishes a large-scale benchmark
for these applications. It will offer a forum for the community and
provide a rallying point for data-intensive supercomputing
problems. This is the first serious approach to augment the Top 500
with data-intensive applications.
</p>
<p>
The intent of this benchmark problem ("Search") is to develop a
compact application that has multiple analysis techniques (multiple
kernels) accessing a single data structure representing a weighted,
undirected graph. In addition to a kernel to construct the graph from
the input tuple list, there is one additional computational
kernel to operate on the graph.
</p>
<p>
This benchmark includes a scalable data generator which produces edge
tuples containing the start vertex and end vertex for each
edge. The first kernel constructs an <i>undirected</i> graph in a format
usable by all subsequent kernels. No subsequent modifications are
permitted to benefit specific kernels. The second kernel performs a
breadth-first search of the graph. Both kernels are timed.
</p>
<p>
There are five problem classes defined by their input size:
</p>
<dl class="org-dl">
<dt> toy </dt><dd>17GB or around 10<sup>10</sup> bytes, which we also call level 10,
</dd>
<dt> mini </dt><dd>140GB (10<sup>11</sup> bytes, level 11),
</dd>
<dt> small </dt><dd>1TB (10<sup>12</sup> bytes, level 12),
</dd>
<dt> medium </dt><dd>17TB (10<sup>13</sup> bytes, level 13),
</dd>
<dt> large </dt><dd>140TB (10<sup>14</sup> bytes, level 14), and
</dd>
<dt> huge </dt><dd>1.1PB (10<sup>15</sup> bytes, level 15).
</dd>
</dl>
<p>
Table <a href="#tbl:classes">2</a> provides the parameters used by the graph
generator specified below.
</p>
</div>
<div id="outline-container-sec-1-1" class="outline-3">
<h3 id="sec-1-1"><span class="section-number-3">1.1</span> References</h3>
<div class="outline-text-3" id="text-1-1">
<p>
D.A. Bader, J. Feo, J. Gilbert, J. Kepner, D. Koester, E. Loh,
K. Madduri, W. Mann, Theresa Meuse, HPCS Scalable Synthetic Compact
Applications #2 Graph Analysis (SSCA#2 v2.2 Specification), 5
September 2007.
</p>
</div>
</div>
</div>
<div id="outline-container-sec-2" class="outline-2">
<h2 id="sec-2"><span class="section-number-2">2</span> Overall Benchmark</h2>
<div class="outline-text-2" id="text-2">
<p>
The benchmark performs the following steps:
</p>
<ol class="org-ol">
<li>Generate the edge list.
</li>
<li>Construct a graph from the edge list (<b>timed</b>, kernel 1).
</li>
<li>Randomly sample 64 unique search keys with degree at least one,
not counting self-loops.
</li>
<li>For each search key:
<ol class="org-ol">
<li>Compute the parent array (<b>timed</b>, kernel 2).
</li>
<li>Validate that the parent array is a correct BFS search tree
for the given search tree.
</li>
</ol>
</li>
<li>Compute and output performance information.
</li>
</ol>
<p>
Only the sections marked as <b>timed</b> are included in the performance
information. Note that all uses of "random" permit pseudorandom
number generation.
</p>
</div>
</div>
<div id="outline-container-sec-3" class="outline-2">
<h2 id="sec-3"><span class="section-number-2">3</span> Generating the Edge List</h2>
<div class="outline-text-2" id="text-3">
</div><div id="outline-container-sec-3-1" class="outline-3">
<h3 id="sec-3-1"><span class="section-number-3">3.1</span> Brief Description</h3>
<div class="outline-text-3" id="text-3-1">
<p>
The scalable data generator will construct a list of edge tuples
containing vertex identifiers. Each edge is undirected with its
endpoints given in the tuple as StartVertex and EndVertex.
</p>
<p>
The intent of the first kernel below is to convert a list with no
locality into a more optimized form. The generated list of input
tuples must not exhibit any locality that can be exploited by the
computational kernels. Thus, the vertex numbers must be randomized
and a random ordering of tuples must be presented to kernel 1.
The data generator may be parallelized, but the vertex names
must be globally consistent and care must be taken to minimize effects
of data locality at the processor level.
</p>
</div>
</div>
<div id="outline-container-sec-3-2" class="outline-3">
<h3 id="sec-3-2"><span class="section-number-3">3.2</span> Detailed Text Description</h3>
<div class="outline-text-3" id="text-3-2">
<p>
The edge tuples will have the form <StartVertex, EndVertex> where
StartVertex is one endpoint vertex label and EndVertex is the
other endpoint vertex label. The space of labels is the set of integers
beginning with <b>zero</b> up to but not including the number of vertices N
(defined below). The kernels are not provided the size N explicitly
but must discover it.
</p>
<p>
The input values required to describe the graph are:
</p>
<dl class="org-dl">
<dt> SCALE </dt><dd>The logarithm base two of the number of vertices.
</dd>
<dt> edgefactor </dt><dd>The ratio of the graph's edge count to its vertex count (i.e.,
half the average degree of a vertex in the graph).
</dd>
</dl>
<p>
These inputs determine the graph's size:
</p>
<dl class="org-dl">
<dt> N </dt><dd>the total number of vertices, 2<sup>SCALE</sup>. An implementation may
use any set of N distinct integers to number the vertices, but at
least 48 bits must be allocated per vertex number. Other parameters
may be assumed to fit within the natural word of the machine. N is
derived from the problem's scaling parameter.
</dd>
<dt> M </dt><dd>the number of edges. M = edgefactor * N.
</dd>
</dl>
<p>
The graph generator is a Kronecker generator similar to the Recursive
MATrix (R-MAT) scale-free graph generation algorithm [Chakrabarti, et
al., 2004]. For ease of discussion, the description of this R-MAT
generator uses an adjacency matrix data structure; however,
implementations may use any alternate approach that outputs the
equivalent list of edge tuples. This model recursively sub-divides the
adjacency matrix of the graph into four equal-sized partitions and
distributes edges within these partitions with unequal
probabilities. Initially, the adjacency matrix is empty, and edges are
added one at a time. Each edge chooses one of the four partitions with
probabilities A, B, C, and D, respectively. These probabilities, the
initiator parameters, are provided in Table <a href="#tbl:initiator">1</a>.
</p>
<table id="tbl:initiator" border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">
<caption class="t-above"><span class="table-number">Table 1:</span> Initiator parameters for the Kronecker graph generator</caption>
<colgroup>
<col class="left" />
<col class="left" />
</colgroup>
<tbody>
<tr>
<td class="left">A = 0.57</td>
<td class="left">B = 0.19</td>
</tr>
<tr>
<td class="left">C = 0.19</td>
<td class="left">D = 1-(A+B+C) = 0.05</td>
</tr>
</tbody>
</table>
<p>
The next section details a high-level implementation for this
generator. High-performance, parallel implementations are included in
the reference implementation.
</p>
<p>
The graph generator creates a small number of multiple edges between
two vertices as well as self-loops. Multiple edges, self-loops, and
isolated vertices may be ignored in the subsequent kernels but must
be included in the edge list provided to the first kernel. The
algorithm also generates the data tuples with high degrees of
locality. Thus, as a final step, vertex numbers must be randomly
permuted, and then the edge tuples randomly shuffled.
</p>
<p>
It is permissible to run the data generator in parallel. In this case,
it is necessary to ensure that the vertices are named globally, and
that the generated data does not possess any locality, either in local memory
or globally across processors.
</p>
<p>
The scalable data generator should be run before starting kernel 1, storing its
results to either RAM or disk.
If stored to disk, the data may be retrieved before
starting kernel 1. The data generator and retrieval operations need not be
timed.
</p>
</div>
</div>
<div id="outline-container-sec-3-3" class="outline-3">
<h3 id="sec-3-3"><span class="section-number-3">3.3</span> Sample High-Level Implementation of the Kronecker Generator</h3>
<div class="outline-text-3" id="text-3-3">
<p>
The GNU Octave routine in Algorithm <a href="#alg:generator">1</a> is an
attractive implementation in that it is embarrassingly parallel and
does not require the explicit formation of the adjacency matrix.
</p>
<div class="org-src-container">
<label class="org-src-name">High-level generator code</label>
<pre class="src src-Octave" id="alg:generator">function ij = kronecker_generator (SCALE, edgefactor)
%% Generate an edgelist according to the Graph500
%% parameters. In this sample, the edge list is
%% returned in an array with two rows, where StartVertex
%% is first row and EndVertex is the second. The vertex
%% labels start at zero.
%%
%% Example, creating a sparse matrix for viewing:
%% ij = kronecker_generator (10, 16);
%% G = sparse (ij(1,:)+1, ij(2,:)+1, ones (1, size (ij, 2)));
%% spy (G);
%% The spy plot should appear fairly dense. Any locality
%% is removed by the final permutations.
%% Set number of vertices.
N = 2^SCALE;
%% Set number of edges.
M = edgefactor * N;
%% Set initiator probabilities.
[A, B, C] = deal (0.57, 0.19, 0.19);
%% Create index arrays.
ij = ones (2, M);
%% Loop over each order of bit.
ab = A + B;
c_norm = C/(1 - (A + B));
a_norm = A/(A + B);
for ib = 1:SCALE,
%% Compare with probabilities and set bits of indices.
ii_bit = rand (1, M) > ab;
jj_bit = rand (1, M) > ( c_norm * ii_bit + a_norm * not (ii_bit) );
ij = ij + 2^(ib-1) * [ii_bit; jj_bit];
end
%% Permute vertex labels
p = randperm (N);
ij = p(ij);
%% Permute the edge list
p = randperm (M);
ij = ij(:, p);
%% Adjust to zero-based labels.
ij = ij - 1;
</pre>
</div>
</div>
</div>
<div id="outline-container-sec-3-4" class="outline-3">
<h3 id="sec-3-4"><span class="section-number-3">3.4</span> Parameter Settings</h3>
<div class="outline-text-3" id="text-3-4">
<p>
The input parameter settings for each class are given in Table <a href="#tbl:classes">2</a>.
</p>
<table id="tbl:classes" border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">
<caption class="t-above"><span class="table-number">Table 2:</span> Problem class definitions and required storage for the edge list assuming 64-bit integers.</caption>
<colgroup>
<col class="left" />
<col class="right" />
<col class="right" />
<col class="right" />
</colgroup>
<thead>
<tr>
<th scope="col" class="left">Problem class</th>
<th scope="col" class="right">Scale</th>
<th scope="col" class="right">Edge factor</th>
<th scope="col" class="right">Approx. storage size in TB</th>
</tr>
</thead>
<tbody>
<tr>
<td class="left">Toy (level 10)</td>
<td class="right">26</td>
<td class="right">16</td>
<td class="right">0.0172</td>
</tr>
<tr>
<td class="left">Mini (level 11)</td>
<td class="right">29</td>
<td class="right">16</td>
<td class="right">0.1374</td>
</tr>
<tr>
<td class="left">Small (level 12)</td>
<td class="right">32</td>
<td class="right">16</td>
<td class="right">1.0995</td>
</tr>
<tr>
<td class="left">Medium (level 13)</td>
<td class="right">36</td>
<td class="right">16</td>
<td class="right">17.5922</td>
</tr>
<tr>
<td class="left">Large (level 14)</td>
<td class="right">39</td>
<td class="right">16</td>
<td class="right">140.7375</td>
</tr>
<tr>
<td class="left">Huge (level 15)</td>
<td class="right">42</td>
<td class="right">16</td>
<td class="right">1125.8999</td>
</tr>
</tbody>
</table>
</div>
</div>
<div id="outline-container-sec-3-5" class="outline-3">
<h3 id="sec-3-5"><span class="section-number-3">3.5</span> References</h3>
<div class="outline-text-3" id="text-3-5">
<p>
D. Chakrabarti, Y. Zhan, and C. Faloutsos, R-MAT: A recursive model
for graph mining, SIAM Data Mining 2004.
</p>
<p>
Section 17.6, Algorithms in C (third edition). Part 5 Graph
Algorithms, Robert Sedgewick (Programs 17.7 and 17.8)
</p>
<p>
P. Sanders, Random Permutations on Distributed, External and
Hierarchical Memory, Information Processing Letters 67 (1988) pp
305-309.
</p>
</div>
</div>
</div>
<div id="outline-container-sec-4" class="outline-2">
<h2 id="sec-4"><span class="section-number-2">4</span> Kernel 1 – Graph Construction</h2>
<div class="outline-text-2" id="text-4">
</div><div id="outline-container-sec-4-1" class="outline-3">
<h3 id="sec-4-1"><span class="section-number-3">4.1</span> Description</h3>
<div class="outline-text-3" id="text-4-1">
<p>
The first kernel may transform the edge list to any data structures
(held in internal or external memory) that are used for the remaining
kernels. For instance, kernel 1 may construct a (sparse) graph from a
list of tuples; each tuple contains endpoint vertex identifiers for an
edge, and a weight that represents data assigned to the edge.
</p>
<p>
The graph may be represented in any manner, but it may not be modified
by or between subsequent kernels. Space may be reserved in the data
structure for marking or locking.
Only one copy of a kernel will be
run at a time; that kernel has exclusive access to any such marking or
locking space and is permitted to modify that space (only).
</p>
<p>
There are various internal memory representations for sparse graphs,
including (but not limited to) sparse matrices and (multi-level)
linked lists. For the purposes of this application, the kernel is
provided only the edge list and the edge list's size. Further
information such as the number of vertices must be computed within this
kernel. Algorithm <a href="#alg:kernel1">2</a> provides a high-level sample
implementation of kernel 1.
</p>
<p>
The process of constructing the graph data structure (in internal or
external memory) from the set of tuples must be timed.
</p>
<div class="org-src-container">
<label class="org-src-name">High-level implementation of kernel 1</label>
<pre class="src src-Octave" id="alg:kernel1">function G = kernel_1 (ij)
%% Compute a sparse adjacency matrix representation
%% of the graph with edges from ij.
%% Remove self-edges.
ij(:, ij(1,:) == ij(2,:)) = [];
%% Adjust away from zero labels.
ij = ij + 1;
%% Find the maximum label for sizing.
N = max (max (ij));
%% Create the matrix, ensuring it is square.
G = sparse (ij(1,:), ij(2,:), ones (1, size (ij, 2)), N, N);
%% Symmetrize to model an undirected graph.
G = spones (G + G.');
</pre>
</div>
</div>
</div>
<div id="outline-container-sec-4-2" class="outline-3">
<h3 id="sec-4-2"><span class="section-number-3">4.2</span> References</h3>
<div class="outline-text-3" id="text-4-2">
<p>
Section 17.6 Algorithms in C third edition Part 5 Graph Algorithms,
Robert Sedgewick (Program 17.9)
</p>
</div>
</div>
</div>
<div id="outline-container-sec-5" class="outline-2">
<h2 id="sec-5"><span class="section-number-2">5</span> Sampling 64 Search Keys</h2>
<div class="outline-text-2" id="text-5">
<p>
The search keys must be randomly sampled from the vertices in the
graph. To avoid trivial searches, sample only from vertices that are
connected to some other vertex. Their degrees, not counting self-loops,
must be at least one. If there are fewer than 64 such vertices, run
fewer than 64 searches. This should never occur with the graph sizes
in this benchmark, but there is a non-zero probability of producing a
trivial or nearly trivial graph. The number of search keys used is
included in the output, but this step is untimed.
</p>
</div>
</div>
<div id="outline-container-sec-6" class="outline-2">
<h2 id="sec-6"><span class="section-number-2">6</span> Kernel 2 – Breadth-First Search</h2>
<div class="outline-text-2" id="text-6">
</div><div id="outline-container-sec-6-1" class="outline-3">
<h3 id="sec-6-1"><span class="section-number-3">6.1</span> Description</h3>
<div class="outline-text-3" id="text-6-1">
<p>
A Breadth-First Search (BFS) of a graph starts with a single source
vertex, then, in phases, finds and labels its neighbors, then the
neighbors of its neighbors, etc. This is a fundamental method on
which many graph algorithms are based. A formal description of BFS can
be found in Cormen, Leiserson, and Rivest. Below, we specify the
input and output for a BFS benchmark, and we impose some constraints
on the computation. However, we do not constrain the choice of BFS
algorithm itself, as long as it produces a correct BFS tree as output.
</p>
<p>
This benchmark's memory access pattern (internal or external) is data-dependent
with small average prefetch depth. As in a simple
concurrent linked-list traversal benchmark, performance reflects an
architecture's throughput when executing concurrent threads, each of
low memory concurrency and high memory reference density. Unlike such
a benchmark, this one also measures resilience to hot-spotting when
many of the memory references are to the same location; efficiency
when every thread's execution path depends on the asynchronous
side-effects of others; and the ability to dynamically load balance
unpredictably sized work units. Measuring synchronization performance
is not a primary goal here.
</p>
<p>
You may not search from multiple search keys concurrently.
</p>
<p>
<b>ALGORITHM NOTE</b> We allow a benign race condition when vertices at BFS
level k are discovering vertices at level k+1. Specifically, we do
not require synchronization to ensure that the first visitor must
become the parent while locking out subsequent visitors. As long as
the discovered BFS tree is correct at the end, the algorithm is
considered to be correct.
</p>
</div>
</div>
<div id="outline-container-sec-6-2" class="outline-3">
<h3 id="sec-6-2"><span class="section-number-3">6.2</span> Kernel 2 Output</h3>
<div class="outline-text-3" id="text-6-2">
<p>
For each search key, the routine must return an array containing valid
breadth-first search parent information (per vertex). The parent of
the search<sub>key</sub> is itself, and the parent of any vertex not included in
the tree is -1. Algorithm <a href="#alg:kernel2">3</a> provides a sample (and
inefficient) high-level implementation of kernel two.
</p>
<div class="org-src-container">
<label class="org-src-name">High-level implementation of kernel 2</label>
<pre class="src src-Octave" id="alg:kernel2">function parent = kernel_2 (G, root)
%% Compute a sparse adjacency matrix representation
%% of the graph with edges from ij.
N = size (G, 1);
%% Adjust from zero labels.
root = root + 1;
parent = zeros (N, 1);
parent (root) = root;
vlist = zeros (N, 1);
vlist(1) = root;
lastk = 1;
for k = 1:N,
v = vlist(k);
if v == 0, break; end
[I,J,V] = find (G(:, v));
nxt = I(parent(I) == 0);
parent(nxt) = v;
vlist(lastk + (1:length (nxt))) = nxt;
lastk = lastk + length (nxt);
end
%% Adjust to zero labels.
parent = parent - 1;
</pre>
</div>
</div>
</div>
</div>
<div id="outline-container-sec-7" class="outline-2">
<h2 id="sec-7"><span class="section-number-2">7</span> Validation</h2>
<div class="outline-text-2" id="text-7">
<p>
It is not intended that the results of full-scale runs of this
benchmark can be validated by exact comparison to a standard reference
result. At full scale, the data set is enormous, and its exact details
depend on the pseudo-random number generator and BFS algorithm used. Therefore,
the
validation of an implementation of the benchmark uses soft checking of
the results.
</p>
<p>
We emphasize that the intent of this benchmark is to exercise these
algorithms on the largest data sets that will fit on machines being
evaluated. However, for debugging purposes it may be desirable to run
on small data sets, and it may be desirable to verify parallel results
against serial results, or even against results from the executable
specification.
</p>
<p>
The executable specification verifies its results by comparing them
with results computed directly from the tuple list.
</p>
<p>
Kernel 2 validation: after each search, run (but do not time) a
function that ensures that the discovered breadth-first tree is
correct by ensuring that:
</p>
<ol class="org-ol">
<li>the BFS tree is a tree and does not contain cycles,
</li>
<li>each tree edge connects vertices whose BFS levels differ by
exactly one,
</li>
<li>every edge in the input list has vertices with levels that differ
by at most one or that both are not in the BFS tree,
</li>
<li>the BFS tree spans an entire connected component's vertices, and
</li>
<li>a node and its parent are joined by an edge of the original graph.
</li>
</ol>
<p>
Algorithm <a href="#alg:validate">4</a> shows a sample validation routine.
</p>
<div class="org-src-container">
<label class="org-src-name">High-level implementation of kernel 2 validation</label>
<pre class="src src-Octave" id="alg:validate">function out = validate (parent, ij, search_key)
out = 1;
parent = parent + 1;
search_key = search_key + 1;
if parent (search_key) != search_key,
out = 0;
return;
end
ij = ij + 1;
N = max (max (ij));
slice = find (parent > 0);
level = zeros (size (parent));
level (slice) = 1;
P = parent (slice);
mask = P != search_key;
k = 0;
while any (mask),
level(slice(mask)) = level(slice(mask)) + 1;
P = parent (P);
mask = P != search_key;
k = k + 1;
if k > N,
%% There must be a cycle in the tree.
out = -3;
return;
end
end
lij = level (ij);
neither_in = lij(1,:) == 0 & lij(2,:) == 0;
both_in = lij(1,:) > 0 & lij(2,:) > 0;
if any (not (neither_in | both_in)),
out = -4;
return
end
respects_tree_level = abs (lij(1,:) - lij(2,:)) <= 1;
if any (not (neither_in | respects_tree_level)),
out = -5;
return
end
</pre>
</div>
</div>
</div>
<div id="outline-container-sec-8" class="outline-2">
<h2 id="sec-8"><span class="section-number-2">8</span> Computing and Outputting Performance Information</h2>
<div class="outline-text-2" id="text-8">
</div><div id="outline-container-sec-8-1" class="outline-3">
<h3 id="sec-8-1"><span class="section-number-3">8.1</span> Timing</h3>
<div class="outline-text-3" id="text-8-1">
<p>
Start the time for a search immediately prior to visiting the search
root. Stop the time for that search when the output has been written
to memory. Do not time any I/O outside of the search routine. If
your algorithm relies on problem-specific data structures (by our
definition, these are informed by vertex degree), you must include the
setup time for such structures in <i>each search</i>. The spirit of the
benchmark is to gauge the performance of a single search. We run many
searches in order to compute means and variances, not to amortize data
structure setup time.
</p>
</div>
</div>
<div id="outline-container-sec-8-2" class="outline-3">
<h3 id="sec-8-2"><span class="section-number-3">8.2</span> Performance Metric (TEPS)</h3>
<div class="outline-text-3" id="text-8-2">
<p>
In order to compare the performance of Graph 500 "Search"
implementations across a variety of architectures, programming models,
and productivity languages and frameworks, we adopt a new performance
metric described in this section. In the spirit of well-known
computing rates floating-point operations per second (flops) measured
by the LINPACK benchmark and global updates per second (GUPs) measured
by the HPCC RandomAccess benchmark, we define a new rate called traversed
edges per second (TEPS). We measure TEPS through the benchmarking of
kernel 2 as follows. Let time<sub>K2</sub>(n) be the measured execution time for
kernel 2. Let m be the number of input edge tuples within the
component traversed by the search, counting any multiple edges and
self-loops. We define the normalized performance rate (number of edge
traversals per second) as:
</p>
<div class="center">
<p>
TEPS(n) = m / time<sub>K2</sub>(n)
</p>
</div>
</div>
</div>
<div id="outline-container-sec-8-3" class="outline-3">
<h3 id="sec-8-3"><span class="section-number-3">8.3</span> Output</h3>
<div class="outline-text-3" id="text-8-3">
<p>
The output must contain the following information:
</p>
<dl class="org-dl">
<dt> SCALE </dt><dd>Graph generation parameter
</dd>
<dt> edgefactor </dt><dd>Graph generation parameter
</dd>
<dt> NBFS </dt><dd>Number of BFS searches run, 64 for non-trivial graphs
</dd>
<dt> construction\<sub>time</sub> </dt><dd>The single kernel 1 time
</dd>
<dt> min\<sub>time</sub>, firstquartile\<sub>time</sub>, median\<sub>time</sub>, thirdquartile\<sub>time</sub>, max\<sub>time</sub> </dt><dd>Quartiles for the kernel 2 times
</dd>
<dt> mean\<sub>time</sub>, stddev\<sub>time</sub> </dt><dd>Mean and standard deviation of the kernel 2 times
</dd>
<dt> min\<sub>nedge</sub>, firstquartile\<sub>nedge</sub>, median\<sub>nedge</sub>, thirdquartile\<sub>nedge</sub>, max\<sub>nedge</sub> </dt><dd>Quartiles for the number of
input edges visited by kernel 2, see TEPS section above.
</dd>
<dt> mean\<sub>nedge</sub>, stddev\<sub>nedge</sub> </dt><dd>Mean and standard deviation of the number of
input edges visited by kernel 2, see TEPS section above.
</dd>
<dt> min\<sub>TEPS</sub>, firstquartile\<sub>TEPS</sub>, median\<sub>TEPS</sub>, thirdquartile\<sub>TEPS</sub>, max\<sub>TEPS</sub> </dt><dd>Quartiles for the kernel 2 TEPS
</dd>
<dt> harmonic\<sub>mean\</sub><sub>TEPS</sub>, harmonic\<sub>stddev\</sub><sub>TEPS</sub> </dt><dd>Mean and standard
deviation of the kernel 2 TEPS. <b>Note</b>: Because TEPS is a
rate, the rates are compared using <b>harmonic</b> means.
</dd>
</dl>
<p>
Additional fields are permitted. Algorithm <a href="#alg:output">5</a> provides