C++ lento?

[DQ]

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]

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]

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]

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]

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

Divirtam-se :)

T+

Bruno

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

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

[Thiago R. Adams]

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

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 sei porque, mas depois de uma rapida olhada eu digo que nao confio
nesse codigo.

[Roberto Santos (DEVDIV)]

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]

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]

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]

Eh bem divertido esse link :)

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

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

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]

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]

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]

corrigindo: ... Depois *o* GC se vira para desfragmentar...

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

[Roberto Santos (DEVDIV)]

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]

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]

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]

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]

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

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

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]

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]

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]

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]

Esta é a página do SmartHeap:

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

[]
Mello

[Rodrigo Kumpera]

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]

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]

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

 
Temos um critério de pré-existência, nós usamos os dados nessa árvore para fazer stack unwinding, a garantia é que se o código em questão ainda está em execução não podemos liberar o descritor dele, como garantimos isso é outra história um pouco mais complicada.

Um problema que temos é que as vezes a busca binária (usamos algo próximo a uma btree) termina no ponto errado e temos de manualmente corrigir isso via busca linear. O número de passos é correspondente ao número de inserções / remoções concorrentes que ocorreram junto a busca, então é limitado a um número pequeno.

[Thiago Adams]

Nesta página:
http://www.msobczak.com/prog/downloads.html
ver rawpool.zip
Tem uma implementação com exemplo sobre pool de objetos.

Basicamente quando o objeto é deletado sua memória fica numa listinha
e é reaproveitado de forma rápida para a alocação seguinte.
É util quando os objetos são criados e deletados muitas vezes.

On 20 jul, 00:38, "Raphael Menezes" <rapha...@gmail.com> wrote:
> Vc poderia nos explicar isso mostrando os pedacos do codigo, Thiago?
> Achei mt interessante suas explicacoes referentes a esse
> pseudomicrobenchmark
>
> abraços
>

> On Sun, Jul 20, 2008 at 12:35 AM, Thiago Adams <thiago.ad...@gmail.com>

[Daniel]

Então,

Talvez nem precise ser no hardware, será que algo no sistema
operacional não resolveria ?

Algo que o processo possa informar ao sistema operacional o quanto de
memória iria utilizar e assim o sistema operacional controlaria esta
área alocada através de algo como um garbage collector. Creio que um
modelo assim e ainda tendo ajuda do delete(), creio que seria um
scenário ideal.

Lembrando que não sou nenhum especialista em sistemas operacionais.

[Rodrigo Kumpera]

Todo SO moderno dos últimos 20 anos faz isso via page faulting e swap.

2008/7/21 Daniel <daniel...@gmail.com>:

[Rodrigo Strauss]

Os GCs, tanto do Java quanto do .NET já são muito bons. É mais fácil fazer um GC em um ambiente controlado e gerenciado (Java/.NET), mas é possível fazer em C++ também, tanto que já existem alguns.

O problema não é que os GCs existentes não sejam bons. Toda tecnologia tem suas vantagens e desvantagens, nunca vai existir uma coisa 100% automatica que resolva 100% das situações. Eu e muitos caras dessa lista poderiam escrever um GC (*acho* que o Kumpera que trabalha no Mono mexe no GC, mas estou com preguiça de procurar os commits dele :-)), mas o caras da Microsoft/Sun/Novell/SeiLáMaisQuem, já fazem isso faz anos, eles com certeza sabem o que fazem.

Um GC **nunca** vai ser tão eficiente quanto alocação manual em todas as situações. Quando você controla a memória manualmente, você sabe exatamente o tipo de uso, quando, como e porque. Um troço automático nunca vai conseguir adivinhar o que você quer.

Um GC resolve para a maioria dos padrões de uso. Mas não é o mais eficiente para algumas situações que eu encontro. Por isso que eu (e a maioria aqui) uso C++ e uso boost::shared_pointer quando interessa, VirtualAlloc quando interessa, HeapAlloc quando interessa, malloc, new, Boost.Pool, etc, etc. E, claro, tenho muito mais trabalho e pago o preço por isso.

Rodrigo Strauss

2008/7/19 <ari...@sardano.net>:

