저 시-비 리- 경 지 2.0 한민

는 아래 조건 르는 경 에 한하여 게

l 저 물 복제, 포, 전송, 전시, 공연 송할 수 습니다.

다 과 같 조건 라야 합니다:

l 하는, 저 물 나 포 경 , 저 물에 적 된 허락조건 명확하게 나타내어야 합니다.

l 저 터 허가를 면 러한 조건들 적 되지 않습니다.

저 에 른 리는 내 에 하여 향 지 않습니다.

것 허락규약(Legal Code) 해하 쉽게 약한 것 니다.

Disclaimer

저 시. 하는 원저 를 시하여야 합니다.

비 리. 하는 저 물 리 목적 할 수 없습니다.

경 지. 하는 저 물 개 , 형 또는 가공할 수 없습니다.

공학석사 학 논문

Breadth-firstsearch벤치마크의

성능비교 구 개선에 한 연구

2016년 1월

서울 학교 융합과학기술 학원

융합과학부 지능형융합시스템 공

이 상 민

Breadth-firstsearch벤치마크의

성능비교 구 개선에 한 연구

A Study on Performance Comparison and

Improvement of Breadth-First Search

Benchmarks

지도 수 안

이 논문 공학 사 학 논문 로 출함

2016년 1월

울 학 합과학기술 학원

합과학부 지능 합시스템 공

이 상 민

이상민 사 학 논문 인준함

2016년 1월

원 장 재 흥 (인)

부 원장 안 (인)

원 곽 노 준 (인)

국문 록

최근 들어 빅데이터,그 에서 소셜네트워크가 폭발 으로 성

장함에 따라 소셜네트워크 데이터의 요성이 높아지고 있다.이

런 방 한 양의 데이터들은 그래 데이터구조를 이용하여 장되

고 분석된다.

그래 는 선으로 연결된 객체들을 나타낼 때 사용하는 표 법

으로 소셜네트워크에서는 사용자를 노드,사용자간의 계를 엣지

로 표 한다.이런 소셜네트워크 데이터에서 의미 있는 정보를 얻

기 해서는 데이터를 분석하는 과정이 필요하며,분석은 모든 노

드를 순회하며 노드의 상태들을 확인하며 진행된다.따라서 소셜

네트워크 데이터분석에 그래 순회는 요한 부분이다.

표 인 그래 순회 알고리즘인 Breadth-firstsearch(BFS)는

순회시작 노드와 인 해있는 모든 노드들을 우선 으로 방문한

후,방문한 노드와 인 한 노드들을 순차 으로 순회한다.이런 순

회방식은 그 특성상 같은 벨에 치하는 노드들을 병렬 으로

처리할 수 있다.

BFS는 체 인 틀은 동일하지만 다양한 구 의 벤치마크들이

있다.구 에 따라서 확인해야 할 엣지의 수를 이거나,노드를

근하는 순서 등을 바꿔서 성능 향상을 도모한다. 한 각 벤치

마크의 특성이 다르므로 워크로드에 따라 성능이 다르다.

본 논문에서는 최근 발표된 주요 BFS벤치마크 5종을 선택하

고 각종 워크로드를 사용하여 수행시간과 메모리 측면에서 성능을

비교 분석하고,워크로드 특성을 고려하여 합한 벤치마크를

제시한다. 한 일부 벤치마크에 해서는 구 개선을 통하여 성

능을 개선하 다.마지막으로 메모리와 벤치마크 성능간의 상

계를 악하여,차후 벤치마크의 구 을 개선하거나 메모리 근

방식의 최 화를 통해 체 인 성능 향상이 가능할 수 있음을 보

다.

주요어 :빅데이터,그래 ,Breadth-firstsearch,벤치마크

학 번 :2014-24844

목 차

제 1장 서론 ································································· 1

제 1 연구동기··································································· 1

제 2 연구내용··································································· 3

제 2장 그래 순회 알고리즘 ································ 4

제 1 그래 ······································································· 4

제 2 Breadth-firstsearch·········································· 7

제 3 Depth-firstsearch·············································· 8

제 3장 주요 BFS벤치마크 ···································· 9

제 1 CRONOBenchmarkSuite································ 9

제 2 GAPBenchmarkSuite······································10

제 3 Problem-basedBenchmarkSuite·················11

제 4 Galois········································································13

제 5 Green-Marl····························································15

제 4장 CRONO BFS구 개선 ···························17

제 1 문제 ·······································································17

제 2 개선 ·······································································18

제 5장 실험 ·································································20

제 1 실험환경 구성 ···················································20

제 2 수행시간 측면에서의 성능 비교·······················23

1.워크로드별 실험 결과·························································23

2.벤치마크별 실험 결과·························································27

제 3 메모리 측면에서의 성능 비교····························29

제 6장 결론 ·································································32

참고문헌 ········································································33

Abstract·······································································35

표 목 차

[표 1]실험환경···········································································20

[표 2]워크로드별 차수 기 상 10개 노드·····················22

[표 3]워크로드···········································································23

그 림 목 차

[그림 1]페이스북,트 터 활성사용자 추이························ 1

[그림 2]탐색을 한 그래 ··················································· 2

[그림 3]그림 2에 한 BFS결과········································· 2

[그림 4]비가 무향그래 ······················································· 4

[그림 5]비가 유향그래 ······················································· 4

[그림 6]가 무향그래 ··························································· 5

[그림 7]가 유향그래 ··························································· 5

[그림 8]표 할 그래 ····························································· 6

[그림 9]그림 8의 인 행렬····················································· 6

[그림 10]그림 8의 인 리스트··············································· 6

[그림 11]Breadth-firstsearch················································ 7

[그림 12]Depth-firstsearch··················································· 8

[그림 13]CRONO의 스 드별 노드할당······························· 9

[그림 14]Direction-optimizing알고리즘······························10

[그림 15]Prioritywrite····························································12

[그림 16]Scan,Filter동작 ················································12

[그림 17]Bellman-Ford알고리즘··········································14

[그림 18]Hybridmethod·························································16

[그림 19]구 개선 CRONO수행시간·····························18

[그림 20]구 개선 후 CRONO수행시간·····························18

[그림 21]임의의 노드 10개 선정···········································21

[그림 22]차수 기 상 10개 선정·····································21

[그림 23]벤치마크별 roadNet-CA수행시간·······················24

[그림 24]벤치마크별 LiveJournal1수행시간······················25

[그림 25]벤치마크별 pokec-relationships수행시간··········25

[그림 26]벤치마크별 orkut-memberships수행시간·········26

[그림 27]벤치마크별 actor-collaboration수행시간···········26

[그림 28]워크로드별 Galois수행시간··································27

[그림 29]워크로드별 PBBS수행시간···································28

[그림 30]워크로드별 GAPBS수행시간·······························28

[그림 31]워크로드별 Green-Marl수행시간························28

[그림 32]각 벤치마크의 워크로드별 메모리 사용량·········29

[그림 33]워크로드별 노드 엣지 수·································30

[그림 34]각 벤치마크의 워크로드별 MAPKI·····················31

-1-

제 1장 서 론

제 1 연구동기

