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

Ora, ora, ora…
Como foi comentado nesse blog do Buchheit, Java bem escrito costuma ser mais rápido que C++ não-otimizado ou portável.
Mas se você quiser, pode chegar tão perto do “metal” quanto quiser em C++. Em última instância, pode usar até “inline assembly”.
Por exemplo, copiar um arquivo usando java.nio é mais rápido que usar fopen/fread/fwrite em C++ para efetuar a cópia. Assim como alocar memória com Java é mais rápido que usar malloc/free em C++.
Mas se você se permitir usar as APIs específicas do sistema operacional no seu programa em C++, então a cópia será mais rápida. Tudo depende de quanto tempo você pode investir.

Repare que ele falou no GCC, usei um pouquinho e ele e lento para C++, bom para C, e agora parece que também para Java.

Até!

Ta… mas o GCC não é o compilador que melhor otimiza um código, se ele ao menos tivesse testado o compilador da intel, o i++ , acho que teriamos um bom retrospecto.

e quantos % do mundo usa o i++ ? me desculpe… temos que falar do mais utilizado… quantos projetos por ae vc ve compilado usando I++ ?

Normalmente você usa o icc (Intel C Compiler) se você quiser extrair até a última gota de desempenho de seu código em C, e estiver usando Windows ou Linux. (Se quiser o equivalente em Solaris, use o Sun Studio).
Nunca ouvi falar de “i++”, só de “g++” (o gcc para C++) ou de icc (o Intel C Compiler, que pode ser adaptado ao Visual Studio (Windows) ou ao gcc (Linux).

ops, i++ aqui é um link simbólico para o icc :oops:

De qualquer maneira, se você tem alguns dólares para gastar e tem um programa grande em C++, é interessante compilá-lo com o icc. Sempre pode ganhar alguns segundos de execução.

Só para deixar claro a opinião do autor:

Ou seja, ele disse que Java não é mais lento(costumava ser em suas versões iniciais) e que já pode ser considerado rápido a ponto de ser utilizado em diversas aplicações.

Sendo mais claro ainda, o foco da matéria era mostrar que Java pode ser tão rápido quanto as linguagens mais rápidas, e não dizer que é mais rápido que C++, inclusive em alguns testes dele o C++ foi mais rápido.

[]'s

Nossa, a discussão sobre a otimização que rolou nos comentários dá página é MUITO interessante… Do tipo, de quais otmizações a JVM pode fazer…

Mark said…
Paul - I think java does use the -ffast-math optimisation. It is used by default, and can be turned off using the ‘strictfp’ keyword.

Será isso verdade? Alguém já fez algum aplicativo geográfico / físico em java para nos falar a respeito?

igouy said…

Following on from Matthew's replacement of the while loop by a for loop ....

Simply using a while loop in an ordinary way maybe marginally faster than the for loop - </blockquote>

Quando programava em c/c++ (BREW) substituia sempre o for por um while, pela performace (mínima diferenca)… mas no meu mundo fazia diferença… isso faz diferença para alguem que desenvolve aplicativos/plataformas em Java?

Barry said…
You’re right I am guessing, and that’s the point. What you think the JVM is optimizing today may be completely changed in another version. So maybe in Java 7, even those for loops would be optimized out if you removed the trace statements. I’m actually surprised they’re not optimized now.
It’s clear the JVM is optimizing as the program runs. You can actually see the asterisks printing faster and faster as it runs. What’s not clear is what exactly is being optimized. Is it the math calculations, or the printing, a little of both, or something completely different? Maybe it figures out the program is printing the same thing over and over and compiles the program to simply
print “*”
print “**” etc. And the math is no longer needed. WOW! That would be something, wouldn’t it?

Será isso possível / válido? Se um loop não utilizar o resultado de uma chamada a metodo, ele simplesmente pode ignorar a chamada aaquele método, aumentando a performance. Achei a idéia fantástica e nunca tinha pensado nisso. Hoje o editor já é capaz de identificar váriaveis não utilizadas, então a JVM também poderia fazer o mesmo.

[]'s

Isso é possível se:

• O método for suficientemente pequeno (inlinable);
• Ele não tiver efeitos colaterais (uma “função pura”).

Se o método for muito grande, ou não for possível determinar que ele não tem efeitos colaterais, não é possível efetuar a tal otimização.

http://java.sun.com/products/hotspot/whitepaper.html

Apenas uma referência para o pessoal que se interessou pelo assunto de performance no Java:

http://www.javaperformancetuning.com

[]'s

cada dia que passa Java owna cada vez mais muitas tecnologias, detonando os “grandes” como o C, o Python (quando a Nuxeus, não lembro o nome, que era o maior conteúdo Python do mundo, trocou toda a sua arquitetura pra plataforma JBoss + Seam) e o Ruby (quando os testes de bm do JRuby vs Ruby mostraram que o JRuby era mais rapido)

parabéns a equipe da Sun e aos desenvolvedores que contribuem para a evolução da linguagem

e com isso, nós, desenvolvedores só temos a ganhar

Eu programo em Java mas algumas coisas no meu trabalho tenho que fazer em C. Cada vez estou mais convencido que nao ha qualquer desculpa hoje em dia para se perder tempo com C.

Programar em C eh como usar fita kacete para persistir dados hoje em dia, ou como usar aqueles telefones moveis que vinham numa maleta.

Eh simplesmente um atente ao meu precioso tempo e a minha baixa tolerancia ha coisas infernalmente complexas.

Essa semana estava compilando uma parada em Solaris e o compilador estava dando um monte de erros. Detalhe: O erro era mais ou menos assim: “Deu pau! Se vira para descobrir qual eh o problema!” O Google me salvou. Tinha que colocar uma flag louca no compilador para nao dar esse erro. Coisas sem qualquer cabimento logico…

Dai vc compila e quando executa eh um show de segmentation faults. Dai vc tem que resolver um a um colocando printf no seu codigo, pois usar gdb eh uma coisa para monges budistas.

Conclusao: Programar em C soh nos ultimos dos ultimos casos…

Tem um pessoal da minha faculdade (professores, um pessoal do INPE/CPTEC, etc) que não troca C puro por nada…
Eu não gosto muito de C porque é extremamente dificil fazer qualquer coisa. Acho legal para estudar e entender como as coisas funcionam “mais baixo nível”, mas fico só nisso. No meu trabalho programo 70% do tempo em Java e 30% em um sistema legado em C++. Não vejo diferença significativa de desempenho, mas sem dúvida Java é bem menos complexo que C++. Ainda assim, me divirto bastante com o C++. Mas realmente, usar GDB, ninguém merece…

Com o adendo dos processadores com cada vez mais nucleos hoje se encontra facil o de 4 nucleos… e a Intel tem previsao até 2012 o de 32 nucleos em escala industrial… a linguagem C vai perder cada vez mais mercado… pois fica cada vez mais dificil se aproveitar o poder de um computador usando linguagem C sem programacao Multithread… e garanto que se programar em C já é uma complicação desnecessária em dias de hoje (salvo em alguns quisitos) , fico imaginando programar em C usando Multithread…

Vejo C apenas como solucao para acesso a dispositivos em baixo nivel, já que linguagens como Java que são de uso geral que não fazem interface diretamente com o sistema operacional. ( o que na minha opiniao é uma pena. )

Tem professor que não troca C por nada simplesmente porque deve ser dificil para eles aprender alguma linguagem mais moderna.

Agora, C não é de todo ruim, basta saber o que se esta fazendo.

isso , ou como diz o saoj , basta ser um Monge Budista !

chun:

Com o adendo dos processadores com cada vez mais nucleos hoje se encontra facil o de 4 nucleos… e a Intel tem previsao até 2012 o de 32 nucleos em escala industrial… a linguagem C vai perder cada vez mais mercado… pois fica cada vez mais dificil se aproveitar o poder de um computador usando linguagem C sem programacao Multithread… e garanto que se programar em C já é uma complicação desnecessária em dias de hoje (salvo em alguns quisitos) , fico imaginando programar em C usando Multithread…

Vejo C apenas como solucao para acesso a dispositivos em baixo nivel, já que linguagens como Java que são de uso geral que não fazem interface diretamente com o sistema operacional. ( o que na minha opiniao é uma pena. )

Em Java, hoje, você é capaz de definir o que cada processador fará com seu programa? Ou você só escreve o programa e deixa a JVM se virar com isso?

E como C não tem Multithreads? pthread / windows / SDL…

Não esquece que também é preciso saber o que se faz em Java… geralmente o problema não é a linguagem, é o programador. (;

abilio:

cassio:

Tem um pessoal da minha faculdade (professores, um pessoal do INPE/CPTEC, etc) que não troca C puro por nada…
Eu não gosto muito de C porque é extremamente dificil fazer qualquer coisa.

Muitos professores universitários simplesmente pararam no tempo, ou sequer dominam o assunto que se propõe a lecionar. A comprovação final que tive deste fato foi quando um professor de redes que tive, ter falado que redes locais Token Ring ainda são largamento utilizadas (e devem estar rodando netware rsrs). Teve um outro também que afirmou ceticamente que o sendmail não é um daemon, pois um apesar dele escutar ficar rodando em background e escutar numa porta “daemons geralmente tem alto nivel de complexixade” (!?!?!?!). Enfim, nem sempre confie no que alguns professores de cursos superiores de tecnologia dizem.

O fato não é que os professores pararam no tempo (tudo bem, alguns deles pararam sim) mas é que programação para computação científica é um mundo completamente diferente. Para este tipo de software, C funciona melhor, até mesmo fortran é muito usado ainda. Quase ninguém nesta área escreve nada OO, é tudo estruturado. E pode acreditar, eles fazem isso de propósito.
São programas para cálculo matemático, discretização de equações diferenciais, utilização de matrizes de double da ordem de 10000 x 10000, etc…
Não duvido que Java possa ser tào rápido quanto C neste ponto (claro, com as devidas otimizações e opçòes de compilação), mas já existe muita coisa rodando feita em C / Fortran (de vez em quando C++) e existe também um problema chamado tradição.
Enfim, será por isso que a previsão de tempo sempre falha?

bandrade ,

Leia direito , eu nao disse que C nao é possivel programar em multithread… estou dizendo que é BEM COMPLICADO… se um programa SingleThread eh um kct imagina um multithread…

Quanto a outra questao… a JVM cuida disso para voce… como comentei… se vc quer descer o nivel a ponto de querer fazer “tal coisa dependendo do processador” , entao… use C

Quanto ao problema nao ser a linguagem… consideremos um programador de nivel mediano… que ele faca um ERP em C do zero… e faca depois usando Java ou Python ou qualquer outra coisa atual… e dae vc me diz se o problema é a linguagem ou programador C puro para aplicações comerciais nem fodendo… no maximo uma JNI acessando o dispositivo e só… o resto uso algo com que consiga dar manutencao facilmente

Olá

Sobre threads…

Vamos falar a verdade: pouquíssimos programadores Java tem alguma noção sobre o que é programar usando threads. A maioria esmagadora nem sente necessidade de aprender programação concorrente.

Destes poucos que tem necessidade de usar threads, a maioria usa mal o conceito de programação concorrente.

Seria melhor se o Java tivesse um mecanismo mais automatizado para o uso de threads. Talvez algo como tipos de dados realmente imutáveis pudesse facilitar bastante.

[]s
Luca

Luca… o proprio ClassLoader nao faz uso de multrehad na carga das classes ? automaticamente ele já não faz uso de varios processadores neste tipo de operacao ?

Luca:
Programação concorrente é um conceito relativamente dificil… sincronizar coisas, evitar dead-locks.

Alguém aí sabe porque não há ‘const’ em java? Existe o final. Mas em C o valor de uma variável const deve ser setada na declaração… Além dessa, alguém sabe as outras diferenças?

chun:
Um sistema ERP é difícil independente da linguagem. Concordo que C pode ser mais dificil de implementar algumas coisas e que hoje em dia não vejo porque alguém comecaria um sistema em C (a não ser nos casos já citados de ter que tratar muito com hardware ou aplicações em tempo real)

brandrade ? Tempo real ? JSR-1 “Real-time Specification for Java” ?

ueh… para mim const e final sao a mesma coisa… explique a diferenca mais claramente por favor.

Também não sei exatamente a diferença entre os 2… no C eu faço assim:

const int minhaConstante = 10;

Com essa declaração, minhaConstante é imutavel, pra sempre, desde a criação. Na declaração eu devo informar o valor da constante.

Além disso, eu posso usar const no retorno ou parâmetro de métodos… é um bocado bagunçado. (em java tb rola de colar final em retorno/parametro de metodo, mas sinceramente, não sei para que serve) );

Em java, vc pode fazer assim:

final int minhaConstante; ... ... void metodoFake(int x){ minhaConstante = x; }
O valor da constante pode ser setado em qualquer lugar, além de que final em Java pode ser usado em classes (a classe com final não pode ser extendida.
Final também pode ser usada em métodos, que não poderão ser sobreescritos. (lembrando que metodos static e privados são automaticamente ‘finals’

Você sabe do que você tá falando? Você já usou o JSR-1? Sabe o que significa tempo real? Conhece alguma implementação madura do JSR-1?

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! )

Você sabe do que você tá falando? Você já usou o JSR-1? Sabe o que significa tempo real? Conhece alguma implementação madura do JSR-1?

Calma cocada… estou PERGUNTANDO e nao afirmando.

Quanto a JSR-1

thingol:

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… ?

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

#include <omp.h>
#include <stdio.h>
#include <windows.h>

    static long num_steps = 100000;
    double step;
#define NUM_THREADS 10

int main (int argc, char *argv[]) {
/*
    double A [1000];
    omp_set_num_threads (4);
    #pragma omp parallel
    {
        int id = omp_get_thread_num();
        printf ("OMP Thread %d - Windows Thread %d\n", id, GetCurrentThreadId());
    }
    printf ("Finally: OMP Thread %d - Windows Thread %d\n", omp_get_thread_num(), GetCurrentThreadId());
*/
    int i;
    double x, pi, sum = 0.0;
    step = 1.0 / (double) num_steps;
    omp_set_num_threads (NUM_THREADS);
    #pragma omp parallel for reduction (+:sum) private (x) 
    for (i = 1; i &lt= num_steps; i++) {
        x = (i - 0.5) * step;
        sum = sum + 4.0 / (1.0 + x * x);
    }
    pi = step * sum;
    printf ("%.10f\n", 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 ?

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.

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

__declspec (thread) int myvar;
...
printf ("%d\n", myvar);

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

static ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
    public DateFormat initialValue() {
        return new SimpleDateFormat ("dd/MM/yyyy");
    }
}
...
System.out.println (df.get().format (new java.util.Date()));

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.

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

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…

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…

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.

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…

Interessante. Acho que aqui vc respondeu a minha pergunta de casos onde C resolve e Java nã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.