djano a écrit 1147 commentaires

Non: Emacs est ecrit en C est peut etre etendu en utilisant du Emacs LISP.

Reference:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

-foptimize-sibling-calls
Optimize sibling and tail recursive calls.
Enabled at levels -O2, -O3, -Os.

Cool je connaissais pas!

Si j'ai bien compris ce qui fait la spécificité de Cerberus, c'est que les tests sont stockes dans la base de données.

J'ai énormément de mal avec ce concept. Ça fait tellement années 80!
Je ne comprends pas que les tests ne soient pas stockes dans un gestionnaire de version. Peut importe lequel d'ailleurs.
Comment comprendre l’évolution des tests? Pourquoi se couper de ces outils fait pour ça?

Je comprend le besoin d'impliquer les 'gens du métiers' pour les tests, mais je ne comprend pas le nivellement par le bas dans la gestion des sources de tests.

N’hésitez pas a me contredire s'il y a quelque chose que je n'ai pas compris.

et vu la rapidité du passage à Python 3 (pourquoi Pyston ne commence pas directement par là ?)

Certainement parce que DropBox (sponsor du projet) travaille avec Python 2.7 en production.
Visiblement ils ne prévoient pas de passer bientôt a Python 3.

oracle-jdk8 est complètement base sur open-jdk8 auquel il rajoute des choses.

Oracle rajoute des babioles vérolées comme le plugin Java pour les navigateurs (a l'origine de nombreuses failles de sécurité), des fontes et des algorithmes propriétaires pour des trucs graphiques dans AWT et Swing, bref des choses qui n’intéressent pas grand monde et qu'IcedTea a remplacé en libre.

Par contre Oracle vient de rajouter Mission Control (qui vient de JRockit) a son JDK, mais pas a OpenJDK. :(

J'avais lu à l'époque une publication sur le sujet qui montrait l'impact que cela pouvait avoir et promouvait le recyclage d'objets à la place de leur destruction par le garbage collector.

Ça expliquerait pourquoi les gars de Grizzly s'amusent a réutiliser les objets HTTPServletRequestImpl et a les relâcher agressivement en faisant disparaître les données dont tu j'avais besoin plus tard :)

Concrètement je n'ai jamais vu de preuve montrant que cela améliorait les perfs, ou bien même que ça les dégradait. Peut être que ça effectivement du sens pour un serveur web avec énormément d’opérations par seconde.

Quoiqu'il en soit, je me demande si de telles techniques ont été utilisées a une époque ou la JVM était moins performante ?

De ce que je comprends, les problèmes sont:

• Les allocations multiples pour tous les objets dans ta classes, et la gestion individuelle de chacun de ces objets avec les problèmes de synchronisation, GC, etc.

• Les multiples références qui ralentissent l’exécution du code (déréférencements a faire)

• L’impossibilité de profiter des instructions vectorielle des processeur pour travailler avec des nombres très grands (> 64 bits, qui est le type "long" en Java, le plus grand géré par la JVM)

Ajouter des value objects permettrait de gérer de tels objets comme un tout ce qui permettrait de boxer/unboxer toute la structure d'un coup au lieu de le faire un champ après l'autre (meilleures perfs), de mieux profiter des lignes de cache des processeurs modernes (perfs++++) et de profiter des instructions vectorielles des processeurs (perfs++).

Personnellement, dans mon travail au jour le jour, ces améliorations auront un impact bien plus faible que si je faisais du calcul numérique.
Malgré tout, l’écriture de classes immuables pour la concurrence en serait facilitée et les perfs améliorées, même si ce n'est pas le cœur de notre problème.

Moi ce qui me ferait réellement plaisir en tant que programmeurs ce serait des tuples a la Python pour facilement retourner plusieurs valeurs d'une fonction :)

Autrement l'approche de Scala me semble la plus pragmatique: au niveau du langage il y a des types correspondants aux types primitifs de Java (Int, Long, etc.), mais qui se comportent comme des classes, ont leur propres méthodes, sont utilisables dans les types génériques. Le compilateur se débrouille après pour utiliser les types primitifs au niveau du bytecode (donc pas plus d'overhead).

Ok pour la praticité pour le programmeur.
Mais justement je me demande en quoi les compilateur Scala ferait mieux que le compilateur Java?
L’exécution se faisant sur la JVM pour les deux langages, les problèmes de perfs de l'un devraient se retrouver également avec l'autre.

