Por que seria possível que o Java fosse mais rápido que o C ++?

78

Às vezes, o Java supera o C ++ em benchmarks. Claro, às vezes o C ++ supera.

Veja os links a seguir:

Mas como isso é possível? Confunde que o código de idioma interpretado poderia ser mais rápido que uma linguagem compilada.

Alguém por favor pode explicar? Obrigado!

    
por Deets McGeets 26.09.2011 / 06:47
fonte

15 respostas

107
Primeiro, a maioria das JVMs inclui um compilador, então "bytecode interpretado" é realmente muito raro (pelo menos no código de benchmark - não é tão raro na vida real, onde seu código geralmente é mais do que alguns loops triviais que são obtidos repetido com muita frequência).

Em segundo lugar, um bom número de pontos de referência envolvidos parece ser bastante tendencioso (seja por intenção ou incompetência, eu não posso dizer realmente). Por exemplo, há alguns anos, analisei alguns dos códigos-fonte vinculados de um dos links que você postou. Tinha código assim:

  init0 = (int*)calloc(max_x,sizeof(int));
  init1 = (int*)calloc(max_x,sizeof(int));
  init2 = (int*)calloc(max_x,sizeof(int));
  for (x=0; x<max_x; x++) {
    init2[x] = 0;
    init1[x] = 0;
    init0[x] = 0;
  }

Como calloc fornece memória que já está zerada, usar o loop for para zerar novamente é obviamente inútil. Isto foi seguido (se a memória servir) preenchendo a memória com outros dados de qualquer maneira (e sem dependência de ser zerada), então todo o zeramento era completamente desnecessário de qualquer maneira. Substituir o código acima por um simples malloc (como qualquer pessoa sensata teria usado para começar) melhorou a velocidade da versão C ++ o suficiente para superar a versão Java (por uma margem razoavelmente ampla, se a memória servir).

Considere (por outro exemplo) o valor de referência methcall usado na entrada do blog no seu último link. Apesar do nome (e como as coisas podem parecer), a versão C ++ disso não é realmente muito sobre a sobrecarga da chamada de método. A parte do código que se torna crítica está na classe Toggle:

class Toggle {
public:
    Toggle(bool start_state) : state(start_state) { }
    virtual ~Toggle() {  }
    bool value() {
        return(state);
    }
    virtual Toggle& activate() {
        state = !state;
        return(*this);
    }
    bool state;
};

A parte crítica é a state = !state; . Considere o que acontece quando alteramos o código para codificar o estado como int em vez de bool :

class Toggle {
    enum names{ bfalse = -1, btrue = 1};
    const static names values[2];
    int state;

public:
    Toggle(bool start_state) : state(values[start_state]) 
    { }
    virtual ~Toggle() {  }
    bool value() {  return state==btrue;    }

    virtual Toggle& activate() {
        state = -state;
        return(*this);
    }
};

Esta pequena alteração melhora a velocidade geral em cerca de uma margem de 5: 1 . Embora o benchmark fosse planejado para medir o tempo de chamada do método, na realidade, a maior parte do que ele estava medindo era o tempo de conversão entre int e bool . Eu certamente concordaria que a ineficiência mostrada pelo original é lamentável - mas dada a raridade com que parece surgir no código real, e a facilidade com que ele pode ser consertado quando / se surgir, tenho dificuldade em pensar como significando muito.

Caso alguém decida reexecutar os benchmarks envolvidos, devo também acrescentar que há uma modificação quase igualmente trivial na versão Java que produz (ou pelo menos uma vez produzida - eu não re-executei o testes com uma recente JVM para confirmar que eles ainda fazem) uma melhoria bastante substancial na versão Java também. A versão do Java tem um NthToggle :: activate () que se parece com isto:

public Toggle activate() {
this.counter += 1;
if (this.counter >= this.count_max) {
    this.state = !this.state;
    this.counter = 0;
}
return(this);
}

