Esqueletos Algorítmicos para Paralelismo de Tarefas em Sistemas Multi-GPU

Tamanho: px
Começar a partir da página:

Download "Esqueletos Algorítmicos para Paralelismo de Tarefas em Sistemas Multi-GPU"

Transcrição

1 Esqueletos Algorítmicos para Paralelismo de Tarefas em Sistemas Multi-GPU Fernando Alexandre, Ricardo Marques, and Hervé Paulino CITI / Departamento de Informática Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa Caparica, Portugal Resumo A crescente utilização de Unidades de Processamento Gráfico (GPUs) na computação de caráter geral levanta questões de desempenho e de escalabilidade. Para responder a estes requisitos de forma efetiva, cada vez mais se recorre à utilização colaborativa de vários GPUs num só sistema. Esta abordagem introduz, no entanto, novos desafios, tal como a decomposição do domínio do problema e a gestão da possível heterogeneidade dos dispositivos. Neste contexto assume particular relevância a proposta de abstrações que escondam a complexidade da programação destes sistemas. Existe já algum trabalho na área, mas este restringese ao paralelismo de dados. Por conseguinte, neste artigo abordamos a utilização de uma biblioteca de esqueletos algorítmicos, Marrow, para a exploração de paralelismo de tarefas em sistemas computacionais com estas características. Os resultados são promissores, apresentado a escalabilidade esperada nos sistemas testados. 1 Introdução O GPU tem, cada vez mais, assumido um papel de relevo na resolução de problemas que possam beneficiar de paralelismo centrado nos dados, exemplos são o processamento numérico, a prospeção de dados (data-mining), simulações físicas, entre outros [1]. Com a crescente popularidade deste paradigma surgiu a necessidade de lidar com questões de escala e melhorar o desempenho, em termos de tempos de resposta e de quantidade de trabalho efetuado por unidade de tempo. Por conseguinte, emergiu recentemente uma nova tendência que recorre à utilização colaborativa de múltiplos GPUs dentro de uma só máquina [2, 3]. As plataformas base para computação de caráter geral em GPUs - GPGPU (General Programming on Graphics Processing Units) - OpenCL [4] e CUDA [5] oferecem algum suporte para computação em múltiplos dispositivos. No entanto, o nível de abstração é bastante baixo; o nível de conhecimentos de programação paralela exigido no contexto de um único dispositivo são subsequentemente amplificados. Além da gestão explícita dos espaços de memória e a orquestração Este trabalho foi parcialmente financiado pela FCT-MCTES através do PEst- OE/EEI/UI0527/ Centro de Investigação em Informática e Tecnologias e utilizou equipamento adquirido no âmbito dos projectos PTDC/EIA-EIA/102579/2008 e PTDC/EIA-EIA/111518/2009.

2 das operações que devem ser executadas pelos dispositivos, o programador deve agora também assumir a responsabilidade de decompor a computação pelos diversos GPUs, possivelmente heterogéneos, e considerar detalhes arquiteturais, como a eventual partilha de barramentos (bus) pelos mesmos. Neste contexto torna-se imperativo a proposta de abstrações que, por um lado, escondam a complexidade da programação destes sistemas computacionais, e por outro, sejam úteis na resolução de problemas que beneficiem de execução com múltiplos GPUs. Esta área tem recebido particular atenção, com várias propostas a endereçar o paralelismo de dados [6, 7], que mapeia naturalmente no modelo de execução subjacente. No que se refere à exploração do paralelismo de tarefas, a área é muito recente e com muitos desafios por endereçar, particularmente no contexto multi-gpu. Que seja do nosso conhecimento, para além da biblioteca Marrow [8] que será a base deste trabalho, apenas é suportado o encadeamento de tarefas, pipelining, sem suporte multi-gpu em [9] ou restrito a um dado domínio, como o processamento de streams em [10, 11]. O Marrow é uma biblioteca de esqueletos algorítmicos para a orquestração de computações OpenCL. Destaca-se das restantes disponíveis para GPGPU [6,7,12 14] por ser a primeira a suportar esqueletos para paralelismo de tarefas e propor o aninhamento destes mesmos esqueletos como ferramenta para a criação de árvores de computação de complexidade arbitrária. Nesta medida, o objetivo deste trabalho é permitir que computações Marrow possam executar em vários GPUs num só nó computational, com particular ênfase no paralelismo de tarefas. Pretende-se utilizar esqueletos algorítmicos para usufruir da capacidade de abstração da complexidade inerente às computações paralelas, delegando ao sistema de execução a decomposição da computação, a adaptação de acordo com a heterogeneidade dos dispositivos e endereçar possíveis otimizações nas transferências de dados entre os múltiplos espaços de memória. As contribuições deste trabalho são portanto: 1 - a proposta de esqueletos para paralelismo de tarefas em sistemas multi-gpu, tirando partido do aninhamento de esqueletos para o cálculo de computações complexas (Secção 3); 2 - um sistema de execução capaz de distribuir a computação de uma tarefa por múltiplos dispositivos, possivelmente heterogéneos (Secção 4); 3 - uma avaliação comparativa do desempenho dos esqueletos propostos relativamente à execução num único GPU (Secção 5). 2 Biblioteca de Esqueletos Algorítmicos Marrow Marrow é uma biblioteca de esqueletos algorítmicos com o objetivo de orquestrar computações OpenCL em vários GPUs. Para criar computações complexas, o Marrow suporta aninhamento de esqueletos algorítmicos, sendo que este pode ser representado através de uma árvore onde os nós intermédios introduzem comportamentos sobre a sua sub-árvore até chegar às folhas, que contém as computações OpenCL (kernels). Os esqueletos algorítmicos escolhidos para in-

3 Pipeline Pipeline Pipeline Estágio 1 Estágio 2 Estágio 4 Estágio 5 Figura 1. Aninhamento de pipelines. clusão na biblioteca têm em conta a sua utilidade na área de GPGPU, sendo que os seguintes são suportados: Pipeline define uma sequência de computações dependentes pelos dados, em que os dados de saída resultantes de um estágio são passados para a entrada da computação seguinte. Os dados intermédios entre dois estágios são mantidos no respetivo GPU de forma a evitar transferências de dados desnecessárias e caras. Uma instância deste esqueleto suporta apenas dois estágios. É no entanto possível utilizar aninhamento para criar estruturas com um número arbitrário de estágios, como apresentado na Figura 1. Loop permite a execução iterativa de uma computação de acordo com uma condição de paragem definida pelo programador. O esqueleto permite modelar os comportamentos dos esqueletos For e While [15] que diferem pelo facto que a condição de paragem pode depender dos dados intermédios da iteração corrente (While) ou não (For). Ambas as variantes do esqueleto suportam aninhamento. Map permite aplicar uma árvore de computação em paralelo a um conjunto de dados. MapReduce é uma extensão do Map que permite que um passo posterior de redução seja este executado no GPU, utilizando internamente um Pipeline, ou no CPU. Nenhum destes esqueletos permitem aninhamento pois precisam de deter controlo sobre os dados residentes na memória do host para iniciar a execução e transferências de dados. Exemplo de Programação A Listagem 1 apresenta a um exemplo que faz uso de um Pipeline com dois estágios de computação, sendo o primeiro um FFT (Fast Fourier Transformation) e o segundo, o seu inverso. A árvore de computação é construída de baixo para cima, iniciando-se com a criação das folhas, instâncias de KernelWrappers que representam as computações em si (kernels, linha 2), seguindo-se o aninhamento incremental nos esqueletos desejados (linha 3 4). Uma vez criada, a arvore de computação pode receber múltiplos pedidos de execução. Estes recebem como argumento o conjunto de dados (composto por escalares e/ou vetores) sobre o qual a árvore vai ser aplicada. Vetores em Marrow são instâncias da classe Vector, que abstrai as operações de decomposição necessárias para a execução multi-gpu (linhas 6 9). A função de submissão (linha 11) devolve imediatamente a referência ao objeto Future que permite à aplicação esperar pelo fim da execução da árvore, tal como acesso aos dados resultantes.

