Logo Hardware.com.br
ricardo.calister
ricardo.cali... Novo Membro Registrado
18 Mensagens 0 Curtidas

Compilador_C++

#1 Por ricardo.cali... 15/02/2014 - 17:15
Olá a todos
eu preciso de uma ajuda, neste momento eu estou usando o compilador g++ para a versão linux, eu preciso declarar vetores estáticos do tipo float. No meu programa eu preciso declarar 20 vetores float com 4.1x10 ^ 6 elementos cada. mas o compilador permite declarar 2.9x10 ^ 5 para cada vetor. é possível a utilização de mais memória para vetor estatico com g++? Existe algum compilador para C++ (para linux) que permiti a fazer isso?
Eu uso o Ubuntu 12.04 LTS, eu tenho um computador com (1,5 GB de memória RAM e outro com 3 GB de memória RAM), mas eu posso declarar apenas 2,9 x10 ^ 5 mesmo quando eu estou usando o dobro de memória RAM(tanto faz usar 1,5G ou 3GBytes). Declaro as variáveis na área geral (antes do principal main() e das funções e classes), ou seja, fora da área de pilha.

Eu testei gfortran (compilador Fortran) que permitem declarar mais, vetores estáticos, mas porém meu código está em C ++! também eu não posso usar vetor dinâmico.

Por favor, alguém poderia me ajudar?

Obrigado !

Ricardo
Gokuro
Gokuro Veterano Registrado
704 Mensagens 76 Curtidas
#2 Por Gokuro
15/02/2014 - 19:34
Sugestão: separe os dados do código.

Contorne a restrição armazenando as matrizes em disco com substituição dos acessos a elementos das matrizes por funções apropriadas e alternativamente visando facilitar a implementação, use banco de dados i.e.: matriz(es) armazenada(s) em tabela(s), que permitem naturalmente acesso indexado otimizado (desejável para matrizes esparsas) e de quebra: acesso a elementos em "cache".
Duas sugestões de API de DB com interface para C/C++:
SQLite C/C++ interface Spec
MySQL Connector/C++

[
]'s
ricardo.calister
ricardo.cali... Novo Membro Registrado
18 Mensagens 0 Curtidas
#4 Por ricardo.cali...
18/02/2014 - 12:25
Olá a todos,

Primeiramente eu uso o codeblock, o code block usa o compilador g++, e já rodeio programa tanto com o codeblock como por linha de comando (usando somente o compilador).
O codeblock e o DevC++ são IDE e ambos usam o compilador g++ em Linux.

Quanto a armazenar uma matriz em disco, é rápido a leitura disto ? pois meu programa deve resolver em torno de 1.200.000 equações (como faço evolução temporal resolvo essa quantidade dezenas de vezes), e antes de resolver ele deve varrer os vetores e montar as equações, por exemplo com lista ligadas simples demora muito mas muito para varer este vetores dinâmicos é dar um e ir dormir...

Obrigado pelos comentários

Abraço
ricardo.calister
ricardo.cali... Novo Membro Registrado
18 Mensagens 0 Curtidas
#5 Por ricardo.cali...
18/02/2014 - 12:40
Complementando, com Fortran é possível declarar mais vetores estáticos que C/C++ ? mas tem vários compiladores Fortran que são escreito em C..
ou seja, existe um compilador C++ livre que pode permitir ter vetores estáticos maiores ? Pois em Fortran é possível..ou seja, há memória RAM suficiente, poi se fosse memória esgotada tanto em Fortran quanto em C/C++ dariam problema de falta de memória !

Já me arrependo de desenvolver todo programa em C++ frown.png

Abraços
Gokuro
Gokuro Veterano Registrado
704 Mensagens 76 Curtidas
#6 Por Gokuro
18/02/2014 - 13:47
Quanto a armazenar uma matriz em disco, é rápido a leitura disto?
SIm, é satisfatório porém dependente do hardware, tipo/status do dispositivo de armazenagem, da formatação do dispositivo, etc, e diante da magnitude das várias matrizes, esparsas ou não, sempre haverá penalização de tempo de processamento devido aos acessos e assim temos nova alternativa: usar a ideia/sugestão em discos virtuais...um mimo, ao menos no Linux.
...meu programa deve resolver em torno de 1.200.000 equações...
(comentários omitidos) no mínimo você precisa de hardware/software a altura e como você citou "lista ligada simples", lembre-se que DBs usam estruturas de dados muito mais eficientes.
...com Fortran é possível declarar mais vetores estáticos que C/C++ ?
Não, igual montante com perda de produtividade.
...me arrependo de desenvolver todo programa em C++
Bobagem, você acertou.

