Números aleatórios para vários segmentos
Eu pretendo escrever um aplicativo C ++ 11 para Linux que faça alguma simulação numérica (não criptografia) baseada em aproximadamente um milhão de números 32bit pseudo-aleatórios. Para acelerar as coisas, eu gostaria de realizar a simulação em threads paralelos usando todos os núcleos de uma CPU de desktop. Eu gostaria de usar o Mersenne Twistermt19937 fornecido pelo boost como o PRNG, e eu acho que por razões de desempenho eu deveria ter um tal PRNG por thread. Agora não tenho certeza sobre como gerá-los para evitar gerar a mesma subsequência de números aleatórios em vários segmentos.
Aqui estão as alternativas que pensei até agora:
Semente o PRNG para cada segmento independentemente de/dev/urandom.
Estou um pouco preocupado com o caso quando o pool de entropia do sistema se esgota, pois não sei como o PRNG interno do sistema opera. Poderia acontecer que eu acidentalmente pegue sementes consecutivas que identifiquem exatamente estados consecutivos do Mersenne Twister, devido ao fato de que/dev/urandom está usando um Mersenne Twister em si? Provavelmente fortemente relacionado com as minhas preocupações para o próximo ponto.
Semente PRNG de/dev/urandom e os outros daquele primeiro.
Basicamente, a mesma preocupação também: é bom ou ruim usar um PRNG para semear outro que use o mesmo algoritmo? Ou em outras palavras, lê 625 inteiros de 32 bits de ummt19937 correspondem diretamente ao estado interno domt19937 gerador em qualquer ponto durante esta geração?
Semente outros de primeiro com informações não-Mersenne.
Como usar o mesmo algoritmo para gerar números aleatórios e gerar a semente inicial parece, de alguma forma, que pode ser uma má idéia, pensei em introduzir algum elemento que não seja dependente do algoritmo Mersenne Twister. Por exemplo, eu poderia XOR o id do segmento em cada elemento do vetor inicial de semente. Isso torna as coisas melhores?
Compartilhe um PRNG entre os segmentos.
Isso garantiria que houvesse apenas uma seqüência, com todas as propriedades conhecidas e desejáveis do Mersenne Twister. Mas a sobrecarga de bloqueio necessária para controlar o acesso a esse gerador me preocupa um pouco. Como não encontrei nenhuma evidência em contrário, presumo que eu, como usuário da biblioteca, seria responsável por impedir o acesso simultâneo ao PRNG.
Pré-gerar todos os números aleatórios.
Isso faria com que um encadeamento gerasse todos os números aleatórios 1M necessários na frente, para serem usados pelos diferentes encadeamentos posteriormente. O requisito de memória da 4M seria pequeno comparado ao da aplicação geral. O que mais me preocupa nessa abordagem é que a geração de números aleatórios em si não é concorrente. Toda essa abordagem também não escala muito bem.
QuestõesQuais dessas abordagens você sugeriria e por quê? Ou você tem uma sugestão diferente?
Você sabe quais das minhas preocupações são justificadas e quais são simplesmente devido à minha falta de percepção de como as coisas realmente funcionam?