Peut-être que c'est possible de faire un codage n parmi m. En gros, tu prends toute les séquences de 5 nucléotides (soit 45) et tu interdis toutes les séquences problématiques (il reste par exemple 35 possibilité).
Il aurait du surtout faire une mise en trame de donné comme pour les transmissions hertzienne avec une notion de trame de taille fixe avec des patterns fixes qui se répètent et cassent ces séquences de GC.
Taille du fichier de sortie : 4.9 Go
Vidéo : VP8 720x480 NTSC 30i/s 2Go
Audio0 : FLAC 48KHz 2ch 900Mo
Audio1 : FLAC 48KHz 6ch 2Go
Cela ne vous choque pas d'avoir plus d'information de son que de vidéo ? A ce niveau là, il faudrait voir la codage mp3 330kbits ou ogg à 256 kbits. Il faut juste un support correct du 5.1.
Dans ton code objet, le fetcher du cpu, le bloc qui va chercher les instructions a executer va tomber sur un
JUMP 0X012345678
Cette instruction peut être conditionnel, or la condition n'est pas calculer. Il doit choisir si il va chercher l'adresse PC+4 comme d'habitude (sur un risc 32 bits) ou 0x012345678.
Savoir si la clause du if qui est exécuté dépend de la forme du code assembleur choisi par le compilateur. J'aurais tendance à dire que dans un if qui a 2 clause, la clause vrai sera privilégié, mais si il n'y a qu'une clause, elle sera sauté.
Je serais curieux de savoir si cela change quelques choses d'utiliser un tableau de taille 5 pour éviter d'avoir uns structure. Souvent les structures sont alignés en mémoire sur la taille du plus grand type C, qui peut être 16 bits ici. Ce n'est en général pas le cas des tableaux simples.
Les instructions de saut typique contiennent l'adresse de saut. Il faut savoir si le saut est effectué ou pas avant la fin de l’exécution de "quelques instructions" dans le pipeline.
Le niveau le plus basique est : "forward not taken, backward taken". En gros, si l'adresse est en avant du PC, le saut n'est pas pris (cas d'un if qui est vrai), si le saut est en arrière, il est pris (cas d'une boucle).
Dans les faits, cette prédiction n'est pas si mauvaise que ça.
Le niveau suivant utilise une machine d'état à 4 états : strong taken - taken - not taken - strongly not taken. Le saut effectué ou pas fait changer d'état cette machine d'état. Il existe des cpu qui ont une seul de ces machines, pour aller plus loin que la prédiction statique. Les cpu moderne disposent de ces 2 bits d'information pour quelques centaines d'adresses d'instruction de saut.
Seul les cpus de la génération du core 2 et suivant possèdent une gestion des sauts indirects, avec sauvegarde de l'adresse de saut dans le buffer (comme les tableaux de fonction ou les vtable).
L'overhead des fonctions inline est en général dû à l'absence du mot clef "static". Sans ce mot, le symbol doit être visible de l'extérieur du .o et ainsi en plus des copies de la fonction en ligne, une fonction "normal" existe.
Gcc demande juste "static", "static inline" n'est plus nécessaire.
Le vertical est pratique uniquement parce que la résolution des écrans a diminué en hauteur. Le top des écran était le 1600*1200 en 2000. Aujourd'hui trouver un écran ayant 1200 pixel de haut est rare. J'ai encore un vieux 19" qui semble avoir une résolution grossière à coté d'un portable HD, mais qui propose autant de pixel que lui en hauteur 1024 (x1280).
Cela devient ridicule quand est-ce que les écrans 24" 4k vont sortir ? Ou au moins les écran ayant exactement 4x la résolution du 720p(2500x1440 ?), c'est déjà un bon début.
"L’optimisation en vitesse est généralement incompatible avec l’optimisation en taille."
Souvent mais pas toujours. L'inline est un bon exemple. En général, il est vu comme une augmentation de la taille du code. Dans un driver qui manipulait beaucoup de constantes, j'ai pu gagner beaucoup de place de code avec de l'inlining qui se simplifiait beaucoup (élimination de constante, etc…).
Dans tous les cas, chaque fois que je me documente sur le choix des types, le conseil est "utilisez le plus petit type possible".
Le compilo va prendre le plus rapide qui est en général la taille des registres.
Pas GCC 3.3.5. J'avais fait un travail d'optimisation sur un programme, l'inversion manuel des boucles apportaient un joli gain (mais ça date). Dans tous les cas, ça ne coûte rien de le faire soit même.
si des bugs, car c'est moins lisible. Parfois, le compilateur ne peut pas faire la transformation à cause de condition extérieur au fichier C ou à cause d'une variable d'induction.
La documentation du micro-contrôleur apporte ce genre d'info.
j'imagine. Mais dans le cas que j'avais en tête cela n'y était pas.
Si tu parles de variable automatique, en déclarant un char, un short ou un int, le compilateur te collera un int (16 ou 32 bit selon la plateforme), en tout cas sur tous les compilos que j'ai vu.
Concernant le retournement de compteur de boucle, il me semble que gcc fait ce genre de transformation dans toutes les boucles car la comparaison à zéro est toujours plus facile.
Concernant le switch-case, j'aime beaucoup l'utiliser mais il utilise un tas de pointeur de fonction, ce qui peut être très lent sur les cpu "simples".
Enfin, le plus simple est toujours de regarder la sortie assembleur pour voir ce que sort le compilateur.
"réfléchir dix fois avant de déclarer une variable "
Euh ?! Ton compilateur ne fait pas le boulot ?
Pour compacter à mort du code, le plus efficace que j'ai trouvé est l'inlining et le mot clef "static" (suivi des simplifications du compilo) pour éviter les .o où la moitié du code n'est pas utilisé et une fonctionnalité de récupération de fin de fonction par le compilateur. Je ne me rappelle plus le nom, mais en gros, si 2 fonctions se finissent de façon identique, l'une d'elle contient un goto vers la fin de la suivante. Cela permet de faire des choses, que la factorisation de code ne permet pas.
Pour ce genre de jeu, il ne serait pas plus joli et moins couteux en temps, de générer une carte en 3D plutôt que d'utiliser des tiles ou des modèles tout fait ?
L'avantage des modèles générés est le coté carré et répétitif qui disparait, ainsi que la variété du graphisme. Il est sans doute possible de trouver un modèle de 3D généré qui est aussi modulaire que ce que fait Minecraft, non ? (en plus, cela serait plus facile de coder les tremblement de terre, ras de marré, tsunami et autre dévastation de la nature)
J'imagine un rts style pierre/papier/ciseau (hélicoptère/char/infanterie) avec juste une notion d'amélioration de chacun des éléments quand il s'affronte entre eux et une grosse pris en compte de la map : ralentissement dans la terre pour garder le coté stratégique des routes, augmentation de la porté et de la vision sur les points haut, effet de la météo sur la vitesse de déplacement, difficulté pour déterminer le coté ami/ennemi des troupes (tir fratricide qui est un vrai problème irl), changer aussi la vision avec la nuit (genre alternance toutes les 5 minutes pendant le jeu). On pourrait ainsi réellement tirer parti du terrain. Il manque aussi la gestion des lignes de ravitaillement.
J'imagine bien le thème comme l'affrontement de compagnie pétrolière pour le contrôle de champ pétrolier, avec des objectifs de livraison à la maison mère qui engendre des hausses de budget et donc des livraisons de matériels militaires. Cela permet de remplacer les Fremen par des vrais civiles :)
Le pire étant la formation genre gros char devant, lance-missile derrière qui tire loin mais sont fragiles. En formation, il roule au moins à la même vitesse, sinon les chars se font dépassé et les camions sont détruit. Au premier obstacle ou rétrécissement(pont), les chars s'engagent et le superbe algo A* (à la con) décide de faire faire le tour aux camions de derrière. Et paf, le camion.
Le joueur qui gagne est donc celui qui clic le plus vite.
Il fallait définir une zone plus grande. C'est vrai que dans TA j'utilisais surtout le mode "tir à vue" sans déplacement. Car en cas de déplacement, l'unité se mettait à porter de tir de beaucoup d'unité adverse et était rapidement détruite.
[^] # Re: En corrèze
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un Ipad dans la liste des fournitures scolaires. Évalué à 3.
Je ne suis pas sûr que cela soit une économie géniale, vu comment sont gérés les achats dans le publique.
"La première sécurité est la liberté"
[^] # Re: En corrèze
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un Ipad dans la liste des fournitures scolaires. Évalué à 0.
C'est aussi une histoire de poule d'oeuf. Jamais les éditeurs ne feront d'application pour tablette si il n'y a pas un marché derrière.
"La première sécurité est la liberté"
[^] # Re: Encodage
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Téra-octet, cette unité bientôt démodée.... Évalué à 2.
Peut-être que c'est possible de faire un codage n parmi m. En gros, tu prends toute les séquences de 5 nucléotides (soit 45) et tu interdis toutes les séquences problématiques (il reste par exemple 35 possibilité).
"La première sécurité est la liberté"
[^] # Re: Encodage
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Téra-octet, cette unité bientôt démodée.... Évalué à 4.
Il aurait du surtout faire une mise en trame de donné comme pour les transmissions hertzienne avec une notion de trame de taille fixe avec des patterns fixes qui se répètent et cassent ces séquences de GC.
"La première sécurité est la liberté"
[^] # Re: Petite conclusion
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une autre structure pour la diffusion des films / appel à contribution.. Évalué à 2.
Cela ne vous choque pas d'avoir plus d'information de son que de vidéo ? A ce niveau là, il faudrait voir la codage mp3 330kbits ou ogg à 256 kbits. Il faut juste un support correct du 5.1.
"La première sécurité est la liberté"
[^] # Re: Gestion des paramètres
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
Dans ton code objet, le fetcher du cpu, le bloc qui va chercher les instructions a executer va tomber sur un
JUMP 0X012345678
Cette instruction peut être conditionnel, or la condition n'est pas calculer. Il doit choisir si il va chercher l'adresse PC+4 comme d'habitude (sur un risc 32 bits) ou 0x012345678.
Savoir si la clause du if qui est exécuté dépend de la forme du code assembleur choisi par le compilateur. J'aurais tendance à dire que dans un if qui a 2 clause, la clause vrai sera privilégié, mais si il n'y a qu'une clause, elle sera sauté.
"La première sécurité est la liberté"
[^] # Re: compteur ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
Je serais curieux de savoir si cela change quelques choses d'utiliser un tableau de taille 5 pour éviter d'avoir uns structure. Souvent les structures sont alignés en mémoire sur la taille du plus grand type C, qui peut être 16 bits ici. Ce n'est en général pas le cas des tableaux simples.
"La première sécurité est la liberté"
[^] # Re: Gestion des paramètres
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 3.
Il existe plusieurs niveau de complexité.
Les instructions de saut typique contiennent l'adresse de saut. Il faut savoir si le saut est effectué ou pas avant la fin de l’exécution de "quelques instructions" dans le pipeline.
Le niveau le plus basique est : "forward not taken, backward taken". En gros, si l'adresse est en avant du PC, le saut n'est pas pris (cas d'un if qui est vrai), si le saut est en arrière, il est pris (cas d'une boucle).
Dans les faits, cette prédiction n'est pas si mauvaise que ça.
Le niveau suivant utilise une machine d'état à 4 états : strong taken - taken - not taken - strongly not taken. Le saut effectué ou pas fait changer d'état cette machine d'état. Il existe des cpu qui ont une seul de ces machines, pour aller plus loin que la prédiction statique. Les cpu moderne disposent de ces 2 bits d'information pour quelques centaines d'adresses d'instruction de saut.
Seul les cpus de la génération du core 2 et suivant possèdent une gestion des sauts indirects, avec sauvegarde de l'adresse de saut dans le buffer (comme les tableaux de fonction ou les vtable).
"La première sécurité est la liberté"
[^] # Re: static ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
L'overhead des fonctions inline est en général dû à l'absence du mot clef "static". Sans ce mot, le symbol doit être visible de l'extérieur du .o et ainsi en plus des copies de la fonction en ligne, une fonction "normal" existe.
Gcc demande juste "static", "static inline" n'est plus nécessaire.
"La première sécurité est la liberté"
[^] # Re: static ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
les fonctions static font la même chose que les macros mais en plus propre (si le compilateur n'est pas moisi).
"La première sécurité est la liberté"
# static ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
Est-ce que ce genre de code est mis dans un .h ou dans son .c à part ?
Si la bibliothèque est souvent utilisé, du code "static" (ou static inline) peut être très compact, si mis dans le .h.
"La première sécurité est la liberté"
# compteur ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Parlons C, parlons pipe !. Évalué à 10. Dernière modification le 21 août 2012 à 14:33.
C'est pas plus simple d'utiliser un tableau d'octet et un compteur de début et de fin ? Comme un buffer tournant ?
"La première sécurité est la liberté"
[^] # Re: Я не понимаю
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Logiciel libre, sexisme et féminisme. Évalué à -2.
Pourquoi reprocher ta méconnaissance de l'anglais à linuxfr ?
"La première sécurité est la liberté"
[^] # Re: 2 écrans, trois fonctions
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage La disposition multi-écrans idéale. Évalué à 6.
Le vertical est pratique uniquement parce que la résolution des écrans a diminué en hauteur. Le top des écran était le 1600*1200 en 2000. Aujourd'hui trouver un écran ayant 1200 pixel de haut est rare. J'ai encore un vieux 19" qui semble avoir une résolution grossière à coté d'un portable HD, mais qui propose autant de pixel que lui en hauteur 1024 (x1280).
Cela devient ridicule quand est-ce que les écrans 24" 4k vont sortir ? Ou au moins les écran ayant exactement 4x la résolution du 720p(2500x1440 ?), c'est déjà un bon début.
L'ipad a déjà une grosse résolution.
"La première sécurité est la liberté"
[^] # Re: Moi aussi!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 2.
"L’optimisation en vitesse est généralement incompatible avec l’optimisation en taille."
Souvent mais pas toujours. L'inline est un bon exemple. En général, il est vu comme une augmentation de la taille du code. Dans un driver qui manipulait beaucoup de constantes, j'ai pu gagner beaucoup de place de code avec de l'inlining qui se simplifiait beaucoup (élimination de constante, etc…).
"La première sécurité est la liberté"
[^] # Re: Moi aussi!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 2.
Dans tous les cas, chaque fois que je me documente sur le choix des types, le conseil est "utilisez le plus petit type possible".
Le compilo va prendre le plus rapide qui est en général la taille des registres.
Pas GCC 3.3.5. J'avais fait un travail d'optimisation sur un programme, l'inversion manuel des boucles apportaient un joli gain (mais ça date). Dans tous les cas, ça ne coûte rien de le faire soit même.
si des bugs, car c'est moins lisible. Parfois, le compilateur ne peut pas faire la transformation à cause de condition extérieur au fichier C ou à cause d'une variable d'induction.
La documentation du micro-contrôleur apporte ce genre d'info.
j'imagine. Mais dans le cas que j'avais en tête cela n'y était pas.
"La première sécurité est la liberté"
[^] # Re: Moi aussi!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 2.
Si tu parles de variable automatique, en déclarant un char, un short ou un int, le compilateur te collera un int (16 ou 32 bit selon la plateforme), en tout cas sur tous les compilos que j'ai vu.
Concernant le retournement de compteur de boucle, il me semble que gcc fait ce genre de transformation dans toutes les boucles car la comparaison à zéro est toujours plus facile.
Concernant le switch-case, j'aime beaucoup l'utiliser mais il utilise un tas de pointeur de fonction, ce qui peut être très lent sur les cpu "simples".
Enfin, le plus simple est toujours de regarder la sortie assembleur pour voir ce que sort le compilateur.
"La première sécurité est la liberté"
[^] # Re: Moi aussi!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 1.
"réfléchir dix fois avant de déclarer une variable "
Euh ?! Ton compilateur ne fait pas le boulot ?
Pour compacter à mort du code, le plus efficace que j'ai trouvé est l'inlining et le mot clef "static" (suivi des simplifications du compilo) pour éviter les .o où la moitié du code n'est pas utilisé et une fonctionnalité de récupération de fin de fonction par le compilateur. Je ne me rappelle plus le nom, mais en gros, si 2 fonctions se finissent de façon identique, l'une d'elle contient un goto vers la fin de la suivante. Cela permet de faire des choses, que la factorisation de code ne permet pas.
"La première sécurité est la liberté"
# graphisme
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Webcrise: ébauche d'architecture. Évalué à 2.
Pour ce genre de jeu, il ne serait pas plus joli et moins couteux en temps, de générer une carte en 3D plutôt que d'utiliser des tiles ou des modèles tout fait ?
L'avantage des modèles générés est le coté carré et répétitif qui disparait, ainsi que la variété du graphisme. Il est sans doute possible de trouver un modèle de 3D généré qui est aussi modulaire que ce que fait Minecraft, non ? (en plus, cela serait plus facile de coder les tremblement de terre, ras de marré, tsunami et autre dévastation de la nature)
"La première sécurité est la liberté"
[^] # Re: Temps long
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Webcrise: ébauche d'architecture. Évalué à 3.
oui, je le sais bien et cela me gonfle :)
J'imagine un rts style pierre/papier/ciseau (hélicoptère/char/infanterie) avec juste une notion d'amélioration de chacun des éléments quand il s'affronte entre eux et une grosse pris en compte de la map : ralentissement dans la terre pour garder le coté stratégique des routes, augmentation de la porté et de la vision sur les points haut, effet de la météo sur la vitesse de déplacement, difficulté pour déterminer le coté ami/ennemi des troupes (tir fratricide qui est un vrai problème irl), changer aussi la vision avec la nuit (genre alternance toutes les 5 minutes pendant le jeu). On pourrait ainsi réellement tirer parti du terrain. Il manque aussi la gestion des lignes de ravitaillement.
J'imagine bien le thème comme l'affrontement de compagnie pétrolière pour le contrôle de champ pétrolier, avec des objectifs de livraison à la maison mère qui engendre des hausses de budget et donc des livraisons de matériels militaires. Cela permet de remplacer les Fremen par des vrais civiles :)
"La première sécurité est la liberté"
[^] # Re: Temps long
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Webcrise: ébauche d'architecture. Évalué à 1.
"C'est un aspect qui est encore flou dans ma tête: quel sera exactement le rôle des joueurs et les interactions possibles?"
C'est pourtant le plus important, le gameplay.
"La première sécurité est la liberté"
[^] # Re: Temps long
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Webcrise: ébauche d'architecture. Évalué à 2.
Le pire étant la formation genre gros char devant, lance-missile derrière qui tire loin mais sont fragiles. En formation, il roule au moins à la même vitesse, sinon les chars se font dépassé et les camions sont détruit. Au premier obstacle ou rétrécissement(pont), les chars s'engagent et le superbe algo A* (à la con) décide de faire faire le tour aux camions de derrière. Et paf, le camion.
Le joueur qui gagne est donc celui qui clic le plus vite.
"La première sécurité est la liberté"
[^] # Re: procédure biaisée
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Est ce que LibreOffice ne respecte pas les standards ODF ?. Évalué à 9.
Tu me rappelles quelle version de la norme implémente word ? Ou quel logiciel suit la norme corrigé en question ?
"La première sécurité est la liberté"
[^] # Re: je ne vois que le texte alternatif
Posté par Nicolas Boulay (site web personnel) . En réponse à l’entrée du suivi insertion d'image malformé. Évalué à 2 (+0/-0).
En fait, il faut accepter le certificat de https//img.linuxfr.org
"La première sécurité est la liberté"
[^] # Re: Temps long
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Webcrise: ébauche d'architecture. Évalué à 2.
Il fallait définir une zone plus grande. C'est vrai que dans TA j'utilisais surtout le mode "tir à vue" sans déplacement. Car en cas de déplacement, l'unité se mettait à porter de tir de beaucoup d'unité adverse et était rapidement détruite.
"La première sécurité est la liberté"