Si tu veux faire du ternaire, en effet, ca marche plus d'utiliser directement les bits sur disque (ou tu utilises 2 bits par ternaire, mais tu perds un peu de "place")
Comment sais-tu d'avance que tes cellules vivantes seront rares?
Sachant qu'il te faudra, au strict minimum, 32 ou 64 bits d'adressage, ça peut n'être rentable que si tu as moins de 1/64e de bits actifs. Et encore, même là, il faudra que les adressages soit ordonnées si tu veux chercher facilement & rapidement là dedans (sinon, en gros, tu as le processeur qui va se pallucher chaque adresse une à une jusqu'à trouver celle que tu cherches). Ce dernier point pouvant être ignoré si tu process de toute façon toutes les cellules, dans un ordre indéterminé/osef, mais apparemment, c'est pas le cas si je comprends bien: tu émules ici une machine de turing avec une seule tête de lecture.*
Après, si tu comptes les faire en jeuweb, je ne pense pas que tu puisses créer un fichier de 2To sur le disque du joueur x)
Faire des sous-fichiers/sous-dossiers, je pense que ce n'est pas une bonne idée, vu que tu as dit qu'il y aurait des milliards de bits dans ton automate. Ca va encombrer inutilement les choses, sans améliorer les perfs (par rapport à un seul fichier d'un bloc dans lequel tu accèdes au N-eme bit directement, ou au 2xNeme bit si jamais tu veux faire du ternaire). Mais forcément, ca demandera aux joueurs d'accepter qu'un jeu du genre prenne 2To sur leur disque x)
* Ceci est à matériel constant: entre un accès disque au N-eme bit, ou un accès par adressage 64bits dans la RAM, la RAM sera très probablement plus rapide, même si'lo faut checker 10.000 adresses (mais là, faudrait savoir si vraiment tu as 1/100k-eme des bits actifs, ou si c'est juste du "je pense qu'au feeling ça sera ça"
Comment sais-tu d'avance que tes cellules vivantes seront rares?
Sachant qu'il te faudra, au strict minimum, 32 ou 64 bits d'adressage, ça peut n'être rentable que si tu as moins de 1/64e de bits actifs. Et encore, même là, il faudra que les adressages soit ordonnées si tu veux chercher facilement & rapidement là dedans (sinon, en gros, tu as le processeur qui va se pallucher chaque adresse une à une jusqu'à trouver celle que tu cherches). Ce dernier point pouvant être ignoré si tu process de toute façon toutes les cellules, dans un ordre indéterminé/osef, mais apparemment, c'est pas le cas si je comprends bien: tu émules ici une machine de turing avec une seule tête de lecture.*
Après, si tu comptes les faire en jeuweb, je ne pense pas que tu puisses créer un fichier de 2To sur le disque du joueur x)
Faire des sous-fichiers/sous-dossiers, je pense que ce n'est pas une bonne idée, vu que tu as dit qu'il y aurait des milliards de bits dans ton automate. Ca va encombrer inutilement les choses, sans améliorer les perfs (par rapport à un seul fichier d'un bloc dans lequel tu accèdes au N-eme bit directement, ou au 2xNeme bit si jamais tu veux faire du ternaire). Mais forcément, ca demandera aux joueurs d'accepter qu'un jeu du genre prenne 2To sur leur disque x)
* Ceci est à matériel constant: entre un accès disque au N-eme bit, ou un accès par adressage 64bits dans la RAM, la RAM sera très probablement plus rapide, même si'lo faut checker 10.000 adresses (mais là, faudrait savoir si vraiment tu as 1/100k-eme des bits actifs, ou si c'est juste du "je pense qu'au feeling ça sera ça"