Nicolas Boulay a écrit 15824 commentaires

Je trouve que c'est très équitable : Haskel ne permet pas de faire l'algo quicksort le plus rapide. C'est bien l'intéret d'un (micro) bench !

Pour être juste, je pense qu'il faudrait pouvoir mettre l'algo de trie que l'on veut. Mais si le quicksort est le plus rapide, alors Haskel produit dans tous les cas de trie, un code plus lent que C.

Si on prend le en place ce n'est pas équitable car Haskell aura des problèmes pour l'exprimer.

Je ne vois pas pourquoi cela serait injuste, c'est le but du test de montrer ce genre de limitation.

"La première sécurité est la liberté"

sur des machines bien plus puissantes.

"La première sécurité est la liberté"

"Non, figer l'algo biaise car certains algo sont plus adaptés aux paradigmes de certains langages."

J'y crois moyen... Que certain algo soit plus facile à écrire avec certain langage, c'est une évidence. Mais les performances sont lié à l'algorithme et le traitement capable d'être fait par le compilateur.

Tu as des exemples ?

"La première sécurité est la liberté"

Tu ne sais plus trop ce que tu tests dans ce cas là.

Il vaut mieux un truc imparfait avec une imperfection borné, qu'un truc ou tu ne sais quoi dire des chiffres. Est-ce que les chiffres est faibles car l'algo n'est pas le meilleur ?, etc...

"La première sécurité est la liberté"

Les algos proposés sont parfois loin d'être optimal pour le problème posé. Une solution plus performante mais ne respectant pas l'algo original ne sera pas retenu.

"La première sécurité est la liberté"

Si tu as respecté l'algo de base, c'est le jeu !

"La première sécurité est la liberté"

Globalement, c'est vrai pour tous les pays en voie de développement. Tu va là-bas avec un bon diplôme tu prends immédiatement des responsabilité dont tu ne pourrais pas rêver en France (Maghreb, Amérique central, etc...).

Il manque tellement de personnel qualifiés qu'il t'embauche immédiatement.

"La première sécurité est la liberté"

"Mais je reste stupéfait quand je lis "Le langage A crachant du langage B est plus rapide que le langage B"
Non, et non, ça ne peut pas marcher, rien qu'intellectuellement."

Cela démontre juste qu'intellectulement, tu n'as rien compris à la compilation, voir même à l'intérêt d'un langage de programmation (qui doit aider à gérer les problèmes de maintenabilité et d'absence d'erreur).
Et on revient à la débilité où on compare C et l'assembleur.

Or le C n'est qu'un assembleur un poil plus évolué.

l'avantage d'un langage haut-niveau n'étant pas la mesure de sa rapidité (un langage qui pour faire la même chose rame 10x plus n'est pas forcement un mauvais langage, c'est surtout le compilo qui est merdique).

Et pourtant, tous les langages de haut niveau sont plus lent que C (jusqu'à présent). On connait tous les avantages du haut niveau si en plus on a la vitesse, c'est encore mieux...

"Dire que tel langage est plus rapide que tel autre est une grosse connerie : ce n'est pas le langage qui fait forcement la vitesse, mais le compilo."

Sauf que c'est simplement faux. Faire un compilo rapide pour perl ou python est super difficile, car le langage ne le permet pas au contraire de lisaac. C montre aussi ces limites (contrainte sur le structure de donné en mémoire par exemple).

Pour un effort identique, un compilo ne te donnera pas du tout le même résultat selon le langage. Dans le cas de génération du C, tu peux en plus utiliser toutes les optimisation bas niveau du compilo C.

"La première sécurité est la liberté"

Si ton but est de faire un programme dans ton coin, Lisaac est prêt pour ça. Pour contre, il n'est pas encore stable. Il y a quelques changements dans le langage lui-même qui sont dans le pipeline.

Tu peux regarder dans les exemples. Il y a même un petit tetris.

"La première sécurité est la liberté"

code assembleur (langue maternelle du CPU)

C'est faux ça. J'ai souvent vu des instructions qui sont en fait des macros ou des concatenations d'instruction (par exemple pour faire un saut absolue en ARM, le call est transformé en call indirect qui va chercher l'adresse de saut un peu plus loin en mémoire).

C'est encore un poil au dessus du binaire de base.

Tu balances une truc super-général, avec quelques tests, désolé mais ça n'a rien de scientifique, ça fait la personne qui veut prouver quelque chose et qui va biaiser son étude pour arriver à la conclusion qui l'arrange...

Espèce de rabat-joie.

Ne t'inquiète pas je sais très bien ce que veut dire ce bench et ce qu'il ne veut pas dire.

Mais si il y a 2 ans tu aurais dit qu'un langage à prototype qui est encore plus haut niveau que Eiffel aurait des performances proches du C, tu aurais été mis à l'asile.

As-tu fixé les bornes? Sont-elles acceptée par tous? Est-ce que tu as fait des tests sur les autres langages avec les mêmes bornes? Dire des "vérités" brutes, c'est pas si évident, tu généralises à partir d'un exemple, on peut te donner un autre exemple ou C est plus rapide que Lisaac (genre void main(){}) et dire "Lisaac ca rame.

