Presque parfais. Sont seul probleme est de ne pas gérer explicitement l'aspect multiprocesseur, mais je ferais 8 queues.
Le seul soucis sera de répartir correctement les tâches pour que chaque queue est glabalement la même durée totale.
C'est le genre de chose que je voudrais faire, mais j'aimerais trouver un truc tout près qui le fasse, si ça existe...
C'est le genre de programme qui peut devenir vite chiant a débugger si on veut être sûr que ça marche bien. (et pour lancer 400 jobs avant les vacances, il y pas intéret à ce que ça plante deux aprés une foi que je suis dans le train sans acces au net...)
Si vraiment je ne trouve rien, je m,y résoudrais, mais j'éspère que quelqu'un à déjà fait le boulot.
Merci, mais ce n'est pas du tout ce que je cherche. Taskset te permet de chosir sur quel cpu executer une tache mais il ne va pas ce charger tout seul de lancer des commandes.
Je me tape de savoir sur quel proc la commande est executée. Linux fait tres bien sont boulot a ce niveau. Si je lance 8 commandes en même temps, les 8 proc seront utiliser en même temps.
Le problemes c'est que j'ai 400 commandes a lancer, et que je ne peut les lancer que 8 à la fois. Tout ce qu'il me faut c'est un programme qui surveille ces 8 programme et qui, quand un ce termine, lance le suivant.
D'un autre côté, mettre dans les codes des URLs telles que http://ratp.fr/code?id=0123456789 aurait été bien plus simple pour eux.
Ils gèrent la redirection comme ils le veulent, pour la mise en place, un stagiaire pendant une semaine leur fait tous le bousin, avec une interface similaire à celle du prestataire actuel.
Comme ça le temps pour faire une modif est le même voir inferieur a la situation actuelle mais avec un coût quasiment nul.
Si seulement les décision n'était pas prise par des gens qui ni connaissent rien conseillés par des commerciaux.
Attention, je suis bien d'accord avec le fait que la grosse majoritée de remasters actuels sont de grosse daubes.
Je n'ai fait ces test que pour bien montrer que le travail qui à été fait sur ceux des Beattles est de très bonne qualitée contrairement à ce qu'indiquait Aurélien Girard.
Bon, d'autre l'on fait aussi mais comme je me suis fais chiez à le faire hier je le met quand même.
J'ai récupéré l'album hier soir et j'ai pus l'écouter et faire quelques éssais. Eh bien, après écoute, je dois avouer qu'à mon avis ce que tu as entendu ça ne devait pas être le même album. Tu es sur qu'on ne t'a pas fait écouter un mp3 regraver sur un CD ?
Parce que bon, à l'oreille, ça doit être un des meilleurs de tous ceux que j'ai de la série. En même temps c'est loin d'être mon préféré donc je suis surement moins éxigent que avec certains autres, mais quand même. Le son de «Wild Honey Pie» est d'un clarté presque magique, «Blackbird» est d'une propretée étonante quand on voit le premier master CD et je parle pas de «Piggies». Il est remonté de quelques place dans ma liste d'achats, un vrai bonheur ce CD.
Mais bon, en même temps je vous demande pas de faire confiance à mon oreille, surtout que j'ai tendance à me contretaper des mauvais résultats théoriques si le disque me plait. Mais bon, j'ai lancer le sujet en disant que je n'était pas d'acord avec ti sur la qualité de ces remaster, donc je vais argumenter avec autre chose que du subjectif.
Donc du côté objectif, j'ai rippé le CD avec cdparanoia en mode le plus paranoiaque et bien vérifié qu'il m'indiquait aucune erreur ou problème et j'ai ensuite analysé les fichiers avec audacity. J'ai fais des captures d'écrans de tous les morceaux du CD pour ceux qui ne l'on pas et qui veulent qand même voir ce que cela donne (http://nosys.oniros.org/beattles/ ).
Ce qu'on peut voir sur ces captures onfirme mon impréssion, on a pas de problème de compression dynamique ici. Les morceaux sont un peu plus masteriser un peu plus fort que ceux de 1987 mais sans qu'il n'y ait de perte. Et ce n'est pas un problème. À l'époque des vinyles et des cassettes, le support faisait que l'on obtenait la meilleur qualité en masterisant plus bas que les limittes du support pour éviter la plage limite. Un bon master à l'époque devait donc être suffisament fort pour avoir une bonne dynamique mais suffisament faible pour ne pas être dégradé.
De nos jour on à plus ce problème là grace au numérique, donc sur un support comme les CD, l'idéal est de masteriser pour que les morceaux soient calés au plus près des limiteset donc ainsi bénéficié de la plus grace plage de dynamique possible. Ce qui est le cas sur ce CD.
On peut voir que le morceaux qui est calé au plus juste est «While My Guita Weeps» qui donne même l'impression d'être écretté, pourtant en y regardant de plus près on voit que c'est pas si sûr. S'il à perdu quelque chose, c'est vraiment minime et uniquement en 4 ou 5 point du morceaux, et honêtement, à l'oreille, même en sachant ou son les perte éventuelles, je suis bien incapable d'entendre quoi que ce soit.
Les autres morceaux sont tous calés pour être homogène avec celui là, et je pense qu'il doit y avoir un ajustement global sur l'ensemble des albums.
Pour ceux que ça amuse, vous pouvez regrdez l'ensemble des morceaux, on voit bien la forte disymétrie entre les deux canneaux stéréo qui est relativement typique de cette époque ou le véritable enregistrement et le mixage avec les artiste ce faisait en mono et ou la version stéréo, quand elle existait, était préparé plus tard avec ce que l'on pouvait...
Et pour ce qui est de la dynamique en chiffres, on dépasse facilement les -12db d'amplitude, donc on est largement dans les bon vieux standards et pas dans les bouse infames qu'ils nous sortent maintenant et qui on du mal à atteindre les -3 ou -4db.
Donc pour conclure, cet album (comme les autres de la série que j'ai pus écouter) est excelent, et honetement je ne vois pas comment ils aurraient pus faire mieux. Mais je suis ouvert à tout commentaire et critiques.
Ça m'intrigue de plus en plus, donc j'ai passer un coup de fil au pote pour récupérer le CD ce soir et faire le test. Je vous donne mes impréssions demain, et je vais éssayer de faire des captures d'écran de audacity.
L'interet c'est que cela donne l'impression que le volume de ta musique est plus fort que celui des autres morceaux, et en théorie ça fait vendre plus.
Dans la pratique, toutes les radio et autre ce sont adapté à cette débilité et normalisent les musiques avant de les passer.
Donc au final ça ne sert qu'à une chose : réduire la qualitée...
Tu l'as vraiment écouté ? Sur une bonne chaine ? Fait un test en aveugle ?
Parceque pour avoir écouté, aussi bien les anciens que les remaster, je les trouvent très bons. J'ai pas l'album blanc sous la main, je ne les ai pas tous acheter, mais sur un test rapide sur deux autres de la collection remaster sortis à la fin de l'année dernière il n'y a aucun problème.
En ouvrant dans audacity un rip fai en mode paranoia on peut voir du premier coup d'oeil que l'on est très loin des bouses de ces dernières années. Il n'y a pas de compression de la dynamique et on peut voir que les pics sont très prècis, ce qui confirme mon impression à l'oreille.
Donc, à moins que l'album blanc soit une exception dans la série des remaster, ce qui m'ètonnerais, tu n'as pas du bien l'écouter, ou ce n'était pas les dernier remasters. Je vois un pote qui l'a ce week end, je ferais le test pour être sur.
Pour une fois qu'ils nous font de bon remasters, on va éviter de cracher dessus.
[WARNING: ce commentaire est hors-sujet mais puisque l'on en parle]
Tout-à-fait, désolé j'avais oublié le lien.
Le 1er guide est un must-read pour toute personne qui veut optimiser son code serieusement plutôt qu'avec les recette de sa grand-mère.
Le 3ème est aussi très intéressant pour les optimisations de haut niveau notament la partie sur la prédiction de branchement. Comprendre ce qui ce passe dans le processeur est un énorme atout pour l'optimisation plus hardcore.
Il y a bien longtemps que je n'ai pas écrit d'assembleur, par contre je lit très souvent le code produit par le compilateur pour voir ce qu'il produit et chercher ce que je pourrais faire pour l'aider à mieux comprendre ce que je veux et l'aider à écrire du meilleur code.
Le 5 est à feuilleter une fois juste pour bien voir ce que coute chaque paramètres lors d'un appel, mais ça reste négligeable. Globalement c'est pas vraiment là qu'il y a gagner. La plupart des optimisation la dessus rendent le code bien moins lisible et pas vraiment plus rapide.
Le 2 et le 4 sont, pour moi, intéressant uniquement pour l'utilisation des instruction SIMD via les intrinsics. Ils seront très utile à des personnes qui écrive des compilateurs mais ce n'est plus mon cas.
Ce qui me sert le plus ce sont les timing des instructions SIMD pour justement tous les cas ou GCC ne pourra rien faire.
e dois avouer que personnellement les perf de lisaac, surtout sur le code des autres, je m'en fou...
Je disais juste qu'a mon avis certaines optimisation font bien plus de mal qu'autre chose, au moins pour l'instant. Pourquoi vouloir faire très compliqué, risqué et peu-utile en général, quand il y a moyen de faire compliqué, moins risqué et très utile ?
Contrairement à ce que tu dis, faire mieux que gcc en matière de vectorisation n'est pas si complexe (tout est relatif bien sur....)
Le langage C est tel qu'il est difficilement vectorisable automatiquement, à cause des pointeurs ou de la sémantique complexe de certaines constructions notamment. Les boucles vectorisable doivent avoir des formes simples et correspondre aux motif connus, ce qui rend l'écriture de ces boucles généralement difficiles.
En Lisaac par contre, il y a beaucoup moins d'ambigüité et bien plus de sémantique dans les constructions, donc la vectorisation est plus simple. Que ce soit juste réécrire les boucles pour que gcc puisse les optimiser ou utiliser les intrinsics ça reste quand même bien plus profitable.
Je parlais de cela dans le sens ou Lisaac ne sera pas capable de produire d'autres forme de vectorisations que celle que gcc gère, et il est très contraint par les formes reconnues par gcc, don pas trop d'imbrication de ces boucles et de combinaison simples.
J'ai citer ce type d'optimisation car je pense que c'est bien plus profitable que d'essayer (et à mon avis de rater, vu la difficultée) de faire automatiquement les optimisation que j'ai fait à la main. Et je pensais plutôt à la possibilité d'utiliser les intrinsics pour les cas ou lisaac peut vectoriser mais ne peut pas transmettre l'optimisation à gcc. (désactivable bien sur)
Ce n'était pas une critique du fait que lisaac est limité au c89, plutôt une remarque sur cette limitation et le fait qu'optionellement lever cette restriction permettrait de faire des optimisations bien profitable que ce que nicolas proposait.
Ne mélange pas ce qui existe et ce qu'il est possible de faire. Lisaac produit du C89 car en l'état actuelle des choses, il n'y a aucun intérêt à produire autre chose sauf à être incompatible.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Je ne mélange pas tout, je dit juste que, à mon avis, si votre objectif est de produire du code rapide, il faut mettre des priorités sur les optimisation à implémenter, et si ce n'est pas votre objectif, ça ne sert à rien de continuer la discution.
Implémenter des optimisation extrêmement complexes de ce type c'est prendre le risque d'introduire des erreurs dans le code généré et de rendre le compilateur très complexe pour des cas relativement rare.
Par contre la vectorisation, bien que complexe, à fait l'objet de bien plus de recherche et va s'appliquer dans beaucoup plus de cas. Donc moin de risque pour un plus gros gain. Il me semble plus pertinent de commencer par la.
Et donc je soulevais le problème du fait que Lisaac pour l'instant produit du code c89 donc la vectorisation n'est pas directement possible.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Lisaac à une vision plus haut niveau du code, à mon avis il doit y avoir plein de cas ou gcc ne peut pas vectoriser le code mais ou lissac possède lui les informations pour le faire.
Même si gcc est très bon pour ce genre de choses, les motifs qu'il est capable de paralléliser restent très limités, et bien souvent il suffit qu'il y ait un pointeur qui traine pour tout foutre en l'air. Dans la pratique, écrire du code que gcc peut paralléliser est souvent au moins aussi complexe que d'écrire directement le code parallèle avec les intrinsics. Et le plus embêtant c'est que la moindre petite modification anodine peut rendre le code non parallélisable, donc un patch par quelqu'un qui ne fait pas super gaffe peut-être catastrophique.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Le problème c'est qu'optimiser pour le cache est à double tranchant. Il y a trois cas à considérer :
- tu as la bonne taille pour remplir exactement le cache comme il faut et le code est très rapide ;
- tu as exactement la bonne taille pour que le cache soit pourit à mort, et la tu as un code affreusement lent ;
- le reste ou tu as une quantité classique de cache miss et un code de vitesse normale.
Et mon experience à ce niveau la me fait dire que quand tu ne fais rien de spécial, tu est à peu près toujours dans le cas 3, mais des que tu cherche à faire des trucs un peu intelligent tu tombe le plus souvent dans le cas 2 et il faut faire pas mal d'essais avec différentes tailles pour réussir à tomber dans le cas 1.
Donc si tu ne connais pas la taille du cache, il vaut mieux ne rien faire, et si tu connais la taille du cache, trouver la bonne taile pour tes blocs est souvent possible uniquement de manière empirique.
Je suis loin d'etre persuader qu'un compilateur puisse le faire automatquement avant un bon bout de temps, les éléments à prendre en compte sont tellement nombreux et différents dans chaque cas. Pour plus d'infos tu peut regarder les manuels d'optimisation d'agner qui décrit bien le problème.
Mais avant de savoir ce qu'il est possible de faire ou de ne pas faire, il faut déjà avoir une idée assez précise de ce que l'on voudrait.
Je ne veut pas être méchant, mais avant de songer à ce genre d'optimisation, qui ont l'inconvénient d'être à la fois extrêmement complexe à implémenter sans faire de conneries et applicable dans très peu de cas, il faudrait peut-être trouver une solution pour des optimisations plus utiles.
La vectorisation du code est généralement beaucoup plus efficace que l'optimisation des caches car la majorité du code accède à la mémoire avec des motifs facilement identifiables par le processeur. À par sur des cas précis comme celui-là, j'ai rarement recours à ce genre de techniques. En plus le code est spécifique à un modèle de processeur car la taille des blocs doit être choisie en fonction de la taille des lignes de cache.
Par contre la vectorisation du code apporte généralement beaucoup plus et surtout s'applique dans bien plus de cas. Et coup de bol, il y a moyen de ce comparer à d'autre compilateurs et il y a même des benchs qui trainent sur le net.
Mais la on tombe sur une limitation de Lisaac, le fait de générer du C89 à l'avantage d'être portable mais empêche tout optimisation de ce côté, vous êtes obligé de croisé les doigts pour que le compilateur C en dessous réussisse à faire ce boulot.
C'est vraiment dommage que ton code soit fermé. Cela aurait fait une bonne référence, pour un bench pour voir l'effet d'optimisation.
On choisit pas toujours ce que l'on peut faire de son code... Mais si ça peut te faire plaisir une version plus simple du code devrait être disponible dans quelques temps, mais pas en Lisaac, juste en C.
Perdu, mais pas trop loin. Mon rêve serait de lui filer mon article en TeX et qu'il aille tout seul chercher les formules et les implémenter de la manière la plus efficace possible sans que j'ai à me poser aucune question.
Le problème est que ce n'est pas réalisable pas plus qu'un compilateur qui prend l'algo en Octave et qui me pond un programme aussi rapide et peu gourmand en mémoire que ma version en C.
Un bon compilateur pourrait éventuellement s'apercevoir que certains vecteurs et matrice intermédiaires n'on pas à être conservé et factoriser le code. Pour d'autre endroits, il pourrait voir que tous les traitement sont indépendants et donc paralleliser le code ou faire du striping.
Mais, il sera incapable de gérer tous les cas que j'ai eu à résoudre ici, notament les calculs qui permettent de gérer les valeurs au limites des blocs, ou il faut réellement inventer la manière de faire le calcul, elle n'est pas dans le code pour octave. Ou encore des réorganisation complètes de l'ordre dans lequel sont fait les calculs, pour obtenir un calcul théoriquement plus long mais qui en fait permet un meilleur traitement en flux avec moins de valeur intermédiaires à stocker.
Mais si tu invente un compilateur capable de faire ça, tu va faire fortune.
J'évite au maximum d'optimiser et je préfère que ce soit le compilateur qui le fasse à ma place, mais il faut pas oublier qu'il a des limites...
Fait des manipulations de vecteurs et de matrices en Octave et en C et tu vas vite comprendre.
Tout ce que tu peut faire en Octave peut être fait en C bien sur, mais de manière bien plus complexe. L'avantage de Octave est que la notation est beaucoup plus proche des formules mathématiques que l'on écrit et est beaucoup plus concise. Elle donc bien plus facilement vérifiable.
Un exemple tout con, j'ai un décodage de Viterbi à un moment, une des opérations nécessaire consiste à prendre une matrice et pour chaque ligne, chercher la plus grande valeur. Il faut stocker pour chaque lignes, la valeur maximale et son indice.
En Octave, cela ce code val, idx = max(M') M étant la matrice en question, que l'on transpose et sur laquelle on appelle la fonction max. Elle retourne le vecteur val qui contient les valeurs maximales, et le vecteur idx qui contient les indices.
Maintenant en C, c'est beaucoup moins trivial. Bien sur, on peut utiliser des libs toutes faites, mais cela implique de stocker dde nombreuse valeurs intermédiaires, ce qui n'est pas possible dans notre cas vu la taille de tout ces éléments.
Il faut donc coder tout cela avec des boucles, en tenant compte du fait que les matrices sont stocker en column-major (car de manière globale pour les calculs que l'on fait, c'est l'ordre le plus pratique.
Donc pour éviter d'avoir des cache-miss en permanence il faut travail dans un ordre qui n'est pas spécialement logique, c'est-à-dire que l'on ne calcul pas le max d'une ligne puis le suivant, mais toutes les lignes en même temps. Ça permet d'avoir des patterns d'accès mémoire très prévisibles par le processeur et presque aucun cache-miss.
La version en Octave n'est absolument pas optimisée et construit explicitement en mémoire de nombreuses matrices intermédiaires et donc, est lente à mourir car, dès que les données deviennent un peu importantes, elle swap énormément.
Mais par contre, le code est très simple et parfaitement lisible car très proche de la description mathématique de l'algo et donc très facilement vérifiable.
La version en C est prévue pour stocker complètement aucune matrices intermédiaire, ce qui implique de travailler par blocs, donc des niveaux de boucles supplémentaire et du code pour gérer les limites entre blocs.
Donc cela donne très rapidement un code beaucoup plus dur à comprendre, mais plusieurs ordres de grandeurs plus rapide.
Pour donner une idée, la version octave ne peut gérer de manière réaliste des modèle de plus de 100000 éléments, là ou la version en C est encore loin de ses limites avec un modèle de 1.3 milliard d'éléments.
La version en Octave permet de valider l'algorithme et d'obtenir une implémentation de référence. Celle est C permet de travailler sur des données réelles dans des condition correcte avec des temps de calculs raisonnables.
Le code en C à été relu de nombreuse fois et possède de nombreuses vérifications, mais ce n'est pas suffisant pour être sur de sa validité. Ce genre de code est à peu près impossible à prouver, le meilleur outils que l'on a pour l'instant pour être à peu près sûr qu'il fait ce que l'on pense c'est de vérifier qu'il donne les même résultats qu'une autre implémentation indépendante qu'il elle est bien plus facilement vérifiable.
Bien sûr on est loin d'une preuve absolue, mais c'est le mieux que l'on puisse faire pour l'instant et c'est le prix à payer pour pouvoir travailler avec d'aussi gros modèles.
Je ne te fais pas de procès d'intention, je parle de la communauté Lisaac en général qui s'exprime sur ce site. Il est souvent très dur de vous faire admettre les limitations de Lisaac.
Il suffit de regarder ce journal pour comprendre ce dont je parle.
Pour répondre sur les assertions et ton problème d'erreur de signe. Tu peux trouver des erreurs d'équation en utilisant les propriétés mathématiques de ta fonction, par exemple, tu vérifies que l'opération reste transitive, reflexive, tu peux vérifier les éléments neutres, et autre propriété un peu poussé. Si tu codes une multiplication de matrice tu peux vérifier par exemple que ((A*B)*A)*B =A*((B*A)*B).
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
Le truc c'est que ça ne change rien au schmilblic. Pour les vérifs dont tu parle, il faut qu'il y en ais des propriétés testables et c'est pas toujours le cas.
Dans mon cas, c'est un algo itératif qui converge vers un optimum, l'opération en question était destinée à corriger certains comportements très particulier de l'algo dans des cas rares qui produisent une instabilité.
L'algo va quand même converger, mais sur certaines dimension il va osciller pendant plusieurs itérations avant de réussir à sortir de la configuration particulière.
Donc, les assertions qui vérifie que globalement on converge ne sont pas levées puisque l'on continue de converger. On converge beaucoup plus lentement mais on ne peut pas savoir que ça devrait être plus rapide.
Et on ne peut pas mettre d'assertions sur l'instabilité car ces un comportement qui ne peut être vérifié que sur un grand nombre d'itérations. Une instabilité sur deux ou trois itération c'est normal, sur plus d'une dizaine ça doit être corrigé. Et garder en mémoire les valeurs des dix dernière itération c'est tout simplement impossible.
Je ne vais pas rentrer dans les détails du système mais la vérification des propriétés n'est absolument pas une solution miracle, tout comme le debuggage à coup de log.
Il faut bien voir qu'il y a plein de manière de debugger et quelle sont toutes complémentaires. Dans mon cas, le programme en question c'est parfois plusieurs jours de calculs avec des problèmes qui ne se manifestent que sur de gros volumes de données et très difficiles à cibler, donc le debuggeur interactif, c'est pas vraiment gérable.
C'est des morceaux de code ou des vérifications complexes reviendrais à rajouter 4 fois plus de code que l'existant et qui donc contiendrais surement 4 fois plus de bugs.
Le coeur de l'algo fait en gros 400 lignes de C. C'est pas beaucoup mais ça reste très complexe à debugger. Tu rajoute à un peu plus d'une centaine de lignes de commentaires, et un peu moins de 200 lignes d'assertions.
Si je le transforme en Lisaac, du peu d'experience que j'ai dans ce langage, j'ai pas l'impression que le nombre de lignes de code va changer. C'est vraiment des math brutal, il y a rien du style allocation memoire ou autre. C'est juste des boucles, des if et des calculs.
La seule différence qu'il y aura ce sont les assertion qui deviennent des contrats, donc rien de plus facile pour debugger.
C'est même pire avec les contrats... Actuellement j'ai 6 types d'assertions différentes qui ne sont pas tous activés en même temps. Certains test sont peu couteux et peuvent rester en permanence, mais d'autre sont très couteux et ne sont activé que quand il y en as besoin, générallement sur des jeux de données petits ou avant le week-end.
A ma connaissance, ce genre de vérification sélective n'est pas simple à faire avec des contrats. C'est plus du tout ou rien.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
C'est bien beau tout ça, mais quand ? Ça à quand même l'air d'être pour dans longtemps. Ce n'est pas une critique mais ça veut dire que pour un gros projet c'es pas pour tout de suite, donc pour un gros projet Lisaac n'est pas adapté.
Je prend un autre exemple ou une compilation rapide est presque indispensable : un projet colaboratif ou la compilation commence à être longue.
Dans ce genre de projet, quand tu soumet un fonctionalité, la politesse veut que tu découpe ton gros patch en plusieurs petits patch progressif qui peuvent être testé un par un, et approuvé un par un. Pour la libdispatch par exemple, il y a eu un patch il y a peu découpé en 17 petits-patchs. Cela veut dire pour celui qui soumet 17 compilation pour vérifier à chaque fois que le patch marche bien donc beaucoup de temps s'il faut tout recompiler. Et autant de compilation pour tout ceux qui testent les patchs.
Sachant que génarallement il y a des remarques et des petites modifs à faire, c'est beaucoup de temps au final.
Et pourtant la libdispatch n'est pas un si gros projets que ça au final et des patch de ce genre son pas des cas rares.
Donc Lisaac a, à mon avis, un manque à ce niveau là. Encore une fois, ce n'est pas une critique du langage en lui-même, mais quand tu en parles, il faut accepter cette limitation et dire que ça changera, mais surtout admettre que au moins pour l'instant il n'est pas adapté.
Je serais curieux de voir le code pour comparer les 2 implémentations et voir le résultat, si il est disponible.
Hélas non, à l'époque ce n'était pas trop distribuable (toujours maintenant d'ailleurs) et je dois avouer que je n'ai pas garder les version Lisaac. C'était juste un essais pour tester le langage, pas vraiment comparer les perfs.
Jabber est un protocol de messagerie standard, ce qui n'implique absolument pas ue tous les logiciels qui l'implémentent doivent être libre, ni que les personnes chargée de la spécification doivent utiliser des logiciels libres.
Je n'ai absolument rien contre les logiciels propriétaire quand ils respectent ma liberté, c'est-à-dire dans un cas comme celui-ci :
- que je ne soit pas obligé de les utiliser ;
- qu'il utilisent des protocols standard, ouvert et dont l'implémentation est libre.
Donc ici, tu n'a aucune obligation d'utiliser leur serveur, tu peut sans problème passer à un autre serveur sans perdre tes contacts puisque le protocol est standard.
Je comprend qe ça puisse décevoir, mais les admins du site sont eux aussi libres et choisissent le serveur qu'ils veulent. Ce qui me ferait beaucoup plus peur, ce serais que des gros serveurs commence à implémenter des trucs non-standard et pas documenté.
Mais ce que j'aimerais bien savoir c'est les raisons de ce changement. Qu'est-ce que ce serveur propose de plus ? Est-ce pour des raisons techniques ou politique ?
Je me suis motivé et j'ai recherche dans mes notes. Bon en fait c'était pas bien dur... juste un grep dans le bon répertoire...
Le principal soucis était bien la gestion de la mémoire qui faisait que Lisaac ne pouvait pas traiter autant de donnée que la version en C. Apparement sur des jeux de données plus petit les perfs se raprochait un peu mais encore à l'avantage du C, sachant que ma version en Lisaac était loin d'être aussi optimisée que celle en C car je connais pas super bien lisaac par rapport au C.
J'avais noté que la syntaxe était globalement agréable à lire en dehors du coup des majuscules qui pour moi son un truc immonde, mais question de gouts.
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
Mais pour rester dans la discution en cours : « on en à rien à foutre »...
Peut-être que les contrats hérités de Lisaac ou autre sont mieux que les assertions, mais ça ne change pas le fait qu'ils ne détecterons pas les bugs qui me prennent le plus de temps à corriger et qui parfois nécéssitent des techniques de debuggage particulière telles que de multiple compilations avec génération de logs.
Donc on en reviens au même point, dire que la compilation par module n'est pas utile et vive les optimisations globales, c'est réducteur. Et, à mon avis, Lisaac n'est pour l'instant pas un bon choix de ce point de vue pour un gros projet.
On a ici un bon exemple de ce que j'ai du mal à apprécier dans les journeaux et news sur Lisaac et que j'ai éssayer plusieur fois d'expliquer. Si on prend le message de NB http://linuxfr.org/comments/1087340.html#1087340 il dit à propos de la compilation séparée :
«On ne le fera jamais. Cela ne sert à rien. On rend possible de faire un .o mais le but n'est pas d'en lier plusieurs mais sois de faire des plugin soit de se lier à du code autre.»
C'est un point de vue relativement tranché, auquel TIM répond par :
«Donc là t'es en train de dire à tous les utilisateurs :
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.»
C'est une réponse un peu provocante mais qui n'a rien de particulier dans ce journal, ils donne des cas ou l'on a envie de faire de la compilation séparée. Ce qu'on peut lui reprocher c'est de ne pas vraiment détailler pourquoi on veut une compilation séparée.
Mais NB montre qu'il a bien compris le problème quand on voit sa réponse, donc pas de problème de clartée :
«Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.»
C'est encore très tranché. Et surtout un détail qui m'avait échapé, il dit que lisaac se compile en quelques secondes mais que GCC fait ramer le tout. Donc en gros lisaac c'est plus que quelques secondes de compilation... C'est quelques minutes pour un «petit» programme de 50kloc. Sur un gros projets ça va devenir ingérable.
Et il ajoute : «les bugs sont attrapé par le compilo en majorité.» à quoi je lui répond que tout les bugs ne peuvent pas être attrapé de cette manière.
Et la ça dérape, avec quelques messages pour montrer que sur un gros projets une compilation globale c'est pas gérable dans tous les cas, et expliquer qu'il y a des bug que l'on ne peut pas débugger sans refaire plusieurs compilation, on obtient comme réponses à côté de la plaque.
NB admet quand même que «C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.»
Sauf que quelques minute peu devenir une heure ou plus sur un gros projet, et on a l'impression qu'il admet plus qu'il ne faut pas faire du debuggage test/erreur même s'il n'y a que ça de possible.
Ensuite, après avoir détailler le cas d'exemple pour mieux faire comprendre, on se prend encore une réponse qui n'a rien à voir avec le shmilblic suivit de :
«Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".»
La c'est de la mauvaise foi. On dit que pour un gros projet, avec une compilation longue c'est un problème, et on me répond que pour un autre projet, bien plus petit, la compilation est rapide !!!
Si je vais voir un vendeur en lui disant «les pommes que vous m'avez vendues sont pourries» il ne vas pas me répondre «oui mais mes poires que j'ai vendue à votre voisin ne le sont pas». On s'en fou que lisaac ce compile super vite, nous on va le compiler au pire une fois, alors que notre projet qu'on doit débugger et qui prend une heure à compiler, on va devoir le faire plusieur fois par jour peut-être.
Il y a une petite lueur d'espoir apres. Alors que le fil est partit d'une affirmation comme quoi la compilation séparée ne sert à rien et date de la préhistoire, on obtient un :
«A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.»
On se dit que peut-être sur ce cas, un jour ça marchera. Mais en même temps, on nous dit souvent qu'il est domage qu'il n'y ait pas plus de gens à dévelloper en lisaac... Moi, ça ne me donne pas envie.
Et la tu arrive pour me dire que «oui mais, au lieu de mettre des assertions, tu met des contrats hérité, c'est bien mieux»
Sauf que ça n'a aucun rapport... Les bugs que l'on peut détecter par contrat on peut aussi les détecter par assertion. Au pire je vais oublier de mettre une assertion et ton héritage la met automatiquement. Mais ça ne change rien au problème des bugs qui ne peuvent pas être détecter avec c'est méthodes.
C'est super les contrats pour vérifier les bornes ou les invariants ou autres, mais ça ne marche pas pour tout. Je me suis fait chiez à expliquer un exemple ou il n'y a pas vraiment l choix et ou un contrat qu'il soit hériter ou pas ne change rien.
Ça donne vraiment l'impression classique des discution autour de lisaac avec sa communauté. Quand on montre un problème lié à Lisaac, ça commence par une levée de bouclier dans le genre «Lisaac c'est génial, nous on fait les chose bien les autres le font mal» et ensuite si on réussit à montrer que vous avez tord, on arrive parfois à vous arrachez un petit «tu as peut-être vaguement raison dans un univers parallel» et le plus souvent on à le droit à un «mais nous on a ce truc qui n'a rien à voir et qui ne résoud pas ton problème mais qui est vachement cool».
Je suis désolé, mais moi ça ne me donne pas envie. C'est pourtant pas compliqué d'expliqué que «pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets».
Ensuite soit tu rajoute «on admet le problème mais notre cible actuelle est les projets de taille raisonable qui ne sont pas génés par cela» ou «on y réfléchit et ce sera implémenter dans le futur».
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
PS: Je ne prétend pas détenir la vérité absolue et j'admet que ce que je dis dans ce message est mon interprétation de ce qui c'est dit ici. Mais si j'ai mal interpreté vos propos, je ne suis peut-être pas le seul, et si Lisaac est autant un sujet à troll c'est peut-être que l'on est nombreux à pas vous comprendre correctement.
Ce qui me gène avec ce site c'est le FLAC qu'ils proposent. Pour quasimenttous les morceaux, le FLAC n'est pas issus du master orignal ou d'un master qualité CD mais proviens juste d'un réencodage d'un fichier compresser dans un format à perte.
Je n'ai rien contre le fait de réencoder en FLAC, c'est stupide mais ils font ce qu'ils veulent. Ce que je critique c'est le fait que ce ne soit pas clair sur leur site. Il y a quelques temps en tout cas, lorsque l'on achetait un album en FLAC chez eux, c'était très difficile de savor quelle était la qualitée réelle de ce que l'on achetait.
Il y a des morceaux ou ça passe, mais il y en as ou c'est une veritable catastrophe. Je comprend qu'ils font avec ce que les maison de disque leur filent, mais vendre du FLAC dans cet état, je trouve que ça frise parfoit l'escrocrie. Je me serais fait avoir si je n'avais pas déjà eu le cas avec un autre site de vente en ligne qui avait le même genre de pratique mais sans aucune indication du réencodage.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
J'en ai rien a battre puisque comme je te le dit ce genre d'erreur est détecter rapidos par les assertion et ne représente qu'une fraction minime du temps de debuggage.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
Principalement la notion vectorielle et les fonction de manipulation des matrice de haut niveau. Mais on s'en fout ici. Le truc c'est que j'ai une version de référence et que je veut comparer mon programe à cette référence et que vu les volumes de données, la seule solution raisonable ici, est de sortir des logs ce qui impose des recompilations.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure.
Encore completement à côtè de la plaque, je t'explique qu'il y a des projet ou il faut 1h voir plus pour tout compiler et seulement une ou deux minutes quand on fait de la compilation modulaire. Et toi tu me répond que tu en as rien a battre de leur gueule car ton compilo ce compile en quelques minutes.
Tu crois vraiment que tu me donne envie d'écrire un gros projet en Lisaac : «oui, bonjour monsieur. en effet votre programe prend 2h a compiler pour une modif d'une ligne, mais ce n'est pas grave, le compilateur qui est aussi lent ce compile lui en moins de 2minutes sur le processeur de votre montre.»
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
Tu finis par avouer que c'est quand même pas mal d'avoir de la compilation modulaire... Le truc c'est que «un jour» c'est trop tard pour un projet qui démare maintenat, donc faut pas venir ce plaindre que personne veut utiliser votre langage.
[^] # Re: jobq
Posté par beagf (site web personnel) . En réponse au message Logiciel de Batch tout simple. Évalué à 1.
Le seul soucis sera de répartir correctement les tâches pour que chaque queue est glabalement la même durée totale.
Merci beaucoup pour le lien.
[^] # Re: sh ?
Posté par beagf (site web personnel) . En réponse au message Logiciel de Batch tout simple. Évalué à 2.
C'est le genre de programme qui peut devenir vite chiant a débugger si on veut être sûr que ça marche bien. (et pour lancer 400 jobs avant les vacances, il y pas intéret à ce que ça plante deux aprés une foi que je suis dans le train sans acces au net...)
Si vraiment je ne trouve rien, je m,y résoudrais, mais j'éspère que quelqu'un à déjà fait le boulot.
[^] # Re: man taskset
Posté par beagf (site web personnel) . En réponse au message Logiciel de Batch tout simple. Évalué à 1.
Je me tape de savoir sur quel proc la commande est executée. Linux fait tres bien sont boulot a ce niveau. Si je lance 8 commandes en même temps, les 8 proc seront utiliser en même temps.
Le problemes c'est que j'ai 400 commandes a lancer, et que je ne peut les lancer que 8 à la fois. Tout ce qu'il me faut c'est un programme qui surveille ces 8 programme et qui, quand un ce termine, lance le suivant.
[^] # Re: Avocats du diable
Posté par beagf (site web personnel) . En réponse au journal Des « flashcodes » propriétaires sur les arrêts de bus. Évalué à 5.
Ils gèrent la redirection comme ils le veulent, pour la mise en place, un stagiaire pendant une semaine leur fait tous le bousin, avec une interface similaire à celle du prestataire actuel.
Comme ça le temps pour faire une modif est le même voir inferieur a la situation actuelle mais avec un coût quasiment nul.
Si seulement les décision n'était pas prise par des gens qui ni connaissent rien conseillés par des commerciaux.
[^] # Re: C'est les Beatles qu'on assassine
Posté par beagf (site web personnel) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 2.
Je n'ai fait ces test que pour bien montrer que le travail qui à été fait sur ceux des Beattles est de très bonne qualitée contrairement à ce qu'indiquait Aurélien Girard.
[^] # Re: C'est les Beatles qu'on assassine
Posté par beagf (site web personnel) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 8.
J'ai récupéré l'album hier soir et j'ai pus l'écouter et faire quelques éssais. Eh bien, après écoute, je dois avouer qu'à mon avis ce que tu as entendu ça ne devait pas être le même album. Tu es sur qu'on ne t'a pas fait écouter un mp3 regraver sur un CD ?
Parce que bon, à l'oreille, ça doit être un des meilleurs de tous ceux que j'ai de la série. En même temps c'est loin d'être mon préféré donc je suis surement moins éxigent que avec certains autres, mais quand même. Le son de «Wild Honey Pie» est d'un clarté presque magique, «Blackbird» est d'une propretée étonante quand on voit le premier master CD et je parle pas de «Piggies». Il est remonté de quelques place dans ma liste d'achats, un vrai bonheur ce CD.
Mais bon, en même temps je vous demande pas de faire confiance à mon oreille, surtout que j'ai tendance à me contretaper des mauvais résultats théoriques si le disque me plait. Mais bon, j'ai lancer le sujet en disant que je n'était pas d'acord avec ti sur la qualité de ces remaster, donc je vais argumenter avec autre chose que du subjectif.
Donc du côté objectif, j'ai rippé le CD avec cdparanoia en mode le plus paranoiaque et bien vérifié qu'il m'indiquait aucune erreur ou problème et j'ai ensuite analysé les fichiers avec audacity. J'ai fais des captures d'écrans de tous les morceaux du CD pour ceux qui ne l'on pas et qui veulent qand même voir ce que cela donne (http://nosys.oniros.org/beattles/ ).
Ce qu'on peut voir sur ces captures onfirme mon impréssion, on a pas de problème de compression dynamique ici. Les morceaux sont un peu plus masteriser un peu plus fort que ceux de 1987 mais sans qu'il n'y ait de perte. Et ce n'est pas un problème. À l'époque des vinyles et des cassettes, le support faisait que l'on obtenait la meilleur qualité en masterisant plus bas que les limittes du support pour éviter la plage limite. Un bon master à l'époque devait donc être suffisament fort pour avoir une bonne dynamique mais suffisament faible pour ne pas être dégradé.
De nos jour on à plus ce problème là grace au numérique, donc sur un support comme les CD, l'idéal est de masteriser pour que les morceaux soient calés au plus près des limiteset donc ainsi bénéficié de la plus grace plage de dynamique possible. Ce qui est le cas sur ce CD.
On peut voir que le morceaux qui est calé au plus juste est «While My Guita Weeps» qui donne même l'impression d'être écretté, pourtant en y regardant de plus près on voit que c'est pas si sûr. S'il à perdu quelque chose, c'est vraiment minime et uniquement en 4 ou 5 point du morceaux, et honêtement, à l'oreille, même en sachant ou son les perte éventuelles, je suis bien incapable d'entendre quoi que ce soit.
Les autres morceaux sont tous calés pour être homogène avec celui là, et je pense qu'il doit y avoir un ajustement global sur l'ensemble des albums.
Pour ceux que ça amuse, vous pouvez regrdez l'ensemble des morceaux, on voit bien la forte disymétrie entre les deux canneaux stéréo qui est relativement typique de cette époque ou le véritable enregistrement et le mixage avec les artiste ce faisait en mono et ou la version stéréo, quand elle existait, était préparé plus tard avec ce que l'on pouvait...
Et pour ce qui est de la dynamique en chiffres, on dépasse facilement les -12db d'amplitude, donc on est largement dans les bon vieux standards et pas dans les bouse infames qu'ils nous sortent maintenant et qui on du mal à atteindre les -3 ou -4db.
Donc pour conclure, cet album (comme les autres de la série que j'ai pus écouter) est excelent, et honetement je ne vois pas comment ils aurraient pus faire mieux. Mais je suis ouvert à tout commentaire et critiques.
[^] # Re: C'est les Beatles qu'on assassine
Posté par beagf (site web personnel) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 2.
[^] # Re: Intérêt?
Posté par beagf (site web personnel) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 3.
Dans la pratique, toutes les radio et autre ce sont adapté à cette débilité et normalisent les musiques avant de les passer.
Donc au final ça ne sert qu'à une chose : réduire la qualitée...
[^] # Re: C'est les Beatles qu'on assassine
Posté par beagf (site web personnel) . En réponse au journal Un article sur la compression sonore (compression de la dynamique). Évalué à 4.
Parceque pour avoir écouté, aussi bien les anciens que les remaster, je les trouvent très bons. J'ai pas l'album blanc sous la main, je ne les ai pas tous acheter, mais sur un test rapide sur deux autres de la collection remaster sortis à la fin de l'année dernière il n'y a aucun problème.
En ouvrant dans audacity un rip fai en mode paranoia on peut voir du premier coup d'oeil que l'on est très loin des bouses de ces dernières années. Il n'y a pas de compression de la dynamique et on peut voir que les pics sont très prècis, ce qui confirme mon impression à l'oreille.
Donc, à moins que l'album blanc soit une exception dans la série des remaster, ce qui m'ètonnerais, tu n'as pas du bien l'écouter, ou ce n'était pas les dernier remasters. Je vois un pote qui l'a ce week end, je ferais le test pour être sur.
Pour une fois qu'ils nous font de bon remasters, on va éviter de cracher dessus.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Tout-à-fait, désolé j'avais oublié le lien.
Le 1er guide est un must-read pour toute personne qui veut optimiser son code serieusement plutôt qu'avec les recette de sa grand-mère.
Le 3ème est aussi très intéressant pour les optimisations de haut niveau notament la partie sur la prédiction de branchement. Comprendre ce qui ce passe dans le processeur est un énorme atout pour l'optimisation plus hardcore.
Il y a bien longtemps que je n'ai pas écrit d'assembleur, par contre je lit très souvent le code produit par le compilateur pour voir ce qu'il produit et chercher ce que je pourrais faire pour l'aider à mieux comprendre ce que je veux et l'aider à écrire du meilleur code.
Le 5 est à feuilleter une fois juste pour bien voir ce que coute chaque paramètres lors d'un appel, mais ça reste négligeable. Globalement c'est pas vraiment là qu'il y a gagner. La plupart des optimisation la dessus rendent le code bien moins lisible et pas vraiment plus rapide.
Le 2 et le 4 sont, pour moi, intéressant uniquement pour l'utilisation des instruction SIMD via les intrinsics. Ils seront très utile à des personnes qui écrive des compilateurs mais ce n'est plus mon cas.
Ce qui me sert le plus ce sont les timing des instructions SIMD pour justement tous les cas ou GCC ne pourra rien faire.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je disais juste qu'a mon avis certaines optimisation font bien plus de mal qu'autre chose, au moins pour l'instant. Pourquoi vouloir faire très compliqué, risqué et peu-utile en général, quand il y a moyen de faire compliqué, moins risqué et très utile ?
Contrairement à ce que tu dis, faire mieux que gcc en matière de vectorisation n'est pas si complexe (tout est relatif bien sur....)
Le langage C est tel qu'il est difficilement vectorisable automatiquement, à cause des pointeurs ou de la sémantique complexe de certaines constructions notamment. Les boucles vectorisable doivent avoir des formes simples et correspondre aux motif connus, ce qui rend l'écriture de ces boucles généralement difficiles.
En Lisaac par contre, il y a beaucoup moins d'ambigüité et bien plus de sémantique dans les constructions, donc la vectorisation est plus simple. Que ce soit juste réécrire les boucles pour que gcc puisse les optimiser ou utiliser les intrinsics ça reste quand même bien plus profitable.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je parlais de cela dans le sens ou Lisaac ne sera pas capable de produire d'autres forme de vectorisations que celle que gcc gère, et il est très contraint par les formes reconnues par gcc, don pas trop d'imbrication de ces boucles et de combinaison simples.
J'ai citer ce type d'optimisation car je pense que c'est bien plus profitable que d'essayer (et à mon avis de rater, vu la difficultée) de faire automatiquement les optimisation que j'ai fait à la main. Et je pensais plutôt à la possibilité d'utiliser les intrinsics pour les cas ou lisaac peut vectoriser mais ne peut pas transmettre l'optimisation à gcc. (désactivable bien sur)
Ce n'était pas une critique du fait que lisaac est limité au c89, plutôt une remarque sur cette limitation et le fait qu'optionellement lever cette restriction permettrait de faire des optimisations bien profitable que ce que nicolas proposait.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Je ne mélange pas tout, je dit juste que, à mon avis, si votre objectif est de produire du code rapide, il faut mettre des priorités sur les optimisation à implémenter, et si ce n'est pas votre objectif, ça ne sert à rien de continuer la discution.
Implémenter des optimisation extrêmement complexes de ce type c'est prendre le risque d'introduire des erreurs dans le code généré et de rendre le compilateur très complexe pour des cas relativement rare.
Par contre la vectorisation, bien que complexe, à fait l'objet de bien plus de recherche et va s'appliquer dans beaucoup plus de cas. Donc moin de risque pour un plus gros gain. Il me semble plus pertinent de commencer par la.
Et donc je soulevais le problème du fait que Lisaac pour l'instant produit du code c89 donc la vectorisation n'est pas directement possible.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Lisaac à une vision plus haut niveau du code, à mon avis il doit y avoir plein de cas ou gcc ne peut pas vectoriser le code mais ou lissac possède lui les informations pour le faire.
Même si gcc est très bon pour ce genre de choses, les motifs qu'il est capable de paralléliser restent très limités, et bien souvent il suffit qu'il y ait un pointeur qui traine pour tout foutre en l'air. Dans la pratique, écrire du code que gcc peut paralléliser est souvent au moins aussi complexe que d'écrire directement le code parallèle avec les intrinsics. Et le plus embêtant c'est que la moindre petite modification anodine peut rendre le code non parallélisable, donc un patch par quelqu'un qui ne fait pas super gaffe peut-être catastrophique.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Le problème c'est qu'optimiser pour le cache est à double tranchant. Il y a trois cas à considérer :
- tu as la bonne taille pour remplir exactement le cache comme il faut et le code est très rapide ;
- tu as exactement la bonne taille pour que le cache soit pourit à mort, et la tu as un code affreusement lent ;
- le reste ou tu as une quantité classique de cache miss et un code de vitesse normale.
Et mon experience à ce niveau la me fait dire que quand tu ne fais rien de spécial, tu est à peu près toujours dans le cas 3, mais des que tu cherche à faire des trucs un peu intelligent tu tombe le plus souvent dans le cas 2 et il faut faire pas mal d'essais avec différentes tailles pour réussir à tomber dans le cas 1.
Donc si tu ne connais pas la taille du cache, il vaut mieux ne rien faire, et si tu connais la taille du cache, trouver la bonne taile pour tes blocs est souvent possible uniquement de manière empirique.
Je suis loin d'etre persuader qu'un compilateur puisse le faire automatquement avant un bon bout de temps, les éléments à prendre en compte sont tellement nombreux et différents dans chaque cas. Pour plus d'infos tu peut regarder les manuels d'optimisation d'agner qui décrit bien le problème.
[^] # Re: Retour vers le libre ? peut-être pas.....
Posté par beagf (site web personnel) . En réponse à la dépêche L'envolée de Thunderbird dans l'administration française. Évalué à 6.
Quand on parle d'exchange et d'outlook, j'ai plutôt tendance, personnellement, à parler de galèratique ou de catastrophatique...
ok ~~~~~~~~~~~~~~~>[ ]
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je ne veut pas être méchant, mais avant de songer à ce genre d'optimisation, qui ont l'inconvénient d'être à la fois extrêmement complexe à implémenter sans faire de conneries et applicable dans très peu de cas, il faudrait peut-être trouver une solution pour des optimisations plus utiles.
La vectorisation du code est généralement beaucoup plus efficace que l'optimisation des caches car la majorité du code accède à la mémoire avec des motifs facilement identifiables par le processeur. À par sur des cas précis comme celui-là, j'ai rarement recours à ce genre de techniques. En plus le code est spécifique à un modèle de processeur car la taille des blocs doit être choisie en fonction de la taille des lignes de cache.
Par contre la vectorisation du code apporte généralement beaucoup plus et surtout s'applique dans bien plus de cas. Et coup de bol, il y a moyen de ce comparer à d'autre compilateurs et il y a même des benchs qui trainent sur le net.
Mais la on tombe sur une limitation de Lisaac, le fait de générer du C89 à l'avantage d'être portable mais empêche tout optimisation de ce côté, vous êtes obligé de croisé les doigts pour que le compilateur C en dessous réussisse à faire ce boulot.
C'est vraiment dommage que ton code soit fermé. Cela aurait fait une bonne référence, pour un bench pour voir l'effet d'optimisation.
On choisit pas toujours ce que l'on peut faire de son code... Mais si ça peut te faire plaisir une version plus simple du code devrait être disponible dans quelques temps, mais pas en Lisaac, juste en C.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le problème est que ce n'est pas réalisable pas plus qu'un compilateur qui prend l'algo en Octave et qui me pond un programme aussi rapide et peu gourmand en mémoire que ma version en C.
Un bon compilateur pourrait éventuellement s'apercevoir que certains vecteurs et matrice intermédiaires n'on pas à être conservé et factoriser le code. Pour d'autre endroits, il pourrait voir que tous les traitement sont indépendants et donc paralleliser le code ou faire du striping.
Mais, il sera incapable de gérer tous les cas que j'ai eu à résoudre ici, notament les calculs qui permettent de gérer les valeurs au limites des blocs, ou il faut réellement inventer la manière de faire le calcul, elle n'est pas dans le code pour octave. Ou encore des réorganisation complètes de l'ordre dans lequel sont fait les calculs, pour obtenir un calcul théoriquement plus long mais qui en fait permet un meilleur traitement en flux avec moins de valeur intermédiaires à stocker.
Mais si tu invente un compilateur capable de faire ça, tu va faire fortune.
J'évite au maximum d'optimiser et je préfère que ce soit le compilateur qui le fasse à ma place, mais il faut pas oublier qu'il a des limites...
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 5.
Tout ce que tu peut faire en Octave peut être fait en C bien sur, mais de manière bien plus complexe. L'avantage de Octave est que la notation est beaucoup plus proche des formules mathématiques que l'on écrit et est beaucoup plus concise. Elle donc bien plus facilement vérifiable.
Un exemple tout con, j'ai un décodage de Viterbi à un moment, une des opérations nécessaire consiste à prendre une matrice et pour chaque ligne, chercher la plus grande valeur. Il faut stocker pour chaque lignes, la valeur maximale et son indice.
En Octave, cela ce code
val, idx = max(M')M étant la matrice en question, que l'on transpose et sur laquelle on appelle la fonction max. Elle retourne le vecteur val qui contient les valeurs maximales, et le vecteur idx qui contient les indices.Maintenant en C, c'est beaucoup moins trivial. Bien sur, on peut utiliser des libs toutes faites, mais cela implique de stocker dde nombreuse valeurs intermédiaires, ce qui n'est pas possible dans notre cas vu la taille de tout ces éléments.
Il faut donc coder tout cela avec des boucles, en tenant compte du fait que les matrices sont stocker en column-major (car de manière globale pour les calculs que l'on fait, c'est l'ordre le plus pratique.
Donc pour éviter d'avoir des cache-miss en permanence il faut travail dans un ordre qui n'est pas spécialement logique, c'est-à-dire que l'on ne calcul pas le max d'une ligne puis le suivant, mais toutes les lignes en même temps. Ça permet d'avoir des patterns d'accès mémoire très prévisibles par le processeur et presque aucun cache-miss.
La version en Octave n'est absolument pas optimisée et construit explicitement en mémoire de nombreuses matrices intermédiaires et donc, est lente à mourir car, dès que les données deviennent un peu importantes, elle swap énormément.
Mais par contre, le code est très simple et parfaitement lisible car très proche de la description mathématique de l'algo et donc très facilement vérifiable.
La version en C est prévue pour stocker complètement aucune matrices intermédiaire, ce qui implique de travailler par blocs, donc des niveaux de boucles supplémentaire et du code pour gérer les limites entre blocs.
Donc cela donne très rapidement un code beaucoup plus dur à comprendre, mais plusieurs ordres de grandeurs plus rapide.
Pour donner une idée, la version octave ne peut gérer de manière réaliste des modèle de plus de 100000 éléments, là ou la version en C est encore loin de ses limites avec un modèle de 1.3 milliard d'éléments.
La version en Octave permet de valider l'algorithme et d'obtenir une implémentation de référence. Celle est C permet de travailler sur des données réelles dans des condition correcte avec des temps de calculs raisonnables.
Le code en C à été relu de nombreuse fois et possède de nombreuses vérifications, mais ce n'est pas suffisant pour être sur de sa validité. Ce genre de code est à peu près impossible à prouver, le meilleur outils que l'on a pour l'instant pour être à peu près sûr qu'il fait ce que l'on pense c'est de vérifier qu'il donne les même résultats qu'une autre implémentation indépendante qu'il elle est bien plus facilement vérifiable.
Bien sûr on est loin d'une preuve absolue, mais c'est le mieux que l'on puisse faire pour l'instant et c'est le prix à payer pour pouvoir travailler avec d'aussi gros modèles.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
Il suffit de regarder ce journal pour comprendre ce dont je parle.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 4.
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
Le truc c'est que ça ne change rien au schmilblic. Pour les vérifs dont tu parle, il faut qu'il y en ais des propriétés testables et c'est pas toujours le cas.
Dans mon cas, c'est un algo itératif qui converge vers un optimum, l'opération en question était destinée à corriger certains comportements très particulier de l'algo dans des cas rares qui produisent une instabilité.
L'algo va quand même converger, mais sur certaines dimension il va osciller pendant plusieurs itérations avant de réussir à sortir de la configuration particulière.
Donc, les assertions qui vérifie que globalement on converge ne sont pas levées puisque l'on continue de converger. On converge beaucoup plus lentement mais on ne peut pas savoir que ça devrait être plus rapide.
Et on ne peut pas mettre d'assertions sur l'instabilité car ces un comportement qui ne peut être vérifié que sur un grand nombre d'itérations. Une instabilité sur deux ou trois itération c'est normal, sur plus d'une dizaine ça doit être corrigé. Et garder en mémoire les valeurs des dix dernière itération c'est tout simplement impossible.
Je ne vais pas rentrer dans les détails du système mais la vérification des propriétés n'est absolument pas une solution miracle, tout comme le debuggage à coup de log.
Il faut bien voir qu'il y a plein de manière de debugger et quelle sont toutes complémentaires. Dans mon cas, le programme en question c'est parfois plusieurs jours de calculs avec des problèmes qui ne se manifestent que sur de gros volumes de données et très difficiles à cibler, donc le debuggeur interactif, c'est pas vraiment gérable.
C'est des morceaux de code ou des vérifications complexes reviendrais à rajouter 4 fois plus de code que l'existant et qui donc contiendrais surement 4 fois plus de bugs.
Le coeur de l'algo fait en gros 400 lignes de C. C'est pas beaucoup mais ça reste très complexe à debugger. Tu rajoute à un peu plus d'une centaine de lignes de commentaires, et un peu moins de 200 lignes d'assertions.
Si je le transforme en Lisaac, du peu d'experience que j'ai dans ce langage, j'ai pas l'impression que le nombre de lignes de code va changer. C'est vraiment des math brutal, il y a rien du style allocation memoire ou autre. C'est juste des boucles, des if et des calculs.
La seule différence qu'il y aura ce sont les assertion qui deviennent des contrats, donc rien de plus facile pour debugger.
C'est même pire avec les contrats... Actuellement j'ai 6 types d'assertions différentes qui ne sont pas tous activés en même temps. Certains test sont peu couteux et peuvent rester en permanence, mais d'autre sont très couteux et ne sont activé que quand il y en as besoin, générallement sur des jeux de données petits ou avant le week-end.
A ma connaissance, ce genre de vérification sélective n'est pas simple à faire avec des contrats. C'est plus du tout ou rien.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
C'est bien beau tout ça, mais quand ? Ça à quand même l'air d'être pour dans longtemps. Ce n'est pas une critique mais ça veut dire que pour un gros projet c'es pas pour tout de suite, donc pour un gros projet Lisaac n'est pas adapté.
Je prend un autre exemple ou une compilation rapide est presque indispensable : un projet colaboratif ou la compilation commence à être longue.
Dans ce genre de projet, quand tu soumet un fonctionalité, la politesse veut que tu découpe ton gros patch en plusieurs petits patch progressif qui peuvent être testé un par un, et approuvé un par un. Pour la libdispatch par exemple, il y a eu un patch il y a peu découpé en 17 petits-patchs. Cela veut dire pour celui qui soumet 17 compilation pour vérifier à chaque fois que le patch marche bien donc beaucoup de temps s'il faut tout recompiler. Et autant de compilation pour tout ceux qui testent les patchs.
Sachant que génarallement il y a des remarques et des petites modifs à faire, c'est beaucoup de temps au final.
Et pourtant la libdispatch n'est pas un si gros projets que ça au final et des patch de ce genre son pas des cas rares.
Donc Lisaac a, à mon avis, un manque à ce niveau là. Encore une fois, ce n'est pas une critique du langage en lui-même, mais quand tu en parles, il faut accepter cette limitation et dire que ça changera, mais surtout admettre que au moins pour l'instant il n'est pas adapté.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Hélas non, à l'époque ce n'était pas trop distribuable (toujours maintenant d'ailleurs) et je dois avouer que je n'ai pas garder les version Lisaac. C'était juste un essais pour tester le langage, pas vraiment comparer les perfs.
# Question de point de vue
Posté par beagf (site web personnel) . En réponse au journal jabber.org quitte le libre ?. Évalué à 10.
Je n'ai absolument rien contre les logiciels propriétaire quand ils respectent ma liberté, c'est-à-dire dans un cas comme celui-ci :
- que je ne soit pas obligé de les utiliser ;
- qu'il utilisent des protocols standard, ouvert et dont l'implémentation est libre.
Donc ici, tu n'a aucune obligation d'utiliser leur serveur, tu peut sans problème passer à un autre serveur sans perdre tes contacts puisque le protocol est standard.
Je comprend qe ça puisse décevoir, mais les admins du site sont eux aussi libres et choisissent le serveur qu'ils veulent. Ce qui me ferait beaucoup plus peur, ce serais que des gros serveurs commence à implémenter des trucs non-standard et pas documenté.
Mais ce que j'aimerais bien savoir c'est les raisons de ce changement. Qu'est-ce que ce serveur propose de plus ? Est-ce pour des raisons techniques ou politique ?
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le principal soucis était bien la gestion de la mémoire qui faisait que Lisaac ne pouvait pas traiter autant de donnée que la version en C. Apparement sur des jeux de données plus petit les perfs se raprochait un peu mais encore à l'avantage du C, sachant que ma version en Lisaac était loin d'être aussi optimisée que celle en C car je connais pas super bien lisaac par rapport au C.
J'avais noté que la syntaxe était globalement agréable à lire en dehors du coup des majuscules qui pour moi son un truc immonde, mais question de gouts.
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Peut-être que les contrats hérités de Lisaac ou autre sont mieux que les assertions, mais ça ne change pas le fait qu'ils ne détecterons pas les bugs qui me prennent le plus de temps à corriger et qui parfois nécéssitent des techniques de debuggage particulière telles que de multiple compilations avec génération de logs.
Donc on en reviens au même point, dire que la compilation par module n'est pas utile et vive les optimisations globales, c'est réducteur. Et, à mon avis, Lisaac n'est pour l'instant pas un bon choix de ce point de vue pour un gros projet.
On a ici un bon exemple de ce que j'ai du mal à apprécier dans les journeaux et news sur Lisaac et que j'ai éssayer plusieur fois d'expliquer. Si on prend le message de NB http://linuxfr.org/comments/1087340.html#1087340 il dit à propos de la compilation séparée :
«On ne le fera jamais. Cela ne sert à rien. On rend possible de faire un .o mais le but n'est pas d'en lier plusieurs mais sois de faire des plugin soit de se lier à du code autre.»
C'est un point de vue relativement tranché, auquel TIM répond par :
«Donc là t'es en train de dire à tous les utilisateurs :
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.»
C'est une réponse un peu provocante mais qui n'a rien de particulier dans ce journal, ils donne des cas ou l'on a envie de faire de la compilation séparée. Ce qu'on peut lui reprocher c'est de ne pas vraiment détailler pourquoi on veut une compilation séparée.
Mais NB montre qu'il a bien compris le problème quand on voit sa réponse, donc pas de problème de clartée :
«Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.»
C'est encore très tranché. Et surtout un détail qui m'avait échapé, il dit que lisaac se compile en quelques secondes mais que GCC fait ramer le tout. Donc en gros lisaac c'est plus que quelques secondes de compilation... C'est quelques minutes pour un «petit» programme de 50kloc. Sur un gros projets ça va devenir ingérable.
Et il ajoute : «les bugs sont attrapé par le compilo en majorité.» à quoi je lui répond que tout les bugs ne peuvent pas être attrapé de cette manière.
Et la ça dérape, avec quelques messages pour montrer que sur un gros projets une compilation globale c'est pas gérable dans tous les cas, et expliquer qu'il y a des bug que l'on ne peut pas débugger sans refaire plusieurs compilation, on obtient comme réponses à côté de la plaque.
NB admet quand même que «C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.»
Sauf que quelques minute peu devenir une heure ou plus sur un gros projet, et on a l'impression qu'il admet plus qu'il ne faut pas faire du debuggage test/erreur même s'il n'y a que ça de possible.
Ensuite, après avoir détailler le cas d'exemple pour mieux faire comprendre, on se prend encore une réponse qui n'a rien à voir avec le shmilblic suivit de :
«Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".»
La c'est de la mauvaise foi. On dit que pour un gros projet, avec une compilation longue c'est un problème, et on me répond que pour un autre projet, bien plus petit, la compilation est rapide !!!
Si je vais voir un vendeur en lui disant «les pommes que vous m'avez vendues sont pourries» il ne vas pas me répondre «oui mais mes poires que j'ai vendue à votre voisin ne le sont pas». On s'en fou que lisaac ce compile super vite, nous on va le compiler au pire une fois, alors que notre projet qu'on doit débugger et qui prend une heure à compiler, on va devoir le faire plusieur fois par jour peut-être.
Il y a une petite lueur d'espoir apres. Alors que le fil est partit d'une affirmation comme quoi la compilation séparée ne sert à rien et date de la préhistoire, on obtient un :
«A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.»
On se dit que peut-être sur ce cas, un jour ça marchera. Mais en même temps, on nous dit souvent qu'il est domage qu'il n'y ait pas plus de gens à dévelloper en lisaac... Moi, ça ne me donne pas envie.
Et la tu arrive pour me dire que «oui mais, au lieu de mettre des assertions, tu met des contrats hérité, c'est bien mieux»
Sauf que ça n'a aucun rapport... Les bugs que l'on peut détecter par contrat on peut aussi les détecter par assertion. Au pire je vais oublier de mettre une assertion et ton héritage la met automatiquement. Mais ça ne change rien au problème des bugs qui ne peuvent pas être détecter avec c'est méthodes.
C'est super les contrats pour vérifier les bornes ou les invariants ou autres, mais ça ne marche pas pour tout. Je me suis fait chiez à expliquer un exemple ou il n'y a pas vraiment l choix et ou un contrat qu'il soit hériter ou pas ne change rien.
Ça donne vraiment l'impression classique des discution autour de lisaac avec sa communauté. Quand on montre un problème lié à Lisaac, ça commence par une levée de bouclier dans le genre «Lisaac c'est génial, nous on fait les chose bien les autres le font mal» et ensuite si on réussit à montrer que vous avez tord, on arrive parfois à vous arrachez un petit «tu as peut-être vaguement raison dans un univers parallel» et le plus souvent on à le droit à un «mais nous on a ce truc qui n'a rien à voir et qui ne résoud pas ton problème mais qui est vachement cool».
Je suis désolé, mais moi ça ne me donne pas envie. C'est pourtant pas compliqué d'expliqué que «pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets».
Ensuite soit tu rajoute «on admet le problème mais notre cible actuelle est les projets de taille raisonable qui ne sont pas génés par cela» ou «on y réfléchit et ce sera implémenter dans le futur».
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
PS: Je ne prétend pas détenir la vérité absolue et j'admet que ce que je dis dans ce message est mon interprétation de ce qui c'est dit ici. Mais si j'ai mal interpreté vos propos, je ne suis peut-être pas le seul, et si Lisaac est autant un sujet à troll c'est peut-être que l'on est nombreux à pas vous comprendre correctement.
[^] # Re: Y'a d'autres sites
Posté par beagf (site web personnel) . En réponse au journal Conditions de ventes et autres débilités. Évalué à 6.
Si je prend l'exemple de l'album qui s'affiche en premier sur leur site en ce moment, celui de charlotte gainsbourg http://www.starzik.com/mp3/produits/IRM_plus_LIVRET-454190.h(...) . Le fichier FLAC est obtenu en décompressant un fichier encodé en 192Kb/s.
Je n'ai rien contre le fait de réencoder en FLAC, c'est stupide mais ils font ce qu'ils veulent. Ce que je critique c'est le fait que ce ne soit pas clair sur leur site. Il y a quelques temps en tout cas, lorsque l'on achetait un album en FLAC chez eux, c'était très difficile de savor quelle était la qualitée réelle de ce que l'on achetait.
Il y a des morceaux ou ça passe, mais il y en as ou c'est une veritable catastrophe. Je comprend qu'ils font avec ce que les maison de disque leur filent, mais vendre du FLAC dans cet état, je trouve que ça frise parfoit l'escrocrie. Je me serais fait avoir si je n'avais pas déjà eu le cas avec un autre site de vente en ligne qui avait le même genre de pratique mais sans aucune indication du réencodage.
[^] # Re: Surprise
Posté par beagf (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
J'en ai rien a battre puisque comme je te le dit ce genre d'erreur est détecter rapidos par les assertion et ne représente qu'une fraction minime du temps de debuggage.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
Principalement la notion vectorielle et les fonction de manipulation des matrice de haut niveau. Mais on s'en fout ici. Le truc c'est que j'ai une version de référence et que je veut comparer mon programe à cette référence et que vu les volumes de données, la seule solution raisonable ici, est de sortir des logs ce qui impose des recompilations.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure.
Encore completement à côtè de la plaque, je t'explique qu'il y a des projet ou il faut 1h voir plus pour tout compiler et seulement une ou deux minutes quand on fait de la compilation modulaire. Et toi tu me répond que tu en as rien a battre de leur gueule car ton compilo ce compile en quelques minutes.
Tu crois vraiment que tu me donne envie d'écrire un gros projet en Lisaac : «oui, bonjour monsieur. en effet votre programe prend 2h a compiler pour une modif d'une ligne, mais ce n'est pas grave, le compilateur qui est aussi lent ce compile lui en moins de 2minutes sur le processeur de votre montre.»
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
Tu finis par avouer que c'est quand même pas mal d'avoir de la compilation modulaire... Le truc c'est que «un jour» c'est trop tard pour un projet qui démare maintenat, donc faut pas venir ce plaindre que personne veut utiliser votre langage.