question for #define experts - page 9

New comment
 
Alexandr Andreev:

This does not always work.


This is not the correct test because the loop bodies are different.
The second body has more instructions cnt--
So this is not my correct test.
With PI I think it is more correct.

 
Roman:

This is not the correct test because the loop bodies are different.
The second body also has instructions cnt--
This is not my correct test.
With PI I think it is more correct.

this is just the way of life, the test is as correct as can be in terms of usage and common sense. In any loop where we change the size of the array itself, there will be exactly the same code. This example is right on the money.

But the PI is there and the results are not obviously one way, check it out.

 
Alexandr Andreev:

This is exactly the way of life, a test that is not correct in terms of usage and common sense.
In any loop where we change the size of the array itself, there will be exactly the same code. This example is right on the money.

But the PI is there and the results are not obviously in one direction.

But how is it correct?
If there are more instructions in the loop body, more code is executed during iteration, an extra instruction is incremented.
Which increases the execution time. It is logical.
And when the bodies are the same, it's already safe to evaluate the reference to the loop condition.

 
Roman:

How is it correct?
If there are more instructions in the loop body, more code is executed during iteration, an extra instruction is incremented.
Which increases execution time. It is logical.
And when the bodies are the same, we can already safely estimate the call to the loop condition.

))))

It's not correct by all canons. You have between runs (run more often, compile more runs - one way), so the difference in computation of one way is larger than the value you're calculating. The difference is due to the current tasks from the system. I.e. the share of the examined value is too small, to increase it you must increase the number of these functions in the body.... and take the cheapest operation. And this is multiplication!... I haven't found another one yet. For example, my example uses one division - which is many times less than the way pi is calculated, where type ghosting is also used (quite expensive process).

 
Alexandr Andreev:

))))

It is not correct by all canons. You have between runs (run more often, compile more runs - one way), so you have a difference in computation between runs for one way more than the professed value. The difference is due to the current tasks from the system. I.e. the share of the examined value is too small, to increase it you must increase the number of these functions in the body.... and take the cheapest operation. And this is multiplication!... I haven't found another one yet. For example my example uses one division - which is many times less than the way pi is calculated, where type ghosting is also used (quite expensive process).

Once again. It is not the loop body which is being tested, but the loop condition.
Loops' bodies must be the same to measure whether the condition is met or not.
Otherwise, the measurement time will be different because the bodies are executed with different times.
Which is what we got in this case, since there is an extra instruction 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();
  }

In general, it turns out that alternating between forgiveness and binary shift (which is one of the cheapest operations) also affects the calculation of.... Well there is no difference, that's the verdict
 
Roman:

Once again. It is not the loop body that is being tested, but the loop condition.
The loop bodies must be the same in order to measure if the condition is met.
Otherwise the measuring time will be different because the bodies are executed with different times.
Which we got in this case, since there is an extra instruction cnt--

Actually my text was exactly about the way with pi

 
I'm afraid to even ask about #define
 
Алексей Тарабанов:
I'm afraid to even ask about #define

Let's talk more about the define.
As I understand it, it doesn't give a runtime boost in the executable.

 
Roman:

Let's talk more about the define.
As I understand it, it doesn't give an increase in execution in the executable file.

Okay. First the define, then the executable, then the execution of the executable.

123456789101112
New comment