[
]'s
ricardo.calister
ricardo.cali... Novo Membro Registrado
18 Mensagens 0 Curtidas
#9 Por ricardo.cali...
23/02/2014 - 15:39
Olá Gokuro
Sim com Fortran a declaração de variáveis é bem maior..testei a mesma declaração de variáveis em um IDE fortran Plato(Silverfrost FTN95) com o mesmo hardware (pentium dualcore de 2Mhz e 3 GBytes de RAM) , e com o windows 7 (neste computador tenho dual boot) e consegui declarar vetores muito muito maiores ! 17 vezes maior ! e ele permite.., e abro outro aplicativos,e tudo bem !, ou seja, acredito quem limita vetores estáticos são os compliladores..no windows 7 se usar o compilador g++ ele ainda permite armazenar menos vetores estáticos que no ubuntu. A diferença entre o Silverfrost e o g++ (rodo via codeblocks) é que um mesmo programa (que faz a mesma coisa) o g++ é muito mais rápido.
Eu não tarbalho com computação, a linguagem é uma ferramenta, eu estudo física e não entendo de DB.. preciso ver o quanto é complexo usar isso..mantendo o hardware sem alteração, pois não tenho dinheiro para comprar nenhum Hardware novo.

Obrigado !!
Gokuro
Gokuro Veterano Registrado
704 Mensagens 76 Curtidas
#10 Por Gokuro
23/02/2014 - 17:39
Eu não trabalho com computação...
isto non existe mais! rindo_ate_agora.png
Programação é a atividade + maquiavélica (no bom sentido) de todos os tempos.

..acredito que; quem limita vetores estáticos são os compiladores...
Sim, são projetados para aproveitar o hardware ao máximo, mas no Linux os compiladores são genéricos com parametrizações especificas para algumas arquiteturas: gcc specific instalation notes

...não entendo de DB...
Para quem trabalha com física, SQL (lnguagem dos DBs) é trivial, mas de fato não há necessidade. Se os arquivos das matrizes forem armazenados em disco virtual, o desempenho do aplicativo poderá surpreender positivamente: HD Virtual na RAM

Execute o script abaixo e acesse/use a partição /mnt/hdram para avaliar a ideia:
#!/bin/bash
#
# Monta sistema de arquivos na RAM conforme parâmetros declarados opcionalmente:
# * tamanho da partição em kbytes > 0
# * tipo do sistema de arquivos: ext2, ext3 ou ext4.
#
if [[ $USER != root ]]; then
echo -e '\n\tAtenção: "'$USER'" não tem privilégios para executar "'$0'".\n'
exit 1
fi
# extrai/valida os parâmetros declarados
while [[ $@ ]]; do
if [[ $1 =~ ^[[:digit:]]+$ ]]; then
(( $1 > 0 )) && KBYTES=$1
elif [[ ${1,,} =~ ^ext[234]$ ]]; then
FS_TYPE=${BASH_REMATCH[0]}
fi
shift
done
# default dos parâmetros não declarados
FS_TYPE=${FS_TYPE:-'ext2'}
KBYTES=${KBYTES:-1024}
# garante memória suficiente para criação de "journal" do ext3/ext4
[[ $FS_TYPE != ext2 ]] && (( $KBYTES < 2048 )) && KBYTES=2048
#
declare -r TARGET_DEV=/dev/ram0
declare -r TARGET_DIR=/mnt/hdram
# prepara o dispositivo a ser montado copiando conteúdo de /dev/zero
dd if=/dev/zero of=$TARGET_DEV bs=1k count=$KBYTES
# formata o dispositivo que de facto não é partição e nem bloco especial
mke2fs -v -F -m 0 -t $FS_TYPE $TARGET_DEV $KBYTES
# garante disponibilidade do ponto de montagem
[[ -e $TARGET_DIR ]] || { mkdir $TARGET_DIR; chmod -R 777 $TARGET_DIR; }
mount -t $FS_TYPE $TARGET_DEV $TARGET_DIR
Nota: A partição não persistente entre sessões pode ser desmontada via comando umount:

# sudo umount /mnt/hdram

Muito sucesso!

[
]'s
intruso
intruso Tô em todas Registrado
1.8K Mensagens 41 Curtidas
#12 Por intruso
27/02/2014 - 20:57
Gokuro disse:



Minha recomendação é fazer benchmark para o seu tipo de operação. Operações em disco geralmente são muito mais lentas do que operações em memória (geralmente, não é regra, depende o que você está fazendo).

Mas, você realmente precisa de um vetor estático? é simplesmente por causa da indexação/varredura? Estudar o tipo de varredura pode ser uma solução mais simples.

Manter os dados ordenados pode ser outra solução e a indexação de um vetor estático usa na verdade aritmética de ponteiros, não me parece algo lento e na verdade, você pode percorrer um vetor usando o ponteiro que identifica a primeira posição dele.

Geralmente sistemas usam soluções hibridas de memória para ganhar agilidade, cache é justamente isso. A paginação é justamente o uso do disco para compensar memória ram, eu não uso paginação, mas, tenho um note com 12gb de ram dedicada.

O proprios bancos de dados possuem mecanismos para manter os dados mais requisitados em memória e você ainda tem o "overread" manipulando as conexões e no final vai ter de conservar os dados em memória em alguma estrutura de dados qualquer para poder operar.

Dá uma explicada melhor no problema, quem sabe podemos recomendar uma solução melhor ou te ajudar a comparar a performance.

Se der, poste um trecho de código ou diga o nome do fenômeno que está tentando simular, quem sabe achamos alguma coisa na net que te ajude.