소셜네트워크는 빅데이터의 요분야 하나로 최근 빅데이터 시 로

어들면서 사용자 정보 메시지 데이터와 같은 소셜네트워크 데이터

에 한 분석이 활발히 연구되고 있다.특히 기업들은 자사의 제품에

한 마 을 수행하거나,제품에 한 시장의 반응을 살펴보기 해 소

셜네트워크 데이터 분석에 많은 심을 기울이고 있고, 한 소셜네트워

크 데이터가 지속 으로 증가함에 따라 그 요성이 더욱 커지고 있다.

0

200

400

600

800

1,000

1,200

1,400

1,600

1,800

Q3 '08

Q1 '09

Q2 '09

Q3 '09

Q4 '09

Q1 '10

Q2 '10

Q3 '10

Q4 '10

Q1 '11

Q2 '11

Q3 '11

Q4 '11

Q1 '12

Q2 '12

Q3 '12

Q4 '12

Q1 '13

Q2 '13

Q3 '13

Q4 '13

Q1 '14

Q2 '14

Q3 '14

Q4 '14

Q1 '15

Q2 '15

Q3 '15

사자

(단위

: 백만

)

분

Facebook Twitter

그림 1페이스북,트 터 활성사용자 추이[1][2]

소셜네트워크 데이터 분석은 그래 가 노드와 그 노드들을 연결하는 선

인 엣지로 구성되어 있다고 정의하는 그래 이론을 기반으로 하며,소

셜네트워크의 사용자 연결 구조와 강도 등을 바탕으로 해당 사용자의 명

-2-

성이나 향력을 측정함으로써 그 요도를 단하는 기술이다.

소셜네트워크와 같은 그래 데이터를 분석하기 해서는 노드를 순회

하며 정보를 수집해야 한다.그러한 일련의 과정을 그래 순회라고 하

며 표 인 그래 순회 알고리즘으로는 Breadth-firstsearch(BFS)와

Depth-firstsearch(DFS)가 있다.이 에서 빅데이터와 같이 량의 데

이터를 분석하기 해서는 상 으로 병렬화가 용이한 BFS가 DFS에

비해 보다 합하다.

0

1 3

2

4 5

6

그림 2탐색을 한 그래

0

1 3

2

4 5

6

1

45

2

3

6

그림 3그림 2에 한 BFS결과

이에 따라 BFS를 수행하는 여러 알고리즘과 해당 알고리즘을 구 하고

용한 다양한 벤치마크들이 발표되었다.본 연구에서는 최근 발표된 주

요 BFS벤치마크 5가지를 선택하여 다양한 워크로드에 해 메모리

근과 수행시간 측면에서의 성능을 비교 분석하고,워크로드 특성을

고려하여 해당 워크로드에 합한 벤치마크를 제시하고 구 개선 방안

을 모색해보았다.

-3-

제 2 연구내용

본 연구는 BFS를 구 한 여러 벤치마크에 해 워크로드 특성에 따

른 성능 변화를 분석하고,벤치마크의 구 개선을 통한 체 인 성능

향상에 해 연구하 다.

워크로드 특성에 따른 성능 변화를 분석하기 해 워크로드를 노드와

엣지,그리고 차수(degree)를 고려하여 다양하게 선정하 고,해당 요소

에 따라 각 벤치마크들이 어떤 성능변화를 보이는지를 메모리 근과 수

행시간 측면에서 비교하여 워크로드 특성과 벤치마크 성능간의 상 계

를 악하 다. 한 정확한 성능비교를 해 다른 순회종료조건을 가진

벤치마크를 일반 인 종료조건으로 맞춰 수정하고,불필요한 순회를 제

거하는 등 구 개선을 통해 성능향상을 보 다.

본 논문은 BFS벤치마크의 성능 비교에 앞서 2장에서 그래 와 그래

순회 알고리즘인 BFS와 DFS의 동작에 해 이해하고,3장에서 주요

BFS벤치마크에 해서,사용된 알고리즘과 병렬화 방법 등 특징에

해 살펴보고,이를 바탕으로 5장에서 수행시간과 메모리 근 측면에서

각 벤치마크의 성능을 측정하고 분석하 다.

그리고 4장에서는 CRONO벤치마크의 노드 순회 방법에 해서 집

으로 살펴보며 순회종료조건 수정과 불필요한 순회를 제거하는 방식으

로 구 을 개선하고,마지막으로 6장에서는 각 벤치마크의 특징을 확인

하고,워크로드별로 합한 BFS벤치마크를 제시하며 본 논문을 마무리

하 다.

-4-

제 2장 그래 순회 알고리즘

제 1 그래

그래 [3]는 그래 이론에서 그림 2와 같이 선으로 연결된 일련의 객

체들을 나타내는 표 법으로,상호 연결된 객체들은 노드(node 는

vertex)라고 부르고,노드들을 연결한 선은 엣지(edge 는 link)라고 부

른다.수학식으로는 그래 G =(V,E)로 표 하며,여기서 V는 노드를

의미하고 E는 엣지를 나타낸다.그림 2를 수학식으로 표 한다면 G =

(V,E),V ={0,1,2,3,4,5,6},E={(0,1),(0,2),(0,3),(1,4),(2,

4),(2,5),(3,5),(4,6),(5,6)}로 나타낼 수 있다.

그래 의 종류는 크게 2가지 특성에 따라 나뉜다.먼 ,엣지가 방향

성을 가지고 있는지에 따라 방향성이 있다면 유향그래 (directedgraph,

digragh),방향성이 없다면 무향그래 (undirectedgraph)로 나뉜다.다음

으로 엣지의 가 치 유무에 따라 가 그래 (weightedgraph)와 비가

그래 (unweightedgraph)로 분류된다.

그림 4비가 무향그래 그림 5비가 유향그래

-5-

10

48

11

3

19

1

163

107

그림 6가 무향그래

10

4

1610

135

3

20

10

723

9

1

그림 7가 유향그래

다른 그래 특성으로는 차수가 있다.차수는 노드에 연결된 다른

노드의 개수를 나타내며,방향성이 있는 유향그래 는 in-degree와

out-degree가 존재한다.일반 으로 차수가 높을수록 순회 시 확인해야

할 노드가 많으므로 수행시간이 오래 걸린다.

그래 를 표 하는 방법으로는 크게 인 행렬(Adjacency matrix)과

인 리스트(Adjacencylist)가 있다.인 행렬은 그래 를 구성하는 각

노드들 사이를 연결하는 엣지의 존재 여부를 2차원 배열을 이용하여 나

타낸 것으로,노드의 개수가 N인 그래 는 N xN인 인 행렬을 사용한

다.비가 그래 에서는 엣지가 존재하면 1,그 지 않으면 0을 값으로

가지며,가 그래 에서는 엣지가 존재하면 해당 엣지의 가 치를,그

지 않으면 비가 그래 와 동일하게 0의 값을 가진다.

인 리스트는 인 행렬의 각 행을 하나의 연결리스트로 나타낸 것으

로,연결리스트는 모든 노드에 해 해당 노드와 인 하고 있는 노드들

의 정보를 장한다.특정 엣지의 상태를 확인하기 해서는 O(n)의 시

