Discussion :

[wafiwafi]

Bonjour,
Tout d'abord, j'aime bien ce langage et j'ai tendance à le préférer sur d'autres.
Ceci me pousse à méditer un peu plus sur ce dernier sans pour autant le critiquer sans fondements. Il s'agit de mettre en évidence quelques questions qui me sont posées malgré moi.
aujourd'hui, je m'intéresse à la complexité des programmes dans un souci d'optimisation. Seulement, le JVM fait à sa sauce! je dirai même que cela commence à m'agacer dans la mesure ou je n'ai pas vraiment de bases garanties sur les quelles je pourrais m'appuyer en profondeur.
Est ce que c'est le revers de la médaille de la portabilité?
vous me direz peut être qu'il faut se documenter de plus en plus sur la JVM. Je répond que je préfère me concentrer sur la programmation. Et je pense que c'est le cas d'un grand nombre d'utilisateur.
Faut il changer de langage dans ce cas précis?
Je me trompe peut être!
Bien à vous

[tchize_]

heu, mais quelle est la question dans l'histoire?

[wafiwafi]

aujourd'hui, je m'intéresse à la complexité des programmes dans un souci d'optimisation. Seulement, le JVM fait à sa sauce! je dirai même que cela commence à m'agacer dans la mesure ou je n'ai pas vraiment de bases garanties sur les quelles je pourrais m'appuyer en profondeur.
Est ce que c'est le revers de la médaille de la portabilité?

ma réflexion sous entend ma question; pourrait on faire une étude de complexité alors que la jvm fait à sa sauce? qu'en pensez vous?
Merci à vous

[adiGuba]

Salut,


En quoi la JVM en fait-elle à sa sauce ?
Pourquoi ne pourrait-on pas faire d'étude de complexité ?


a++

[tchize_]

oui je comprend pas ou est le problème. Ce que la jvm 'fait à sa sauce' est exactement la même chose que les bidouille que va faire un compilateur C pour optimiser un code. Ca gagnera des performance, mais un code en O(n²) restera un code en O(n²).

[hwoarang]

De toute facon, les compilateurs actuels (ou la machine virtuelle) produisent des codes bien mieux optimisés que la plupart des programmeurs produiraient. Il y a quand meme des 100aines de personnes qui se sont gratté la tete pour les pondre...

Par contre, ca ne dispense pas des optimisations de conception. Si on parcours 10 fois la meme liste qu'on pourrait ne parcourir qu'une fois, le compilateur ou la machine virtuelle ne fera pas des miracles...

[wafiwafi]

Bonjour,
je n'ai aucun recul par rapport à une optimisation professionnelle. Néanmoins, je me pose la question. A priori, Les couches (compilateur, machine virtuelle,...), ne peuvent qu'arranger les choses si j'ai bien compris.
Salutations

[tchize_]

quelles "choses" ?

[wafiwafi]

quelles "choses" ?

optimisation du programme.

[tchize_]