4 1 // Computation Tree Allocation 2 std :: unique_ptr < IExecutable > fft ( new KernelWrapper( kernelfile, " fft1d_512 ", ininfo, outinfo, globalworksize )); 3 std :: unique_ptr < IExecutable > ifft ( new KernelWrapper( kernelfile, " ifft1d_512 ", ininfo, outinfo, globalworksize )); 4 std :: unique_ptr < IExecutable > pipe ( new Pipeline (fft, ifft )); 5 // Request skeleton executions ; Vector Creation 6 std :: vector <std :: shared_ptr <Vector >> inputvectors (1) ; 7 inputdata [0] = std :: shared_ptr <Vector >( new Vector ( input, sizeof ( cl_float2 ), size )); 8 std :: vector <std :: shared_ptr <Vector >> outputvectors (1) ; 9 outputdata [0] = std :: shared_ptr <Vector >( new Vector ( output, sizeof ( cl_float2 ), size )); 10 // Execution Requests 11 future = pipe -> write ( inputvectors, outputvectors ); 12 // Wait for results ; Computation tree de - allocation : delete pipe Listing 1. Pipeline de FFTs e a sua operação inversa 3 Orquestração do Loop e Pipeline Nesta secção é descrita a orquestração necessária para a implementação dos esqueletos para paralelismo de tarefas presentes no Marrow, nomeadamente Loop e Pipeline, seguido de considerações relacionadas ao aninhamento de esqueletos. Condição Step (2) (4) Loop GPUs (5) Input (1) Computação (3) Output (6) Sistema de Execução Figura 2. Orquestração do Loop GPUs Input Stage1 Middle Stage2 Output Pipeline (1) (2) Sistema de Execução (3) (4) Figura 3. Orquestração do Pipeline Orquestração do Loop A Figura 2 apresenta os passos principais na execução do Loop. Os dados são inicialmente transferidos para os GPUs (1). De seguida, iniciam-se as iterações, seguido pelo teste da condição (2), sendo que se assume que a condição é inicialmente válida. A condição de paragem pode ou não depender do conjunto de dados de saída da computação, assemelhando-se a um For e While respetivamente. Caso esta for verdadeira é lançada a execução das árvores de computação nos GPUs (4). É utilizada uma função de step para evoluir os valores necessários pela condição de paragem (5), e imediatamente a seguir é efetuada uma sincronização de dados que tenham sido modificados pela função

5 step (1) e são trocados os dados de entrada com os dados de saída em preparação da próxima iteração (6). Para suportar múltiplos GPUs, o While precisa garantir que os passos relacionados à função de evolução step sejam sincronizados entre as várias tarefas, para esta ser apenas calculada uma vez, e apenas quando os dados de todas as partições estão disponíveis. Orquestração do Pipeline A Figura 3 ilustra os passos principais da orquestração realizada pelo Pipeline. Este começa por transferir os dados de entrada para os vários GPUs (1), seguindo-se a computação sequencial dos dois estágios (2 e 3), sendo que os resultados do primeiro, já presentes nos GPUs, são utilizados como dados de entrada do segundo. Por fim, os resultados da segunda execução são transferidos para a memória principal (4). Em ambos os esqueletos é necessário que exista compatibilidade nos dados de entrada e saída, nomeadamente entre dois estágios do Pipeline e na entrada e saída do Loop. Uma consideração importante, é que esta compatibilidade tem de transpor para as várias decomposições criadas pelo Marrow. Aninhamento de Esqueletos O aninhamento permite a criação de computações complexas através da composição de um número arbitrário de esqueletos aninhados, apenas limitada pela quantidade de memória disponível nos GPUs. Que seja do nosso conhecimento, o Marrow é o único sistema a suportar este nível de composicionalidade no contexto GPGPU, o que levanta uma série de desafios. O suporte de aninhamento requer que os esqueletos tenham comportamentos diferenciados, dependendo se se encontram, ou não, na raiz da árvore de computação. Tal deve-se ao facto de todo o controlo sobre a computação e interação com o hospedeiro estar concentrado na raiz. Desse modo, o fluxo da computação e da partilha dos dados desce ao longo da árvore. A raiz é responsável por transferir os dados (do e para o hospedeiro) e por desencadear a computação, orquestrando subsequentemente a(s) sua(s) sub-árvore(s) (emitindo pedidos de execução e comunicando as necessárias referências para dados) de acordo com o comportamento que fatoriza. Estas sub-árvores assumem, por sua vez, essas mesmas responsabilidades perante a sua descendência, até que seja atingindo uma folha, caso em que a computação associada é executada. 4 Sistema de execução Nesta secção apresentamos a arquitetura e modelo de execução do Marrow. A arquitetura, representada na Figura 4, está organizada em três camadas principais, sendo que cada uma só tem visão da camada abaixo. O programador apenas tem acesso à camada da biblioteca de esqueletos, possibilitando a criação de árvores de computação, com esqueletos ou computações OpenCL (KernelWrapper), com a ajuda de um conjunto de contentores que descrevem os tipos de dados válidos para uma computação OpenCL. A camada de execução é utilizada pela biblioteca para lidar com a plataforma, seja para a decomposição do domínio, utilizando

6 Aplicações Biblioteca de Esqueletos MapReduce Loop Pipeline Tipos de Dados Kernel Map For Vector KernelWrapper Sistema de Execução KernelBuilder Scheduler Excepções Contentores PartitionInfo ExecutionPlatform Task Launcher Auto-Tuner Task Dispositivos OpenCL Figura 4. Arquitectura do Marrow o Auto-Tuner, para distribuir tarefas pelos GPUs com o Scheduler ou para o lançamento de tarefas com o TaskLauncher. Por sua vez, o modelo de execução (Figura 5) está dividido em dois estágios principais: decomposição estática do domínio e pedidos dinâmicos de execução. O primeiro é iniciado com a criação do Skeleton (1) que desencadeia um pedido ao Scheduler para a decomposição das suas estruturas de entrada/saída (2). Para levar a cabo tal tarefa, o Scheduler recorre a dados de desempenho predeterminados (3), recolhidos no ato de instalação da biblioteca utilizando o Shoc Benchmark Suite [16]. A descrição das partições é de seguida organizada numa estrutura (4), que é guardada na informação associada às respetivas computações (KernelWrapper) aninhadas na árvore de computação (5). O segundo estágio inicia quando o programador submete um pedido execução ao esqueleto algorítmico, fornecendo o conjunto de dados ao qual quer aplicar a computação (6). É criado e devolvido um objeto Future (7, 8) que permite o acesso ao estado da computação (se terminou, ou não) tal como para acesso aos dados quando esta acaba. O programador pode então escolher esperar que a computação acabe (9), ou continuar execução até precisar dos resultados. O pedido é então submetido para o Scheduler, que utilizando as já criadas (10), adicionaas às filas de tarefas de cada GPU para serem executadas (11). A emissão dos comandos de execução e transferência de dados para o GPUs está a cargo do TaskLauncher. Para tal, este dispõe de um conjunto de threads que consomem os pedidos de execução da fila (12), transferem os dados de entrada para o dispositivo alvo e emitem os pedido de execução (13). Por fim quando todas as tarefas associadas a um pedido de execução terminam, o TaskLauncher notifica o Future que a computação acabou (14), que por sua ver notifica qualquer aplicação bloqueada à espera dos resultados (15). 4.1 Decomposição do Domínio A decomposição estática dos dados de entrada é efetuada utilizando o módulo Auto-Tuner, que permite a utilização de dados empíricos de desempenho para criar cargas de trabalho adequadas para os GPUs presentes no sistema. Neste contexto, o Auto-Tuner calcula o desempenho relativo entre todos os GPUs e as partições são criadas de acordo com este rácio. O desempenho relativo é na

7 Decomposição Estática de Domínio (9) (15) (8) Future Aplicação Skeleton (1) (6) (5) (7) Skeleton Pedido Dinâmico de Execução Partições GPU #1: P11 P12... P1n GPU #2: P21 P22... P2n (14) (2) Ref. (4) (10) Sistema de Execução (3) Scheduler (11) T(P1n)... T(P12) T(P11) T(P2n)... T(P22) T(P21) TaskLauncher (13) (12) GPU #1 GPU #2 Figura 5. Fluxo de execução do Marrow. realidade calculado em duas métricas: cálculo de precisão simples e dupla. A classificação no Marrow de que métrica utilizar não é perfeita, visto que o Auto-Tuner apenas tem acesso aos tipos de dados dos argumentos e não é analisado o código da computação OpenCL. Dado que apenas consideramos neste trabalho computações com paralelismo de dados e operações do tipo stencil (com fronteiras partilhadas) não são ainda suportadas, tem de existir uma correspondência entre os conjuntos de dados de entrada e de saída. Para ajudar o utilizador é possível, no entanto, definir um tamanho indivisível, pelo qual o Auto-Tuner adere de forma a possibilitar restrições na decomposição dos dados. 5 Resultados Experimentais Esta secção tem o objetivo de avaliar o desempenho dos esqueletos Marrow para paralelismo de tarefas quando transpostos de um para um para vários GPUs. Não comparamos com computações OpenCL puras, dado que Ricardo et al. já o fizeram em [8] com bons resultados. Começamos por descrever os casos de estudo escolhidos, seguido de uma breve discussão sobre o impacto do barramento PCIe na performance geral de aplicações em GPUs e finalmente são apresentados os resultados dos casos de estudo. Neste contexto, apresentamos quatro testes. O primeiro caso de estudo é um encadeamento de filtros de imagem, constituído por dois pipelines e três filtros, nomeadamente Gaussian Noise, Solarize e Mirror. Estes requerem que seja decomposto por tamanho de linha sendo que esta restrição é passada como tamanho indivisível ao Auto-Tuner. O segundo é um conjunto de Fast-Fourier Transformations (FFTs) de 512kB cada, adaptados do Shoc Benchmark Suite. Este é composto por um Pipeline em que o primeiro estágio é o FFT e o segundo é a sua inversa. É designado a cada GPU um certo número de FFTs, sendo que é utilizado o tamanho de um FFT como o tamanho indivisível para decomposição no Auto-Tuner.

