Como já foi indicado acima, a conversão de dados para redes heterogéneas T805-C40 é efectuada pelas macros ieee2ti e ti2ieee que operam sobre vectores de números de vírgula flutuante. Como a versão actual do SPAM suporta apenas diferenças na representação de dados entre a representação de números de vírgula flutuante de 32 bits, segundo a norma IEEE 754, a qual é a adoptada pela maior parte das famílias de processadores comerciais, e o formato interno de vírgula flutuante do C4x, ou formato C4f para abreviar, as macros acima mencionadas são relativamente simples de implementar e de rápida execução. No entanto, se se pretender generalizar o ambiente de comunicações para suportar qualquer tipo de nó, será conveniente usar uma norma de transporte de dados comum, mais geral, que suporte conversões entre outros tipos de dados, como a XDR. De facto, esta norma é usada para transportar dados entre nós no âmbito do PVM. No caso do ambiente MPI, esta norma já é opcional, podendo ser utilizadas funções de conversão especificas para o tipo de nós utilizado, como é o caso do SPAM.
No caso do SPAM a conversão de dados é efectuada entre uma instância Prg (x) alocada num C4x e o ambiente de comunicações E / S (x) pelos guardas de entrada. Se bem que não seja obrigatório, existe toda a conveniência em efectuar as conversões num C4x, pois este processador dispõe de instruções em código nativo dedicadas para tal. Deste modo as conversões serão efectuadas o mais eficientemente possível.
Assim os dados de vírgula flutuante são transportados no formato IEEE 754 e só em instâncias da aplicação alocadas em C4x é que tomam o formato C4f, como mostra a seguinte figura.
No entanto esta estratégia de conversão implica que os números de vírgula flutuante transferidos entre dois C40 tem de ser convertidos entre os formatos C4f e IEEE 754 na origem e efectuar a conversão contrária no destino. Esta limitação é necessária, pois no caso de difusão de mensagens numa rede heterogénea, estas serão enviadas para processadores de famílias diferentes, de modo que é obrigatório que a mensagem seja transportada num formato que poderá ser descodificado por qualquer processador, tendo sido adoptado é o formato IEEE 754.
Fig. 4-20: Formato dos números de vírgula flutuante ao longo da rede
A implementação desta estratégia deve ser feita de modo a poupar os recursos do processador, bem como simplificar o código dos mecanismos de encaminhamento, de modo a evitar atrasos desnecessários nas comunicações.
Quanto à conversão para o formato C4f, é efectuada após o vector de dados ter sido recebido e colocado na área de memória que lhe está destinada, elemento a elemento, no próprio lugar, sem necessidade de recorrer a variáveis auxiliares.
C4f -> IEEE 754 IEEE 754 IEEE 754 -> C4f IEEE 754 E / S (0) Prg (0) IEEE 754 T805 E / S (1) Prg (1) IEEE 754 T805 E / S (x) Prg (x) C4f C40
Para simplificar a conversão contrária, isto é de um vector que será enviado de um C4x para a rede, pode-se recorrer a um algoritmo semelhante, ou seja efectuar a conversão do vector de dados para o formato IEEE 754, no lugar, e só depois enviar este para a rede. No entanto, muito provavelmente o vector armazenado no C4x será usado no futuro. Isto vai implicar que os elementos desse vector terão de ser transformados novamente na representação C4f. Tem- se assim uma conversão extra, que irá demorar o seu tempo. Seguidamente encontra-se representada a sequência de operações e o tempo requerido por este algoritmo:
Operação Tempo de execução (µs)
por número de vírgula flutuante
conversão de C4f para IEEE 754 1,994
Comunicação externa uni-direccional T8-C40 (Qeu) 4,896
conversão de IEEE 754 para C4f 1,731
Tempo total por número de vírgula flutuante 8,621
algoritmo 4-8: Envio de um vector de números flutuantes para uma rede heterogénea a partir de um C40
Como indicado, o tempo perdido na reconversão do vector para o formato C4f é de 1,731 µs por cada número de vírgula flutuante, o que representa um acréscimo de 25% no custo da comunicação.
Fig. 4-21: Conversão do entre formatos de vírgula flutuante usando um buffer
Deste modo, para se obter uma maior eficiência na comunicação deve-se usar uma estratégia um pouco mais complexa. Como indicado na figura anterior, é possível eliminar a
E / S (x) Prg (x) C4f IEEE /54 buffer C40 Qiu Qeu Qeu
necessidade de reconversão, desde que uma cópia do vector a converter seja colocada num segmento de memória auxiliar, sobre a qual é operada a conversão.
O custo da reconversão pode ser assim trocado pelo custo da comunicação interna uni- direccional, que é bastante inferior, reduzindo-se o acréscimo ao custo da comunicação para apenas 4%. No entanto é necessário gastar memória para criar mais um buffer adicional, o qual deve ter o comprimento dos pacotes.
Operação Tempo de execução (µs)
por número de vírgula flutuante
Comunicação interna uni-direccional T8-C40 (Qiu) 0,283
conversão de C4f para IEEE 754 1,994
Comunicação externa uni-direccional T8-C40 (Qeu) 4,896
Tempo total por número de vírgula flutuante 7,173
algoritmo 4-9: Envio de um vector de números flutuantes para uma rede heterogénea a partir de um C40
Se bem que esta estratégia permita reduzir o tempo de conversão, requer mais memória interna do processador, a qual em alguns processadores não é abundante. Além disso a implementação desta estratégia requer algoritmos mais complexos e longos do que os apresentados anteriormente. Se por um lado algoritmos mais complexos requerem mais tempo para processamento, algoritmos mais longos requerem mais memória. De facto, se se considerar difusão de mensagens de um para todos, o tamanho máximo de um pacote PCM é bastante grande: 64 KBytes, para aumentar a eficiência. Usar um buffer com esta dimensão é impraticável. Uma forma de resolver a situação seria converter os pacotes PCM para séries de pacotes passantes com o comprimento PACKET_LEN, no entanto isto iria aumentar ainda mais a complexidade dos mecanismos de comunicação.
Deste modo, para não aumentar a complexidade dos mecanismos de comunicação, optou-se por manter a técnica indicada no algoritmo 4-8, a qual os algoritmos dos guardas de entrada já descritos seguem.
Finalmente é conveniente referir que o protocolo PCM suporta apenas dados inteiros ou vírgula flutuante. O campo MSG_FLT do descritor, isto é o bit 30 toma o valor 1 se os dados de uma mensagem forem números de vírgula flutuante e 0 se inteiros, de modo que as macros de conversão apenas operem sobre números de virgula flutuante, visto que a representação dos inteiros é comum a todos os processadores utilizados.