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é.
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.
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' ).
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...
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
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).
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]
> Tais técnicas são inviáveis de se aplicar no C++, assim como qualquer
> mecanismo de GC de alta performance.
Não vejo nada que proiba o C++ de rodar em uma VM.
O C++ pode ser tipado você o quanto você queira.
On 22 jul, 09:54, "Rodrigo Kumpera" <kump...@gmail.com> wrote:
> A questão de se um GC pode ser mais rápido ou não que alocação manual já é
> assunto vencido. Sim, pode e existe
> pesquisa séria por traz disso apontando para esse tipo de resultado. Porém
> esse tipo de solução só é possível com
> linguagens com tipagem forte, que não é o caso do C++.
2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:
>Não vejo nada que proiba o C++ de rodar em uma VM.
> Tais técnicas são inviáveis de se aplicar no C++, assim como qualquer
> mecanismo de GC de alta performance.
Eu não falei sobre GC, respondi sobre isto:
Fora isso existe muita pesquisa em volta de VMs capazes de reordenar
de maneira adaptativa os atributos dos objetos
de forma a otimizar o comportamento de caching da aplicação, fora
otimizações tradicionais que aumentam a localidade
dos dados.
Tais técnicas são inviáveis de se aplicar no C++, assim como qualquer
mecanismo de GC de alta performance.
> Com C++ é impossível gerar stack maps precisos sem modificar o compilador.
> Isso é um dos
> exemplos dos vários problemas.
Você está falando de C++, que é uma linguagem padronizada por um órgão
internacional.
E esta pode ser implementada como quiser, desde que não desvie do padrão.
E isto inclui GC e implementar sobre uma VM. E pode portanto utilizar
as técnicas que você falou que são inviáveis.
Acredito que não são inviáveis, mas que provavelmente não valem a pena
pra qualquer
vendor.
Dá para notar pela metodologia usada que o cara entende patavinas de máquinas virtuais e como fazer benchmarking das mesmas.
2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:Dá para notar pela metodologia usada que o cara entende patavinas de máquinas virtuais e como fazer benchmarking das mesmas.
Roberto,
Não quero ser resistente ao inevitável; neste momento eu só quero entender... pois resistir ao inveitável é realmente ignorância mas não consegui encontrar nos links que você enviou (com exceção daqueles de repositório fechado do IEEE) algo que me fizesse entender isto melhor.
Kumpera,
Sem sarcasmo e com muita franqueza:
- Como se realiza um benchmarking entre programas que rodam gerenciados por uma VM e programas que são domados manualmente? Sinceramente, eu gostaria de saber. Há algum documento que você indique para um entendimento adequado? Se for uma sequência de papers e literaturas eu não importo, estou interessado em saber.
4all,
Recentemente, num seminário da Intel, quando um palestrante da Microsoft foi questionado se já era recomendado utilizar programas sobre o Windows Embedded Real Time e .Net Compact Framework para missão crítica e Life Maintenance o palestrante soltou um riso e afirmou que isto ainda não era confiável. Durante o coffe-break então ficou o questionamento: porque outro RTOS de Missão Crítica pode ser utilizado para estes propósitos e o Windows Embedded Real Time com .Net Compact Framework não? Inconsequência daqueles que o fazem sobre RTOS ou medo do palestrante Microsoft de assumir tal risco com sua afirmação? Sem sarcarsmo, mas fiquei com esta dúvida em mente. Infelizmente, quando somos submetidos a este tipo de programas não estamos em condições de questionar se o software é gerenciado ou não, desenvolvido em C, C++, Ada, Forth, Assembly, Java ou VB.Net...
From: ccppb...@googlegroups.com [mailto:ccppb...@googlegroups.com] On Behalf Of Marco Aurélio
Sent: Tuesday, July 22, 2008 1:58 PM
To: ccppb...@googlegroups.com
Subject: [ccppbrasil] Re: C++ lento?
Sei que existem interpretadores para C++.
Mas...existe alguma VM para rodar C++?
Me pareceu que a pergunta é mais por curiosidade do que "pragmática" (nada de errado), então vou citar um exemplar de cada coisa significativa que lembrei...
Talvez não 100% o que procura...
Uma VM para um IR de um frontend específico: http://www.interstron.ru/eng/text.asp?id=1937
Um binding de C++ para uma runtime padrão: http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf
Talvez nem 50%...
Um interpretador: http://root.cern.ch/twiki/bin/view/ROOT/CINT
E, na mesma linha do que o Kumpera já respondeu (LLVM), haviam compiladores de C e de C++ para o Virtual Processor: http://www.byte.com/art/9407/sec6/art1.htm (LLMV é um exemplo melhor com certeza)
E só para curiosidade (e pesquisa) mesmo...
Uma VM para BCPL, um ancestral de C: http://www.gtoal.com/languages/bcpl/amiga/bcpl/booting.txt
Pesquisas antigas de RTCG e C: http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TM-526.pdf
Uma linguagem inspirada em C (fora uns adornos o código é C) com uma runtime para processamento paralelo: http://charm.cs.uiuc.edu/papers/CharmSys2TPDS94.pdf (estavam trabalhando para C++ também)