ckyl a écrit 3877 commentaires

Aucune idée pour le 1000D jamais testé cette gamme. Mon commentaire s'appliquait au "haut de gamme" de la gamme particuliers: xxxD et xxD.

Pour le jargon c'est partout pareil, même pour le tricot :-)

> un Canon 20D de nettement meilleure qualité que le 450D

La je suis pas d'accord. Le 450D est de très bonne qualité. C'est à dire équivalent ou supérieur à un 20D ou 30D.

Tu as quelques différences mineures qui peuvent te faire préférer l'un ou l'autre: solidité/prise en main, mode rafale, proco DIGIC II ou III, résolution du capteur, gestion des ISO un peu plus fine sur le 20D mais les proco récents gèrent un peu mieux le bruit etc. Mais il n'y a rien de transcendant. Les boitiers d'entrée de gamme d'aujourd'hui sont devenu très bon, voir meilleur que la gamme du dessus d'il y a quelques années.

Bref si tu veux de belles photos claque ton pognon dans de bons objos, le boitier ne change pas grand chose à ces prix là. En cherchant un peu sur ebay tu trouves des 20D/30D + canon 17-85 IS USM à <600 euros et là tu as un bon boitier et objo passe partout de tr.ès bonne qualité. Tu rajoutes un 50mm f1.8 pour le portrait à 100 euros et t'es déjà bien équipé pour 700/800 euros. Par contre 400 euros pour un 20D nu, c'est très cher. T'arrives à les sortir à 250/300 euros...

En dehors des fonctionnalités, tu as une vraie différence de qualité et de finition des boitiers et des objectifs entre les gammes. Pour rester chez canon les xxxD (entrée de gamme) sont des boitiers plastique, les xxD sont en magnésium (milieu) et les xD (gamme pro) sont tropicalisés et ultra robustes. Et ca se sent tout de suite à la prise en main.

Un 450D ne survivra pas longtemps dans le sable. Un boitier pro avec objo pro (tropicalisé, avec join etc.) supportera relativement bien les séances dans le sable, sous la pluie, la neige genre http://lh4.ggpht.com/_hVOW2U7K4-M/Sjq-E63GR3I/AAAAAAABCg0/4U(...)

Après ça à un prix à la hauteur du matos... Aller dans la gamme pro n'a pas de sens pour quelqu'un qui laisse tout en auto. C'est ultra cher, assez lourd et encombrant, plus compliqué à utiliser etc. Par contre taper dans le haut de gamme grand publique c'est pas absurde.

> Je vais redire ce qu'il y a sur wikipedia car j'aime bien mon clavier bépo

Le problème c'est que tu as du t'arrêter à la section "basic algorithms"... Les GC de prod, c'est un tantinet moins con et plus optimisé que ça.

Tu crois vraiment qu'un GC passe son temps à scanner toute la mémoire ? Tu as entendu parlé des GC générationels ? Tu as déjà monitoré un vraie application pour avoir les stats des générations et constater combien de fois on scanner la mémoire en pratique ? Quels étaient les bouts de code pathologique contre un GC ? Comme écrire son application pour aider le GC ( http://developers.sun.com/learning/javaoneonline/j1sessn.jsp(...) ) ?

