pepp a écrit 82 commentaires

Il doit mal expliquer mais en fait, c'est exactement ce qu'il fait : comparer comment stocker les entités. Avec deux variantes : "struct of array" et "array of struct".

Oui. Mais ce que je voulais souligner c'est que la difficulté est dans "comment les stocker efficacement, sachant que toutes les entités n'ont pas nécessairement tous les composants".

Il serait probablement plus pertinent de commenter tous les appels à SDL_* pour benchmarker l'effet du layout mémoire.
(sinon sur ma machine, une large majorité du temps est consommé par la stack graphique).

Comme profiler pour ce genre de cas, je te conseille perf, par ex:

perf record -e cycles,cache-misses,stalled-cycles-frontend,branch-misses ./superpaflaballe
perf report

Ça permet de voir assez finement les effets des choix d'organisation de la mémoire.

Dernier point, ton benchmark étant simple, il omet une des difficultés (à mon goût) des E/S : comment stocker de manière efficaces des composants pour N entités sachant que les entités n'ont pas toutes les mêmes composants.

(dans mon cas j'ai choisis après divers test : une entité représente un index, et les composants sont stockés dans des std::vector. Ça permet d'améliorer l'utilisation du cache pour l'opération la plus couteuse : la maj des systèmes)

Apparemment c'est également le choix d'Apple avec son logiciel «Pages». Ça ressemble à du Word simplifié au maximum pour ne garder que les fonctionnalités principales (et donc pas besoin de 100M€ ou 30 ans pour le développer). Quelqu'un ici l'a testé ?

Ça fait déjà une belle somme - mais effectivement probablement insuffisant pour corriger tous vos problèmes.
Sans compter le coût de la formation pour accompagner une transition Office -> LibreOffice.

N'empêche, si plusieurs communes se regroupaient pour financer de manière la plus directe possible (sans 4 étages de management par ex) 1 ou 2 développeurs pour corriger les bugs les plus gênants rencontrés dans leur usage*, il serait possible d'obtenir des résultats intéressants…

(*: j'entends par là : si ça marchait avant avec Office, ça doit marcher avec LibreOffice)

devoir payer ma dime à Microsof
Pourquoi ce vocabulaire péjoratif ? Autant pour le cas de la vente liée le rapprochement avec un impôt forcé est approprié, autant dans ce cas là ton choix est volontaire : Microsoft fait apparemment un meilleur produit pour ton usage.

Vocabulaire mis à part, est-ce qu'on peut savoir quel genre de budget ça représente ?
Ça m'intéresserait de le comparer aux coûts de la correction des problèmes les plus génants pour vous dans LibreOffice (en sous-traitant le développement par ex).

Enfin ce code est issu de "id Tech 3" qui d'après Wikipedia date de fin 1999.
Depuis les compilateurs/processeurs se sont peut-être suffisamment améliorés pour rendre obsolète ce genre d'astuce.

Pour moi ce code est peut-être au choix:
- une solution élégante à un problème rencontré par les développeurs à l'époque : mise en oeuvre d'une approximation mathématique, plus rapide et dispo sur toutes les plateformes tout en s'assurant que ses défauts n'étaient pas gênants pour le domaine concerné.
- ou l'exemple typique de chose à ne pas faire (si c'était juste pour le fun).

On ne doit pas avoir la même lecture en effet :-)

Pour rejoindre le thread plus bas, je n'ai jamais lu :

Si ça bouge, alors on le met dans un composant, sinon c'est une donnée statique […] Par définition des composants.

Mais bon, tant mieux si ça fonctionne pour toi comme ça - mes questions étaient surtout destinés à voir si tes réponses allaient me faire changer ma manière de faire. Pour l'instant je ne suis pas convaincu, donc je reste sur mon plan : tout est entité (même le fond de carte :p)

Je veux bien des liens vers ces autres, histoire de comprendre leur démarche.
De mon côté l'inspiration principale c'est cette série d'articles.