Mudar isto para chamar a função base ao invés de manipular this.state diretamente dá uma melhoria considerável na velocidade (embora não o suficiente para acompanhar a versão modificada do C ++).

Então, o que acabamos com é uma falsa suposição sobre códigos de bytes interpretados versus alguns dos piores benchmarks (que eu já vi). Nem está dando um resultado significativo.

Minha própria experiência é que, com programadores igualmente experientes que prestam a mesma atenção à otimização, o C ++ superará o Java com mais frequência - mas (pelo menos entre esses dois), a linguagem raramente fará tanta diferença quanto os programadores e designers. . Os pontos de referência citados nos dizem mais sobre a (in) competência / (des) honestidade de seus autores do que sobre as linguagens que pretendem avaliar.

[Edit: Como implícito em um lugar acima mas nunca declarado tão diretamente quanto eu provavelmente deveria ter, os resultados que estou citando são aqueles que obtive quando testei isso ~ 5 anos atrás, usando implementações de C ++ e Java que eram atuais naquela hora. Eu não executei novamente os testes com as implementações atuais. Um relance, no entanto, indica que o código não foi corrigido, então tudo o que teria mudado seria a capacidade do compilador de encobrir os problemas no código.]

Se ignorarmos os exemplos de Java, no entanto, é realmente possível para o código interpretado ser executado mais rápido do que o código compilado (embora difícil e um tanto incomum).

A maneira usual como isso acontece é que o código que está sendo interpretado é muito mais compacto que o código da máquina, ou está sendo executado em uma CPU que possui um cache de dados maior que o cache de código.

Nesse caso, um pequeno intérprete (por exemplo, o intérprete interno de uma implementação da Forth) pode ser capaz de se ajustar inteiramente ao cache de código, e o programa que está interpretando se ajusta inteiramente ao cache de dados. O cache é tipicamente mais rápido que a memória principal por um fator de pelo menos 10, e frequentemente muito mais (um fator de 100 não é particularmente mais raro).

Então, se o cache é mais rápido que a memória principal por um fator de N, e leva menos que N instruções de código de máquina para implementar cada código de byte, o código de byte deve ganhar (estou simplificando, mas acho que o geral idéia ainda deve ser aparente).

    
por 26.09.2011 / 07:53
fonte
109

Handled C / C ++ feito por um especialista com tempo ilimitado será pelo menos tão rápido ou mais rápido que o Java. Por fim, o próprio Java é escrito em C / C ++, portanto, é claro que você pode fazer tudo o que o Java faz se estiver disposto a investir em um esforço de engenharia suficiente.

Na prática, no entanto, o Java geralmente executa muito rápido pelos seguintes motivos:

  • Compilação JIT - embora as classes Java sejam armazenadas como bytecode, isso é (normalmente) compilado em código nativo pelo compilador JIT quando o programa é inicializado. Uma vez compilado, é puro código nativo - então, teoricamente, pode-se esperar que ele funcione tão bem quanto C / C ++ compilado depois que o programa estiver rodando por tempo suficiente (ou seja, depois que toda a compilação JIT tiver sido feita)
  • A coleta de lixo em Java é extremamente rápida e eficiente - o GC do Hotspot é provavelmente a melhor implementação de GC em todo o mundo. É o resultado de muitos anos de trabalho de especialistas da Sun e de outras empresas. Praticamente qualquer sistema de gerenciamento de memória complexo que você se revele em C / C ++ será pior. É claro que você pode escrever esquemas básicos de gerenciamento de memória bastante rápidos / leves em C / C ++, mas eles não serão tão versáteis quanto um sistema completo de GC. Como a maioria dos sistemas modernos precisa de gerenciamento de memória complexo, o Java tem uma grande vantagem para situações do mundo real.
  • Melhor direcionamento de plataforma - atrasando a compilação à inicialização do aplicativo (compilação JIT, etc.), o compilador Java pode aproveitar o fato de conhecer o processador exato que está executando em. Isso pode permitir algumas otimizações muito benéficas que você não seria capaz de fazer no código C / C ++ pré-compilado que precisa direcionar um conjunto de instruções do processador "menor denominador comum".
  • Estatísticas de tempo de execução - como a compilação JIT é feita em tempo de execução, ele pode coletar estatísticas enquanto o programa está em execução, permitindo melhores otimizações (por exemplo, conhecendo a probabilidade de uma determinada ramificação). Isso pode permitir que os compiladores Java JIT produzam código melhor que compiladores C / C ++ (que precisam "adivinhar" a ramificação mais provável com antecedência, uma suposição que pode estar errada).
  • Bibliotecas muito boas - o Java runtime contém um host de bibliotecas muito bem escritas com bom desempenho (especialmente para aplicativos do lado do servidor). Muitas vezes, são melhores do que você poderia escrever ou obter facilmente para C / C ++.

