para Programa¸c˜ao Paralela
A maquina SDF [43] pode ser considerada uma m´aquina dataflow h´ıbrida, pois ela permite a compila¸c˜ao de blocos que ser˜ao executadas em uma m´aquina de Von Neumann, mas que ser˜ao disparados segundo o modelo dataflow. Por outro lado, a arquitetura TRIPS [44] ´e ortogonal `a SDF. A execu¸c˜ao de blocos ´e disparada segundo o modelo de Von Neumann, mas, dentro de cada bloco, a execu¸c˜ao segue o modelo dataflow. A execu¸c˜ao de programas no modelo TRIPS requer um hardware dataflow.
A BMDFM [45] ´e uma m´aquina virtual h´ıbrida que suporta a descri¸c˜ao de pro- gramas tanto em granularidade fina quanto grossa. C´odigo de granularidade fina ´e escrito na linguagem nativa da m´aquina virtual, uma linguagem funcional baseada em LISP. As instru¸c˜oes da m´aquina virtual podem ser alternadas com instru¸c˜oes personalizadas, escritas em C, como as super-instru¸c˜oes da Trebuchet. Segundo a terminologia do BMDFM, as instru¸c˜oes personalizadas s˜ao chamadas de instru¸c˜oes
de granularidade grossa. A BMBFM usa diversos daemons correspondentes aos di- ferentes componentes do escalonador dinˆamica. O uso de uma linguagem funcional para descri¸c˜ao de programas para a BMDFM ´e um ponto negativo do trabalho.
O Program Demultiplexing [7] ´e um paradigma de execu¸c˜ao onde m´etodos ou fun¸c˜oes s˜ao demultiplexados para serem executados concorrentemente com o resto do programa, de acordo com o modelo dataflow. O c´odigo fonte das aplica¸c˜oes ´e modificado para permitir a execu¸c˜ao de fun¸c˜oes em outros n´ucleos de processamento antes do seu ponto de chamada. Sendo assim, resultados s˜ao produzidos e recebidos pelo fluxo de controle principal para serem utilizados quando o ponto de chamada for atingido. Os operandos de entrada (conjunto de leitura) podem ser especulados para permitir a execu¸c˜ao demultiplexada com maior antecedˆencia. A implementa- ¸c˜ao demanda mudan¸cas no protocolo de coerˆencia de cache, estruturas adicionais para armazenar resultados de execu¸c˜oes especulativas, bem como ferramentas para selecionar e demultiplexar os m´etodos. Embora seja uma solu¸c˜ao interessante, ela depende, em muitos casos, da especula¸c˜ao para conseguir demultiplexar os m´etodos com antecedˆencia suficiente para que os resultados possam estar prontos nos pontos de chamada. Al´em disso a dependˆencia de suporte de hardware faz com que este m´etodo n˜ao seja uma realidade para os usu´arios em um futuro pr´oximo.
O DDMCPP ´e um projeto que se baseia em anota¸c˜ao de c´odigo para paraleliza¸c˜ao [46]. O DDMCPP ´e um pr´e-processador para o modelo Data Driven Multithreading [47], que suporta dataflow dinˆamico. O modelo provˆe unidades de sincroniza¸c˜ao de threads, que tamb´em s˜ao respons´aveis pelo escalonamento. O DMCPP disponibiliza um conjunto de pragmas para a defini¸c˜ao de threads e a descri¸c˜ao dos operandos trocados entre elas, como no modelo dataflow, al´em de pragmas para descri¸c˜ao de la¸cos do tipo for e opera¸c˜oes de redu¸c˜ao. O pr´e-processador transforma o c´odigo para incluir a troca de operandos entre threads e opera¸c˜oes de sincroniza¸c˜ao. No entanto, este modelo n˜ao ´e muito flex´ıvel. Como o DDMCPP n˜ao ´e um compilador e o ambiente de execu¸c˜ao n˜ao ´e uma arquitetura dataflow, n˜ao h´a a descri¸c˜ao de la¸cos usando instru¸c˜oes de granularidade fina em fluxo de dados (como uso de instru¸c˜oes de incremento de r´otulo de itera¸c˜ao). O ´unico tipo de la¸co dispon´ıvel ´e do tipo for, e o dataflow dinˆamico ´e garantido com a cria¸c˜ao de novos contextos no ambiente de execu¸c˜ao (semelhante a uma chamada de fun¸c˜ao). A cria¸c˜ao de contextos ´e inclu´ıda pelo pr´e-processador. Al´em disto, n˜ao ´e feita uma compara¸c˜ao de desempenho com outras ferramentas consagradas de programa¸c˜ao paralela.
O HMPP [48] ´e um ambiente heterogˆeneo de programa¸c˜ao paralela para multi- cores que permite a integra¸c˜ao de diferentes aceleradores em hardware de maneira simples e preservando c´odigo legado. ´E provido um ambiente de execu¸c˜ao, um con- junto de diretivas de compila¸c˜ao, chamadas de codelets, que podem ser executadas em GPFPU, FPGAS, m´aquinas remotas (com MPI ) ou o CPU local. Os Codelets
s˜ao fun¸c˜oes puras, sem efeitos colaterais (n˜ao afetam a mem´oria global ou arquivos). M´ultiplos Codelets, cada um desenvolvido para um tipo de hardware diferente, po- dem existir e o ambiente de execu¸c˜ao vai escolher qual Codelet ser´a executado, de acordo com a disponibilidade dos recursos e com as diretivas de compila¸c˜ao previa- mente definidas. O ambiente de execu¸c˜ao tamb´em ´e respons´avel pelas transferˆencias de dados de/para os componentes de hardware envolvidos na computa¸c˜ao. A ideia de um ambiente heterogˆeneo ´e interessante, no entanto, o problema do modelo de programa¸c˜ao paralela ainda precisa ser tratado. A programa¸c˜ao continua sendo feita com os modelos tradicionais.
O sistema Galois [49–51] ´e um sistema de paraleliza¸c˜ao otimista baseado em objetos, para aplica¸c˜oes irregulares. Ele ´e composto por: (i) constru¸c˜oes sint´aticas para empacotar paralelismo otimista com itera¸c˜oes sobre conjuntos ordenados e de- sordenados, (ii) um sistema de execu¸c˜ao para detectar acessos inseguros `a mem´oria compartilhada e executar as opera¸c˜oes de recupera¸c˜ao necess´arias e (iii) verifica¸c˜oes de m´etodos em bibliotecas de classes. Em vez de rastrear os endere¸cos acessados pelo c´odigo otimista, o Galois rastreia viola¸c˜oes de semˆantica em alto n´ıvel em tipos de dados abstratos. Para cada m´etodo que realiza acessos `a mem´oria comparti- lhada, o programador precisa descrever quais m´etodos (e em quais circunstˆancias) podem ser executados de forma comutativa sem conflitos. O Galois tamb´em intro- duz alternativas `as verifica¸c˜oes de comutatividade, pois estas podem ser custosas [50]. Dados compartilhados s˜ao particionados e atribu´ıdos aos diferentes n´ucleos de processamento e o sistema monitora se parti¸c˜oes est˜ao sendo “tocadas” por threads concorrentes (o que acarretaria em um conflito). Indiferente do m´etodo de detec- ¸c˜ao usado, o programador precisa descrever um m´etodo inverso para cada m´etodo que acessa objetos compartilhados. Os m´etodos inversos s˜ao executados no caso de um rollback. O sistema de execu¸c˜ao ´e encarregado de detectar conflitos, chamar os m´etodos inversos e comandar a re-execu¸c˜ao. Embora seja um sistema bastante ino- vador, o Galois exp˜oe ao programador alguns detalhes do modelo de especula¸c˜ao, ao demandar a descri¸c˜ao dos m´etodos inversos e das rela¸c˜oes de comutatividade. Al´em disto, foi mostrado que especula¸c˜ao baseada em verifica¸c˜ao de comutatividade pode ser custosa [50]. Foi ent˜ao sugerido um mecanismo de parti¸c˜ao de dados e a modi- fica¸c˜ao do mecanismo de especula¸c˜ao para controlar o acesso a blocos de mem´oria, inv´es de objetos em alto n´ıvel. No entanto, os m´etodos inversos para fazer opera¸c˜oes de rollback continuam existindo.