Tu sais qu'on peut faire tout ca de manière concurrente ? Qu'on est pas obligé de faire un stop-the-world pour marquer ni pour contacter ? Qu'on est pas obligé de scanner toute la mémoire modulo un petit overhead mémoire ? Qu'on peut faire du GC en temps réel soft et collaborer avec le GC pour minimiser le jitter ( http://qconlondon.com/london-2008/file?path=/qcon-london-200(...) ) ?

Présentation d'un GC moderne, aka G1:
slides, http://developers.sun.com/learning/javaoneonline/2008/pdf/TS(...)
papier, http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf

Est ce que tu as compris que le problème d'un GC, c'est simplement qu'en général il ne va pas réclamer la mémoire dans les veilles générations sauf si il est à cours à mémoire. C'est aussi simple que ca ! C'est pas génant pour certaines applis, pour d'autres si.

De même tu as beau faire tes jolis malloc/free à la main. Si ton tas devient fragmenté le système ne récupéra pas la mémoire non plus, et bon courage pour compacter à la main...

Après j'ai donné tout les exemples en Java par ce que tu aimes bien dire n'importe quoi sur Java, mais on peut prendre d'autres exemples.

> je trouve que c'est du gâchis.

Du gâchis pour qui ? Le mec il a filé 200 euros à l'état via la TVA, fait vivre un commerçant, canon etc. Tu préfères qu'il garde son fric sur son compte pour que personne n'en profite ? Si le mec est content de son mode tout auto c'est son problème...

Un 40D kit ça reste raisonnable pour du grand publique. C'est pas non plus comme si il avait fait péter un 1DmIII avec la collection de serie L associée.

On retrouve beaucoup ce mode de pensé en France, notamment sur le matos de sport. Il faudrait être bon pour se payer du bon matos... Pourquoi un débutant ne pourrait pas se payer un vélo de descente à plus de 8000 euros si ça lui fait plaisir. Je m'en fou qu'il roule deux fois moins vite que moi avec un vélo deux fois plus cher. Inversement je me fais sécher par des jeunes avec des vélos encore deux fois moins cher. On peut multiplier les exemples à l'infini. Chacun fait ce qu'il veut, si ça leur fait plaisir et que ça fait de mal à personne...

Par ce qu'il faut être bon pour se payer du bon matos ? C'est applicable à tout les domaines ou juste à la photo ? Si les gens on de l'argent ils en font bien ce qu'ils veulent non ?


Deuxièmement, comme dis au dessus un reflex en mode programme sort de très belles photos pour les besoins communs. Incomparable avec ce que peut sortir un compact si tu as l'optique adaptée à ce que tu veux faire. Une bonne optique sortira de meilleures photos qu'une optique moins bonne quelque soit le photographe ou presque.

Après c'est quoi que tu appelles "reflex-numérique-qui-vaut-bien-cher" ? Tu parles de quelle gamme ?

Pas seulement.

Tu peux faire une super compo et tout ce que tu veux avec un compact, mais il n'empêche que, pour rester dans votre exemple, tu ne pourra pas jouer sur la profondeur de champ. T'auras donc un photo sans intérêt avec le compact. Tu ne pourras pas mettre ton sujet en valeur en jouant sur le flou, tu ne mettras pas le grain de peau en valeur avec un piqué de malade juste sur la partie du corps que tu veux etc.
La première fois que tu essayes un reflex c'est justement le portrait qui peut être le plus marquant. Prends un boitier correct avec un caillou adapté genre 50mm f1.2 ( http://www.canon.fr/For_Home/Product_Finder/Cameras/EF_Lense(...) ) et tu m'en diras des nouvelles...

Les compacts actuels sortent de très bonnes photos quand les conditions sont bonnes, que tu veux une profondeur de champs infinie, que tu ne cherches pas à jouer sur l'ouverture ou la vitesse (pour faire un filé ou une photo de nuit par exemple), que tu cherches pas un piqué de malade, que tu peux te contenter d'un autofocus merdique et que tu veux une focale 30..100.

Une paire de bons cailloux sur un reflex c'est totalement autre chose. Pour le boitier les entrés de gamme genre 450D sont devenu très bon pour pas cher, pas besoin de casser la tirelire avec un 5D/1D. Après un bon caillou ça coute un rein mais le plaisir est là...

Je dis ca mais j'ai sorti et sors toujours de très belle photos au compact, c'est juste pas la même activité... Si tout est là; le compact te permet d'immortaliser le moment. Le reflex, lui te permet de vraiment jouer avec le décor et les conditions.

C'est ce qu'ils ont annoncé. Java et Solaris étaient les deux raisons majeures du rachat:


“The acquisition of Sun transforms the IT industry,” said Oracle chief executive Larry Ellison, in a statement. “Our customers benefit as their systems integration costs go down while system performance, reliability and security go up.”

Oracle said it sees “strategic customer advantages” to owning two of Sun’s most popular software products: the programming language Java and the Solaris operating system.


En fait ils continueront à supporter Linux, mais un des buts de l'acquisition de Solaris est de pouvoir maitriser et vendre des serveurs avec toute la pile logicielle pour les serveurs de DB et les serveur d'application Java. Les DB étant très fortement liées au système et Solaris étant bien adapté à ce genre de serveur, il y a peu de risques de le voir abandonné....

Bref l'auteur du journal est à côté de la plaque, Solaris n'est pas un OS desktop (ca avait un peu bougé ces dernières années mais bon) et Oracle l'a racheté pour le domaine dans lequel il excelle: les serveurs haut de gamme. Après il se pourrait aussi qu'Open Solaris ne fasse pas long feu... Lors du rachat de BEA ils n'avaient pas eu beaucoup de scrupules à faire disparaitre des produits disponibles gratuitement pour les intégrer dans des solutions plus grosses (exemple JRockit qui a été perdu dans Oracle Fusion Middleware...)

> tu es plus libre mais certains trucs sont moins évidents, puisque Google te fournit des services de parallélisationsympa, style BigTable + MapReduce).