8 Pipeline de filtros FFT N-Body (pixels) (MBytes) (número de corpos) Input parameter size S 1 tempo de execução (ms) S 2 tempo de execução (ms) Tabela 1. Tempos de execução com um GPU em milisegundos. O terceiro e último caso de estudo é uma simulação N-Body em que são iterativamente calculados os efeitos de forças num sistema de dinâmico de corpos (bodies). Este é decomposto pelo número de partículas (uma região) a calcular por cada decomposição. Visto que este teste precisa de acesso a todos os outros corpos do sistema, é necessário que todo o conjunto de entrada esteja disponível em todos os GPUs na sua integralidade, tal como a sincronização ao fim de cada iteração da simulação. Este caso de estudo é implementado utilizando um Loop com uma condição de paragem semelhante a um For. A única diferença é que é necessário forçar a sincronização dos dados de entrada para todos os GPUs, simplesmente marcando-os como modificados na função de evolução step. Foram utilizados dois sistemas distintos para avaliar os casos de estudos: S 1 S 2 tem um Intel(R) Xeon(R) E GHz, com uma motherboard ASUS P6T7, 12 GB de RAM, e três GPUs: duas NVidia Tesla C1060 e uma NVIDIA Quadro FX A configuração dos GPUs é C1060 :: FX3800 :: C1060. tem um Intel(R) Core(TM) i7-3930k 3.20GHz, com uma motherboard ASUS P9X79 PRO, 32 GB de RAM, e duas AMD Radeon HD É importante notar que o S 2 ao contrário do S 1 suporta uma configuração com duplo x16 PCIe possibilita fatores de aceleração escalarem linearmente na transferência de dados para dois GPUs versus um único GPU. Este facto foi confirmado com o nosso benchmark de transferência de dados. Em contraste, o S 1, apesar de apresentar um melhoramento na taxa de utilização do barramento PCIe, este não é linear, apresentando ganhos de 40% quando se utiliza dois GPUs e 54% quando se utiliza os três. Desempenho Os casos de estudo têm o objetivo de avaliar a nossa abordagem em termos da escalabilidade. Os tempos de execução estão limitados ao tempo entre a submissão e obtenção dos resultados, excluindo o tempo de inicialização e tempos de decomposição do domínio. Este último apenas calculado uma vez, e tem um tempo de execução mínimo, sem ultrapassar 0.15ms. A Tabela 1 apresenta os tempos base de execução usando um GPU. Na Figura 6 podemos ver os fatores de aceleração de múltiplos GPUs para os quatro casos de estudo apresentados previamente, em relação à execução no Marrow utilizando apenas um GPU. Cada caso de estudo foi executado 500 vezes, as suas durações foram guardadas e ordenadas e apenas temos em conta um terço dos valores situados no meio da lista.

9 2.00 Fator de Aceleração ^2 4096^2 8192^2 128 MB 256 MB 512 MB Pipeline de Filtros (pixels) FFT (tamanho dos dados) N- Body (número corpos) (S1) 2 GPUs (S1) 3 GPUs (S2) 2 GPUs ^2 4096^2 8192^2 3 GPU 2 GPU 1 GPU 3 GPU 2 GPU 1 GPU 3 GPU 2 GPU 1 GPU 0% 20% 40% 60% 80% 100% Execução Transferência de dados e orquestração Figura 6. Fatores de aceleração versus execução com um GPU. Figura 7. Decomposição do pipeline de filtros de imagem em S1. Sendo que no sistema S 1, temos um conjunto de GPUs heterogéneos, o desempenho relativo calculado pelo Marrow para o tamanho das partições é: C1060 (36%) :: FX 3800 (27%) :: C1060 (37%). Desta forma o fator de aceleração máximo para dois e três GPUs 1.75 e 2.70 respetivamente. Estes, no entanto, são os valores ótimos que não têm em conta o barramento PCIe partilhado entre os três GPU, limitando mais os fatores de aceleração possíveis em problemas com tamanhos significativos de transferências. Na Figura 7 podemos observar a decomposição do tempo de execução numa computação limitada pela transferência de dados, sendo que esta relação entre tempo de computação e tempo de transferência é indiretamente proporcional ao número de GPUs. No nosso conjunto de casos de teste, o pipeline de filtros de imagens tem esta característica, sendo que apresentam os melhores resultados em problemas de tamanho médio com um fator de aceleração máximo de 1.85 com três GPUs. O FFT, em contraste, tem um peso de computação mais significante, que se pode ver na escalabilidade constante, apesar de não ser linear, sendo o valor mais elevado de A simulação N-Body, utiliza um algoritmo O(N 2 ), apresentando uma carga computacional extrema, que contabiliza entre 88% (para problemas pequenos) e 98% (para um número elevado de corpos). Para ter melhor performance, este tira partido de memória local de cada grupo de trabalho no GPU para otimizar o acesso aos dados em memória global. Esta característica implica que o tamanho do trabalho de grupo local tem um papel importante no desempenho desta computação. O Auto-Tuner neste momento não tenta otimizar este parâmetro, sendo que neste momento os grupos de trabalho são forçados para serem múltiplos de 64 (variando no tamanho, de acordo com o tamanho da partição). Esta é uma medida temporária, e proporciona um tradeoff entre granularidade da decomposição dos conjuntos de dados (mantendo alguma precisão em relação à proporção de desempenho dos GPUs) e o tamanho dos grupos

10 de trabalho locais possíveis. Este facto pode-se observar na escalabilidade, por vezes super-escalabilidade, mas que não se aplica a todos os casos devido à flutuação implícita do tamanho dos grupos locais de trabalho presente no sistema S 1. No caso do sistema S 2, devidos aos GPUs serem homogéneos, temos resultados consistentes, visto que o tamanho do grupo local de trabalho se tornar constante dado haver decomposições iguais, este possibilita uma escalabilidade proporcional ao tamanho do problema, sendo interessante mencionar que obtém um fator de aceleração 1.77 para corpos neste caso de estudo apesar de este caso não estar apresentado devido à instabilidade do desempenho no S 1 no estado corrente do Marrow. Esta escalabilidade deve-se à elevada capacidade de computação dos GPUs, que se pode observar na Tabela 1 em relação às placas presentes em S 1. Em geral os tempos de execução no S 2 apresentam um grau de escalabilidade melhor, devido, não só à potência já mencionada dos GPUs, mas também do facto de existirem barramentos PCIe dedicados. Tal como no N-Body, todos os testes escalam proporcionalmente com o tamanho do conjunto de dados, mostrando fatores de aceleração perto ou acima de Trabalho Relacionado Já existe alguma investigação de construções pipeline no contexto GPGPU, nomeadamente Lime [9], StreamIt [10] e NMM [11]. O Lime é uma linguagem compatível com o Java que permite computação em sistemas com um único GPU de forma transparente. Pipelines são possíveis utilizando uma operação nova (=>), encadeando filters, a unidade de computação. O StreamIt e NMM são trabalhos que tiram partido de stream processing, um modelo de programação que permite a computação de fluxos contínuos de dados. Ambos suportam múltiplos GPUs, e as computações podem ser representadas utilizando um grafo orientado, onde cada nó é uma computação. No StreamIt o grafo é particionado, utilizando um algoritmo iterativo de coarsening/uncoarsening que permite a partição do grafo tendo em conta os requisitos de cada nó e analisando os caminhos dos dados. Esta abordagem permite também minimizar a migração de dados entre GPUs. O NMM suporta clusters, sendo que se baseia no alto número potencial de GPUs disponíveis para distribuir apenas um nó de computação do grafo para cada GPU. Existe um alto nível de migração de dados neste sistema, sendo que é necessário que cada nó de computação seja pesado o suficiente para que o overhead da transferência seja minimizado. No contexto dos esqueletos algorítmicos, não existe nenhum sistema que implemente Pipeline nem Loop no contexto GPGPU. Do nosso conhecimento, apenas três bibliotecas suportam computação em múltiplos GPUs. O primeiro é o SkelCL [6] que oferece um conjunto de esqueletos que tira partido de paralelismo de dados, nomeadamente Map, Reduce, Zip e Scan. Para o suporte multi-gpu, o SkelCL usa decomposição estática dos conjuntos de dados e distribui estas usando políticas predeterminadas. O segundo é o SkePU [7] que se foca também em esqueletos que tiram partido de paralelismo de dados tais como Map, Reduce e variantes do Map, MapOverlap

