Ah…entendi agora. Você quer dizer “vão rodar”, no sentido de “um dia vão rodar”. Pois é…talvez.

Temos pontos de vista bem diferentes.

“Um algorítmo? Qual algorítmo? Existem toneladas de exemplos de algorítmos com implementações de semelhante complexidade que vão rodar mais que 2x mais rápido em uma linguagem gerenciada que em C/C++.”

Sem comentários.

Vinte ms é irrelevante para um sistema web. A home do G1 demora 500ms para ser entregue aqui (tempo entre o primeiro e o último pacote apenas). Meu ponto foi que para o usuário a performance extra na vai se converter em uma aplicação com tempo de resposta melhor.

“Não disse isto. Antes, apenas afirmei que um algoritmo compilado no gcc, com otimização do compilador ligada, roda mais rápido do que o mesmo algoritmo implementado em Java rodando em uma JVM. Isto significa que com as ferramentas atuais, C é mais rápido.”

Um algorítmo? Qual algorítmo? Existem toneladas de exemplos de algorítmos com implementações de semelhante complexidade que vão rodar mais que 2x mais rápido em uma linguagem gerenciada que em C/C++.

Claro que faz diferença! Shell script é muito lento…

“Uma aplicação web passa a maior parte do tempo lidando com latência da rede. O banco de dados e o sistema de arquivos vão continuar sendo lentos da mesma maneira seja com Ruby ou C++. Uma requisição web vai continuar gastando mais de 100ms-300ms entre estabelecer a conexão, enviar a requisição e transmitir a resposta.”

Concordo.

“Para começar, o usuário final iria sentir quase nenhuma melhora. Se com Python leva 20ms para processar a requisição e em com C++ leva 0ms. A melhora vai ser de de 17% indo de 120ms para 100ms o tempo de resposta.”

Vinte milissegundos é muito tempo, considerando este tempo para vários usuários. Veja o quanto me preocupo com isso neste meu outro post: http://blog.globoi.com/webmedia/2007/10/03/meta-plugin/

“Continuando, o maior gargalo é a rede e contra isso usar C++ não vai melhorar em nada. Uma webapp feita com mod_perl consegue saturar uma placa gigabit de um servidor razoável (4 cores) se esta não tiver nenhum ponto de espera - tal qual um SGDB.

Quem dita escalabilidade de um sistema é sua arquitetura. Coisas como se usa um cache distribuído, mensageria assíncrona, sharding, particionamento, etc. Porém esse tipo de decisão é agnóstica a linguagem de programação utilizada.”

Concordo. Disse isso no post, inclusive.

“Moral da história, usar C++ não compra quase nenhuma vantagem em relação a linguagens gerenciadas e dinâmicas. Com desvantagens, não esqueçamos, como produtividade muito inferior, deployment complicado, troubleshooting muito mais complexo e por ai vai.”

Bom, aí, como eu já disse, depende do peopleware.

“Só para concluir, nenhuma pessoa em sã consciencia que trabalha com compiladores ou máquinas virtuais diria que compilação estática produz resultados melhores que compilação em tempo de execução. É mais provado e comprovado que um JIT produz código mais rápido. Isso vale para linguagens gerenciadas e não gerenciadas como C ou C++.”

Não disse isto. Antes, apenas afirmei que um algoritmo compilado no gcc, com otimização do compilador ligada, roda mais rápido do que o mesmo algoritmo implementado em Java rodando em uma JVM. Isto significa que com as ferramentas atuais, C é mais rápido.

Uma aplicação web passa a maior parte do tempo lidando com latência da rede. O banco de dados e o sistema de arquivos vão continuar sendo lentos da mesma maneira seja com Ruby ou C++. Uma requisição web vai continuar gastando mais de 100ms-300ms entre estabelecer a conexão, enviar a requisição e transmitir a resposta.

Para começar, o usuário final iria sentir quase nenhuma melhora. Se com Python leva 20ms para processar a requisição e em com C++ leva 0ms. A melhora vai ser de de 17% indo de 120ms para 100ms o tempo de resposta.

Continuando, o maior gargalo é a rede e contra isso usar C++ não vai melhorar em nada. Uma webapp feita com mod_perl consegue saturar uma placa gigabit de um servidor razoável (4 cores) se esta não tiver nenhum ponto de espera - tal qual um SGDB.

Quem dita escalabilidade de um sistema é sua arquitetura. Coisas como se usa um cache distribuído, mensageria assíncrona, sharding, particionamento, etc. Porém esse tipo de decisão é agnóstica a linguagem de programação utilizada.

Moral da história, usar C++ não compra quase nenhuma vantagem em relação a linguagens gerenciadas e dinâmicas. Com desvantagens, não esqueçamos, como produtividade muito inferior, deployment complicado, troubleshooting muito mais complexo e por ai vai.

Só para concluir, nenhuma pessoa em sã consciencia que trabalha com compiladores ou máquinas virtuais diria que compilação estática produz resultados melhores que compilação em tempo de execução. É mais provado e comprovado que um JIT produz código mais rápido. Isso vale para linguagens gerenciadas e não gerenciadas como C ou C++.

Para aplicações que rodam por tempo suficiente, como costuma ser o caso das que rodam num servidor, os bons GCs e JIT Compilers começam a brilhar e deixar aplicações gerenciadas até mais rápidas que as compiladas nativamente em muitos casos.

Compilação nativa usa heurística para muita coisa. O JIT Compiler não precisa de heurística.