Escolha C ++ ou Java para aplicativos que exigem grandes quantidades de RAM? [fechadas]


11

Estou pensando em aplicativos científicos que são principalmente vinculados ao processador e pesados ​​no uso de heap (pelo menos vários gigabytes). Em qualquer outra época do ano, eu ficaria feliz em usar o C ++, mas, neste caso, gostaria de saber se a fragmentação natural do gerenciador de memória C ++ pode ser um problema sério versus a vantagem dos coletores de compactação do Java.

Alguém pode apontar para exemplos do mundo real relacionados a isso?


Não acho que a linguagem seja tão importante quanto a programação neste caso. Qualquer linguagem madura provavelmente funcionará dependendo da escala do seu cálculo. Existem Javas, C / C ++, até Pythons e Rubies que podem se encaixar nessa função. Alguns seriam mais difíceis do que outros, pois parece que você realmente precisa ter uma garantia firme de que não está perdendo memória.
Rig

2
Se você conseguir um GB por US $ 7,99, isso é um problema? Kingston 1GB DDR3
Bo Persson

2
@BoPersson, na minha experiência, as pessoas que enfrentam esse tipo de problema começam a preencher completamente sua placa-mãe de ponta e reclamam que não podem colocar lá o quanto desejam e, em seguida, alimentam dados tão grandes quanto possível de gerenciar e depois reclamam que não é suficiente.
AProgrammer

@dsign, atualmente onde você pode obter placas-mãe aceitando várias centenas de shows de memória por menos de 1000 €, alguns shows não são pesados ​​em uso de memória.
AProgramador

1
Concorde com a parte da memória barata. Quanto ao desenvolvimento, estou no C ++ há algum tempo e as boas práticas de codificação tornam os vazamentos um fenômeno pouco frequente; por uma questão de fato, eu realmente prefiro C ++ sobre java nesse sentido.
Dsign

Respostas:


11

Se você está falando de um aplicativo que deve estressar os limites da máquina, de modo que espera executar truques de programação para evitar exceder esses limites, o C ++ é o caminho a seguir. Não apenas o C ++ oferece espaço para otimização onde o Java não funciona (como apontou Emilio), mas também os Garbage-Collectors são equipamentos que consomem muita memória e precisam de muita memória livre extra para funcionar com eficiência.

As respostas a esta pergunta: StackOverflow: Quanta memória extra é necessária para a coleta de lixo ? pintar um quadro bastante sombrio, mas mesmo se coletores de lixo precisa a memória livre para ser apenas cerca de tanta como a memória alocada, (que é o que eu tinha ouvido falar,) isto significa ainda que, com Java você ainda vai precisar de um monte de memória livre para que ele funcione com eficiência.

Por outro lado, hoje em dia geralmente preferimos comprar hardware mais caro do que ter que executar truques de programação para evitar exceder os limites do hardware. No seu caso, seus problemas de RAM normalmente seriam resolvidos usando uma máquina de 64 bits e jogando quantos módulos de RAM fossem necessários. Veja bem, o custo do hardware não chega nem perto do custo do tempo de desenvolvimento no mundo desenvolvido atualmente.

Eu acho que você deve considerar seriamente essa opção e, se possível, optar por essa opção e pelo Java em vez do C ++, porque é muito mais fácil desenvolver algo em Java do que em C ++ e mantê-lo posteriormente.


Obrigado pela sua resposta. Eu concordo com a sua ilustração de hardware.
Dsign

Se você não se importa com a pausa do programa enquanto a coleta de lixo é executada, as necessidades de memória são muito menores.

1
Não concordo com o último parágrafo. Java não é necessariamente mais fácil de desenvolver do que C ++. Não seria para mim, já que fiz muito C ++ e relativamente pouco Java nos últimos cinco ou seis anos. É possível escrever código sustentável e não-sustentável tanto em C ++ quanto em Java.
David Thornley

1
@DavidThornley Faço C / C ++ há mais de 10 anos e Java há mais de 6 anos. Acho que o Java é mais fácil em todos os aspectos: criação de protótipos, desenvolvimento, extensão e manutenção. Mas, de qualquer forma, é isso que as opiniões devem fazer: diferem . C:: =
Mike Nakis

Algum de vocês programou para um projeto com grande volume de dados e com fome de processador? Algum comentário aí?
usar o seguinte comando

7

O problema não é usar C ++, pois é Java e não usar Java, pois é C ++. Um contêiner C ++ é normalmente implementado para evitar excesso de fragmentação, assim como o armazenamento gratuito em Java.

Mas se você se alocar diretamente a memória, poderá fazer coisas que Java não permite, que podem resultar em fragmentação.

A solução adequada (em C ++) é usar contêiner e ponteiros inteligentes por meio de classes alocadoras que gerenciam a alocação por meio de "plexes" fixos (o ponto principal, aqui, é escrever uma boa classe alocadora). E esse é um estilo de programação que não tem nada a ver com Java; portanto, qualquer comparação não faz sentido.

[EDIT] Pode ser uma amostra desatualizada: alocação fixa