11 e MapArray. O seu suporte para múltiplos GPU é conseguido através de integração do StarPU [17]. Este utiliza paralelismo de tarefas com work-stealing num ambiente com vários GPUs e clusters. O terceiro é o Muesli [18], que suporta clusters com múltiplos cores e GPUs usando CUDA. Os esqueletos suportados são Pipeline, Farm, DivideAndConquer, BranchdAndBound, Fold, Map, Scan e Zip, sendo que apenas os quatro últimos são suportados para execução GPU. O Pipeline é semelhante ao presente no Marrow, podendo ser utilizado para a orquestração explícita de execuções em CPUs, no entanto, este não tem suporte para GPUs. Não existe muita informação sobre o funcionamento das execuções com múltiplos GPUs, e o código disponível não apresenta suporte para execução GPU. No entanto, pela informação existente consegue-se concluir que todo o particionamento e agendamento de tarefas é delegado ao programador. O Marrow distingue-se das bibliotecas de esqueletos mencionadas ao implementar esqueletos novos (Pipeline e Loop) no contexto GPGPU utilizando múltiplos GPUs. O modelo interno de execução do Marrow assemelha-se vagamente ao presente no SkePU, pois ambos utilização paralelismo de tarefas internamente. Em relação aos trabalhos de processamento de fluxos de dados, há uma diferença obvia em modelo de programação, sendo que o Marrow é mais flexível nos tipos de computação possíveis pelo programador. 7 Conclusões Neste trabalho apresentamos o Marrow, uma biblioteca de esqueletos algorítmicos, para a execução de computações complexas em sistemas contendo múltiplos GPUs. Do nosso conhecimento o Marrow é a primeira biblioteca de esqueletos algorítmicos a implementar, neste contexto, esqueletos que tiram partido de paralelismo de tarefas, nomeadamente o Loop e Pipeline. Os resultados apresentam escalabilidade significativamente consistente, exceto no caso do N-Body, que introduz novas considerações relacionadas a ambientes com GPUs heterogéneos, que não são ainda consideradas no Marrow. Estas estão intrinsecamente associadas ao tamanho do grupo local de trabalho quando se utiliza a memória local para implementar técnicas de caching. Discutimos também o impacto que a configuração do barramento PCIe tem em vários tipos de computação, através dos dois sistemas apresentados na avaliação do Marrow, em que um sistema está equipado com barramentos PCIe dedicados a cada GPU, e o outro tem um barramento partilhado entre três GPUs. O Marrow está ainda em desenvolvimento pelo que existem ainda vários tópicos de investigação a endereçar. Uma nova abordagem seria a designação de tarefas utilizando work-stealing. É também possível melhorar a decomposição do domínio de duas formas: (1) introduzindo otimizações relativas à configuração dos grupos locais de trabalho e (2) decompondo a árvore de computação e distribuindo-a pelos GPUs. Esta última abordagem implica também a utilização de técnicas que minimizem a migração de dados, devido ao elevado custo inerente ao barramento PCIe.

12 Referências 1. hgpu.org: High performance computing on graphics processing units - Applications. (consultado em Junho 2013) 2. Gu, L., Li, X., Siegel, J.: An empirically tuned 2D and 3D FFT library on CUDA GPU. In: ICS 10, ACM (2010) Lalami, M.E., Baz, D.E., Boyer, V.: Multi GPU implementation of the simplex algorithm. In: HPCC 11, IEEE (2011) Munshi, A., et al.: The OpenCL Specification. Khronos OpenCL Working Group. (2009) 5. NVIDIA Corporation: NVIDIA CUDA. home_new.html (last visited in June 2013) 6. Steuwer, M., Kegel, P., Gorlatch, S.: Towards High-Level Programming of Multi- GPU Systems Using the SkelCL Library. In: IPDPSW 12, IEEE Computer Society (2012) Dastgeer, U., Enmyren, J., Kessler, C.: Auto-tuning SkePU: a multi-backend skeleton programming framework for multi-gpu systems. In: IWMSE 11, ACM (2011) Marques, R., Paulino, H., Alexandre, F., Medeiros, P.D.: Algorithmic skeleton framework for the orchestration of GPU computations. In: Euro-Par Number 8097 in Lecture Notes in Computer Science, Springer-Verlag (2013) Dubach, C., Cheng, P., Rabbah, R.M., Bacon, D.F., Fink, S.J.: Compiling a highlevel language for GPUs: (via language support for architectures and compilers). In: PLDI 12, ACM (2012) Huynh, H.P., Hagiescu, A., Wong, W.F., Goh, R.S.M.: Scalable framework for mapping streaming applications onto multi-gpu systems. In: PPOPP 12, ACM (2012) Repplinger, M., Slusallek, P.: Stream processing on GPUs using distributed multimedia middleware. Concurrency and Computation: Practice and Experience (2011) Ernsting, S., Kuchen, H.: Algorithmic skeletons for multi-core, multi-gpu systems and clusters. IJHPCN 7(2) (2012) AMD Corporation: Bolt C++ Template Library. tools/heterogeneous-computing/ (consultado em Junho 2013) 14. Hoberock, J., Bell, N.: Thrust: A parallel template library (consultado em Junho 2013) 15. González-Vélez, H., Leyton, M.: A survey of algorithmic skeleton frameworks: high-level structured parallel programming enablers. Softw., Pract. Exper (2010) Danalis, A., Marin, G., McCurdy, C., Meredith, J.S., Roth, P.C., Spafford, K., Tipparaju, V., Vetter, J.S.: The scalable heterogeneous computing (SHOC) benchmark suite. In: GPGPU 10, ACM (2010) Augonnet, C., Thibault, S., Namyst, R., Wacrenier, P.A.: StarPU: A unified platform for task scheduling on heterogeneous multicore architectures. In: Euro-Par 09, Springer (2009) Ernsting, S., Kuchen, H.: Algorithmic skeletons for multi-core, multi-gpu systems and clusters. Int. J. High Perform. Comput. Netw. (2012)

Análise de desempenho e eficiência energética de aceleradores NVIDIA Kepler

Análise de desempenho e eficiência energética de aceleradores NVIDIA Kepler Análise de desempenho e eficiência energética de aceleradores NVIDIA Kepler Emilio Hoffmann, Bruno M. Muenchen, Taís T. Siqueira, Edson L. Padoin e Philippe O. A. Navaux Universidade Regional do Noroeste

Leia mais

Auditoria de senhas em hardware paralelo com o John the Ripper O impacto das tecnologias de processamento paralelo na quebra de senhas

Auditoria de senhas em hardware paralelo com o John the Ripper O impacto das tecnologias de processamento paralelo na quebra de senhas Auditoria de senhas em hardware paralelo com o John the Ripper O impacto das tecnologias de processamento paralelo na quebra de senhas Claudio André claudio.andre@correios.net.br Motivação Seu computador

Leia mais

Computação Heterogênea Programação paralela, clusters e GPUs

Computação Heterogênea Programação paralela, clusters e GPUs Computação Heterogênea Programação paralela, clusters e GPUs Profa. Dra. Denise Stringhini (ICT- Unifesp) Primeiro Encontro do Khronos Chapters Brasil Belo Horizonte, 20/09/2013 Conteúdo Computação heterogênea:

Leia mais

Computação Paralela. Desenvolvimento de Aplicações Paralelas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho.

Computação Paralela. Desenvolvimento de Aplicações Paralelas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho. Computação Paralela Desenvolvimento de Aplicações Paralelas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho Outubro 2005 Desenvolvimento de Aplicações Paralelas Uma Metodologia

Leia mais

Placa de vídeo em CUDA

Placa de vídeo em CUDA Placa de vídeo em CUDA Matheus Costa Leone de Souza Krystian Aparacido Resumo Quando você tem um cálculo que possa ser grande demais para você realizar a mão, a primeira solução que lhe vem a cabeça é

Leia mais

FACULDADE PITÁGORAS PRONATEC

