C'est ce genre de méthode que je disais lente, mais c'est de l'ordre de 1000 à 10000 ouverture/fermeture de fichier par seconde. 1000 io/s sur des machines Ghz ayant des centaines de Mo/s vers leurs disque dure, cela m'a toujours paru lent.
"Depuis quand parser des fichiers textes est plus efficace qu'utiliser SQLite (si on veut rester dans un truc facilement distribuable / installable) ??"
Tu as mesuré les performances au lieu de cracher sur la personne ?
Oui, son application est impressionnante, car tout ce que l'on trouve sur internet à souvent des latences de l'ordre de la demi-seconde et non de 200ms. Et niveau réactivité, cela change tout.
Pour ma part, je n'ai jamais compris le dev web moyen qui utilise des technologies aussi lentes (ruby, php,…).
Si tu veux être robuste, tu fais des écritures type ajout seulement. En cas d'écriture multiple, cela doit être le bordel. J'imagine que le write bas niveau (et non fwrite) doit permettre de faire des écriture atomiques, mais rien ne le garantie formellement (reserfs l'avais mis dans sa doc). Pour des raisons de performance, il vaux mieux, de toute façon, avoir un seul écrivain qui gère les accès multiple au fichier.
Pour un fichier en ajout seulement, le dernier write() sera présent ou absent, c'est la garantit du VFS Linux (cela ne sera pas un truc à moitié). Cela peut être déjà une bonne garantie. fsync() est un mauvaise solution, sans garanti que le disque dur ne fasse pas de cache en écriture. C'est hyper lent, et surtout ce que l'on veut c'est un fdone().
Si tout peut résider en RAM, les lectures ne sont pas vraiment un problème et l'écriture en ajout seulement offre déjà pas mal de garanti.
Plein de fichier, cela ne tient pas la charge. Ouvrir/fermer un fichier, c'est lent. Il doit y avoir un paquet de lock à droite à gauche. J'imagine que la limite doit être sur le nombre d'utilisateur en même temps.
Si, cela doit être possible. Mais cela serait très lent. Tu fais une modulation d'amplitude à 18khz (genre morse, c'est très insensible au bruit), au mieux tu passes du 10kb/s, avec une correction d'erreur c'est encore plus bas.
La partie du teste ABX en double aveugle est plus pertinent.
Je ne vois pas comment le filtre passe bas qui a détruit la phase du signal autour de 20 khz pour l'enregistrement peut être gommer ensuite par un oversampling.
L'article oublie complètement la distorsion des filtres passe-bas. A 44 khz, le filtre est raide à 20 khz à -3 dB. -3db, c'est /2 en terme d'amplitude et les phases peut-être complètement décalés (90°).
Le 192khz permet d'un filtre simple, avec zéro distorsion à 20khz, ni changement de phase.
Son intermodulation à 33khz, passe à -80dB ! C'est limite audible, de l'ordre de grandeur des erreurs du son 16 bits.
Disons qu'il faudrait une type de flashage par type de clef. Or il y a un tas de fabricant. Mais de l'autre coté, il ne doit y avoir tant de vendeur de controlleur de flash avec USB que ça (moins d'une dizaine ?).
J'imagine que c'est à destination de francophones ou uniquement des Français ?
Pour du logiciel libre, il faudrait un personnage comme c'est souvent le cas.
Un vendeur en l’occurrence? Genre Boulanger ou chef restaurateur (caricature de commerçant français) ou garçon de café ? Les personnages sont rarement humains dans le logiciel libre, par contre.
Ce n'est pas une loterie. Si on reprend les point qui n'ont pas le droit d'exister les 4 ensembles :
a) le hasard
b) le sacrifice financier du joueur (contrepartie financière)
c) l’espérance du gain
d) l’offre faite au public (article L121-36 du Code de la consommation)
Or:
a) il n'y a pas de hasard
b) il n'y a pas d'achat
Il a existé des concours de site web, il existe des "bounty" pour du code libre (google). Exprimer un besoin pour qu'il soit couvert par un logiciel libre, cela doit bien exister.
La question est d'interdire d'interdire le reverse engineering ou d'obliger à publier une documentation pour chaque outil informatique ? (genre ICD pour les formats de fichier, ou les réseaux, etc…)
"Ah oui je me rappelle de toi, tu es le gars qui se plaint sans arret que les perfs de Java sont a chier, mais qui refuse d'en apprendre plus sur le fonctionnement du langage et de la JVM."
Les perf pas top, je les es vu, donc dire que tu n'y crois pas trop… C'est un peu énorme.
for() {if()…} -> if(){for()…}{for()…}
un peu de déroulage de boucle, etc…
réutiliser les objets au lieu de les oublier et en créer d'autre. En gros, faire en sorte de ne jamais faire de new en rythme de croisière.
"A propos de l'inline des getters/setters je n'y crois pas du tout"
Je m'en fout pas mal de ton avis. Quand tu vires les getter/setter et que tu gagnes 30% de perf, tu te dis que le compilo optimise rien (c'était une JVM sun sous Linux)
"A propos des methodes statics, je te crois sans peine, c'est toujours le plus rapide a appeler quel que soit le langage."
Y'a des moyens pour que la différence soit minime, c'est loin d'être le cas.
"As-tu au moins laisser la JVM "chauffer" et trouver les methodes a inliner?"
Peut-être pas assez. Mais tout le code était chaud car cyclique avec un parcours d'arbre.
Pour avoir jouer avec un IA en Java, j'estime l'efficacité d'une JVM Sun à l'équivalent de gcc -O0. Il n'y même pas de sortie de test des boucles, ni d'inline des getter/setter. Une methode static est bien plus rapide qu'une méthode virtuel normal.
Je ne sais pas si les x86 fonctionnent de la même façon, mais les Omap3 avaient une gestion distincte concernant les caches. Ils n'avait que 2 modes : On ou rétention. La consommation statique est aussi proportionnel à la tension d'alimentation. Les caches prennent une grosse partie de ces puces, 30% à vue de nez. Si on baisse la tension/fréquence cpu, sans faire de même avec les caches, la puissance restant la même, l'énergie consommée augmente pour un cycle cpu.
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 1.
C'est ce genre de méthode que je disais lente, mais c'est de l'ordre de 1000 à 10000 ouverture/fermeture de fichier par seconde. 1000 io/s sur des machines Ghz ayant des centaines de Mo/s vers leurs disque dure, cela m'a toujours paru lent.
"La première sécurité est la liberté"
[^] # Re: Absurde
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à -1.
"Depuis quand parser des fichiers textes est plus efficace qu'utiliser SQLite (si on veut rester dans un truc facilement distribuable / installable) ??"
Tu as mesuré les performances au lieu de cracher sur la personne ?
Oui, son application est impressionnante, car tout ce que l'on trouve sur internet à souvent des latences de l'ordre de la demi-seconde et non de 200ms. Et niveau réactivité, cela change tout.
Pour ma part, je n'ai jamais compris le dev web moyen qui utilise des technologies aussi lentes (ruby, php,…).
"La première sécurité est la liberté"
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 2.
Si tu veux être robuste, tu fais des écritures type ajout seulement. En cas d'écriture multiple, cela doit être le bordel. J'imagine que le write bas niveau (et non fwrite) doit permettre de faire des écriture atomiques, mais rien ne le garantie formellement (reserfs l'avais mis dans sa doc). Pour des raisons de performance, il vaux mieux, de toute façon, avoir un seul écrivain qui gère les accès multiple au fichier.
Pour un fichier en ajout seulement, le dernier write() sera présent ou absent, c'est la garantit du VFS Linux (cela ne sera pas un truc à moitié). Cela peut être déjà une bonne garantie. fsync() est un mauvaise solution, sans garanti que le disque dur ne fasse pas de cache en écriture. C'est hyper lent, et surtout ce que l'on veut c'est un fdone().
Si tout peut résider en RAM, les lectures ne sont pas vraiment un problème et l'écriture en ajout seulement offre déjà pas mal de garanti.
"La première sécurité est la liberté"
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 1.
J'avais cru comprendre que chaque ticket était dans un fichier différent.
"La première sécurité est la liberté"
[^] # Re: pas mal !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 3.
Plein de fichier, cela ne tient pas la charge. Ouvrir/fermer un fichier, c'est lent. Il doit y avoir un paquet de lock à droite à gauche. J'imagine que la limite doit être sur le nombre d'utilisateur en même temps.
"La première sécurité est la liberté"
[^] # Re: Au delà de 20kHz, on entend rien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 3.
"Donc si tu bouges ta tête de un quart de longueur d'onde (90°), soit environ 6mm, la phase change autant que ce que fait le filtre."
Tu veux dire que bouger la tête provoque un changement de phase entre un signal à 20khz et un autre à 1khz par exemple ?
"La première sécurité est la liberté"
[^] # Re: Fake
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 4.
Si, cela doit être possible. Mais cela serait très lent. Tu fais une modulation d'amplitude à 18khz (genre morse, c'est très insensible au bruit), au mieux tu passes du 10kb/s, avec une correction d'erreur c'est encore plus bas.
"La première sécurité est la liberté"
# pas mal !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 3.
Il manque peut être une "page perso" qui résume les tickets lié à une personne.
C'est très réactif, mais il faudrait charger la base avec 10000 tickets pour vraiment vérifier :)
"La première sécurité est la liberté"
[^] # Re: Au delà de 20kHz, on entend rien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 2.
La partie du teste ABX en double aveugle est plus pertinent.
Je ne vois pas comment le filtre passe bas qui a détruit la phase du signal autour de 20 khz pour l'enregistrement peut être gommer ensuite par un oversampling.
"La première sécurité est la liberté"
[^] # Re: Au delà de 20kHz, on entend rien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 0.
L'article oublie complètement la distorsion des filtres passe-bas. A 44 khz, le filtre est raide à 20 khz à -3 dB. -3db, c'est /2 en terme d'amplitude et les phases peut-être complètement décalés (90°).
Le 192khz permet d'un filtre simple, avec zéro distorsion à 20khz, ni changement de phase.
Son intermodulation à 33khz, passe à -80dB ! C'est limite audible, de l'ordre de grandeur des erreurs du son 16 bits.
"La première sécurité est la liberté"
[^] # Re: Au delà de 20kHz, on entend rien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 7.
Lors d'une expo sur le son, il y avait un générateur sonor, j'entendais 17khz mais pas 18. Des gamins entendaient 20khz.
Lors du scandale du matos anti-jeune, ou des sonneries moskito que les profs ne pouvaient entendre, il s'agissait de sonnerie à 18khz de mémoire.
"La première sécurité est la liberté"
[^] # Re: Well listen, let the police do the job, be sure I'll give you answer as soon as possible okay?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Rencontrez badbios le virus plus puissant que Stuxnet. Évalué à 4.
Disons qu'il faudrait une type de flashage par type de clef. Or il y a un tas de fabricant. Mais de l'autre coté, il ne doit y avoir tant de vendeur de controlleur de flash avec USB que ça (moins d'une dizaine ?).
"La première sécurité est la liberté"
[^] # Re: Que vaut un mot de passe comme ceux de pwgen ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La proche fin des mots de passe. Évalué à 2.
filmer avec un téléphone portable ?
"La première sécurité est la liberté"
# Réflexions
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours logo pour l'association En Vente Libre. Évalué à 2.
J'imagine que c'est à destination de francophones ou uniquement des Français ?
Pour du logiciel libre, il faudrait un personnage comme c'est souvent le cas.
Un vendeur en l’occurrence? Genre Boulanger ou chef restaurateur (caricature de commerçant français) ou garçon de café ? Les personnages sont rarement humains dans le logiciel libre, par contre.
"La première sécurité est la liberté"
[^] # Re: concours
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours logo pour l'association En Vente Libre. Évalué à 2. Dernière modification le 04 novembre 2013 à 14:19.
Ce n'est pas une loterie. Si on reprend les point qui n'ont pas le droit d'exister les 4 ensembles :
Or:
a) il n'y a pas de hasard
b) il n'y a pas d'achat
Le règlement :
http://enventelibre.org/blog/concours-cr%C3%A9ation-du-logo-d%E2%80%99en-vente-libre
"La première sécurité est la liberté"
[^] # Re: mauvaise pratique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Concours logo pour l'association En Vente Libre. Évalué à 2.
Il a existé des concours de site web, il existe des "bounty" pour du code libre (google). Exprimer un besoin pour qu'il soit couvert par un logiciel libre, cela doit bien exister.
"La première sécurité est la liberté"
[^] # Re: Je confirme
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Droit des Logiciels : Un livre de référence pour les juristes et les informaticiens. Évalué à 2.
La question est d'interdire d'interdire le reverse engineering ou d'obliger à publier une documentation pour chaque outil informatique ? (genre ICD pour les formats de fichier, ou les réseaux, etc…)
"La première sécurité est la liberté"
# sse ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal G'MIC 1.5.7.2 : Multi-threading, Krita, et autres nouveautés.... Évalué à 5. Dernière modification le 31 octobre 2013 à 10:31.
Toujours pas de gentil code pour le SSE ? (gcc est capable de faire le boulot tout seul si le code a la bonne forme)
On peut encore doubler les perfs dans certain cas.
Est-ce que le threading utilise openMP ? Cela marche pas mal en général.
"La première sécurité est la liberté"
[^] # Re: OpenGL antique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à -2.
"Ah oui je me rappelle de toi, tu es le gars qui se plaint sans arret que les perfs de Java sont a chier, mais qui refuse d'en apprendre plus sur le fonctionnement du langage et de la JVM."
Les perf pas top, je les es vu, donc dire que tu n'y crois pas trop… C'est un peu énorme.
"La première sécurité est la liberté"
[^] # Re: OpenGL antique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à -1. Dernière modification le 29 octobre 2013 à 15:04.
"Qu'est ce qu'un IA?"
une intelligence artificiel pour un jeu.
"De quelle optimisation parles-tu?"
for() {if()…} -> if(){for()…}{for()…}
un peu de déroulage de boucle, etc…
réutiliser les objets au lieu de les oublier et en créer d'autre. En gros, faire en sorte de ne jamais faire de new en rythme de croisière.
"A propos de l'inline des getters/setters je n'y crois pas du tout"
Je m'en fout pas mal de ton avis. Quand tu vires les getter/setter et que tu gagnes 30% de perf, tu te dis que le compilo optimise rien (c'était une JVM sun sous Linux)
"A propos des methodes statics, je te crois sans peine, c'est toujours le plus rapide a appeler quel que soit le langage."
Y'a des moyens pour que la différence soit minime, c'est loin d'être le cas.
"As-tu au moins laisser la JVM "chauffer" et trouver les methodes a inliner?"
Peut-être pas assez. Mais tout le code était chaud car cyclique avec un parcours d'arbre.
"La première sécurité est la liberté"
[^] # Re: OpenGL antique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 2.
Pour avoir jouer avec un IA en Java, j'estime l'efficacité d'une JVM Sun à l'équivalent de gcc -O0. Il n'y même pas de sortie de test des boucles, ni d'inline des getter/setter. Une methode static est bien plus rapide qu'une méthode virtuel normal.
"La première sécurité est la liberté"
[^] # Re: OpenGL antique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 2.
Et personne n'a voulu faire de moteur 3D intermédiaire, un peu comme SDL pour la 2D à une certaine époque ? Les EFL ne sont pas bien ?
"La première sécurité est la liberté"
[^] # Re: OpenGL antique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 2.
C'est pas le rôle des "moteurs 3D" d'abstraire tout ça ?
"La première sécurité est la liberté"
[^] # Re: OpenGL antique
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche EGLX : un petit traducteur GLX-EGL pour Wayland. Évalué à 9.
Tu peux décrire un peu mieux le problème pour nous expliquer, à nous autre ,qui ne prennont pas d'OpenGL au petit déjeuner ?
"La première sécurité est la liberté"
[^] # Re: Pourquoi les constructeurs augmentent le nombre de points de fonctionnement tension/fréquence?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Amélioration des performances graphiques du noyau 3.12. Évalué à 3.
Je ne sais pas si les x86 fonctionnent de la même façon, mais les Omap3 avaient une gestion distincte concernant les caches. Ils n'avait que 2 modes : On ou rétention. La consommation statique est aussi proportionnel à la tension d'alimentation. Les caches prennent une grosse partie de ces puces, 30% à vue de nez. Si on baisse la tension/fréquence cpu, sans faire de même avec les caches, la puissance restant la même, l'énergie consommée augmente pour un cycle cpu.
"La première sécurité est la liberté"