C++ lento?
DQ
elas trazem alguma coisa de útil. Entretanto, o post abaixo me deixou
curioso:
http://vitorpamplona.com/wiki/JavaVsC+com+Processadores+CoreX
Resumindo, no teste o Java foi 3x mais rápido que o C++ num teste que
(se entendi direito) envolve basicamente uma implementação de lista
ligada com um monte de criação/destruição de objetos.
Dei só uma passada de olhos no código e me parece que exala o odor de
memory leak, porém não tenho um ambiente parecido (nem linux nem Core
Duo) para olhar a fundo (e, sim, estou com preguiça!).
Quem sabe alguem da lista se interessa e explica esta "anomalia
temporal".
Felipe Magno de Almeida
do Java nao tenha tempo de executar.
Por isso é muito mais rapido.
2008/7/18 DQ <d.qu...@yahoo.com>:
Felipe Magno de Almeida
Thiago R. Adams
rápidos em linguagens com garbage collector.
Na prática, para resolver um problema semelhante seria usado um vector
com resize antes.
Ou se isso não fosse possível, outra forma de allocação poderia ser
usada como um pool de objetos.
2008/7/18 DQ <d.qu...@yahoo.com>:
Felipe Magno de Almeida
>
> Exemplos com alocação de memória de pequenos objetos ficam mais
> rápidos em linguagens com garbage collector.
>
> Na prática, para resolver um problema semelhante seria usado um vector
> com resize antes.
> Ou se isso não fosse possível, outra forma de allocação poderia ser
> usada como um pool de objetos.
Normalmente sem uso de um garbage collector de alta performance,
que não costuma acompanhar as implementações Java, quando
o garbage collector roda, ele costuma ser mais lento já. Os mallocs
da maioria das implementacoes do C++ hoje em dia costumam ser
consideravelmente rapidos (porém nem tanto).
O garbage collector pode ser mais rapido em vários cenários,
(principalmente multithreading). Mas não tanto no caso comum.
Esses testes porém costumam terminar antes do garbage collector
se quer fazer um sweep, aí fica fácil né.
Bruno Sanches
Thiago R. Adams
> se quer fazer um sweep, aí fica fácil né.
2008/7/18 Felipe Magno de Almeida <felipe.m...@gmail.com>:
Felipe Magno de Almeida
>> se quer fazer um sweep, aí fica fácil né.
>
> Também acho que está acontecendo isso.
Sem contar que ele nao rodou o teste numa máquina com apenas um processador :P.
Onde o multithreading do garbage collector adicionaria overhead considerável.
Psycho Mantys
Não sei porque, mas depois de uma rapida olhada eu digo que nao confio
nesse codigo.
Roberto Santos (DEVDIV)
1. Alocações por uma runtime podem ser tão rápidas quanto uma simples soma; o que também gera menos contenção em ambientes multi-thread (cada vez mais importante)
2. GCs modernos não são tão lentos quanto se imagina à primeira vista (embora comprimir seja relativamente caro)
3. Runtime/GC pode fazer coisas a menos (ou nada) no encerramento de um processo (otimizações possíveis variam com a runtime, mas imagine que comprimir não é útil)
4. Se o GC não precisou rodar, e o cenário é real, e ao terminar o processo ele trabalhou menos, quem ganhou é o usuário final. Ele não se interessa em forçar o GC a rodar prá comparação ficar "mais justa".
5. Há várias pesquisas em hardware assisted real time garbage collector; imagine o dia em que isso estiver nos chips...
De novo, isso não diz que a comparação citada é um cenário real. Apenas achei interessante ser o advogado do diabo de uma tecnologia com 1/2 século de idade (GC), que tornou-se cotidiana porque provavalmente provou que tem valor (é tempo o suficiente para terem passado por processe de "seleção e evolução 'natural' ).
DQ
> Por outro lado:http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=gpp...
Ótimo link! A parte que gostei mais foi a definição de "não é justo":
http://shootout.alioth.debian.org/gp4/faq.php#fable
Feu Teston
Eu trabalho com Java faz uns 6 anos e pude ver diferentes cenários relativos a esta questão do garbage colector.
Diversos projetos deram problemas de leak de memória devido a um GC mal configurado. Arrumando meia dúzia de parametros do GC a aplicação até ficou mais rápida.
Mas projetos realmente críticos que eu tive contato necessitaram de um hardware realmente absurdo para segurar a onda. Muito dinheiro investido por pouco retorno na minha opinião.
Os gráficos de uso de memória sempre ficam parecendo uma serra, pois o GC espera a memória chegar em determinado patamar para fazer a fachina. Realmente a opção de usar um operador delete faz uma falta tremenda no java, na minha opinião. Eu acho que hoje em dia os GCs no java não são tão bons quanto deveriam...
Agora pensar em um GC no hardware eh show! Nunca tinha pensado nisso!
E é isso!
Teston
Bruno Sanches
Virgilio Alexandre Fornazin
A grande diferença ai é que todo new/delete modifica o HEAP, coisa que o Java não faz, por isso a diferença...
e o gc roda em outra thread, ja estando em multi-cpu, da uma enorme vantagem... agora, coloque um allocator
SMP (tipo o jemalloc que o Mozilla colocou no firefox), e faça ambos funcionarem da mesma maneira, ai sim você
pode ter uma comparação justa...
É aquela velha história do managed e non-managed app no Windows... tente fazer um sistema real time e você
vai ver a diferença... testes simples não contam muito como benchmarks a meu ver...
Blabos de Blebe
Por essas e outras, é complicado tentar medir linguagens. Talvez o
mais adequado seria pegar um expert em Java para implementar em Java e
um expert em C++ para implementar em C++.
2008/7/18 DQ <d.qu...@yahoo.com>:
Hélder Gomes
Rodrigo Strauss
Dá pra fazer a mesma coisa em C++ usando a classe de Pool do Boost, http://www.boost.org/doc/libs/1_35_0/libs/pool/doc/index.html.
Já fiz um teste parecido com C# e C++, ficou 10x mais rápido em C#. É só uma característica do heap GC. Mais um microbenchmark bem específico no qual as VMs se saem muito bem. E ao contrário do que o cara quis dizer com o título, não tem **nada** a ver com o modelo de processador.
Rodrigo Strauss
Rodrigo Strauss
Roberto Santos (DEVDIV)
No Boost Pool, é necessário um pool de cada chunk size, enquanto a managed heap aloca objetos de tamanhos variados. A compactação na managed heap ainda auxilia na desfragmentação, o que não tem equivalente no Boost Pool porque os chunk sizes são fixos. A funcionalide (flexibilidade) é completamente diferente.
Dito isso, o que importa é o resultado final. Há situações em que se pode prever o cenário, a carga e o ambiente razoavelmente bem e se usar Boost pool com sucesso. Há mais cenários em que não. A oportunidade para um resultar me maior benefício para o usuário final é grande.
Mesmo em realtime. Soft realtime systems em que dependemos usam GC há bastante tempo (exemplo: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/ppxt/HT2007/general/languages/armstrong-erlang_history.pdf). Hard realtime systems em cenários mais específicos usam também, e há várias pesquisas e perspectivas de se tornar algo mais genérico e acessível. As mais interessantes, para mim, são as de hardware-assisted realtime garbage collection. Como pode parecer que defendi .NET acima (não é o intuito) faço questão citar uma que fala da concorrência: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/7755/27366/01217230.pdf?arnumber=1217230. Mas esse é um assunto anterior a qualquer uma dessas duas tecnologias: http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.html.
Enfim, GC é apenas uma instância da solução mais recorrente em ciência da computação: a adição de um nível de indireção (pode-se resolver tudo dessa forma, certo?). Se esse nível de indireção lhe permitir administrar os recursos de uma forma mais eficiente, ele em si não precisa ser absolutamente mais eficiente que o nível anterior para promover eficiência ao usuário final. (http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/4343798/4343799/04343832.pdf?tp=&isnumber=&arnumber=4343832)
Meu objetivo não é dar crédito à comparação inicial (não li, na verdade me interessa pouco, e não é sobre o que estou realmente falando), nem defender uma tecnologia ou outra, nem promover a computação baseada em GC.Acho apenas um tema bastante interessante. Na verdade acho todos esses tipos de adição de camadas de indireção tão interessantes (há uma sensação de Singularidade :-) http://en.wikipedia.org/wiki/Technological_singularity) que merecem apreciação sem preconceito.
Ainda mais, acredito que "programadores de sistema" (nós?) têm uma posição privilegiada para apreciar, investigar, usar conscientemente e evoluir essas tecnologias (embora não sejamos os únicos). Ainda mais ainda :-), imagino que o tema de automatic memory management será ainda mais importante no futuro, afinal é grande parte do que se fala hoje em dia: http://www.cs.kent.ac.uk/people/staff/rej/ismm2008/program.html. E há uma certa renascença no mundo das linguagens funcionais, onde o conceito de GC era tão natural que empregou-se um GC sem "inventar o conceito" (LISP).
Em tempo, há diversos GCs para C e C++ e isso não é contrário à filosofia da linguagem: http://www.research.att.com/~bs/bs_faq.html#garbage-collection, http://www.research.att.com/~bs/nantes-interview-english.html.
--------------------------------------------------------------------------------
From: ccppb...@googlegroups.com [ccppb...@googlegroups.com] On Behalf Of Rodrigo Strauss [rod...@1bit.com.br]
Sent: Friday, July 18, 2008 22:21
To: ccppb...@googlegroups.com
Subject: [ccppbrasil] Re: C++ lento?
[...]
Dá pra fazer a mesma coisa em C++ usando a classe de Pool do Boost, http://www.boost.org/doc/libs/1_35_0/libs/pool/doc/index.html.
Já fiz um teste parecido com C# e C++, ficou 10x mais rápido em C#.
[...]
Rodrigo Strauss
ari...@sardano.net
eficiente que você conhece para C?
..e qual a mais eficiente que você conhece para C++?
Entenda como eficiente a que faz o melhor gerenciamento e que tem a
melhor performance.
Há alguma que supera a performance da GC do .NET (C#) ou do Java?
Ricardo
ari...@sardano.net
Seria possível ter uma GC em C++ mais eficiente que as GCs do .NET (C#)
e do Java, ou as características do C++ não permitiriam isso?
Se a resposta for sim, então é apenas uma questão de implementação, logo
a questão seria procurar uma implementação de GC em C++ mais eficiente
(que a solução dada com Boost), ou na pior das hipóteses escrever uma.
Acredito que um cara tecnicamente bom como você não teria dificuldades
de escrever uma; assisti uma palestra sua em um evento C/C++.
A questão é valeria a pena, ou seja, com uma GC eficiente em C++ o
desenvolvedor poderia ser mais eficiente, ter programas mais rápidos,
mais fáceis de dar manutenção e ainda de quebra ser mais produtivo
(escrever menos código para fazer a mesma coisa)?
Só para pensar...rss
Ricardo
ari...@sardano.net
> objetos, e alocacao dele eh muito mais rapido do que em C++ (devido a
> otimizacoes de garbage e tal). O correto na minha opiniao eh
> reproduzir o algoritmo, nao o programa. Tirar as alocacoes que do
> ponto de vista C++ sao na maioria inuteis (o chain no loop principal
> pro exemplo).
>
> Lembre-se que em C++ voce pode criar objetos na pilha, Java nao.
>
> Por outro
> lado: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=javaclient
> <http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=javaclient>
>
> Divirtam-se :)
>
> T+
>
> Bruno
>
> 2008/7/18 Thiago R. Adams <thiago...@gmail.com
>
> Exemplos com alocação de memória de pequenos objetos ficam mais
> rápidos em linguagens com garbage collector.
>
> Na prática, para resolver um problema semelhante seria usado um vector
> com resize antes.
> Ou se isso não fosse possível, outra forma de allocação poderia ser
> usada como um pool de objetos.
>
> > Ok, eu acho bobagem estas comparações de linguagens, pois
> dificilmente
> > elas trazem alguma coisa de útil. Entretanto, o post abaixo me
> deixou
> > curioso:
> >
> > http://vitorpamplona.com/wiki/JavaVsC+com+Processadores+CoreX
> >
> > Resumindo, no teste o Java foi 3x mais rápido que o C++ num
> teste que
> > (se entendi direito) envolve basicamente uma implementação de lista
> > ligada com um monte de criação/destruição de objetos.
> >
> > Dei só uma passada de olhos no código e me parece que exala o
> odor de
> > memory leak, porém não tenho um ambiente parecido (nem linux nem
> Core
> > Duo) para olhar a fundo (e, sim, estou com preguiça!).
> >
> > Quem sabe alguem da lista se interessa e explica esta "anomalia
> > temporal".
> >
> > >
> >
>
>
>
>
>
> --
> Bruno Sanches
> ========================
> http://bcsanches.wordpress.com
>
> >
Para escrever um código mais eficiente em C++ (escrever menos e gerar um
código mais fácil de dar manutenção e que roda mais rápido) preciso de
um GC?
Se sim, em que caso seria obrigatório o uso de um GC?
Ricardo
ari...@sardano.net
Java (1.4.2) para testar a performance, era um algoritmo que extraia
dados de arquivos PDL (Print Document Language) para uma aplicação
específica, os arquivos tratados tinham em média 2GB de tamanho.
Na implementação Java fui obrigado a usar chamadas explícitas ao GC do Java.
Bom para o meu espanto o Java foi mais rápido que o C++ mas consumia
muito mais memória para rodar.
Buscando explicações para o "fenômeno" encontrei algo que dizia que
realmente em "alguns casos" o Java era mais rápido que o C++ devido ao
gerenciamento dinâmico que o Java faz dos recursos da máquina.
É importante destacar que não fiz um esforço adicional para escrever um
algoritmo mais eficiente em C++, ou seja acredito que se tivesse feito
um esforço adicional na codificação teria conseguido melhor performance
com C++, porém a idéia envolvia também produtividade, logo fazer um
esforço maior para codificar não faria sentido.
Ricardo
Roberto Santos (DEVDIV)
> eficiente que você conhece para C?
Não estou qualificado a dizer qual é a mais eficiente. Depedendo do seu cenário, diferentes estratégias e implementações de GC podem se comportar melhor. Algo para se simular e medir.
A que mais ouvi falar (não significa que seja a melhor) no mundo Unix foi http://www.hpl.hp.com/personal/Hans_Boehm/gc/. No mundo Windows houve um desenvolvimento interessante mais recente, que é o C++/CLI, que usa o GC do .NET. Em C++/CLI a desalocação de memória e a destruição do objeto são separados de forma transparente e, embora a desalocação não seja determinística, a destruição é (habilita idioma RAII). Deixando claro que C++/CLI é um binding para a CLI inteira, não só o GC.
Uma lista de bibliografias (para encontrar outras implementações) está aqui: http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbibA.html. Essas 2 empresas tiveram produtos de GC para C++ no passado: http://www.geodesic.com/, http://www.reflective.com/index.html. Acho que precisa fazer contato para ganhar detalhes (pelo menos uma delas era assim há bastante tempo; a outra possibilidade é que não está no site porque não comercializam mais).
Thiago Adams
Compilei a versâo original do programa C++ e rodei no meu computador.
Levou 85 segundos
Depois coloquei um pool de objetos em Person.
E tirei a alocação inútil de Chain dentro do for.
O programa rodou em menos de 10 segundos.
Ou seja, um pool de 36 linhas de código deixou o programa 9 vezes mais
rápido sem precisar um GC.
Thiago Adams
implementa;'ao da lista ligada est'a errada.)
Isso atrapalha a performance do pool pois n'ao esta reutilizando os
objetos que tem estao com leak.
Raphael Menezes
Achei mt interessante suas explicacoes referentes a esse pseudomicrobenchmark
abraços
"A diferença entre o Batman e o Bill Gates é que o Batman consegue derrotar o Pingüim"
Cesar Mello
o smartheap:
http://www.microquill.com/
No trabalho já vi ganhos absurdos de mais de 400% (temos o SmartHeap
não-SMP, a versão SMP deve ser ainda melhor).
[]
Mello
Cesar Mello
Rodrigo Kumpera
da pior maneira, que para programação de estruturas de dados lock-free ter um GC é uma enorme
vantagem.
No mono tem uma implementação de arvore de busca que é lock-free e wait-free. A parte mais
complicada de implementar foi o gerenciamento de memória, uma vez que é impossível prever
se outra thread está usando um bloco de memória quando vc deseja desalocá-lo - uma operação
necessária p/ implementar expansão de arrays.
A solução que adotamos foi usar hazard pointers, que exige fazer dois CAS por leitura de ponteiro
para sinalizar seu uso e depois liberá-lo. Além disso, para liberar um bloco de memória é necessário
ler hazard pointers de todas threads.
Descobrimos recentemente em um cliente que tinha problemas de performance que um dos principais motivos
era o uso de hazard pointers, uma vez que CAS é uma operação incrivelmente lenta com muitas CPUs.
Em contrapartida, uma implementação da mesma estrutura de dados feita em uma linguagem com GC é muito
mais rápida devido ao gerenciamento automático de memória.
O mesmo pode ser visto para implementar hash tables que sejam wait-free, sem um GC é quase impossível ter
uma implementação que seja escalável para várias dúzias de cpus.
Felipe Magno de Almeida
> Gerenciar memória via GC possui uma série de vantagens inusitadas.
> Recentemente descobri,
> da pior maneira, que para programação de estruturas de dados lock-free ter
> um GC é uma enorme
> vantagem.
>
> No mono tem uma implementação de arvore de busca que é lock-free e
> wait-free. A parte mais
> complicada de implementar foi o gerenciamento de memória, uma vez que é
> impossível prever
> se outra thread está usando um bloco de memória quando vc deseja desalocá-lo
> - uma operação
> necessária p/ implementar expansão de arrays.
Uma pergunta: Como você faz buscas se pode haver um remove
de um elemento da árvore?
A operacao de busca pode terminar, e quando retornado o elemento
já vai estar removido.
[snip]