간이 소모된다.

-6-

u y

v w

x

그림 8표 할 그래

=

0 1 1 1 11 0 1 0 01 1 0 1 11 0 1 0 11 0 1 1 0

그림 9그림 8의 인 행렬

u

v

w

x

y

v

u

u

u

u

w

w

v

w

w

x

x

y

x

y

y

null

null

null

null

null

그림 10그림 8의 인 리스트

-7-

제 2 Breadth-firstsearch

Breadth-firstsearch(BFS)[4]는 트리나 그래 데이터 구조를 순회하

기 한 알고리즘의 일종으로 1959년 E.F.Moore가 미로의 최단경로를

찾기 해 처음 발표하 다.

BFS는 순회를 시작하는 노드인 소스노드와 인 해있는 모든 노드들

을 우선 으로 방문한 후,방문한 노드들과 인 한 모든 노드들을 순차

으로 순회한다.이러한 방식으로 더 이상 방문할 노드가 없을 때까지

반복하여 동작하며,먼 방문한 노드에 인 한 노드를 다음회차에서 우

선 으로 방문해야하기 때문에 일반 으로 큐를 사용하여 방문할 노드를

장한다.

BFS에서 각 노드들은 상황에 따라 명칭이 달라진다.순회를 하기

해 기 이 되는 노드를 frontier라고 하고,frontier와 인 하고 있는 노드

들은 neighbor라고 한다.따라서 순회의 가장 기에는 소스노드가

frontier가 되며 다음회차에서는 소스노드와 인 해있던 노드들인

neighbor가 frontier가 된다.상황에 따라 여러 개의 frontier가 하나의

neighbor를 공유하는 그래 가 존재하기도 한다.이런 경우에 하나의

frontier만이 해당 neighbor를 방문하게 되고,그 neighbor에게 방문했던

frontier는 parent가 된다.

a

cb

d e f g

h i j k

그림 11Breadth-firstsearch

-8-

제 3 Depth-firstsearch

Depth-firstsearch(DFS)도 BFS와 마찬가지로 트리나 그래 등을

탐색하기 한 알고리즘의 일종으로 19세기 C.P.Tremaux가 미로를 해

결하기 해서 개발하 다.

DFS는 소스노드를 기 으로 방문할 수 있는 노드를 끝까지 따라가며

탐색하고,더 이상 탐색할 수 없을 때는 바로 이 치로 돌아가 다른

노드를 선택하여 순회한다.BFS가 방문할 노드를 장하기 해 큐를

사용하는 것과는 달리,DFS는 더 이상 탐색할 수 없을 때 한 벨만 올

라가고 다시 아랫방향으로 탐색하기 때문에 방문할 노드를 스택에 장

하는 것이 더 합하다.

a

cb

d e f g

h i j k

그림 12Depth-firstsearch

-9-

제 3장 주요 BFS벤치마크

제 1 CRONO BenchmarkSuite

CRONO Benchmark Suite(CRONO)[5]는 Masab Ahmad 등이

InternationalSymposium onWorkloadCharacterization2015에서 발표

한 “CRONO:A BenchmarkSuiteforMultithreadedGraphAlgorithms

ExecutingonFuturisticMulticores”에서 처음 소개되었다.

미래의 멀티코어 시스템을 가정한 시뮬 이터 환경을 고려하여 벤치

마크가 설계되었다.CRONO BenchmarkSuite안에는 BFS뿐만이 아니

라 DFS,SingleSourceShortestPath(SSSP),AllPairsShortestPath

(APSP),Betweenness Centrality(BC),Travelling Salesman Problem

(TSP),ConnectedComponents(CC),TriangleCounting(TC),PageRank

(PR)등이 구 되어있다.

POSIX Threads(Pthreads)API를 이용하여 멀티스 드 로그램을

구 하 으며,0부터 가장 큰 노드번호를 스 드 개수로 N등분하여 각

등분을 해당 코어에 할당하는 방식으로 병렬처리를 수행한다.이런 방식

은 구 이 간편하다는 장 이 있지만 노드들이 불균등하게 할당되기 때

문에 로드밸런싱의 측면에서는 합하지 않다.

CRONO의 순회종료조건은 다른 벤치마크와 상이하다.보통 BFS의

순회종료조건은 모든 노드를 순회하여 더 이상 순회할 노드가 존재하지

않을 때 종료되지만,CRONO의 경우엔 가장 큰 노드번호를 가진 노드를

만났을 경우 종료되는 특징을 가지고 있다.

0 stop

start

stop

start

stop

start

largest

그림 13CRONO의 스 드별 노드할당

-10-

제 2 GAPBenchmarkSuite

GAPBenchmarkSuite(GAPBS)[6]는 ScottBeamer등이 그래

로세싱의 표 화 된 평가를 수행하기 해 개발한 그래 벤치마크로

OpenMPAPI[7]를 사용하여 병렬처리를 한다.GAPBS에는 BFS,SSSP,

PR,CC,BC,TC등이 포함되어있다.

GAPBS의 BFS는 Direction-optimizing 알고리즘[8]을 사용한다.

Direction-optimizing알고리즘은 ScottBeamer,KrsteAsanovic,David

A.Patterson이 TheInternationalConferenceforHigh Performance

Computing, Networking, Storage and Analysis 2015에서 발표한

“Direction-OptimizingBreadth-FirstSearch”에서 제안된 알고리즘으로

frontier와 neighbor의 수에 따라 순회방향을 조 한다.

그림 14는 Direction-optimizing알고리즘의 동작을 나타내는 상태 다

이어그램으로 진행방향이 frontier에서 neighbor인 Top-down방식과 반

로 neighbor에서 frontier인 Bottom-up방식의 상태천이를 보여 다.

CTB는 Top-down방식에서 Bottom-up방식으로 바꿀 임계값으로 방

문하지 않은 노드로부터 나온 확인해야 할 엣지 수 mu를 상수 α로 나

값이다.이 값보다 frontier로부터 나온 확인해야 할 엣지 수 mf의 값이

더 크면 Top-down에서 Bottom-up으로 순회방법이 바 다.

Top-down

Bottom-up

>

=

≤

< =

≥

그림 14Direction-optimizing알고리즘

-11-

CBT는 Bottom-up방식에서 Top-down방식으로 바꿀 임계값이다.총

노드의 수를 상수 β로 나 값을 가지며,frontier수 nf가 해당 값보다

크면 Bottom-up에서 Top-down으로 환된다.여기서 α와 β는 미리 정

해진 상수 값으로 해당 값들은 성능향상을 해 조정할 수 있다.

제 3 Problem-basedBenchmarkSuite

2012년 24th ACM Symposium on Parallelism in Algorithmsand

Architectures에서 처음 소개된 Problem-based Benchmark Suite

(PBBS)[9]는 BFS를 포함하여 Comparisonsort,Integersort,Remove

Duplicates,Dictionary,Suffix Array, MaximalIndependent Set,

MaximalMatching,Minimum Spanning Forest,Spanning Forest,

Convex Hull, Delaunay Triangulation, Delaunay Refinement,

K-NearestNeighbors,Ray-TriangleIntersection,NbodyForces등 여

