Lider do GMAIL afirma: Java é mais rápido que C

thingol wrote:Se você vai fazer contas em C/C++ ou Fortran e precisa usar multiprocessamento (podendo usar threads ou não - isso fica a cargo do compilador) ou máquinas vetoriais, basta usar uma extensão relativamente portável chamada OpenMP. Ela está disponível nos compiladores da Sun, da Microsoft, da IBM e da Intel, pelo menos.

Isso está disponível em várias arquiteturas e compiladores (mesmo o MS Visual Studio 2005 tem isso disponível! )

como que o compilador vai sair quebrando meu processo em varias threads ? e o controle ? dead locks , etc... ?

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

Se você compilar este programa no MS Visual Studio 2005, vai ver que ele calcula o valor de pi.

Aqui no caso, há alguns controles (número de threads, modo de lidar com o "for" - essa coisa maluca de usar "#pragma omp parallel for reduction (+:sum) private x" e outras coisas.) (O pedaço de código comentado é uma maneira de ver que o OpenMP está realmente usando threads).

Aprender a usar direito esses pragmas é uma arte, mas o bom é que seu programa pode ser, com algumas adaptações, rodado em uma máquina Sparc com 32 núcleos sem problemas, e dando o mesmo resultado.

E vc acha isso mais facil de mecher/manter ?

chun wrote:E vc acha isso mais facil de mecher/manter ?

Faça o código acima em Java, e que rode com um consumo de memória e velocidade de processamento parecido.

Olá

Thingol, vou aproveitar sua levantada de bola.

O OpenMP, que a Intel anda fazendo o maior estardalhaço, já é bem antigo. Na prática usa a modo de resolver problemas "divida e conquiste" que é o mesmo da técnica Fork/Join que vem no Java 7. Há vários modos de se resolver problemas concorrentes e o Fork/Join é um deles.

O exemplo do PI era um dos exemplos que eu ia mostrar na minha palestra do JustJava. Mas segundo o Doug Lea, o Fork/Join só apresenta vantagens reais a partir de máquinas com 4 processadores e eu preciso que apareça uma alma caridosa com acesso a um ambiente destes para fazer os testes para mim.

Alguém aí se oferece para testar para mim programinhas Java (no mínimo versão 1.5) em ambientes com mais de 2 processadores?

[]s
Luca

Curioso, mas existem ainda um monte de razões para Java não ser sequer cogitado no lugar de C:

-Consumo de memória, para dispositivos compactos utilizar Java pode ser um desastre, já que a JVM consome uma enormidade de recursos e a KVM é quase uma ordem de magnitude mais lenta que a HotSpot.

-Múltiplas aplicações, se você precisa rodar multas aplicações simultâneamente, Java é sua útlima escolha, image implementar em Java os Widgets do Dashboard do mac? Imagive você ter umas 10 JVM rodando simultâneamente, cada uma chupando 10M de ram. Quando o programa equivalente em C consome uma pequena fração disso.

-Integração com SO ou necessidade de executar operações de baixo nível como geração dinâmica de código. Para isso é dificil imaginar como Java poderia ser útil, por sinal.

Quanto a programação concorrente, Java usa o mesmo modelo que c, apenas ter uma biblioteca um pouco mais requintada. Todas construções e facilidades existem para C/C++. Outra coisa, Java ainda é uma piada ainda quando o assunto é programação concorrente por uma enorme série de motivos:

-Quanto maior o número de cores e memória RAM, maior o tempo desperdiçado com GC. Dado que não existe nenhuma JVM com suporte a GC realmente concorrente - O Metronome não entra nessa categoria pois ele é para sistemas realtime, então possui outros tradeoffs. Experimente rodar java com 16 cores e 32Gb de ram, vai ver que quase 40% do tempo vai ser torrado pelo GC.

-Java não possui nenhum recurso para criar aplicações no estilo Fork/Join tão facilmente quanto com OpenMp ou as extensões paralelas do fortran. Com Lisp é trivial escrever uma implementação de for/all e map/reduce usando múltiplas threads, com Java isso consome algumas centenas de linhas de código e fica com uma enorme cara de bacalhau.

-Thread local storage no Java é sofrivelmente lenta, além de ser um vespeiro para memory leakage. Compare com C, onde o custo de acessar uma variavel threadlocal é quase a mesmo que uma variavel volatile. Em Java com ThreadLocal você precisa passar por um HashTable primeiro.

-Se você quiser usar coisas como SIMD ou CUDA com Java, aquele abraço, vai precisar de C.

No geral, programação paralela é algo extremamente dificil, eu já apanhei muito de programas que supostamente eram simples e os bugs levavam semanas para serem descobertos em produção.

Não acho que o modelo do Java ou do C seja útil para consumo em massa, pois a grande maioria dos programadores, nossos code monkeys, não vão conseguir produzir nada funcional apenas esmurrando o teclado, como fazem no dia a dia.

