As arquiteturas de CPU são tendenciosas para tempos de execução processuais?


12

Há alguma alteração que possa ser feita nas CPUs para que elas tenham um desempenho melhor em tempos de execução simultâneos como o Rust? Por exemplo, há alterações nas implementações de previsão de ramificação ou nos tamanhos de cache que ajudariam nos tempos de execução simultâneos?

Tenho a impressão de que os designs atuais de CPU podem ser otimizados mais para tempos de execução procedimentais como C. Se, em vez disso, otimizássemos para tempos de execução simultâneos, como as CPUs seriam diferentes?

Por exemplo, a predição de ramificações foi implementada com base em generalizações desenhadas em trabalhos de pesquisa analisando códigos de procedimentos. Gostaria de saber se a abstração de simultaneidade adicionará um conjunto de trabalho significativo ao tempo de execução que afeta negativamente os algoritmos de previsão de ramificação existentes. Por exemplo, prever em um loop for é uma coisa, mas quando o destino da ramificação é sempre uma parte nova da memória (gráfico, texto, etc.), sempre haverá uma falta de cache e nunca haverá ramificação história para isso - porque ainda não o tocaram.

Essa provavelmente é uma pergunta boba, porque o conteúdo, embora possa sempre estar na RAM, será ramificado para uma ordem de magnitude menor do que será usado (depois de carregado no cache) ... mas ainda assim, deve ser um limite temporal observável para os contextos armazenados nos preditores de cache e ramificação em um tempo de execução processual, que se manifestariam como um limite de abstração em um ambiente mais paralelo. Então, eu estou pensando ... Esses limites foram observados? Algum trabalho de pesquisa analisou isso?

As arquiteturas de CPU são tendenciosas em relação ao código processual sobre o código simultâneo; ou as CPUs modernas são de uso geral suficiente para que uma linguagem altamente concorrente não sofra?


2
Você já olhou a literatura em torno da arquitetura Itanium (IA-64)? Foi projetado com grandes sonhos de ultraparalelismo, mas as pessoas não conseguiram criar compiladores que tirassem proveito dos recursos da CPU, e o software não teve um desempenho tão bom, afinal.
Gilles 'SO- stop be evil'

@Gilles sim. Embora uma pergunta diferente, essa seja realmente uma observação interessante - talvez o paralelismo incorporado ao Itanium seja mais adequado para as linguagens concorrentes modernas?
paIncrease 9/09/15

@Gilles: E da mesma forma, a nova arquitetura Mill parece ter sido construída com paralelismo e opções de baixo custo em mente. Por exemplo, usando um único espaço de endereço virtual para todos os "processos", ele empurra o TLB entre o último nível de cache e os controladores de dispositivo (consulte o slide 49 de millcomputing.com/docs/memory ).
Matthieu M.

1
O @pedAntic Rust que precisa de um tempo de execução é um equívoco fácil de ser feito: chat.stackoverflow.com/transcript/message/24171983#24171983 . Sua pergunta parece apoiar esse equívoco, o que não é bom para Rust.
ArtemGr 11/09/2015

1
@pedAntic Veja, o Rust teve um tempo de execução simultâneo (para rosqueamento verde), mas não possui mais. No momento, o Rust está amplamente na mesma liga que o C em relação ao perfil de desempenho de simultaneidade. A única diferença de C é que a análise estática no Rust torna a simultaneidade principalmente segura.
ArtemGr 11/09/2015

Respostas:


1

Provavelmente, as arquiteturas modernas de computadores são projetadas com o objetivo de melhorar a qualidade do código gerado pelos compiladores contra um orçamento de custo na área da matriz e na energia utilizada. As bibliotecas de tempo de execução são apenas uma instância específica do código compilado que precisa ser executado de maneira eficiente.

Por muito tempo, o idioma de destino para a maioria das arquiteturas tem sido o idioma "C". Isso reflete as demandas modestas que essa linguagem faz em seu hardware e o fato de ter se tornado uma linguagem de programação de sistemas quase universal (Sorry Rust and Go, você ainda tem um longo caminho a percorrer para vencer C).

Uma conseqüência disso parece ser que novas linguagens geralmente são definidas em termos de semântica equivalente em C, apenas para evitar a necessidade de recursos de processador que provavelmente estão ausentes nos computadores atuais.

A recompensa para um processador que combina bem com os compiladores modernos é que o código desses compiladores funciona bem e que o processador tem pelo menos uma chance de ser competitivo. O custo da falha aqui condena o processador antes que ele possa começar. Apenas dois exemplos negativos incluem o iAPX-432 e o Itanium, ambos da Intel. Ambos tinham um relacionamento muito ruim com seus compiladores (Ada e C, respectivamente), com o fracasso dos produtos se transformando em um jogo de culpa entre silício e software.


0

Sem dúvida sim.

Em particular, o modelo de comunicação implícito em C99 é de memória compartilhada. Idiomas simultâneos mais avançados têm modelos de comunicação mais avançados, como canais de passagem de mensagens (como no Rust).

As arquiteturas modernas de CPU têm suporte explícito de hardware para memória compartilhada. Em particular, protocolos de coerência de cache como o MESI são implementados em portas e fios reais. Não há suporte real para a passagem de mensagens entre processos, mesmo que a idéia de passagem de mensagens não seja estranha para as CPUs. Os modernos barramentos PCI-e até emulam a memória compartilhada usando a passagem de mensagens, enquanto os processos da CPU precisam emular a passagem de mensagens usando a memória compartilhada!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.