Ao mesmo tempo, o C / C ++ também tem algumas vantagens:

  • Mais tempo para fazer otimizações avançadas - A compilação C / C ++ é feita uma vez e pode, portanto, gastar um tempo considerável fazendo otimizações avançadas se você configurá-lo para fazer isso. Não há razão teórica para que o Java não possa fazer o mesmo, mas na prática você quer compilar código Java para JIT com relativa rapidez, então o compilador JIT tende a se concentrar em otimizações "mais simples".
  • Instruções que não são expressas em bytecode - enquanto o bytecode Java é totalmente genérico, ainda há algumas coisas que você pode fazer em um nível baixo que você não pode fazer no bytecode (aritmética de ponteiro não verificado é um bom exemplo!). Por (ab) usando este tipo de truques você pode obter algumas vantagens de desempenho
  • Menos contstraints de "segurança" - o Java faz algum trabalho extra para garantir que os programas sejam seguros e confiáveis. Exemplos são verificações de limites em matrizes, certas garantias de simultaneidade, verificações de ponteiro nulo, segurança de tipo em conversões, etc. Ao evitá-las em C / C ++, você pode obter alguns ganhos de desempenho (embora isso possa ser uma má ideia!)

Geral:

  • Java e C / C ++ podem atingir velocidades semelhantes
  • O C / C ++ provavelmente tem uma ligeira vantagem em circunstâncias extremas (não é de surpreender que desenvolvedores de jogos AAA ainda prefiram, por exemplo)
  • Na prática, dependerá de como os diferentes fatores listados acima se equilibram para sua aplicação específica.
por 26.09.2011 / 08:40
fonte
19

O bytecode de interpretação do Java runtime isnt . Em vez disso, ele usa o que é chamado de Compilação Just In Time . Basicamente, quando o programa é executado, ele executa bytecode e o converte em código nativo otimizado para a CPU em particular.

    
por 26.09.2011 / 06:58
fonte
18

Sendo tudo igual, você poderia dizer: não, Java nunca deveria ser mais rápido . Você pode sempre implementar Java em C ++ a partir do zero e, assim, obter pelo menos um desempenho tão bom. Na prática, no entanto:

  • O JIT compila o código na máquina do usuário final, permitindo que ele otimize a CPU exata em que estão sendo executados. Embora haja uma sobrecarga aqui para a compilação, pode valer a pena para aplicativos intensivos. Muitas vezes, os programas da vida real não são compilados para a CPU que você está usando.
  • O compilador Java pode ser melhor para otimizar automaticamente as coisas do que um compilador C ++. Ou talvez não, mas no mundo real, as coisas nem sempre são perfeitas.
  • O comportamento do desempenho pode variar devido a outros fatores, como a coleta de lixo. Em C ++, você normalmente chama o destrutor imediatamente quando feito com um objeto. Em Java, você simplesmente libera a referência, atrasando a destruição real. Este é outro exemplo de diferença que não está nem aqui nem ali, em termos de desempenho. Claro, você pode argumentar que você poderia implementar GC em C ++ e acabar com isso, mas a realidade é que poucas pessoas querem / podem.

