Discussion :

[pcaboche]

Sans même parler d'implémentation, le test est tellement peu représentatif de la réalité qu'on se dit qu'on est bien Vendredi

Vu la méthodologie utilisée et les conclusions de l'étude, j'ai plutôt cru à un poisson d'Avril.

[marsupial]

En langage proche de la machine, il s'agit de la majorité du code qui doit s'exécuter en mémoire. En Java, a priori, il s'agit de l'inverse.

Un comparatif Java vs ASM + random C peut-il être fait sur le même algorithme ?
Par curiosité d'abord. Orientation technique ensuite. Suivant le résultat, même dans le cas de quelques cycles gagnés, ces quelques cycles sont primordiaux à grande échelle, ou, pour savoir à armes égales, qui meurt.
De par mon expérience, l'ingénierie mécanique a fait gagner une demi-seconde. Des années lumières faisant la différence sur le champs de bataille.

La différence entre la vie et la mort. La victoire et la défaite.

[AdmChiMay]

Écriture, quel intérêt ? C'est "un peu" comme l'affichage. On a fait ses calculs, on emballe le tout dans une valise, et hop passe à ton voisin. Le dit voisin prend le paquet (ou plutôt sa référence) et se dé…patouille dans son coin.

Mais, si on a besoin de nouvelles données, alors là oui il vaut mieux minimiser le temps d'attente. Attendez, on me souffle un mot à l'oreillette… ah oui, on suppose que tout est déjà en mémoire ? donc inutile de vérifier la contrepartie lecture ? Donc ils n'avaient plus assez de temps avant la date de rendu du rapport ?

[Bestel74]

Quid de l'utilisation d'un langage bas niveau comme le C ?
(histoire de mieux maîtriser / comprendre ce qu'il se passe)

[Freem]

Ces chercheurs sont moins doués que des auto didactes débutants quand même... Déjà, utiliser des langages qui n'ont pas accès au hard pour vérifier la diff de perfs entre bosser en ram pour écrire d un bloc, ou travailler au fur et à mesure sur le disque est profondément stupide.
Ensuite, utiliser des instructions connues pour avoir un cache... Est ridicule. meme en c, leur test serait débile s'ils utilisaient les fonctions standard (le standard c n'offre que du cache et du bloquant... Obligé de recourir aux appels systèmes si on veut plus de liberte).
Pour finir, concatèner des chaînes, c'est pas vraiment ce que j'appelle du calcul intensif, surtout quand on connaît le nombres d'éléments de la chaîne finale.
Qualifier ce type de foutaises de papier scientifique, ou en faire article...
Me demande pourquoi je passe encore ici de temps en temps... L'espoir sans doute.

[Traroth2]

En gros, leur étude, ça veut dire : "quand la seule opération qu'on veut faire dans le code, c'est écrire sur le disque, ça va plus vite d'écrire directement sur le disque sans faire d'opération en mémoire". C'est assez évident, non ?

[thelvin]

Je vois que la discussion a l'air finie, alors je corrige juste un ptit détail pour la postérité :

Heu... C'est peut être une option d'optimisation mais "a" + "b" + "c" en code java utilise StringBuilder à l'exécution (eclipse, config par défaut, il suffit d'exécuter en pas-à-pas pour le constater).

Le code "a" + "b" + "c" même pas, en fait.
C'est une expression constante, c'est le compilateur lui-même qui va calculer la concaténation. L'exécution se fera à partir d'un binaire, qui contient directement la String "abc" prête à l'emploi, et pas la moindre opération de concaténation.
Et ce n'est pas une option d'optimisation. Soit le compilateur fait ça, soit il compile mal le Java.

Voici un code qui force la concaténation à l'exécution, mais où la concaténation ne crée qu'une seule String en utilisant un seul StringBuilder :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
class Concat {

  static String concat(String a, String b, String c) {
    return a + b + c;
  }

  public static void main(String... args) {
    System.out.println(concat("a", "b", "c"));
  }

}

L'expression n'est pas constante => le compilateur ne la calcule pas lui-même.

Voilà voilà, c'était la minute "fonctionnement avancé de Java" et "Pourquoi quand j'essaie le pas-à-pas dans Eclipse je vois pas ce qu'il dit ?"

[BugFactory]

