Aplicações web nativas - por que não?
Recentes discussões sobre desempenho e escalabilidade de sistemas me levaram a seguinte questão: por que não se fala em frameworks e sistemas web server-side compilados diretamente para assembly nativo?
Este é um fenômeno curioso para mim, já que aplicações interpretadas (e até as compiladas para uma virtual machine), são menos performáticas. Quero que fique claro que não acredito que o uso de aplicações compiladas seja a solução para problemas de performance. Estas questões precisam ser primariamente endereçadas a melhorias arquiteturais e infraestruturais desenhadas para cada aplicação particular. Apenas questiono o fato de nós desenvolvedores, na grande maioria dos casos, não considerarmos essa hipótese ao desenvolver uma aplicação web, ou mesmo como meio de otimizar sistemas específicos cuja performance é crítica.
Por exemplo, ainda que soluções Java tenham desempenho excelente em muitos casos, seria muito interessante e perfeitamente justificável, do meu ponto de vista, o desenvolvimento de um framework para C++ que suportasse um esquema semelhante à tecnologia Servlet do Java - sem as limitações de performance de programas CGI - entre outras soluções web consagradas, além de bibliotecas que facilitassem o desenvolvimento de aplicações C++ para web.
É claro que não podemos negar que existem vantagens interessantes oferecidas pelas linguagens interpretadas neste campo. Mas, honestamente, não entendo porque o simples ganho de performance oferecido por aplicações nativas ainda não resultou no surgimento de pelo menos um framework desse gênero consolidado e de uma comunidade de desenvolvedores que, assim como eu, são aficionados por desempenho. 
June 6th, 2008 at 8:05 pm
C++ nasceu para web.
Quem não sabe desenvolver uma aplicação escalavel e com performance no mínimo comprou o diploma.
June 6th, 2008 at 8:34 pm
Meu projeto final da faculdade foi todo em CGIs em C++, e funcionava muito bem por sinal. Quem diz que CGI é ruim é porque não sabe fazer do jeito certo. As minhas eram bastante performáticas.
Se você quiser, existe uma biblioteca que simplifica um pouco a implementação: http://www.vbmcgi.org
[]’s
June 6th, 2008 at 11:02 pm
Existem varios, mas o problema eh que webapps nao escalam pela arquitetura. A performance de um programa isolado nao vale o esforço.
June 6th, 2008 at 11:40 pm
Vamos fazer o C++ on rails
Mas sério, a questão é a facilidade de desenvolvimento, a abstração que as linguagens interpretadas dão aumentam bastante a produtividade. Acredito que o custo de um desenvolvedor é maior que o de escalar uma aplicação.
Deixo então uma pergunta inversa, não seria interessante compilar uma aplicação web inteira feita em uma linguagem interpretada para código nativo? Um tipo de JIT total e prévio?
June 7th, 2008 at 12:30 am
@phillip calcado
Esse é o ponto, os frameworks atuais não têm uma arquitetura boa o suficiente, se comparados aos que existem para Java, por exemplo. Acho que o simples fato de ter a opção de criar e rodar suas webapps com performance ótima vale sim o esforço de desenvolver um framework desse tipo. É algo que poderiamos ter hoje e ainda não temos.
@Tiago Albineli Motta
A proficiência do desenvolvedor na linguagem aumenta a produtividade. Onde você leu que “a abstração que as linguagens interpretadas dão aumentam bastante a produtividade”? A bilionária indústria de games quase não usa linguagens interpretadas e parece ser uma das mais produtivas, senão a mais produtiva.
No post eu falo sobre rodar aplicações nativas, não apenas sobre usar linguagens que geram código nativo por padrão. Isso inclui a sua idéia de “compilar uma aplicação web inteira feita em uma linguagem interpretada para código nativo”.
June 7th, 2008 at 12:35 am
@anselmo exatamente A bilionaria industria de games, que tem dinheiro pra contratar os melhores desenvolvedores. O seu manoel da padaria que quer vender pães pela web não tem essa grana toda.
June 7th, 2008 at 9:00 pm
Voce nao entendeu, nao eh arquitetura do framework, seja java ou o que for, mas da aplicacao. Os gargalos estao quase sempre na comunicacao entre partes entao otimizar uma parte por si so nao traz tanto beneficio.
June 7th, 2008 at 9:05 pm
Sobre games, baseado em que voce afirma que eh produtiva? Alem do mais, os games de hoje usam sempre que possivel uma linguagem como lua e mantem apenas seu engine em codigo nao gerenciado.
June 9th, 2008 at 10:56 am
http://idgnow.uol.com.br/computacao_pessoal/2008/01/25/industria-de-games-movimenta-us-9-5-bilhoes-durante-2007-diz-npd/ além da enorme qualidade e complexidade encontrada nos games.
June 9th, 2008 at 11:06 am
Acho que você está confundindo produtividade com lucratividade. O link que você me mandou ala sobre quanto a indústria fatura, com 5 minutos de internet você acha um link dizendo o quanto, digamos, bancos aturam. É mais que isso e não faz deles exemplo de produtividade.
June 9th, 2008 at 11:20 am
Eh dificil medir isso…tem gente que mede em linhas de codigo.
June 9th, 2008 at 11:25 am
Isso dá um outro post.
June 9th, 2008 at 11:43 am
Existem diversos estudos de produtividade em ambientes gerenciados x nativos. Independete da maneira como são aferidos acho que você concorda comigo que é geralmente mais rápido implementar algo numa linguagem gerenciada, onde boa parte do hardware e recursos estão abstraídos.
June 9th, 2008 at 1:45 pm
Concordo. É necessário um time muito especializado e um bom motivo.
June 10th, 2008 at 1:26 am
Cuidado quando acha que aplicações compiladas nativamente são mais rápidas que as que rodam em uma VM. Daqui a pouco aparece o louds por aqui para te crucificar!
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.
June 10th, 2008 at 7:06 am
Fabio, já vi Java ser tão rápido quanto C, por exemplo, por conta do JIT da JVM. Era um pequeno programinha, que fazia um determinado tipo de operação. Isto mostra claramente que o tempo de execução de um programa em uma VM, dependendo do tipo de operações que se faça, pode ser comparável ao tempo de execução de um programa nativo. Porém, em várias operações, o C se mostra mais rápido. Equacionando isso, programas nativos ainda são mais rápidos.
June 12th, 2008 at 1:50 am
Acho que essa questão é equivalente a “Por que não escrever uma engine 3D com shell script?”. Por simplesmente não fazer o menor sentido. Por não fazer a menor diferença.
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++.
June 12th, 2008 at 12:04 pm
“Acho que essa questão é equivalente a “Por que não escrever uma engine 3D com shell script?”. Por simplesmente não fazer o menor sentido. Por não fazer a menor diferença.”
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.
June 12th, 2008 at 8:58 pm
“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/”
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++.
June 12th, 2008 at 11:07 pm
“Vinte ms é irrelevante para um sistema web.”
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.
June 12th, 2008 at 11:23 pm
“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++.”
Ah…entendi agora. Você quer dizer “vão rodar”, no sentido de “um dia vão rodar”. Pois é…talvez.