C++ lento?

27 visualizações
Pular para a primeira mensagem não lida

DQ

não lida,
18 de jul. de 2008, 07:43:3118/07/2008
para ccppbrasil
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".

Felipe Magno de Almeida

não lida,
18 de jul. de 2008, 07:49:3018/07/2008
para ccppb...@googlegroups.com
Esses testes normalmente funcionam de forma que o garbage collector
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

não lida,
18 de jul. de 2008, 07:51:2618/07/2008
para ccppb...@googlegroups.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.

2008/7/18 DQ <d.qu...@yahoo.com>:

Felipe Magno de Almeida

não lida,
18 de jul. de 2008, 07:56:0118/07/2008
para ccppb...@googlegroups.com
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.

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

não lida,
18 de jul. de 2008, 07:56:1718/07/2008
para ccppb...@googlegroups.com
Eu acho injusto a comparacao porque em JAva voce sempre tem que alocar 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.


Divirtam-se :)

T+

Bruno

2008/7/18 Thiago R. Adams <thiago...@gmail.com>:



--
Bruno Sanches
========================
http://bcsanches.wordpress.com

Thiago R. Adams

não lida,
18 de jul. de 2008, 08:05:5218/07/2008
para ccppb...@googlegroups.com
> Esses testes porém costumam terminar antes do garbage collector
> se quer fazer um sweep, aí fica fácil né.

Também acho que está acontecendo isso.


2008/7/18 Felipe Magno de Almeida <felipe.m...@gmail.com>:

Felipe Magno de Almeida

não lida,
18 de jul. de 2008, 08:08:0018/07/2008
para ccppb...@googlegroups.com
2008/7/18 Thiago R. Adams <thiago...@gmail.com>:
>
>> Esses testes porém costumam terminar antes do garbage collector
>> 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 lida,
18 de jul. de 2008, 09:16:1418/07/2008
para ccppb...@googlegroups.com
#########################################################################################################

Não sei porque, mas depois de uma rapida olhada eu digo que nao confio
nesse codigo.

Roberto Santos (DEVDIV)

não lida,
18 de jul. de 2008, 09:42:2718/07/2008
para ccppb...@googlegroups.com
Não discordando de nenhuma das opiniões anteriores (por favor!), e sem querer dar mérito à compração inicial, que sinceramente não li, gostaria apenas de ressaltar que o cenário, não focando em uma tecnologia específica, mas falando de GC em conjunto com runtimes em geral, no contexto de gerenciamento de memória automático vs explícito, não é absurdo:

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

não lida,
18 de jul. de 2008, 09:45:3318/07/2008
para ccppbrasil
On Jul 18, 8:56 am, "Bruno Sanches" <bcsanc...@gmail.com> wrote:
> 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

não lida,
18 de jul. de 2008, 10:03:4718/07/2008
para ccppb...@googlegroups.com
Garçon, mais um chopp pra mim!

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

2008/7/18 Roberto Santos (DEVDIV) <Roberto...@microsoft.com>:

Bruno Sanches

não lida,
18 de jul. de 2008, 10:14:5618/07/2008
para ccppb...@googlegroups.com
Eh bem divertido esse link :)

2008/7/18 DQ <d.qu...@yahoo.com>:

Virgilio Alexandre Fornazin

não lida,
18 de jul. de 2008, 10:55:3318/07/2008
para ccppb...@googlegroups.com

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

não lida,
18 de jul. de 2008, 13:52:3618/07/2008
para ccppb...@googlegroups.com
Como o pessoal do Perl costuma dizer, o código é C++ com sotaque Java.

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

não lida,
18 de jul. de 2008, 14:05:5418/07/2008
para ccppb...@googlegroups.com
Eu creio nisso também, e um código bem feito em C++ eu tenho certeza que passa a velocidade do Java, simplesmente por causa do Overhead menor (a galera se esquece que a máquina virtual do Java também é um programa, e obviamente não foi feito usando o próprio Java...)

2008/7/18 Blabos de Blebe <bla...@gmail.com>:

Rodrigo Strauss