Como um aparte, isso me lembra o debate sobre C nos anos 80/90. Todos se perguntavam "C pode ser tão rápido quanto a montagem?". Basicamente, a resposta foi: não no papel, mas na realidade o compilador C criou código mais eficiente que 90% dos programadores de montagem (bem, uma vez que amadureceu um pouco).

    
por 26.09.2011 / 07:23
fonte
10

But allocation is only half of memory management -- deallocation is the other half. It turns out that for most objects, the direct garbage collection cost is -- zero. This is because a copying collector does not need to visit or copy dead objects, only live ones. So objects that become garbage shortly after allocation contribute no workload to the collection cycle.

...

JVMs are surprisingly good at figuring out things that we used to assume only the developer could know. By letting the JVM choose between stack allocation and heap allocation on a case-by-case basis, we can get the performance benefits of stack allocation without making the programmer agonize over whether to allocate on the stack or on the heap.

link

    
por 26.09.2011 / 08:34
fonte
5
Enquanto um programa Java completamente otimizado raramente irá superar um programa C ++ completamente otimizado, diferenças em coisas como gerenciamento de memória podem tornar muitos algoritmos funcionalmente implementados em Java mais rápido do que os mesmos algoritmos implementados idiomaticamente em C ++.

Como @Jerry Coffin apontou, há muitos casos em que mudanças simples podem tornar o código muito mais rápido - mas muitas vezes pode exigir muitos ajustes impuros em um idioma ou outro para que a melhoria no desempenho valha a pena. Isso é provavelmente o que você veria em um benchmark bom que mostra Java fazendo melhor que C ++.

Além disso, embora geralmente não seja tão significativo, há alguma otimização de desempenho que uma linguagem JIT como Java pode fazer que o C ++ não pode. O Java runtime pode incluir melhorias após o código ter sido compilado, o que significa que o JIT pode potencialmente produzir código otimizado para aproveitar os novos (ou pelo menos diferentes) recursos da CPU. Por esse motivo, um binário Java com 10 anos de idade pode potencialmente superar um binário de 10 anos de idade em C ++.

Por último, a segurança de tipo completa no quadro geral pode, em casos muito raros, oferecer melhorias extremas de desempenho. Singularity , um sistema operacional experimental escrito quase inteiramente em uma linguagem baseada em C #, tem comunicação entre processos muito mais rápida e multitarefa devido ao fato de que não há necessidade de limites de processo de hardware ou de switches de contexto caros.

    
por 26.09.2011 / 12:05
fonte
5

Postado por Tim Holloway em JavaRanch:

Here's a primitive example: Back when machines operated in mathematically-determined cycles, a branch instruction typically had 2 different timings. One for when the branch was taken, one for when the branch wasn't taken. Usually, the no-branch case was faster. Obviously, this meant that you could optimize logic based on the knowledge of which case was more common (subject to the constraint that what we "know" isn't always what's actually the case).

JIT recompilation takes this one step further. It monitors the actual real-time usage, and flips the logic based on what actually is the most common case. And flip it back again if the workload shifts. Statically-compiled code can't do this. That's how Java can sometimes out-perform hand-tuned assembly/C/C++ code.

Fonte: link

    
por 26.09.2011 / 19:31
fonte
4

Isso ocorre porque a etapa final que gera o código da máquina ocorre de forma transparente dentro da JVM ao executar seu programa Java, em vez de explícito ao construir seu C ++ proram.

Você deve considerar o fato de que a JVM moderna gasta bastante tempo compilando o código de byte dinamicamente para código de máquina nativo para torná-lo o mais rápido possível. Isso permite que a JVM faça todos os tipos de truques do compilador que podem ser ainda melhores, conhecendo os dados de criação de perfil do programa que está sendo executado.