FACULDADE PITÁGORAS PRONATEC FACULDADE PITÁGORAS PRONATEC DISCIPLINA: ARQUITETURA DE COMPUTADORES Prof. Ms. Carlos José Giudice dos Santos carlos@oficinadapesquisa.com.br www.oficinadapesquisa.com.br Objetivos Ao final desta apostila,

Leia mais

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

ANDERSON UILIAN KAUER ESCALONAMENTO DE TAREFAS EM ARQUITETURAS HETEROGÊNAS APUS

ANDERSON UILIAN KAUER ESCALONAMENTO DE TAREFAS EM ARQUITETURAS HETEROGÊNAS APUS ANDERSON UILIAN KAUER ESCALONAMENTO DE TAREFAS EM ARQUITETURAS HETEROGÊNAS APUS CANOAS, 2012 ANDERSON UILIAN KAUER ESCALONAMENTO DE TAREFAS EM ARQUITETURAS HETEROGÊNAS APUS Trabalho de conclusão apresentado

Leia mais

Software Pipeline. Sergio Ricardo Souza Leal de Queiroz. IC-Unicamp - RA: 107070 RESUMO 2. SOFTWARE PIPELINE, CONCEITOS 1.

Software Pipeline. Sergio Ricardo Souza Leal de Queiroz. IC-Unicamp - RA: 107070 RESUMO 2. SOFTWARE PIPELINE, CONCEITOS 1. RESUMO Software Pipeline Sergio Ricardo Souza Leal de Queiroz A partir do momento em que se constatou que a evolução dos computadores não estaria mais na velocidade do processador, e sim em projetar máquinas

Leia mais

PROGRAMAÇÃO E APERFEIÇOAMENTO DA APLICAÇÃO DO ALGORITMO WATERSHED PARA A SEGMENTAÇÃO DE GALÁXIAS BASEADO EM DADOS ESPECTROGRÁFICOS.

PROGRAMAÇÃO E APERFEIÇOAMENTO DA APLICAÇÃO DO ALGORITMO WATERSHED PARA A SEGMENTAÇÃO DE GALÁXIAS BASEADO EM DADOS ESPECTROGRÁFICOS. PROGRAMAÇÃO E APERFEIÇOAMENTO DA APLICAÇÃO DO ALGORITMO WATERSHED PARA A SEGMENTAÇÃO DE GALÁXIAS BASEADO EM DADOS ESPECTROGRÁFICOS. Murilo Moritz Parize 1 - Marcelo Massocco Cendron 2 INTRODUÇÃO A necessidade

Leia mais

Programação Paralela em Ambientes Computacionais Heterogêneos com OpenCL

Programação Paralela em Ambientes Computacionais Heterogêneos com OpenCL Programação Paralela em Ambientes Computacionais Heterogêneos com OpenCL César L. B. Silveira Prof. Dr. Luiz G. da Silveira Jr. Prof. Dr. Gerson Geraldo H. Cavalheiro 28 de outubro de 2010 contato@v3d.com.br

Leia mais

Arquitetura e Organização de Computadores. Capítulo 0 - Introdução

Arquitetura e Organização de Computadores. Capítulo 0 - Introdução Arquitetura e Organização de Computadores Capítulo 0 - Introdução POR QUE ESTUDAR ARQUITETURA DE COMPUTADORES? 2 https://www.cis.upenn.edu/~milom/cis501-fall12/ Entender para onde os computadores estão

Leia mais

Programação Paralela Híbrida em CPU e GPU: Uma Alternativa na Busca por Desempenho

Programação Paralela Híbrida em CPU e GPU: Uma Alternativa na Busca por Desempenho 124 - Encontro Anual de Tecnologia da Informação Programação Paralela Híbrida em CPU e GPU: Uma Alternativa na Busca por Desempenho André Luís Stefanello¹, Crístian Cleder Machado1, Dioni da Rosa¹, Maurício

Leia mais

Muitas aplicações modernas podem ser modeladas como tarefas divisíveis.

