UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA 1

Avaliando Técnicas de Particionamento e

Execução Paralela do Algoritmo Pagerank
Fabrício Leite Soares

Resumo—PageRank é um algoritmo fundamental para
avaliar a importância de vértices num grafo. Nesse artigo,
métodos de otimização desse algoritmo são apresentados e
discutidos. É feito um estudo sobre o impacto (i) do uso
paradigma scatter-gather centrado em arestas para superar
problemas causados por empobrecimento inato a grafos
em termos de localidade de memória; (ii) de uma técnica
de particionamento que utiliza vértices não-sobrepostos tal
que os dados de cada vértice se encaixem em linhas da
cache de maneira unívoca; ordenando arestas de saída com
base em seu destino para minimizar o número de escritas
aleatórias em memória. Tal técnica de particionamento re-
duz de maneira significante acessos a memória principal e
melhora a largura de banda em até 3x, e também permite
a diferentes núcleos de CPU processarem diferentes conjun-
tos de vértices, possibilitando um processamento paralelo.
Uma implementação contendo estas melhorias foi testada e
avaliada com conjuntos de dados sintéticos e experimentos
são apresentados levando em conta métricas como tempo de
execução, acessos a memória e quantidade de cache miss (para
diferentes níveis de cache).
I. I NTRODUÇÃO
A análise de Grafos é uma parte crítica de diversas
aplicações como análise de genoma, segurança da infor-
mação e redes sociais [1], [2], [3]. No entanto, conseguir
trazer alta performance em grande escala para esse
processo é um desafio. Isso se dá principalmente por
causa do tamanho dos dados e a natureza dos grafos, que
demonstram baixa localidade espacial e temporal. Como
consequência, o tempo de execução é dominado pela
quantidade de acessos à memória externa [4]. Para me-
lhorar essa performance, técnicas de pré-processamento
que levam em conta a disposição dos dados do grafo em
memória e sua ordenação são comuns [5], [6].
O algoritmo PageRank [7] foi desenvolvido para de-
terminar a popularidade de páginas web com respeito
as seus links de entradas e saída, funcionando como
componente principal de algoritmos de busca com ran-
king. Com o tempo esse algoritmo perdeu sua impor-
tância nesse tipo de aplicação, sendo substituído por
abordagens baseadas em conhecimento e web semân-
tica. No entanto, continua estando presente em diversos
cenários onde a medidas de centralidade também são
importantes, como Análise Semântica[8], Desambigua-
ção de Palavras,[9] Sistemas de Recomendação[10] e
Bibliometria[11]. Este artigo busca discutir técnicas de
execução paralela do PageRank presentes na literatura,
mais especificamente:
• Analisar como o particionamento melhora a perfor-
mance de cache e possibilita a execução paralela em
plataformas multi-core.
• Verificar o impacto de técnicas do ajuste de dispo-
sição de dados.
• Comparar os resultados para o processamento de
diferentes grafos sob diferentes configurações.
II. F UNDAMENTAÇÃO T EÓRICA
A. PageRank
O algoritmo PageRank [7] é altamente utilizado para
obter um ranking de importância de vértices num grafo.
Os valores de PageRank de cada vértice indicam a proba-
bilidade de o vértice ser alcançado num percorrimento
aleatório, de forma que um valor de PageRank maior
sugere que o vértice possui maior importância. Quando
o grafo não se altera com o tempo, o algoritmo percorre
o grafo de forma iterativa, atualizando o valor PageRank
de cada vértice v com base na equação 1, onde d é
um fator de damping (geralmente igual a 0.85); |V | é o
número total de vértices do grafo; vi representa o vizinho
de v tal que v tem uma aresta de entrada a partir de vi ;
Li é a quantidade de arestas de saída de vi
1−d PageRank(vi )
PageRank(v) = +d×∑ (1)
|V | Li
B. Paradigma Scatter-Gather centrado em arestas
Diversos problemas de grafos podem ser processados
com base num modelo centrado em arestas denominado
Scatter-gather (tradução livre: espalhar-recolher) [4], [12].
UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA 2