Amazon ne te fournit pas que des serveurs virtuels (EC2 + EBS). Tu as d'autres services associés comme simpleDB ( = bigTable chez goggle), SQS ou elastatic map/reduce basé sur Hadoop.

Chez amazon tu peux te construire une appli assez indépendante de la plateforme. Si t'aimes pas leur elastic map/reduce tu te déploies un cluster hadoop en 10 minutes, si t'aimes pas SQS tu installes ton service de messaging. Chez google, c'est du code pour google, avec un gros lock-in. Après faut pas rêver, une aplli un peu complexe sur EC2 + EBS + S3 + SimpleDB + SQS migrera pas en une journée...

http://aws.amazon.com/simpledb/
http://aws.amazon.com/sqs/
http://aws.amazon.com/elasticmapreduce/

C'est marrant d'un côté tu nous vends un truc fait complément à l'arrache "hier" "en urgence" "120 minutes" "migration". Et de l'autre tu parles de professionnalisme, de problème de compatibilité, de DSI. C'est pas par ce que t'as réussi à refourguer de l'OOo, que le truc n'en ait pas moins à l'arrache, non testé, implique deux suites etc. Un comble pour quelquu'un que se plaint des problèmes potentiels du pack. Après tu as peux être mal vendu ton truc, mais la j'en plutôt tendance à rigoler...

Dans le vrai monde, tu dépenses du temps ou de l'argent pour descendre tes concurrents... Racheter des boites concurrentes pour les couler c'est dans l'air du temps (hint: Oracle VS Virtual Iron).

Produire quelque chose de mieux n'est pas forcement important; ce qui l'est c'est que ça se vende et que ca rapporte du pognon. En fait, même si ca se vend pas mais que ca rapporte c'est bon aussi...

Tu as déjà participer à des WG à l'IETF ? Si on suit ta logique on peut aussi leur demander d'arrêter de publier des RFC... Tu n'as qu'à remplacer Mozilla, Microsoft, Apple et consort par Cisco, Comcast, Juniper, Alcatel et consort.


Le W3C c'est tout petit en lui même. Les choses "intéressantes" se font dans les WG et par définition c'est un travail collaboratif: http://www.w3.org/2000/09/dbwg/details?group=40318&publi(...)

Si on était dans le sens inverse avec tout le monde ok pour h264 sauf mozilla est ce que tu aurais la même réaction ?

Je ne te dis pas que je suis satisfait de la décision, mais se facher avec apple ne couterait que 68500$/an au W3C. L'enjeu de garder son rôle ou de ne pas envenimer la situation est peut être plus important pour eux... C'est le rôle du board de prendre ces décisions et ils doivent avoir leurs raisons.

> Le W3C s'en préoccupe uniquement parce qu'Apple est une grosse entreprise.

Le W3C se préoccupe de l'avis d'Apple par ce qu'Apple est membre du W3C, participe au WG html5 depuis presque le début et est un navigateur du Top 5.

Tu vis dans le monde des bisounours pour penser que les instituts de standardisation n'ont aucun rapport avec les industriels ?

Quelque soit l'organisme le lobbying est et restera la règle. Quand on paye pour faire marcher un organisme et qu'on paye des gens pour bosser dans les WG c'est pas uniquement pour les beaux yeux de la princesse. Si tu sors un standard qui n'est pas suivi, il ne sert à rien et tu es mort. De leur côté, chaque participant cherche à trouver son intérêt. Tout l'art du compris et du rapport de force.... Ca à vraiment rien de spécifique au W3C...