[Thiago Adams]

Só para complementar o que o Strass falou, o c++ além de não ter um GC
obrigatório, ainda permite que a maneira como o new funciona seja
customizada.
A própria STL permite que o allocator dos containers seja customizada
também.

On 21 jul, 22:48, "Rodrigo Strauss" <rodr...@1bit.com.br> wrote:
> Os GCs, tanto do Java quanto do .NET já são muito bons. É mais fácil fazer
> um GC em um ambiente controlado e gerenciado (Java/.NET), mas é possível
> fazer em C++ também, tanto que já existem alguns.
>
> O problema não é que os GCs existentes não sejam bons. Toda tecnologia tem
> suas vantagens e desvantagens, nunca vai existir uma coisa 100% automatica
> que resolva 100% das situações. Eu e muitos caras dessa lista poderiam
> escrever um GC (*acho* que o Kumpera que trabalha no Mono mexe no GC, mas
> estou com preguiça de procurar os commits dele :-)), mas o caras da
> Microsoft/Sun/Novell/SeiLáMaisQuem, já fazem isso faz anos, eles com certeza
> sabem o que fazem.
>
> Um GC **nunca** vai ser tão eficiente quanto alocação manual em todas as
> situações. Quando você controla a memória manualmente, você sabe exatamente
> o tipo de uso, quando, como e porque. Um troço automático nunca vai
> conseguir adivinhar o que você quer.
>
> Um GC resolve para a maioria dos padrões de uso. Mas não é o mais eficiente
> para algumas situações que eu encontro. Por isso que eu (e a maioria aqui)
> uso C++ e uso boost::shared_pointer quando interessa, VirtualAlloc quando
> interessa, HeapAlloc quando interessa, malloc, new, Boost.Pool, etc, etc. E,
> claro, tenho muito mais trabalho e pago o preço por isso.
>
> Rodrigo Strauss
>

> 2008/7/19 <arie...@sardano.net>:

>
>
>
>
>
> > 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- Ocultar texto entre aspas -
>
> - Mostrar texto entre aspas -

[Rodrigo Kumpera]

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++.

Uma característica comum a linguagens gerenciadas é o fato de tanto performance quanto alocação de memória podem
ser compostos em larga escala, enquanto isso, em C/C++ não é prático fazer isso para grandes programas. Enquanto
uma máquina virtual pode aplicar uma otimização uniformemente através todo o programa, não é prático fazer o mesmo
para bases grandes de C/C++, em boa parte devido ao uso de bibliotecas de terceiros.

Máquinas virtuais de pesquisa já são capazes de promover alocação feita no heap p/ pilha ou mesmo segmentar
de forma adaptativa todas alocações de forma a ter várias heaps por zonas, thread ou grupos de. O que permite
eliminar contenção, aumentar performance, e reduzir o desperdício de memória p/ ter um alocador paralelo.

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.

Boa parte dessa pesquisa ainda está uma década de chegar em VMs de produção, porém é inevitável que aconteça.

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

[Thiago Adams]

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++.

O C++ pode ser tipado você o quanto você queira.

Eu concordo com o Strauss, que algo automático não pode ser melhor do
que algo manual feito por quem entende o problema.

Lembre-se que até o momento os computadores não pensam e eles não tem
conhecimento sobre o problema, além daquele que foi abstraído e
simplificado na implementação.

Por exemplo, no código que começou este tópico, vi que o número de
itens alocados era sempre 40. Ou seja, coloquei o memory pool
exatamente para este valor.
Se este valor fosse digitado por um usuário e tivesse um "if" entre
com um valor de 0 a 100. Eu colocaria 100 no meu memory pool. Agora eu
duvido que os GCs/Compiladores atuais saibam interpretar este if da
interface gráfica e relacionar com o GC para aquele objeto específico.

Além disso, o GC tem que dar conta de todas as alocações no caso de
linguagens que o GC é obrigatório. No C++ se tem um ajuste fino do que
e em quem se quer gerenciar memória.

Pode existir algum caso que não é feita nenhuma análise e a análise
mecânica do GC gera um resultado melhor. Isso também não é impossível.
Mas é uma questão somente de querer fazer melhor "na mão".