Abs
ricardo.calister
ricardo.cali... Novo Membro Registrado
18 Mensagens 0 Curtidas
#13 Por ricardo.cali...
02/03/2014 - 16:12
Olá intruso,
Bom meu problema é bem complicado em termos físicos, eu faço evolução temporal de discos ,que podem representar Galáxias, por exemplo, então eu resolvo uma equação que se chama equação de Fokker-Planck, cujo resultaldo é uma função que dá a probabilidade de encontrar uma estrela na posição r+dr e com velocidade v+dv. O programa em si é bem grande, tem métodos de resolução de sistemas lineares (3 métodos implementados no qual podemos escolher), integrais duplas, interpolações, etc. tudo funcionando bem, então eu tenho algo que chamamos de espaço de fases (posições e velocidades) para montar as equações para por exemplo um ponto, eu tenho uma equação Ao*f0+B*f310+C0+f8000+...=Q0, ou seja além de armazenar um monte de valores de f(variável a ser resolvida), eu preciso de desempenho, pois eu resolvo estas equações não somente uma vez..mas um monte de vezes..cada tempo t0,t1,t2...tn, eu monto e resolvo todas estas equações.., pois eu analiso a evolução dinãmica do disco e com vetores estáticos é satisfatório a velocidade, mas agora eu preciso deixar uma região de "vácuo" e ver a massa migrar para essa região, bom então eu preciso aumentar o número de pontos..de 25^4 equações (390.625 equações) hoje resolvo bem isto, para em torno de 50^2*25^2=1.562.500 equações, vc não consegue alocar isto com vetores estáticos com o g++, mas um compilador gfortran vc consegue..então há uma limitação de alocação do g++ para vetor estáticos, pois se fosse problema físico (limite de memória) um compilador Fortran não deixaria alocar..mesmo no meu hardware um tanto limitado.
O problema é bem complexo mesmo usando coisas simples de programação, por isso estava evitando carregar mais com outras estruturas de dados (testei lista dinâmica simples claro que aloca mas é muito muito lenta para montar as equações), eu não tenho também muito tempo para alterar muito o programa, pois termino meu curso logo..e tenho que defender a tese..é isso, caso não tivessemos que usar em volta do disco uma região de vácuo..mesmo com hardware limitado o metodos numéricos usados são rápidos faz as contas rápidos..coisa de minutos..agora se der um enter e demorar horas até saber se um cálculo está certo ou não..é complicado..

Obrigado !

Abs
intruso
intruso Tô em todas Registrado
1.8K Mensagens 41 Curtidas
#15 Por intruso
05/03/2014 - 10:56
O problema em usar as listas encadeadas me parece o mesmo problema em usar alocação dinâmica, ou seja, você não garante que os dados estarão alocados em um espaço contínuo de memória, como nos vetores.

Então, me parece que o seu "montar" as equações demora porque o programa tem que solicitar blocos de memória livre para o SO enquanto que nos vetores o número de requisições de memória é o número de vetores, quando você passa a alocar exponencialmente, o numero de requisições passa a ser exponencial e por tabela o tempo de execução sofre uma demora exponencial também. Sem falar que nos vetores o espaço de memória é percorrido linearmente, então seu problema seria ter um espaço de memória contíguo maior para os vetores onde a resolução de endereços é basicamente aritmética de ponteiros, o que é muito mais rápido.

O problema pra mim é que você aumenta o numero de equações de forma exponencial, ai fica difícil de dar uma sugestão num primeiro momento.

Em ultimo caso, migrar de linguagem para ganhar performance não me parece uma má ideia. Alocação de memória é um item que varia muito de plataforma (SO)/compilador e arquitetura de hardware.

Estou pesquisando para ver se encontro uma solução, mas, não seria uma coisa trivial e provavelmente terás de alterar coisas que talvez, não valem a pena.

Sua máquina é de 32 bits, correto? `Geralmente o valor máximo de alocação é uma potência de 2 no caso, 2^32 para char, e vai diminuindo, quanto maior o tipo (double, int, float). Porém, esse é um número teórico.

E porque outras linguagens (fortran ou lisp ou haskell) não apresentam esse problema? Não sei de fortran, mas, tenha em mente que a forma como alocação é feita depende da implementação e do paradigma da linguagem. Linguagens funcionais foram feitas para lidarem com conceitos matemáticos abstratos e não fazem toda a alocação de memória no momento da requisição, na verdade, você poderia ter "vetores infinitos" em haskell/lisp e isso não existe na pratica.

Mas, ao mesmo tempo, você tem o limite de memória física, que vai sempre estourar e em haskell/lisp não tem esse negócio de 'variável', é recursividade na veia.

Esses coeficientes precisam ser float? Tipos mais simples aumentam o valor máximo do vetor.

Poderia me fazer um favor, me retorna os valores dessas chamadas:

[code=rich]
  • std::vector::max_size()
  • std::vector::max_size()
  • std::vector::max_size()
[/code]
© 1999-2025 Hardware.com.br. Todos os direitos reservados.
Imagem do Modal