Apenas como inserir automaticamente um getter, para que um JUMP-RETURN não seja necessário apenas para obter um valor, acelera as coisas.

No entanto, o que realmente permitiu programas rápidos é melhor limpeza depois. O mecanismo de coleta de lixo em Java é mais rápido que o manual malloc-free em C. Muitas implementações modernas sem malloc usam um coletor de lixo abaixo.

    
por 26.09.2011 / 08:10
fonte
4

Resposta curta - não é. Esqueça, o assunto é tão antigo quanto fogo ou roda. Java ou .NET não é e não será mais rápido que C / C ++. É rápido o suficiente para a maioria das tarefas em que você não precisa pensar em otimização. Como formulários e processamento de SQL, mas é aí que termina.

Para benchmarks, ou pequenas aplicações escritas por desenvolvedores incompetentes, sim, o resultado final será que o Java / .NET provavelmente estará próximo e talvez até mais rápido.

Na realidade, coisas simples como alocar memória na pilha ou simplesmente usar memzones simplesmente matam o Java / .NET na hora.

O mundo da coleta de lixo está usando uma espécie de memzone com toda a contabilidade. Adicionar memzone a C e C será mais rápido ali mesmo no local. Especialmente para os benchmarks Java vs. C "código de alto desempenho", que são assim:

for(...)
{
alloc_memory//Allocating heap in a loop is verrry good, in't it?
zero_memory//Extra zeroing, we really need it in our performance code
do_stuff//something like memory[i]++
realloc//This is lovely speedup
strlen//loop through all memory, because storing string length is soo getting old
free//Java will do that outside out timing loop, but oh well, we're comparing apples to oranges here
}//loop 100000 times

Tente usar variáveis baseadas em pilha em C / C ++ (ou posicionamento novo), elas se traduzem em sub esp, 0xff , é uma única instrução x86, supere isso com Java - você não pode ...

Na maioria das vezes eu vejo aqueles bancos onde Java contra C ++ são comparados, o que me faz ir como, wth? Estratégias erradas de alocação de memória, contêineres de auto-crescimento sem reservas, vários novos. Isso não está nem perto do código C / C ++ orientado para o desempenho.

Também uma boa leitura: link

    
por 26.09.2011 / 15:02
fonte
2

A realidade é que ambos são apenas montadores de alto nível que fazem exatamente o que o programador lhes diz, exatamente como o programador lhes diz na ordem exata que o programador lhes diz. As diferenças de desempenho são tão pequenas que são irrelevantes para todos os fins práticos.

A linguagem não é "lenta", o programador escreveu um programa lento. Muito raramente, um programa escrito da melhor maneira, em uma língua, supera (para qualquer propósito prático) um programa que faz a mesma coisa usando o melhor caminho da língua alternativa, a menos que o autor do estudo esteja à procura de seu objetivo específico.

Obviamente, se você estiver indo para um caso de borda rara, como sistemas embutidos em tempo real, a escolha da linguagem pode fazer a diferença, mas com que frequência é esse o caso? e, nesses casos, com que frequência a escolha correta não é cegamente óbvia.

    
por 26.09.2011 / 09:38
fonte
2

See the following links ... But how is this even possible? It boggles my mind that interpreted bytecode could ever be faster than a compiled language.

  1. Esses posts do blog fornecem evidências confiáveis?
  2. Esses posts no blog fornecem evidências definitivas?
  3. Esses posts ainda fornecem evidências sobre "bytecode interpretado"?

Keith Lea diz que há "falhas óbvias", mas não faz nada sobre essas "falhas óbvias". Em 2005, essas tarefas antigas foram descartadas e substituídas pelas tarefas exibidas agora no jogo de benchmarks .

Keith Lea diz que ele "pegou o código de referência para C ++ e Java do já superado Great Computer Language Shootout e executou os testes", mas na verdade ele só mostra medições para 14 de 25 desses testes desatualizados .

