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]