Bon ok, on ne voit pas du tout les choses sous le même angle.
Mon point de vue (éprouvé sur quelques jeux finis, c'est pas uniquement de la théorie) : tout est entité. Oui le fond de carte est une entité, les éléments de l'interface, etc. Et charge au code qui crée ces entités de spécifier s'il désire les voire sauvegardée ou s'il les recréera tout seul.
De ton côté si j'ai bien saisi, l'importance c'est d'avoir une sauvegarde/chargement facile.

De là à affirmer que "tu penses correctement" (ce qui sous-entend quand même que moi non) et que "tu ne déroges pas du paradigme" (avec le même sous-entendu) me semble quand même un brin culotté - j'attendrai de pouvoir ton jeu (fini) pour voir si tu as raison.

Donc si j'ai bien compris, ces questions de statique/dynamique/config/entité/etc te bloque au niveau architecture :

c'est assez complexe. […] Qu'est-ce qui relève de l'état du jeu, qu'est-ce qui relève de données statiques

Supprimer cette séparation arbitraire (statique = config, dynamique = entité) te faciliterait la vie selon moi, mais apparemment tu y tiens pour la sauvegarde.

Du coup, je vais poser une question plus directe sans suggestion de réponse pour te laisser élaborer : quel est le problème que tu essayes de résoudre par rapport à la sauvegarde ?

Il s'agit simplement de mieux modéliser ton application et de mieux comprendre les interactions entre les différentes parties. Si tu comprends mieux ce que tu fais, tu mieux utiliser des paradigmes plus fins et donc plus optimisés.

Tu ne réponds pas à ma question. Je me doute bien que tu le fais pour une raison, mais je ne comprends pas laquelle.

Tu peux. Mais ce n'est sans doute pas la meilleure façon de faire, à mon avis.

Un brin affirmatif comme réponse. Je trouve au contraire qu'un fichier texte c'est un compromis intéressant : plus souple qu'avec du code/binaire mais un peu moins rapide.

Ton entité pour le fond de carte, elle ne te sert à rien

Elle sert à afficher la carte. Ça parait déjà pas mal.
Ensuite je pense que les problématiques de sauvegarde sont secondaires : quelle est le problème de sauvegarder une entité statique ? Si c'est la taille du fichier de sauvegarde, n'importe quel algo de compression te ferait gagner beaucoup.
Et justement non, utiliser une entité pour afficher le fond de carte ne crée pas d'exception : tout ce qui est visible est une entité avec un composant Affichage.

ça a du sens du point de vue de l'application globale et d'un jeu en particulier.

Je veux bien savoir lequel ?

«est-ce que tu vas devoir sauvegarder la masse parce qu'elle change pour chaque entité ou est-ce que l'information de masse va venir d'un fichier de config pour toutes les entités ?»

Ben, tu peux aussi définir tes entités dans un fichier texte - c'est comme un fichier de config sauf que tu n'as pas de cas particulier : un composant = toutes les données nécessaires au système.

C'est ce que je fais aussi, mais par exemple, mettre tous les tuiles du fond de cartes dans des composants, c'est con. Outre le fait que c'est sous-optimal pour plein de raisons, ça n'a rien à faire là. Et pourtant, le système qui gère l'affichage, il mange des composants avec des sprites donc il pourrait manger des tuiles.

Vu d'ici je dirais :
* une entité avec un composant d'affichage pour afficher le fond de cartes
* N entités avec les composants de gameplay pour les tuiles qui en ont besoin (et en option un composant d'affichage)

Je ne comprends pas trop pourquoi tu t'embêtes à essayer de séparer arbitrairement ce qui est statique du reste. Le fait que la masse ne change pas n'est pas lié au fait que la propriété 'masse' appartienne au composant 'physique'.
La logique que j'utilise pour mes composants c'est simplement d'y mettre toutes les entrées/sorties d'un système - au moins on voit clairement ce que manipule un système. J'y stocke aussi les états intermédiaires quand ils sont nécessaires au fonctionnement du système (par ex, le temps écoulé pour un système qui gère du morphing).
Ensuite pour la sauvegarde/restauration, ne sont sauvées que les variables d'entrées/sorties (les autres pouvant être recalculées).

Les commentaires LWN indiquent certes que les patchs ont été mergé il y a une semaine, mais aussi que cet exploit (la version publiée en tout cas) ne fonctionnait pas sur un noyau grsecurity.

cf :

spender integrated the fix to grsecurity 3.14.x and 3.2.x more than a week ago.

et la réponse :

Not only that, but at least four separate features of grsecurity […] prevent successful exploitation using the public exploit above.

Salut,

Si besoin je peux vous fournir plus d'infos si vous avez un email.

Ça pourrait m'intéresser, eo6lshga0l31gkl@jetable.org

Merci :-)

Le blog de Jan Hubička (dév GCC) a des articles détaillés sur GCC, notammement le LTO.

(et une petite faute à corriger : "les éventuelles bugs")

Dans un jeu vidéo, une telle resynchronisation nuit souvent à l'immersion (syndrome du joueur téléporter à cause d'un pic de latence), et on laisse donc au client une certaine marche de manoeuvre, le serveur acceptera, jusqu'à une certaine mesure, la position d'un client même si elle est différente de celle qu'il a lui même calculé.