Je ne pensais pas a ce genre de code mais a des trucs beaucoup plus bêtes avec des variables locales qui mixent allègrement boxing et unboxing.
Mais en voyant ton benchmark, je me dis que l'optimisation a lqauelle je pensais reste forcement limitée et que ça gêne le calcul numérique.

Au passage, c'est sympa JMH, je ne connaissais pas.
Du coup je me demande si la JVM ne fait pas des optimisations spéciales pour le tableau d'int ? Loop unrolling, etc.

Yep!

C'est sympa ton exemple sur la curryfication, je ne pensais pas que les lambdas pouvaient le faire.
Merci!

Idem, merci pour ces explications!

Je travaille sur OpenDJ, un annuaire LDAP libre avec réplication multi-maîtres, et je me rend compte qu'on lui doit une fière chandelle: la réplication utilise une horloge de Lamport et les vecteurs d'horloges

Il avait été établi qu'une petite partie du code source avait été copiée, javadocs, commentaires, et détails d'implementation. Cela touchait très peu de fichiers, moins de 10 si je ne me trompe pas.
Le juge avait alors ordonné a Google de remplacer ce code copié par du code propre a Google.

julienv, comme Julien Verlaguet ?

J'aime bien linuxfr qui nous met au contact direct des auteurs du code :)

Tu as un lien sur le fichiers dont tu parles? J'ai regarde les commits de ton user sur la page github du projet, mais je ne l'ai pas trouve.

Comme je suis curieux je te pose une petite question: sur quelle partie de Hack travailles-tu ?
Es-tu responsable de l'utilisation de OCaml et js_of_ocaml?

J'ai oublie de dire qu'on dirait que les default methods soient un effet de bord de l'introduction des lambdas qui modifie les interfaces de l'API collection,
Ces interfaces ont ete implementees de nombreuses fois et ces implementations alternatives sont souvent très utilisées.
Ils ne pouvaient pas se permettre de casser la compatibilité ascendante.

Les default methods sont clairement la pour pouvoir faire évoluer les interfaces sans casser la compatibilité au niveau source et binaire.
Avant ça, l’évolution des interfaces suivait 2 approches:

• A la JDBC: changements cassant l'API, nécessitant de fournir des drivers différents pour chaque version du JDK. C'est deja bien gere par les fournisseurs de base de données, et le default methods ne vont probablement pas résoudre ce problème puisque les fournisseurs de drivers devront quand même fournir 2 versions supportant les specificite de chaque version.

• A la Eclipse: Publier une interface IMyInterface, puis itérer lorsque des ajouts sont nécessaires: IMyInterface2 extends IMyInterface, IMyInterface3 extends IMyInterface2, etc.

Bref, c'est pas top, quoique la méthode d'Eclipse a l'avantage de toujours garder la compatibilité ascendante, au prix d'une verbosité et d'une lourdeur sans pareille (même pour du Java).
Les default methods vont résoudre le problème de l’évolution d'interfaces a la Eclipse.

S'ils pouvaient en faire deux de plus pour gérer les "structs à la C" et les types de base dans les generics (et pas via ces horribles wrappers Integer, Float &co), ce serait super !

Oui, les structs a la C ou meme C# sont un sujet chaud en ce moment. Beaucoup de monde le demande. C'est peut-être l'effet d'Android qui a amené beaucoup plus de programmeurs de jeux que le Java Desktop ?
Bref, il me semblent qu'ils parlent d'un truc comme ça pour Java 9 avec les Value Objects: http://openjdk.java.net/jeps/169

Par ailleurs, il me semblait avoir entendu qu'ils optimisaient déjà les collections avec les types primitifs via des intrinsics dans la JVM (pattern de code recevant une optimisation spéciale), ou bien que c’était en projet. Je ne me rappelle plus exactement.

Mais si ça se faisait, rien n'empêcherait le compilateur au besoin d'utiliser directement les types de base dans le bytecode tant qu'il a la garantie que la variable ne peut être null, sans que ça soit au développeur de se poser la question. D'ailleurs, ma connaissance de javac et du bytecode Java est au mieux parcellaire, mais ça ne m'étonnerait même pas qu'il s'agisse d'une optimisation déjà existante…