Não tem graça comparar o desempenho de C++ com outra linguagem que não
permite controle sobre o código gerado. Em C++ você chega ao limite,
nem que para isso tenha que recorrer a um bloco em assembly.

[Felipe Magno de Almeida]

2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:
>

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

[Rodrigo Kumpera]

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

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++.

O C++ pode ser tipado você o quanto você queira.

Qual C++? A última especificação que me vem a cabeça fala de uma linguagem fracamente tipada.
Para ter tipagem forte, passaria a ser uma linguagem derivada e grande parte do código existente não funcionaria.

[Rodrigo Kumpera]

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

2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:

>

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

E qual a relação em poder rodar em uma VM com poder ter um GC de alta performance?

Com C++ é impossível gerar stack maps precisos sem modificar o compilador. Isso é um dos
exemplos dos vários problemas.

[Thiago Adams]

Os tipos são fracos.
Por exemplos os enums que são herança do C.

Mas nada impede de criar seus próprios tipos que se comportem
exatamente como tipos nativos.
Isso serve para enums, inteiros, typefeds..
e eles serão fortemente tipados.

On 22 jul, 10:29, "Rodrigo Kumpera" <kump...@gmail.com> wrote:
> 2008/7/22 Thiago Adams <thiago.ad...@gmail.com>:

[Felipe Magno de Almeida]

2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:

> 2008/7/22 Felipe Magno de Almeida <felipe.m...@gmail.com>:
>>
>> 2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:
>> >
>>
>> > 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.
>
> E qual a relação em poder rodar em uma VM com poder ter um 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.

[Thiago Adams]

Um exemplo do que eu quero dizer sobre gerar tipos.

BOOST_STRONG_TYPEDEF
http://www.boost.org/doc/libs/1_35_0/boost/strong_typedef.hpp

[Marco Aurélio]

Nobre DQ,

   Independente das discussões originárias do seu lance inicial neste post, parece que o artigo da Lasse Kärkkäinen é mais isento e mais interessante, vejam:

Yet Another Java vs. C++ Shootout
http://zi.fi/shootout/

[]s

Pyro

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

[Rodrigo Kumpera]

Dá para notar pela metodologia usada que o cara entende patavinas de máquinas virtuais e como fazer benchmarking das mesmas.

2008/7/22 Marco Aurélio <pyrot...@googlemail.com>:

[Roberto Santos (DEVDIV)]

Falei de adição de níveis de indireção em um âmbito mais teórico (e citei artigos que acredito não tenham sido lidos), Kumpera deu exemplos mais pragmáticos de GC e outras interações entre runtime e memória. Muita gente ainda acha impossível que um modelo automático de gerenciamento de memória possa ser "melhor" que um manual. Vi linhas dizendo que o automático executa mais código, e não sabe o que o programador estava fazendo. Verdade, mas ao executar mais código, e ao tomar decisões em runtime, o modelo automático não se baseia em conhecimento prévio, o que pode ser "melhor". Vou tentar ilustrar isso com uma comparação, de novo, que não prova que gerenciamento automático de memória é sempre melhor, mas que mostra que sim ele pode ser "melhor".

 

Um sistema com gerência manual de memória e bem otimizado é um especialista. Ele não se adapta ao ambiente muito bem, gerencia a memória de forma muito semelhante se houver 4MB ou 4GB, se L1 for the 64kB ou 8MB, se estiver rodando sozinho ou com um programa de tocar DVD, ou se seu input for um arquivo no disco ou um usuário interativo, que está ao mesmo tempo assistindo TV e jantando. As decisões que o programador tomou em compile-time não têm como ser as melhores para todas as condições. Essas decisões são o DNA do sistema. E ele não tem níveis de indireção o suficiente para fazer muito diferente do que seu DNA determina.

 

Um sistema com diversos níveis de indireção é consciente. Ele se adapta ao ambiente, e evolui as suas técnicas em runtime. As decisões feitas em runtime, e para um caso em específico, se feitas corretamente e com eficiência, não têm poque ser piores do que as "manuais". Ser feitas corretamente e eficientemente só é algo assustador para quem está desinformado da literatura, e no caso de GC, até mesmo do status quo.

 