러 가지 로그램으로 구성되어있다.

PBBS는 여러 가지 방식으로 병렬화 된 구 을 제공한다. 기 버

에서는 Clikplus[10]만 지원하 으나,그 이후로 cilk++와 OpenMP를 이

용한 병렬화도 지원한다.

PBBS의 BFS는 Serial,Deterministic parallel,Non-deterministic

parallel3가지 버 의 구 이 제공된다.Serial은 일반 인 구 으로 병

렬이 아닌 순차 으로 처리한다.Parallel은 Deterministic parallel과

Non-deterministicparallel2가지로 나뉜다.Non-deterministicparallel은

병렬처리 특성 때문에 실행마다 결과가 다르지만,Deterministicparallel

은 특별한 기법을 용하여 항상 같은 결과 보장한다.PBBS에서는

Deterministicparallel을 구 하기 해 Prioritywrite방식을 사용한다.

Priority write[11]은 2단계로 구성되며,frontier인 노드들은 frontier

배열 내에서 자신의 치를 우선순 로 가진다.먼 1단계로 frontier들

은 자신의 우선순 를 방문하지 않은 모든 neighbor에게 쓴다.그 이후

-12-

2단계에서 frontier들은 neighbor의 우선순 를 읽고 자신과 같으면,

frontier는 해당 neighbor의 parent가 되고 neighbor를 다음회차 frontier

배열에 넣는다.그리고 neighbor들은 재 frontier의 우선순 로 다음

회차 frontier배열에 넣어진다.

0

4

5

6

7

2

3

80

4 5 6

2 7 3

8

입력그래프 배열

그림 15Prioritywrite

Parallel버 에서는 Dataparalleloperator[12] Scan과 Filter를 사

용한다.Scan은 체 frontier에 해 차수의 Prefixsum을 계산하기

해 사용되고,Filter는 기 방문한 neighbor를 frontier배열에서 제거하기

사용한다.

Scan( + , [1, 2, 4, 2, 3, 3, 5] )

→ [0, 1, 3, 7, 9, 12, 15, 20]

List = [ 1, 2, 0, 5, 0, 12, 7, 0, 0, 2]Filter( num != 0, List )

→ [1, 2, 5, 12, 7, 2]

그림 16Scan,Filter동작 시

-13-

제 4 Galois

Galois[13]는 병렬 로그램을 쉽게 작성하기 한 일종의 임워크

로 2011년 ACM ConferenceonProgrammingLanguageDesignand

Implementation에서 발표된 “Thetaoofparallelism inalgorithms”를 통

해 기본 원리를 설명하고 있다.

Galois는 해당 임워크를 이용하여 작성된 벤치마크들을 포함하고

있으며,작성된 벤치마크로는 AgglomerativeClustering, Barnes-Hut,

BC, BFS, GMetis, Independent Set, Max Cardinality Bipartite

Matching,Minimum Spanning Tree,Preflow-Push,SSSP,Survey

Propagation등이 있다.

Galois의 BFS는 Bellman-Ford알고리즘[14][15]을 수정하고 용하여

BFS를 수행한다.Bellman-Ford알고리즘은 유향가 그래 에서 최단경

로 문제를 푸는 알고리즘으로 1958년과 1956년에 Richard Bellman,

LesterFord,Jr.에 의해 각각 발표되었다.

최단경로 탐색이라는 같은 목 을 가진 Dijkstra알고리즘[16]보다 수

행속도는 느리지만 가 치 음수가 있는 그래 에도 용이 가능하다

는 특징이 있다.

Bellman-Ford알고리즘의 동작은,먼 소스노드의 가 치를 0으로

설정하고 모든 나머지 노드는 가 치를 무한 값으로 기화를 한다.

그 다음,출발할 노드의 가 치와 엣지의 가 치를 더한 값이 도착할 노

드의 가 치보다 작으면 해당 값으로 체하고 그 경로를 최단경로로 설

정한다.같은 방식으로 모든 노드를 순회하며 최단경로를 찾는다.

Bellman-Ford 알고리즘은 기본 으로 유향가 그래 를 상으로

용하지만,BFS는 비가 그래 에 용하므로,모든 엣지의 가 치를 1

로 설정하여 Bellman-Ford알고리즘을 용한다.

-14-

−

-15

8 10

21

12

8

-7

84

9

3115

⑦

−

⑧

−

-15

8 10

21

12

8

-7

84

9

3115

⑤

−

-15

8 10

21

12

8

-7

84

9

3115

⑥

−

∞

-15

8 10

21

12

8

-7

84

9

3115

③

−

-15

8 10

21

12

8

-7

84

9

3115

④

∞

∞

∞

∞ ∞

∞

∞

-15

8 10

21

12

8

-7

84

9

3115

①

∞

∞

∞

∞

-15

8 10

21

12

8

-7

84

9

3115

②

그림 17Bellman-Ford알고리즘

-15-

제 5 Green-Marl

Green-Marl[17]은 그래 알고리즘을 쉽게 작성하기 한 Domain

Specific-Language(DSL)로 37th International Conference on

ArchitecturalSupportfor Programming Languages and Operating

Systems에서 처음 발표되었다.Built-inBFS템 릿과 Built-in DFSt

템 릿를 이용하여 그래 순회 알고리즘을 작성할 수 있으며, BFS와

DFS의 구 은 용 컴 일러에 내장되어 있다.

Green-MarlBFS는 기에 순회할 노드가 을 때는 순차 으로 진

행하며, 벨을 거치며 순회해야 할 노드가 늘어나면 OpenMPAPI를 이

용하여 병렬 으로 처리한다. 다른 특징으로는 Green-MarlBuilt-in

BFS은 Efficientcode-generationtemplates을 사용한다.

Efficientcode-generationtemplates[18]의 개념은 SungpackHong등

이 2011년 InternationalConference on ParallelArchitectures and

Compilation Techniques에서 발표한 “Efficient Parallel Graph

Exploration on Multi-Core CPU and GPU”에서 소개되었다.Level

synchronous Parallel BFS을 보완한 Queue-based method와

Read-basedmethod를 순회해야 할 노드 수에 따라 교차 으로 사용하

는 Hybridmethod사용한다.

LevelsynchronousParallelBFS는 소스노드부터 시작해서 연결된 모

든 노드를 방문하는 순회 알고리즘으로 소스노드와 가까운 노드부터 우

선 으로 방문한다.소스노드에서 같은 벨(hop-distance)을 가진 노드

들은 병렬 으로 근 가능하다.단 으로는 매 벨마다 동기화가 필요

하며 각 벨에 치한 노드 수만큼까지만 병렬화가 가능하도록 제한된

다.

Queue-basedmethod는 Visitedset을 큐 신에 비트맵으로 구 하

며 비트맵을 원자 으로 업데이트하기 해 test,test&setoperation사

용한다.그리고 Next-level노드를 장할 스 드별 localqueue와 local

queue들을 모을 globalqueue사용한다.

-16-

Read-basedmethod는 Next-levelset과 Current-levelset을 큐 신

배열로 구 한다.그로 인해 Queueoverhead가 감소하고 메모리 근패