não lida,
18 de jul. de 2008, 21:21:1418/07/2008
para ccppb...@googlegroups.com
O motivo é muito simples: uma alocação .NET ou Java é uma soma de um ponteiro. **Só uma soma de ponteiro e só***. Depois do GC se vira para desfragmentar essa memória durante a coleta, em C ou C++ mover memória alocada não é uma opção. Em C++ é um caminhão de coisas. Quer ver, faz um debug de C++ no windbg, entra na código da função new e usa o comand 'wt' prar fazer um trace.

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

2008/7/18 DQ <d.qu...@yahoo.com>:

Rodrigo Strauss

não lida,
18 de jul. de 2008, 21:22:5318/07/2008
para ccppb...@googlegroups.com
corrigindo: ... Depois *o* GC se vira para desfragmentar...

2008/7/18 Rodrigo Strauss <rod...@1bit.com.br>:

Roberto Santos (DEVDIV)

não lida,
19 de jul. de 2008, 00:06:4819/07/2008
para ccppb...@googlegroups.com
Assim como a comparação inicial pode ser considerada entre bananas e maçãs, a comparação entre Boost Pool e o Managed Heap do .NET também é entre desiguais ("desiguais" é diferente de "injusta").

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

não lida,
19 de jul. de 2008, 09:24:4819/07/2008
para ccppb...@googlegroups.com
Roberto Santos (DEVDIV) escreveu:
Oi Roberto, você disse que há diversas GCs para C e C++, Qual a mais
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

não lida,
19 de jul. de 2008, 09:35:0119/07/2008
para ccppb...@googlegroups.com
Roberto Santos (DEVDIV) escreveu:
Essa vai para o Strauss:

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

não lida,
19 de jul. de 2008, 09:48:0819/07/2008
para ccppb...@googlegroups.com
Bruno Sanches escreveu:
> Eu acho injusto a comparacao porque em JAva voce sempre tem que alocar
> 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
> <mailto: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.
>
> 2008/7/18 DQ <d.qu...@yahoo.com <mailto:d.qu...@yahoo.com>>:
> >
> > 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 ir na mesma linha do Bruno, a questão é preciso de um GC em C++?

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

não lida,
19 de jul. de 2008, 09:56:2219/07/2008
para ccppb...@googlegroups.com
Roberto Santos (DEVDIV) escreveu:
A alguns anos atrás escrevi implementei o mesmo algoritmo em C++ e em
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)

não lida,
19 de jul. de 2008, 12:06:1119/07/2008
para ccppb...@googlegroups.com
> Oi Roberto, você disse que há diversas GCs para C e C++, Qual a mais
> 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

não lida,
19 de jul. de 2008, 22:32:0819/07/2008
para ccppbrasil

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

não lida,
19 de jul. de 2008, 23:35:4119/07/2008
para ccppbrasil
Outra coisa.. o programa est'a com memory leaks , (porque a
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

não lida,
19 de jul. de 2008, 23:38:4219/07/2008
para ccppb...@googlegroups.com
Vc poderia nos explicar isso mostrando os pedacos do codigo, Thiago?
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

não lida,
19 de jul. de 2008, 23:50:2519/07/2008
para ccppb...@googlegroups.com
Outro teste que talvez seja interessante pra abrir os horizontes é usar
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

não lida,
19 de jul. de 2008, 23:51:3419/07/2008
para ccppb...@googlegroups.com
Esta é a página do SmartHeap:

http://www.microquill.com/smartheap/index.html

[]
Mello

Rodrigo Kumpera

não lida,
20 de jul. de 2008, 00:13:4720/07/2008
para ccppb...@googlegroups.com
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.

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.


2008/7/19 Roberto Santos (DEVDIV) <Roberto...@microsoft.com>:

Felipe Magno de Almeida

não lida,
20 de jul. de 2008, 09:15:5120/07/2008
para ccppb...@googlegroups.com
2008/7/20 Rodrigo Kumpera <kum...@gmail.com>:

> 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]

Rodrigo Kumpera

não lida,
20 de jul. de 2008, 12:22:2620/07/2008