Nesse modelo, as computações são iterativas, cada ite- da memória, como o tamanho da cache, tal que os dados
ração consistindo de uma fase de espalhamento (scatter) de vértice proporcionem reuso otimizado de dados.
seguida de uma fase de recolhimento (gather). Na fase de
espalhamento, cada aresta produz uma mensagem que Algoritmo 1: PageRank com particionamento
transmite os dados do vértice de origem a ser utilizado 1 Seja m o número de vértices em cada conjunto;
para atualizar os vértices de destino do aresta. Na fase de 2 enquanto não estiver pronto faça
recolhimento, todas as mensagens produzidas nas fases 3 Scatter:;
de espalhamento anteriores são utilizadas para atualizar 4 para cada partição faça
os vértices de destino correspondentes. 5 para cada aresta e na lista de arestas faça
6 Leia os dados do vértice e.src;
III. O TIMIZAÇÕES 7 Seja v = e.src;
8 Produza a mensagem msg;
Cache e performance de memória possuem um im- PR(v)
pacto no comportamento do PageRank. A abordagem 9 msg.value = #out(v)
;
escolhida para solucionar este problema foi proposta 10 msg.dest = e.dest;
por [13] e consiste em particionar todos os vértices em 11 Escreva msg na lista da partição b e.dest
m c;
conjuntos de tamanho igual. Supondo que cada conjunto 12 fim
de vértices tem tamanho m, o grafo será particionado 13 fim
|V | 14 Gather:;
em d m e partições, sendo a i-ésima partição responsável
por manter o conjunto de vértices que inclui vértices 15 para Cada partição faça
|V | 16 para cada mensagem msg na lista faça
com índices de i × m a (i + 1) × m − 1, (0 ≤ i < d m e).
Cada partição também possui uma lista de arestas e 17 Atualize PageRank do vértice msg.dest;
uma lista de mensagens. A lista de arestas armazena 18 fim
todos as arestas cujo os vértices de origem estão no 19 fim
conjunto de vértices da partição; a lista de mensagens 20 fim
armazena todas as mensagens cujo os vértices de destino
estão no conjunto de vértices da partição. A lista de
arestas de cada partição é a mesma durante toda a Algoritmo 2: Pagerank Multicor usando loops "for"
computação. Os dados de cada lista de mensagem são do OpenMP.
recomputados a cada fase do tipo scatter, e os dados 21 Seja k o número de partições;
do conjunto de vértice são atualizados a cada fase do 22 Seja p o número de núcleos;
tipo gather. A figura 1 mostra um exemplo de layout de 23 enquanto não estiver pronto faça
dados após os dados do grafo serem particionados. Note 24 para i de 0 a k − 1 faça
que os dados de cada vértice possuem tamanho igual 25 schedule(dynamic, kp );
e uniforme e portanto os requisitos de memória para 26 scatter(i);
cada conjunto de dados é igual. As listas de arestas e 27 fim
mensagens podem ter tamanho diferentes. Os requisitos 28 para i de 0 a k − 1 faça
de memória de cada lista de arestas depende do número 29 schedule(dynamic, kp );
de arestas cujo os vértices de origem estão no conjunto 30 scatter(i);
de vértices correspondente. Os requisitos de memória 31 fim
de cada lista de mensagem dependem do número de 32 fim
arestas cujo os vértices de destino estão no conjunto
de vértices correspondente. O Algoritmo 1 ilustra o
algoritmo PageRank com os ajustes de particionamento.
O particionamento do grafo leva a dois benefícios. IV. O TIMIZAÇÃO DO L AYOUT DE D ADOS
Primeiro, o processo de espalhamento e recolhimento de Os artigos [14], [6], [13] afirmam que cada sequência
cada partição pode ser realizado em paralelo em plata- de acesso a memória pode ser particionada em conjun-
formas multi-core. Segundo, é possível escolher tama- tos ainda menores compostos também por sequencias
nhos para conjuntos de vértices com base nos recursos de acesso a memória, propondo definir o número de
 ● Proposta de [S. Zhou et al, 2015]:
UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA 3
○ Divida todos os vértices em n = conjuntos de tamanho igual.

Dados do Grafo

Partição 0 Partição 1 Partição 2 Partição n

Vertices 0

Arestas 0
Vertices 1

Arestas 1
Vertices 2

Arestas 2
... Vertices n

Arestas n

Mensagens 0 Mensagens 1 Mensagens 2 Mensagens n

Figura 1: Particionamento de Grafo.

Otimização de Layout: Situação original: pior caso com O(|E|) acessos
Otimização de Layout: Situação: pior caso para k partições : O(k ) acessos
2

Ordem de
Lista de Arestas 0 Escreva DRAM
Percorrimento mensagens com Lista de Arestas 0 Escreva DRAM
Origem Destino base no destino
Lista de Mensagens 0
Ordem de
Percorrimento mensagens com

para vértices [0..99]

Origem Destino base no destino
0 10 Lista de Mensagens 0
0 10 para vértices [0..99]
0 101
Lista de Mensagens 1 78 20
1 201 para vértices [100..199] Lista de Mensagens 1
0 101 para vértices [100..199]
1 105
1 105
78 20 Lista de Mensagens 2
para vértices [200..299] 79 105 Lista de Mensagens 2
79 201
para vértices [200..299]
1 201
79 105 ...
79 201 ...

Figura 2: Acessos aleatórios a memória devidos a escrita

Figura 3: Acessos aleatórios a memória otimizados.
de mensagens.

conjuntos em relação ao número de acessos aleatórios Como mostrado no algoritmo 2, supondo que o processa-
em sequência. dor possui p núcleos, dividem-se todas as computações
No algoritmo 1, os acessos de memória feitos para ler das k em p trechos e se utiliza o escalonador dinâmico
arestas (linha 5) são sequenciais e os dados de vértices do OpenMP1 para processar cada um dos trechos em
são lidos a partir da cache (linha 6). No entanto, escrever cada um dos p núcleos disponíveis, com todos os núcleos
mensagens na RAM (linha 11) causa um acesso aleatório executando as computações de diferentes partições em
a memória. Isto ocorre devido ao fato de mensagens paralelo.
serem escritas na memória com base nos seus vértices
Durante tanto a fase scatter quanto a fase gather
de destino, que podem estar em qualquer uma das
de cada partição, os dados do conjunto de vértice da
listas de mensagens. No pior caso, escrever mensagens
partição são repetidamente acessados. Então, é desejável
na memória resulta, durante a fase scatter, em O(| E|)
armazenar os dados do conjunto de vértices na cache.
acessos aleatórios. A figura 2 ilustra como cada escrita
O artigo [13] propõe utilizar o número m de vértices de
de mensagem causa um acesso aleatório a memória.
cada conjunto de vértices baseado no tamanho da cache
Para minimizar este efeito, utilizou-se a proposta de
L2 de cada núcleo, tal que os dados de cada conjunto
[13], que tenta dispor os dados de forma que a lista de
ocupem este espaço, e quando um núcleo estiver execu-
arestas de cada partição fique ordenada em relação aos
tando uma das fases, poderá acessar os dados de vértices
vértices de destino. A figura 3 ilustra como cada escrita
de sua própria cache, em vez de precisar consultar a
ocorre após essa otimização
memória ou a cache de outros núcleos.
V. I MPLEMENTAÇÃO PARALELA
Utilizando as proposta de [13], [5], [6], [2] é possível
paralelizar o Algoritmo 1 para plataformas multinúcleos. 1 https://www.openmp.org
UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA 4