Muitas aplicações modernas podem ser modeladas como tarefas divisíveis. 1 Introdução O grande aumento de performance das redes de computadores, combinado com a proliferação de computadores de baixo custo e alto desempenho, trouxe à tona ambientes de meta-computação, ou grids[15,

Leia mais

CAD Trabalho III. PThreads e OpenMP. Pedro Carvalho de Oliveira Rui André Ponte Costa

CAD Trabalho III. PThreads e OpenMP. Pedro Carvalho de Oliveira Rui André Ponte Costa Universidade de Coimbra Faculdade de Ciências e Tecnologia Departamento de Engenharia Informática CAD Trabalho III PThreads e OpenMP Pedro Carvalho de Oliveira Rui André Ponte Costa Maio 2008 Resumo Neste

Leia mais

PARALELIZAÇÃO DE APLICAÇÕES NA ARQUITETURA CUDA: UM ESTUDO SOBRE VETORES 1

PARALELIZAÇÃO DE APLICAÇÕES NA ARQUITETURA CUDA: UM ESTUDO SOBRE VETORES 1 PARALELIZAÇÃO DE APLICAÇÕES NA ARQUITETURA CUDA: UM ESTUDO SOBRE VETORES 1 DUTRA, Evandro Rogério Fruhling 2 ; VARINI, Andre Luis 2 ; CANAL, Ana Paula 2 1 Trabalho de Iniciação Científica _UNIFRA 2 Ciência

Leia mais

PROJETO LÓGICO DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

PROJETO LÓGICO DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 6 - ARQUITETURAS AVANÇADAS DE COMPUTADORES 1. INTRODUÇÃO As arquiteturas dos processadores têm evoluído ao longo dos anos, e junto com ela o conceito de arquitetura avançada tem se modificado. Nos

Leia mais

Arquitetura e Organização de Computadores. Capítulo 0 - Introdução

Arquitetura e Organização de Computadores. Capítulo 0 - Introdução Arquitetura e Organização de Computadores Capítulo 0 - Introdução POR QUE ESTUDAR ARQUITETURA DE COMPUTADORES? 2 https://www.cis.upenn.edu/~milom/cis501-fall12/ Entender para onde os computadores estão

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

FACULDADE PITÁGORAS DISCIPLINA: ARQUITETURA DE COMPUTADORES

FACULDADE PITÁGORAS DISCIPLINA: ARQUITETURA DE COMPUTADORES FACULDADE PITÁGORAS DISCIPLINA: ARQUITETURA DE COMPUTADORES Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br ESQUEMA DE UM COMPUTADOR Uma Unidade Central de

Leia mais

3/9/2010. Ligação da UCP com o barramento do. sistema. As funções básicas dos registradores nos permitem classificá-los em duas categorias:

3/9/2010. Ligação da UCP com o barramento do. sistema. As funções básicas dos registradores nos permitem classificá-los em duas categorias: Arquitetura de Computadores Estrutura e Funcionamento da CPU Prof. Marcos Quinet Universidade Federal Fluminense P.U.R.O. Revisão dos conceitos básicos O processador é o componente vital do sistema de

Leia mais

Análise de Desempenho de um SGBD para Aglomerado de Computadores

Análise de Desempenho de um SGBD para Aglomerado de Computadores Análise de Desempenho de um SGBD para Aglomerado de Computadores Diego Luís Kreutz, Gabriela Jacques da Silva, Hélio Antônio Miranda da Silva, João Carlos Damasceno Lima Curso de Ciência da Computação

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA DEPARTAMENTO DE ELETRÔNICA E COMPUTAÇÃO PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA

UNIVERSIDADE FEDERAL DE SANTA MARIA DEPARTAMENTO DE ELETRÔNICA E COMPUTAÇÃO PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA UNIVERSIDADE FEDERAL DE SANTA MARIA DEPARTAMENTO DE ELETRÔNICA E COMPUTAÇÃO PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA Estudo e aperfeiçoamento da técnica de Steering Behaviors na simulação física de fluidos

Leia mais

DistributedCL: a framework for transparent distributed GPU processing using the OpenCL API

DistributedCL: a framework for transparent distributed GPU processing using the OpenCL API DistributedCL: a framework for transparent distributed GPU processing using the OpenCL API André Tupinambá Programa de Engenharia Eletrônica PEL Universidade do Estado do Rio de Janeiro UERJ Rio de Janeiro,

Leia mais

CPU - Significado CPU. Central Processing Unit. Unidade Central de Processamento

CPU - Significado CPU. Central Processing Unit. Unidade Central de Processamento CPU - Significado CPU Central Processing Unit Unidade Central de Processamento CPU - Função Na CPU são executadas as instruções Instrução: comando que define integralmente uma operação a ser executada

Leia mais

Definindo melhor alguns conceitos

Definindo melhor alguns conceitos Definindo melhor alguns conceitos Processamento Paralelo: processamento de informação concorrente que pertencem a um ou mais processos que resolvem um único problema. Processamento Distribuído: processamento

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

Oracle Grid Engine. Thiago Marques Soares. Pós-Graduação em Modelagem Computacional Universidade Federal de Juiz de Fora. 8 de abril de 2015

Oracle Grid Engine. Thiago Marques Soares. Pós-Graduação em Modelagem Computacional Universidade Federal de Juiz de Fora. 8 de abril de 2015 Oracle Grid Engine Thiago Marques Soares Pós-Graduação em Modelagem Computacional Universidade Federal de Juiz de Fora 8 de abril de 2015 Thiago Marques Soares Algoritmos e E.D. 8 de abril de 2015 1 /

Leia mais

Arquitetura de Computadores. Professor: Vilson Heck Junior

Arquitetura de Computadores. Professor: Vilson Heck Junior Arquitetura de Computadores Professor: Vilson Heck Junior Agenda Conceitos Estrutura Funcionamento Arquitetura Tipos Atividades Barramentos Conceitos Como já discutimos, os principais componentes de um

Leia mais

Multi-processamento. Arquitecturas MIMD de memória partilhada Multi-cores heterogéneos Multi-processadores

Multi-processamento. Arquitecturas MIMD de memória partilhada Multi-cores heterogéneos Multi-processadores Multi-processamento Arquitecturas MIMD de memória partilhada Multi-cores heterogéneos Multi-processadores Arquitecturas MIMD de memória distribuída Massive Parallel Computers Sistemas distribuídos Ainda

Leia mais

PPD: Balanceamento de Carga e Scheduling 2

PPD: Balanceamento de Carga e Scheduling 2 PPD: Balanceamento de Carga e Scheduling 2 Fernando Silva DCC-FCUP 2 (Alguns dos slides são baseados nos de Kathy Yelick, www.cs.berkeley.edu/ yelick) Fernando Silva (DCC-FCUP) PPD: Balanceamento de Carga

Leia mais

Paralelização Introdução a vetorização, OpenMP e MPI

Paralelização Introdução a vetorização, OpenMP e MPI 1/45 Paralelização Introdução a vetorização, OpenMP e MPI 1 Conceitos Paulo Penteado IAG / USP pp.penteado@gmail.com Esta apresentação: Arquivos do curso: Artigo relacionado: http://www.ppenteado.net/ast/pp_para_on/pp_para_on_1.pdf

Leia mais

3.1. Paralelização em CUDA (GPU-PGLIQ)

3.1. Paralelização em CUDA (GPU-PGLIQ) 44 3 3.1. Paralelização em CUDA (GPU-PGLIQ) Aplicação: Aceleração Base No algoritmo serial de PGLIQ, o maior tempo de processamento está na avaliação da função de aptidão, embora este procedimento seja

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA DEPARTAMENTO DE ELETRÔNICA E COMPUTAÇÃO Programa de Pós-Graduação em Informática

UNIVERSIDADE FEDERAL DE SANTA MARIA DEPARTAMENTO DE ELETRÔNICA E COMPUTAÇÃO Programa de Pós-Graduação em Informática UNIVERSIDADE FEDERAL DE SANTA MARIA DEPARTAMENTO DE ELETRÔNICA E COMPUTAÇÃO Programa de Pós-Graduação em Informática Estudo e aperfeiçoamento da técnica de steering behaviors na simulação física de fluidos

Leia mais

INSTITUTO DE EMPREGO E FORMAÇÃO PROFISSIONAL, I.P.

INSTITUTO DE EMPREGO E FORMAÇÃO PROFISSIONAL, I.P. INSTITUTO DE EMPREGO E FORMAÇÃO PROFISSIONAL, I.P. Centro de Emprego e Formação Profissional da Guarda Curso: Técnico de Informática Sistemas (EFA-S4A)-NS Trabalho Realizado Por: Igor_Saraiva nº 7 Com

Leia mais

Técnicas de Desenvolvimento para Sistemas Real Time com LabVIEW

Técnicas de Desenvolvimento para Sistemas Real Time com LabVIEW Técnicas de Desenvolvimento para Sistemas Real Time com LabVIEW André Oliveira Engenheiro de Vendas Rodrigo Schneiater Engenheiro de Aplicações NIDays 2011 1 Agenda Projeto Entendendo Modelos de Agendamento

Leia mais

Fundamentos em Informática

Fundamentos em Informática Fundamentos em Informática 04 Organização de Computadores nov/2011 Componentes básicos de um computador Memória Processador Periféricos Barramento Processador (ou microprocessador) responsável pelo tratamento

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Balanceamento de Carga

Balanceamento de Carga 40 4. Balanceamento de Carga Pode-se entender por balanceamento de carga uma política a ser adotada para minimizar tanto a ociosidade de utilização de alguns equipamentos quanto a super utilização de outros,

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Arquitetura e Programação de GPU. Leandro Zanotto RA: 001962 Anselmo Ferreira RA: 023169 Marcelo Matsumoto RA: 085973

Arquitetura e Programação de GPU. Leandro Zanotto RA: 001962 Anselmo Ferreira RA: 023169 Marcelo Matsumoto RA: 085973 Arquitetura e Programação de GPU Leandro Zanotto RA: 001962 Anselmo Ferreira RA: 023169 Marcelo Matsumoto RA: 085973 Agenda Primeiras Placas de Vídeo Primeira GPU Arquitetura da GPU NVIDIA Arquitetura

Leia mais

Arquiteturas RISC. (Reduced Instructions Set Computers)

Arquiteturas RISC. (Reduced Instructions Set Computers) Arquiteturas RISC (Reduced Instructions Set Computers) 1 INOVAÇÕES DESDE O SURGIMENTO DO COMPU- TADOR DE PROGRAMA ARMAZENADO (1950)! O conceito de família: desacoplamento da arquitetura de uma máquina

Leia mais

ESTRUTURAS DE DADOS I. Notas de Aula. Prof. Dr. Gilberto Nakamiti

ESTRUTURAS DE DADOS I. Notas de Aula. Prof. Dr. Gilberto Nakamiti ESTRUTURAS DE DADOS I Notas de Aula 1 SUMÁRIO 1. INTRODUÇÃO... 2 1.1 Array (vetores)... 2 2. BUSCA DE ELEMENTOS... 3 2.1 Busca Seqüencial... 3 2.2 Busca Binária... 3 2.3 Busca Indexada... 3 2.4 Busca Hash...

Leia mais

A história do Processadores O que é o processador Características dos Processadores Vários tipos de Processadores

A história do Processadores O que é o processador Características dos Processadores Vários tipos de Processadores A história do Processadores O que é o processador Características dos Processadores Vários tipos de Processadores As empresas mais antigas e ainda hoje no mercado que fabricam CPUs é a Intel, AMD e Cyrix.

Leia mais

Paradigmas de Programação

Paradigmas de Programação Paradigmas de Programação Tipos de Dados Aula 5 Prof.: Edilberto M. Silva http://www.edilms.eti.br Prof. Edilberto Silva / edilms.eti.br Tipos de Dados Sistema de tipos Tipos de Dados e Domínios Métodos

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

Foz do Iguaçu PR Brasil luiz.baltazar@gmail.com, joao@barbosa.net.br, jorgeaikes@gmail.com

Foz do Iguaçu PR Brasil luiz.baltazar@gmail.com, joao@barbosa.net.br, jorgeaikes@gmail.com Análise de Desempenho e Viabilidade do Raspberry Pi como um Thin Client utilizando o Protocolo SPICE Luiz Alberto Alves Baltazar 1, João Paulo de Lima Barbosa 1, Jorge Aikes Junior 1 1 Curso de Ciência

Leia mais

Chord. Tecnologias de Middleware. Fernando Martins - fmp.martins@gmail.com

Chord. Tecnologias de Middleware. Fernando Martins - fmp.martins@gmail.com Chord Tecnologias de Middleware 2006/2007 Fernando Martins - fmp.martins@gmail.com Tópicos Objectivo Motivação Peer-To-Peer Chord Descrição Geral Características Distintivas Comparação DNS Modelo do Sistema

Leia mais

Arquitetura e Sistema de Monitoramento para

Arquitetura e Sistema de Monitoramento para Arquitetura e Sistema de Monitoramento para 1 Computação em Nuvem Privada Mestranda: Shirlei A. de Chaves Orientador: Prof. Dr. Carlos Becker Westphall Colaborador: Rafael B. Uriarte Introdução Computação

Leia mais

ENIAC. Introdução aos Computadores e à Programação (Noções Básicas)

ENIAC. Introdução aos Computadores e à Programação (Noções Básicas) ENIAC Introdução aos Computadores e à ção (Noções Básicas) Introdução aos Computadores e à ção (Noções Básicas) 1 Introdução aos Computadores e à ção (Noções Básicas) 2 O transistor foi inventado em 1947

Leia mais

12 EXCEL MACROS E APLICAÇÕES

12 EXCEL MACROS E APLICAÇÕES INTRODUÇÃO O principal objetivo deste livro é auxiliar o leitor na sua aprendizagem sobre os recursos avançados do Excel em especial na interligação com o Visual Basic for Applications (VBA). Pretende-se

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

LICENCIATURA EM COMPUTAÇÃO PROCESSADOR TEGRA 2

LICENCIATURA EM COMPUTAÇÃO PROCESSADOR TEGRA 2 LICENCIATURA EM COMPUTAÇÃO PROCESSADOR TEGRA 2 SANTO AMARO 2011 ANGELO RAMOS JACKELINE BARBOSA JEANDERVAL SANTOS PROCESSADOR TEGRA 2 Trabalho apresentado ao Instituto Federal de Ciências e Tecnologia da

Leia mais

Nível 3 Sistema Operacional

Nível 3 Sistema Operacional Nível 3 Sistema Operacional Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET Tecnologia de Análise e Desenvolvimento de Sistemas Organização de Computadores Prof. André Luiz 1 Nível

Leia mais

COMPARAÇÃO DE DESEMPENHO ENTRE DIFERENTES IMPLEMENTAÇÕES DO ALGORITMO KECCAK PARA PLATAFORMAS GPGPUS UTILIZANDO OPENCL

COMPARAÇÃO DE DESEMPENHO ENTRE DIFERENTES IMPLEMENTAÇÕES DO ALGORITMO KECCAK PARA PLATAFORMAS GPGPUS UTILIZANDO OPENCL CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO COMPARAÇÃO DE DESEMPENHO ENTRE DIFERENTES IMPLEMENTAÇÕES DO ALGORITMO KECCAK

Leia mais

O Problema do Fractal de Mandelbrot como Comparativo de Arquiteturas de Memória Compartilhada GPU vs OpenMP

O Problema do Fractal de Mandelbrot como Comparativo de Arquiteturas de Memória Compartilhada GPU vs OpenMP O Problema do Fractal de Mandelbrot como Comparativo de Arquiteturas de Memória Compartilhada GPU vs OpenMP Bruno P. dos Santos, Dany S. Dominguez, Esbel V. Orellana Departamento de Ciências Exatas e Tecnológicas

Leia mais

Organização e Arquitetura de Computadores I. de Computadores

Organização e Arquitetura de Computadores I. de Computadores Universidade Federal de Campina Grande Departamento de Sistemas e Computação Curso de Bacharelado em Ciência da Computação Organização e Arquitetura de I Organização Básica B de (Parte V, Complementar)

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

RELATÓRIO DE ATIVIDADES DISCIPLINA: ARQUITETURAS PARALELAS. Hadoop e QEF: Uma abordagem distribuída para aplicações de Astronomia

RELATÓRIO DE ATIVIDADES DISCIPLINA: ARQUITETURAS PARALELAS. Hadoop e QEF: Uma abordagem distribuída para aplicações de Astronomia UNIVERSIDADE FEDERAL FLUMINENSE INSTITUTO DE COMPUTAÇÃO (IC) RELATÓRIO DE ATIVIDADES DISCIPLINA: ARQUITETURAS PARALELAS Hadoop e QEF: Uma abordagem distribuída para aplicações de Astronomia Henrique Klôh

Leia mais

Introdução às arquiteturas paralelas e taxonomia de Flynn

Introdução às arquiteturas paralelas e taxonomia de Flynn Introdução às arquiteturas paralelas e taxonomia de Flynn OBJETIVO: definir computação paralela; o modelo de computação paralela desempenhada por computadores paralelos; e exemplos de uso da arquitetura

Leia mais

Aplicação Informática para o Ensino de Processamento Digital de Imagem

Aplicação Informática para o Ensino de Processamento Digital de Imagem Aplicação Informática para o Ensino de Processamento Digital de Imagem Sandra Jardim * e Paulo Sequeira Gonçalves ** * Departamento de Engenharia Informática e Tecnologias da Informação ** Departamento

Leia mais

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Sistemas Paralelos e Distribuídos Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Conceitos preliminares Paralelismo refere-se a ocorrência simultânea de eventos em um computador Processamento

Leia mais

1 Padrões de Implementação em Processamento de Imagens. 2 Resumo. 4 Computação paralela. 1.1 Relátório final para PIBIC/CNPq

1 Padrões de Implementação em Processamento de Imagens. 2 Resumo. 4 Computação paralela. 1.1 Relátório final para PIBIC/CNPq 1 Padrões de Implementação em Processamento de Imagens 1.1 Relátório final para PIBIC/CNPq Victor M. de A. Oliveira, Rubens Campos Machado Centro de Tecnologia da Informação Renato Archer CTI Divisão de

Leia mais

Tabela 4.2 Estatística típica de um sistema em 2007

Tabela 4.2 Estatística típica de um sistema em 2007 4. CONSTRUÇÃO DE ÍNDICE Neste capítulo é mostrado como construir um índice invertido, processo chamado de indexação. O projeto de indexação depende de algumas restrições de hardware, fato que leva a necessidade

Leia mais

Escola. Europeia de. Ensino. Profissional ARQUITETURA DE COMPUTADORES

Escola. Europeia de. Ensino. Profissional ARQUITETURA DE COMPUTADORES Escola Europeia de t Ensino Profissional ARQUITETURA DE COMPUTADORES TRABALHO REALIZADO: ANDRÉ RIOS DA CRUZ ANO LETIVO: 2012/ 2013 TÉCNICO DE GESTÃO DE EQUIPAMENTOS INFORMÁTICOS 2012 / 2013 3902 Escola

Leia mais

Introdução ao Processador CELL BE

Introdução ao Processador CELL BE 1 Introdução ao Processador CELL BE por: José Ricardo de Oliveira Damico 17 / Maio / 2007 São Paulo SP 2 SUMÁRIO LISTA DE FIGURAS 3 RESUMO 4 1.) INTRODUÇÃO 5 1.1) O que é? 5 2.) Utilização 5 3.) FUNCIONAMENTO

