1

Não é bem o Assembly que otimizou, foi a capacidade do Chris Sawyer de fazer o Assembly bem feito. Ao contrário da crença popular, Assembly não dá performance sozinho. Especialmente hoje em dia é mais fácil conseguir melhor performance escrevendo em uma linguagem de mais alto nível que Assembly. Na época do Rollercoaster Tycoon estava no meio termo, os compiladores, especialmente de C estavam bem agressivos, mas não tanto quanto hoje.

Então não é questão de que agora o hardware ser melhor e não precisa baixar o nível, é que agora o nível mais alto costuma ser o mais otimizado. E nem entrei na questão de que a maioria das pessoas não fará um Assembly minimamente bom.

Não me surpreenderia que o OpenRCT tenha melhor performance ou menos uso do processador pelo menos em algumas partes. De qualquer forma, ele roda em máquinas bem antigas de boa.

Isso me lembra quem foi meu mentor e que ele tinha um sistema feito em Clipper, uma linguagem de script e que o software de folha de pagamento dele batia o líder de mercado que foi escrito no icônico Turbo Pascal que entraga performance que até C não entregava em alguns pontos. O segredo dele é que os cálculos primitivos eram feitos em Assembly. Quando precisou portar para Windows resolveu mudar tudo para C++, em vez de usar Clipper e Assembly. O resultado passou ser mais rápido que antes, mas só porque ele soube fazer direito em C++. E a conversão foi fácil porque criavamos código em Clipper já pensando que um dia será mudado para C ou C++.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

Carregando publicação patrocinada...
1

Deixa eu corrigí-lo: Clipper não é linguagem de Script, é de compilação nativa.
Você disse que o segredo do seu mentor era que os cálculos primitivos eram feitos em Assembly, nesse sistema feito em Clipper. Sim, era possível através de gerar um arquivo .OBJ a partir do código Assembly (.ASM) e linkar com o programa em Clipper com o Tlink por exemplo.
A parte que ficou sem coerência foi esse trecho, pois se você já havia afirmado antes que ele usava Clipper + Assembly, este trecho deu a me entender que ele não usava.

Quando precisou portar para Windows resolveu mudar tudo para C++, em vez de usar Clipper e Assembly

1

Você está enganado, mas pode me mostrar uma fonte que diga que Clipper é de compilação nativa. A linguagem ser de script e ter compilação nativa são ortogonais, ou seja, uma não elimina a outra. Ele gerava um bytecode (chamado de pcode pela Nantucket) que era colocado no .obj que tinha um pequeníssimo código nativo apenar para encapsular o pcode que era interpretado pela VM, esta sim era nativa (nem poderia ser diferente) em C e sempre igual, inclusive até o Summer 87 era usado o Lattice C e no 5 passou para o compilador da Microsoft.

A descompilação era feita em cima do pcode quando fizeram a engenharia reversa, e gerava um código muito próximo do real, especialmente quando usava apenas a sintaxe do Summer 87.

Funcionava assim desde sempre (Summer 85 - eu usei a primeira cópia vendida no Brasil) e no Aunm 86 começou ter a possobilidade real de usar códigos em C e ASM de forma coinsistente (na Winter 85 tinha algo, mas não edava para usar direito). O Visual Objetcs era nativo, mas nu nca me aprofundei compltamente para ver se n ão tinha uma VM em algumas situações. Ele nasceu morto.

Só para adintar, eu trabalhaei a vida toda com Clipper e Harbour (Harbour tem um experimento abandonado que compila para C e pode criar uma código nativo, mas o código é todo feito com chamadas diretas à vitual machine, o que o torna uma linguagem de script - poderia não ser). Eu semrpe estudei o que poucas pessoas estudavam (quase todo programador de Clipper era ruim, faiam suposições erradas, não entendiam o uso de índices e causavam problemas qe culpavam a ferramenta). Eu tinha acesso privilegiado a muitas informações, eu trabalha com uma pessoa que dominava o baixo nível que me direcionou bem sobre o assunto, fui inclusive beta tester do Visual Objects em uma época que conseguir isso era um enorme privilégio. E conheçõ de perto a VM do Harbour que apesar de ser melhor (tem uma ou outra parte pior), a base funciona quase idêntica ao do Clipper, eu participei da comunidade intensamente durante um período e queria que o experimento citado tivesse qualidade de produção (também queria) que se iniciasse um transição opcional para tipagem estática - teve um início de implementação mas nunca foi adiante).

O Harbour ainda teria uma Vm pelo menos para rodar o GC. E clar oque teria algumas proibições como gerar código com macro ou outro mecanismo (no Harbour). O Clipper e Harbour precisam carregar quase um compilador completo debtro dele se usar macro (ou hb_compile()). No Harnour é possível salvar o pcode em um arquivo ou banco de dados, carregar depois e executar pela VM. No Clipper dava fazendo gambiarra, mas na prática era problemático. No Harbour o ideal era ter um controle de versão do pcode e poder recompilar se não batesse com a versão da atual VM. O pcode do Harbour é completamente incompatível com o do Clipper em qualquer versão.

.>A parte que ficou sem coerência foi esse trecho, pois se você já havia afirmado antes que ele usava Clipper + Assembly, este trecho deu a me entender que ele não usava.

Não foi minha interpretação, mas pode tentar mostrar o que está inconsistente. Antes usava Clipper + Asm e passou usar só C++ na nova versão.