Medusa: A Parallel Graph Processing System onGraphics Processors

Jianlong ZhongNanyang Technological University

jzhong2@ntu.edu.sg

Bingsheng HeNanyang Technological University

bshe@ntu.edu.sg

ABSTRACTMedusa is a parallel graph processing system on graph-ics processors (GPUs). The core design of Medusa isto enable developers to leverage the massive parallelismand other hardware features of GPUs by writing sequen-tial C/C++ code for a small set of APIs. This simplifiesthe implementation of parallel graph processing on theGPU. The runtime system of Medusa automaticallyexecutes the user-defined APIs in parallel on the GPU,with a series of optimizations based on the architecturefeatures of GPUs and characteristics of graph applica-tions. In this paper, we present an overview of theMedusa system and a case study of adopting Medusa toa research project on social network simulations. WithMedusa, users without GPU programming experiencecan quickly implement their graph operations on theGPU, which accelerates the discovery and findings ofdomain-specific applications.

1. INTRODUCTIONGPGPU (General-Purpose Computation on Graph-

ics Processing Units) is gaining increasing popu-larity in performance acceleration for many ap-plications, including graph processing [8, 10]. AModern GPU can have over an order of magni-tude higher memory bandwidth and computationpower than a multi-core CPU. With intensiveand application-specific optimizations, GPU-basedgraph algorithms have shown significant perfor-mance improvement over CPU-based implementa-tions. For example, the GPU accelerated breadthfirst search (BFS) algorithm is up tp 14 times fasterthan multi-core implementation [10]. However,despite the recent improvements on GPGPU pro-grammability, writing a correct and e�cient GPUprogram is challenging in general and even moredi�cult for the highly irregular graph applications.

To address the above-mentioned issues and sim-plify programming graph processing algorithms onthe GPU, we propose the Medusa parallel graphprocessing programming framework. Like exist-

ing programming frameworks such as Hadoop [17]and Mars [9], Medusa provides a small set ofAPIs for developers to implement their applicationsby writing sequential (C/C++) code. Di↵erentfrom Hadoop and Mars, which adopts the MapRe-duce programming model [3], Medusa adopts ournovel “Edge-Message-Vertex” (EMV) graph pro-gramming model for fine-grained processing onedges, messages and vertices. Medusa embracesan e�cient message passing based runtime. Itautomatically executes user-defined APIs in parallelwithin one GPU and across multiple GPUs, andhides the complexity of GPU programming fromdevelopers. Thus, developers can write the sameAPIs, which automatically run on one or multipleGPUs. To maximally leverage the power of GPUs,Medusa embraces a series of optimizations based onthe architecture features of GPUs and characteris-tics of graph applications.

As a case study, we adopt Medusa to implementGPU accelerated simulation of information propa-gation over social networks. Simulation of informa-tion propagation is computationally intensive andfortunately highly parallelizable, which makes itviable for GPU acceleration. By the case study, wedemonstrate that Medusa both improves the codingproductivity and brings significant performancespeedups.

This paper gives an overview of Medusa basedon work reported in [20, 18, 11, 12, 13]. Wefirst present the design of the main componentsof Medusa’s system architecture and evaluationresults. We then present the case study developedbased on Medusa. Finally, we conclude this paperand present the future work.

2. RELATED WORKParallel graph processing. It has been ob-

served that many common graph algorithms can beformulated using a form of the bulk synchronousparallel (BSP) model [14] (we call it GBSP). Under

SIGMOD Record, June 2014 (Vol. 43, No. 2) 35

the GBSP model, local computations on each vertexare performed in parallel iteratively. At the end ofeach iteration, vertices exchange data by messagepassing, followed by a global synchronization. Morerecently, the asynchronous model has been appliedto improve the convergence speed of some graphapplications [14]. Due to the synchronous nature ofthe GPU programming model, we only support thesynchronous GBSP model on GPU at the moment.