Leia mais

Xavantes: Structured Process Execution Support for Grid Environments

Xavantes: Structured Process Execution Support for Grid Environments Xavantes: Structured Process Execution Support for Grid Environments Fábio R. L. Cicerre 1, Edmundo R. M. Madeira 1, Luiz E. Buzato 1 1 Instituto de Computação Universidade Estadual de Campinas (UNICAMP)

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

On Scalability of Software-Defined Networking

On Scalability of Software-Defined Networking On Scalability of Software-Defined Networking Bruno dos Santos Silva bruno.silva@ic.uff.br Instituto de Computação IC Universidade Federal Fluminense UFF 24 de Setembro de 2015 B. S. Silva (IC-UFF) On

Leia mais

O hardware é a parte física do computador, como o processador, memória, placamãe, entre outras. Figura 2.1 Sistema Computacional Hardware

O hardware é a parte física do computador, como o processador, memória, placamãe, entre outras. Figura 2.1 Sistema Computacional Hardware 1 2 Revisão de Hardware 2.1 Hardware O hardware é a parte física do computador, como o processador, memória, placamãe, entre outras. Figura 2.1 Sistema Computacional Hardware 2.1.1 Processador O Processador

Leia mais

Remote Procedure Call. Programação distribuída e paralela (C. Geyer) RPC 1

Remote Procedure Call. Programação distribuída e paralela (C. Geyer) RPC 1 Remote Procedure Call Programação distribuída e paralela (C. Geyer) RPC 1 Autoria Autores C. Geyer Local II-UFRGS Versão V11.4 2014-2 Disciplinas SOII Programação distribuída e paralela (C. Geyer) RPC

Leia mais

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos Capítulo 8 Sistemas com Múltiplos Processadores 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos 1 Sistemas Multiprocessadores Necessidade contínua de computadores mais rápidos modelo

Leia mais

Técnicas de Computação de Alto Desempenho para o Processamento e Análise de Imagens Complexas da Cavidade Pélvica Feminina

Técnicas de Computação de Alto Desempenho para o Processamento e Análise de Imagens Complexas da Cavidade Pélvica Feminina Técnicas de Computação de Alto Desempenho para o Processamento e Análise de Imagens Complexas da Cavidade Pélvica Feminina Carlos Alex S. J. Gulo Orientador: Prof. Dr. João Manuel R. S. Tavares Co-Orientador:

