[Pereira, IC'2013] Uma nova abordagem para detecção e extracao de paralelismo em programas Java

“Uma nova abordagem para
detecção e extração de
paralelismo em programas Java”
1
paralelismo em programas Java”
Marcio Machado Pereira

Estrutura
Introdução
Motivação
Linhas de Pesquisa
2
Linhas de Pesquisa
Trabalhos Relacionados
Conclusões “The greatest ideas are
(literally) worthless if
you keep them to
yourself”

Introdução
A extração de paralelismo para algumas classes de
aplicações single-threaded tornou-se um problema
altamente relevante para a computação moderna. e. g.:
o Processamento de Imagens, Multimídia
3
o Processamento de Imagens, Multimídia
Abordagens baseadas no Modelo de Programação
o MPI, OpenMP, TM, HPF, X10, ...
Paralelização automática ou semi-automática
o Baseada em compilador
o Compilação Dinâmica

Paralelização baseada em Compilador
Técnicas de Paralelização
o DOALL, DOACROSS, DSWP, PS-DSWP, ...
A incapacidade destas técnicas de, até agora,
4
Técnicas Especulativas
o Spec-DSWP, DSWP+, ...
A incapacidade destas técnicas de, até agora,
proporcionar um bom desempenho em uma
ampla gama de aplicações é um dos principais
problemas para que a paralelização
automática possa ser amplamente adotada.

Compilação Dinâmica
A compilação dinâmica tem algumas desvantagens em relação
à compilação estática tradicional, mais especificamente, a
sobrecarga incorrida através da realização da compilação em
tempo de execução pode ser substancial.
A compilação dinâmica tem algumas desvantagens em relação
à compilação estática tradicional, mais especificamente, a
sobrecarga incorrida através da realização da compilação em
tempo de execução pode ser substancial.
Otimização Seletiva
5
Otimização Seletiva
o aplicação de otimização apenas nas partes
críticas do aplicativo
Otimização dirigida por feedback
o capacidade de adaptar as otimizações ao
ambiente de execução atual

Otimizações dirigidas por feedback
Otimizações automáticas guiadas por profile:
Em contraste com as técnicas de otimização tradicionais,
que apenas usam o código-fonte, otimizações dirigidas por
feedback utilizam-se dos resultados de ensaios do programa
instrumentado (profile) para otimizar o código final gerado.
Em contraste com as técnicas de otimização tradicionais,
que apenas usam o código-fonte, otimizações dirigidas por
feedback utilizam-se dos resultados de ensaios do programa
instrumentado (profile) para otimizar o código final gerado.
6
Otimizações automáticas guiadas por profile:
o Coletados offline
Aplicação pode não se comportar similar ao treino
o Coletados online
sobrecarga de coleta de dados instrumentados pode ser
um problema.

Motivação [1]
O obstáculo chave na paralelização de aplicações são as
dependências existentes entre as instruções do programa.
Considere o exemplo abaixo:
7
1 int cost = 0;
2 node = list.head;
3 while (node != null) {
4 int ncost = visit (node);
5 cost += ncost;
6 node = node.getNext();
7 }
3
5
4
6
(a) laço com dependências loop-carried (b) PDG

Motivação [2]
Latência de 2
instruções
8
Cada thread
executa uma
parte do
corpo do laço

Motivação [3]
No exemplo abaixo, todas as instruções do laço participam
de uma única dependência cíclica (uma única SCC no grafo
de dependências). Em função disto, o grafo não pode ser
particionado.
não ocorre com
frequência
9
1 int cost = 0;
2 node = list.head;
3 while (cost < threshold && node != null) {
4 int ncost = visit (node);
5 cost += ncost;
6 node = node.getNext();
7 }
3
6
4
5
(a) laço com dependências loop-carried (b) PDG
frequência

Motivação [4]
O aumento do paralelismo é determinado
pelo número (e “custo”) das SCCs no PDG
de um laço!
10
Identificado os laços “quentes” do programa,
definimos um Plano de Ataque:
o Especular a remoção de arestas de dependências de
maneira a aumentar o número de SCCs.
o Encapsular e executar as SCCs (partes do corpo do
laço ou chunks) na forma de “transações”

Linhas de Pesquisa
Três questões são então levantadas:
o Como garantir a semântica do programa ?
o Como determinar quais dependências podem ser
especuladas? e;
11
especuladas? e;
o Como manter a corretude do programa na presença
de “falhas de especulação” ?
Para endereçar estas questões definimos duas
linhas de pesquisa:
o “Paralelização com suporte de STM”
o “Seleção e Especulação de Arestas Críticas”

Paralelização com suporte de STM[1]
Lembrando que nosso objetivo é a paralelização de laços:
o Nossa proposta modifica o algoritmo DSWP fazendo
com que as partes do corpo do laço que serão
executadas em diferentes cores, sejam encapsuladas
e executadas na forma de transações
12
e executadas na forma de transações
Considere o exemplo:
node = list.head;
A: while (node != null) {
B: index = calc (node.data, arr[ ]);
C: density[index] = update_density (density[index], node.data);
D: node = node.next;
}

Paralelização com suporte de STM[2]
Similar ao DSWP, construímos o Grafo de Dependências
(PDG) e identificamos as Componentes Fortemente
Conexas (SCCs):
Tempo de
execução
13
12,5%
50%
37,5%

Exemplo Paralelizado com DSWP
DSWP aloca cada SCC a uma thread e insere as operações
“produce/consume” para transmitir dados e controle:
node = list.head;
while (node != null) {
produce (queue[1][2], node);
while (true) {
node = consume (queue[1][3]);
if (!node) break;
index = consume (queue[2][3]);
14
o Com isso, o desempenho do
laço é limitado pela SCC
mais lenta: SCCB (1 /50% = 2x)
SCCAD
node = node.next;
}
SCCB
while (true) {
node = consume (queue[1][2]);
if (!node) break;
index = calc (node.data, arr[]);
produce (queue[2][3], index);
}
SCCC
index = consume (queue[2][3]);
density[index] = update_density
(density[index], node.data);
}

Heuristica com STM[1]
Diferentemente de DSWP, cada SCC define um chunk do
corpo do laço, que por sua vez é encapsulado em uma
transação.
Para garantir a semântica do programa sequencial,
assumimos um modelo de transações ordenadas:
15
Para garantir a semântica do programa sequencial,
assumimos um modelo de transações ordenadas:
o Um identificador (ID) crescente é atribuído a cada
transação, definindo o pipeline de execução.
o Os chunks são forçados a realizar o “commit” em
ordem para manter a execução correta e ainda
permitir a recuperação parcial do laço.

Exemplo Paralelizado com STM [1]
int id = 1;
try {
while (node != null) {
new taskB (id+1, node);
node = node.next;
id += 3; }
void run (id, node) {
try { stm.begin ( );
index = calc (node.data, arr[ ]);
new taskC (id+1,node, index);
} catch (stmException e) { }
finally {
SCCAD==taskA SCCB == taskB:
16
id += 3; }
finally {
stm.commit(id); }
}
void run (id, node, index) {
try { stm.begin( );
density[index] = update_density
(density[index], node.data);
finally {
stm.commit(id); }
}
o Na nossa proposta, o
desempenho do laço é
limitado somente pela
SCCAB: (1 /12,5% = 8x)
SCCC == taskC:

taskA
taskB taskC
Exemplo Paralelizado com STM [2]
Iteração
1
tempo
Id=1 Id=2 Id=3
4
7
5
8
6
9
17
1
2
3
4
7
10
8
11
9
12
12,5% 50% 37,5%
8 “worker”
threads

Heuristica com STM[2]
o No caso de um conflito, a transação com o maior ID
é selecionada para ser abortada, podendo ser re-
escalonada.
o No caso de “falhas de especulação”, as transações
com ID maior que a transação corrente são
18
com ID maior que a transação corrente são
selecionadas para serem abortadas.
Esta decisões são baseadas no fato de que laços “while”,
e laços “for” com desvios condicionais, ocorrem com mais
frequência em aplicações de propósito geral:
o a execução de cada iteração do laço depende do
resultado dos branchs de saída nas iterações
anteriores.

Planejamento Experimental
O ganho de desempenho é limitado pela SCC crítica. Isto
posto, o planejamento experimental tem como objetivo
determinar o “upper bond” esperado com a aplicação desta
heurística nos benchmarks de mercado (dacapo, specjvm)
Utilizando a máquina Virtual Jikes-RVM devemos:
19
Utilizando a máquina Virtual Jikes-RVM devemos:
o Identificar os laços ”quentes” e medir a % média do
tempo de execução (p1) dos mesmos em relação ao
tempo da aplicação (T)
o Determinar a % média do tempo de execução (p2) das
SCCs críticas nestes mesmos laços
o speedup: T / (T * (1 – p1 + p2))

Seleção de Arestas Críticas[1]
Nosso objetivo nesta linha de pesquisa é usar o
“Instrumentation Sampling Framework – ISF” e o
“Adaptive Optimization System – AOS”, presentes na
máquina Virtual Jikes-RVM para prover,
respectivamente, um Profile eficiente e um contexto
20
respectivamente, um Profile eficiente e um contexto
para a implementação dos “mecanismos de especulação”,
e.g.:
o Biased Branch Speculation
o Infrequent Basic Block Speculation
o Alias Speculation

21

Instrumentar todas
as arestas cujas
dependências são
fortes candidatas
para especulação
Inferir se as
mesmas tem sua
frequência de
execução baixa
(<= threshold)
22
fortes candidatas
para especulação
execução baixa
(<= threshold)ISF
Especular as
de especulação
Especular as
dependências
selecionadas e inserir
código para
tratamento das falhas
de especulação
AOS

Mecanismos de especulação[1]
Biased branch
speculation
23
Infrequent
Basic Block
speculation

Mecanismos de especulação[2]
Alias Speculation
o Uma analise de Alias indica que dependências de
memória podem ocorrer, mesmo que tais dependências
se manifestem raramente na prática. Porém, com o uso
24
se manifestem raramente na prática. Porém, com o uso
de instrumentação adequada no código, com o suporte
dos frameworks ISF e AOS, podemos estimar a
frequência com que um Alias ocorre. Isto posto, o
“controle de especulação” poderá instruir o compilador
a remover esta aresta do grafo de dependências,
aumentando potencialmente assim o número de SCCs
e, consequentemente, o nível de paralelização.

Exemplo com especulação[1]
ListNode findNode (Pair dataPtr) {
ListNode nodePtr = head;
A: for (; nodePtr != null; nodePtr = nodePtr.nextPtr) {
B: if (nodePtr.dataPtr.firstPtr.compareTo(dataPtr.firstPtr) >= 0) {
C: return nodePtr; }
D: }
25
D: }
return null;
}
Este ramo será
executado uma
única vez SCCAD
SCCBC
Tempo de
execução
20%
80%

ListNode findNode (Pair dataPtr) {
ListNode nodePtr = head; int id = 1;
try {
for (; nodePtr != null; nodePtr = nodePtr.nextPtr)
new taskB (id+1, nodePtr, dataPtr); id += 2;
}
catch (stmAbort e) {
stm.abortAll( ); nodePtr = fndPtr; }
static ListNode
fndPtr = null;
“Fila de
taskA:
26
void run (int id, ListNode nodePtr, Pair dataPtr) throws stm.abort {
bool isFound = false;
try { stm.begin( );
if (nodePtr.dataPtr.firstPtr.compareTo(dataPtr.firstPtr) >= 0)
{ isFound = true; fndPtr = nodePtr; }
}
catch (stmException e) { }
finally { stm.commit(id); if (isFound) throw new stmAbort( ); }
}
stm.abortAll( ); nodePtr = fndPtr; }
finally { return nodePtr; }
}
“Fila de
comunicação”
taskB:

taskA
taskB
Iteração
1
tempo
Id=1 Id=2
3
5
4
6
speedup
potencial = 5x
27
1
2
3
4
7
6
8
20% 80%
5 “worker”
threads
“send”
stmAbortAll()
isFound=true

Trabalhos relacionados (DSWP)
N. Vachharajani, R. Rangan, E. Raman, M. J. Bridges, G. Ottoni, and D. I.
August. Speculative decoupled software pipelining. In Proceedings of
the 16th International Conference on Parallel Architectures and Compilation
G. Ottoni, R. Rangan, A. Stoler, and D. I. August. Automatic thread
extraction with decoupled software pipelining. In Proceedings of the
38th IEEE/ACM International Symposium on Microarchitecture (MICRO '05).
28
the 16th International Conference on Parallel Architectures and Compilation
Techniques (PACT '07).
E. Raman, G. Ottoni, A. Raman. M. J. Bridges, D. I. August. Parallel-Stage
Decoupled Software Pipelining. In Proceedings of the 6th annual
international symposium on Code generation and optimization (CGO '08).
Jialu Huang, Arun Raman, Thomas B. Jablin, Yun Zhang, Tzu-Han Hung, and
David I. August. 2010. Decoupled software pipelining creates
parallelization opportunities. In Proceedings of the 8th annual
international symposium on Code generation and optimization (CGO '10).

Trabalhos relacionados (ISF/AOS)
Matthew Arnold, Stephen Fink, David Grove, Michael Hind, and Peter F.
Sweeney. Adaptive optimization in the Jalapeño JVM. In ACM
Conference on Object-Oriented Programming Systems, Languages, and
Applications (OOPSLA '00).
Matthew Arnold, Michael Hind, and Barbara G. Ryder. An empirical study of
29
Matthew Arnold, Michael Hind, and Barbara Ryder. Online feedback-
directed optimization of Java. In ACM Conference on Object Oriented
Programming, Systems, Languages and Applications (OOPSLA '02).
Matthew Arnold, Michael Hind, and Barbara G. Ryder. An empirical study of
selective optimization. In 13th International Workshop on Languages and
Compilers for Parallel Computing (LCPC '00).
Matthew Arnold, and Barbara Ryder. A framework for reducing the cost
of instrumented code. In Conference on Programming Language Design
and Implementation (PLDI '01).

Trabalhos relacionados (STM)
M. Mehrara, J. Hao, P.-C. Hsu, and S. Mahlke. Parallelizing sequential
B. Carlstrom, J. Chung, H. Chafi, A. McDonald, C. Minh, L. Hammond, C.
Kozyrakis, and K. Olukotun. Executing java programs with transactional
memory. Science of Computer Programming, 63(2):111–129, 2006.
30
M. Mehrara, J. Hao, P.-C. Hsu, and S. Mahlke. Parallelizing sequential
applications on commodity hardware using a low-cost software
transactional memory. In Proceedings of the conference on Programming
language design and implementation (PLDI ’09).
A. Raman, H. Kim, T. R. Mason, T. B. Jablin, and D. I. August. Speculative
parallelization using software multi-threaded transactions. In
Proceedings of the fifteenth Architectural support for programming
languages and operating systems (ASPLOS ’10).

Trabalhos relacionados (Outros)
J.-S. Yur, B. G. Ryder, and W. Landi. An incremental flow and context-
sensitive pointer aliasing analysis. In Twenty-first International
Conference on Software Engineering (ICSE ’99).
Chandra Krintz, and Brad Calder. Using Annotations to Reduce Dynamic
Optimization Time. In Conference on Programming Language Design and
31
Optimization Time. In Conference on Programming Language Design and
Implementation (PLDI ’01).

Conclusão
Este trabalho apresentou uma nova abordagem para
detecção e extração de paralelismo em programas Java.
o O mesmo teve por base outros trabalhos na área que compartilham
uma solidez, fruto de vários anos de pesquisa e conhecimento.
A abordagem endereça o aumento na exploração do
32
A abordagem endereça o aumento na exploração do
paralelismo de código de forma automatizada.
o decisões de projeto podem se mostrar equivocadas, o que não é de
todo improvável em um trabalho de tal extensão e escopo.
o se os equívocos forem sustados e se ao menos algumas das
avaliações e conclusões se mostrarem promissoras, teremos
atingido nosso objetivo.
Marcio Machado Pereira

[Pereira, IC'2013] Uma nova abordagem para detecção e extracao de paralelismo em programas Java

Mais conteúdo relacionado

Semelhante a [Pereira, IC'2013] Uma nova abordagem para detecção e extracao de paralelismo em programas Java (20)

Último (16)

[Pereira, IC'2013] Uma nova abordagem para detecção e extracao de paralelismo em programas Java