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.
"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.
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.
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.
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.
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 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.
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.
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 ?
Et niveau sécurité de l'engin ? Il faut protéger sa source de temps ? Il faut empêcher a tout prix l'accès a la clef prive ?
Par ce que réaliser ce genre de compteur avec un écran, cela représente rien en électronique. (en gros, je sais faire)
Par contre, faire la même chose en protégeant toutes les IOs, c'est une autre paire de manche. (protection de la RTC, utilisation de puce de carte a puce pour planquer la clef, utiliser sans doute un autre uP pour gérer l'affichage, etc...)
J'imagine qu'un truc le moins chére possible mais non sécurisé pourrait amorcer le projet. Déjà si la clef prive dépend du porteur et non du systèmes, il y a moins besoin de sécuriser la calculette contre les attaques hardware (en gros que chaque carte contient une clef différente, cela complique les attaques sur la clef).
disons que si le sujet est le token, on ne sait pas quel doivent être ses propriétés. Je vois bien le genre de calculette RSA mais est-ce qu'une clef usb avec un seul bouton ne suffirait pas ?
Les démarrages sont fastidieux. Mais après un moment, l'application démarre. Amarok tourne très bien par exemple. Même quelques jeux en 3D tourne bien.
[^] # Re: Pas la peine d'aller si loin
Posté par Nicolas Boulay (site web personnel) . En réponse au journal [OFF]Annonce ANPE hallucinante. Évalué à 7.
Il manque tellement de personnel qualifiés qu'il t'embauche immédiatement.
"La première sécurité est la liberté"
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 5.
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é"
[^] # Re: Prêt à être utilisé par les masses?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
Tu peux regarder dans les exemples. Il y a même un petit tetris.
"La première sécurité est la liberté"
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 3.
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é"
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 5.
"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é"
[^] # Re: Tout mauvais...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 3.
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é"
[^] # Re: Langage de "très haut niveau"?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
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é"
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 4.
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é"
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
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é"
[^] # Re: Hum
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 9.
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OpenToken : un projet de token d'authentification matérielle ouvert. Évalué à 2.
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é"
[^] # Re: c'est rigolo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 4.
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é"
[^] # Re: c'est rigolo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 3.
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é"
[^] # Re: c'est rigolo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 4.
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é"
[^] # Re: c'est rigolo
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 4.
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é"
[^] # Re: ISO, la norvège, l'ECMA et un seul gars
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OpenToken : un projet de token d'authentification matérielle ouvert. Évalué à 3.
Par ce que réaliser ce genre de compteur avec un écran, cela représente rien en électronique. (en gros, je sais faire)
Par contre, faire la même chose en protégeant toutes les IOs, c'est une autre paire de manche. (protection de la RTC, utilisation de puce de carte a puce pour planquer la clef, utiliser sans doute un autre uP pour gérer l'affichage, etc...)
J'imagine qu'un truc le moins chére possible mais non sécurisé pourrait amorcer le projet. Déjà si la clef prive dépend du porteur et non du systèmes, il y a moins besoin de sécuriser la calculette contre les attaques hardware (en gros que chaque carte contient une clef différente, cela complique les attaques sur la clef).
"La première sécurité est la liberté"
[^] # Re: ISO, la norvège, l'ECMA et un seul gars
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Statistiques sur les procédures fast track de l'ECMA. Évalué à 8.
"La première sécurité est la liberté"
[^] # Re: Comment nous aider
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OpenToken : un projet de token d'authentification matérielle ouvert. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Un peu léger
Posté par Nicolas Boulay (site web personnel) . En réponse au message PII 300 Mhz et Compiz. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: OTP
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OpenToken : un projet de token d'authentification matérielle ouvert. Évalué à 3.
De plus, certain téléphone ont des fonctionnalités proche de celle des cartes a puces.
"La première sécurité est la liberté"