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

Assuntos Gerais
#22

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 :slight_smile:

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 :slight_smile: 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

#23

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

#24

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 ?

#25

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)

#26

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.

#27

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’

#28

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?

#29

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

#30

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?[/quote]

Calma cocada… estou PERGUNTANDO e nao afirmando.

Quanto a JSR-1


#31

[quote=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! )

[/quote]

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

#32

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.

#33

E vc acha isso mais facil de mecher/manter ?

#34

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

#35

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

#36

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.

#37

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()));
#38

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.

#39