| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Essa está boa... :)
Se a JVM é feita em C, como pode o java ser mais rápido que C? Se é, então é porque o código C em questão está mal escrito. Claro que a JVM deverá ter optimizações em assembly, mas isso não explica tudo.
|
| |
| |
| | A explicação é simples:
Um programa em C/C++ tem de ser optimizado no processo da compilação, altura em que o compilador não conhece exactamente as condições em que vai executar (qual o código mais frequentemente executado e quais os fluxos mais prováveis de execução, etc.), não sabendo assim onde aplicar mais o seu esforço. O Intel C++ resolve parcialmente esta questão recorrendo a executáveis modificados que geram estatísticas de execução que depois podem voltar a ser fornecidas ao compilador para o ajudar a optimizar. Ora o Java não precisa disto, pode recolher estatísticas ao longo da execução e alterar o código JIT gerado de acordo com elas (ou não gerar nada se o código em causa não justificar o overhead da compilação JIT). Se juntarmos o facto do Java só recolher a memória libertada pelo programa quando lhe convém (tempos mortos ou falta de memória), percebemos porque consegue levar vantagem em alguns casos.
É claro que isto só acontece em programas com tempos de execução longos.
-- Carlos Rodrigues
|
| |
| | Hmm... Implementa lá uma balanced binary tree em java e demonstra essa performance superior em todo o seu explendor contra C/C++... Esta discussão entre C e Jva é completamente ridícula, porque estamos a falar de linguagens com níveis de abstracção diferentes. Todos os exemplos que vi até hoje em benchmarks que dizem que Java é mais rápido incluíam código muito mau em C, portanto só posso deduzir que quem fez os testes não sabe programar C decentemente. No entanto, se alguem aqui no gildot quiser rebater isto, desafio-o a uma demonstração: o meu código em C contra o de alguem em Java. Assim temos uma comparação mais justa.
Como protesto contra a ridicularidade das novas políticas do gildot, todos os meus comentários serão colocados sem possibilidade de resposta. |
| |
| | Como eu já disse, não acontece em todos os casos e precisa de algum tempo de execução para ocorrer. Quanto mais tempo correr a aplicação (e desde que tenha um padrão minimamente regular), mais informação a VM vai ter e mais vai conseguir optimizar. Não te esqueças que, apesar das linguagens compiladas poderem em teoria ser optimizadas globalmente, tal não acontece por duas razões:
- levaria a tempos de compilação descomunais;
- se o compilador for demasiado agressivo pode escavacar o executável em algumas situações que ele possa não ter previsto.
Ora uma VM pode fazer ambas as coisas, porque analisa a execução e não o código. Pode optimizar para o padrão actual com um certo grau de confiança que isso vai melhorar a performance. Se se enganar, pode sempre voltar atrás e refazer o trabalho para o código afectado.
O problema é que o pessoal normalmente só olha para o Java aplicado ao desktop, ou a aplicações afins, onde raramente há padrões regulares e/ou tempo de execução suficientemente prolongado para que a VM mostre aquilo que é capaz de fazer.
-- Carlos Rodrigues
|
| |
| | O problema é que (como disse antes) estão a comparar linguagens com níveis de abstracção diferentes. Em C/C++ é possível optimizar logo enquanto se programa, porque podem usar-se caminhos mais curtos para obter os mesmos resultados dependendo do que se pretende obter. É aqui que as linguageis de níveis mais altos (mais abstractas) falham, e é aqui que os benchmarks falham também, porque tratam C como tratam uma linguagem de mais alto nivel (como no caso das arrays), o que é errado.
Como protesto contra a ridicularidade das novas políticas do gildot, todos os meus comentários serão colocados sem possibilidade de resposta. |
| |
| | A optimização pelo programador está sobreestimada. É certo que podes (e deves) optimizar escolhendo algoritmos melhores e evitando algumas armadilhas, mas isso é possível em C e em Java. Quando começas a tentar optimizar demais, acontece uma de duas coisas, ou tornas o código ilegível, ou não optimizas nada.
Repara que eu não estou a dizer que o Java seja sempre mais rápido, mas apenas que tem potencial de ser mais rápido (e é em alguns casos).
-- Carlos Rodrigues
|
| |
| | | tem potencial de ser mais rápido (e é em alguns casos). Prova-o. Arranja um desses casos que eu proponho-te uma alternativa em C.
|
| |
| | | Todos os exemplos que vi até hoje em benchmarks que dizem que Java é mais rápido incluíam código muito mau em C Eu não iria tanto por aí. Normalmente os benchmarks acabam por obter a atenção dos experts em qq das linguagens que optimizam as respectivas implementações. Trata-se mais de aplicações onde o JIT pode brilhar: acessos a arrays com indices literais, e ausência ou pouco uso de new(), exceptions, herança de classes e sobretudo interfaces. Aí o java pode aproximar-se da performance de C, mas não batê-la (ver #18).
|
| |
| | | Welcome to the world of JIT compilers...
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | O que acontece é que quem faz as benchmarks faz código do género em que chamam mallocs e afins de coisas que não são usadas depois. O código de Java acaba por ficar muito mais rápido pois em Java quando um objecto não é usado, nem sequer é criado. Ou seja, estes benchmarks não se aplicam a programação a sério.
|
| |
| | Ou seja, estes benchmarks não se aplicam a programação a sério.
Mas há algum que se aplique? :)
|
| |
| | Claro que não é por isso que eu uso tcl...
Essa cena dos benchmarks é uma treta.. tcl é tão rápido como qualquer outra linguagem compilada.
... Ou então não. |
| |
| | Pois... eu uso shell scripts pela mesma razão... ?
|
| |
| | ou então não, MESMO!
-----
Microsoft has funded 13 studies over the past year comparing Linux with its own products. Guess what: All of them come out in favor of Microsoft. |
| |
| | | O que e' "programacao a serio" ? E' claro que o facto de o Java ter um garbage collector tem um impacto na performance: positivo.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | | E' claro que o facto de o Java ter um garbage collector tem um impacto na performance: positivo. Exactamente. Com garbage collecting, java é quase tão rápida como o great kat a tocar guitarra. Se a isto lhe juntarmos "array bounds checking", um stack apenas para referências e tipos primitivos, todos os métodos virtuais by default, e os belos desses interfaces, então aí temos assembler puro, só que dinâmico...
|
| |
| | Repara que métodos virtuais e bounds checking têm um impacto negativo.
-- Carlos Rodrigues
|
| |
| | Estava a ser irónico. Todos os factores que mencionei têm impacto negativo em performance, tal como garbage collection (GC). Isto é fácil de provar. Existem estudos que quanto muito atribuem penalização quase zero entre GC e um sistema de alocação explícita, mas a partir de um dado threshold de memória consumida a mais do que a necessária (7x aparece referenciado frequentemente: ou seja, à custa de desperdicio de 6x memória é que a performance em GC pode ser comparável). Mesmo assim existem penalizações no processamento do "collecting" que é simplesmente ZERO no caso manual, embora admitidamente possa ser desprezável para longos runtimes.
|
| |
| | Não estás a ver a "big picture" e esse é o teu problema. Recolher a memória consome CPU, e se essa recolha for feita à custa de "free()" ou "delete", existe consumo de CPU durante todo o tempo de execução, de uma forma regular. Ora se usares um garbage collector, essa recolha só é feita em caso de necessidade (falta de memória) ou quando a carga do programa é suficientemente baixa. Isto tem enormes vantagens do lado do servidor, porque permite aguentar um burst de transacções maximizando a performance. Nestas situações o garbage collector é mais eficaz que a recolha manual.
Se no total ele consome mais CPU, isso é verdade, mas num servidor que está com pouca carga, qual é o problema de consumir CPU se isso poupar quando a carga é elevada?
Obviamente que isto se faz à custa de memória, mas o garbage collector também pode ser suficientemente inteligente para ajustar o seu threshold de "falta de memória" para o padrão de utilização da aplicação. E o facto de se correr em modo "-client" (default) ou "-server" também afecta bastante o consumo de memória.
-- Carlos Rodrigues
|
| |
| | | Não estás a ver a "big picture" e esse é o teu problema. Obrigado. Durante muito tempo procurei descobrir, sem sucesso, qual era o meu problema.
Quanto ao resto, vê o #18, por favor.
|
| |
| | O que dizes nesse comentário não altera em nada o que eu digo. Continuas a esquecer-te que reconhecer o padrão de execução de uma aplicação pode permitir optimizações significativas, que um compilador nunca consegue alcançar. É como levar a lógica que hoje em dia qualquer CPU decente tem e levá-la ao extremo.
-- Carlos Rodrigues
|
| |
| | Claro que altera. Tinhas acabado de dizer que o uso de GC na prática tornava um programa mais rápido. Se reparares nos tempos assimptóticos vês que isso não é verdade.
|
| |
| | | A Great Kat. É uma mulher... O facto de usar garbage collecting permite usar estratégias de alocação/dealocação simplificadas que podem, nos casos mais extremos, reduzir o custo de alocar objectos em heap a um custo da ordem do da alocação em stack.
OS métodos "virtuais by default" também não são grandes problemas, porque a JVM tem o luxo especular sobre isso muito mais agressivamente que um compilador.
O custo de fazer bounds checking também pode ser eliminado em muitos casos. O facto de as arrays serem objectos e não referências para um elemento da array como no C também permite melhores optimizações (menos problemas de aliasing). Também questões como o facto de os programas em Java beneficiarem de facto de optimização enquanto muitos programas em C/C++ não são compilados com optimização (e não é tão simples como meter uma flag no compilador). PS: Isto é, obviamente, um comentário do contra e nada equilibrado.
|
| |
| | | Tens razão numa coisa: great kat é uma mulher. Vejamos: alocação explícita custa no seu pior O(N) na alocação e O(1) na libertação. GC: O(N), O(N*M) (M: espaço alocado, N: espaço total). Com optimizações podemos ter quase O(1)/O(1) no caso explícito e O(1)/O(N) para GC. Conclusão: até um dado threshold GC pode ser *quase* equivalente, depois é mais lento. Consome sempre muito mais memória. Como é que isso afecta as *outras* aplicações que correm na máquina? Os métodos virtuais podem ser reduzidos a finais em alguns casos, mas com interfaces isso logo À partida não se faz (ponto final). Com herança simples é mais difícil e com herança via classloading ainda mais. E a decisão sobre fazer isto ou não tem que ser feita em runtime. Pode simplesmente sair mais barato fazer dupla indirecção de ponteiros! Quanto ao bound checking, podia ser eliminado em *alguns* casos-- notavelmente muitos dos presentes nas benchmarkings tipicas: for (int i=0; i<8; i++) /* A[i] ... */ -- mas na maior parte dos casos reais não pode. Quanto ao facto de serem objectos, foi um mero expediente "by Sun" "to manage" arrays. Como é que passavas um array como parâmetro de outra forma? De resto o "restrict" de C permite optimizações sobre ponteiros, tal como são. Conclusão: java é lento by design, tal como C#/.NET. É lento porque faz mais coisas implicitamente. No fim do dia, tudo se resume a instruções máquinas a passarem pelas tubagens do CPU. Quantas mais lá passarem, (em média) mais tempo demora e mais lento o programa é. Os engines de java e .NET põe muita coisa redundante nessas tubagens. Os optimizadores JIT têm tentado retirar *algumas* das coisas redundantes, mas, como é óbvio, não conseguem tirar todas, senão o seu valor existencial era nulo. Consequentemente java ou .net nunca será mais rápido que C, no limite poderão quanto muito ser quase equivalentes, mas duvido. See also.
|
| |
| | | Uma conclusão interessante, tendo em conta a variedade de técnicas de alocação existentes e as JVM usarem mais que uma (a tal que eu referi é O(1)) e o facto de a notação big-O representar a escalabilidade do algoritmo e esconder as constantes.
Quanto à questão do consumo de memória desnecessária, é como as caches do SO: não são precisas, mas podem ajudar.. ou não. É uma questão de encontrar o equilibrio.
Não vejo em que é que os interfaces afectam o problema de optimização do dynamic binding. Num caso estático, o que é preciso é provar que os objectos acedidos através de uma determinada referência são sempre da mesma classe. No caso da JVM, basta-lhe especular sobre isso.
Quanto às arrays.. não me apetece repetir-me. A keyword "restrict" pode ajudar, mas também te pode morder. Na sua intenção, pode complicar-te um bocado a vida. Na sua implementação, não me admirava que venha a haver divergências na interpretação que os compiladores fazem dela. O problema é que a optimizar hoje em dia é mais do que minizar o número de instruções. Isso era verdade quando o C foi pensado, quando os compiladores eram básicos, os CPUs levavam N ciclos a executar uma instrução e os tempos de acesso à memória eram alguns ciclos de CPU.
Já não é. O acesso à memória demora centenas de ciclos, os CPUs executam N instruções por ciclo mas com dependências e regras que nunca mais acabam e os compiladores fazem trinta por uma linha. Até geram código multi-threaded nalguns casos.
Hoje em dia é uma questão de expressar o programa de forma que uma máquina (compilador, JVM, etc) desprovidade de inteligência mas com capacidade de aplicar métodos de optimização ad-nauseum o possa implementar eficientemente.
O Java coloca muitos problemas mas também tem as suas vantagens, no contexto de JIT. E o C, com as suas origens de assembly portável, também está longe de ser ideal neste aspecto. Claro que tudo isto assume que o processamento é o factor limitativo e que a capacidade de desenvolvimento é infinita. A primeira só é verdade às vezes, a outra nunca.
|
| |
| | "Quanto à questão do consumo de memória desnecessária, é como as caches do SO: não são precisas, mas podem ajudar.. ou não. É uma questão de encontrar o equilibrio."
As caches do OS usam memória não alocada, o que faz todo o sentido para optimização visto que essa memória não é necessária. No entanto, sempre que essa memória é pedida por uma aplicação, o kernel devolve-a sem qualquer problema. Isto nunca pode acontecer entre dois processos no user-space. Duas aplicações em Java podem em alguns casos partilhar a mesma memória, mas se houverem outras aplicações a correr no sistema, essas aplicações não vão poder usar essa memória.
Como protesto contra a ridicularidade das novas políticas do gildot, todos os meus comentários serão colocados sem possibilidade de resposta. |
| |
| | Não e sim..
A libertação das caches/buffers do SO não necessariamente imediata nem grátis. Nalguns casos, é apenas uma read-cache e pode ser limpa (parece-se imenso com garbage colleting). Noutros, contém informação a que é necessário dar destino.
As aplicações também não têm prioridade absoluta no direito a memória fisica. O SO pode por aplicações na swap e usar memória fisica para caches/buffers à sua discrição. Um sintoma comum disso são as aplicações em que não mexemos enquando fazesmos um find / e depois levam alguns seguindos a voltar à vida.
Naturalmente, é concebivel que JVMs entrem num esquema semelhante, ajustanto a agressividade do garbage collector em função da pressão que existe no sistema para obter memória fisica.
Não sei é se há JVMs de produção a usar isso...
|
| |
| | | Garbage collecting não se parece nada com cache! Mesmo que tenhas dados readonly, vais ter que percorrer todos os ponteiros (referências) que possam referenciar um dado bloco, para ver se pode ir para a lista do espaço livre. É isto que lixa os GCs em geral-- lentos e, quanto a memória, apenas garantem um "lower bound" de uso, não garantem memória zero desperdiçada... De qq modo, usar GCs pode-se fazer em muitas linguagens, mesmo nas que não foram originalmente pensadas para isso. Existem para C alguns GCs conhecidos, como o hans-boem. Se fosse pelo uso ou não de GC, não era por aqui que uma dada linguagem tinha vantagem em relação a outra... mas não é por aqui.
|
| |
| | | Sim, tens razão. Eliminar as caches é diferente de garbage collecting. Tu apontaste GC como factor para a má performance de Java. Eu apontei factores em que o GC pode ser benéfico.
|
| |
| | | Quanto às ordens assimptóticas de execução, são elas que medem realmente o tempo de execução de um algoritmo. As constantes escondidas podem ter peso apenas para pequenos valores de N, por isso não vejo bem onde pretendes chegar. Acho qeu não é preciso pedir muito para se concordar que alocar quase em O(1) (repara que o memory allocator pode reservar uma quantidade de memória equivalente às que os GC usam, e nesse caso até a memória se esgotar são iguais) e libertar a custo quase zero é o mais rápido que se consegue! Quanto à memória: é exactamente ao contrário do que dizes. Quanto menos o teu sistema desperdiçar, mais podes usar para cache aplicacional, por exemplo. Aqui sim, temos ganhos de performance mas a nível funcional (independente da linguagem). interfaces: necessitam de um criar sempre um objecto e preenchê-lo em runtime. Interfaces são das coisas mais lentas em java/c#. optimização, cpus, et al: que eu saiba os CPUs modernos ainda são máquinas de turing. Limitam-se a ler uma tape e processar a instrução da fita. Agora se tens N tapes a ser lidas em paralelo, M quadrados da fita a serem absorvidos de cada vez pela máquina, são optimização locais que podes fazer. Essas mantêm-se válidas no caso do C (e outras linguagens) tanto agora como há 20 anos. O único caso de nota são os ponteiros como mencionaste e bem. Mas existe o restrict como (eu) falei. Mesmo sem este o compilador pode seguir a vida de muitos dos ponteiros usados ao longo do código e a partir daí pode optimizar. Quanto ao resto: produzir sequências de código independente para aproveitar as pipes e manter localidade de dados (responsabilidade do memory allocator no caso dinâmico) e código, que, em termos de desempenho de software, qualquer compilador de C tem matéria prima para o fazer e bem.
|
| |
| | Sou só eu ou o plugin bloqueia o Firefox (Linux) na maioria das vezes que se sai de uma página que tem applets java?
-- Carlos Rodrigues
|
| |
| |
| | Erm nao me costuma acontecer mas uso windows... :)
Comecei uma dieta, cortei a bebida e comidas pesadas e, em catorze dias, perdi duas semanas. - Joe E. Lewis |
| |
|
| | Não foi o CEO da SUN que disse: "We love linux!" :-)
|
| |
| | Comigo parece funcionar perfeitamente.
Ainda estou a usar o firefox 0.9.3.
Experimentei quase todas as applets daqui e não tive qualquer problema.
"As you know, these are open forums, you're able to come and listen to what I have to say."
--George W. Bush |
| |
| | Bem, a festa da Sun pelo anúncio da nova versão foi estragada pela decisão de um tribunal num caso de patentes. A Kodak processou a Sun alegando que o Java infringia patentes suas (adquiridas à Wang em 1997, anos depois da criação do Java). A Kodak está a exigir $1.06bn como compensação pela maneira como "inovam". Link para a Zdnet. Interessante também o artigo no Groklaw.
|
| |
