Atualmente, estou usando 4 GB de RAM como cache de RAM usando o FancyCache, ele armazena em cache meu SSD. Está funcionando muito bem com jogos, pois o tempo de carregamento é quase zero, e também está funcionando bem com o pacote da Adobe. Está diminuindo o uso do meu SSD também, o que é uma coisa boa.
Eu tenho 16 GB de RAM no total e minha pergunta é, você diria que obter 16 GB de RAM adicional e usá-lo para o FancyCache seria benéfico?
Obrigado! (Eu percebo que esta pergunta não é muito orientada para o problema e se não é o fórum certo para isso, peço desculpas)
Especificações do meu computador: Asus P9X79 Deluxe, i7 3930K a 4,3 Ghz, Corsair Vengence LP de 4 x 4 GB, Samsung SSD 830 de 256 GB, Win 7 Pro x64
A partir de agora (maio de 2012), eu diria que ter mais 16 GB ou RAM para usar no FancyCache seria dinheiro bem gasto. Se você jogar vários jogos diferentes além de usar aplicativos grandes, não deverá ter problemas para preencher o cache de 16 GB. 16 GB de RAM extra não é um investimento muito grande, e garantirá que seu sistema permaneça rápido e responsivo ao alternar entre grandes aplicativos e jogos.
Tenho 48 GB de RAM (plataforma X58 com 6x8 GB) e dediquei 16 GB ao FancyCache no Win7. O FancyCache vem com um monitoramento integrado. O monitoramento da utilização é, de longe, a coisa mais importante que você pode fazer para determinar isso.
Eu estou usando esta caixa para quebrar senhas usando dicionários grandes (~ 400GB), então eu estava esperando, pelo menos, manter na RAM alguns dos dicionários mais utilizados. Para minha surpresa, por causa de como meus scripts foram configurados, eu estava fazendo o mesmo conjunto de hashes com diferentes dicionários, efetivamente 'sujando' meu cache lendo continuamente em novos dicionários. Como resultado disso, minha taxa de acertos do cache foi terrivelmente ruim (algo como 0,1%). Então eu mudei a ordem assim:
de
for hash in hashes;
for dict in dicts;
crack hash with dict
para
for dict in dicts;
for hash in hashes;
crack hash with dict'
Desta forma, o dicionário que acabou de ser lido permanece na memória para o próximo conjunto de hashes, e a próxima leitura ocorre a partir da RAM e não do disco.
Este pequeno order-flip despertou o cache de leitura, já que agora ele está em torno de 80%. Essa observação valeu a pena em ouro.
Além disso, limitar seu FancyCache a funcionar apenas em discos com os dados que você sabe que vai ter IO pesado, e não depender do sistema operacional para descobrir isso, também é bastante benéfico.
A segunda melhor coisa que fiz foi observar os comportamentos de gravação em cache. Acontece que alguns programas estão sendo seguros e tentam despejar dados após cada pequena chance, em vez de mesclar várias gravações em gravações menos frequentes, mas maiores. Quando feito de forma totalmente síncrona, isso fazia com que o programa bloqueasse até que a gravação fosse concluída. Minha caixa está em um no-break, então não preciso me preocupar com ampliações antes que o cache de gravação conclua o write-back. Isso ajudou imensamente com a performance bruta do meu programa principal, mas também ajudou visivelmente na suavidade do sistema, já que o sistema não pararia toda vez que o cache de gravação estivesse ocupado enviando buffers sujos para o disco. Claro, sem um no-break (ou uma bateria se for um laptop), esse seria um cenário perigoso.
Todas essas coisas chegam a um problema fundamental de CS se o tamanho do 'conjunto de trabalho'. Se você estiver trabalhando em um único arquivo de 4GB, provavelmente um pouco mais de 4GB funcionará bem (a menos que o aplicativo tente armazenar vários níveis de desfazer na memória). Não há como alocar memória para o FancyCache, a menos que você esteja realmente usando. Se você está perto de 100% dele, faça-o maior, mas se você está com 2%, então você está apenas desperdiçando RAM.