O DNA (tomada de decisão em tempo de compilação) é absurdamente eficiente e poderoso. Insetos, altamente especialistas (muito DNA e pouca consciência), voam muito melhor que qualquer humano! Se o desafio fosse chegar de um lugar até outro voando, até Santos Dumont ou or irmão Wright você provavelmente teria apostado num inseto. Quando os primeiros aviões apareceram, ainda mais gente teria apostado nos insento, pois exceto aos visionários, aquelas geringonças pouco eficientes, produzidas por uma sociedade que se vangloriava por estar no auge da industrialização, eram a prova de que seria impossível ser mais eficiente do que o DNA específico. Mas "consciência", a capacidade de se adaptar e evoluir sem a necessidade de mudar seu DNA (i.e. em runtime) é muito poderosa, e hoje um humano pode chegar a outro lugar, voando, mais rápido que um inseto.

 

Nenhum humano tem o DNA para voar, mas tem muita consciência. Insetos têm o DNA, mas não têm consciência. A consciêcia é um processo que "executa muito mais código", e que não tem a menor idéia do que o programador original queria atingir, mas que ainda assim atinge "melhores" resultados. Na corrida aérea, a consciência se provou mais importante do que o DNA.

 

Consciência é o equivalente à níveis adicionais de indireção (DNA é equivalente à otimização em compile time). Ela permite que o comportamente seja alterado de forma dramática, sem a necessidade que os níveis inferiores (o DNA, a parte que foi decidida em tempo de compilação) se altere. Estamos cercado de tecnologias que usam níveis adicionais de indireção para se beneficiar de melhores decisões diante de situações específicas (em runtime); não entendo porque o mesmo conceito aplicado à memória parece tão repulsivo.

 

Isso falando do feijão e arroz. Runtimes do futuro (breve) vão fazer otimizações de uso de cache como o Kumpera falou, que serão específicas para o caso de uso do usuário final. Quem sabe vão habilitar usos extraordinátios de NUMA mais baratas baseados em coisas que só uma runtime poderia fazer! Isso são coisas que no mundo manual as pessoas sequer tiveram tempo de se acostumar ainda (e.g. profile guided optimization no backend do compilador, POGO).

 

E por outro lado, se quiséssemos otimizar ao máximo o uso de memória de forma "manual", a forma como usamos C++ não costuma ser, nem de perto, a forma mais eficiente para isso. Alocamos muitos objetos na pilha. Muitos desses objetos têm destrutores. Ora, para garantir que esses destrutores sejam executandos, precisamos de stack-frames para tratar exceções, que não ocorrem a maior parte das vezes (desperdício!), e não adianta tentar otimizar muito baseado no conhecimento do próprio programa, porque ele está inserido num ambiente que possibilita exceções assíncronas. Há um custo nisso tudo. O que fazem esses destrutores? A maior parte gerencia memória alocada da heap! (nem todos desalocam, um bom númerica faz reference counting somente) Se não houver essa necessidade de gerenciar memória, podemos simplificar muitos desses frames! O código vai ser menor na imagem e na memória! Repare que o esquema de stack frames em si já é um nível adicional de indireção, para permitir que uma situação que não pode ser prevista (o stack da thread) seja tratada por um programador.

 