턴이 보다 순차 으로 바 는 장 이 있다.하지만 High-diameter

graphs등 worst-caseinputs에 해서 취약하다.

두 method 어떤 method가 사용될지는 벨의 노드와 다음

벨의 노드의 수로 결정지어진다.Queue-basedmethod를 사용하던

다음 벨의 노드수가 미리 정해둔 임계치인 T2보다 크고 벨의 노

드보다 α배 이상 크다면,상태를 Read-basedmethod로 바꾼다.반 로

Read-basedmethod사용 엔 다음 벨의 노드의 수가 벨의 노

드 수의 β배보다 작다면 Queue-basedmethod로 순회방법을 바꾼다.여

기서 α와 β,T2는 미리 정해진 상수 값으로 해당 값들은 상황에 맞춰

조정하여 사용한다.

QUEUE

QUEUETo

READ

READTo

QUEUE

READSEQ

#Next >

#Next ≤

(#Next > ) && (#Next > ∗ #Current)

(#Next ≤ ) || (#Next ≤ ∗ #Current)

#Next < ∗ #Current

#Next ≥ ∗#Current

그림 18Hybridmethod

-17-

제 4장 CRONO BenchmarkSuite구 개선

제 1 문제

CRONO는 기본 으로 실제 물리컴퓨터를 상정하고 개발된 벤치마크

가 아니라 멀티코어 시뮬 이터 환경을 고려하여 설계된 벤치마크이다.

따라서 순회의 효율성보다는 구 의 간편함과 병렬 처리를 극 화하는

것에 이 맞춰져 있다.

멀티스 드 수행을 해 0부터 가장 큰 노드번호를 스 드 개수로 N

등분하여 각 등분을 해당 코어에 할당한다.노드번호가 체 으로 고르

게 분포할 경우에는 의 같은 방법을 사용해도 무방하지만,노드가 특

정 역에 편 되어 있다면 해당 역을 할당받은 스 드는 로드가 과

하다. 를 들어 0,1,2,4,6,7,10,31번 노드가 존재하고 스 드가 4개

일 경우 0번 스 드는 0,1,2,4,6,7번 노드,1번 스 드는 10번 노드,

2번 스 드는 할당받은 노드가 없으며,3번 스 드는 31번 노드를 담당

하게 된다.

재 CRONO의 BFS는 회차 frontier의 neighbor 처음 방문하

는 노드를 임시배열에 장 후,frontier배열에 입하여 다음회차에서

사용한다. 재 구 에서는 frontier배열에 입 후 임시배열을 기화

하지 않기 때문에 재 frontier의 neighbor만 탐색하는 것이 아니라 이

회차들의 모든 neighbor를 탐색하여 이미 탐색한 노드까지 다시 탐색

한다.

한 순회 종료조건이 일반 인 BFS와는 다르게 가장 큰 노드번호를

가진 노드를 만나거나,순회 횟수가 체 노드보다 많을 때 순회를 종료

하도록 되어 있다.그 기 때문에 모든 노드를 순회하지 않더라도 가장

큰 노드번호를 가진 노드를 만나면 순회가 종료되어 체 그래 를 탐색

할 수 없다.

-18-

제 2 개선

이미 방문하여 frontier로 사용된 노드가 다시 frontier배열에 들어가

는 것을 방지하기 해 임시배열을 매 회차가 종료될 때 기화하 다.

이를 통해 불필요한 순회를 이고 결과 으로 성능을 향상시킬 수 있었

다.다음으로 순회종료조건을 수정하 다.기존의 2가지 종료조건인 1)

가장 큰 노드번호를 가진 노드를 만나거나,2)노드 순회 횟수가 체

노드보다 클 때 에,1번 종료조건을 삭제하고 더 이상 순회를 시작할

frontier가 없을 경우로 수정하 다.

0 10 20 30 40 50 60 70 80 90 100

actor-collaboration

soc-pokec-relationships

roadNet-CA

com-amazon.ungraph

수행시간 (단위 : 초)

file read mem alloc etc bfs

1400

그림 19구 개선 CRONO수행시간

0 10 20 30 40 50 60 70 80 90 100

actor-collaboration

soc-pokec-relationships

roadNet-CA

com-amazon.ungraph

수행시간 (단위 : 초)

file read mem alloc etc bfs

그림 20구 개선 후 CRONO수행시간

-19-

그림 19와 그림 20은 CRONOBenchmarkSuiteBFS를 4가지 워크로

드에 해 수행하 을 때 수정 과 수정 후의 수행 시간을 나타낸다.

com-amazon.ungraph과 roadNet-CA 워크로드의 경우엔 수행시간이 확

연히 단축되어 성능이 향상됨을 볼 수 있었다.soc-pokec-relationships

과 actor-collaboration은 체 인 수행시간은 비슷하게 보이지만,수정

에는 제일 큰 노드번호를 가진 노드를 비교 순회 기에 만나 종료

되기 때문에 짧은 시간에 로그램이 종료되었지만,수정 후에는 그래

의 모든 노드를 순회하 음에도 수행시간이 더 짧은 것을 보아 성능이

향상되었음을 알 수 있다.

-20-

제 5장 실 험

제 1 실험환경 구성

실험은 수행 시간과 메모리 근을 척도로 진행하 다.수행 시간은

체 인 로그램의 수행시간과 BFS알고리즘의 수행시간을 나 어서

분석하 고,IntelVtuneprofiler[19]를 이용하여 측정하 다.메모리

근은 MemoryAccessPerKiloInstruction(MAPKI)와 메모리 사용량을

측정하여 경향을 분석하 으며 실험 환경은 아래와 같다.

구분 환경

CPUXeonE5-2650v22.6GHz,1socket,8corespersocket

HyperThreadingdisabled,HW prefetchoff,DVFSoff

메모리4memorychannel,DDR31600,64GB

4ranksperchannel,8banks& 4GBperrank

운 체제 CentOS7.1(kernelversion:3.12.30)

반복횟수 10회

표 1실험환경

체 수행 시간은 기능에 따라 크게 3부분으로 나 수 있다. 일로

부터 노드 정보를 읽어오고,읽어온 노드 정보를 바탕으로 그래 를 생

성하고,해당 그래 를 BFS를 이용하여 순회하는 부분으로 구분하 다.

와 같이 3부분으로 구분하 지만 일 입력과 그래 생성에 비해

BFS를 수행하는 시간이 으로 짧다.이런 문제의 원인으로는 부

분의 벤치마크가 순회를 시작할 소스노드를 0번 노드로 고정하고 있고,

한 오직 하나의 소스노드에 해서만 그래 를 순회하기 때문이다.

BFS의 성능을 비교하기 해서는 어느 정도 그래 순회 시간이 길

어야 한다.하지만 모든 입력 그래 가 0번 노드를 가지고 있다고 보기

어렵고,여러 커뮤니티로 분할된 그래 에서는 0번 노드의 차수가 작다

-21-

면 확률 으로 작은 역만을 순회하기 때문에 BFS수행시간이 짧다.

이런 문제를 해결하기 해 한 번의 일 입력과 그래 생성 후 서

로 다른 10개의 소스노드에 해 BFS를 수행할 수 있도록 코드를 일부