Je fais pas mal d'optimisation pour m'amuser. Je suis sûr que je peux battre Lisaac, car c'est une partie de mes idées qui sont à la base de certaine optimisation. Mais entre prendre un code clean, pour le transformer en truc immonde 2 fois plus rapide, il y a des heures de boulot. Et encore, certaine optimisation nécessite d'avoir la connaissance adéquate, cela n'est pas à la porté de tout codeur.

"La première sécurité est la liberté"

Dans la distribution de lisaac, il y a un lisaac.c qui est le compilé Lisaac vers C du compilo, pour avoir une idée de la tronche du code généré.

"Si tu suis un raisonnement scientifique (logique), Lisaac ne peut pas, par conception, être plus rapide que du C."

Et donc par conception, du code C ne peut pas être plus rapide que de l'assembleur ? Et par extension, aucun langage ne peut être plus rapide que l'assembleur ?

Il est évident que je parle pour un temps de développement "borné". "Plus rapide" n'a de sens que dans ce cadre.

"La première sécurité est la liberté"

C'est très exactement pour cette raison que je pense qu'un langage de haut niveau est plus facile à optimiser que le C. (A la base je suis ingé hardware et j'ai bossé sur le projet f-cpu)

Il y a des tas d'optimisation inaccessible en C sans casser la sémantique, par exemple, sur le layout mémoire. Tu n'as pas le droit de toucher à l'ordre des champs d'un struct en C, Lisaac peut le faire. (je crois qu'il y a une option pour le faire maintenant dans gcc mais cela peut casser des programmes)

Un langage de haut niveau permet mieux d'exprimer ce que le codeur veut faire ce qui donne suffisamment d'information au compilateur pour générer le meilleur code possible.

"La première sécurité est la liberté"

Si tu prends l'exemple du codeur mpeg2, lisaac a 30% de ligne de code en moins car il n'a pas besoin de gérer la mémoire pour les buffer interne.

"La première sécurité est la liberté"

La différence est minime de toute façon, c'est symbolique...

Propose ta modification. Mais fait attention aussi que tu respectes bien les règles de codages, si tu change l'algo cela n'a pas de sens, et que si tu fais exploser la consommation mémoire tu y perds sur ce paramètre.

"La première sécurité est la liberté"

Sauf qu'un humain mettra infiniment plus de temps à le générer que le compilo Lisaac.

"La première sécurité est la liberté"

Disons que si tu prends 2 codeurs moyen avec un temps fixe de développement, tu auras un binaire plus rapide sous Lisaac que sous C. Car c'est plus costaux d'optimiser à mort pour C.

Ce sont les processus exécutants des tâches aux finalités équivalentes sur un même matériel qui sont plus où moins performants. Éventuellement les programmes qu'éxécutent ces processus sont écrit dans un langage différent.

c'est ça un bench. Même algo, même machine, même donné, seul change le langage, donc toute différence de performance peut-être imputé au langage, ou au codeur. C'est l'intérêt du développement ouvert du shoutout tout le monde peut proposer mieux.

"La première sécurité est la liberté"

et passer un temps hyper long...

"La première sécurité est la liberté"

Dire que Lisaac c'est du C, c'est aussi débile que dire que du C, c'est de l'assembleur car c'est ce que génère gcc.

"La première sécurité est la liberté"

"Et puis bon le pb de shootout, c'est que les "tests" ne sont pas forcement représentatif."

C'est pas le problème du shoutout, c'est le problème des microbenchs en général par rapport à un bench applicatif.

Mais si un langage n'est pas devant dans ce genre de cas, il a très peu de chance d'être devant dans des cas plus gros.

"La première sécurité est la liberté"

A bah, non, c'est de l'assembleur puisque le C génère de l'assembleur.

"La première sécurité est la liberté"

L'idée principal est de ne pas pouvoir demander un nouveau mot de passe de façon logiciel.

Il existe des cartes à puces ayant une interface USB, il doit être possible de les utiliser, sauf si elle implémente une norme spécial.

"La première sécurité est la liberté"

J'utilise juste mon cerveau et le bon sens.

A quoi sert de définir une norme sur les dates et les dessins vectoriels si c'est pour inventer de nouvel façon de faire à la première occasion !

Un format n'a pas à tenir compte de l'existant, mais à préparer le futur. C'est juste du bon sens technique.

"La première sécurité est la liberté"

pas le fast-track

Norme 10 fois plus grosse que les autres ?

A lire et assimiler en quelques mois... c'est d'un ridicule.

"La première sécurité est la liberté"

Tu es d'une mauvaise foie affligeante !

On te montre une statistique avec plus de 300 documents, un graphique qui montre que OOXML est un monstre obèse 10 fois plus gros que n'importe qu'elle autre norme en fast track, et tu continues à défendre l'indéfendable !

Faut-il rappeler que ODF n'est pas passé en fast track ?

Que MPEG4 a mis 6 ans et 17 revues pour 4000 pages ?

"La première sécurité est la liberté"

il n'y a pas de regles disant qu'un standard ne doit pas essayer d'etre compatible avec l'existant, "

C'est juste la définition d'un standard, qu'une norme implémente. Juste la définition...

"La première sécurité est la liberté"