O HPE (Hash Programming Environment)

A implementação de referência do modelo Hash é o HPE36 (Hash Programming Environment) (JUNIOR et al., 2007; CARVALHO-JUNIOR; REZENDE, 2013), desenvolvido para construção e execução de programas paralelos construídos pela composição de componentes voltados a plataformas de cluster computing. A fim de permitir uma prototipagem mais rápida de sua implementação, bem como maior portabilidade, seus componentes são desenvolvidos sobre a plataforma CLI (Common Language Infrastructure) (ECMA International, 2006), cujas 34 _{Domain Specific Language}

35 _{Single Component Multiple Data}

principais implementações são o Mono e o .NET.

O HPE é compatível com o modelo CCA (CARVALHO-JUNIOR; CORREA, 2010). Comparado com outros frameworks CCA, o HPE oferece total expressividade para descrever algoritmos de computação paralela e encapsulá-los em componentes, suportando o padrão MCMD (Multiple Component Multiple Data). Apresenta pouca sobrecarga inerente de ligação entre os componentes (CARVALHO-JUNIOR; REZENDE, 2013).

Do ponto de vista do usuário, o HPE é composto por instâncias de três elementos arquiteturais: o Frontend, o Core e um conjunto de Backend ’s. O Frontend é o ambiente respon- sável por oferecer uma interface através da qual desenvolvedores possam construir configurações de componentes, representando aplicações finais ou outros componentes, e gerenciar o seu ciclo de vida, registrando componentes em uma biblioteca acessível através do serviço do Core e executando aplicações em plataformas de computação paralela (clusters) disponíveis, cada qual acessível através de um serviço Backend.

As interfaces do Core e do Backend com o Frontend são implementadas usando a tecnologia de serviços web37, permitindo transparência de localização, enquanto o Frontend foi implementado como um plugin para a plataforma Eclipse, capaz de conectar-se ao serviço Core e a algum serviço Backend cada vez que deseja executar aplicações. O Backend é implementado como uma plataforma de componentes compatível com o padrão CCA sobre a plataforma de execução virtual Mono, do padrão CLI (Common Language Infrastructure) (ECMA International, 2006). Embora o Mono suporte várias linguagens de programação, atualmente componentes do HPE devem ser escritos na linguagem C#, a principal dentre as linguagens de plataformas de execução virtual que seguem o padrão CLI, cujos principais representantes são .NET Microsoft (2012) e o próprio Mono.

O HPE suporta as seguintes espécies de componentes: qualificadores, platafor- mas, ambientes, computações, estrutura de dados, sincronizadores, topologias e aplicações (CARVALHO-JUNIOR et al., 2007). Elas representam unidades de composição de programas paralelos por passagem de mensagens, ou seja, programas tipicamente construídos usando MPI (DONGARRA et al., 1996), a interface de programação por passagem de mensagens mais difun- dida e expressiva. Assim, no HPE podem ser construídos os mesmos programas que podem ser construídos em MPI, porém fatorado em componentes, sem perda significativa de desempenho (CARVALHO-JUNIOR; REZENDE, 2013).

Figura 2 – Aplicações Simuladas SP e BT do NAS Parallel Benchmarks no HPE y z x y z x

SP and BT are distinguished by their implementations of Solver

for each axis (x, y, z)

by the current value for the subtypes of Solver defined context parameter solver <<component>> <<component>> ** * * ** * ** * ** * ** ** * ** * ** * ** * ** * ** * ** * ** * ** * ** * ** x y z x y z x y z x y z x y z x y z <<component>> <<component>> Timer LHSInit Initialize ExactRHS MultiPartition CopyFaces ComputeRHS Solver Solver Solver Add Verify ADI ErrorNorm RHSNorm Ring Ring Ring ProblemData MultiPartitionCells <<component>> x y z <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>> <<component>>

ADI_Solver3D [ class = C:Class,

method = S:SolvingMethod ] problem_data cells_config y z x initialize data_partition exact_rhs compute_rhs copy_faces rhs_norm verify error_norm add copy_faces z_solve x_solve y_solve adi sp/bt lhsinit timer CopyFaces

Fonte: (CARVALHO-JUNIOR; REZENDE, 2013)

Uma dos principais aspectos do projeto da plataforma HPE é a sua estratégia de resolução de componentes, baseada no sistema de tipos Hash Type System (HTS) (CARVALHO- JUNIOR et al., 2016). No HPE, uma aplicação é um componente da espécie aplicação que orquestra seus componentes aninhados a fim de implementar o interesse da aplicação. Ao submeter uma aplicação para execução em um cluster, através de um serviço Backend, os componentes da aplicação são recursivamente resolvidos, implantados e instanciados a partir dos serviços do Core. Para cada componente, podem existir uma ou mais implementações. A estratégia de resolução é responsável pela seleção da implementação desenvolvida levando em consideração o maior número de características inerentes à arquitetura do cluster alvo, uma vez que tal componente é aquele que, teoricamente, é capaz de melhor explorar o desempenho do computador paralelo.

A Figura 2 ilustra a arquitetura de componentes de uma aplicação real implementada sobre o HPE com o propósito de avaliar o seu desempenho comparado a uma versão monolítica (CARVALHO-JUNIOR; REZENDE, 2013). Trata-se das aplicações simuladas SP e BT do NAS Parallel Benchmarks (NPB), um conjunto de 8 programas, incluindo 3 kernels e 5 aplicações simuladas, desenvolvido pelo Centro de Supercomputação Avançada da NASA, agência especial do EUA, para avaliar o desempenho de plataformas de computação paralela na execução de aplicações de dinâmica dos fluidos, com versões em várias linguagens de programação (C, Fortran, Java, C#) e usando diferentes modelos e interfaces de programação paralela (OpenMP,

HPF, Java Threads, MPI) (Bailey et al., 1991). Os resultados desse trabalho constituem forte evidência de que:

• o HPE não introduz sobrecarga de desempenho inerente comparado à mesma aplicação desenvolvida sem a abstração dos componentes;

• o HPE possui expressividade para representar padrões de computação paralela que possam ser programados com MPI;

• um montador de componentes e aplicações é capaz de abstrair-se dos detalhes de parale- lismo, encapsulados nos componentes mais básicos.

Além desses resultados, a abordagem de componentes permitiu identificar os interes- ses comuns entre as aplicações SP e BT e encapsulá-los em componentes de maneira que possam ser compartilhados entre as duas aplicações, sem redundância. Na versão original monolítica, não baseada em componentes, tais interesses estavam separadamente implementados no código fonte de cada aplicação, escondendo suas similaridades de implementação. O HPE permitiu ainda a separação de interesses não-funcionais, alguns dos quais transversais, tais como estratégias de distribuição de dados, suposições sobre classes de problemas, padrões de comunicação paralela, que não estavam, e não podiam ser, separados em procedimentos na versão original.