수정하 다. 한 가능한 체 그래 를 탐색하거나 만약 커뮤니티가 나

뉘어져 있다면 최 한 그래 의 많은 부분을 탐색하기 해 차수를 기

으로 상 10개의 노드를 선정하 으며,비교를 해 차수와 상 없이

임의의 노드 10개를 더 선정하 다.이러한 방식으로 10개씩 선정한 노

드를 소스노드로 사용하여 BFS의 수행시간 비교를 용이하게 하 다.

0

20

40

60

80

100

120

140

160

180

De

gre

e

Node

그림 21임의의 노드 10개 선정

0

20

40

60

80

100

120

140

160

180

De

gre

e

Node

그림 22차수 기 상 10개 선정

-22-

roadNet-CA soc-LiveJournal1 actor-collaboration

Node Degree Node Degree Node Degree

1 562818 12 10009 20293 126 8382

2 534751 10 37356 15163 3446 7868

3 521168 10 87 13050 2506 7706

4 1795416 9 40748 8428 215 7230

5 1872330 8 91341 8180 3562 7175

6 1780830 8 102293 5597 2351 7013

7 1631015 8 39370 4879 290 6978

8 1616784 8 92961 4758 2497 6951

9 1545464 8 39369 4572 2408 6566

10 1495419 8 37188 3265 1297 6445

orkut-groupmembership soc-pokec-relationships

Node Degree Node Degree

1 160756 40425 5867 8763

2 244013 14192 1891 7564

3 1604162 6171 5935 6785

4 1406943 5922 189 6661

5 392751 5157 25994 4535

6 1022074 4680 6228 3878

7 446555 4652 107646 2375

8 1155385 4109 8413 2315

9 1104147 3743 1830 1757

10 429154 3373 36521 1693

표 2워크로드별 차수 기 상 10개 노드

실험에 사용할 워크로드는 노드와 엣지의 수를 고려하여 다양하게 선

정하 다.roadNet-CA(roadCA)는 캘리포니아지역의 도로망을 표 한

그래 로 노드는 교차로나 종 을 나타내고 엣지는 교차로나 종 을 연

결하는 도로를 나타낸다.도로망에 한 그래 이므로 평균 차수가 낮다

는 특징을 가진다.

soc-LiveJournal1(soclive)과 soc-pokec-relationships(pokec),orkut-

groupmemberships(orkmem)는 소셜네트워크 사용자데이터를 나타낸다.

LiveJournal은 인터넷 사용자들이 블로그,간행물,일기를 쓸 수 있는

소셜네트워크 서비스로 약 천만 명 이상의 사용자를 가지고 있고,Pokec

은 슬로바키아에서 가장 인지도 높은 소셜네트워크 서비스로 10년 이상

-23-

서비스를 지속하고 있다.마지막으로 Orkut은 구 이 제공하는 소셜네트

워킹 웹사이트로 서비스를 개발한 직원으로부터 이름을 따왔다.

orkut-groupmemberships은 다른 두 소셜네트워크 사용자데이터와는 다

르게 사용자정보와 그룹정보까지도 함께 포함하고 있다.마지막으로

out.actor-collaboration(actor)은 1999년까지의 미국 배우들의 업 계를

그래 로 표 한 것이다.노드는 각각의 배우를 나타내고,두 배우가 같

은 화에 출연하 다면 두 배우를 나타내는 노드들은 엣지로 연결된다.

이름 노드수 엣지수평균degree

설명

roadNet-CA 1,965,206 2,766,607 1.408California의도로네트워크

soc-LiveJournal1

4,847,571 68,993,773 14.233LiveJournal온라인소셜네트워크

soc-pokec-relationships

1,632,803 30,622,564 18.755Pokec온라인소셜네트워크

orkut-memberships

11,514,053 327,037,487 28.403Orkut온라인소셜네트워크

actor-collaboration

382,219 33,115,812 86.641 화배우간의업 계

표 3사용한 워크로드[20][21]

제 2 수행시간 측면에서의 성능 비교

1.워크로드별 실험 결과

실험환경에서 10개의 소스노드를 사용하도록 수정하 기 때문에 두드

러지게 BFS부분의 비 이 커진 것을 볼 수 있다.이를 통해 다음 항에

서 다룰 벤치마크별 수행 결과의 분석이 용이하게 되었다.

그래 에서 top10은 차수 기 상 10개의 소스노드를 사용한 결과

이고,random은 임의의 노드에 한 결과이다. 체 으로 top10의 수행

시간이 random에 비해 오래 걸리거나 비슷하 다.이는 확률 으로

top10이 그래 의 더 많은 부분을 순회했다고 볼 수 있다.다만 차수의

차이에 비해 수행시간의 차이가 두드러지지 않은 것은 top10과 random

-24-

모두 해당 그래 상에 존재하는 노드를 선택하 기 때문이다.따라서

소스노드가 그래 상에 존재하지 않아 바로 종료되는 비정상 인 상황

이 발생하지 않는다.

벤치마크들의 체 수행시간이 동일한 워크로드에 해서 많은 차이

를 보인다.이는 BFS알고리즘의 차이로 인해 발생되기도 하지만,더 두

드러진 요인은 일을 읽거나 그래 를 생성하는 방식의 차이로 발생한

다.하지만 본 실험의 목 은 BFS의 성능비교이므로 BFS순회시간만을

고려하 다.

차수가 낮은 워크로드에서는 4개의 벤치마크가 모두 비슷한 성능을

보 다. 하지만 평균 차수가 높은 워크로드에서는 Green-Marl과

GAPBS가 다른 벤치마크보다 유리한 것을 볼 수 있다.이는 Green-

Marl과 GAPBS은 neighbor와 frontier의 수에 따라 근법을 바꾸기 때

문에 상 으로 복잡하다고 단될 수 있는 차수가 높은 워크로드에서

성능이 우수한 것을 알 수 있다.

0 0.5 1 1.5 2 2.5 3 3.5

GAPBS

PBBS

Galois

Green-Marl

GAPBS

PBBS

Galois

Green-Marl

top

10

ran

do

m

BFS build graph file read verify etc

그림 23벤치마크별 roadNet-CA수행시간

-25-

0 5 10 15 20 25 30

GAPBS

PBBS

Galois

Green-Marl

GAPBS

PBBS

Galois

Green-Marl

top

10

ran

do

m

BFS build graph file read verify etc

그림 24벤치마크별 LiveJournal1수행시간

0 2 4 6 8 10 12

GAPBS

PBBS

Galois

Green-Marl

GAPBS

PBBS

Galois

Green-Marl

top

10

ran

do

m

BFS build graph file read verify etc

그림 25벤치마크별 pokec-relationships수행시간

-26-

0 20 40 60 80 100 120

GAPBS

PBBS

Galois

Green-Marl

GAPBS

PBBS

Galois

Green-Marl

top

10

ran

do

m

BFS build graph file read verify etc

그림 26벤치마크별 orkut-memberships수행시간

0 2 4 6 8 10 12 14

GAPBS

PBBS

Galois

Green-Marl

GAPBS

PBBS

Galois

Green-Marl

