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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho

Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho Avaliação do Uso de Xen em Ambientes de Computação de Alto Desempenho Márcio Parise Boufleur Guilherme Piegas Koslovski Andrea Schwertner Charão LSC - Laboratório de Sistemas de Computação UFSM - Universidade

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

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

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

Weather Search System

Weather Search System Weather Search System PROJECTO DE COMPUTAÇÃO EM NUVEM RELATÓRIO Grupo 2 Gonçalo Carito - Nº57701 Bernardo Simões - Nº63503 Guilherme Vale - Nº64029 Índice Weather Search System...1 1. A Solução Implementada...3

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

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

William Stallings Arquitetura e Organização de Computadores 8 a Edição

William Stallings Arquitetura e Organização de Computadores 8 a Edição William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 7 Entrada/saída Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Problemas de entrada/saída Grande variedade

Leia mais

7 Processamento Paralelo

7 Processamento Paralelo 7 Processamento Paralelo Yes, of course, who has time? Who has time? But then if we do not ever take time, how can we ever have time? (The Matrix) 7.1 Introdução Classificação de Sistemas Paralelos Diversas

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

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

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

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Aplicações. Sistema Operacional Hardware. Os sistemas de computadores são projetados com basicamente 3 componentes: Máquinas Virtuais e Emuladores

Aplicações. Sistema Operacional Hardware. Os sistemas de computadores são projetados com basicamente 3 componentes: Máquinas Virtuais e Emuladores Máquinas Virtuais e Emuladores Marcos Aurelio Pchek Laureano Sistemas de Computadores Os sistemas de computadores são projetados com basicamente 3 componentes: hardware sistema operacional aplicações Sistemas

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

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

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

Aula 04 A. Barramentos. Prof. Ricardo Palma

Aula 04 A. Barramentos. Prof. Ricardo Palma Aula 04 A Barramentos Prof. Ricardo Palma Definição Em ciência da computação barramento é um conjunto de linhas de comunicação que permitem a interligação entre dispositivos, como o CPU, a memória e outros

Leia mais

OpenGL. Uma Abordagem Prática e Objetiva. Marcelo Cohen Isabel Harb Manssour. Novatec Editora

OpenGL. Uma Abordagem Prática e Objetiva. Marcelo Cohen Isabel Harb Manssour. Novatec Editora OpenGL Uma Abordagem Prática e Objetiva Marcelo Cohen Isabel Harb Manssour Novatec Editora Capítulo 1 Introdução A Computação Gráfica é uma área da Ciência da Computação que se dedica ao estudo e ao desenvolvimento

Leia mais

Uma Arquitetura Distribuída de Hardware e Software para Controle de um Robô Móvel Autônomo

Uma Arquitetura Distribuída de Hardware e Software para Controle de um Robô Móvel Autônomo Uma Arquitetura Distribuída de Hardware e Software para Controle de um Robô Móvel Autônomo rbritto@dca.ufrn.br Orientador: Adelardo A. D. Medeiros adelardo@dca.ufrn.br - Universidade Federal do Rio Grande

Leia mais

Introdução ao Processamento Paralelo

Introdução ao Processamento Paralelo Introdução ao Processamento Paralelo Prof. Rômulo Calado Pantaleão Camara Carga Horária: 2h/60h Introdução Crescente aumento de desempenho dos PCs (máquinas convencionais). Existem aplicações que requisitam

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

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

Cálculo Aproximado do número PI utilizando Programação Paralela

Cálculo Aproximado do número PI utilizando Programação Paralela Universidade de São Paulo Instituto de Ciências Matemáticas e de Computação Cálculo Aproximado do número PI utilizando Programação Paralela Grupo 17 Raphael Ferras Renan Pagaiane Yule Vaz SSC-0143 Programação

Leia mais

Maestro. Arthur Kazuo Tojo Costa 317497. Universidade Federal de São Carlos Campus Sorocaba Bacharelado em Ciência da Computação

Maestro. Arthur Kazuo Tojo Costa 317497. Universidade Federal de São Carlos Campus Sorocaba Bacharelado em Ciência da Computação Maestro Arthur Kazuo Tojo Costa 317497 Universidade Federal de São Carlos Campus Sorocaba Bacharelado em Ciência da Computação Introdução Sistema Operacional de Redes Detalhes do hardware Multiplexação

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

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

TECNÓLOGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PROGRAMAÇÃO DE COMPUTADORES I Aula 01: Conceitos Iniciais / Sistema Operacional

TECNÓLOGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PROGRAMAÇÃO DE COMPUTADORES I Aula 01: Conceitos Iniciais / Sistema Operacional TECNÓLOGO EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS PROGRAMAÇÃO DE COMPUTADORES I Aula 01: Conceitos Iniciais / Sistema Operacional O conteúdo deste documento tem por objetivo apresentar uma visão geral

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

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

FAT32 ou NTFS, qual o melhor?

FAT32 ou NTFS, qual o melhor? FAT32 ou NTFS, qual o melhor? Entenda quais as principais diferenças entre eles e qual a melhor escolha O que é um sistema de arquivos? O conceito mais importante sobre este assunto, sem sombra de dúvidas,

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

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

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

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

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto.

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Modelação, Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Test O Matic 10 de Maio de 2009 1 Índice 1 Índice... 1 2 Sumário...

Leia mais