Mais níveis de indireção são naturais, necessários e inevitáveis. Resintence is futile. (http://en.wikipedia.org/wiki/Resistance_is_futile)

 

[Gianni]

On Tuesday 22 July 2008 12:42:15 Roberto Santos (DEVDIV) wrote:
[snip]

> Mais níveis de indireção são naturais, necessários e inevitáveis.
> Resintence is futile. (http://en.wikipedia.org/wiki/Resistance_is_futile)

Mas só se: <1 ohm

[Thiago Adams]

On 22 jul, 12:42, "Roberto Santos (DEVDIV)"

<Roberto.San...@microsoft.com> wrote:
> E por outro lado, se quiséssemos otimizar ao máximo o uso de memória de forma "manual", a forma como usamos C++ não costuma ser, nem de perto, a forma mais eficiente para isso. Alocamos muitos objetos na pilha. Muitos desses objetos têm destrutores. Ora, para garantir que esses destrutores sejam executandos, precisamos de stack-frames para tratar exceções, que não ocorrem a maior parte das vezes (desperdício!), e não adianta tentar otimizar muito baseado no conhecimento do próprio programa, porque ele está inserido num ambiente que possibilita exceções assíncronas. Há um custo nisso tudo. O que fazem esses destrutores? A maior parte gerencia memória alocada da heap! (nem todos desalocam, um bom númerica faz reference counting somente) Se não houver essa necessidade de gerenciar memória, podemos simplificar muitos desses frames! O código vai ser menor na imagem e na memória! Repare que o esquema de stack frames em si já é um nível adicional de indireção, para permitir que uma situação que não pode ser prevista (o stack da thread) seja tratada por um programador.
>

Não existem exceções assíncronas. Exceções são sempre síncronas.

E os destrutores do C++ não tem como único objetivo gerenciar memória.
A memória é apenas mais um tipo de recurso que é usado pelo objeto. É
um modelo lógico, simétrico e eficiente e chamada dos destrutores
quando ocorre uma exceção faz parte da lógica toda, independente da
memória.

[Marco Aurélio]

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

[]s


 

[Rodrigo Kumpera]

2008/7/22 Marco Aurélio <pyrot...@googlemail.com>:

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.

A grande diferença é que VMs modernas fazem JIT e o fazem de maneira adaptativa, então é necessário uma série de rounds de warm-up. Basta ler os documentos sobre a metodologia de testes do DaCapo ou da Spec.
 

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

Sistemas Life Critical exigem um grau de testes e QA que vai muito além daquilo que é razoável. Por exemplo, a exigência de alguns sistemas militares inclui que a suite de testes deve cobrir 100% do código e a derivação de segunda ordem de todos branches.

Fora isso, existe a exigência de se provar que o sistema seja hard-realtime e isso inclui medir o execution-length de todos possíveis caminhos de execução.

Fazer isso para um SO é muito difícil e ele precisa ser especialmente construído para tal propósito. O Linux tem como operar como um RTOS, mas ainda é uma piada próximo do necessário para estar pronto para sistemas Life Critical. O mesmo pode ser dito do WERT.

Máquinas virtuais com linguagens de alto nível com suporte a hard-realtime é uma coisa muito nova ainda, a VM mais antiga tem menos de cinco anos. É uma tecnologia imatura demais para esse tipo de coisa, deve levar pelo menos uns 10 anos ainda até alguém se arriscar a produzir tal sistema com Java, C# ou similares.

Basta ver que p/ usar C nesses sistemas existe uma lista ridiculamente enorme de restrições.

[Roberto Santos (DEVDIV)]

Exceções assíncronas por causa do ambiente & extensões à linguagem (que é algo previsto no standard). Não dá prá disconsiderar os muito usuários de http://msdn.microsoft.com/en-us/library/1deeycx5.aspx (que até avisa do impacto na otimização). De qualquer forma, você está estritamente mais correto, e depois que li meu texto editado (cortei muito antes de enviar, hábito que tenho) reconheço que não ficou sequer tão claro quanto o meu intuito original (era parte de um exemplo). De qualquer forma, não muda o crux da questão: mesmo com otimização estática de exceções síncronas, haverá mais stack-frames necessários to exceções que serão thrown. E no caso das thrown, a maior parte dos destrutores estão apenas lidando com memory management.

Você respondeu que é um modelo lógico, simétrico e eficiente e fez parecer que eu disse o contrário, o que não é verdade. O que disse que ele não é o mais eficiente possível, e que adiciona custo em relação ao que seria "mais manual e especialista" e, ainda mais, é justamente uma instância de nível adicional de indireção. Se esse nível funcinou tão bem que algumas pessoas (não estou dizendo você) até param de pensar que ele existe e o encaram como a forma mais eficiente, é ainda mais natural que a evolução da tecnologia vá aperfeiçoar e aumentar esse método ainda mais. E, dado o devido tempo, esse será o novo status quo. Também disse que o status quo de automatic memory management de hoje já retira aquele custo específico que citei. De resto, também acho o modelo lógico, simétrico e satisfatoriamente eficiente. Também acho que há muito desperdício e pouca flexibilidade em runtime.

Disclaimer: Como surgiu o comentário um palestrante da empresa onde trabalho, devo dizer que essas são minhas opiniões pessoais e não do meu empregador.

-----Original Message-----
From: ccppb...@googlegroups.com [mailto:ccppb...@googlegroups.com] On Behalf Of Thiago Adams
Sent: Tuesday, July 22, 2008 1:50 PM
To: ccppbrasil
Subject: [ccppbrasil] Re: C++ lento?

[Roberto Santos (DEVDIV)]

Resistance is futile era prá ser engraçado, não era parte do argumento :-) Quanto à referências, pode começar por esse aqui: http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbibA.html.

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?

[Thiago Adams]

...

". E no caso das thrown, a maior parte dos destrutores estão apenas
lidando com memory management."

Na verdade a maior parte dos objetos deveriam ser criados na pilha.
Não existe prejuízo de performance no destrutor. (Notem que o exemplo
que comparou com java fez exatamente o que não é para fazer)
Dentro de cada objeto alocado na pilha poderá ter memória gerenciada.
Neste caso você também gerência como quiser e como for eficiente para
o problema.

É possível no C++ fazer sem exceções se o problema "pedir".

[Roberto Santos (DEVDIV)]

> Na verdade a maior parte dos objetos deveriam ser criados na pilha.
> Não existe prejuízo de performance no destrutor.

> Dentro de cada objeto alocado na pilha poderá ter memória gerenciada.

Isso é exatamente o que disse que acontence mais frequentemente...

> Neste caso você também gerência como quiser e como for eficiente para
> o problema.

... e gerenciamento automático com níveis adicionais de inferência podem sim melhores. Além de que o problema, mais frequentemente que não, não pode ser considerado como um programa único, mas um ecosistema. E que o problema, mais frequentemente que não, não pode ser previamente conhecido em infinito detalhamento em termos de cenário de uso e carga.

-----Original Message-----
From: ccppb...@googlegroups.com [mailto:ccppb...@googlegroups.com] On Behalf Of Thiago Adams
Sent: Tuesday, July 22, 2008 2:39 PM
To: ccppbrasil
Subject: [ccppbrasil] Re: C++ lento?

[/* Alberto Fabiano */]

2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:

     A propósito,  são para estes casos que se aplica do MISRA C que foi comentado aqui em discussão anterior, como uma correção que na época eu havia comentado que o MISRA C++ estava para sair, porém agora ele já é uma realidade.

     Este é um questionamento que eu já fiz para alguns especialistas e a resposta que eu já recebi várias vezes é que RTOS e inclusive o Windows CE tem sido utilizado em sistemas de "apoio médico", pois em sistemas de Life Maitenance tem imperado o código bare-metal e ainda sobre rígidos processos de codificação, testes, revisão e homlogação.


[1] MISRA C, JSF e afins
    http://groups.google.com.br/group/ccppbrasil/browse_thread/thread/193b9c704a0e0578/f9178b8f9e46dfc5

[2] MISRA C++,
    http://www.misra-cpp.org/

[3] Misra C++ - Intro
    User Experience of Tools for Safety-Critical Systems
    http://www.misra-cpp.org/downloads/SCSC-Tapp.pdf

[ari...@sardano.net]

Felipe Magno de Almeida escreveu:

> 2008/7/22 Rodrigo Kumpera <kum...@gmail.com>:
>
>
>
>> 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.
>
> [snip]
>
>

Boa pergunta Felipe!

Sei que existem interpretadores para C++.

Mas...existe alguma VM para rodar C++?

[Rodrigo Kumpera]

2008/7/22 <ari...@sardano.net>:

Qual a diferença entre um interpretador e uma máquina virtual? Nenhuma, por sinal.

De qualquer forma, usando LLVM é possível compilar C++ p/ uma linguagem intermediária
e executar com JIT.

[Roberto Santos (DEVDIV)]

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