VI. R ESULTADOS DOS E XPERIMENTOS Nome do Conjunto Vértices Arestas Grau Médio
Kron24 [1] 16,7 M 536 M 16,1
A. Condições do Experimento Google+ [16] 28,9 M 463 M 15,2
Os experimentos foram conduzidos numa instância Kron25 [1] 33,5 M 1073 M 16,0
virtual dos serviços Google Cloud Compute Engine, uti- Pld [17] 43,0 M 623 M 14,5
lizando o processador Intel Xeon E5 Skylake2 @ 3.5GHz Twitter [18] 52,5 M 1963 M 37,4
executando o Sistema Operacional Ubuntu 18.04. As Sd1 [17] 94,9 M 1937 M 20,4

caches L1 e L2 por núcleo nesse processador possuem Tabela I: Diferentes Conjuntos de Dados utilizados
tamanho 64KB e 256KB respectivamente, e a cache L3
(compartilhada) tem tamanho de 20MB. Todo o código
milhões de arestas, com o grau médio no intervalo de
foi escrito em C++ e compilado com o compilador G++
15 a 37. As propriedades dos conjuntos de dados estão
versão 9 com a flag de otimização -O3. Estatísticas de me-
sumarizadas na tabela I.
mória e cache foram coletadas utilizando a ferramenta
Kron24 e Kron25 são grafos sintéticos de autoria do
Intel Performance Counter Monitor3 .
grupo Graph Challenge com escalas de 24 e 25 res-
pectivamente. Google+ e Twitter são redes sociais reais.
B. Métricas e Casos
Pld e Sd1 são grafos maiores, extraídos entre 2012 e
Comparou-se a performance do algoritmo contendo 2014 pelo Common Crawl, contendo mais de 3,5 bilhões
todas as otimizações contra a sua versão com apenas de páginas links e 128 bilhões de hyperlinks entre as
otimizações de multithreading e contra a sua versão sem páginas, representando um recorte real da web.
otimizações. As versões com multithreading utilizam 16
núcleos, de acordo com o processador que se utilizou
E. Resultados
nos testes.
299
300
C. Representação do Grafo
240
Os grafos utilizam os formato CSR e COO [15]. O
formato CSR contém 2 estruturas do tipo array, uma de 200
vértice e uma de arestas. Elementos da array de vértices
consistem num índice em offset para a array de arestas, 99 100
representando a posição da primeira aresta do vértice. 100 74 76
50 37
Arrays de arestas contém índices da origem de todos os 35
13 9 10 9 7 22 13
8 7
vértices, numa lista ordenada por destino. Arrays adici- 0
onais como atributos e pesos podem ser utilizadas para Sd1 Pld Kron25 Kron24 G+ Twitter
armazenar atributos dos vértices e pesos das arestas. O
Sem Otimizações Multithreading Todas
formato COO contém um grafo armazenado como uma
lista de vértices e arestas onde cada vértice consiste num Figura 4: Resultado 1: Tempo de Execução (segundos).
ID e seu atributo específico, como um valor PageRank.
Cada arestas é definida por sua origem, destino e peso. 1) Tempo de Execução: A figura 4 ilustra a comparação
As mensagens são definidas pelo vértice de destino e de performance entre as diferentes versões do algoritmo.
pela atualização do atributo do vértice. A versão otimizada supera de forma consistente ambas
as versões menos otimizadas. A termos de tempo de
D. Conjuntos de Dados execução, a melhora é de 12× a 19× desta versão
Foram utilizados tanto conjuntos de dados do mundo em comparação às outras. A versão Multithread tem
real quanto sintéticos para avaliar a performance. O uma melhora de 1.4× a 2x no tempo de execução.
tamanho dos grafos varia de 16 milhões de vértices a 97 A melhoria no tempo de execução pode ser explicada
milhões de vértices e 536 milhões de de arestas a 1963 por duas razões: (1) partições são acessadas de uma
2 https://cloud.google.com/compute/docs/cpu-platforms
maneira normalizada, com acessos a vértices e arestas
3 https://software.intel.com/en-us/articles/intel-performance- de cada partição acontecendo de forma sequencial e (2)
counter-monitor o ajuste na disposição dos dados reduz o número de
UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA 5