Heureusement, la JVM sait déjà faire ça bien sur sinon les codes numériques auraient des perfs très très très mauvaises…

Je ne vois pas en quoi les lambdas java ne sont pas DRY. Je ne connais pas assez le C++ pour parler de leur équivalent.

Premièrement les lambdas Java ne sont pas des classes, donc c'est déjà ça en moins.
Pour l'inlining, ça va être exactement comme tu dis. Une lambda simple va très bien être inlinée par le JIT. Une lambda plus complexe ne le sera probablement pas. J'avais lu que la limite pour que le JIT inline une méthode était quelque chose comme 35 opcodes du bytecode Java.

Avant l’introduction des lambdas, dans cet exemple, il fallait définir une implémentation pour Comparator, ce qui était un peu plus verbeux…

C’était aussi moins performant car une lambda ne créera pas de classe sous-jacente, d’où pas besoin de charger une classe, pas besoin de passer par un security manager, etc.
C'est beaucoup plus léger!

Quelqu'un a un retour sur le mélange des lambdas avec un code définissant des generics? (A ne pas confondre avec un code utilisant les generics, c'est a dire qui parametrise les types)
Est ce que cela ne fait pas trop de vilain?

Disparition du Permgen
Le PermGen est remplace par Metaspace dont la taille n'est pas bornée par défaut, ce qui veut dire qu'elle peut grossir indéfiniment. Les Ops préféreront peut-être la borner avec l'option MaxMetaspaceSize de la JVM HotSpot:
http://java.dzone.com/articles/java-8-permgen-metaspace

Oui j'ai la même analyse que toi sur le retour de PHP vers un langage de templating.
C'est out a fait intéressant.

Je n'ai pas dit que les nouveaux types étaient inutiles.
Je suis au contraire convaincu que ne pas les avoir est une mauvaise idée.
Ils rendent la compréhension du code plus claire et améliorent les performances en étant dédiés a une tache et une seule.

En plus si je regarde Java, il y a plusieurs implémentations de List, Set ou Map qui répondent toutes a des besoins particuliers.
Par exemple, je n'aime pas le choix de Go de forcer une et une seule implémentation de Map ou List.

ActiveRecord de RubyOnRails est un exemple: toutes les methodes pour parler a la base de donnees sont codees avec des proxys dynamiques.

Exemple: http://guides.rubyonrails.org/active_record_querying.html

Toutes les méthodes find_by_* sont gérées par des proxy dynamiques et dépendent de la table dans la base données.
Maintenant, de la a aimer… les gouts et les couleurs sont dans la nature.

L'un des gros apports de hack c'est de rendre des types non-nullables, tu l'a ça en Java ?

Je l'attendais celle la.
Oui, par l'utilisation de @NonNull qui va bien, avec l'IDE qui va bien. Et malheureusement ce n'est pas intégré au langage.

Java utilise massivement l'injection de référence, chose impossible en PHP (parce qu'on ne peut pas manipuler de chargeur de classe comme dans la JVM).
Et alors c'est bien ou mal selon toi?

PHP possède une dynamicité que Java n'a pas (comme la possibilité d'avoir une méthode « par défaut » quand on appel une méthode sur un objet avec le mauvais nom - moche sur bien des aspects, pratique pour faire des proxy).
Tout a fait, d'ailleurs je parlais des ajouts de Hack par rapport a ce dont dispose déjà Java.
Quoique les proxy existent aussi en Java même s'ils ne sont pas très dynamique puisque leur utilisation suppose l'existence d'une interface.

Facebook a des problemes avec le codage en PHP, alors ils inventent une version java-ifiee de PHP!

En fait c'est surtout quand j'ai vu les nouveaux types Vector, Set, Map et Pair que je me suis dit ca, en plus des autres changements :)

Bref, les principales differences entre Hack et Java sont: pas de compilation pour Hack, l'utilisation de XHP qui rend le templating plus agreable et aussi plus sur car type.
A part ca, Java savait deja faire beaucoup de chose que Hack apporte au monde PHP.

Appréciable, la page de De Python à Ruby, ça permet de voir les grosses différences. Certaines choses ne sont que syntaxiques, mais d'autres portent sur la sémantique,

Ils comparent avec quelle version de Python?

Les classes old style et new style, ce n'est pas du Python < 3?