Dans 9x% des cas, ce n'est pas le mode distribué qui est intéressant. Ta situation est exactement la mienne. En contexte pro, sur un repository centralisé (backend SVN en plus), avec ton le monde dans les mêmes locaux. Bin tout ceux qui ont gouté à git ne sont jamais revenu en arrière. C'est d'une souplesse incroyable pour développer en local. Pour moi tu as le même saut de productivité entre editeur de texte -> IDE qu'entre SVN -> git.

Ca demande un petit temps d'apprentissage, mais ca en vaut largement le coup.


Je te parle de git par ce que c'est celui que j'utilise, mais ca doit être aussi vrai avec mercurial ou d'autres.

git (ou n'importe quel SCM pratique) est ton ami et tu n'auras plus jamais ce genre de problèmes.

Je dois en effet créer entre une et dix branches par jour... Exemple: une branche locale pour chaque ticket sur BTS comme ca tu peux passer d'un truc à l'autre sans aucun problème.


Pour ce qui est du refactoring, notre ami yellowiscool montre encore une fois qu'il parle beaucoup sans savoir grand chose... Quand tu refactores une méthode tu renomes la définition et les appels. Je te souhaite bon courage avec ton expression régulière pour distinguer A.getName() de B.getName(). La seul exception c'est pour refactorer des noms de package ou de classe dans de gros projets, ca marche avec des regexp et ca peut être plus simple. Eclipse (y'a ~2 ans) avait un peu de mal à changer 4000 classes en même temps. IDEA lui y arrivait, mais c'était tout de même plus rapide en shell pour combiner les étapes.

Marrant comment certains étudiants/stagiaires arrivent en disant que les IDE ca sert à rien et surtout sans savoir s'en servir. J'en ai jamais vu un garder son emacs/vim/ed :-)

Évidement il faut un IDE adapté au langage...

Tu peux définir un répertoire pour tes plugins. C'est d'ailleurs une facon de faire une mise à jour sans perdre tes plugins.

Pour 99.99% des projets c'est futile comme problème. Le HPC est un monde à part où écrire un compilo dédié ou du code jetable avec la machine peut encore avoir un sens :-)

Cela dit ça peut paraitre bête comme info, mais tu peux vite avoir des surprises. Itérer dans le mauvais sens sur un tableau multidimensionnel peut faire très mal aux perfs. De même savoir comment sont gérés les tableaux multidimensionnels en Java (types primitifs inclus) peut t'éviter de fâcheuses surprises plus tard.

> Si critiquer le travail, c'est insulter, je te souhaite bien du bonheur.

Il y a critique objective, et critique bête, méchante et non justifiée. Quand tu dis qu'un GC est une abbération; t'as pas l'impression de dire à quelques milliers de mecs qu'ils sont vraiment incompétents ? Idem avec ta remarque sur Eclipse. Tu as peut être une comparaison objective et factuelle à proposer ? Ou une vraie expérience à partager ?

> Si t'avais lu le passage du code sur mon power pc, tu serais que c'est le code posté par un autre gars juste au dessus de mon message.

Donc par chance le gars il a écrit exactement le même code que toi. C'est un coup de bol quand même !

Puisque c'est le même tu peux regarder mon bench plus haut ou tout les paramètres sont fixés et connus de tous. Tu peux le reproduire chez toi. J'ai refait tourner en natif et en Java x86 et x86_64 (même code, config, proc que plus haut):

$ file x86*
x86: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ time ./x86
user 0m15.097s
sys 0m0.012s
$ time ./x86_64
user 0m7.143s
sys 0m0.012s
$ time ~/java/x86/sun/jre1.6.0_14/bin/java -server -cp Dev/workspace/Test/bin/ TestRec
user 0m4.272s
sys 0m0.028s
$ time ~/java/x86_64/sun/jre1.6.0_14/bin/java -server -cp Dev/workspace/Test/bin/ TestRec
user 0m7.802s
sys 0m0.035s


C'est reproductible, tout est fixé. De ce test je retire:
- Que tu as des résultats extravagants et que tu ne cherches pas à savoir pourquoi.
- Que le test est vraiment merdique pour prouver quoi que ce soit. Pourquoi l'avoir écrit ?
- Que chez moi le temps d'exécution en x86 de la version C est 4x plus lente qu'avec un JRE x86. Je peux donc dire que le devs de linux sont vraiment trop cons de coder en C...
- Que les mecs d'apple qui ont fait le JIT ont pu faire nawak (ou les sous traitants)
- Que les powerpc peuvent ne pas aimer du tout la récursion, faudrait regarder la tête du code machine généré par gcc. Un coup d'objdump c'est vite fait...
- Que ne pas avoir à pusher ebp à chaque appel de méthode en x86_64 fait doubler les perfs par rapport à de l'x86, sont pas bête chez AMD.
- Qu'il faudra que je trouve une explication à la perf du JRE x86

Sur ce j'arrête là.

Toi qui donnais des leçons aux mecs de mozilla et d'eclipse. Tu devrais soit montrer que tu fais bien mieux, soit chercher à comprendre ce qu'il ce passe. Après tu utilises ce que tu veux je m'en fou, mais ne crache pas sur les autres quand tu n'as rien pour te justifier.

> Je te dit pas si j'avais fait le truc présenté sérieusement…

Pourquoi parler si ce n'est pas sérieux (et que ce n'est pas un truc marrant) ? Tu généralises et te permets d'insulter des devs a partir d'un test reprśentatif de rien du tout, que tu n'as toujours pas présenté, qu'on ne sais comment il a tourné et sur une archi exotique. Ça t'étonne qu'on le fasse remarquer ?

