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 ?
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.
[^] # 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é"
[^] # 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é"