Especialistas em software ignoraram a economia do hardware
... ou "Moore estava certo e os dois estavam errados"
A maior coisa que foi esquecida neste debate foi o impacto da tecnologia e da economia de fabricação de CPU, impulsionada pelo tamanho reduzido dos transistores, conforme expresso na Lei de Moore (não é de surpreender que eles soubessem muito sobre o hardware da CPU, esses caras estudaram e debateram software, não Economia ou fabricação de CPU). Os custos fixos de fabricação que são amortizados sobre as CPUs (por exemplo, design ISA, design de CPU e instalações de produção de CPU) cresceram rapidamente, aumentando assim o valor das economias de escala; com os custos de CPU por unidade (em termos de "retorno do investimento" e "retorno do watt"), o custo de uma CPU não precisa ser amortizado por uma ampla seleção de funções para fornecer valor, portanto, a computação em produtos com função fixa explodiu; Os orçamentos de transistor de CPU cresceram exponencialmente,
1. A escala da CPU vence a diversidade da CPU
A importância das economias de escala fez com que os benefícios de um ISA / CPU direcionado para um mercado maior (portanto mais amplo) superasse os benefícios potenciais das escolhas de design que restringem o mercado para um ISA / CPU. Os sistemas operacionais podem abordar partes cada vez maiores do mercado por ISA / CPU suportado, portanto, há pouca necessidade (ou mesmo nenhuma) de exercícios de portabilidade para permitir que um ecossistema de sistemas operacionais prospere. O problema domina o alvo do ISA e da CPU tendem a ser tão amplos que se sobrepõem, portanto, para qualquer software além de um compilador, o tamanho dos exercícios de portabilidade também diminuiu. Indiscutivelmente, Torvalds e Tanenbaumsuperestimou a parte do design e implementação do kernel que agora precisa ser ISA ou mesmo específica da CPU. Como Tanenbaum descreveu, os kernels de sistemas operacionais modernos abstraem as distinções entre CPU e ISA. No entanto, o código específico da CPU / ISA nos sistemas operacionais modernos é muito menor que um microkernel. Em vez de implementar o gerenciamento / agendamento de interrupções, gerenciamento de memória, comunicação e E / S, esses bits não portáteis tratam apenas de uma pequena fração da implementação desses serviços, com a grande maioria da arquitetura dessas funções principais do sistema operacional sendo portáteis.
2. O código aberto venceu a batalha, mas perdeu a guerra
Mais economia para o dinheiro significa que uma parcela maior da computação é realizada por produtos de função fixa, onde a capacidade de modificar o produto não faz parte da proposta de valor para o cliente. Agora, ironicamente, o código aberto floresceu nesses dispositivos de função fixa, mas, na maioria das vezes, os benefícios dessas liberdades foram percebidos mais por quem fabrica os produtos do que pelos usuários finais (o que era verdade no mercado de software naquela época: Microsoft era um grande consumidor de software de código aberto, mas seus clientes não eram). Da mesma forma, alguém poderia argumentar que o código aberto lutou mais no espaço de desktop de uso geral do que em qualquer outro lugar, mas à medida que a computação na web e na nuvem cresceu, a computação de desktop foi cada vez mais usada para um propósito mais restrito (principalmente executando um navegador), com as demais funções em execução na nuvem (ironicamente, principalmente em plataformas de código aberto). Em resumo: o código aberto realmente possui o espaço de computação de uso geral, mas o mercado se tornou mais sofisticado; o empacotamento do produto de computação com menos frequência para na função de uso geral, mas continua com o produto destinado a funções fixas, onde grande parte da vantagem da computação de código aberto está em conflito com os objetivos do produto.
3. 2 n significa crescimento k fixo As economias não são importantes
O crescimento exponencial dos orçamentos dos transistores trouxe consigo a percepção de que o custo do orçamento dos transistores de uma arquitetura CISC é quase completamente fixo. A vantagem estratégica do RISC foi que ele moveu a complexidade do conjunto de instruções da CPU para o compilador (sem dúvida, em parte motivado pelo fato de que os escritores do compilador se beneficiaram muito menos dos ISA complexos do que os desenvolvedores humanos que codificam em montagem, mas os compiladores poderiam raciocinar com muito mais facilidade matematicamente sobre e, portanto, explorar, um ISA mais simples); a economia resultante do transistor poderia ser aplicada para melhorar o desempenho da CPU. A ressalva era que as economias no orçamento do transistor de um ISA mais simples eram principalmente corrigidas (e a sobrecarga no design do compilador também era principalmente corrigida). Embora esse impacto fixo tenha sido uma grande parte do orçamento naquela época, como se pode imaginar, são necessárias apenas algumas rodadas de crescimento exponencial para que o impacto se torne trivial. Esse impacto em rápido declínio, combinado com a crescente importância da monocultura de CPU acima mencionada, significou uma janela de oportunidade muito pequena para qualquer novo ISA se estabelecer. Mesmo onde os novos ISA obtiveram sucesso, os ISA modernos "RISC" não são os ISA ortogonais descritos pela estratégia RISC, pois o crescimento contínuo nos orçamentos dos transistores e a aplicabilidade mais ampla do processamento SIMD, em particular, incentivou a adoção de novas instruções ajustadas para funções específicas. Esse impacto em rápido declínio, combinado com a crescente importância da monocultura de CPU acima mencionada, significou uma janela de oportunidade muito pequena para qualquer novo ISA se estabelecer. Mesmo onde os novos ISA obtiveram sucesso, os ISA modernos "RISC" não são os ISA ortogonais descritos pela estratégia RISC, pois o crescimento contínuo nos orçamentos dos transistores e a aplicabilidade mais ampla do processamento SIMD em particular incentivaram a adoção de novas instruções ajustadas para funções específicas. Esse impacto em rápido declínio, combinado com a crescente importância da monocultura de CPU acima mencionada, significou uma janela de oportunidade muito pequena para qualquer novo ISA se estabelecer. Mesmo onde os novos ISA obtiveram sucesso, os ISA modernos "RISC" não são os ISA ortogonais descritos pela estratégia RISC, pois o crescimento contínuo nos orçamentos dos transistores e a aplicabilidade mais ampla do processamento SIMD em particular incentivaram a adoção de novas instruções ajustadas para funções específicas.
4. Simples: Separação de Preocupações. Complexo: separação do espaço de endereço.
O kernel moderno do Linux (junto com a maioria dos outros kernels) se encaixa na definição bastante flexível de um macrokernel e não na definição restrita de um microkernel. Dito isto, com sua arquitetura de driver, módulos carregados dinamicamente e otimizações de multiprocessamento que tornam as comunicações do espaço do kernel cada vez mais parecidas com a passagem de mensagens de um microkernel, sua estrutura se parece mais com um design de microkernel (como incorporado pelo Minix) do que com o design de macrokernel (como incorporado pelo design do Linux no momento da discussão). Como um design de microkernel, o kernel Linux fornece comunicação generalizada, agendamento, manipulação de interrupções e gerenciamento de memória para todos os outros componentes do SO; seus componentes tendem a ter estruturas distintas de código e dados. Enquanto os módulos são carregados dinamicamente, pedaços de código portátil fracamente acoplados, que se comunicam por meio de interfaces fixas, não empregam uma propriedade restante dos microkernels: eles não são processos de espaço do usuário. No final, a Lei de Moore garantiu que os problemas motivados por preocupações de hardware como portabilidade (uma preocupação da Tanenbaum) e desempenho (uma preocupação da Torvalds) diminuíssem, mas os problemas de desenvolvimento de software se tornaram de suma importância. As vantagens ainda não realizadas que uma separação de espaços de endereço poderia oferecer são superadas pela bagagem adicional imposta no software OS, devido a limitações de design e ao aumento da complexidade das interfaces de componentes. s A lei assegurava que os problemas motivados por preocupações de hardware como portabilidade (uma preocupação da Tanenbaum) e desempenho (uma preocupação da Torvalds) diminuíssem, mas as questões de desenvolvimento de software se tornaram de suma importância. As vantagens ainda não realizadas que uma separação de espaços de endereço poderia oferecer são superadas pela bagagem adicional imposta no software OS, devido a limitações de design e ao aumento da complexidade das interfaces de componentes. s A lei assegurava que os problemas motivados por preocupações de hardware como portabilidade (uma preocupação da Tanenbaum) e desempenho (uma preocupação da Torvalds) diminuíssem, mas as questões de desenvolvimento de software se tornaram de suma importância. As vantagens ainda não realizadas que uma separação de espaços de endereço poderia oferecer são superadas pela bagagem adicional imposta no software OS, devido a limitações de design e ao aumento da complexidade das interfaces de componentes.
Curiosamente, o que tem sido uma forte tendência é o surgimento do hipervisor, que, como os microkernels, abstrai o hardware. Alguns afirmam que os hipervisores são microkernels. A arquitetura do hipervisor é diferente, pois as responsabilidades que pertencem aos microkernels são tratadas pelos kernels "convidados", no topo, com os hypervisores multiplexados entre eles, e a abstração do hipervisor não é um espaço genérico de mensagens e endereços de memória, mas sim uma emulação de hardware predominantemente real.
Em conclusão: o futuro favorece aqueles que adotam semântica menos rigorosa
* .. ou "nitpickers são péssimos em prever o futuro"
Na prática, grande parte do acerto / errado no debate é uma questão de semântica (e isso era parte do que Torvalds estava discutindo e o IMHO Tanenbaum não conseguiu apreciar completamente). É difícil fazer definições precisas sobre o futuro, porque existem muitos fatores fora do argumento que podem surgir; semântica mais flexível significa que suas previsões são um alvo maior no alvo do que o outro, oferecendo chances muito melhores. Se você ignorar a semântica, os argumentos avançados por Torvalds e Tanenbaum estavam certos sobre muitas coisas e errados sobre muito pouco.
tl; dr
A maioria dos ISA não se encaixa na definição semântica de RISC, mas aproveita a maioria das vantagens de design que eram distintas das CPUs RISC na época; a quantidade de SO que é específica da CPU é menor do que Tanenbaum esperava, sem falar no Torvalds; o código aberto domina a computação de uso geral, mas agora os consumidores desse mercado são principalmente os que empacotam a computação em produtos com funções mais fixas, onde grande parte dos benefícios do software de código aberto não é alcançada; separar a função do SO nos espaços de endereço não provou ser benéfico, mas separar a função do SO no hardware "virtual". Se você quiser afirmar que suas previsões foram acertadas, deixe o máximo de espaço de manobras semântico possível, assim como o Sr. Torvalds.
PS Uma observação final irônica: Linus Torvalds é um dos mais fortes defensores de manter o máximo de novas funcionalidades possível no espaço do usuário e fora do kernel do Linux.