> Le score sur mon power pc est assez parlant.

Ce n'est pas du tout "parlant". Tu aurais voulu que ca le soit tu aurais posté ton code et on aurait pu valider en moins de 5 minutes le problème...

>La prochaine fois, je foutrais un lien si facile comme http://shootout.alioth.debian.org/

Étant donné que les conclusions de ton "test" et du shootout sont totalement opposés la prochaine fois il vaudrait mieux en effet...

Notre ami fait tourner son truc sur un powerpc G4. Hotspot n'a jamais eu de backend pour powerpc supporté ou pblié par Sun.

Je ne sais pas qui a développé le backend utilisé avec OS X sur g4/g5 mais je pencherais pour Apple, au moins en parti, puisque le code ne s'est pas retrouvé dans OpenJDK...

> La seule chose qui change avec le miens

Mais dans ce genre de bench TOUT rentre en compte, de la moindre valeur de retour, à la version du compilateur et des options de compile. Ca vaut deja que dalle ces benchs en temps normal mais là...

Le code ci dessus, et on va s'y tenir, en C ca donne ca:


void rec(int val) {
if (val == 0)
return;
rec(val - 1);
}

int main(void) {
for (int i = 0; i < 655536; i++) {
rec(5000);
}
return 0;
}


une fois compilé en -O1 par gcc ca donne ca:


000000000040047c :
40047c: 48 83 ec 08 sub $0x8,%rsp
400480: 85 ff test %edi,%edi
400482: 74 08 je 40048c <rec+0x10>
400484: 83 ef 01 sub $0x1,%edi
400487: e8 f0 ff ff ff callq 40047c
40048c: 48 83 c4 08 add $0x8,%rsp
400490: c3 retq

0000000000400491 :
400491: 53 push %rbx
400492: bb 00 00 00 00 mov $0x0,%ebx
400497: bf 88 13 00 00 mov $0x1388,%edi
40049c: e8 db ff ff ff callq 40047c
4004a1: 83 c3 01 add $0x1,%ebx
4004a4: 81 fb b0 00 0a 00 cmp $0xa00b0,%ebx
4004aa: 75 eb jne 400497 <main+0x6>
4004ac: b8 00 00 00 00 mov $0x0,%eax
4004b1: 5b pop %rbx
4004b2: c3 retq


Tu passes en -O2, et la magie du data flow analysis:


0000000000400480 :
400480: f3 c3 repz retq
400482: 66 66 66 66 66 2e 0f nopw %cs:0x0(%rax,%rax,1)
400489: 1f 84 00 00 00 00 00

0000000000400490 :
400490: 31 c0 xor %eax,%eax
400492: c3 retq