Ou autre solution : on laisse faire au client ce qu'il veut en local (donc l'affichage est instantané chez le joueur), et le serveur vérifie a posteriori les actions.
Et on utilise des effets graphiques (animations, fumées, etc) pour masquer cette latence.

Cette page sur le wiki de Valve explique bien les problèmes et les solutions mises en oeuvre.

Les jeux proprios essayent aussi beaucoup de business model : shareware, demo/jeu complet, jeux à abonnements, free to play, pubs, DLC, etc

Et rencontrent les mêmes difficultés pour viabiliser leurs prodruits.
L'offre en jeux vidéo est très importante (tant mieux), il n'est donc pas très étonnant qu'il soit difficile de se faire une place au soleil.

L'aspect libre ne change pas grand chose à mon avis. Proprio ou pas ce qui compte c'est la qualité.

Par exemple, si vous faites un jeu de plateforme (libre ou non), on peut choisir Braid ou Super Meat Boy comme point de référence. Si votre jeu est moins bien, il a peu de chance de réussir quelque soit le business model (encore une fois ce n'est que mon avis, mais on peut l'illustrer par exemple avec Ethan Meteor Hunter)

D'après git blame:
* tty-ask-password-agent.c
- auteur principal: Lennart Poettering
- fin 2010/début 2011

Pour le code que j'ai cité ci dessus umount.c:
- auteur principal: Lennart Poettering
- 2010 -> 2013

Les commentaires semblent venir de modifications récentes.

On dirait que le code est écrit sans (trop de) commentaire au départ, par contre quand des modifications sont faites, pour un bugfix ou un cas particulier non prévu au départ, un commentaire précise pourquoi.

J'ai fini par cloner le dépot systemd pour avoir d'autres exemples de sources à lire.

Du coup pour la variable "r" la réponse est simple : ils utilisent "int r" dans toutes les fonctions. Alors certes c'est moins expressif que int return_value; mais c'est cohérent sur l'ensemble du projet.