acessos aleatórios ao escrever as mensagens na memória ·1012

durante a fase de scatter. Então, em comparação com
o método sem otimizações, a versão otimizada reduz 1.5
acessos aleatórios e tende a sustentar a largura de banda
por mais tempo, diminuindo o tempo de execução. 1

23 24 0.5
20
16 17
0
Sd1 Pld Kron25 Kron24 G+ Twitter

10 9
7 8 6 7 7 Sem Otimizações Multithreading Todas
3 2 3 3 1 2 Figura 7: Resultado 4: Total de Acessos à Memória.
1 1
0
Sd1 Pld Kron25 Kron24 G+ Twitter ·1012

Sem Otimizações Multithreading Todas 1.5

Figura 5: Resultado 2: Taxa de Cache Miss L3.

1

40 37 37 0.5

30
23 23
20
12 12
11 10
10
4 Figura 8: Resultado 5: Total de Leituras à Memória.
2 3
1 1
0
Sd1 Pld Kron25 Kron24
Sem Otimizações Multithreading
Figura 6: Resultado 3: Taxa de Cache Miss L2.
2) Cache Miss: A mesma comparação é feita para
acessos a cache. Um número alto de acessos a cache
representa um número alto de acessos a memória, le-
vando a um aumento no tempo de execução. Conforme
ilustrado na figura 5, a versão com todas as otimizações
ativadas reduz o número total de misses L3 de 9× a 19×
em comparação com as abordagens menos otimizadas. A
performance da versão com multithreading é semelhante
em termos de número de cache miss. O alto número
de cache misses da versão sem otimizações pode ser
atribuído à natureza de acessos do PageRank. O ajuste
de disposição dos dados proporciona que arestas sejam
lidas e escritas de forma mais rápida, pois ao processar
27 27
0
Sd1 Pld Kron25 Kron24 G+ Twitter
Sem Otimizações Multithreading Todas
7 7
1
G+ Twitter
uma partição, os acessos aleatórios são limitados pelos
dados de vértices armazenados em cache.
Todas
Uma análise semelhante foi feita para caches L2. Como
ilustrado na figura 6, a versão otimizada reduz o número
de misses L2, e a versão multithread tem um resultado
semelhante.
3) Acessos à Memória: O número total de acessos a
memória tem um impacto significativo no tempo de
execução. A figura 7 compara o número total de acessos
a memória entre as versões testadas do PageRank. É
notável que o algoritmo otimizado reduz o número total
de acessos a memória em 1, 5× em comparação com
as outras duas versões. Este é o fato mais importante
para determinar o tempo de execução para aplicações
baseadas em grafo uma vez que o tempo de acesso a
memória domina o tempo de computação em si.
A figura 8 compara o número total de leituras à memó-
ria. O algoritmo totalmente otimizado reduz o número
UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA
·1011
1
0
Sd1 Pld Kron25 Kron24 G+ Twitter
Sem Otimizações Multithreading Todas
Figura 9: Resultado 6: Total de Escritas à Memória.
de leituras de memória em até 2×. Isto ocorre devido ao
fato de haver um número maior de leituras aleatórias nas
outras duas versões, resultando em menor utilização de
cache. No entanto, para o algoritmo otimizado, a cache
é utilizada completamente quando é feito o acesso a
memória.
As estatísticas de escrita são dadas pela figura 9 O
número total de escritas à memória no algoritmo com
todas as otimizações é 5× maior que o do algoritmo mais
básico. No algoritmo sem otimizações, o número total de
escritas de vértices é dado por O(|V |), pois cada vértice
é atualizado a cada iteração. Na versão otimizada, as
atualizações são escritas para cada arestas e recolhidas
(gather) posteriormente num vértice, ocorrendo então
O(| E|) escritas à memória. No entanto, como o número
total de leituras é muito maior que o de escritas, o algo-
ritmo otimizado reduz o número de acessos à memória
ao reduzir o número de leituras.
4) Impacto do Tamanho da Partição: Na versão otimizada
do algoritmo, o grafo foi dividido em várias partições.
Cada uma possui um conjunto de vértices de tamanho
determinado pelo tamanho da cache do processador.
Quanto menor o tamanho do conjunto de vértices, maior
o número de partições do grafo.
A figura 10 ilustra o efeito de diferentes tamanhos
de conjuntos de vértices no tempo total de execução do
algoritmo otimizado. O tamanho do conjunto de vértices
foi configurado para 64K, 128K e 256K. Observou-se que
o tempo total de execução diminui para 128K e aumenta
em função do tamanho do conjunto de vértices, pois
o número de partições e reduzido e acessos aleatórios
durante a fase scatter são reduzidos. No entanto, se
o tamanho do conjunto do vértice é muito grande, a
6
20
10
0
Sd1 Pld Kron25 Kron24 G+ Twitter
64K 128K 256K
Figura 10: Resultado 7: Tempo de execução (s) para
diferentes tamanho do Conjunto de Vértices.
atividade de um núcleo durante a fase gather é alta e
se torna difícil balancear todas as atividades entre os
diversos núcleos do processador. Outro problema ocorre
devido a cache L1/L2 não conseguir armazenar um con-
junto, provocando maior número de acessos aleatórios à
memória principal durante a fase gather.
VII. C ONCLUSÃO
Neste trabalho, técnicas de implementação paralelas,
ajuste de disposição de dados e particionamento do al-
goritmo PageRank foram colocadas a prova e discutidas.
O grafo de entrada foi particionado e diferentes núcleos
do processador executaram computações de partições
distintas em paralelo. Resultados experimentais mos-
traram que as melhorias selecionadas e implementadas
ofereceram ganho de velocidade de 12× a 9×.
Lidar com estruturas com dados dispostos de maneira
aleatórias e portanto pouco ideais para processamento
proporciona enxergar o impacto que pequenas otimi-
zações a nível estrutural e ajustadas à características
de baixo nível podem trazer para um programa. Em
suma, este trabalho demonstra que, dada o fato que
a arquitetura de um computador é fixa, em diversas
situações isto exigirá do desenvolvedor uma atenção
que vai além de simples técnicas de programação e
engenharia de software, ocorrendo além do nível lógico
de implementação e de forma externas ao código.
UNIVERSIDADE FEDERAL DA PARAÍBA - PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA 7