Super le bench... Tu as tellement peu d'instructions dans un microbench que n'importe quelle modif peut vraiment tout changer.

Bon maintenant si tu compares une exécution du code donné par bad sheep en C (cf plus haut) et en Java (cf poste précédant), gcc 4.3.2 en -01 et un OpenJDK 1.6.0_0-b14 sur un C2D P9400, :


$ time java -server -cp Dev/workspace/Test/bin/ TestRec

real 0m7.983s
user 0m7.882s
sys 0m0.029s

$ time ./O1

real 0m7.206s
user 0m7.156s
sys 0m0.008s


Si tu veux la sortie assembleur d'Hotspot je te la file. C'est la même chose que gcc modulo quelques optims sur la gestion des boucles.

Plus tu réponds plus tu montre que tu ne comprend absolument pas ce que tu fais et que tu n'as aucune rigueur. Tu peux continuer à cracher sur les mecs de mozilla ou d'eclipse, mais moi à ta place je me retiendrais...

...mais attend beaucoup plus avant de faire passer le JIT (1000 contre 10000 passages IIRC). Le mode client ou serveur ne change pas énormément le temps de démarrage, par contre le compilateur JIT fait des choses beaucoup plus complexes: http://java.sun.com/products/hotspot/whitepaper.html#client. Sur un bench tout con avec juste un main, tu passes très peu de temps dans le JIT (-XX:+PrintCompilation) donc le temps de chargement est très court quelque soit le mode (~0.2s chez moi). Par contre sur une vraie appli le warmup sera plus lent le temps de profiler/compiler/profiler/recompiler/etc. tout ce qu'il faut.

Ca sert a rien de chercher ce qui va pas ou des options magiques, si il veut comprendre il donnera son code... Tout le monde semble d'accord pour dire que c'est un résultat très inhabituel.

Ici tu as des mecs qui ont codé un peu plus que des TP d'IUT; qui sont certainement capable d'écrire du C bien mieux que toi et qui en plus sont compétents en Java. Tu penses pas que tu devrais réfléchir un peu ? De plus tu découvriras aussi le compromis plus tard. Si je peux faire 30% plus rapide mais que ca demande 50% de budget en plus est ce que j'y gagne ? La rapidité n'est qu'un critère il y en a de nombreux autres, techniques ou pas.