top

10

ran

do

m

BFS build graph file read verify etc

그림 27벤치마크별 actor-collaboration수행시간

-27-

2.벤치마크별 실험 결과

그림 28,29,30,31은 벤치마크별로 각 워크로드에 해 체 수행시

간과 BFS수행시간동안의 주요동작들을 나타낸다. 체 수행시간의 주

요동작은 부분 유사하게 구분되었지만,BFS는 벤치마크별로 상이한

알고리즘을 용하 기 때문에 주요동작들이 다르게 구분된다.

Galois와 PBBS는 일반 인 알고리즘을 사용하 기 때문에 결과가 유

사하다. 체 으로 보면 neighbor를 순회하고 이미 방문한 노드인지 확

인하는 등 neighbor의 정보를 확인하는데 부분의 시간을 사용하는 것

을 볼 수 있다.이 두 벤치마크의 BFS순회시간은 워크로드의 엣지의

수와 유사한 경향을 보인다.이를 통해 엣지가 많을수록 확인해야할

neighbor가 많고 시간이 오래 걸린다는 것을 확인을 할 수 있다.

GAPBS과 Green-Marl은 차수가 높은,즉 frontier에 비해 neighbor가

매우 많은 경우에는 기존과는 다른 근법을 사용하여 속도를 향상시키

는 기법을 사용하고 있다.오른쪽 결과에서 볼 수 있듯이 평균 차수가

높은 워크로드에서는 GAPBS은 Bottom-up,Green-Marl은 Read-based

method가 많은 부분을 차지하는 것을 확인할 수 있다.

0 10 20 30 40 50 60

top10

random

top10

random

top10

random

top10

random

top10

random

roa

dC

Asocliv

eo

rkm

em

acto

rpo

ke

c BFS

verify

build graph

etc

0 5 10 15 20 25 30

top10

random

top10

random

top10

random

top10

random

top10

random

roa

dC

Asocliv

eo

rkm

em

acto

rpo

ke

c neighbor 순회neighbor의 distance 확인neighbor를 frontier에추가etc

그림 28워크로드별 Galois수행시간

-28-

0 20 40 60 80

top10

random

top10

random

top10

random

top10

random

top10

random

road

CA

socl

ive

orkm

em

act

or

poke

c BFS

file read

build graph

etc

0 5 10 15 20 25

top10

random

top10

random

top10

random

top10

random

top10

random

road

CA

socl

ive

orkm

em

act

or

poke

c neighbor 순회

neighbor visited 여부확인

neighbor를 frontier에추가

etc

그림 29워크로드별 PBBS수행시간

0 20 40 60 80 100 120

top10

random

top10

random

top10

random

top10

random

top10

random

road

CA

socl

ive

orkm

em

acto

rp

okec

BFS

file read

build graph

etc

0 2 4 6 8

top10

random

top10

random

top10

random

top10

random

top10

random

road

CA

socl

ive

orkm

em

acto

rp

okec

TD

BU

Init parent

bitmap to Q

etc

그림 30워크로드별 GAPBS수행시간

0 10 20 30 40 50

top10

random

top10

random

top10

random

top10

random

top10

random

road

CA

socl

ive

orkm

em

acto

rp

okec

BFS

file read

build graph

etc

0 1 2 3 4 5 6

top10

random

top10

random

top10

random

top10

random

top10

random

road

CA

socl

ive

orkm

em

acto

rp

okec

Read-based

Queue-based

etc

그림 31워크로드별 Green-Marl수행시간

-29-

제 3 메모리 측면에서의 성능 비교

메모리 측면에서는 MemoryAccessPerKiloInstruction(MAPKI)와

메모리사용량을 측정하여 분석하 다.MAPKI는 1,000개의 명령어 당 메

모리 근횟수를 나타내는 값으로,값이 클수록 해당 로그램이 빈번하

게 메모리를 근한다고 볼 수 있다.

메모리사용량을 보면 두 가지를 확인 할 수 있다.첫 번째로 워크로

드의 노드와 엣지의 수가 메모리 사용량과 비례한다.그림 32와 그림 33

은 워크로드별 메모리사용량과 엣지의 수를 나타내며,두 지표의 경향이

동일한 것을 알 수 있다.

두 번째로는 벤치마크의 수행시간과 메모리 사용량이 비례한다.수행

시간이 짧은 벤치마크일수록 메모리사용량이 고,이는 메모리사용량을

개선하면 수행시간을 향상시킬 수 있음을 나타낸다.

0 2000 4000 6000 8000 10000 12000 14000 16000 18000

actor_collaboration

ork_memberships

soc-pokec-relationships

roadNet_CA

soc-LiveJournal1

Galois Green-Marl PBBS GAPBS

그림 32각 벤치마크의 워크로드별 메모리 사용량 (단 :MB)

-30-

0 100,000,000 200,000,000 300,000,000 400,000,000

actor_collaboration

ork_memberships

soc-pokec-relationships

roadNet_CA

soc-LiveJournal1

엣지 노드

그림 33워크로드별 노드와 엣지 수

메모리 근빈도인 MAPKI를 살펴보면 GAPBS가 다른 벤치마크와

비교하여 메모리를 히 게 근한다.이는 GAPBS의 Direction-

optimizing알고리즘의 Bottom-up방식 때문이다.

Bottom-up방식은 확인해야 할 neighbor가 많을 경우 순회방향을

neighbor에서 frontier로 바꿔서 확인해야 할 엣지의 수를 여 다.이

로 인해 다른 벤치마크에 비해 메모리를 근하는 빈도를 낮출 수 있으

며,결과 으로 메모리 근으로 인해 생기는 지연을 여 체 인 수

행시간을 일 수 있다.

Green-Marl의 경우는 Read-basedmethod를 수행시간 단축의 요인으

로 볼 수 있다.GAPBS의 Bottom-up처럼 메모리 근 자체를 여주진

않지만 배열을 사용하여 보다 순차 인 메모리 근을 하도록 하여 수행

시간을 인다.

-31-

0.000 2.000 4.000 6.000 8.000 10.000 12.000 14.000

actor_collaboration

ork_memberships

soc-pokec-relationships

roadNet_CA

soc-LiveJournal1

Galois Green-Marl PBBS GAPBS

그림 34각 벤치마크의 워크로드별 MAPKI

-32-

제 6장 결 론

그래 데이터분석에서 그래 의 순회는 체 인 수행능력에서 상

당한 부분을 차지한다.따라서 그래 순회를 향상시킨다면 그래 분석

이 한층 더 용이해질 수 있다.BFS는 표 인 그래 순회알고리즘으

로 체 인 틀은 같지만 세부 으로 다양한 구 들이 존재하며,특정

요건에 따라 유리한 벤치마크가 존재한다.따라서 벤치마크들의 특징을

알아보고 워크로드별 성능을 측정하여 벤치마크들을 비교하는 것이 필요

하다.

본 논문에서는 BFS순회알고리즘을 구 한 벤치마크들의 성능비교와

특정 벤치마크에 한 구 개선에 한 연구를 진행하 다.사용된 벤치

마크들은 서로 다른 특징을 가진 5개의 벤치마크로 CRONO,Galois,

