Sistemas O.O. não são apropriados para grandes demandas (milhares de transações/hora)

Assuntos Gerais
#41

É a diferença do teoricamente possível, do realmente possível.
Teoricamente é possível fazer em assembly um programa mais rápido que em C.

Mas, na prática, isso não é possível:

  1. Compiladores NUNCA perdem uma chance de otimização;
  2. Organização do código contribui para boa performance;
  3. O número de bugs é incrivelmente reduzido (e bota incrivelmente nisso);
  4. Um compilador específico conhece centenas de instruções específicas, além de técnicas de otimização. Mesmo que você seja bom em assembly, tente entender um código gerado em C com compilação o3 num compilador específico da Intel, e você vai ver o que estou falando.

Na Siemens, constatamos que programar em C com muito cuidado era mais fácil e gerava código mais rápido do que em assembly. Mesmo com desenvolvedores experientes nas duas plataformas e altos investimentos em otimização. O que não significa que pequenas rotinas muito específicas fossem escritas em ASM, mas aí, em trechos bastante restritos e críticos.[/quote]

Sem falar que a linguagem c foi criada justamente para se poder ter os mesmos recursos do assembly em uma linguagem de nível mais alto. Hoje é praticamente inviável escrever um aplicação em assembly. Digo aplicação, mas em hardware ou partes críticas de programas(como funções de copia e transferência de dados na memória Ex: memcpy, copymem, ZeroFill) ainda é amplamente utilizado assim como c.

#42

Tem gente criando aplicação web com C++ http://www.webtoolkit.eu/wt

Recentemente eu li um estudo sobre custo operacional destas aplicações. Em larga escala (casos como Facebook), vale muito à pena. Assim que encontrar o link repasso aqui.

#43

Yeap, existe programação orientada a objetos em COBOL: http://www.netcobol.com/info/whitepaper/oocoby2k.pdf

#44

Teoricamente qualquer linguagem pode ser orientada a objetos, já que isso é uma metodologia. Basta aplicar os conceitos em qualquer uma delas. O problema das linguagens que não suportam esse conceito é a dificuldade em se empregar a metodologia. Existe um exemplo de interfaces com c++.

Em c também é perfeitamente possível, tanto é que temos o seu set objective c, que nada mais é que a linguagem c.

#45

[quote=kicolobo]Pra enriquecer um pouco a discussão, encontrei um post interessante: “Java for HPC” que tem links muito interessantes

http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html[/quote]

Esse artigo é muito esclarecedor mesmo kiko. Por uma questão de magnitude c++ tem melhor desempenho que java, mas escrever um bom software em java é mais fácil que um bom software em c++. Então este é o motivo do software java se equiparar ou até mesmo ser uns 50% mais rápido. Tudo questão de otimização de código de máquina no final das contas(Quanto menos código melhor para o processador).

#46

É a diferença do teoricamente possível, do realmente possível.
Teoricamente é possível fazer em assembly um programa mais rápido que em C.

Mas, na prática, isso não é possível:

  1. Compiladores NUNCA perdem uma chance de otimização;
  2. Organização do código contribui para boa performance;
  3. O número de bugs é incrivelmente reduzido (e bota incrivelmente nisso);
  4. Um compilador específico conhece centenas de instruções específicas, além de técnicas de otimização. Mesmo que você seja bom em assembly, tente entender um código gerado em C com compilação o3 num compilador específico da Intel, e você vai ver o que estou falando.

Na Siemens, constatamos que programar em C com muito cuidado era mais fácil e gerava código mais rápido do que em assembly. Mesmo com desenvolvedores experientes nas duas plataformas e altos investimentos em otimização. O que não significa que pequenas rotinas muito específicas fossem escritas em ASM, mas aí, em trechos bastante restritos e críticos.[/quote]

Ué e só o cara ter um compilador no cerebro… Chuck Norris não usa compilador… compila tudo com o cerebro e injeta com um randhousekick as instruções direto no processador… alias chuck norris não precisa de processador… :lol:

#47

Chuck Norris não tem celebro, tem cérebro =)

#48

Um case de ambiente critico que foi migrado do mainframe para “baixa” plataforma(.Net) é a Bolsa de Valores de São Paulo. Diversos sistemas de billing das maiores operadoras de telefonia do pais são feitos em java e rodam em servidores e bancos de dados que não estão em mainframe. Então é balela que não da pra migrar sistemas em mainframe(COBOL) pra plataformas como JEE ou .Net. Outra coisa, não é o fato da aplicação ser escrita em COBOL que faz dela mais rápida, no caso de uma ambiente mainframe e sim o CICS, que é um monitor de transações. E digo mais, da pra escrever aplicações CICS em java se quiser.

#49