Revenons à nos moutons, tu ne comprends pas que le code que tu as pondu (et qu'on a toujours pas vu) doit cumuler les cas pathologiques qui ne se retrouvent pas dans une vraie appli ? Tu ne comprends pas pourquoi ton test est mauvais ? Il n'y a que des imbéciles qui disent que Java est facile. Il faut apprendre comment ca marche. Certains concepts sont propres à l'OOP, d'autres à a spécification de la JVM, du langage Java ou à une implémentation particulière. Il faut les maitriser, et c'est parreil avec toutes les technos. Par contre java n'est pas piégieur (l'API de la libc est ultra casse gueule par exemple).


Tu parles tu temps d'appel d'une fonction ok, mais c'est quoi un appel de fonction ? Quelle est la sémantique en C et en Java ? A ton avis tout les appels de méthodes suivants sont ils équivalents ?


private void a() {}
public void b() {}
public final void c() {}
public static void d() {}


La réponse est bien évidement non. X.b() est un appel de méthode virtuel alors que tout les autres seront des appels finaux. Dans le cas d'un appel virtuel tu as des opérations supplémentaires pour déterminer le type réel de l'objet et appeler la bonne méthode:


010 B2: # B6 B3 <- B1 Freq: 0.999999
010 movq R11, precise klass Virt: 0x0000000000d5b7d8:Constant:exact * # ptr
01a cmpq R10, R11 # ptr
01d je,us B6 P=0.500000 C=-1.000000
01d
01f B3: # B11 B4 <- B2 Freq: 0.499999
01f movq R11, precise klass Virt2: 0x0000000000d5b9e8:Constant:exact * # ptr
029 cmpq R10, R11 # ptr
02c jne,us B11 P=0.000001 C=-1.000000
02c
02e B4: # B12 B5 <- B3 Freq: 0.499999
02e movq RBP, RSI # spill
031 # checkcastPP of RBP
031 movq RSI, RBP # spill
034 nop # 3 bytes pad for loops and calls
037 call,static Virt2::b
# Main::doit @ bci:1 L[0]=RBP
# OopMap{rbp=Oop off=60}
03c
03c B5: # B8 <- B4 Freq: 0.499989
# Block is sole successor of call
03c movq RSI, RBP # spill
03f jmp,s B8
03f
041 B6: # B13 B7 <- B2 Freq: 0.499999
041 movq RBP, RSI # spill
044 # checkcastPP of RBP
044 movq RSI, RBP # spill
047 call,static Virt::b
# Main::doit @ bci:1 L[0]=RBP
# OopMap{rbp=Oop off=76}
04c


Ce n'est pas si couteux que ca mais sur un microbench tu peux le sentir. Contrairement au C++, en Java les méthodes sont virtuelles sauf si private/static/final. La JVM est tout de même assez intelligente, ici elle se passe d'un call,dynamic et préfere deux call,static conditionnels. De plus si une classe n'est pas sous classée ca devient un appel non virtuel:


014 B2: # B7 B3 <- B1 Freq: 0.999999
014 nop # 3 bytes pad for loops and calls
017 call,static Virt::b
# Main::doit @ bci:1 L[0]=RBP
# OopMap{rbp=Oop off=28}


Et comme Java supporte le dynamic code loading ça peut changer au cours de l'exécution, une autre beauté d'Hotspot...

Ce n'est qu'un exemple de pourquoi ce genre de microbench peut être très trompeur si tu ne maitrise pas parfaitement ton sujet tu peux mesurer deux choses très différentes sans t'en rendre compte.


Maintenant qu'on a vu l'"appel de méthode". Passons à ton bench. Supposons que tu a écris une fonction tail recursive, comme factoriel. Compilé par gcc ça donne ça (-O2):


0000000000400480 <fact>:
400480: 85 ff test %edi,%edi
400482: b8 01 00 00 00 mov $0x1,%eax
400487: 74 0f je 400498 <fact+0x18>
400489: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
400490: 0f af c7 imul %edi,%eax
400493: 83 ef 01 sub $0x1,%edi
400496: 75 f8 jne 400490 <fact+0x10>
400498: f3 c3 repz retq
40049a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)


C'est dommage tu voulais bencher les appels de méthode mais y'en a pas ! L'opti qui est possible en C n'est pas possible en Java. Donc ton bench il sert à quoi ? Tu enfonces une porte ouverte, un jump est plus rapide qu'un callq et toutes les opérations associées. Écrire un tel code en Java c'est une faute, il faut utiliser la version impérative tu auras exactement les mêmes perfs qu'en C ou assembleur.

Je passe sur le fait que ton bench a peu de chances d'être compilé par le JIT étant donné la structure de ton test.

Mais au final tout ca on s'en fou. Hormis si tu bosses dans quelques secteurs bien précis, du code CPU bound t'en écriras pas des masses... Et c'est pas ca qui est important ou qui fera ramer un projet, ça serait trop simple.

T'as pas trouvé un bench plus mauvais et plus pathologique ? Tu cumules:
- un microbench représentatif de rien du tout
- une méthodologie non documentée (sources, outils, procédure de test etc)
- une boucle qui est certainement dans la main. Comment tu fais du JIT sur le main ? Question bonus est ce que hotspot sait le faire ?
- un bench un mode interprété et non en JIT. Aux dernières nouvelles le CompileThreshold c'est 10000 en mode serveur
- un bench sur une tail call récursion qui n'est pas optimisé par Hotspot ce qui explique les stack overflow et la lenteur

Bref ca vaut pas beaucoup plus que du papier WC ton truc. Si tu veux microbencher un truc inutile compare au moins le code machine produit par gcc et par HotSpot (-XX:+PrintOptoAssembly -XX:CompileThreshold=1). Cela dit je pense que ton temps serait mieux investi à apprendre 2 ou 3 trucs.


Pour les perfs de Java sur des trucs bas niveau type calcul numérique tu peux regarder là: http://hal.inria.fr/inria-00312039/en paragraphe 5.2.3. Faut pas généraliser dans un sens comme dans l'autre. Comme toute techno il faut savoir comment ca marche en dessous pour pondre du code rapide, que tu tournes sur une VM ou pas.