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 ?
L'idée de ce genre d'optimisation multicritère n'est pas de maintenir une liste pré-trié pour chaque composant ? Genre tu tries les entités par textures utilisé, puis tu as une autre liste par mesh. Il doit être possible de ne pas avoir à retrier tout à chaque fois, car le contenu de la liste change peu. Ensuite, quand tu fais un rendu tu utilises les 2 listes.
Pour simplifier les parcours, est-ce qu'il ne suffirait pas d'avoir une liaison composant -> entité, qui permet de parcourir les composants dans l'ordre mais pouvoir faire référence aux entités si besoin ?
Là, tu racontes n'importe quoi, quand tu règles EXT3 (et 4) pour journaliser les données, tu ne tombes à pas à 100 io/s.
"Ou au moins aussi lentement que pour une base de données quand elle assure la même chose."
Je ne considère pas qu'un fsync() assure quoique ce soit, il demande une écriture en urgence qui tue beaucoup les performances, alors que bloquer (fdone()) jusqu'à une écriture effective, rendra exactement le même service mais avec de bien plus grande performance globales.
I2C est trop simple et demande beaucoup de CPU pour être gérer : la réception du message à mettre en mémoire, n'est pas faite par un DMA.
Si tu as une application avec plein de capteurs et un µp de gestion, tu as une floppé de bus qui converge vers ce µP. Sans gestion automatique, le cpu va passer son temps à gérer ses bus, ce qui est complètement con.
Dans une application robotique, tu lis tes capteurs 100 fois par seconde, ce n'est pas événementiel du tout. Tu as donc des trames prévisibles à gérer. Faire ça en I2C demande du soft et beaucoup de temps cpu.
De plus, il me semble que la version à 3.4Mhz a du mal avec le multipoint. Quitte à faire un bus IO avec un vrai espace d'adressage sur un seul bit, autant faire en sorte que sa distribution en étoile soit possible (genre clock + data, un dans chaque sens, (4fils) + 2*4 pour une distribution en étoile = 12 fils).
Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).
Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.
Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.
On peut imaginez un format de coque comme pour le format ATX.
Ensuite, on peut définir une taille d'écran, une fois la guerre des tailles fini, il va rester 3 ou 4 tailles différentes.
Ensuite, il faut définir le facteur de forme de l'électronique (avec port µusb, SIM et SD), de l'écran, et de la batterie. Mais je ne pense pas que l'on puisse moduler le bloc électronique.
[^] # 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é"
[^] # 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é à 2.
Vu les optims 2D de fou des EFL (cache multi niveau, rendu par morceau, shader de copie, etc…), cela serait dommage de ne pas en profiter.
"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é à 2.
L'idée de ce genre d'optimisation multicritère n'est pas de maintenir une liste pré-trié pour chaque composant ? Genre tu tries les entités par textures utilisé, puis tu as une autre liste par mesh. Il doit être possible de ne pas avoir à retrier tout à chaque fois, car le contenu de la liste change peu. Ensuite, quand tu fais un rendu tu utilises les 2 listes.
"La première sécurité est la liberté"
[^] # Re: quelques remarques
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é à 5.
Parfois la téchnique aide à ne pas écrire des conneries.
"La première sécurité est la liberté"
[^] # Re: netbook ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 3.
En plein soleil oui, mais du brillant à part dans le noir c'est pas possible.
"La première sécurité est la liberté"
[^] # Re: quelques remarques
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.
ok mais l'arbre n'est même pas typé par des archetypes ou autre ?
On peut vraiment y mettre n'importe quoi.
Cela risque de devenir un cauchemard à debuguer non ?
"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é à 3.
Pour simplifier les parcours, est-ce qu'il ne suffirait pas d'avoir une liaison composant -> entité, qui permet de parcourir les composants dans l'ordre mais pouvoir faire référence aux entités si besoin ?
"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.
Là, tu racontes n'importe quoi, quand tu règles EXT3 (et 4) pour journaliser les données, tu ne tombes à pas à 100 io/s.
"Ou au moins aussi lentement que pour une base de données quand elle assure la même chose."
Je ne considère pas qu'un fsync() assure quoique ce soit, il demande une écriture en urgence qui tue beaucoup les performances, alors que bloquer (fdone()) jusqu'à une écriture effective, rendra exactement le même service mais avec de bien plus grande performance globales.
"La première sécurité est la liberté"
[^] # Re: quelques remarques
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.
Comment tu fais un arbre d'entité ? Est-ce que des entités peuvent être référencé dans les composantes ?
"La première sécurité est la liberté"
[^] # Re: netbook ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 3.
L'XPS 13 a une dalle brillante, c'est pour moi inutilisable en extérieur, ce qui est un comble pour un ultraportable.
Le E… a une autonomie pas top de mémoire.
"La première sécurité est la liberté"
[^] # Re: oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 2.
I2C est trop simple et demande beaucoup de CPU pour être gérer : la réception du message à mettre en mémoire, n'est pas faite par un DMA.
Si tu as une application avec plein de capteurs et un µp de gestion, tu as une floppé de bus qui converge vers ce µP. Sans gestion automatique, le cpu va passer son temps à gérer ses bus, ce qui est complètement con.
Dans une application robotique, tu lis tes capteurs 100 fois par seconde, ce n'est pas événementiel du tout. Tu as donc des trames prévisibles à gérer. Faire ça en I2C demande du soft et beaucoup de temps cpu.
De plus, il me semble que la version à 3.4Mhz a du mal avec le multipoint. Quitte à faire un bus IO avec un vrai espace d'adressage sur un seul bit, autant faire en sorte que sa distribution en étoile soit possible (genre clock + data, un dans chaque sens, (4fils) + 2*4 pour une distribution en étoile = 12 fils).
"La première sécurité est la liberté"
[^] # Re: pas dans le sens du vent
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 2.
Le pop se fait pour la mémoire, le reste se fait sur le même die.
Chez TI, ils ont eu beaucoup de mal à mettre la partie RF de la radio sur le die numérique. Je ne sais pas si ils ont réussi.
"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.
Tu pourrais être plus précis ? Pour la base de donnée, je n'y connais pas grand chose, mais ce n'est pas du tout le cas des système de fichiers.
"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.
"select" SQL, pas le select() posix.
"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é à 1.
C'est pas faux.
Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).
Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.
Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.
"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.
Et on est autour de 100 op/s, c'est vraiment pas top. A croire que personne n'utilise les db dans ce mode là.
"La première sécurité est la liberté"
[^] # Re: L'idée est sympathique mais c'est loin d'être facile
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 3.
On peut imaginez un format de coque comme pour le format ATX.
Ensuite, on peut définir une taille d'écran, une fois la guerre des tailles fini, il va rester 3 ou 4 tailles différentes.
Ensuite, il faut définir le facteur de forme de l'électronique (avec port µusb, SIM et SD), de l'écran, et de la batterie. Mais je ne pense pas que l'on puisse moduler le bloc électronique.
"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é à 1.
Je veux la persistance quand même.
"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é à 3.
LevelDB a l'air pas mal : Environ 5x plus rapide que SQLite.
"La première sécurité est la liberté"