GAPBS,Green-Marl,PBBS등이 사용되었다.

수행시간과 메모리측면에서 실험을 진행하여 벤치마크들을 분석하여

두 가지의 특징을 확인하 다.첫 번째로 워크로드의 차수가 낮을 때는

모든 벤치마크가 비슷하며 GAPBS,Green-Marl은 가변 인 근법을

사용하여 차수가 높아질수록 유리하다.그리고 나머지 벤치마크들은 엣

지의 수와 수행시간이 비례한다.

다음으로 메모리사용량은 엣지의 수,즉 수행시간과 비례한다.따라서

메모리사용량을 이면 수행시간측면에서 이득이 된다.메모리 근빈도

측면에서는 Direction-optimizing알고리즘을 사용한 GAPBS가 근빈도

가 낮으며 수행시간도 짧다.Green-Marl은 다른 벤치마크들과 메모리를

비슷하게 근하지만 순차 근을 하여 수행시간이 다른 벤치마크에

비해 짧다.

따라서 와 같은 특징들은 BFS순회 성능을 향상시키는 작업의 착

안 이 될 수 있다. 의 결과를 보면 체 인 수행시간이 연산보다는

메모리에 민감하게 반응 한다.따라서 순회할 워크로드의 노드와 엣지

수는 바꿀 수 없지만 알고리즘의 구 자체를 개선하거나 메모리 근 방

식을 최 화함으로써 체 인 성능을 향상시킬 수 있을 것이다.

-33-

참 고 문 헌

[1] Statista 2015,“Numberofmonthly active Facebook users

worldwideasof3rdquarter2015“[Online].Available:

http://www.statista.com/statistics/264810/number-of-monthly-a

ctive-facebook-users-worldwide/

[2] Statista 2015,“Number of monthly active Twitter users

worldwidefrom 1stquarter2010to3rdquarter2015“[Online].

Available:

http://www.statista.com/statistics/282087/number-of-monthly-a

ctive-twitter-users/

[3] Robin J.Wilson,“Introduction to Graph Theory 4th ed“,

Prentice Hall,1996.

[4] E.F.Moore,“Theshortestpath through amaze“,,in the

InternationalSymposium ontheTheoryofSwitching,Harvard

UniversityPress,1959.

[5] M.Ahmad,F.Hijaz,Q.Shiand O.Khan,“CRONO:A

Benchmark Suite for Multithreaded Graph Algorithms

ExecutingonFuturisticMulticores“,inIISWC,2013.

[6] S.Beamer,K.Asanovic,and D.A.Patterson,“TheGAP

benchmarksuite“,arXiv:1508.03619,2015.

[7] “OpenMP“ [Online].Available:http://openmp.org/wp/

[8] S.Beamer,K.Asanovic,and D.A.Patterson,“Direction-

optimizingbreadth-firstsearch“,inSC,2012.

[9] J.Shun,G.E.Blelloch,J.T.Fineman,P.B.Gibbons,A.

Kyrola, Ha. V. Simhadri and K. Tangwongsan, “Brief

Announcement:The Problem Based Benchmark Suite“,in

SPAA,2012.

[10] “CilkPlus“[Online].Available:https://www.cilkplus.org/

-34-

[11] G.E.Blelloch,J.T.Fineman,P.B.Gibbons,andJ.Shun,

“InternallyDeterministicParallelAlgorithmsCanBeFast“,in

PPoPP,2012.

[12] Eric Holk, “Data Parallel Operator“ [Online]. Available:

http://blog.theincredibleholk.org/blog/2013/05/14/data-parallel-op

erators/

[13] K.Pingali,D.Nguyen,M.Kulkarni,M.Burtscher,M.A.

Hassaan,R.Kaleem,T-H.Lee,A.Lenharth,R.Manevich,M.

Méndez-Lojo, D. Prountzos, and X. Sui, “The tao of

parallelism inalgorithms“,PLDI,2011.

[14] RichardBellman,“Onaroutingproblem“,QuarterlyofApplied

Mathematics16(1),1958.

[15] L.R.Ford and D.R.Fulkerson,“Flows in Networks“,

PrincetonUniversityPress,1962.

[16] E.W.Dijkstra,“A NoteonTwoProblemsinConnexionwith

Graphs“,NumerischeMathematik1,1959.

[17] S.Hong,H.Chafi,E.SedlarandK.Olukotun,“Green-Marl:

A DSL foreasyandefficientgraphanalysis“,inASPLOS,

2012.

[18] S.Hong,T.Oguntebiand K.Olukotun,“Efficientparallel

graphexploration onmulti-coreCPU andGPU“,in PACT,

2011

[19] “VTune“[Online].Available:

https://software.intel.com/en-us/intel-vtune-amplifier-xe

[20] JureLeskovecandAndrejKrevl,“SNAP Datasets:Stanford

LargeNet-workDatasetCollection“,2014[Online].Available:

http://snap.stanford.edu/data/

[21] “konectnetworkdataset– KONECT“,2015[Online].Available:

http://konect.uni-koblenz.de/

-35-

Abstract

AStudyonPerformance

ComparisonandImprovementof

Breadth-FirstSearchBenchmarks

SangminLee

DepartmentofTransdisciplinaryStudies

GraduateSchoolofConvergenceScienceandTechnology

SeoulNationalUniversity

RecentlytheSocialnetworkdata'simportancyhasgrow upasthe

explosivegrowth ofSocialnetwork.Thevestdataisstored and

analyzedbyusingGraphdatastructure.

Graphistheexpression,how toexpressobjectasconnectwith

line.Insocialnetwork,NodemeansuserandEdgeisrelationofuser.

Itisnecessaryforanalysetotakethemeaningfulinformationfrom

theseSocialnetworkdata.Analyzingthedataisprogresstotraverse

allofNodeandchecktheNode'scondition.ThusGraphtraversalis

importantpartforSocialnetworkanalyze.

First of all, Breadth-First Search(BFS), representative Graph

traversalalgorithm,preferentially visittheallNodenearby Source

node,whichpointofstartingtraversal.Nextistraversethevisited

-36-

Neighbor'sNodeprogressively.Thesemethodoftraversecanprocess

Nodeinparallel,duetoaccessNodeatthesamelevelconcurrently.

Although BFS's whole frame is same, BFS has several

implementationofbenchmark.Somebenchmarkreducethenumberof

Edge to check and others change the orderofaccess Node to

improveperformance.Inaddition,Eachcharacteristicofbenchmarkis

various.Soperformanceisdifferent,eventhoughsameworkloadis

used.

Inthispaper,weselect5representativeBFS benchmarkswhich

arerecentlyannounced.Wecompareandanalyzeforperformanceas

theaspectofexecutiontimeandmemory.Weproposetheappropriate

benchmark asweconsidertheworkload'scharacteristic.And we

improve the performance by revising the implementation about

CRONO benchmark.In addition,as correlation analysis between

memoryandbenchmark'sperformance,show thepossibilityofoverall

performance improve by optimizing the implementation and the

memoryaccesspattern,

keywords:Bigdata,Graph,Breadth-FristSearch,Benchmark

StudentNumber:2014-24844