Je sais pas ce qu'il en est pour l'apprentissage du japonais, mais je confirme que "Les 12 Royaumes" est vraiment une excellente série!
Elle est disponible en DVD en France.
Sinon c'est pas les bonnes séries qui manquent.
Tu peux tenter Hikaru no Go. C'est une série sur le Go... mais vraiment excellente. J'ai complètement accroché et ... je sais toujours pas jouer au Go!
Ce qu'il y a de bien avec les animes japonais, c'est que les dvd qui sortent en France on un doublage tellement pourris (rien à voir avec celui des films ou séries tv) que ça te force à les regarder en VO!
En fansub il y a actuellement Death Note qui est vraiment très bien.
Oui c'est bien à par2 que je faisait allusion plus haut.
Mon utilisation (non encore testée) n'utiliserait pas dar ou autre programme d'archivage. Ca serait juste dans le cadre d'une gravure normale de génèrer préalablement via par2 des fichiers de parité qui seront gravés avec le reste.
Cela suppose évidemment de laisser un peu de place pour ces fichiers de parité.
Comme ça en cas de problème, un coup de ddrescue et un par2repair pourra peut-être me permettre de récupérer mes données.
Encore une fois ça serait plutôt pour des données que j'estime moyennement importantes (genre divx récupérés sur le net).
Par contre générer des fichiers de parité a l'air de prendre du temps. Faut pas être très pressé.
Petite question au passage pour avoir des avis sur une idée qui vient de me passer par la tête:
Puisque souvent (en tout cas c'est mon cas) le problème de lecture d'un DVD sont localisés et n'impactent pas tout le disque, ne serait-il pas intéressant de rajouter des fichiers de redondance de type fichiers PAR souvent utilisés dans les newsgroups? Par exemple consacrer 10% de l'espace disque à cela.
Evidemment c'est contraignant et en cas d'erreur la correction prend du temps (et puis il faut copier les données sur le disque dur en ignorant les erreurs de lecture), mais ça permettrait de récupérer des données autrement perdues.
Ca pourrait être utile pour des données que l'on veut sauvegarder, mais qu'on ne considèrent pas suffisamment importantes pour multiplier les sauvegardes.
Je prend l'exemple des fichiers de parités PAR (basés sur du Reed-Solomon), mais une solution 'intégrée' existe peut-être déjà.
Ouais, bah attention. La fiablilité des DVD n'est pas garantie. Ca m'est arrivé plusieurs fois, après plusieurs mois, d'avoir des problèmes de lecture sur des DVD gravés. Et pourtant je ne les avaient guère manipulés.
Et c'est pas un problème de gravure, je fais systématiquement une vérification.
Moralité pour des données importantes, faire toujours plusieurs gravures!
Juste une remarque et rappel:
publier une spécif DRM n'est pas une idée judicieuse si tu souhaites que ta technique de DRM soit efficace (?!). En effet l'idée derrière les DRM c'est de chiffrer le fichier à protéger avec une clé cryptographique. Le petit problème c'est que l'utilisateur il veut tout de même pouvoir écouter sa musique! On est donc obligé de lui fournir la clé, ou du moins le logiciel qu'il utilise doit pouvoir la récupérer.
Donc au final on envoie un chiffré avec la clé! Généralement l'algo crypto est publique (histoire d'avoir qqch qui tient la route). Le seul moyen que ça marche (façon de parler...) est de ne rien révéler sur le mécanisme et la manière d'accéder à la clé, afin que seul le logiciel ad hoc (fermé et tout) puisse lire le fichier.
Dans leur principe même de fonctionnent, les DRM sont donc foireux.
Si tu fais un logiciel libre capable de lire des fichiers DRM (et sans aide d'une lib proprio), autant dire que ton mécanisme est cassé.
Evidemment la situation peut être différente si tu obliges l'utilisation de puces crypto (genre TPM), ou si ton mécanisme utilise une connexion réseau pour gérer les droits.
Vu que les formules dans ODF sont sensées utiliser MathML, je vois mal ce qui peut clocher à moins que MathML ait des problèmes... Je n'en sais rien mais:
- je n'ai pas prétendu que ODF était la perfection incarnée.
- si De Icaza est si fier d'avoir forcé MS à documenter les formules de OpenXML, j'aimerai savoir pourquoi il a pas fait la même chose pour l'ODF? Au passage je n'ai pas trouvé ses arguments très convaincants. Il prétend que pour supporter les formules ODF il peut être nécessaire de regarder comment fait... OpenXML! Ouais c'est ça, n'importe quoi. Il a pas l'air d'avoir vu que c'était basé sur MathML (qu'il ne cite même pas). Il connait peut-être bien l'OpenXML, mais il semble que sa connaissance de l'ODF ait comme qui dirait de grosses lacunes. Au passage tu trouves normal qu'il ait dû forcer MS à fournir les spécifications? Elles auraient dû être fournies depuis le début du processus à l'EMCA. Et qu'est-ce qui nous prouve qu'il n'y a pas d'autres choses manquantes?
- s'il y a tant d'absurdités, pourquoi ce monsieur n'est pas intervenu pour tenter de les faire corriger?
- historiquement le format d'OpenOffice n'est pas basé sur le doc. Par contre l'OpenXML oui.
- je suis un écologiste convaincu. MS est en train de détruire toutes les forêts de la planète!! :)
aucun projet open-source n'implémente entièrement ce format [le SVG] ...
Je connais plusieurs projets libres qui implémentent le SVG suffisamment bien pour faire des dessins très élaborés (Inkscape entre autre). Ce qui pêche encore c'est les animations mais il me semble que pour une suite bureautique c'est pas trop un problème. Par contre il est vrai que le support du SVG est encore inexistant dans OpenOffice et c'est embêtant.
il suffit pas de dire "j'ai que 600 pages moi !" si c'est pour faire référence à des trucs externes conséquents à côté.
Je vais sans doute t'apprendre quelquechose alors: faire référence à d'autres normes est une pratique courante en normalisation, que ce soit à l'ISO, l'IETF ou ailleurs.
il n'y a que KOffice qui va supporter l'ODF en natif et qui ne soit pas un clone de OOo
Il n'y a pas non plus 36 suites bureautiques différentes (et avancées) dans le monde du libre (ni dans le monde propriétaire d'ailleurs). Et tu n'adoptes pas en interne du jour au lendemain un format d'enregistrement différent. Il est plus simple de faire un outil de conversion.
D'ailleurs on s'en fout: l'important c'est qu'on puisse produire des documents lisibles par n'importe quelle suite bureautique. Si le logiciel utilise le format en interne, tant mieux, mais ce qui est important c'est qu'il puisse lire et écrire de l'ODF à la demande.
Avantage MS ? Ca oblige MS a documenter "enfin" son format, tu crois qu'il le fait de bon coeur et que ca va lui être bénéfique ? Tout son modèle se basait sur un format fermé proprio, dissuadant ainsi les transitions vers un concurrent. Là MS a été "obligé" de s'ouvrir à cause de de OOo et l'ODF plus récemment. Alors non, ce format n'avantage pas MS, au contraire.
Je ne conteste pas le fait que MS documente son format, je trouve cela très bien. Mais il l'a déjà fait via l'ECMA! Au passage, vu les problèmes rapportés dans les liens que j'ai donné avant, il semble que le boulot laisse un peu à désirer (y a quelques omissions qu'on espère involontaires...).
Le problème c'est que l'ECMA est plus un organisme d'enregistrement de standards, sans chercher de consensus avec d'autres acteurs, qu'autre chose.
J'exagère peut-être mais à mon avis pas tellement.
Non ce que je conteste c'est qu'il veuille en faire un standard ISO par un processus d'adoption rapide. On risque de se retrouver avec un format avantageant seulement MS, car étant le seul à pouvoir l'implémenter complètement, avec toute l'aura qu'a un standard ISO, sans corriger les problèmes déjà repérés (cf. mes liens) et sans s'interroger sur la pertinence par rapport à l'ODF.
mais l'OpenXML a été conçu pour être interopérables avec les produits MS
C'est justement ce lieu important avec un seul produit propriétaire qui pose problème. Le format ne s'intéresse pas assez l'intéropérabilité avec d'autres produits ce qui est le but des standards ISO. C'est une intéropérabilité MS-MS. C'est intéressant mais pas à l'ISO.
Après si le format passe par le processus normal de révision où toutes les parties intéressées pourront (et auront le temps) de proposer des améliorations, ok.
Bienvenu dans l'enfer d'Office! Je compatie l'éditeur d'équation est une vraie plaie.
Pour la petite histoire c'est même ça qui m'a fait sauter le pas vers OpenOffice dont l'éditeur d'équation t'offre les deux possibilités: souris (lent et chiant) ou syntaxe LaTeX (rapide et pratique). Et depuis je suis resté sous OpenOffice même s'il est rare maintenant que j'ai à rentrer des équations (mais je trouve qu'OpenOffice en tant que logiciel a d'autres avantages).
J'avoue que le LaTeX j'ai jamais réussi à m'y mettre. J'ai juste retenu quelques trucs pour les équations et c'est tout.
Oui je sais que le MathML est imbitable pour un humain. Mais encore une fois tu n'auras jamais sous OpenOffice à écrire du MathML.
Tu écriras comme pour LaTeX : x^2 + 4x + 4 = 0
Pour les trucs de base la syntaxe est la même que LaTeX. Pour les trucs plus compliqués aussi mais je n'en suis pas sûr.
Ce qui compte c'est que le logiciel soit capable de bien interpréter l'équation et pour lui lire du MathML n'est pas un problème.
Le format LaTeX est très bien adapté pour être écris par un humain, mais ici c'est la machine qui gère cela et le MathML répond au besoin.
L'intérêt du MathML c'est que c'est du XML, donc pas besoin de parseur supplémentaire. C'est un bon format d'échange de machine à machine.
Si tu as besoin d'écrire du MathML, il existe des convertisseurs LaTeX->MathML. Pas la peine de se casser la tête.
Sur la question du MathML, ok le LaTex est peut-être mieux foutu mais n'est pas basé sur du XML.
A mon avis cela n'a guère d'importance car l'utilisateur ne va écrire directement du MathML. Si le logiciel te permet d'entrer des équations à la manière de LaTex, comme le fait OpenOffice d'ailleurs, et fait la conversion en MathML comme il faut je ne vois pas le problème.
Bon tu sembles complètement zapper le principal argument: un standard ISO est fait pour faciliter l'interopérabilité entre plusieurs acteurs. Pour cela on a déjà l'ODF.
Le format de MS ne sert principalement que pour Office et pour ses besoins particuliers a besoin de gérer les vieilles versions des formats.
(Surtout que la compatibilité avec les vieux formats MS ça me fait bien rire. OpenOffice affiche parfois mieux ces vieux fichiers qu'un Office récent.)
C'est très bien mais encore une fois ces soucis de compatibilité sont un problème seulement avec Office, pas avec les autres suites bureautiques. Elles n'ont rien à faire ici.
Je ne vois pas l'intérêt pour l'ISO de standardiser ces spécifs qui avantagent manifestement un seul acteur, c'est à dire MS.
S'il s'agit de publier les formats OpenXML c'est déjà fait via l'ECMA.
Je suis particulièrement opposé ici au processus d'adhésion rapide à l'ISO:
- la norme est très longue et le temps trop court pour pouvoir étudier complètement le document. On risque de laisser passer de gros problèmes et un certain nombre on déjà été signalés.
- elle est incomplète. Le document indique que telle chose doit être fait de la même manière que tel logiciel MS mais n'indique pas comment ni où trouver l'information.
- encore une fois elle ne ré-utilise pas les standards en vigueur (alors que cela ne poserait aucun problème de compatibilité avec les vieux formats MS, puisque c'est ton cheval de bataille).
Idéalement l'ISO devrait prendre du temps pour étudier de manière approfondie l'openXML, le comparer avec l'ODF, et voir s'il est pertinent en tant que standard indépendant, doit être rejeté ou encore comment intégrer certaines fonctionnalités qui seraient manquantes (?) à l'ODF.
Tu crois que le HTML est parfait ? Tu crois que les mecs qui ont sorti XHTML se serait pas passé de certaines erreurs du HTML s'ils avaient pas dû gardé une certaine compatibilité ?
Mauvais argument, le HTML est standardisé, pas les formats actuels d'Office. D'autre part OpenXML est sensé être un format complétement différent (XML) des anciens (binaires). Ce n'est pas une extension d'un format existant.
Ceci dit je ne connais pas très bien le XHTML et serais intéressé de connaître quelles sont ces erreurs du HTML conservées dans le XHTML? Il me semblait pourtant que le XHTML "cassait" certaines choses, en étant par exemple plus stricte que le HTML.
Si tu codais un peu et que tu faisais mumuse avec des formats de fichier, y'a longtemps que tu te serais aperçu que la plupart des convertions de formats se fait "dans la douleur" avec une perte souvent non négligeable d'informations. La plupart des applis marchent sur ce mode : un format "natif" qui contient toutes les informations, et de nombreux formats supportés en "import" ou "export", autrement dis avec pertes. L'ODF peut être supporté par MS Office à travers un mécanisme d'import/export, mais il ne peut nullement être utilisé en natif sans passer par des hacks à 2 balles (simuler des fonctionnalités non présentent dans le format en utilisant une autre fonctionnalité, sans aucune garantie d'interprétation correcte par une application tierce).
Vu que Microsoft semble incapable de gérer les vieilles version du format doc, je vois mal ce que ça va changer. D'autre part un des (nombreux) problèmes est un bug concernant la gestion des dates avec je sais plus qu'elle format. Tu vas peut-être me dire que c'est si difficile à corriger que cela? J'ai l'impression que tu me prend pour un con là.
D'après ce que tu dis l'OpenXML ne va finalement servir que pour Office et non pour d'autres suites bureautiques. Il ne s'agit donc que d'une spécification pour permettre de générer des fichiers à destination d'un logiciel propriétaire, en l'occurrence Office. C'est également une spécification qui va permettre à Office de convertir des vieux formats Office vers du OpenXML (en gardant plein de trucs crades du vieux format).
Et il ne s'agit donc pas d'un format de fichier commun qui vise l'intéropérabilité entre suites bureautiques, puisque ici on a un format qui colle au plus près à un logiciel existant (Office). La spécifications va juste permettre que d'autres logiciels puissent générer tant bien que mal un fichier compatible.
C'est bien mais désolé je ne vois toujours pas ce que ça fout à l'ISO. L'ISO vise à permettre l'interopérabilité sans avantager un acteur par rapport à un autre. Ce n'est manifestement pas le cas ici.
D'autre part si l'ISO peut discuter du fond, je t'assure. Certains standards peuvent être refusés, d'autre considérés comme obsolètes retirés, etc.
Que Microsoft veuille garder le contrôle de son format c'est son droit, mais ce qui me gène particulièrement c'est qu'il vend cette spécification comme un concurrent de l'ODF. Ce n'est manifestement pas le cas ici.
L'ODF a peut-être été conçu au départ comme un concurrent du format d'Office mais ses concepteur ont fait l'effort d'en faire quelquechose de suffisamment indépendant du logiciel dont il est issu. Ce n'est pas le cas de l'OpenXML.
J'en revient à ma première conclusion, l'ECMA suffisait amplement.
Sachant que l'ODF ne répond pertinement pas aux attentes de 90% du parc des suites Office déployés, cet argument pu la mauvaise foi à plein nez. Le fait que MS Office est des fonctionnalités non supportés dans l'ODF alors que cette suite est la plus répendue montre également clairement que l'ODF ne suffit pas, et qu'il y a donc un intérêt à avoir un autre format.
Désolé mais c'est toi qui me semble d'une mauvaise fois incroyable.
Quelles sont ces fameuses fonctionnalités indispensables? Désolé mais je n'ai jamais vu de fonctionnalités dans Office qui ne puisse être couvert par l'ODF. Il n'y a pas eu de fonctionnalités révolutionnaires dans les suites Offices depuis pas mal de temps. Donne des exemples.
le format OpenXML joue la carte de la rétro-compatibilité en détaillant toutes les fonctionnalités "historique" de MS Office.
Argument stupide si tu veux mon avis. Je vois vraiment ce que ça vient faire dans un format XML. Si ton logiciel est capable d'ouvrir ton ancien format il doit y avoir moyen de le convertir dans un format propre sans conserver les casseroles du vieux format. C'est le boulot du convertisseur pas du format.
on peut toujours développer un sous-ensemble de la norme sans tous les "hacks" spécifiques aux vieilles versions d'Office si ca nous intéresse pas.
Super. Si je reçois un document provenant d'Office et utilisant ces "hacks" comme tu le dis toi-même, je pourrais pas l'ouvrir. Génial!
D'autre part il faudrai vérifier si ces "hacks" sont facultatifs ou obligatoires pour être conforme à ces spécifications.
c'est pas comme si y'avait pas déjà un gros boulot fait en amont à l'ECMA
Apparemment ce boulot a été plutôt rapide, surtout en comparaison de la taille du document (cf. les liens donnés plus haut). Le processus pour l'ODF a pris beaucoup plus de temps avec plus d'acteurs.
MS ne réinvente rien, ils se basent encore une fois sur leur existant, existant qui est au passage antérieur au format MathML
Sauf que OpenXML lui est proposé à l'ISO alors que des standards existent déjà. Cet existant maison est-il clairement spécifié, permettant une implémentation libre...
De toute façon ça ne les empêchaient pas de se baser sur des normes maintenant établies. Après tout s'ils sont obligés de spécifier leur MathML maison, c'est que le format n'était pas standardisé ni peut-être même publié(?).
D'autre part pour un standard ISO ne pas être conforme avec d'autres standards ISO me semble assez... bizarre. Cela seul justifierait une révision du format.
Tu vois pas l'intérêt de la compatibilité avec la suite MS Office ? Toi aussi tu fais dans la mauvaise foi on dirait...
Comme je l'ai déjà dit, ça n'a rien à faire dans le format. C'est le rôle du convertisseur de bien faire son boulot. Compliquer le format pour ça est une stupidité.
Le but de l'ISO est de normaliser un ensemble de spécifications.
Dans ce cas l'ECMA devrait suffir. Inutile de le proposer à l'ISO.
Tout ce que vous reprochez à l'OpenXML, c'est de ne pas répondre aux même objectifs que l'ODF, et donc de déclarer que son intérêt est nul.
Et quels sont les objectifs spécifiques à l'OpenXML? Ne me dis pas la compatibilité avec les vieilles versions d'Office, pour moi c'est un argument complètement bidon. Surtout que ça lie le format à un seul acteur, MS.
Sans même avoir les spécification MS OpenOffice arrive bien à ouvrir la plupart des documents Office et les convertir vers de l'ODF. Es tu en train de me dire que MS en est incapable? Tu les prends pour des buses ou quoi?
Dois-je rapeller qu'un standard doit être intéropérable et donc implémentable par n'importe quel acteur et sans avantager l'un par rapport à l'autre.
l'ISO n'est pas là pour arbitrer ce genre de truc.
Et bien si, l'ISO peut très refuser une proposition parcequ'elle ne répond pas au besoin, parcequ'elle est mauvaise ou qu'elle fait double emploi. C'est déjà arrivé. L'ISO n'est pas un organisme d'enregistrement comme l'ECMA.
De faire doublon. ODF est maintenant normalisé à l'ISO et on ne voit pas l'intérêt d'un format concurrent.
Elle est trop longue: plusieurs milliers de pages là où ODF en demande quelques centaines. Le tout sans apporter de fonctionnalité fondamentale. Cela rend la norme difficile à implémenter et c'est beaucoup trop pour que la norme puisse être revue dans le processus d'adhésion rapide (fastrack) à l'ISO.
Elle n'est pas conforme avec d'autres standards (dont certains ISO). Par exemple au lieu d'utiliser MathML pour coder les expressions mathématiques, MS réinvente un autre format complètement différent. C'est stupide et complique encore l'implémentation. (parmis les autres standards non respectés:
# 7.2 ISO 8601 (Representation of dates and times)
# 7.3 ISO 639 (Codes for the Representation of Names and Languages)
# 7.4 ISO/IEC 8632 (Computer Graphics Metafile)
# 7.5 ISO/IEC 26300:2006 (OpenDocument Format for Office Applications)
# 7.6 W3C SVG (Scalable Vector Graphics)
Certaines parties sont présentes pour assurer la "compatibilité" avec de vieux formats Microsoft le tout en propageant de vieux bugs (sur les dates notamment). D'une part j'ai du mal à voir l'intérêt, d'autre part le document fait référence à des spécifs MS qui ne sont pas fournies. La norme ne peut donc actuellement n'être implémentée complètement que par MS. Pas terrible pour un standard international qui n'est pas sensé privilégié un acteur par rapport à un autre.
En conclusion le format OpenXML est peut-être bien (enfin j'ai quelques doute tout de même) mais il n'a rien à faire à l'ISO ou alors il devra être profondément remanié.
Certes les perfs d'OCAML n'ont pas à rougir face au C. Même si elles étaient moins bonnes le langage resterait intéressant de par ses qualités intrinsèques (même si je suis jamais arrivé à me faire aux langages fonctionnels...).
Attention cependant à ne pas prendre au pied de la lettre ces benchs notamment pour les perfs des langages utilisant une machine virtuelle (avec JIT et autres optimisations à la volée) comme Java et C#. On avait déjà parlé il y a quelques temps ici de cette page.
Certains des bench s'exécutent en quelques secondes, sans prendre en compte ni le temps de démarrage de la machine virtuelle ni les optimisations faites comme la recompilation native du code à la volée. Contrairement à ce qui est prétendu sur le site, si le programme s'exécute en 3s l'impact est important.
Je rajouterai que les compétences exprimées dans chaque langages ne sont pas forcément équivalentes. J'avais jetté un coup d'oeil sur un des programmes Java proposé et j'avais vu des choses qui ne me semblaient pas optimales (genre recopie d'un tableau case par case alors que souvent il vaut mieux faire un arraycopy). Il n'est pas impossible que la même chose puisse être observée avec les autres langages du panel.
Enfin j'ignore si c'est le cas ici mais avec un langage objet haut niveau on va avoir tendance à batir un model objet qui sera plus lisible et plus facilement (ré-)utilisable mais que les compilateurs ont encore du mal à bien optimiser; alors qu'en C ce sera disons plus 'crade', presque illisible mais plus optimisée. (Il y a peut-être une différence de philosophie)
Il n'est pas impossible que l'on obtienne de meilleures performances aux benchs, sur certains langages, en partant de la version C traduite au plus près vers le langage cible.
A contrario un langage de haut niveau rendra peut-être plus facile l'implémentation d'un algorithme optimisée, alors que sera un casse tête en C.
Tout ça pour dire que les benchs, mieux vaut ne pas y accorder une importance démesurée et programmer avec le langage que l'on préfère.
Et pour en rajouter une couche:
Déchiffrer est l'inverse de l'opération de chiffrement: on possède les clés nécessaires et on récupère le message original.
Décrypter existe bel et bien mais n'a pas le sens qu'on lui donne souvent: Il s'agit de récupérer le message en clair SANS posséder les clés nécessaires. On casse le code quoi, soit par force brute (on essaie toutes les possibilités), soit en exploitant une faille.
Les exemples d'applications sont vraiment excellentes. F3 permet apparemment de faire des interfaces aussi "design" que ce que permet le Flash. Il y a même un exemple d'appli de cartes (Yahoo): F3 pourrait remplacer le Flash dans Mappy.
Bref c'est à surveiller. F3 est potentiellement très intéressant.
Pour un programme qui met moins de 1s à s'exécuter ce qui est le cas du programme en question avec 500 pour argument, oui le temps de chargement de la JVM est significatif (bien qu'imperceptible pour l'utilisateur). Pour une application sur le bureau, excuse moi mais ton client mail tu le lances pendant plus de 1s (ou alors t'es pas un humain, enlève ton masque!)
Une petite précision pour la classe BigInteger: j'ai affirmé qu'elle était plutôt bien optimisée. Mais en fait je faisais référence au calcul d'exponentielles modulaires qui offre des perfs comparables à d'autre lib C/C++ (sans assembleur). Mais il paraît qu'elle n'est pas super optimisée pour les autres opérations comme la multiplication car elle n'utilise pas des algorithmes optimaux (?).
Ca pourrait être intéressant d'essayer la lib JScience qui prétend obtenir de meilleures perfs en addition et multiplication (mais est-ce vrai pour toutes les tailles de nombre?). Par contre en exponentiation modulaire, gardez BigInteger, avec JScience c'est assez catastrophique.
Pour ce qui est des performances des applis Swing elles se sont beaucoup améliorées avec les dernières versions de Java. Sous des applications comme NetBean ou Eclipse, pour citer de gros programmes, la première fois que je clique sur un menu on sent un très léger retard qui ne se produit plus par la suite. Mais sinon les deux sont aussi réactifs qu'une application native.
J'ai également déjà codé des GUI en Java et avec une JVM récente le lancement me semble aussi rapide qu'une application native (ce qui n'a pas toujours été le cas!).
L'idéal serait que les optimisations de la JVM puisse être mise en cache pour éviter de refaire le boulot à chaque lancement. Je sais pas si c'est prévu mais maintenant que java est en GPL on va peut-être voir apparaître des choses intéressantes. Au pire une compilation native via GCJ pourra être viable.
Pour Mono je ne sais pas. Je ne connais aucune application intéressante.
Concis certes, mais je ne me prononcerai pas pour la lisibilité du code Python. Les goût et les couleurs...
Pour les performances, rien ne vaut un petit test.
De base je constate effectivement que dans les conditions précisées sur le site le programme Python s'exécute plus vite que la version Java (par un ratio d'environ 4 avec 500 comme argument)! Sauf que j'estime que le démarrage d'une JVM est relativement long dans le cadre de ces benchmarks et que les optimisations du JIT ne sont pas non plus négligeables.
Donc pour tenter de minimiser l'effet de démarrage de la JVM j'ai mis une boucle for pour exécuter 10 fois la fonction main et j'ai fait de même pour la version Python:
J'ai lancé la JVM en mode client qui ici est plus rapide que le mode -server. Je sais pas pourquoi c'est le cas ici, mais de toute façons lancer une JVM en mode server pour un aussi petit programme est stupide vu qu'elle va se lancer nettement plus lentement.
Pour info la première exécution du main du programme Java s'effectue en environ 530 ms et tombe à environ 300 ms. L'optimisation du JIT n'est tout de même pas négligeable.
Un simple time -p me donne pour Python:
real 2.82
user 2.48
Et pour Java:
real 3.39
user 2.58
Tiens, bizarre la version Python reste certes plus rapide mais on est loin du facteur 3.
L'écart se ressert si on augmente le nombre d'itération et/ou la valeur de l'argument. Par exemple avec 200 itérations:
Python:
real 54.63 / 53.60 (version compilée)
user 49.45 / 48.66 (version compilée)
Java:
real 60.18
user 47.08
Si je ne m'abuse la version officielle de Python est codée en C et j'imagine que c'est également le cas de la partie chargée de traiter les grands nombres. L'aspect "interprétation" n'intervient que très peu dans ce programme, d'où la faible différence avec la version compilée.
Moi j'en conclu que si on laisse le temps à la JVM de se lancer (un petit bout de programme comme celui-là c'est vraiment la pire des situations pour une VM), on obtient des résultats assez différents.
Alors Python a une classe intégrée performante, mais au final pas franchement plus que celle de Java et manifestement elle n'est pas non plus optimisée avec de l'assembleur. Mais de toute façon je crois qu'un binding GMP pour Python existe...
Tout à fait d'accord. Si le langage te permet de développer ton application plus rapidement et qu'elle soit plus fiable, etc. les avantages compensent bien une vitesse d'exécution un peu plus lente. Surtout qu'en pratique si une opération critique doit être ultra optimisée tu peux la coder en C/assembleur et l'appeler depuis ton programme Java/Perl/Python/Ruby.
C'est juste que ça m'énerve que sur ce test on puisse penser que le C écrase littéralement tous ses concurrents alors qu'en fait c'est le code assembleur qui devrait récolter tous les lauriers.
Java dispose en standard d'une énorme bibliothèque qui couvre la plupart des besoins et qui est en plus bien documentée. Le C ne peut en dire autant. Outre ces biblithèques standards tu trouves d'autres bibliothèques externes (notament Apache) qui couvrent des besoins très diverses (bibliothèques mathématiques, base de données, traitement XML, images, ...). Java n'a pas à rougir face au C à ce niveau.
GMP n'est pas une bibliothèque standard du C, au contraire de BigInteger de Java. Out of the box tu as tout ce qu'il te faut en Java. En C il va falloir que tu fasses des recherches sous Google pour trouver les références d'une bibliothèque, qui ne sera pas forcément GMP d'ailleurs, et qui ne sera pas forcément aussi performante.
A l'origine d'ailleurs la classe BigInteger faisait appel à du code en C ou C++ (mais sans assembleur) puis les gars de SUN se sont aperçu que leur nouvelle implémentation Java était pratiquement aussi rapide et même plus rapide pour des calculs sur des petits nombres, pour lesquels le coût d'appel à une lib externe devenait non négligeable par rapport à la durée du calcul proprement dit. Ils ont donc préféré garder la version Java qui offre au final on a une classe intégrée, relativement performante et surtout indépendante de l'architecture.
Il existe peut-être des lib Java non intégrées au JDK plus performantes dans ce domaine (JScience peut être une piste). Et comme je l'ai déjà dit, si le besoin s'en fait sentir tu peux très bien faire une belle interface Java pour GMP (et l'appeller libJavaGMP!) et tu auras quasiment les mêmes perfs que le programme C. Mais tu perdras en portabilité (ça peut ne pas être un problème) et dans le cadre de ces benchmarks beaucoup de monde risque de trouver, à mon avis à raison, que permettre au programme Java d'appeler du code externe C/assembleur ne permet pas d'avoir une vue représentative des perfs du langage en lui-même qui sont pourtant visiblement un des buts de ces benchmarks.
[^] # Re: En vrac.
Posté par ndesmoul . En réponse au journal Anime sympa pour apprendre le japonais ?. Évalué à 4.
[^] # Re: アニメ
Posté par ndesmoul . En réponse au journal Anime sympa pour apprendre le japonais ?. Évalué à 3.
Elle est disponible en DVD en France.
Sinon c'est pas les bonnes séries qui manquent.
Tu peux tenter Hikaru no Go. C'est une série sur le Go... mais vraiment excellente. J'ai complètement accroché et ... je sais toujours pas jouer au Go!
Ce qu'il y a de bien avec les animes japonais, c'est que les dvd qui sortent en France on un doublage tellement pourris (rien à voir avec celui des films ou séries tv) que ça te force à les regarder en VO!
En fansub il y a actuellement Death Note qui est vraiment très bien.
[^] # Re: Quelle solution pour un particulier ?
Posté par ndesmoul . En réponse au journal Plus c'est gros, plus ça fait mal. Évalué à 2.
Mon utilisation (non encore testée) n'utiliserait pas dar ou autre programme d'archivage. Ca serait juste dans le cadre d'une gravure normale de génèrer préalablement via par2 des fichiers de parité qui seront gravés avec le reste.
Cela suppose évidemment de laisser un peu de place pour ces fichiers de parité.
Comme ça en cas de problème, un coup de ddrescue et un par2repair pourra peut-être me permettre de récupérer mes données.
Encore une fois ça serait plutôt pour des données que j'estime moyennement importantes (genre divx récupérés sur le net).
Par contre générer des fichiers de parité a l'air de prendre du temps. Faut pas être très pressé.
[^] # Re: Quelle solution pour un particulier ?
Posté par ndesmoul . En réponse au journal Plus c'est gros, plus ça fait mal. Évalué à 3.
Puisque souvent (en tout cas c'est mon cas) le problème de lecture d'un DVD sont localisés et n'impactent pas tout le disque, ne serait-il pas intéressant de rajouter des fichiers de redondance de type fichiers PAR souvent utilisés dans les newsgroups? Par exemple consacrer 10% de l'espace disque à cela.
Evidemment c'est contraignant et en cas d'erreur la correction prend du temps (et puis il faut copier les données sur le disque dur en ignorant les erreurs de lecture), mais ça permettrait de récupérer des données autrement perdues.
Ca pourrait être utile pour des données que l'on veut sauvegarder, mais qu'on ne considèrent pas suffisamment importantes pour multiplier les sauvegardes.
Je prend l'exemple des fichiers de parités PAR (basés sur du Reed-Solomon), mais une solution 'intégrée' existe peut-être déjà.
Des avis?
[^] # Re: Quelle solution pour un particulier ?
Posté par ndesmoul . En réponse au journal Plus c'est gros, plus ça fait mal. Évalué à 8.
Et c'est pas un problème de gravure, je fais systématiquement une vérification.
Moralité pour des données importantes, faire toujours plusieurs gravures!
[^] # Re: mouaich
Posté par ndesmoul . En réponse au journal Steve Jobs s'exprime publiquement sur les DRM. Évalué à 6.
publier une spécif DRM n'est pas une idée judicieuse si tu souhaites que ta technique de DRM soit efficace (?!). En effet l'idée derrière les DRM c'est de chiffrer le fichier à protéger avec une clé cryptographique. Le petit problème c'est que l'utilisateur il veut tout de même pouvoir écouter sa musique! On est donc obligé de lui fournir la clé, ou du moins le logiciel qu'il utilise doit pouvoir la récupérer.
Donc au final on envoie un chiffré avec la clé! Généralement l'algo crypto est publique (histoire d'avoir qqch qui tient la route). Le seul moyen que ça marche (façon de parler...) est de ne rien révéler sur le mécanisme et la manière d'accéder à la clé, afin que seul le logiciel ad hoc (fermé et tout) puisse lire le fichier.
Dans leur principe même de fonctionnent, les DRM sont donc foireux.
Si tu fais un logiciel libre capable de lire des fichiers DRM (et sans aide d'une lib proprio), autant dire que ton mécanisme est cassé.
Evidemment la situation peut être différente si tu obliges l'utilisation de puces crypto (genre TPM), ou si ton mécanisme utilise une connexion réseau pour gérer les droits.
[^] # Re: C'est censé fonctionner ?
Posté par ndesmoul . En réponse au journal Sortie du plugin ODF pour Microsoft Office. Évalué à 2.
On peut le trouver où ce plugin?
[^] # Re: C'est censé fonctionner ?
Posté par ndesmoul . En réponse au journal Sortie du plugin ODF pour Microsoft Office. Évalué à 3.
C'est pas très au point leur truc.
[^] # Re: J'aurais bien voulu tester...
Posté par ndesmoul . En réponse à la dépêche Magrathea Online, le routard du système solaire !. Évalué à 4.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 6.
- je n'ai pas prétendu que ODF était la perfection incarnée.
- si De Icaza est si fier d'avoir forcé MS à documenter les formules de OpenXML, j'aimerai savoir pourquoi il a pas fait la même chose pour l'ODF? Au passage je n'ai pas trouvé ses arguments très convaincants. Il prétend que pour supporter les formules ODF il peut être nécessaire de regarder comment fait... OpenXML! Ouais c'est ça, n'importe quoi. Il a pas l'air d'avoir vu que c'était basé sur MathML (qu'il ne cite même pas). Il connait peut-être bien l'OpenXML, mais il semble que sa connaissance de l'ODF ait comme qui dirait de grosses lacunes. Au passage tu trouves normal qu'il ait dû forcer MS à fournir les spécifications? Elles auraient dû être fournies depuis le début du processus à l'EMCA. Et qu'est-ce qui nous prouve qu'il n'y a pas d'autres choses manquantes?
- s'il y a tant d'absurdités, pourquoi ce monsieur n'est pas intervenu pour tenter de les faire corriger?
- historiquement le format d'OpenOffice n'est pas basé sur le doc. Par contre l'OpenXML oui.
- je suis un écologiste convaincu. MS est en train de détruire toutes les forêts de la planète!! :)
aucun projet open-source n'implémente entièrement ce format [le SVG] ...
Je connais plusieurs projets libres qui implémentent le SVG suffisamment bien pour faire des dessins très élaborés (Inkscape entre autre). Ce qui pêche encore c'est les animations mais il me semble que pour une suite bureautique c'est pas trop un problème. Par contre il est vrai que le support du SVG est encore inexistant dans OpenOffice et c'est embêtant.
il suffit pas de dire "j'ai que 600 pages moi !" si c'est pour faire référence à des trucs externes conséquents à côté.
Je vais sans doute t'apprendre quelquechose alors: faire référence à d'autres normes est une pratique courante en normalisation, que ce soit à l'ISO, l'IETF ou ailleurs.
il n'y a que KOffice qui va supporter l'ODF en natif et qui ne soit pas un clone de OOo
Il n'y a pas non plus 36 suites bureautiques différentes (et avancées) dans le monde du libre (ni dans le monde propriétaire d'ailleurs). Et tu n'adoptes pas en interne du jour au lendemain un format d'enregistrement différent. Il est plus simple de faire un outil de conversion.
D'ailleurs on s'en fout: l'important c'est qu'on puisse produire des documents lisibles par n'importe quelle suite bureautique. Si le logiciel utilise le format en interne, tant mieux, mais ce qui est important c'est qu'il puisse lire et écrire de l'ODF à la demande.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 3.
Je ne conteste pas le fait que MS documente son format, je trouve cela très bien. Mais il l'a déjà fait via l'ECMA! Au passage, vu les problèmes rapportés dans les liens que j'ai donné avant, il semble que le boulot laisse un peu à désirer (y a quelques omissions qu'on espère involontaires...).
Le problème c'est que l'ECMA est plus un organisme d'enregistrement de standards, sans chercher de consensus avec d'autres acteurs, qu'autre chose.
J'exagère peut-être mais à mon avis pas tellement.
Non ce que je conteste c'est qu'il veuille en faire un standard ISO par un processus d'adoption rapide. On risque de se retrouver avec un format avantageant seulement MS, car étant le seul à pouvoir l'implémenter complètement, avec toute l'aura qu'a un standard ISO, sans corriger les problèmes déjà repérés (cf. mes liens) et sans s'interroger sur la pertinence par rapport à l'ODF.
mais l'OpenXML a été conçu pour être interopérables avec les produits MS
C'est justement ce lieu important avec un seul produit propriétaire qui pose problème. Le format ne s'intéresse pas assez l'intéropérabilité avec d'autres produits ce qui est le but des standards ISO. C'est une intéropérabilité MS-MS. C'est intéressant mais pas à l'ISO.
Après si le format passe par le processus normal de révision où toutes les parties intéressées pourront (et auront le temps) de proposer des améliorations, ok.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 2.
Pour la petite histoire c'est même ça qui m'a fait sauter le pas vers OpenOffice dont l'éditeur d'équation t'offre les deux possibilités: souris (lent et chiant) ou syntaxe LaTeX (rapide et pratique). Et depuis je suis resté sous OpenOffice même s'il est rare maintenant que j'ai à rentrer des équations (mais je trouve qu'OpenOffice en tant que logiciel a d'autres avantages).
J'avoue que le LaTeX j'ai jamais réussi à m'y mettre. J'ai juste retenu quelques trucs pour les équations et c'est tout.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 2.
Tu écriras comme pour LaTeX : x^2 + 4x + 4 = 0
Pour les trucs de base la syntaxe est la même que LaTeX. Pour les trucs plus compliqués aussi mais je n'en suis pas sûr.
Ce qui compte c'est que le logiciel soit capable de bien interpréter l'équation et pour lui lire du MathML n'est pas un problème.
Le format LaTeX est très bien adapté pour être écris par un humain, mais ici c'est la machine qui gère cela et le MathML répond au besoin.
L'intérêt du MathML c'est que c'est du XML, donc pas besoin de parseur supplémentaire. C'est un bon format d'échange de machine à machine.
Si tu as besoin d'écrire du MathML, il existe des convertisseurs LaTeX->MathML. Pas la peine de se casser la tête.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 1.
A mon avis cela n'a guère d'importance car l'utilisateur ne va écrire directement du MathML. Si le logiciel te permet d'entrer des équations à la manière de LaTex, comme le fait OpenOffice d'ailleurs, et fait la conversion en MathML comme il faut je ne vois pas le problème.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 4.
Le format de MS ne sert principalement que pour Office et pour ses besoins particuliers a besoin de gérer les vieilles versions des formats.
(Surtout que la compatibilité avec les vieux formats MS ça me fait bien rire. OpenOffice affiche parfois mieux ces vieux fichiers qu'un Office récent.)
C'est très bien mais encore une fois ces soucis de compatibilité sont un problème seulement avec Office, pas avec les autres suites bureautiques. Elles n'ont rien à faire ici.
Je ne vois pas l'intérêt pour l'ISO de standardiser ces spécifs qui avantagent manifestement un seul acteur, c'est à dire MS.
S'il s'agit de publier les formats OpenXML c'est déjà fait via l'ECMA.
Je suis particulièrement opposé ici au processus d'adhésion rapide à l'ISO:
- la norme est très longue et le temps trop court pour pouvoir étudier complètement le document. On risque de laisser passer de gros problèmes et un certain nombre on déjà été signalés.
- elle est incomplète. Le document indique que telle chose doit être fait de la même manière que tel logiciel MS mais n'indique pas comment ni où trouver l'information.
- encore une fois elle ne ré-utilise pas les standards en vigueur (alors que cela ne poserait aucun problème de compatibilité avec les vieux formats MS, puisque c'est ton cheval de bataille).
Idéalement l'ISO devrait prendre du temps pour étudier de manière approfondie l'openXML, le comparer avec l'ODF, et voir s'il est pertinent en tant que standard indépendant, doit être rejeté ou encore comment intégrer certaines fonctionnalités qui seraient manquantes (?) à l'ODF.
Tu crois que le HTML est parfait ? Tu crois que les mecs qui ont sorti XHTML se serait pas passé de certaines erreurs du HTML s'ils avaient pas dû gardé une certaine compatibilité ?
Mauvais argument, le HTML est standardisé, pas les formats actuels d'Office. D'autre part OpenXML est sensé être un format complétement différent (XML) des anciens (binaires). Ce n'est pas une extension d'un format existant.
Ceci dit je ne connais pas très bien le XHTML et serais intéressé de connaître quelles sont ces erreurs du HTML conservées dans le XHTML? Il me semblait pourtant que le XHTML "cassait" certaines choses, en étant par exemple plus stricte que le HTML.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 5.
Vu que Microsoft semble incapable de gérer les vieilles version du format doc, je vois mal ce que ça va changer. D'autre part un des (nombreux) problèmes est un bug concernant la gestion des dates avec je sais plus qu'elle format. Tu vas peut-être me dire que c'est si difficile à corriger que cela? J'ai l'impression que tu me prend pour un con là.
D'après ce que tu dis l'OpenXML ne va finalement servir que pour Office et non pour d'autres suites bureautiques. Il ne s'agit donc que d'une spécification pour permettre de générer des fichiers à destination d'un logiciel propriétaire, en l'occurrence Office. C'est également une spécification qui va permettre à Office de convertir des vieux formats Office vers du OpenXML (en gardant plein de trucs crades du vieux format).
Et il ne s'agit donc pas d'un format de fichier commun qui vise l'intéropérabilité entre suites bureautiques, puisque ici on a un format qui colle au plus près à un logiciel existant (Office). La spécifications va juste permettre que d'autres logiciels puissent générer tant bien que mal un fichier compatible.
C'est bien mais désolé je ne vois toujours pas ce que ça fout à l'ISO. L'ISO vise à permettre l'interopérabilité sans avantager un acteur par rapport à un autre. Ce n'est manifestement pas le cas ici.
D'autre part si l'ISO peut discuter du fond, je t'assure. Certains standards peuvent être refusés, d'autre considérés comme obsolètes retirés, etc.
Que Microsoft veuille garder le contrôle de son format c'est son droit, mais ce qui me gène particulièrement c'est qu'il vend cette spécification comme un concurrent de l'ODF. Ce n'est manifestement pas le cas ici.
L'ODF a peut-être été conçu au départ comme un concurrent du format d'Office mais ses concepteur ont fait l'effort d'en faire quelquechose de suffisamment indépendant du logiciel dont il est issu. Ce n'est pas le cas de l'OpenXML.
J'en revient à ma première conclusion, l'ECMA suffisait amplement.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 8.
Désolé mais c'est toi qui me semble d'une mauvaise fois incroyable.
Quelles sont ces fameuses fonctionnalités indispensables? Désolé mais je n'ai jamais vu de fonctionnalités dans Office qui ne puisse être couvert par l'ODF. Il n'y a pas eu de fonctionnalités révolutionnaires dans les suites Offices depuis pas mal de temps. Donne des exemples.
le format OpenXML joue la carte de la rétro-compatibilité en détaillant toutes les fonctionnalités "historique" de MS Office.
Argument stupide si tu veux mon avis. Je vois vraiment ce que ça vient faire dans un format XML. Si ton logiciel est capable d'ouvrir ton ancien format il doit y avoir moyen de le convertir dans un format propre sans conserver les casseroles du vieux format. C'est le boulot du convertisseur pas du format.
on peut toujours développer un sous-ensemble de la norme sans tous les "hacks" spécifiques aux vieilles versions d'Office si ca nous intéresse pas.
Super. Si je reçois un document provenant d'Office et utilisant ces "hacks" comme tu le dis toi-même, je pourrais pas l'ouvrir. Génial!
D'autre part il faudrai vérifier si ces "hacks" sont facultatifs ou obligatoires pour être conforme à ces spécifications.
c'est pas comme si y'avait pas déjà un gros boulot fait en amont à l'ECMA
Apparemment ce boulot a été plutôt rapide, surtout en comparaison de la taille du document (cf. les liens donnés plus haut). Le processus pour l'ODF a pris beaucoup plus de temps avec plus d'acteurs.
MS ne réinvente rien, ils se basent encore une fois sur leur existant, existant qui est au passage antérieur au format MathML
Sauf que OpenXML lui est proposé à l'ISO alors que des standards existent déjà. Cet existant maison est-il clairement spécifié, permettant une implémentation libre...
De toute façon ça ne les empêchaient pas de se baser sur des normes maintenant établies. Après tout s'ils sont obligés de spécifier leur MathML maison, c'est que le format n'était pas standardisé ni peut-être même publié(?).
D'autre part pour un standard ISO ne pas être conforme avec d'autres standards ISO me semble assez... bizarre. Cela seul justifierait une révision du format.
Tu vois pas l'intérêt de la compatibilité avec la suite MS Office ? Toi aussi tu fais dans la mauvaise foi on dirait...
Comme je l'ai déjà dit, ça n'a rien à faire dans le format. C'est le rôle du convertisseur de bien faire son boulot. Compliquer le format pour ça est une stupidité.
Le but de l'ISO est de normaliser un ensemble de spécifications.
Dans ce cas l'ECMA devrait suffir. Inutile de le proposer à l'ISO.
Tout ce que vous reprochez à l'OpenXML, c'est de ne pas répondre aux même objectifs que l'ODF, et donc de déclarer que son intérêt est nul.
Et quels sont les objectifs spécifiques à l'OpenXML? Ne me dis pas la compatibilité avec les vieilles versions d'Office, pour moi c'est un argument complètement bidon. Surtout que ça lie le format à un seul acteur, MS.
Sans même avoir les spécification MS OpenOffice arrive bien à ouvrir la plupart des documents Office et les convertir vers de l'ODF. Es tu en train de me dire que MS en est incapable? Tu les prends pour des buses ou quoi?
Dois-je rapeller qu'un standard doit être intéropérable et donc implémentable par n'importe quel acteur et sans avantager l'un par rapport à l'autre.
l'ISO n'est pas là pour arbitrer ce genre de truc.
Et bien si, l'ISO peut très refuser une proposition parcequ'elle ne répond pas au besoin, parcequ'elle est mauvaise ou qu'elle fait double emploi. C'est déjà arrivé. L'ISO n'est pas un organisme d'enregistrement comme l'ECMA.
[^] # Re: paille/poutre etc
Posté par ndesmoul . En réponse à la dépêche La route de PDF vers l'ISO. Évalué à 7.
EOOXML objections
http://www.groklaw.net/article.php?story=2007011720521698
http://www.groklaw.net/article.php?story=20070123071154671
EOOXML objections (Wiki)
http://www.grokdoc.net/index.php/EOOXML_objections
FFII on proposed OpenXML adoption
http://lwn.net/Articles/219520/
En gros on reproche à la proposition :
De faire doublon. ODF est maintenant normalisé à l'ISO et on ne voit pas l'intérêt d'un format concurrent.
Elle est trop longue: plusieurs milliers de pages là où ODF en demande quelques centaines. Le tout sans apporter de fonctionnalité fondamentale. Cela rend la norme difficile à implémenter et c'est beaucoup trop pour que la norme puisse être revue dans le processus d'adhésion rapide (fastrack) à l'ISO.
Elle n'est pas conforme avec d'autres standards (dont certains ISO). Par exemple au lieu d'utiliser MathML pour coder les expressions mathématiques, MS réinvente un autre format complètement différent. C'est stupide et complique encore l'implémentation. (parmis les autres standards non respectés:
# 7.2 ISO 8601 (Representation of dates and times)
# 7.3 ISO 639 (Codes for the Representation of Names and Languages)
# 7.4 ISO/IEC 8632 (Computer Graphics Metafile)
# 7.5 ISO/IEC 26300:2006 (OpenDocument Format for Office Applications)
# 7.6 W3C SVG (Scalable Vector Graphics)
Certaines parties sont présentes pour assurer la "compatibilité" avec de vieux formats Microsoft le tout en propageant de vieux bugs (sur les dates notamment). D'une part j'ai du mal à voir l'intérêt, d'autre part le document fait référence à des spécifs MS qui ne sont pas fournies. La norme ne peut donc actuellement n'être implémentée complètement que par MS. Pas terrible pour un standard international qui n'est pas sensé privilégié un acteur par rapport à un autre.
En conclusion le format OpenXML est peut-être bien (enfin j'ai quelques doute tout de même) mais il n'a rien à faire à l'ISO ou alors il devra être profondément remanié.
[^] # Re: Tout bon!
Posté par ndesmoul . En réponse à la dépêche OCaml summer project. Évalué à 3.
Attention cependant à ne pas prendre au pied de la lettre ces benchs notamment pour les perfs des langages utilisant une machine virtuelle (avec JIT et autres optimisations à la volée) comme Java et C#. On avait déjà parlé il y a quelques temps ici de cette page.
Certains des bench s'exécutent en quelques secondes, sans prendre en compte ni le temps de démarrage de la machine virtuelle ni les optimisations faites comme la recompilation native du code à la volée. Contrairement à ce qui est prétendu sur le site, si le programme s'exécute en 3s l'impact est important.
Je rajouterai que les compétences exprimées dans chaque langages ne sont pas forcément équivalentes. J'avais jetté un coup d'oeil sur un des programmes Java proposé et j'avais vu des choses qui ne me semblaient pas optimales (genre recopie d'un tableau case par case alors que souvent il vaut mieux faire un arraycopy). Il n'est pas impossible que la même chose puisse être observée avec les autres langages du panel.
Enfin j'ignore si c'est le cas ici mais avec un langage objet haut niveau on va avoir tendance à batir un model objet qui sera plus lisible et plus facilement (ré-)utilisable mais que les compilateurs ont encore du mal à bien optimiser; alors qu'en C ce sera disons plus 'crade', presque illisible mais plus optimisée. (Il y a peut-être une différence de philosophie)
Il n'est pas impossible que l'on obtienne de meilleures performances aux benchs, sur certains langages, en partant de la version C traduite au plus près vers le langage cible.
A contrario un langage de haut niveau rendra peut-être plus facile l'implémentation d'un algorithme optimisée, alors que sera un casse tête en C.
Tout ça pour dire que les benchs, mieux vaut ne pas y accorder une importance démesurée et programmer avec le langage que l'on préfère.
(C'était le dicton du jour...)
[^] # Re: nouvelle affirmation douteuse
Posté par ndesmoul . En réponse au journal 100% vote électronique à Issy les Moulineaux : ce serait iVotronic d'ES&S. Évalué à 8.
Et pour en rajouter une couche:
Déchiffrer est l'inverse de l'opération de chiffrement: on possède les clés nécessaires et on récupère le message original.
Décrypter existe bel et bien mais n'a pas le sens qu'on lui donne souvent: Il s'agit de récupérer le message en clair SANS posséder les clés nécessaires. On casse le code quoi, soit par force brute (on essaie toutes les possibilités), soit en exploitant une faille.
Voilà voilà.
[^] # Re: F3
Posté par ndesmoul . En réponse à la dépêche Itheora, un habillage pour Cortado. Évalué à 2.
Bref c'est à surveiller. F3 est potentiellement très intéressant.
[^] # Re: mon avis
Posté par ndesmoul . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Une petite précision pour la classe BigInteger: j'ai affirmé qu'elle était plutôt bien optimisée. Mais en fait je faisais référence au calcul d'exponentielles modulaires qui offre des perfs comparables à d'autre lib C/C++ (sans assembleur). Mais il paraît qu'elle n'est pas super optimisée pour les autres opérations comme la multiplication car elle n'utilise pas des algorithmes optimaux (?).
Ca pourrait être intéressant d'essayer la lib JScience qui prétend obtenir de meilleures perfs en addition et multiplication (mais est-ce vrai pour toutes les tailles de nombre?). Par contre en exponentiation modulaire, gardez BigInteger, avec JScience c'est assez catastrophique.
Pour ce qui est des performances des applis Swing elles se sont beaucoup améliorées avec les dernières versions de Java. Sous des applications comme NetBean ou Eclipse, pour citer de gros programmes, la première fois que je clique sur un menu on sent un très léger retard qui ne se produit plus par la suite. Mais sinon les deux sont aussi réactifs qu'une application native.
J'ai également déjà codé des GUI en Java et avec une JVM récente le lancement me semble aussi rapide qu'une application native (ce qui n'a pas toujours été le cas!).
L'idéal serait que les optimisations de la JVM puisse être mise en cache pour éviter de refaire le boulot à chaque lancement. Je sais pas si c'est prévu mais maintenant que java est en GPL on va peut-être voir apparaître des choses intéressantes. Au pire une compilation native via GCJ pourra être viable.
Pour Mono je ne sais pas. Je ne connais aucune application intéressante.
[^] # Re: mon avis
Posté par ndesmoul . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 3.
Pour les performances, rien ne vaut un petit test.
De base je constate effectivement que dans les conditions précisées sur le site le programme Python s'exécute plus vite que la version Java (par un ratio d'environ 4 avec 500 comme argument)! Sauf que j'estime que le démarrage d'une JVM est relativement long dans le cadre de ces benchmarks et que les optimisations du JIT ne sont pas non plus négligeables.
Donc pour tenter de minimiser l'effet de démarrage de la JVM j'ai mis une boucle for pour exécuter 10 fois la fonction main et j'ai fait de même pour la version Python:
J'ai lancé la JVM en mode client qui ici est plus rapide que le mode -server. Je sais pas pourquoi c'est le cas ici, mais de toute façons lancer une JVM en mode server pour un aussi petit programme est stupide vu qu'elle va se lancer nettement plus lentement.
Pour info la première exécution du main du programme Java s'effectue en environ 530 ms et tombe à environ 300 ms. L'optimisation du JIT n'est tout de même pas négligeable.
Un simple time -p me donne pour Python:
real 2.82
user 2.48
Et pour Java:
real 3.39
user 2.58
Tiens, bizarre la version Python reste certes plus rapide mais on est loin du facteur 3.
L'écart se ressert si on augmente le nombre d'itération et/ou la valeur de l'argument. Par exemple avec 200 itérations:
Python:
real 54.63 / 53.60 (version compilée)
user 49.45 / 48.66 (version compilée)
Java:
real 60.18
user 47.08
Si je ne m'abuse la version officielle de Python est codée en C et j'imagine que c'est également le cas de la partie chargée de traiter les grands nombres. L'aspect "interprétation" n'intervient que très peu dans ce programme, d'où la faible différence avec la version compilée.
Moi j'en conclu que si on laisse le temps à la JVM de se lancer (un petit bout de programme comme celui-là c'est vraiment la pire des situations pour une VM), on obtient des résultats assez différents.
Alors Python a une classe intégrée performante, mais au final pas franchement plus que celle de Java et manifestement elle n'est pas non plus optimisée avec de l'assembleur. Mais de toute façon je crois qu'un binding GMP pour Python existe...
[^] # Re: mon avis
Posté par ndesmoul . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
C'est juste que ça m'énerve que sur ce test on puisse penser que le C écrase littéralement tous ses concurrents alors qu'en fait c'est le code assembleur qui devrait récolter tous les lauriers.
[^] # Re: mon avis
Posté par ndesmoul . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 3.
GMP n'est pas une bibliothèque standard du C, au contraire de BigInteger de Java. Out of the box tu as tout ce qu'il te faut en Java. En C il va falloir que tu fasses des recherches sous Google pour trouver les références d'une bibliothèque, qui ne sera pas forcément GMP d'ailleurs, et qui ne sera pas forcément aussi performante.
A l'origine d'ailleurs la classe BigInteger faisait appel à du code en C ou C++ (mais sans assembleur) puis les gars de SUN se sont aperçu que leur nouvelle implémentation Java était pratiquement aussi rapide et même plus rapide pour des calculs sur des petits nombres, pour lesquels le coût d'appel à une lib externe devenait non négligeable par rapport à la durée du calcul proprement dit. Ils ont donc préféré garder la version Java qui offre au final on a une classe intégrée, relativement performante et surtout indépendante de l'architecture.
Il existe peut-être des lib Java non intégrées au JDK plus performantes dans ce domaine (JScience peut être une piste). Et comme je l'ai déjà dit, si le besoin s'en fait sentir tu peux très bien faire une belle interface Java pour GMP (et l'appeller libJavaGMP!) et tu auras quasiment les mêmes perfs que le programme C. Mais tu perdras en portabilité (ça peut ne pas être un problème) et dans le cadre de ces benchmarks beaucoup de monde risque de trouver, à mon avis à raison, que permettre au programme Java d'appeler du code externe C/assembleur ne permet pas d'avoir une vue représentative des perfs du langage en lui-même qui sont pourtant visiblement un des buts de ces benchmarks.