Keith Lea agora diz que ele não estava tentando provar nada com o post do blog sete anos antes, mas na época ele disse "Eu estava cansado de ouvir pessoas dizerem que o Java estava lento, quando eu sei que é bem rápido ... "o que sugere naquela época havia algo que ele estava tentando provar.

Christian Felde diz "Eu não criei o código, apenas corrijo os testes." como se isso o isentasse de qualquer responsabilidade por sua decisão de divulgar as medições das tarefas e programas que Keith Lea selecionou.

Medições de até 25 minúsculos programas fornecem evidências definitivas?

Essas medições são para programas executados como "modo misto" Java não interpretado Java - "Lembre-se de como o HotSpot funciona " Você pode facilmente descobrir o quão bem Java roda" bytecode interpretado ", porque você pode forçar o Java a somente interpretar bytecode - simplesmente o tempo que alguns programas Java executam com e sem a opção -Xint .

    
por 26.09.2011 / 19:47
fonte
-1

Me diverte como essa noção estranha de "bytecode interpretado" é difundida. Vocês já ouviram falar da compilação JIT? Seu argumento não pode ser aplicado ao Java.

Mas, deixando a JVM de lado, há casos em que um código encadeado direto ou até mesmo uma interpretação trivial de bytecode pode facilmente superar um código nativo altamente otimizado. A explicação é bem simples: o bytecode pode ser bastante compacto e caberá no seu minúsculo cache quando uma versão de código nativo do mesmo algoritmo acabar tendo vários erros de cache para uma única iteração.

    
por 26.09.2011 / 08:25
fonte
-1

JIT, GC e assim por diante, C ++ pode ser muito, muito facilmente feito muito mais lento do que Java. Isso não será mostrado nos benchmarks, mas o mesmo aplicativo escrito por um desenvolvedor Java e um desenvolvedor C ++ pode ser muito mais rápido em Java.

  • Operador sobrecarregado. Todo operador simples como "+" ou "=" pode chamar centenas de linhas de código fazendo verificações de segurança, operações de disco, registro, rastreamento e criação de perfil. E eles são tão fáceis de usar que, quando você sobrecarrega os operadores, você os usa naturalmente e copiosamente sem perceber como o uso se compara.
  • Modelos. Estes não afetam a velocidade, tanto quanto a memória. O uso imprudente de modelos levará à geração de milhões de linhas de código (alternativas para o modelo básico) sem que você as perceba. Mas, em seguida, os tempos de carregamento binários, uso de memória, uso de swap - tudo isso também age contra os benchmarks. E o uso de RAM passa pelo telhado.

Quanto aos padrões avançados de herança, eles são muito semelhantes - o C ++ tem alguns que o Java não possui e vice-versa, mas todos eles também apresentam uma sobrecarga significativa e significativa. Portanto, nenhuma vantagem especial do C ++ na programação com objetos pesados.

Mais uma advertência: o GC pode ser mais rápido ou mais lento do que gerenciar alocações manualmente. Se você alocar muitos objetos pequenos, no ambiente de GC normalmente um pedaço de memória é alocado e partes dele são despachadas conforme necessário para novos objetos. No gerenciado - cada objeto = alocação separada leva um tempo significativo. OTOH, se você malloc () muita memória de uma só vez e, em seguida, apenas atribuir peças a seus objetos manualmente, ou usar algumas instâncias maiores de objetos, você pode chegar muito mais rápido.

    
por 26.09.2011 / 09:07
fonte
-2

De alguma forma, o Stack Exchange não aceita meus outros stackpoints, então ... sem resposta, infelizmente ...

No entanto, a segunda resposta mais votada aqui é cheia de desinformação na minha humilde opinião.

Um App enrolado a mão por um especialista em C / C ++ SEMPRE será muito mais rápido que um aplicativo Java, ponto final. Não há 'tão rápido quanto Java ou Faster'. é apenas mais rápido, precisamente por causa dos itens que você cita abaixo:

