Por que uma linguagem de alto nível compilada e vinculada seria executada mais lentamente que o código Assembly / machine? [fechadas]

Question

Digamos que eu compile e conecte C em um formato de saída binário simples ou algum executável para rodar em uma máquina vazia. Se eu otimizasse e alimentasse o binário direto para a CPU na inicialização, por que o formato resultante levaria mais ciclos de clock de uma origem C compilada e vinculada do que apenas Assembly montado? O que quero dizer é que, se as mesmas instruções forem alimentadas e buscadas de algum formato binário, independentemente da origem, se o binário resultante produzir os mesmos códigos de operação de C, D, Assembly ou até mesmo escritos diretos (se possível), por que os programadores costumam dizer que o Assembly será sempre mais rápido?

Desculpe se não está claro, mas em geral, os mesmos opcodes obtidos não devem ter os mesmos ciclos de clock e recursos da CPU, independentemente da origem, se vinculados e / ou compilados / montados, se o arquivo binário contiver apenas as instruções necessárias (e um script de vinculador ou manipulador de formato de saída pode fazer isso para C ou tal, deve ser tão rápido).

    

Answer 1

Sua premissa é falha. Se você usasse uma linguagem de alto nível que fosse compilada em um binário simples com exatamente os mesmos opcodes que o assembler feito à mão, esse programa seria executado exatamente da mesma forma. O problema é que essas condições nunca acontecem realmente.

Todo programa C tem código de bootstrap no começo (antes de você chegar ao main), então imediatamente há opcodes extras. Se você chamar uma função, as convenções de chamada C podem ser menos otimizadas do que as chamadas de montagem especializadas, que podem variar de acordo com a função. Finalmente, os opcodes gerados por um compilador dentro de qualquer função são diferentes de hand-assembler; às vezes melhor e às vezes pior, dependendo da capacidade dos escritores do compilador versus o programador de montagem. Então, "montagem é sempre melhor" também não é verdade.

Por exemplo, um compilador pode desenrolar um loop para torná-lo mais rápido. No montador, você pode fazer a mesma coisa com uma macro; mas o programador da montagem iria a esse problema?

    

Answer 2

Um programa de montagem bem escrito será executado mais rapidamente do que um programa C comparável simplesmente porque o programa de montagem não terá todo o código clichê que o programa C usaria para salvar e restaurar o estado da CPU ou da pilha.

    

Answer 3

Mais rápido é bom em algoritmos. Códigos embutidos como inserções no montador serão melhores e mais rápidos. Se você pode gastar tempo ilimitado em busca de instruções não documentadas, por exemplo, verá o cálculo instantâneo de somas quadráticas em uma ação apresenta e outras esquisitices ... Tudo depende da compatibilidade e durante a escrita de programas. O segundo ponto multi-core e multi-processador, o algoritmo deve ser bom para a execução simultânea de vários núcleos de processador. Existe tecnologia suficiente quando as ações são feitas antecipadamente. Tal como pesquisa de texto completo - trabalho longo, mas você vê resultados instantâneos dentro de frações de segundo. Há uma coisa que é falsamente tomada para o desempenho do software - a capacidade de resposta do sistema. Você pode fazer o trabalho de forma assíncrona ou em parte, para satisfazer a consulta de um usuário gradualmente, muitas vezes fisicamente incapaz de processar imediatamente a quantidade de informações cedidas. Ou simplesmente perder interesse com base em alguns critérios. Você, por sua vez, economiza os recursos do desempenho e da capacidade de resposta do sistema.

Bem, não há nada melhor do que testar para uma situação específica e boas bibliotecas)).

    

Answer 4

Por muito tempo agora, os compiladores superam rotineiramente os programadores de montagem competentes. Para trechos de código muito curtos e extremamente críticos, um programador especialista pode fazer melhor se ajustar com cuidado por alguns dias de trabalho.