+1 aqui que desenvolve uma aplicação em Java para uma grande quantidade de requisições(média de 1600/minuto) que inclui transações da grande maioria das bolsas do mundo(Bovespa, Chicago, NY, etc).
E como dito, o paradigma não tem quase influência, nosso maior gargalo é sempre I/O

#50

[quote=Rafael Nunes]+1 aqui que desenvolve uma aplicação em Java para uma grande quantidade de requisições(média de 1600/minuto) que inclui transações da grande maioria das bolsas do mundo(Bovespa, Chicago, NY, etc).
E como dito, o paradigma não tem quase influência, nosso maior gargalo é sempre I/O[/quote]

É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).

#51

[quote=YvGa][quote=kicolobo][quote=s4nchez]Eu trabalho num sistema que lida com milhoes de transacoes diarias, escrito em java (totalmente OO) e rodando na amazon sem problema.

Seu professor comeu bola e quem ta concordando precisa dar uma estudada melhor antes de dar opiniao baseada em chute.[/quote]

SIm, é possível, mas executaria muito mais rápido em COBOL, C ou alguma outra linguagem não OO.[/quote]

Mas isso eh bem diferente de dizer que nao sao apropriados.

[/quote]

Cara acho que faltou é a definição de apropriado.
depende dos requisitos não funcionais da app

#52

[quote=juliocbq]
É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante). [/quote]

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.

#53

[quote=Rafael Nunes]+1 aqui que desenvolve uma aplicação em Java para uma grande quantidade de requisições(média de 1600/minuto) que inclui transações da grande maioria das bolsas do mundo(Bovespa, Chicago, NY, etc).
E como dito, o paradigma não tem quase influência, nosso maior gargalo é sempre I/O[/quote]

Eu não duvido nada que “sistemas O.O.” do titulo do tópico na verdade é uma referência a sistemas que acessam SGBDs, mais do que propriamente sistemas orientado a objetos.

#54

[quote=Rafael Nunes][quote=juliocbq]
É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante). [/quote]

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.[/quote]

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

#55

[quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante). [/quote]

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.[/quote]

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

[/quote]

Na maioria dos casos este tempo é insignificante… mais dependendo da app pode ser sim muito significativo…

#56

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)

#57

[quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante). [/quote]

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.[/quote]

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

[/quote]

Você ainda está preso a manipulação, io está mais relacionado ao trabalho do recurso. O Rafael está falando de IO Bloqueante. Da forma convencional não se pode fazer muita coisa além de diminuir o tempo de espera pelo recurso. E a alternativa seria trocar para uma abordagem como node.js, que usa callbacks.

#58

[quote=Rafael Nunes][quote=juliocbq]
Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).
[/quote]

A experiência que tenho com JNI neste projeto é o contrário.
Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI.

E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)[/quote]

Se você usar o driver da Oracle está usando jni.

Se a conexão se mantém firme você não vê diferença porque tudo isso foi carregado na memória ram. A partir do momento que o mapeamento é carregado, é onde acontece o overhead(onde se tem a perda de desempenho). Se já foi carregado ae não é nem mais java, é assembly.

#59

Ouvi dizer que o peido da formiga-leão pode afetar as moléculas transientes que compõem o éter multidimensional onde trafegam as meta-informações extra-sensoriais usadas pelos frameworks abstratos auto-replicantes…

Esse fórum tá muito “legalize” hoje.

#60

[quote=bobmoe][quote=juliocbq][quote=Rafael Nunes][quote=juliocbq]
É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante). [/quote]

Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.[/quote]

Me referi de forma geral também. A maioria delas ae são mapeamentos.

Exemplo: Driver de algum Banco(Mysql ) // A sua conexão com o banco de dados usa uma biblioteca que é um mapeamento de uma nativa.

Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).

[/quote]

Você ainda está preso a manipulação, io está mais relacionado ao trabalho do recurso. O Rafael está falando de IO Bloqueante. Da forma convencional não se pode fazer muita coisa além de diminuir o tempo de espera pelo recurso. E a alternativa seria trocar para uma abordagem como node.js, que usa callbacks.[/quote]

IO é a troca de dados entre recursos, e pode ser software ou hardware. O fato é que se você mapear um recurso nativo, no momento que você carrega ele na memória você tem uma perda consistente no desempenho.

Este artigo é bem interessante
http://www.javamex.com/tutorials/jni/

http://www.javamex.com/tutorials/jni/overhead.shtml

Aqui uma comparação do mapeamento da opencv da Intel, com a execução da biblioteca nativa

http://code.google.com/p/javacv/wiki/SpeedComparisons

É claro que se você usa um recurso nativo, dependendo da biblioteca sua aplicação terá um ganho de desenpenho maior, mas isso não está somente relacionado ao fato do recurso ser nativo.