R EFERÊNCIAS [17] O. Lehmberg, R. Meusel, and C. Bizer, “Graph structure in the

web: aggregated by pay-level domain,” in Proceedings of the 2014
ACM conference on Web science, pp. 119–128, ACM, 2014.
[1] “Graph 500 reference implementations.” [18] J. Kunegis, “Konect: the koblenz network collection,” in Proce-
[2] S. Samsi, V. Gadepally, M. Hurley, M. Jones, E. Kao, S. Mohindra, edings of the 22nd International Conference on World Wide Web,
P. Monticciolo, A. Reuther, S. Smith, W. Song, et al., “Static graph pp. 1343–1350, ACM, 2013.
challenge: Subgraph isomorphism,” in 2017 IEEE High Performance [19] S. Zhou, C. Chelmis, and V. K. Prasanna, “Accelerating large-scale
Extreme Computing Conference (HPEC), pp. 1–6, IEEE, 2017. single-source shortest path on fpga,” in 2015 IEEE International
[3] E. Kao, V. Gadepally, M. Hurley, M. Jones, J. Kepner, S. Mohindra, Parallel and Distributed Processing Symposium Workshop, pp. 129–
P. Monticciolo, A. Reuther, S. Samsi, W. Song, et al., “Streaming 136, IEEE, 2015.
graph challenge: Stochastic block partition,” in 2017 IEEE High [20] Y. Jia, V. Lu, J. Hoberock, M. Garland, and J. C. Hart, “Edge v.
Performance Extreme Computing Conference (HPEC), pp. 1–12, IEEE, node parallelism for graph centrality metrics,” in GPU Computing
2017. Gems Jade Edition, pp. 15–28, Elsevier, 2012.
[4] A. Roy, I. Mihailovic, and W. Zwaenepoel, “X-stream: Edge- [21] D. F. Gleich, “Pagerank beyond the web,” SIAM Review, vol. 57,
centric graph processing using streaming partitions,” in Procee- no. 3, pp. 321–363, 2015.
dings of the Twenty-Fourth ACM Symposium on Operating Systems
Principles, pp. 472–488, ACM, 2013.
[5] H. Wei, J. X. Yu, C. Lu, and X. Lin, “Speedup graph processing by
graph ordering,” in Proceedings of the 2016 International Conference
on Management of Data, pp. 1813–1828, ACM, 2016.
[6] S. Beamer, K. Asanović, and D. Patterson, “Reducing pagerank
communication via propagation blocking,” in 2017 IEEE Inter-
national Parallel and Distributed Processing Symposium (IPDPS),
pp. 820–831, IEEE, 2017.
[7] L. Page, S. Brin, R. Motwani, and T. Winograd, “The pagerank
citation ranking: Bringing order to the web.,” tech. rep., Stanford
InfoLab, 1999.
[8] M. T. Pilehvar, D. Jurgens, and R. Navigli, “Align, disambiguate
and walk: A unified approach for measuring semantic similarity,”
in Proceedings of the 51st Annual Meeting of the Association for
Computational Linguistics (Volume 1: Long Papers), vol. 1, pp. 1341–
1351, 2013.
[9] R. Navigli and M. Lapata, “An experimental study of graph
connectivity for unsupervised word sense disambiguation,” IEEE
transactions on pattern analysis and machine intelligence, vol. 32,
no. 4, pp. 678–692, 2009.
[10] M. Gori and A. Pucci, “Research paper recommender systems:
A random-walk based approach,” in 2006 IEEE/WIC/ACM Inter-
national Conference on Web Intelligence (WI 2006 Main Conference
Proceedings)(WI’06), pp. 778–781, IEEE, 2006.
[11] J. Bollen, M. A. Rodriguez, and H. Van de Sompel, “Mesur:
usage-based metrics of scholarly impact,” tech. rep., Los Alamos
National Lab.(LANL), Los Alamos, NM (United States), 2007.
[12] S. Zhou, C. Chelmis, and V. K. Prasanna, “High-throughput
and energy-efficient graph processing on fpga,” in 2016 IEEE
24th Annual International Symposium on Field-Programmable Custom
Computing Machines (FCCM), pp. 103–110, IEEE, 2016.
[13] S. Zhou, K. Lakhotia, S. G. Singapura, H. Zeng, R. Kannan, V. K.
Prasanna, J. Fox, E. Kim, O. Green, and D. A. Bader, “Design and
implementation of parallel pagerank on multicore platforms,” in
2017 IEEE High Performance Extreme Computing Conference (HPEC),
pp. 1–6, IEEE, 2017.
[14] S. Zhou, C. Chelmis, and V. K. Prasanna, “Optimizing memory
performance for fpga implementation of pagerank,” in 2015
International Conference on ReConFigurable Computing and FPGAs
(ReConFig), pp. 1–6, IEEE, 2015.
[15] J. Riedy, “Updating pagerank for streaming graphs,” in 2016
IEEE International Parallel and Distributed Processing Symposium
Workshops (IPDPSW), pp. 877–884, IEEE, 2016.
[16] N. Z. Gong, W. Xu, L. Huang, P. Mittal, E. Stefanov, V. Sekar, and
D. Song, “Evolution of social-attribute networks: measurements,
modeling, and implications using google+,” in Proceedings of the
2012 Internet Measurement Conference, pp. 131–144, ACM, 2012.