Java e C são linguagens com utilidades distintas e já fazem alguns anos que performance deixou de ser motivo para qualquer argumento.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17539 Offline

-Thread local storage no Java é sofrivelmente lenta, além de ser um vespeiro para memory leakage. Compare com C, onde o custo de acessar uma variavel threadlocal é quase a mesmo que uma variavel volatile. Em Java com ThreadLocal você precisa passar por um HashTable primeiro.

De fato em C (Microsoft C pelo menos; acho que deve haver algo parecido em outros Cs) é estupidamente fácil:

E em Java, mesmo com Generics, é um lixo:

louds wrote:
-Consumo de memória, para dispositivos compactos utilizar Java pode ser um desastre, já que a JVM consome uma enormidade de recursos e a KVM é quase uma ordem de magnitude mais lenta que a HotSpot.

Sim, me lembro que para Palm a linguagem oficial era C. Me lembro que fiquei dois dias para conseguir imprimir um Hello World na tela e sempre pensava que deveria existir pessoas que faziam aquilo em 2 minutos.

Por essas e outras é que eu nunca levei muita fé em programação para dispositivos móveis. Nunca achei um mercado promissor. E sempre admiti que eu poderia estar errado, mas eu particularmente nunca me interessei por isso.

-Múltiplas aplicações, se você precisa rodar multas aplicações simultâneamente, Java é sua útlima escolha, image implementar em Java os Widgets do Dashboard do mac? Imagive você ter umas 10 JVM rodando simultâneamente, cada uma chupando 10M de ram. Quando o programa equivalente em C consome uma pequena fração disso.

Não tinha uma história que uma VM só iria rodar vários aplicativos Java para resolver esse problema?

-Integração com SO ou necessidade de executar operações de baixo nível como geração dinâmica de código. Para isso é dificil imaginar como Java poderia ser útil, por sinal.

Hoje em dia a necessidade de executar operações de baixo nível é muito baixa, visto que existe API para tudo em Java. Mas sim, haverá execessões. Não consigo imaginar qual agora, mas se vc souber de uma situação que o Java não trata e temos que descer o nível posta aí como curiosidade. Vc não tem como gerar bytecode dinamicamente com Java? Acho que na 1.7 dá até para compilar dinamicamente...

Quanto a programação concorrente, Java usa o mesmo modelo que c, apenas ter uma biblioteca um pouco mais requintada. Todas construções e facilidades existem para C/C++. Outra coisa, Java ainda é uma piada ainda quando o assunto é programação concorrente por uma enorme série de motivos:

-Quanto maior o número de cores e memória RAM, maior o tempo desperdiçado com GC. Dado que não existe nenhuma JVM com suporte a GC realmente concorrente - O Metronome não entra nessa categoria pois ele é para sistemas realtime, então possui outros tradeoffs. Experimente rodar java com 16 cores e 32Gb de ram, vai ver que quase 40% do tempo vai ser torrado pelo GC.

O GC vai sempre gastar tempo, mas se vc programar CONTRA o GC vc se safa disso. Aqui por exemplo é proibido usar GC, ou seja, usamos pool de objetos pra tudo. Não sei se é possível desligar o GC em Java...

-Java não possui nenhum recurso para criar aplicações no estilo Fork/Join tão facilmente quanto com OpenMp ou as extensões paralelas do fortran. Com Lisp é trivial escrever uma implementação de for/all e map/reduce usando múltiplas threads, com Java isso consome algumas centenas de linhas de código e fica com uma enorme cara de bacalhau.

Pensei que com as novas sacanagens do java.util.concurrent, as coisas mais sinistras, do tipo ConcurrentSkipListMap, tinham sido implementadas. C provavelmente não terá um objeto desse padrão da linguagem, testado e feito por um cientista da área.

-Thread local storage no Java é sofrivelmente lenta, além de ser um vespeiro para memory leakage. Compare com C, onde o custo de acessar uma variavel threadlocal é quase a mesmo que uma variavel volatile. Em Java com ThreadLocal você precisa passar por um HashTable primeiro.

Sim, seria o caso de melhorarem isso nas próximas versões, pois se dá para fazer em C, deve dar para fazer em Java de maneira descente...

-Se você quiser usar coisas como SIMD ou CUDA com Java, aquele abraço, vai precisar de C.

Interessante. Acho que aqui vc respondeu a minha pergunta de casos onde C resolve e Java não...

No geral, programação paralela é algo extremamente dificil, eu já apanhei muito de programas que supostamente eram simples e os bugs levavam semanas para serem descobertos em produção.

Concordo plenamente com vc. Passei por uma experiencia interessante onde todo o meu framework era SINGLE-THREADED usando java.nio e percebi que concorrencia é o "the root of all bugs". Tem casos que não dá para fugir, mas sempre que possível fuja de programação paralela, pelo bem da produtividade.

Notícias, artigos e o maior fórum brasileiro sobre Java