elles vont optimiser les performance, oui (c'est le but) avec des technique comme l'inlining et en réorganisant le code dans certains cas bien précis, mais ca ne changera rien au fait qu'un algorithme mal concu restera mal concu, quel que soit le compilateur.

[adiGuba]

@wafiwafi : j'ai comme l'impression que tu prend la chose du mauvais coté. On dirait que tu cherches des optimisations "magiques", et généralement dans ces cas là on va droit dans le mur...

Avant de penser "optimisation" il faut d'abord concevoir des algorithmes clair et précis, faire des tests de montée en charge, et détecter les éventuels portions de code à l'origine de problèmes de performance.

Tant qu'un problème de performance n'est pas détecté et bien ciblé, les "optimisations" sont contre-productif et pourrait s'avérer encore plus problématique.

a++

[wafiwafi]

j'ai comme l'impression que tu prend la chose du mauvais coté. On dirait que tu cherches des optimisations "magiques", et généralement dans ces cas là on va droit dans le mur...

J'en prends note. Effectivement cela pourrait être problématique!
Les conseils sont pertinents. A moi de méditer sur l'ensemble de cette discussion pour me corriger. Je me pose peut être trop de questions; néanmoins, cela m'a permis par le passé une meilleure maitrise analytique de ce que j'aborde.
Bien à vous

[Jimmy_]

Bonjour,

Il ne faut pas non plus croire a des miracles les optimisations des compilateurs ne remplaceront jamais une optimisation de l'algorithme.

Par exemple le code suivant :

int a = 0;
int b = a;
a = 0;
int c = a;
a = 0;
int d = a;

Une optimisation du compilateur pourra faire ceci :

int a = 0;
int b = a;
int c = a;
int d = a;

Mais c'est tout.

Il ne remplacera jamais 2 boucles imbriquées par une seule. Seul le talent du programmeur pourra le faire.

[adiGuba]

Cela rejoint ce que je dit : il faut travailler ses algorithmes plutôt que de chercher des soit-disant "astuces d'optimisation"...


a++

[_xme_]

juste une petite remarque à contre courant
J'ai dernièrement implémenter un comparateur de ressemblance entre deux chaînes de caractères. J'ai eu besoin de rechercher les mots d'une chaîne dans une autre, et j'ai donc implémenter ce qui, d'après mes lectures, se faisait de mieux, au niveau algorithme dans ce domaine Booyer Moore.
Afin de faire une comparaison, j'ai réfléchi à un rapide algo mais cette fois basé sur les fonctions natives...
Résultat des courses, je me suis fait péter par les fonctions natives (3 fois plus rapide en moyenne ...)
(bon, bien sur, pas n'importe quel fonction native un split rend les performances pourries mais une combinaison de indexof et super performant...)
Du coup où peut-on trouver la complexité des fonctions natives?

[CyberChouan]

Du coup où peut-on trouver la complexité des fonctions natives?

En regardant le code source des fonctions en questions, qui sont fournies dans le JDK.

[hwoarang]

Du coup où peut-on trouver la complexité des fonctions natives?

Aller, comme je suis sympa (et que j'ai les sources sous la main )

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
   public int indexOf(int ch, int fromIndex)
   {
      int max = offset + count;
      char v[] = value;
 
      if (fromIndex < 0)
      {
         fromIndex = 0;
      }
      else if (fromIndex >= count)
      {
         // Note: fromIndex might be near -1>>>1.
         return -1;
      }
 
      int i = offset + fromIndex;
      if (ch < Character.MIN_SUPPLEMENTARY_CODE_POINT)
      {
         // handle most cases here (ch is a BMP code point or a
         // negative value (invalid code point))
         for (; i < max; i++)
         {
            if (v[i] == ch)
            {
               return i - offset;
            }
         }
         return -1;
      }
 
      if (ch <= Character.MAX_CODE_POINT)
      {
         // handle supplementary characters here
         char[] surrogates = Character.toChars(ch);
         for (; i < max; i++)
         {
            if (v[i] == surrogates[0])
            {
               if (i + 1 == max)
               {
                  break;
               }
               if (v[i + 1] == surrogates[1])
               {
                  return i - offset;
               }
            }
         }
      }
      return -1;
   }

[_xme_]

Merci mais je me demandais les fonctions natives ne sont elle pas optimisée plus particulièrement que le reste?
C'est à dire si je copie cette source et que je la mets dans une classe en static suis-je censé obtenir les mêmes perf que la méthod indexOf?

[adiGuba]

Il ne s'agit pas de "fonctions natives" mais d'une simple méthode Java. Il n'y a pas de raison qu'elle bénéficie d'optimisation plus poussé que n'importe quelle autre méthode... Il n'y a rien de "magique" !

La seule différence qu'il peut y avoir avec une méthode "externe" vient du fait que cette dernière ne pourra pas avoir d'accès direct aux attributs de la classe String...

a++

[tchize_]

il faudrais voir l'implementation de votre algorithme pour situer le problème, mais dans les erreur courante que l'on retrouve et qui plombent les performance
-> Créer inutilement (directement ou indirectement) des objets dans une boucle
-> Appeler régulièrement dans une boucle une méthode en la considérant o(1) alors qu'elle est en fait o(n)
-> utiliser un stockage qui n'a pas les performance que l'on pense