Sur le couplet "y a pas de commentaires cay pourri". On peut aussi trouver du code largement commenté dans systemd, par ex :

 static int mount_points_list_umount(MountPoint **head, bool *changed, bool log_error) {
        MountPoint *m, *n;
        int n_failed = 0;

        assert(head);

        LIST_FOREACH_SAFE(mount_point, m, n, *head) {

                /* If we are in a container, don't attempt to
                   read-only mount anything as that brings no real
                   benefits, but might confuse the host, as we remount
                   the superblock here, not the bind mound. */
                if (detect_container(NULL) <= 0)  {
                        /* We always try to remount directories
                         * read-only first, before we go on and umount
                         * them.
                         *
                         * Mount points can be stacked. If a mount
                         * point is stacked below / or /usr, we
                         * cannot umount or remount it directly,
                         * since there is no way to refer to the
                         * underlying mount. There's nothing we can do
                         * about it for the general case, but we can
                         * do something about it if it is aliased
                         * somehwere else via a bind mount. If we
                         * explicitly remount the super block of that
                         * alias read-only we hence should be
                         * relatively safe regarding keeping the fs we
                         * can otherwise not see dirty. */
                        mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, NULL);
                }

                /* Skip / and /usr since we cannot unmount that
                 * anyway, since we are running from it. They have
                 * already been remounted ro. */
                if (path_equal(m->path, "/")
#ifndef HAVE_SPLIT_USR
                    || path_equal(m->path, "/usr")
#endif
                )
                        continue;

                /* Trying to umount. We don't force here since we rely
                 * on busy NFS and FUSE file systems to return EBUSY
                 * until we closed everything on top of them. */
                log_info("Unmounting %s.", m->path);
                if (umount2(m->path, 0) == 0) {
                        if (changed)
                                *changed = true;

                        mount_point_free(head, m);
                } else if (log_error) {
                        log_warning("Could not unmount %s: %m", m->path);
                        n_failed++;
                }
        }

        return n_failed;
}

(arf, bien sûr la fonction que je cite n'utilise par 'int r' :) )
En tout cas, ils ne sont pas opposés aux commentaires par principe (ou pour justifier de facturer du support).

Enfin le style général est également cohérent (accolades, alignements, assert, etc).

Dernière chose, que je trouve bien plus importante que les commentaires dans le code d'ailleurs, les messages de commits ont l'air complets et utiles.

Si vous considérez cette codebase comme crade, je veux bien un exemple d'un projet (sérieux, pas un hello world de 15 lignes) propre.

Puisqu'apparemment il n'existe pas de juste milieu entre les dév flemmards qui ne savent pas coder proprement et les ayatollah du code propre et des design patterns ce n'est pas la peine de discuter.

C'est assez logique.

Tu opposes ton style de programmation, utilisés quand tu codes "des appli perso" et celui utilisés dans systemd ou des dév "pro" comme tu dis.
Mais les contraintes dans les 2 cas ne sont pas exactement les mêmes.
En l'occurence : aucune pour tes projets persos, là où les autres doivent faire des compromis : délais, qualité, sécurité, performance, nouvelles fonctionnalité, maintenabilité, etc etc.
C'est toujours facile de prendre du code d'un autre et de trouver matière à critiquer.

Moué, analogies foireuses.

Pour le cas du cuisinier, ça serait plutôt aller voir en cuisine, et dire : "je ne suis pas cuisinier, mais à votre place je ne ferais pas comme ça. Et puis vous devriez faire attention avec ce couteau pointu, vous risquez de vous couper."

Donc, tu n'est pas développeur C, mais ça ne t'empêches pas de prendre du code C au hasard et de le juger "bizarre", "douteux" ou "pas très propre".
Et aussi d'enseigner des bonnes pratiques à tes étudiants.

Perso, le code ci-dessus ne me dérange pas - même si je ne l'aurais pas écrit de cette manière.

Et ce code a un mérite : il existe et il fonctionne.

Oui pour un attaquant en brute force.

Mais 512 adresses posssibles + des infos leak (nombreux d'après Spender) qui donnent des indications : les chances de l'attaquant de trouver l'adresse réelle augmentent.

Pour résumer, peut-être que KASLR est utile, mais rejetter les arguments de Spender parce-qu-il-développe-grsecurity-et-qu-il-aide-pas-upstream me parait un peu dommage.