Leia mais

Programação Paralela e Distribuída 2009/10. Fundamentos

Programação Paralela e Distribuída 2009/10. Fundamentos Programação Paralela e Distribuída 1 Porquê Programação Paralela? Se um único computador (processador) consegue resolver um problema em N segundos, podem N computadores (processadores) resolver o mesmo

Leia mais

Hardware. Objetivos da aula. Fornecer exemplos de processadores Intel. Esclarecer as diferenças e as tecnologias embutidas nos processadores Intel.

Hardware. Objetivos da aula. Fornecer exemplos de processadores Intel. Esclarecer as diferenças e as tecnologias embutidas nos processadores Intel. Hardware UCP Unidade Central de Processamento Características dos processadores Intel Disciplina: Organização e Arquitetura de Computadores Prof. Luiz Antonio do Nascimento Faculdade Nossa Cidade Objetivos

Leia mais

Introdução à Computação: Sistemas de Computação

Introdução à Computação: Sistemas de Computação Introdução à Computação: Sistemas de Computação Beatriz F. M. Souza (bfmartins@inf.ufes.br) http://inf.ufes.br/~bfmartins/ Computer Science Department Federal University of Espírito Santo (Ufes), Vitória,

Leia mais

Organização e Arquitetura de Computadores

Organização e Arquitetura de Computadores Organização e Arquitetura de Computadores Entrada e saída Alexandre Amory Edson Moreno Nas Aulas Anteriores Foco na Arquitetura e Organização internas da Cleo Modelo Von Neuman Circuito combinacional Circuito

Leia mais

FACULDADE PITÁGORAS DISCIPLINA: ARQUITETURA DE COMPUTADORES

FACULDADE PITÁGORAS DISCIPLINA: ARQUITETURA DE COMPUTADORES FACULDADE PITÁGORAS DISCIPLINA: ARQUITETURA DE COMPUTADORES Prof. Ms. Carlos José Giudice dos Santos cpgcarlos@yahoo.com.br www.oficinadapesquisa.com.br ESQUEMA EXTERNO DE UM MICROCOMPUTADOR Agora que

Leia mais

Programação de Sistemas

Programação de Sistemas Programação de Sistemas Introdução à gestão de memória Programação de Sistemas Gestão de memória : 1/16 Introdução (1) A memória central de um computador é escassa. [1981] IBM PC lançado com 64KB na motherboard,

Leia mais

NVIDIA GeForce Experience

NVIDIA GeForce Experience NVIDIA GeForce Experience DU-05620-001_v02 outubro 8, 2012 Guia do usuário CONTEÚDO 1 NVIDIA GeForce Experience Guia do usuário... 1 Sobre o GeForce Experience... 1 Instalação e configuração do GeForce

Leia mais

Europass Curriculum Vitae

Europass Curriculum Vitae Europass Curriculum Vitae Personal information Surname(s) / First name(s) Address(es) Custódio, Jorge Filipe Telephone(s) +351 919687707 Email(s) Personal website(s) Nationality(-ies) Rua Francisco Pereira

Leia mais

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow

Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Uma Arquitetura de Linha de Produto Baseada em Componentes para Sistemas de Gerenciamento de Workflow Itana M. S. Gimenes 1 itana@din.uem.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior

Leia mais

Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET

Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET Hardware de Computadores Questionário II 1. A principal diferença entre dois processadores, um deles equipado com memória cache o

Leia mais

Qual é o melhor? Há um ano, todas as principais

Qual é o melhor? Há um ano, todas as principais Comparativo dos sistemas de arquivos para Linux CAPA Qual é o melhor? Será que os novatos Btrfs e Ext4 superam os sistemas de arquivo tradicionais do Linux? por Marcel Hilzinger Há um ano, todas as principais

Leia mais

Categorias de Padrões

Categorias de Padrões Categorias de Padrões Padrão Arquitetural ou Estilo Arquitetural Padrão de Design (Design Patterns) Idiomas Categorias de Padrões ESTILOS ARQUITETURAIS PADRÕES DE DESIGN IDIOMAS Padrões de Design Os subsistemas

Leia mais

Capacidade = 512 x 300 x 20000 x 2 x 5 = 30.720.000.000 30,72 GB

Capacidade = 512 x 300 x 20000 x 2 x 5 = 30.720.000.000 30,72 GB Calculando a capacidade de disco: Capacidade = (# bytes/setor) x (méd. # setores/trilha) x (# trilhas/superfície) x (# superfícies/prato) x (# pratos/disco) Exemplo 01: 512 bytes/setor 300 setores/trilha

Leia mais

Módulo 4: Processos. Conceito de Processo. Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos

Módulo 4: Processos. Conceito de Processo. Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos Módulo 4: Processos Conceito de Processo Escalonamento de processos Operações sobre processos Processos cooperantes Comunicação entre processos 4.1 Conceito de Processo Um Sistema Operacional executa uma

Leia mais

ÁREA: CV ( ) CHSA ( ) ECET ( )

ÁREA: CV ( ) CHSA ( ) ECET ( ) ADAPTAÇÃO E INTEGRAÇÃO DO PROCESSADOR RISCO A UMA ARQUITETURA MULTI-CORE PARA SISTEMAS EMBARCADOS DE PROPOSITO GERAL Laysson Oliveira Luz (Bolsista PIBIC/CNPq), Ivan Saraiva Silva (Orientador, Departamento

Leia mais

Fault-tolerant virtual cluster experiments on federated sites using BonFIRE. Grupo: Edgar Oliveira, E8385 Pedro Jesus, M6369

Fault-tolerant virtual cluster experiments on federated sites using BonFIRE. Grupo: Edgar Oliveira, E8385 Pedro Jesus, M6369 Fault-tolerant virtual cluster experiments on federated sites using BonFIRE Grupo: Edgar Oliveira, E8385 Pedro Jesus, M6369 O Problema: A falha dos sites na Cloud e a variabilidade da performance das máquinas

Leia mais

Avaliação de Desempenho de Sistemas Computacionais

Avaliação de Desempenho de Sistemas Computacionais Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Departamento de Sistemas de Computação Avaliação de Desempenho de Sistemas Computacionais Aula 3 Marcos José Santana Regina Helena

Leia mais

Relatório de Pesquisa

Relatório de Pesquisa Relatório de Pesquisa A Vantagem da Virtualização de Mainframe: Como Economizar Milhões de Dólares Utilizando um IBM System z como um Servidor em Nuvem Linux Sumário Executivo Os executivos de TI (Tecnologia

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Prof. Jó Ueyama Apresentação baseada nos slides da Profa. Dra. Kalinka Castelo Branco, do Prof. Dr. Antônio Carlos Sementille, da Profa. Dra. Luciana A. F. Martimiano e nas transparências

Leia mais

Módulo 4: Processos. Conceito de Processo. Diagrama de Estados de Processos. Estados de Processo

Módulo 4: Processos. Conceito de Processo. Diagrama de Estados de Processos. Estados de Processo Módulo 4: Processos Conceito de Processo Conceito de Processo Escalonamento de Processos Operações com Processos Processos Cooperativos Comunicação entre Processos Um sistema operacional executa uma variedade

Leia mais

4 Computação Paralela 4.1. Introdução

4 Computação Paralela 4.1. Introdução 4 Computação Paralela 4.1. Introdução Nos últimos anos observa-se uma tendência cada vez maior do aumento da demanda computacional na resolução de grandes problemas. Exemplos de aplicações que exigem alto

Leia mais

SIS17 - Arquitetura de Computadores

SIS17 - Arquitetura de Computadores SIS17 - Arquitetura de Computadores Organização Básica B de Computadores (Parte I) Organização Básica B de Computadores Composição básica b de um Computador eletrônico digital Processador Memória Memória

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Nesse capítulo, apresentamos os trabalhos relacionados ao GridFS, entrando em mais detalhes sobre os sistemas citados durante a introdução e realizando algumas considerações sobre

Leia mais

Prof. Sandrina Correia

Prof. Sandrina Correia Tecnologias de I informação de C omunicação 9º ANO Prof. Sandrina Correia TIC Prof. Sandrina Correia 1 Objectivos Definir os conceitos de Hardware e Software Identificar os elementos que compõem um computador

Leia mais

Árvores Binárias de Busca

Árvores Binárias de Busca Árvores Binárias de Busca Uma Árvore Binária de Busca T (ABB) ou Árvore Binária de Pesquisa é tal que ou T = 0 e a árvore é dita vazia ou seu nó contém uma chave e: 1. Todas as chaves da sub-árvore esquerda

Leia mais