Obrigado pela sua resposta Emilio. Estou ciente da flexibilidade do C ++ e sinto-me inclinado a concordar com você. Então, novamente, eu gostaria de conhecer alguns exemplos de uso real onde essas técnicas foram usadas para o sucesso.
Página

@dsign: Post editado, consulte o link
Emilio Garavaglia

1
Eu usei essas técnicas anteriormente. Um aplicativo com desempenho ruim teve seu alocador alterado para usar um conjunto de pilhas de blocos fixos. Então, quando você queria um bloco de 4 bytes, veio do heap que armazenava apenas blocos de 4 bytes. Se você queria 5 bytes, veio do heap de bloco de 8 bytes, etc. O aumento de desempenho (para o nosso aplicativo de alocação pesada) foi tremendo. Você pode não obter um resultado tão bom, mas pode ser muito eficaz. Também houve fragmentação zero, pois todas as alocações vieram em blocos fixos.
Gbjbaanb

2

A vantagem da coleta de lixo é que ela simula uma máquina com uma quantidade infinita de memória. O mecanismo ou implementação dessa abstração pretende ser completamente transparente para você como programador. Todos sabemos que o mecanismo está recuperando a memória que não é mais usada pelo programa, mas que não é realmente garantida. Se você executar o programa em uma máquina com mais RAM do que o programa realmente usa, a coleta de lixo poderá nunca ocorrer. Novamente, irrelevante, porque você pode simplesmente escrever o programa sem levar em consideração como ele usa memória. O gerenciador de memória apenas alocará mais RAM sempre que o programa solicitar, e você poderá assumir que essas alocações sempre serão bem-sucedidas. Java é uma linguagem de coleta de lixo e C ++ não. 1

A desvantagem da coleta de lixo é que, como todas as abstrações , ela tende a vazar. Nem sempre funciona perfeitamente o tempo todo, principalmente em casos extremos, e é provável que você encontre bugs. As pessoas que criaram o algoritmo de coleta de lixo (aquele que deveria ser transparente para você como programador) foram otimizadas para os casos mais comuns, e o problema com casos comuns é que eles nunca são tão comuns. Em geral , você não pode fazer melhor do que o coletor de lixo no gerenciamento de memória. Mas em circunstâncias específicas (e com uma quantidade suficiente de tempo, energia e compreensão), isso pode ser possível. C ++ oferece essa flexibilidade; Java não.

Tudo isso dito, acho que o conselho padrão para a escolha de um idioma se aplica aqui, talvez ainda mais neste caso, dadas as restrições. Escolha o idioma que é o mais familiar para os desenvolvedores principais do projeto. Além dos motivos óbvios (como você poderá desenvolver o aplicativo com mais rapidez e eficiência), isso é particularmenteimportante no caso que você descreve, porque programar C ++ como você está programando Java resultará em práticas de gerenciamento de memória terrivelmente ineficazes e, portanto, vazará e trará falhas. Analogamente, programar em Java como você está programando em C ++ não fará muito bem e pode acabar produzindo um programa menos que otimizado, já que os algoritmos de coleta de lixo são aprimorados e ajustados para os casos mais comuns .

Os programadores que estão acostumados a trabalhar em idiomas coletados pelo lixo aprendem a confiar no coletor de lixo, em vez de lutar contra ele. Se você estiver trabalhando em uma linguagem de coleta de lixo, estes são os programadores que você deseja no seu projeto. Programadores que não sãoacostumado a trabalhar em uma linguagem de coleta de lixo é inerentemente cético em relação a essa abstração de "memória infinita" e frequentemente com muitas boas razões. Por mais bons que sejam esses programadores, não são esses que você deseja trabalhar em uma linguagem de coleta de lixo, porque eles estarão lutando contra o GC a cada passo do caminho, constantemente adivinhando-o e produzindo frequentemente mais lento e menos eficiente em termos de memória código que o outro tipo de programador. Na melhor das hipóteses, eles gastam muito tempo reinventando a roda, custando muito dinheiro e ainda mais em custos de manutenção a longo prazo.

E então você também precisa se perguntar se isso realmente importa. Há mais do que uma pitada de verdade no comentário sarcástico de Bo: a memória é tão barata agora, dificilmente vale muito a pena. Mesmo se você precisar de grandes quantidades, essas quantias não são tão grandes agora como eram há 10 anos. Programadores e desenvolvimento de aplicativos são muito mais caros do que apenas comprar grandes quantidades de RAM e poder de processamento. Isso não significa que você deve evitar a economia sempre que possível, mas também não deve perder muito tempo fazendo isso.


1 Obviamente, essa suposição destaca uma falha mais profunda na questão. Como se vê, "Java ou C ++" é um arenque vermelho. A implementação Java padrão fornece coleta de lixo e o C ++ não atende ao padrão da linguagem, mas não há absolutamente nenhuma razão para que você não possa usar um coletor de lixo de terceiros para o C ++. Muitas empresas ganharam a vida vendendo essas coisas, e algumas provavelmente ganharam a vida dando-as de graça.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.