Cela n'existe pas des petits chip graphique ? Dans le cas contraire, cela risque de manger beaucoup de cycle cpu. Sinon, il doit bien exister des fpga de quelques euros ou il est possible de faire des "blit" rapidement.
"Je dis ça, je déteste recopier sans comprendre, et du coup je le fais rarement, mais il manque parfois des bouts de démos dans mes cours ensuite :)"
Je déteste cette façon de faire cours. L'origine vient du fait de la 'mémoire de la main', qui permet de retenir pour certaine personne (mais pas toutes, chacun à sa methode : oral, visuel, de reformulation, écrite). Mais si le cours va tellement vite que l'on a même pas le temps de comprendre, c'est juste complètement idiot. Pourquoi le prof ne donne pas un polycopier, ce qui permet de suivre le cours et de tenter de comprendre pendant le cours.
"Ce que tu appelle du RT mou, ce n'est pas du RT. C'est une exécution sous contrainte de temps, mais ça n'a rien à voir avec une quelconque garantie."
Et pourtant si tu ne respectes pas tes 30 images/s ton film est illisible, idem pour le son. Pour un jeu, si le temps de réaction est au dessus d'une certaine valeur, c'est injouable. C'est ça le TR mou.
"Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision."
Oui et on s'en contre-fou. On détermine un ou une série de path d'execution long, on prends 50% de marge et c'est bon (avec cache froid, sans appel système, ni lock). Dans la vrai vie.
gcc -MM c'est pas mal. Mais globalement, make, c'est pas top. cmake semble avoir la faveur de beaucoup de monde. si tu as un petit projet, tout recompiler ne prend en général pas trop de temps, non plus.
" Le TR, c'est garantir qu'une opération peut être effectuée en un nombre de cycle déterminé"
N'importe quoi.
Le TR c'est garantir un temps d’exécution borné (réagir en moins de 100ms max, exécuter une fonction cycle en 20ms max). Tes histoires d'instructions qui mettent plus ou moins de temps, on s'en tape complètement, ce temps max est borné. Il suffit d'en tenir compte. En TR dure, ils ont peur des caches write back, mais bon… ils ont une bonne quantité de marge.
Les jeu vidéo, les lecteurs multimédias sont des TR mou et c'est finalement plus dure à faire. Un TR dure qui franchi sa limite, plante, un TR mou doit faire quelques choses d'intelligent (frame drop, freeze, …).
"Je parlais de make. Make ne sait pas ce qu'est un fichier C++. Il sait simplement qu'un .C va être compilé en .o"
C'est également n'importe quoi. make sait simplement qu'un fichier dépend d'autres fichiers, et dispose d'une commande shell pour recréer le fichier si une des dépendances est plus récente. Cela peut être les fichiers .c mais aussi .h.
"Mais je n'ai jamais réussi à le mettre en place de manière fiable."
Un jeu vidéo, c'est du temps réel. Il n'y a pas de vie en jeu, mais demande au joueur si il aime les lags.
"(le problème classique de make qui ne prend pas en compte les en-têtes, car il ne peut pas),"
Si il peut. (gcc -MM de tête) C'est juste très chiant, car en général, une simple modification peut entrainer une cascade de recompilation. En général, les .h ne sont pas inclus, les .c impactés étant aussi modifiés, cela ne se voit pas. En pratique, il faut parfois faire un "make clean".
Le top et le moins chère, c'est netbook récent pour l'autonomie et les nouveaux atom un peu plus rapide + un tablette genre Wacom ( https://www.materiel.net/tablette-graphique/ ).
La tablette pas graphique s'utilise comme une souris mais est bien plus précis. Pour le dessin, les tablettes d'entré de gamme sont un peu trop imprécise (phénomène de marche d'escalier sur un trait droit), c'est à tester j'imagine.
L'avantage c'est que c'est plus rapide. Le défaut, c'est que tu peux avoir des plantages mémoires, après l'allocation (si tu as un "overcommit" supérieur à 1 ou 100%)…
L'avantage aussi, c'est qu'un new ou malloc en plein milieu d'un code code "temps réel", c'est prendre un gros risque sur la latence (min : qq cycles, max 15 000 cycles). Le top, c'est tout de même de ne plus avoir d'allocation mémoire après un certain stade. Tu es à peu prés sûr que ton code ne peut plus planter pour des raisons externes.
Elle est alloué d'une certain façon, mais les pages physiques ne sont pas mappé à ce niveau là. Le système sait juste qu'en cas de fautes mémoires, il faut allouer physiquement les pages et non pas retourner un segfault.
Le COW, c'est en cas de fork, sur la gestion des segments de data, qui ne sont dupliquer qu'en cas de modification.
Pour moi, le seul moment ou tu as une classe, c'est que de façon statique et non dynamique, tu as un traitement global au niveau de la classe mère. Si il n'y a pas de traitement, il aurait fallu faire une inclusion.
Le cas typique, est l'usine d'image, capable d'ouvrir du png ou du jpeg, mais qui retourne toujours une "image".
Ben non justement, l'allocation mémoire est retardé sous linux. Linux n'alloue réellement la mémoire qu'au premier accès. Donc la mémoire n'est pas rééllement consommé au lancement.
Je rêve d'un système de tableur/wiki ou l'on puisse suivre tes calculs pour les vérifier et faire d'autres courbes avec, comme le taux d'imposition réel par exemple.
ça reste une assiette idiote. Le taux est linéaire, non progressif comme un vrai impôt, ni fixe comme une vrai assurance. Cela augmente les charges fixes des entreprises artificiellement, si c'est remplacer par une TVA, les cotisations sont payés si la boite vend. Si elle va mal, ses charges sont plus faible.
Un bon impôt a un taux faible, une assiette large et un cout d'opportunité faible (si on gagne +1, on ne doit pas avoir à payer les impôts locaux d'un coup).
Le principe même des logiciels libres est de démontrer que cela marche quand cela vient de la base et du volontariat, c'est l'inverse "d'une dictature de la majorité".
En gros, les sommes varies entre 500 et 1000€, un RMI ou un SMIC. Certain propose une mega TVA (100%), et une suppression totale des cotisations sociales du salaire.
Cela permet de réduire le SMIC. Cela permet de refuser les "bad job" (car on peut vivre avec le dividende). Cela rend le cout des salaires dans les couts d'une entreprise comme ridicule (imaginez les salaires superbrutes moins toutes les cotisations dans les couts de vos fournisseurs).
Le dividende est inclus dans l'IR, il y aussi une redistribution par ce canaux. Tout le monde le touche, un immigré pourrait le recevoir au prorata de son temps passé en France (avec un max à 10 ans ?). Mais bon, la vie serait très dur au début. Les enfants pourrait le toucher à proportion de l'age pour remplacer la CAF.
En gros, on évite la dépense monstrueuse en vérification dans tous les sens, on mutualise les couts des employés de toutes les entreprises. Seul celles qui marchent paye beaucoup d’impôt.
Pour la mise en place, il faudrait une augmentation progressive de TVA avec une diminution des cotisations sociales à 50/50 employeur/salarié, et le paiement du dividende (le smic diminuant aussi un peu ou reste gelé). Cela permet une arrivé du dividende en douceur, diminuer l'effet de l'augmentation de la TVA sur les bas salaires, et une diminution des cotisations sociales pour les employeurs.
Dans ce cas, utilises une variable global comme pour le C, avec un tableau de structure, elle sera alloué dans le BSS, et ne consommera pas de mémoire, si il n'y en a pas besoin.
Pour moi, la gestion d'interruption est quelques choses de lourds. Ici, il s'agit d'un getter, un truc très très sensible à la performance.
Souvent, dans le cas de try/catch, le compilateur ne fait pas d'inline, ce qui peut être finalement très couteux. Un simple test par rapport à la borne supérieur et à la nullité est suffisant, c'est souvent beaucoup plus efficace.
Non, c'est l’intérêt du componentAdress qui peut être aussi un simple tableau de short (max 65 000 objets, ce qui est pas mal). Cela permet d'éviter d'avoir trop de trou et de bénéficier du cache.
Est-ce que le fait de préallouer de la mémoire ne serait pas un bon moyen pour avoir l'allocation aligné ?
En gros, si fixe un max de N objects, chaque composant est allouer N fois, pour trouver le composant allouer est garder l'alignement mémoire, tu passes par une tables de pointeur.
Genre tu as :
C'est bourrin mais pour quelques milliers d'objet, cela ne consomme pas trop de mémoire, tout est aligné, et l'accès est bien plus rapide qu'avec une table de hash. En plus, Linux ne doit allouer la mémoire que si elle est écrite. Donc, le "haut" du composant pool n'est pas réellement allouer.
Dans l'absolue, si on se fout des perfs de lecture, on peut imaginer coller les writes dans l'ordre genre journal de transaction, sur un disque qui peut tenir 100 Mo/s, on arrive pas à faire mieux que 100 IO/s ? Si on groupe les writes, cela va plus vite j'imagine ?
[^] # Re: Le C++
Posté par Nicolas Boulay (site web personnel) . En réponse au journal C(++) ?. Évalué à 3.
C'est rare les langages qui ne permettent pas un binding vers une fonction C quand les performances sont nécessaires.
"La première sécurité est la liberté"
[^] # Re: Evite le C++
Posté par Nicolas Boulay (site web personnel) . En réponse au journal C(++) ?. Évalué à 2.
Pourquoi tu n'aimes pas le passage par référence ?
"La première sécurité est la liberté"
[^] # Re: presque portable :)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cortex M4 et console portable Bix Box. Évalué à 2.
Ou alors, il faut utiliser 2 puces, l'une ne servant que pour le drivers graphique(GPU).
"La première sécurité est la liberté"
[^] # Re: presque portable :)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cortex M4 et console portable Bix Box. Évalué à 2.
Cela n'existe pas des petits chip graphique ? Dans le cas contraire, cela risque de manger beaucoup de cycle cpu. Sinon, il doit bien exister des fpga de quelques euros ou il est possible de faire des "blit" rapidement.
"La première sécurité est la liberté"
[^] # Re: Apprends à prendre des notes !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal prise de note en cours. Évalué à 4.
"Je dis ça, je déteste recopier sans comprendre, et du coup je le fais rarement, mais il manque parfois des bouts de démos dans mes cours ensuite :)"
Je déteste cette façon de faire cours. L'origine vient du fait de la 'mémoire de la main', qui permet de retenir pour certaine personne (mais pas toutes, chacun à sa methode : oral, visuel, de reformulation, écrite). Mais si le cours va tellement vite que l'on a même pas le temps de comprendre, c'est juste complètement idiot. Pourquoi le prof ne donne pas un polycopier, ce qui permet de suivre le cours et de tenter de comprendre pendant le cours.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
"Ce que tu appelle du RT mou, ce n'est pas du RT. C'est une exécution sous contrainte de temps, mais ça n'a rien à voir avec une quelconque garantie."
Et pourtant si tu ne respectes pas tes 30 images/s ton film est illisible, idem pour le son. Pour un jeu, si le temps de réaction est au dessus d'une certaine valeur, c'est injouable. C'est ça le TR mou.
"Cela permet de calculer un temps statistique d'exécution, mais il ne pourra pas être garanti avec précision."
Oui et on s'en contre-fou. On détermine un ou une série de path d'execution long, on prends 50% de marge et c'est bon (avec cache froid, sans appel système, ni lock). Dans la vrai vie.
gcc -MM c'est pas mal. Mais globalement, make, c'est pas top. cmake semble avoir la faveur de beaucoup de monde. si tu as un petit projet, tout recompiler ne prend en général pas trop de temps, non plus.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
" Le TR, c'est garantir qu'une opération peut être effectuée en un nombre de cycle déterminé"
N'importe quoi.
Le TR c'est garantir un temps d’exécution borné (réagir en moins de 100ms max, exécuter une fonction cycle en 20ms max). Tes histoires d'instructions qui mettent plus ou moins de temps, on s'en tape complètement, ce temps max est borné. Il suffit d'en tenir compte. En TR dure, ils ont peur des caches write back, mais bon… ils ont une bonne quantité de marge.
Les jeu vidéo, les lecteurs multimédias sont des TR mou et c'est finalement plus dure à faire. Un TR dure qui franchi sa limite, plante, un TR mou doit faire quelques choses d'intelligent (frame drop, freeze, …).
"Je parlais de make. Make ne sait pas ce qu'est un fichier C++. Il sait simplement qu'un .C va être compilé en .o"
C'est également n'importe quoi. make sait simplement qu'un fichier dépend d'autres fichiers, et dispose d'une commande shell pour recréer le fichier si une des dépendances est plus récente. Cela peut être les fichiers .c mais aussi .h.
"Mais je n'ai jamais réussi à le mettre en place de manière fiable."
Et alors ?
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Un jeu vidéo, c'est du temps réel. Il n'y a pas de vie en jeu, mais demande au joueur si il aime les lags.
"(le problème classique de make qui ne prend pas en compte les en-têtes, car il ne peut pas),"
Si il peut. (gcc -MM de tête) C'est juste très chiant, car en général, une simple modification peut entrainer une cascade de recompilation. En général, les .h ne sont pas inclus, les .c impactés étant aussi modifiés, cela ne se voit pas. En pratique, il faut parfois faire un "make clean".
"La première sécurité est la liberté"
# netbook + tablette pas graphique.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal prise de note en cours. Évalué à 1.
Le top et le moins chère, c'est netbook récent pour l'autonomie et les nouveaux atom un peu plus rapide + un tablette genre Wacom ( https://www.materiel.net/tablette-graphique/ ).
La tablette pas graphique s'utilise comme une souris mais est bien plus précis. Pour le dessin, les tablettes d'entré de gamme sont un peu trop imprécise (phénomène de marche d'escalier sur un trait droit), c'est à tester j'imagine.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
L'avantage c'est que c'est plus rapide. Le défaut, c'est que tu peux avoir des plantages mémoires, après l'allocation (si tu as un "overcommit" supérieur à 1 ou 100%)…
L'avantage aussi, c'est qu'un new ou malloc en plein milieu d'un code code "temps réel", c'est prendre un gros risque sur la latence (min : qq cycles, max 15 000 cycles). Le top, c'est tout de même de ne plus avoir d'allocation mémoire après un certain stade. Tu es à peu prés sûr que ton code ne peut plus planter pour des raisons externes.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Elle est alloué d'une certain façon, mais les pages physiques ne sont pas mappé à ce niveau là. Le système sait juste qu'en cas de fautes mémoires, il faut allouer physiquement les pages et non pas retourner un segfault.
Le COW, c'est en cas de fork, sur la gestion des segments de data, qui ne sont dupliquer qu'en cas de modification.
"La première sécurité est la liberté"
[^] # Re: « préférer la composition à l’héritage »
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
Pour moi, le seul moment ou tu as une classe, c'est que de façon statique et non dynamique, tu as un traitement global au niveau de la classe mère. Si il n'y a pas de traitement, il aurait fallu faire une inclusion.
Le cas typique, est l'usine d'image, capable d'ouvrir du png ou du jpeg, mais qui retourne toujours une "image".
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Ben non justement, l'allocation mémoire est retardé sous linux. Linux n'alloue réellement la mémoire qu'au premier accès. Donc la mémoire n'est pas rééllement consommé au lancement.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Sauf si tout est dans le .h. Sur une application , j'avais triplé la vitesse.
"La première sécurité est la liberté"
[^] # Re: mignon
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 4.
Je rêve d'un système de tableur/wiki ou l'on puisse suivre tes calculs pour les vérifier et faire d'autres courbes avec, comme le taux d'imposition réel par exemple.
"La première sécurité est la liberté"
[^] # Re: mignon
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 3.
ça reste une assiette idiote. Le taux est linéaire, non progressif comme un vrai impôt, ni fixe comme une vrai assurance. Cela augmente les charges fixes des entreprises artificiellement, si c'est remplacer par une TVA, les cotisations sont payés si la boite vend. Si elle va mal, ses charges sont plus faible.
Un bon impôt a un taux faible, une assiette large et un cout d'opportunité faible (si on gagne +1, on ne doit pas avoir à payer les impôts locaux d'un coup).
"La première sécurité est la liberté"
[^] # Re: débat sur le revenu de base
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 4.
Le principe même des logiciels libres est de démontrer que cela marche quand cela vient de la base et du volontariat, c'est l'inverse "d'une dictature de la majorité".
"La première sécurité est la liberté"
[^] # Re: débat sur le revenu de base
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Initiative citoyenne pour le revenu de base. Évalué à 7.
En gros, les sommes varies entre 500 et 1000€, un RMI ou un SMIC. Certain propose une mega TVA (100%), et une suppression totale des cotisations sociales du salaire.
Cela permet de réduire le SMIC. Cela permet de refuser les "bad job" (car on peut vivre avec le dividende). Cela rend le cout des salaires dans les couts d'une entreprise comme ridicule (imaginez les salaires superbrutes moins toutes les cotisations dans les couts de vos fournisseurs).
Le dividende est inclus dans l'IR, il y aussi une redistribution par ce canaux. Tout le monde le touche, un immigré pourrait le recevoir au prorata de son temps passé en France (avec un max à 10 ans ?). Mais bon, la vie serait très dur au début. Les enfants pourrait le toucher à proportion de l'age pour remplacer la CAF.
En gros, on évite la dépense monstrueuse en vérification dans tous les sens, on mutualise les couts des employés de toutes les entreprises. Seul celles qui marchent paye beaucoup d’impôt.
Pour la mise en place, il faudrait une augmentation progressive de TVA avec une diminution des cotisations sociales à 50/50 employeur/salarié, et le paiement du dividende (le smic diminuant aussi un peu ou reste gelé). Cela permet une arrivé du dividende en douceur, diminuer l'effet de l'augmentation de la TVA sur les bas salaires, et une diminution des cotisations sociales pour les employeurs.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Dans ce cas, utilises une variable global comme pour le C, avec un tableau de structure, elle sera alloué dans le BSS, et ne consommera pas de mémoire, si il n'y en a pas besoin.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
Pour moi, la gestion d'interruption est quelques choses de lourds. Ici, il s'agit d'un getter, un truc très très sensible à la performance.
Souvent, dans le cas de try/catch, le compilateur ne fait pas d'inline, ce qui peut être finalement très couteux. Un simple test par rapport à la borne supérieur et à la nullité est suffisant, c'est souvent beaucoup plus efficace.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
mettre un try/catch si bas niveau, c'est si transparent que ça ? J'ai un doute en C++.
"La première sécurité est la liberté"
[^] # Re: allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
"tu auras sans doute plein de cases vides."
Non, c'est l’intérêt du componentAdress qui peut être aussi un simple tableau de short (max 65 000 objets, ce qui est pas mal). Cela permet d'éviter d'avoir trop de trou et de bénéficier du cache.
"La première sécurité est la liberté"
# allocation à l'arrache
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Est-ce que le fait de préallouer de la mémoire ne serait pas un bon moyen pour avoir l'allocation aligné ?
En gros, si fixe un max de N objects, chaque composant est allouer N fois, pour trouver le composant allouer est garder l'alignement mémoire, tu passes par une tables de pointeur.
Genre tu as :
composant composantPool[N];
composant * composantAddress[N];
getComposant (int entite){
composant * comp = composantAddress[entite];
if (comp) {
return * comp;
} else {
return null;
}
}
C'est bourrin mais pour quelques milliers d'objet, cela ne consomme pas trop de mémoire, tout est aligné, et l'accès est bien plus rapide qu'avec une table de hash. En plus, Linux ne doit allouer la mémoire que si elle est écrite. Donc, le "haut" du composant pool n'est pas réellement allouer.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
Dans l'absolue, si on se fout des perfs de lecture, on peut imaginer coller les writes dans l'ordre genre journal de transaction, sur un disque qui peut tenir 100 Mo/s, on arrive pas à faire mieux que 100 IO/s ? Si on groupe les writes, cela va plus vite j'imagine ?
"La première sécurité est la liberté"
[^] # Re: Duck typing et implementation
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 1.
Aucune idée. Cedric ?
"La première sécurité est la liberté"