Busca Estocástica Baseada em Planejamento para Maximizar Metas em Jogos de RTS

Busca Estocástica Baseada em Planejamento para Maximizar Metas em Jogos de RTS Busca Estocástica Baseada em Planejamento para Maximizar Metas em Jogos de RTS Autor:Thiago França Naves 1, Orientador: Carlos Roberto Lopes 1 1 Programa de Pós-Graduação em Ciência da Computação Universidade

Leia mais

PROCEDIMENTOS METODOLÓGICOS

PROCEDIMENTOS METODOLÓGICOS DEFINIÇÃO DE AMBIENTE COMPUTACIONAL DE ALTO DESEMPENHO PARA MINERAÇÃO DE INFORMAÇÃO EM BANCO DE DADOS ASTRONÔMICOS Murilo Moritz Parize 1 ; Marcelo Massocco Cendron 2 INTRODUÇÃO Com grandes avanços na

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

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo 4 PROCESSOS Os primeiros sistemas operacionais permitiam que apenas um processo fosse executado por vez. Dessa maneira, este processo tinha todo o sistema computacional a sua disposição. Os atuais sistemas

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

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

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

Sequenciamento dinâmico

Sequenciamento dinâmico Sequenciamento dinâmico João Canas Ferreira Outubro de 2004 Contém figuras de Computer Architecture: A Quantitative Approach, J. Hennessey & D. Patterson, 3 a. ed., MKP c JCF, 2004 AAC (FEUP/LEIC) Sequenciamento

Leia mais

28/9/2010. Paralelismo no nível de instruções Processadores superescalares

28/9/2010. Paralelismo no nível de instruções Processadores superescalares Arquitetura de Computadores Paralelismo no nível de instruções Processadores superescalares Prof. Marcos Quinet Universidade Federal Fluminense P.U.R.O. Processadores superescalares A partir dos resultados

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

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

Capítulo 4. MARIE (Machine Architecture Really Intuitive and Easy)

Capítulo 4. MARIE (Machine Architecture Really Intuitive and Easy) Capítulo 4 João Lourenço Joao.Lourenco@di.fct.unl.pt Faculdade de Ciências e Tecnologia Universidade Nova de Lisboa 2007-2008 MARIE (Machine Architecture Really Intuitive and Easy) Adaptado dos transparentes

Leia mais

Modelo Genérico de Módulo de E/S Grande variedade de periféricos

Modelo Genérico de Módulo de E/S Grande variedade de periféricos Conteúdo Capítulo 7 Entrada/Saída Dispositivos externos Módulos E/S Técnicas de E/S E/S Programada E/S Conduzida por interrupções Processamento de interrupções Controlador Intel 82C59A Acesso Directo à

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

Capítulo 8. Software de Sistema

Capítulo 8. Software de Sistema Capítulo 8 Software de Sistema Adaptado dos transparentes das autoras do livro The Essentials of Computer Organization and Architecture Objectivos Conhecer o ciclo de desenvolvimento da linguagem Java

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

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

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

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

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

CICS Resumo. Acerca deste resumo: Introdução (1-2) Arquitectura (3-4)

CICS Resumo. Acerca deste resumo: Introdução (1-2) Arquitectura (3-4) CICS Resumo Acerca deste resumo: Este é o resumo da matéria estudada para apresentar o sistema IBM CICS, o monitor transaccional mais utilizado. Cada secção diz respeito a um conjunto de acetatos que são

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

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

ZS Rest. Manual Avançado. Instalação em Rede. v2011

ZS Rest. Manual Avançado. Instalação em Rede. v2011 Manual Avançado Instalação em Rede v2011 1 1. Índice 2. Introdução... 2 3. Hardware... 3 b) Servidor:... 3 c) Rede:... 3 d) Pontos de Venda... 4 4. SQL Server... 5 e) Configurar porta estática:... 5 5.

Leia mais

Paralelização de Simuladores de Hardware Descritos em SystemC

Paralelização de Simuladores de Hardware Descritos em SystemC Paralelização de Simuladores de Hardware Descritos em SystemC 18 de maio de 2011 Roteiro Motivação Introdução à SLDL SystemC O Escalonador SystemC Simulação Paralela baseada em Eventos Discretos Suporte

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

Processadores clock, bits, memória cachê e múltiplos núcleos

Processadores clock, bits, memória cachê e múltiplos núcleos Processadores clock, bits, memória cachê e múltiplos núcleos Introdução Os processadores (ou CPUs, de Central Processing Unit) são chips responsáveis pela execução de cálculos, decisões lógicas e instruções

Leia mais

Informática. Aulas: 01 e 02/12. Prof. Márcio Hollweg. www.conquistadeconcurso.com.br. Visite o Portal dos Concursos Públicos WWW.CURSOAPROVACAO.COM.

Informática. Aulas: 01 e 02/12. Prof. Márcio Hollweg. www.conquistadeconcurso.com.br. Visite o Portal dos Concursos Públicos WWW.CURSOAPROVACAO.COM. Informática Aulas: 01 e 02/12 Prof. Márcio Hollweg UMA PARCERIA Visite o Portal dos Concursos Públicos WWW.CURSOAPROVACAO.COM.BR Visite a loja virtual www.conquistadeconcurso.com.br MATERIAL DIDÁTICO EXCLUSIVO

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

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