Compilação JIT : Você realmente espera que um otimizador automático tenha a inteligência de um programador especialista e veja o link entre a intenção e o código que a CPU realmente irá executar ??? Além disso, todo o JIT que você faz é tempo perdido comparado a um programa já compilado.

Garbage Collection é uma ferramenta que simplesmente desaloca recursos que um programador teria esquecido de desalocar, de uma maneira mais ou menos eficiente.

Evidentemente, isso só pode ser mais lento do que o que um programador C (você escolheu o termo) faria para lidar com a memória (e não há vazamentos em aplicativos escritos corretamente).

Um aplicativo C otimizado para desempenho sabe que a CPU está sendo executada, foi compilada nele, senão isso significa que você não executou todas as etapas para obter desempenho?

Estatísticas de tempo de execução Isso está além do meu conhecimento, mas suspeito que um especialista em C tenha mais do que suficiente conhecimento de predição de filiais para novamente superar a otimização automatizada -

Bibliotecas muito boas Existem muitas funções não muito otimizadas prontamente disponíveis através de bibliotecas em Java, e o mesmo é verdadeiro em qualquer idioma, porém as bibliotecas mais otimizadas são escritas em C, especialmente para cálculo.

A JVM é uma camada de abstração, o que implica em coisas boas, muitas das quais estão acima, e também implica que a solução geral é mais lenta por design.

Geral:

O Java não pode atingir a velocidade do C / C ++ devido ao modo como ele funciona em uma JVM com muita proteção, recursos e ferramentas.

O C ++ tem uma clara vantagem no software otimizado, seja para computação ou jogos, e é comum ver implementações de C ++ vencerem concursos de codificação ao ponto de as melhores implementações de Java só poderem ser vistas na segunda página.

Na prática, o C ++ não é um brinquedo e não permite que você consiga muitos erros que a maioria das linguagens modernas pode manipular; no entanto, por ser mais simples e menos seguro, é inerentemente mais rápido.

E como conclusão, eu gostaria de dizer que a maioria das pessoas não dá dois centavos sobre isso, que no final a otimização é um esporte reservado apenas para poucos desenvolvedores de sorte e que, exceto em casos em que o desempenho realmente é uma preocupação (ou seja, onde multiplicar o hardware por 10 não ajudará você - ou representará alguns milhões pelo menos), a maioria dos gerentes preferirá um aplicativo não otimizado e uma tonelada de hardware.

    
por 26.09.2011 / 18:15
fonte
-4

Eu já vi pelo menos dois mmos impressionantes feitos em Java, para dizer que não é rápido o suficiente para jogos é um equívoco. Só porque os designers de jogos preferem o C ++ mais do que outras linguagens, ele diz que simplesmente não é apenas relacionado ao Java, ele apenas significa que os programadores nunca se interessaram por outras linguagens / paradigmas de programação. Qualquer coisa em qualquer linguagem tão avançada quanto C / C ++ ou mesmo Java pode produzir código que poderia tecnicamente atender ou derrotar o argumento da velocidade. Tudo isso bem e dito se resume ao que os programadores sabem, com quais equipes trabalham mais e, o mais importante, porque usam essas ferramentas. Como estamos lidando com o aspecto de desenvolvimento de jogos da programação, então deve haver mais no argumento. Simplificando, é tudo sobre dinheiro e tempo para um conjunto de negócios usando ferramentas que atendem ao controle de qualidade e no mundo real não tem nenhum peso em xx razões para escolher o C ++ sobre Java ou qualquer outra linguagem. É apenas uma decisão de produção em massa. No nível mais básico de algoritmos de computação, todos nós estamos jogando com uns e zeros, o argumento da velocidade é um dos argumentos mais burros já aplicados aos jogos. Se você quer ganhos de velocidade tão ruins, então solte completamente as linguagens de programação e trabalhe com montagem que é, de longe, a melhor vantagem.

    
por 06.06.2015 / 13:41
fonte