GPGPU. We use NVIDIA CUDA’s terminology.The GPU consists of multiple of streaming multi-processors (SM), inside which there is an array ofscalar cores. A CUDA program, which is calleda kernel, usually consists of thousands of threads.The massive number of threads of a kernel runson all the SMs of a GPU in parallel. Each 32 ofthe threads are grouped into a warp and executesynchronously. Divergence inside a warp introducessevere performance penalty since di↵erent pathsare executed serially. The GPU requires coalescedaccess to its memory to ensure high utilization of itsmemory bandwidth. To achieve coalesced access,threads in the same warp must access the samememory segment each time. Another importantfeature for performance optimization on the GPU isthe shared memory, which is a small piece of scratchpad memory on the SM. Shared memory has muchlower latency compared with the GPU memory.Utilizing shared memory can greatly improve thedata access performance of CUDA programs.

3. SYSTEM OVERVIEWIn this section, we give an overview on how users

implement their graph processing algorithms basedon Medusa, and outline the key modules of Medusa.

3.1 Programming with MedusaWe propose the EMV model as the programming

model of Medusa. EMV is similar to the GBSPmodel and specifically tailored for parallel graphprocessing on the GPU. To facilitate e�cient andfine-grained graph processing on the GPU, EMVdecomposes each iterative graph operation in GBSPinto three sub-iterations, i.e., processing on edges,messages and vertices. Medusa hides the GPU pro-gramming details from users by o↵ering two kindsof APIs, EMV APIs and system-provided APIs,as shown in Tables 1 and 2, respectively. Throughthose APIs, Medusa enables programmability ande�ciency for parallel graph processing on the GPU.

Each EMV API is either for executing user-defined computation on vertices (VERTEX ), edges(ELIST , EDGE ) or messages (MESSAGE , MLIST ).The vertex and edge APIs can also send messages

