Question pour les experts en #define - page 9

 
Alexandr Andreev:

Cela ne fonctionne pas toujours.


Ce n'est pas le bon test car les corps de boucle sont différents.
Le deuxième corps a plus d'instructions cnt--
Donc ce n'est pas mon test correct.
Avec PI, je pense que c'est plus correct.

 
Roman:

Ce n'est pas le bon test car les corps de boucle sont différents.
Le deuxième corps a aussi des instructions cnt--
Ce n'est pas mon test correct.
Avec PI, je pense que c'est plus correct.

c'est le mode de vie, le test est aussi correct que possible en termes d'usage et de bon sens. Dans toute boucle où nous changeons la taille du tableau lui-même, il y aura exactement le même code. Cet exemple est en plein dans le mille.

Mais l'IP est là et les résultats ne sont pas manifestement à sens unique, allez voir.

 
Alexandr Andreev:

C'est exactement le mode de vie, un test qui n'est pas correct en termes d'usage et de bon sens.
Dans toute boucle où nous changeons la taille du tableau lui-même, il y aura exactement le même code. Cet exemple est en plein dans le mille.

Mais l'IP est là et les résultats ne vont pas forcément dans une seule direction.

Mais en quoi est-ce correct ?
S'il y a plus d'instructions dans le corps de la boucle, plus de code est exécuté pendant l'itération, une instruction supplémentaire est incrémentée.
Ce qui augmente le temps d'exécution. C'est logique.
Et lorsque les corps sont les mêmes, il est déjà sûr d'évaluer la référence à la condition de la boucle.

 
Roman:

Comment est-ce correct ?
S'il y a plus d'instructions dans le corps de la boucle, plus de code est exécuté pendant l'itération, une instruction supplémentaire est incrémentée.
Ce qui augmente le temps d'exécution. C'est logique.
Et lorsque les corps sont les mêmes, nous pouvons déjà estimer sans risque l'appel à la condition de boucle.

))))

Ce n'est pas correct selon tous les canons. Vous avez entre deux exécutions (exécuter plus souvent, compiler plus d'exécutions - une voie), donc la différence de calcul d'une voie est plus grande que la valeur que vous calculez. La différence est due aux tâches actuelles du système. C'est-à-dire que la part de la valeur examinée est trop faible, pour l'augmenter il faut augmenter le nombre de ces fonctions dans l'organisme..... et prendre l'opération la moins chère. Et c'est la multiplication ... Je n'en ai pas encore trouvé d'autre. Par exemple, mon exemple n'utilise qu'une division, ce qui est beaucoup moins que la façon dont pi est calculé, où l'on utilise également le type ghosting (processus assez coûteux).

 
Alexandr Andreev:

))))

Ce n'est pas correct selon tous les canons. Vous avez entre les runs (courir plus souvent, compiler plus de runs - une voie), donc vous avez une différence de calcul entre les runs pour une voie plus que la valeur professée. La différence est due aux tâches actuelles du système. C'est-à-dire que la part de la valeur examinée est trop faible, pour l'augmenter il faut augmenter le nombre de ces fonctions dans l'organisme..... et prendre l'opération la moins chère. Et c'est la multiplication ... Je n'en ai pas encore trouvé d'autre. Par exemple, mon exemple n'utilise qu'une division, ce qui est beaucoup moins que la façon dont pi est calculé, où l'on utilise également l'écriture fantôme (processus assez coûteux).

Encore une fois. Ce n'est pas le corps de la boucle qui est testé, mais la condition de la boucle.
Les corps des boucles doivent être les mêmes pour mesurer la réalisation de la condition.
Sinon, le temps de mesure sera différent car les corps sont exécutés avec des temps différents.
Ce que nous avons dans ce cas, puisqu'il y a une instruction supplémentaire cnt--

 
void OnStart()
  {
   int mas[];
   int mas1[300];
   int mas2[300];
   int mas3[300];
   int mas4[300];
   int mas5[300];
   int mas6[300];
   int z=300;
   int size=1000000000;
   ArrayResize(mas,size);
   int r=0;
   int r1=0;
   int r2=0;
   int random;
   ulong max=100; 
   int t=0;
   int tr=0; 
   MathSrand(10);
    int num_steps=ArraySize(mas);
    double x, pi, sum=0.0;
    double step = 1.0/(double)num_steps;
    
     int v=size;
    ulong t1 = GetMicrosecondCount();
     
    
  // for(ulong z=0; z<max; z++)
     {
      for(int i=0; i<ArraySize(mas); i++)
        {  
        r2+=ArraySize(mas);
        r2<<=3;
        }

     }  
   ulong t2=GetMicrosecondCount();
   //for(ulong z=0; z<max; z++)
   int sizem=ArraySize(mas);
     {
      for(int i=0; i<sizem; i++)
        { 
        r2+=sizem;
        r2<<=3;
        
        }
     }
    
   ulong t3=GetMicrosecondCount();
   Print(t2-t1,"  ",t3-t2," ",r2," ",r1);
// Templ();
  }

En général, il s'avère que l'alternance entre le pardon et le décalage binaire (qui est l'une des opérations les moins coûteuses) affecte également le calcul de..... Il n'y a pas de différence, c'est le verdict.
 
Roman:

Encore une fois. Ce n'est pas le corps de la boucle qui est testé, mais la condition de la boucle.
Les corps des boucles doivent être les mêmes afin de mesurer si la condition est remplie.
Sinon, le temps de mesure sera différent car les corps sont exécutés avec des temps différents.
Ce que nous avons dans ce cas, puisqu'il y a une instruction supplémentaire cnt--

En fait, mon texte était exactement sur le chemin avec pi

 
J'ai même peur de demander pour #define
 
Алексей Тарабанов:
J'ai même peur de demander pour #define

Parlons un peu plus de la définition.
D'après ce que j'ai compris, cela ne donne pas un coup de pouce à l'exécution dans l'exécutable.

 
Roman:

Parlons un peu plus de la définition.
Si je comprends bien, cela ne donne pas une augmentation de l'exécution dans le fichier exécutable.

Ok. D'abord la définition, puis l'exécutable, puis l'exécution de l'exécutable.