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.
Hello, est-ce qu'il existe un base nosql qui s'embarque de la même façon que sqlite ? Un truc qui garanti l'intégrité du fichier, mais dont on se fout un peu du coté "ACID" ?
C'est histoire de dépasser les 100 transactions par seconde.
Le principe de faire des légo avec des ordinateurs posent toujours le même problème : les connecteurs coutent plus chère que les puces. Plus, c'est rapide, plus c'est chère. Thunderbolt peut changer les choses mais, il y aura toujours le problème de la consommation.
Par contre, il peut toujours définir des standards d’interconnexion comme USB ou I2C, voir un standard logiciel BIOS (comme Arduino).
Pour l'embarqué très petit, je trouve qu'il manque un bus type I2C avec du débit mais avec un grand espace d'adressage, mono master et avec DMA. L'idée est d'avoir un µP dont des zones mémoire, se mette à jour régulièrement par DMA, sans surcout CPU de communication, mais plus simple que les CAN, et autre I2C.
Chez moi, cela rame beaucoup moins en plein écran (gpu intel), et cela rame plus(+) si la vidéo embarqué n'est pas visible en entier sur la page, comme si le fait de tronquer lui faisait faire du travail en plus.
J'ai aussi un netbook (EEE) de dev, Atom avec 2 Go de RAM et SSD intel. La machine est hyper véloce, sauf pour lire les vidéos youtube qui ne sont pas en pleine écran, et le navigateur rame un peu.
Peut être que cela va mieux avec les atom bi-coeur.
[^] # 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é"
[^] # 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.
Par transaction,je pensais IO/s (un write, un read, un select…)
"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.
Oui, mais c'est surtout histoire de résister à une coupure de courant, et un kill -9.
"La première sécurité est la liberté"
# 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.
Hello, est-ce qu'il existe un base nosql qui s'embarque de la même façon que sqlite ? Un truc qui garanti l'intégrité du fichier, mais dont on se fout un peu du coté "ACID" ?
C'est histoire de dépasser les 100 transactions par seconde.
"La première sécurité est la liberté"
# 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é à 3.
Le principe de faire des légo avec des ordinateurs posent toujours le même problème : les connecteurs coutent plus chère que les puces. Plus, c'est rapide, plus c'est chère. Thunderbolt peut changer les choses mais, il y aura toujours le problème de la consommation.
Par contre, il peut toujours définir des standards d’interconnexion comme USB ou I2C, voir un standard logiciel BIOS (comme Arduino).
Pour l'embarqué très petit, je trouve qu'il manque un bus type I2C avec du débit mais avec un grand espace d'adressage, mono master et avec DMA. L'idée est d'avoir un µP dont des zones mémoire, se mette à jour régulièrement par DMA, sans surcout CPU de communication, mais plus simple que les CAN, et autre I2C.
"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é à 4.
ça ? http://www.materiel.net/ordinateur-portable/sony-vaio-pro-svp1121a4e-b-93424.html
"La première sécurité est la liberté"
[^] # Re: Oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 2.
Chez moi, cela rame beaucoup moins en plein écran (gpu intel), et cela rame plus(+) si la vidéo embarqué n'est pas visible en entier sur la page, comme si le fait de tronquer lui faisait faire du travail en plus.
Et coté Navigateur, c'est fluide ?
"La première sécurité est la liberté"
[^] # Re: Oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 2.
J'ai aussi un netbook (EEE) de dev, Atom avec 2 Go de RAM et SSD intel. La machine est hyper véloce, sauf pour lire les vidéos youtube qui ne sont pas en pleine écran, et le navigateur rame un peu.
Peut être que cela va mieux avec les atom bi-coeur.
"La première sécurité est la liberté"