"(Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)"
Je suis très intéressé ! Même que j'ai pensé regarder la difficulté d'implémentation de calcul de polynômes avec plein de coefficient, dans le cadre de calcul d'approximation polynomial à la décompression (pour décompresser des images par exemple). La forme "rapide" d'application d'un polynôme étant très itérative, c'est difficile d'imaginer un cœur de code parallèle rapide. Par contre, dans le cas d'une décompression d'image, chaque calcul de pixel est indépendant de celui de ses voisins.
Est-ce qu'il est possible d'inclure du png dans les pdf ?
J'ai vu uniquement du jpg ou du non compressé (tiff ?) Pour les copies d'écran, c'est assez ignoble. On a le choix dans une qualité pas top ou un fichier très lourd.
Comment tu fais si tu as 2 fois une propriété du même objet représenté graphiquement à l'écran, par exemple un chiffre qui change en fonction de l’élément graphique sélectionné, et la couleur de l’élément en question.
"c'est toujours vrai que le firmware d'un SSD simule un disque rotatif et que du coup un système de fichier spécialisé pour les mémoires flash n'a que peu d'intérêt. "
Oui il le simule toujours, mais cela ne veut pas dire que donner des ordres dans le bon sens n'améliore pas les choses.
Un SSD n'écrase jamais en place au contraire des disques dures, car l'effacement prend trop de temps. Donc, écrire "ailleurs" aura les mêmes performances immédiates, sans le surcout de l'effacement différé (write amplification).
Les temps d'accès des 2 technos n'ont rien à voir. Tous les algorithmes qui minimisent le changement d'adresse pour minimiser les changements de place de la tête de lecture ne servent à rien. Par contre, il faut mieux utiliser un bloc complet, qui est plus proche de 64K que de 4Ko.
L'origine du thread est tout de même la vitesse de l'application. Et beaucoup de V1 de site web n'arrive jamais à cette réactivité là.
Ensuite, cela a dérivé sur les outils employés par le web qui sont lent en général, par rapport à des techno moins à la mode mais plus rapide (et plus difficile à gérer) : (Java, ruby, php,…)
qq ms pour un select de 10000 éléments, c'est juste ultra lent. Sur un cpu ghz, cela fait un million de cycle ! une recherche avec strcmp() serait plus rapide.
tu devrais refaire le test avec des fichiers différents à chaque fois ou presque (10000 ?), et qui ne sont pas vides. Là, tu tapes toujours dans le cache disque.
"n'importe quoi qui fait une requête simple à une base de données et affiche le résultat se chargera sans difficulté en beaucoup moins de 50ms"
Rien que la requète SQL peut parfois prendre presque une seconde. Alors, c'est sans doute uniquement transitoire. Mais des applications web aussi rapide, j'en connais très très peu, voir pas du tout. Et encore, je navigue avec http request + ghostery + flashblock, ce qui accélère de beaucoup la plus part des sites.
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.
[^] # Re: Manque d'outils !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 3.
"(Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)"
Je suis très intéressé ! Même que j'ai pensé regarder la difficulté d'implémentation de calcul de polynômes avec plein de coefficient, dans le cadre de calcul d'approximation polynomial à la décompression (pour décompresser des images par exemple). La forme "rapide" d'application d'un polynôme étant très itérative, c'est difficile d'imaginer un cœur de code parallèle rapide. Par contre, dans le cas d'une décompression d'image, chaque calcul de pixel est indépendant de celui de ses voisins.
"La première sécurité est la liberté"
# png ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Intégrer des vidéos dans des fichiers PDF. Évalué à 1.
Est-ce qu'il est possible d'inclure du png dans les pdf ?
J'ai vu uniquement du jpg ou du non compressé (tiff ?) Pour les copies d'écran, c'est assez ignoble. On a le choix dans une qualité pas top ou un fichier très lourd.
"La première sécurité est la liberté"
[^] # Re: tests avec 10000 tickets
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 3.
En général, on passe au spécifique quand il y a des problèmes de performance, pas l'inverse :)
"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.
pour s’exécuter.
"La première sécurité est la liberté"
[^] # Re: J'approuve
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 si tu as 2 fois une propriété du même objet représenté graphiquement à l'écran, par exemple un chiffre qui change en fonction de l’élément graphique sélectionné, et la couleur de l’élément en question.
"La première sécurité est la liberté"
[^] # Re: Précision sur F2FS
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de Linux 3.12. Évalué à 9.
"c'est toujours vrai que le firmware d'un SSD simule un disque rotatif et que du coup un système de fichier spécialisé pour les mémoires flash n'a que peu d'intérêt. "
Oui il le simule toujours, mais cela ne veut pas dire que donner des ordres dans le bon sens n'améliore pas les choses.
Un SSD n'écrase jamais en place au contraire des disques dures, car l'effacement prend trop de temps. Donc, écrire "ailleurs" aura les mêmes performances immédiates, sans le surcout de l'effacement différé (write amplification).
Les temps d'accès des 2 technos n'ont rien à voir. Tous les algorithmes qui minimisent le changement d'adresse pour minimiser les changements de place de la tête de lecture ne servent à rien. Par contre, il faut mieux utiliser un bloc complet, qui est plus proche de 64K que de 4Ko.
"La première sécurité est la liberté"
[^] # Re: tests avec 10000 tickets
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 3.
en général tu manipules des pointeurs vers des string constant, sans les copier :)
"La première sécurité est la liberté"
[^] # Re: identifiants faciles?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 2.
Tu veux ajouter un code correcteur d'erreur ou alors tu veux une fonction de comparaisons tolérantes au erreur du moment qu'il n'y a pas d’ambiguïté.
"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.
L'origine du thread est tout de même la vitesse de l'application. Et beaucoup de V1 de site web n'arrive jamais à cette réactivité là.
Ensuite, cela a dérivé sur les outils employés par le web qui sont lent en général, par rapport à des techno moins à la mode mais plus rapide (et plus difficile à gérer) : (Java, ruby, php,…)
"La première sécurité est la liberté"
[^] # Re: tests avec 10000 tickets
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Small Issue Tracker. Évalué à 4.
Comment un tri de 10000 éléments peut prendre 49s ?
"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.
qq ms pour un select de 10000 éléments, c'est juste ultra lent. Sur un cpu ghz, cela fait un million de cycle ! une recherche avec strcmp() serait plus rapide.
"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é à 3.
Sauf que les propriétés ACID mets de fortes contraintes sur les performances, le nosql a été créé aussi pour ça.
"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.
tu devrais refaire le test avec des fichiers différents à chaque fois ou presque (10000 ?), et qui ne sont pas vides. Là, tu tapes toujours dans le cache disque.
"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é à -2.
"n'importe quoi qui fait une requête simple à une base de données et affiche le résultat se chargera sans difficulté en beaucoup moins de 50ms"
Rien que la requète SQL peut parfois prendre presque une seconde. Alors, c'est sans doute uniquement transitoire. Mais des applications web aussi rapide, j'en connais très très peu, voir pas du tout. Et encore, je navigue avec http request + ghostery + flashblock, ce qui accélère de beaucoup la plus part des sites.
"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.
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é"