Je en suis pas sûr d'avoir compris le test.
Quand on essaye d'économiser les accès au disque dur, on essaye de réduire les accès. Par exemple, si on manipule 10Mo de données que l'on doit modifier 4 fois, on essaye de faire les modifications en mémoire avant d'enregistrer une seule fois, plutôt que d'enregistrer entre chaque modification. Ainsi, on écrit 10Mo de données sur le disque dur plutôt que 40Mo.
Ce n'est pas ce que fait leur test, qui dans tous les cas écrit 10Mo de données sur le disque. La seule différence est que dans un cas, la concaténation est effectué avant l'écriture. On teste en fait l'efficacité des pilotes et la fragmentation du disque dur, pas la différence de vitesse entre le disque dur et la RAM.

[bruneltouopi]

Bizarre car cette etude.Je suis assez surpris de cette declaration quand on connait tous l'impact de l'acces repetee au disque dur.
Bref moi je crois a l'utilisation de la memoire ou cache pour optimiser mes applications et cela marche plutot bien.

[Aillyn]

._. je n'arrive pas à accéder au document source.

Cette étude as-t-elle fait des comparaisons entre les HDD et les SSD ?
Les performances sur l'écriture sur SSD pourrait également être intéressante il me semble.

[Paul TOTH]

mouarf, et ça apparaît dans la newsletter

c'est pas sérieux de la part de Développez, même moi qui ne suis pas programmeur Java à temps plein (en fait le moins possible et que pour Android) je connais StringBuilder !

d'autre part, même dans d'autres langages, concaténer 1Mo octet par octet amène forcément de la fragmentation mémoire, c'est du B-A-BA !

[bmayesky]

L'article a été retiré. Voilà qui conclu la discussion.

Il serait bien que le post initial soit modifié en conséquence, la newsletter reprenant la nouvelle, cela va être une pompe à click et à discrédit pour développez.net.

C'est dommage, les questions de performance et d'optimisation des programmes mixant calculs et accès disques sont à la fois intéressantes et très présente dans le développement. Quoique il faudrait peut-être passer à la question des accès en base de données plutôt qu'à l'écriture séquentielle dans un fichier. En tout cas dommage que l'article ne soit plus accessible, autant les commentaires ont bien traité la question Java, autant j'aurais aimé voir le code Python pour ma part.

[pcaboche]

._. je n'arrive pas à accéder au document source.

Ça a été retiré un 1er Avril ?

[didiergm]

" Ils suggèrent donc qu'une connaissance du système et de meilleures pratiques de programmation sont nécessaires pour assurer que les opérations en mémoire puissent atteindre leur plein potentiel. "
C'est pas idiot : savoir à peu près comment fonctionne une machine, l'OS et le langage qu'on utilise permet d'obtenir des gains des performance.

Ca méritait bien une étude

[raphi73]

Ce genre de microbench n'a strictement aucune valeur. Ils auraient du appliquer leur propre conclusion et décomposer et comprendre toute la pile technologique mise en oeuvre par leurs opérations.

En plus de l'erreur String vs StringBuilder, il y a une crasse ignorance du fonctionnement de Java. Ils négligent le potentiel d'optimisation de la VM en n'exécutant les tests que 10 fois chacun. Ils empêchent l'optimisation poussée et de compilation sélective en code machine dont est capable HotSpot. Il devraient donc faire des essais avec un nombre de boucles très élevé et observer la différence.

Par dessus le marcher, ils utilisent Java 6 au lieu de Java 8, la version actuelle. Donc ils font de l'archéologie.

Donc la conclusion devrait plutôt être: si ca va aussi vite avec le disque qu'en mémoire, c'est que votre code est moisi.

[prgasp77]

Cette étude a été démontée sur le forum du Daily WTF quand un lecteur s'est rendu compte que la version "mémoire" de la concaténation de chaîne utilisait la concaténation Java, qui ré-alloue une nouvelle String à chaque fois, copiant le contenu de la précédente et ajoutant le nouveau caractère. En gros, d'après ledit lecteur tout le test s'effondre sur une erreur de String contre StringBuilder.

Le vrai WTF ici est que les auteurs comparent :

1. écrire N jeux de données sur le disque de manière séquentielle
2. concaténer en mémoire N jeux de données en un grand jeu de données PUIS écrire ce grand jeu de données sur le disque.

1. sera toujours* plus cours que 2., quelque soit la technologie employée pour écrire le programme.
* ... sur des architectures classiques

Edit : oops, je n'avais pas lu la seconde page et je paraphrase Traroth2.