Un point de vue intéressant sur l'OLP - page 9

Nouveau commentaire
 
Igor Makanu:

Je suis sûr à 99% que ces codes seront exécutés avec la même vitesse jusqu'à un tact au niveau du processeur - le processeur dispose de l'optimisation, du parallélisme et de tout ce qui se passe au niveau des micro-commandes.

N'obtenez-vous pas un effet négatif ici lorsque vous écrivez du code de n'importe quelle qualité en comptant sur "le compilateur le brossera jusqu'à l'optimal" ?


Vous savez avec certitude que le compilateur fera ce qu'il faut avec un style d'écriture. Avec un autre style, vous devez simplement faire confiance au compilateur pour être plus intelligent.

Compte tenu de la multi-plateforme, des différents compilateurs, etc., je choisis d'être conscient de ce que je fais dans le code.
 
fxsaber:

N'y a-t-il pas un effet négatif lorsque tout code de qualité est écrit dans l'espoir que "le compilateur le brossera à l'optimal" ?

Mes exemples ne sont guère de qualité, ce sont des constructions typiques - je compare depuis longtemps les sources sur githab, les deux exemples tst1 et tst2, les deux sont activement utilisés par les programmeurs

C'est pourquoi je pense que les développeurs de compilateurs ont appris depuis longtemps les constructions de code standard et que ce n'est pas un problème pour les compilateurs.


effet négatif - comme@TheXpert l'a écrit plus haut, il y a des exigences de l'entreprise pour le formatage du code, mais les exigences sont généralement les mêmes - le code doit être compréhensible pour les autres membres de l'équipe, y compris même ceux qui viennent d'arriver.....


fxsaber:

Avec un style d'écriture, vous êtes sûr que le compilateur fera ce qu'il faut. Avec un autre style, vous devez simplement faire confiance au compilateur pour qu'il soit plus intelligent.

Ce n'est pas le compilateur qui est plus intelligent maintenant, mais le processeur lui-même, imho, si nous parlons de code à haute performance - la principale surcharge de performance n'est pas dans les appels de fonction, mais dans les lectures de mémoire (accès à la mémoire) - si vous pouvez remplacer le stockage des données/variables par de petites valeurs calculées, vous aurez (au niveau de l'optimisation des micro-commandes du processeur) un petit gain

... mais tout le reste, imho, est diabolique ))))


SZY : il y a aussi l'optimisation d'un code au niveau du compilateur, je n'ai pas lu assez - tout au niveau d'une supposition, sur le matériel PC je lis périodiquement, depuis longtemps je lis, j'ai écrit l'opinion




fxsaber:

Compte tenu de la multi-plateforme, des différents compilateurs, etc., je choisis d'être conscient de ce que je fais dans le code.

Je n'ai pas le choix alors - en bref : "Je suis un artiste - c'est comme ça que je le vois" )))) , j'espère que je ne vous ai pas offensé.

 

J'ai une règle, après 5 ans le code doit être compréhensible pour le codeur, si non compréhensible, mauvais code.

Et si elle est comprise par les autres, très bien.

 
Valeriy Yastremskiy:

J'ai une règle, après 5 ans le code doit être compréhensible pour le codeur, si non compréhensible, mauvais code.

Et si elle est comprise par les autres, très bien.

Voici ( et ici) un très bon code. Mais je ne le comprends pas. Mon cerveau a cessé de grandir il y a longtemps.

 
fxsaber:

Voici ( et ici) un très bon code. Mais je ne le comprends pas. Mon cerveau a cessé de grandir il y a longtemps.

Les sujets sont compliqués. Tout le monde ne les comprendra pas,) sans parler du code.

 

Oh, quel sujet... Et sans moi... Ce n'est pas bon... Je dois parler.

En ce qui concerne l'article du titre, la prémisse correcte (le code doit être déterministe autant que possible) est utilisée d'une manière très stupide, en comparant l'opération d'addition et l'opération d'accumulation comme exemples. Et la conclusion est que l'opération d'addition est déterministe, elle renvoie toujours le même résultat, alors que l'accumulation ne l'est pas, car le résultat est toujours différent.

Mais, excusez-moi... Ce sont des opérations différentes, et dans les deux cas, les résultats sont parfaitement corrects, et exactement ce que l'on attend respectivement de l'addition et de l'accumulation !

Même l'exemple du générateur de nombres aléatoires - ne peut pas non plus être qualifié de "non déterministe" si l'on considère qu'il s'agit d'une opération avec une composante aléatoire.

Il me semble que l'aspect non déterministe est dû au fait que l'auteur n'attend pas du code ce à quoi il est destiné.


Et la deuxième chose est la lisibilité du code - je trouve l'opération "point d'interrogation" très nuisible et difficile à comprendre. En remplaçant la "question" par un opérateur conditionnel, on obtient un code exécutable avec absolument la même efficacité. Dans ce cas, le code source devient sensiblement plus volumineux, mais aussi beaucoup plus clair. Ce qui, je pense, est un gros avantage.

J'essaie toujours de scinder toutes ces nombreuses expressions logiques en une série d'opérations distinctes avec des résultats intermédiaires. Même si ce code donne lieu à un code exécutable moins efficace, le bénéfice d'une meilleure compréhension est, à mon avis, bien plus important.

 

et c'est le domaine de la programmation orientée vers les arbres de Noël :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }
 
Maxim Kuznetsov:

et c'est le domaine de la programmation orientée vers les arbres de Noël :-)

Si les conditions sont des expressions courtes, c'est bien. Cependant, vous pouvez les séparer en fonctions.

Et dans ces cas-là, je mets toujours un commentaire dans l'en-tête des crochets ouvrants pour que ce soit clair.

 
fxsaber:

Avec un style d'écriture, vous êtes sûr que le compilateur fera ce qu'il faut. Avec un autre, il suffit de croire que le compilateur est plus intelligent.

Il n'y aura aucune différence dans l'exécution de cette

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  

et ceci :

return( a() || b() );

Je suis pour un code facile à lire et à déboguer.

 
Andrey Khatimlianskii:

Il n'y aura aucune différence en faisant cela :

et ceci :

Je suis pour un code facile à lire et à déboguer.

Je n'aime pas du tout ce design en termes de lisibilité et d'encombrement.

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  
12345678910111213
Nouveau commentaire