Device code APIs:/* EDGE API */struct SendDistance{__device__ void operator() (Edge e){ int head_id = e.get_head_id(); Vertex head(head_id); if(head.get_updated()) { unsigned int msg = v.get_distance() + e.get_length(); e.sendMsg(msg); }}/* VERTEX API */struct UpdateDistance{__device__ void operator() (Vertex v){ unsigned int min_msg = v.combined_msg(); if(min_msg < v.get_distance()) { v.set_distance(min_msg); v.set_updated(true); Medusa_Continue(); } else v.set_updated(false);}

Iteration definition:void SSSP() { /* Initiate message buffer to UINT_MAX */ InitMessageBuffer(UINT_MAX); /* Invoke the EDGE API */ EMV<EDGE>::Run(SendDistance); /* Invoke the message combiner */ Combiner(); /* Invoke the VERTEX API */ EMV<VERTEX>::Run(UpdateDistance);}Configurations and API execution:int main(int argc, char **argv) { /* Load the input graph. */ Graph my_graph; conf.combinerOpType = MEDUSA_MIN; conf.combinerDataType = MEDUSA_UINT; conf.gpuCount = 1; conf.continueIteration = false; /*Setup device data structure.*/ Init_Device_DS(my_graph); Medusa::Run(SSSP); /* Retrieve results to my_graph. */ Dump_Result(my_graph); ...... return 0;}

Figure 1: User-defined functions in SSSPimplemented with Medusa.

to neighboring vertices. The idea of providing theseAPIs is mainly for e�ciency. It decouples thesingle vertex API of previous GBSP-based systemsinto separate APIs which target individual vertices,edges or messages. Each GPU thread executesone instance of the user-defined EMV API. Thefine-grained data parallelism exposed by the EMVmodel can better exploit the massive parallelism ofthe GPU. In addition, a Combiner API is providedto aggregate results of EDGE and MESSAGEusing an associative operator. This enhances theexecution performance since segmented-scan hasvery e�cient and load balanced implementation onthe GPU [15].

A small set of system provided APIs is designedto hide the GPU-specific programming details. Par-ticularly, Medusa provides EMV < type >:: Run()to invoke the device code APIs, which automaticallysets up the thread block configurations and callsthe corresponding user-defined functions. Medusaallows developers to define an iteration which ex-ecutes a sequence of EMV < type >:: Run() callsin one host function (invoked by Medusa :: Run()).The iteration is performed iteratively until prede-fined conditions are satisfied. Medusa o↵ers a set ofconfiguration parameters and utility functions foriteration control.

To demonstrate the usage of Medusa, we show anexample of the SSSP (Single Source Shortest Path)implementation with Medusa, as shown in Figure 1.The function SSSP() consists of three user-definedEMV API function calls, which is the three mainsteps of the algorithm. First, we use an EDGE typeAPI (SendDistance) to send tentative new distancevalues to neighbors of updated vertices. Second, weuse a message Combiner to calculate the minimumsof received distances of each vertex. Third, we

36 SIGMOD Record, June 2014 (Vol. 43, No. 2)

Table 1: EMV APIsAPI Type Parameters Variant Description

ELIST Vertex v, Edge-list el Collective Apply to edge-list el of each vertex v

EDGE Edge e Individual Apply to each edge e

MLIST Vertex v, Message-list ml Collective Apply to message-list ml of each vertex v

MESSAGE Message m Individual Apply to each message m

VERTEX Vertex v Individual Apply to each vertex v

Combiner Associative operation o Collective Apply an associative operation to all edge-lists or message-lists

Table 2: System provided APIs and parameters in MedusaAPI/Parameter Description

AddEdge (void* e), AddVertex(void* v) Add an edge or a vertex into the graphInitMessageBu↵er(void* m) Initiate the message bu↵er

maxIteration The maximum iterations that Medusa executes (231 � 1 by default)halt A flag indicating whether Medusa stops the iterationMedusa :: Run(Func f) Execute f iteratively according to the iteration controlEMV<type>:: Run(Func f

0) Execute EMV API f

0 with type on the GPU

invoke a VERTEX type API (UpdateDistance)to update the distances of vertices which receivenew distances lower than their current distances.In the main function, we load the input graphand configure the execution parameters such asthe Combiner data type and operation type, thenumber of GPUs to use and the default iterationtermination behavior. Medusa::Run(SSSP) invokesthe SSSP function.

3.2 System InternalsWe proposed various optimization techniques for

Medusa internals to ensure the high performance.For example, we optimize the graph data layout onthe GPU memory, as well as layout of user-defineddata structures for the e�ciency of GPU memoryaccess. Specifically, Medusa mainly consists of thefollowing key modules.

Graph Storage. The storage module of Medusaallows developers to load the graph data throughadding vertices and edges with the system providedAPIs AddEdge and AddVertex . During loading ofthe graph data, data are stored in our novel graphlayout optimized for GPU access [20]. Comparedwith the classic adjacency list layout, the optimizedlayout facilitates coalesced access during executionof graph algorithms to ensure high memory band-width utilization. After the graph is loaded intomain memory, it is automatically transfered to theGPU memory.

Medusa code generation tool chain. Usersbuild Medusa-based programs with standard C/C++.The Medusa code generation tool chain trans-lates the user code into CUDA code. Firstly,Medusa translates user-defined EMV APIs intokernel codes, and generates corresponding ker-nel invocation codes. Secondly, Medusa trans-lates user-defined data structures, such as datastructures for vertex and edge, into GPU datastructures and corresponding data transfer codes.

Thirdly, Medusa inserts segmented-scan code forthe Combiner APIs.

Medusa runtime. This module provides run-time support for user applications and managesGPU resource and kernel executions. In particular,this module has three main functionalities. First, itsupports the message passing interface. We developa novel graph aware message passing mechanismfor e�ciency [20]. Second, Medusa runtime enablestransparent execution of user applications on themulti-GPU environment. We further propose tech-niques such as overlapping kernel execution withdata transfer and multi-hop replication to increasethe scalability of multi-GPU execution. Third,Medusa runtime supports concurrent execution ofmultiple Medusa tasks from di↵erent users. In themulti-user environment, Medusa coordinates theGPU memory allocation and kernel execution com-mands to prevent resource allocation deadlocks andexploit opportunities for performance improvement.Meudsa runtime also exploits the complementaryresource requirements among the kernels to improvethe throughput of concurrent kernel executions.More details about our concurrent kernel schedulingmechanism can be found in our paper [19].

4. RESULTSWe evaluate Medusa with both synthetic graphs

generated by GTGraph [7] and publicly availablereal world graphs [16, 1]. The details of the graphdata, including the numbers of vertices and edges,and standard deviations of the vertex degree, areshown in Table 3. Our workload includes a setof common graph computation and visualizationprimitives. The graph computation primitives in-clude PageRank, BFS, maximal bipartite matching(MBM), ans SSSP. Our experimental platform is awork station with four NVIDIA Tesla C2050 GPUsand two six-core Intel Xeon E5645 CPUs at 2.4GHz. We developed a set of visualization primitives

SIGMOD Record, June 2014 (Vol. 43, No. 2) 37

Table 3: Details of graphs used in theexperiments

Graph Vertices(106)

Edges(106)

�

RMAT 1.0 16.0 32.9Random (Rand) 1.0 16.0 4.0BIP 4.0 16.0 5.1WikiTalk (Wiki) 2.4 5.0 99.9RoadNet-CA (Road) 2.0 5.5 1.0kkt power (KKT) 2.1 13.0 7.5coPapersCiteseer (Cite) 0.4 32.1 101.3hugebubbles-00020 (Huge) 21.2 63.6 0.03

Table 4: Coding complexity of Medusa im-plementation and hand-tuned implementa-tions.

Baseline Warp-centric Medusa(N/Q)

GPU code lines (BFS) 56 76 9/7GPU code lines(SSSP)

59 N.A. 13/11

GPU memory man-agement

Yes Yes No

Kernel configuration Yes Yes NoParallel programming Thread Thread+Warp No

such as graph layout and drilling up/down. Weimplement the force direct layout algorithm [4]. Thedrilling up/down operation is implemented usingBFS. The visualization experiments are conductedon a workstation with one NVIDIA Quadro 5000GPU and one Intel Xeon W3565 processor with 4GB memory.

Comparison with Hand-Tuned Implemen-tations. We compare the traversed edges persecond (TEPS) of Medusa-based BFS with the basicimplementation from Harish et al [8] and the warp-centric method from Hong et al [10]. Compared tothe basic implementation, Medusa performs muchbetter on all graphs except KKT. The averagespeedup of Medusa over the basic implementa-tion is 3.4. Medusa has comparable performancewith the warp-centric method, while the latter hasmuch more complicated implementation. We alsocompare Medusa-based SSSP with Harish et al’simplementation. Medusa achieves comparable per-formance with Harish et al’s implementation excepton Road and Huge. This is because Road and Hugehave large diameters, which lead to large numbersof iterations of Medusa. Table 4 shows the codingcomplexity of the three implementations. Medusasignificantly reduces the developing e↵ort by hidingthe GPU programming details and reducing thelines of code.

Comparison with CPU-based Implementa-tions. We compare Medusa with MTGL [2] basedmulti-core implementations running on 12 cores.Similar to Medusa, MTGL o↵ers a set of datastructures and APIs for building graph algorithms.MTGL is optimized to leverage shared memorymultithreaded machines. For all the computa-

(a) Overview (b) Two-hop neighbors of selected

author

Figure 2: Visualization results on DBLP co-authorship graph.

tion primitives, Medusa is significantly faster thanMTGL on most graphs and delivers a performancespeedup of 1.0-19.6 with an average of 5.5.

We also evaluate the performance of our graphvisualization primitives. The input is the co-authorgraph extracted from DBLP (http://dblp.uni-trier.de/xml/).Figure 2(a) shows the results of our layout primitiveon the DBLP graph. On the Quadro 5000 GPU,Medusa takes only 120 seconds to compute thelayout, while the 4-thread CPU implementation onthe Intel Quad-core CPU takes over 1000 seconds.Figure 2(b) shows the two-hop neighbors of aselected author Jiawei Han obtained by a drill-down operation. Medusa greatly improves theresponsiveness of graph visualization tasks.

Scalability. The memory sizes of our inputgraphs ranges from as small as less than 100 MB(Wiki) to as large as 1 GB (Huge). Our experimentsshow that Medusa fully utilizes the GPU for allthe graph sizes. We also evaluate the scalabilityof Medusa on the multi-GPU environment withBFS and PageRank. The speedup of BFS andPageRank on four GPUs is 1.8 and 2.6, respectively.BFS is lightweight on computation compared withPageRank. Hence, the communication overhead islarger for BFS, which leads to fewer speedups.

5. USER EXPERIENCE AND LESSONSIn this section, we present a case study on apply-

ing Medusa to accelerate information propagationsimulations over social networks. Information prop-agation simulations provide a flexible and valuablemethod to study the behaviors over complex socialnetworks.

Large-scale network-based simulations involvinginformation propagation often require a large amountof computing resources. It is therefore necessaryto develop performance-oriented simulation tech-niques and to map those optimized simulationmethods onto high performance computing (HPC)platforms such as GPUs. For complex networks,the network structures are highly irregular due to

38 SIGMOD Record, June 2014 (Vol. 43, No. 2)

the complicated relationships among the verticess.Such irregularity of the data structure may exhibitvery poor memory access locality. The irregularityof the network data structure poses great challengeson e�cient GPU acceleration.

5.1 Models of Information PropagationThe simulation of information propagation is

to investigate the interactive behaviors betweenActive vertices and Inactive vertices within agiven network. Currently, the Independent CascadeModel (ICM) [5] and the Linear Threshold Model(LTM) [6] are widely used in studying the behaviorsof information propagation over networks. In theICM, we define an initial set of active vertexs A0

at step 0. The information propagation unfoldsin discrete time steps: at step t, the newly activevertex v

i

has a single chance to activate its inac-tive neighbor u with an independent probabilityp(vi,u) 2 [0, 1]. If v

i

succeeds in activating u, u

will transit its status from inactive to active at stept + 1 and remain active afterwards [5]. Such aprocess continues until no more new activationsare made in a step. In the LTM, each vertex onthe network is assigned with a random thresholdT

u

2 [0, 1]. At step t, each inactive vertex isinfluenced by its active neighbors (a set A

t

, whereA

t

is ø if no active neighbor exists). The influenceweight between the active vertex v

i

and the inactivevertex u can be expressed as a probability b(vi,u).Thus, vertex u’s influence weight from its activeneighbors can be calculated and represented byP

l

i=1 b(vi

, u), where l denotes the number of activeneighbors and v

i

is the ith active neighbor of u [6].If the transition probability

Pl

i=1 b(vi

, u) is largerthan the predefined threshold value, u’s status willtransit from inactive to active at step t + 1 andremain afterwords.

5.2 Implementations and EvaluationsBased on the ICM and LTM models (with adap-

tions to our application scenarios [11]), we firstintroduce two types of simulation algorithms namedas C-Loop and T-Loop. 1) C-Loop: Starting fromthe active vertices in the network, each active vertexgoes through its neighbors at each simulation stepand tests whether it can propagate the informationto the inactive neighbors with a specific probability.If the inactive vertices receive the information, theywill change status to be active at the next step.2) T-Loop: In contrast to the C-Loop, the T-Loop starts from the inactive vertices and tracesthe neighbors’ status at each step. The inactivevertex can be activated at the next step by any

(a)Simulation Steps

Figure 3: Execution time per simulationstep.

active neighbor if the transmission probability issatisfied.

Both C-Loop and T-Loop can be easily im-plemented using the ELIST API provided byMedusa. Since the processing of neighbors in C-Loop and T-Loop imposes no edge order constraint,we also propose to use EDGE API to imple-ment similar functionalities as C-Loop and T-Loop.This is inspired by the analysis from Medusa thatEDGE API alleviates the load imbalance problemof ELIST API and exhibits better data accessperformance. We name the EDGE API basedalgorithm as E-Loop. Di↵erent from the vertex-oriented approach (C-Loop and T-Loop), the E-Loop approach starts from each edge element andchecks the status of the connected pair of vertices.If the two connected vertices have di↵erent statussuch as Active-Inactive, the information can bepropagated from active to inactive with the givenprobability.

Figure 3 shows the execution time per simulationstep on C2050. The dataset is a random graphgenerated by GTGraph [7] with one million verticesand 8 million edges. Due to di↵erent memory accesspatterns, the above three algorithms can exhibitdi↵erent costs in each step of the simulation. Forexample, the cost of a C-Loop step is initially smalldue to the small number of active vertices. Asthe number of active vertices increases, the costof a C-Loop step increases. The cost of T-Loopiterations is opposite to that of C-Loop. In contrast,the cost of a E-Loop stays stable in di↵erentiterations. Compared to the CPU serial simulationperformance, the C2050 GPU based simulationshows 12.5x, 13.1x, 15.6x speedup with CLoop,T-Loop, and E-Loop, respectively [11]. Thedi↵erent characteristics of the algorithms allow usto adaptively choose the best algorithm based onthe per-step simulation information. More detailson this adaptation can be found in our paper [11].We also experiment with synthetic and real worldgraphs with varying sizes and obtained consistentspeedups [11, 13].

SIGMOD Record, June 2014 (Vol. 43, No. 2) 39

Simulation on Multiple GPUs. Using mul-tiple GPUs for the simulation is a fast way toincrease the memory and computation capacities ofthe system. We use the default graph partitioningmethod of Medusa to partition the graph. Medusaautomatically builds the replicas for each partitionand handles the update of the replicas. Thus, withMedusa, the network-based information propaga-tion is enabled on multiple GPUs with minimizede↵ort. The simulation performance is improved by2.7 times on four GPUs compared with on one GPU.More details can be found in our paper [12].

5.3 Experience on Using MedusaMedusa requires no knowledge of GPU program-

ming and greatly simplifies our work on utiliz-ing GPUs for information propagation simulation.First, the programming model of Medusa fits wellwith the real information propagation process. In-formation propagation over social networks usuallyhappens among neighboring vertices. Similarly,Medusa allows users to formulate their algorithmswith the granularity of individual vertices oredges. Second, the individual and collective APIsof Medusa allow us to develop di↵erent approaches(i.e., vertex-oriented and edge-oriented) for the sim-ulation, leading to more opportunities for improvingthe overall performance of the simulation. Third,despite the fact that Medusa provides an abstractdata model and hides the GPU related implemen-tation details from users, experienced users can stilleasily access the underlying data structures andconduct further customization. Forth, a Medusaprogram can transparently run on multiple GPUs.This feature of Medusa allows the user to enjoy thebenefits of multiple GPUs (more memory space andcomputation power) with little extra implementa-tion e↵ort.

6. CONCLUSIONS AND FUTURE WORKThe design and implementation of Medusa show

that parallel graph computation can e�ciently andelegantly be supported on the GPU with a smallset of user-defined APIs. The fine-grained APIdesign and graph-centric optimizations significantlyimprove the performance of graph computationon the GPU. As for future work, we are consid-ering o↵ering dynamic graph processing supportin Medusa, and extending Medusa to large scalesystems such as clusters and clouds.

The source code of Medusa is available at http://code.google.com/p/medusa-gpu/.

7. ACKNOWLEDGEMENT

The authors would like to thank anonymousreviewers for their valuable comments. This work issupported by a MoE AcRF Tier 2 grant (MOE2012-T2-2-067) in Singapore.

8. REFERENCES[1] 10th DIMACS implementation challenge.

http://www.cc.gatech.edu/dimacs10/index.shtml.[2] J. W. Berry, B. Hendrickson, S. Kahan, and

P. Konecny. Software and algorithms for graph querieson multithreaded architectures. In IPDPS, pages 1–14,2007.

[3] J. Dean and S. Ghemawat. MapReduce: simplifieddata processing on large clusters. Communications ofthe ACM, 51(1):107–113, 2008.

[4] T. M. J. Fruchterman and E. M. Reingold. Graphdrawing by force-directed placement. Software:Practice and Experience, 21:1129–1164, 1991.

[5] J. Goldenberg, B. Libai, and E. Muller. Talk of thenetwork: A complex systems look at the underlyingprocess of word-of-mouth. Marketing letters,12(3):211–223, 2001.

[6] M. Granovetter. Threshold models of collectivebehavior. American journal of sociology, pages1420–1443, 1978.

[7] GTGraph Generator.http://www.cc.gatech.edu/ kamesh/GTgraph/.

[8] P. Harish and P. Narayanan. Accelerating large graphalgorithms on the GPU using CUDA. In HiPC, pages197–208. 2007.

[9] B. He, W. Fang, Q. Luo, N. K. Govindaraju, andT. Wang. Mars: a MapReduce framework on graphicsprocessors. In PACT, pages 260–269, 2008.

[10] S. Hong, S. K. Kim, T. Oguntebi, and K. Olukotun.Accelerating CUDA graph algorithms at maximumwarp. In PPoPP, pages 267–276, 2011.

[11] J. Jin, S. J. Turner, B.-S. Lee, J. Zhong, and B. He.HPC simulations of information propagation oversocial networks. Procedia Computer Science,9:292–301, 2012.

[12] J. Jin, S. J. Turner, B.-S. Lee, J. Zhong, and B. He.Simulation of information propagation over complexnetworks: Performance studies on multi-GPU. InDS-RT, pages 179–188, 2013.

[13] J. Jin, S. J. Turner, B.-S. Lee, J. Zhong, and B. He.Simulation studies of viral advertisement di↵usion onmulti-GPU. In Winter Simulation Conference (WSC),pages 1592–1603, 2013.

[14] Y. Low, J. Gonzalez, A. Kyrola, D. Bickson,C. Guestrin, and J. M. Hellerstein. GraphLab: A newparallel framework for machine learning. In UAI, 2010.

[15] S. Sengupta, M. Harris, and M. Garland. E�cientparallel scan algorithms for GPUs. NVIDIA. Technicalreport, 2008.

[16] Stanford Large Network Dataset Collections.http://snap.stanford.edu/data/index.html.

[17] T. White. Hadoop: The Definitive Guide: TheDefinitive Guide. O’Reilly Media, 2009.

[18] J. Zhong and B. He. Parallel graph processing ongraphics processors made easy. PVLDB,6(12):1270–1273, 2013.

[19] J. Zhong and B. He. Kernelet: High-throughput gpukernel executions with dynamic slicing and scheduling.Parallel and Distributed Systems, IEEE Transactionson, 25(6):1522–1532, 2014.

[20] J. Zhong and B. He. Medusa: Simplified graphprocessing on gpus. IEEE Transactions on Paralleland Distributed Systems, 25(6):1543–1552, 2014.

40 SIGMOD Record, June 2014 (Vol. 43, No. 2)