Это не правильный тест, так как тела циклов разные. Во втором теле есть ещё инструкции cnt-- По этому это не правильный мой тест. С PI считаю более правильным.
Это не правильный тест, так как тела циклов разные. Во втором теле есть ещё инструкции cnt-- По этому это не правильный мой тест. С PI считаю более правильным.
это как раз способ из жизни, тест как нельзя правильный с точки зрения использования и здравого смысла. В любом цикле где мы будем менять размер самого массива будет иеннно такой же код. Пример как нельзя в точку
А вот с PI там и результаты не явно в одну сторону повторюсь, по проверяйте
это как раз способ из жизни, тест как нельзя правильный с точки зрения использования и здравого смысла. В любом цикле где мы будем менять размер самого массива будет иеннно такой же код. Пример как нельзя в точку
А вот с PI там и результаты не явно в одну сторону повторюсь, по проверяйте
Ну как же он правильный? Если в теле цикла больше инструкций, во время итерации выполняется больше кода, лишняя инструкция инкремента. Что увеличивает время выполнения. Это же логично. А когда тела одинаковые, то уже можно смело оценивать обращение к условию цикла.
Ну как же он правильный? Если в теле цикла больше инструкций, во время итерации выполняется больше кода, лишняя инструкция инкремента. Что увеличивает время выполнения. Это же логично. А когда тела одинаковые, то уже можно смело оценивать обращение к условию цикла.
))))
Он не правильный по всем канонам. У вас между запусками (по чаще по запускайте, сделайте компиляцию еще по запускайте - один способ), дак у вас между запусками разница в вычислениях у одного способа больше чем исповедуемая величина. Разница же есть из-за текущий задач от системы. Т,е. доля исследуемой величины слишком мала, чтобы её увеличить надо увеличить количество этих функций в теле.... и взять самую дешевую операцию. И это умножение!... другого пока не нашел. К примеру в том моем примере используется одно деление - что во много раз меньше чем способ вычисление пи, там где также используется привидение типов (довольно дорогой процесс).
Он не правильный по всем канонам. У вас между запусками (по чаще по запускайте, сделайте компиляцию еще по запускайте - один способ), дак у вас между запусками разница в вычислениях у одного способа больше чем исповедуемая величина. Разница же есть из-за текущий задач от системы. Т,е. доля исследуемой величины слишком мала, чтобы её увеличить надо увеличить количество этих функций в теле.... и взять самую дешевую операцию. И это умножение!... другого пока не нашел. К примеру в том моем примере используется одно деление - что во много раз меньше чем способ вычисление пи, там где также используется привидение типов (довольно дорогой процесс).
Ещё раз. Тестируется не тело цикла, а условие цикла. Чтобы замерить выполнение условия, тела циклов должны быть одинаковыми. Иначе время замеров будет разное, так как тела выполняется с разным временем. Что и получили в данном случае, так как есть лишняя инструкция cnt--
voidOnStart()
{
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();
}
В общем оказываться еще чередования между прощением и бинарным сдвигом (что одна из самых дешевых операций) тоже влияет на подсчет.... Ну и разницы нет, таков вердикт
Ещё раз. Тестируется не тело цикла, а условие цикла. Чтобы замерить выполнение условия, тела циклов должны быть одинаковыми. Иначе время замеров будет разное, так как тела выполняется с разным временем. Что и получили в данном случае, так как есть лишняя инструкция cnt--
В обще то тот мой текст был именно про способ с числом пи
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Это не всегда работает.
Это не правильный тест, так как тела циклов разные.
Во втором теле есть ещё инструкции cnt--
По этому это не правильный мой тест.
С PI считаю более правильным.
Это не правильный тест, так как тела циклов разные.
Во втором теле есть ещё инструкции cnt--
По этому это не правильный мой тест.
С PI считаю более правильным.
это как раз способ из жизни, тест как нельзя правильный с точки зрения использования и здравого смысла. В любом цикле где мы будем менять размер самого массива будет иеннно такой же код. Пример как нельзя в точку
А вот с PI там и результаты не явно в одну сторону повторюсь, по проверяйте
это как раз способ из жизни, тест как нельзя правильный с точки зрения использования и здравого смысла.
В любом цикле где мы будем менять размер самого массива будет иеннно такой же код. Пример как нельзя в точку
А вот с PI там и результаты не явно в одну сторону повторюсь, по проверяйте
Ну как же он правильный?
Если в теле цикла больше инструкций, во время итерации выполняется больше кода, лишняя инструкция инкремента.
Что увеличивает время выполнения. Это же логично.
А когда тела одинаковые, то уже можно смело оценивать обращение к условию цикла.
Ну как же он правильный?
Если в теле цикла больше инструкций, во время итерации выполняется больше кода, лишняя инструкция инкремента.
Что увеличивает время выполнения. Это же логично.
А когда тела одинаковые, то уже можно смело оценивать обращение к условию цикла.
))))
Он не правильный по всем канонам. У вас между запусками (по чаще по запускайте, сделайте компиляцию еще по запускайте - один способ), дак у вас между запусками разница в вычислениях у одного способа больше чем исповедуемая величина. Разница же есть из-за текущий задач от системы. Т,е. доля исследуемой величины слишком мала, чтобы её увеличить надо увеличить количество этих функций в теле.... и взять самую дешевую операцию. И это умножение!... другого пока не нашел. К примеру в том моем примере используется одно деление - что во много раз меньше чем способ вычисление пи, там где также используется привидение типов (довольно дорогой процесс).
))))
Он не правильный по всем канонам. У вас между запусками (по чаще по запускайте, сделайте компиляцию еще по запускайте - один способ), дак у вас между запусками разница в вычислениях у одного способа больше чем исповедуемая величина. Разница же есть из-за текущий задач от системы. Т,е. доля исследуемой величины слишком мала, чтобы её увеличить надо увеличить количество этих функций в теле.... и взять самую дешевую операцию. И это умножение!... другого пока не нашел. К примеру в том моем примере используется одно деление - что во много раз меньше чем способ вычисление пи, там где также используется привидение типов (довольно дорогой процесс).
Ещё раз. Тестируется не тело цикла, а условие цикла.
Чтобы замерить выполнение условия, тела циклов должны быть одинаковыми.
Иначе время замеров будет разное, так как тела выполняется с разным временем.
Что и получили в данном случае, так как есть лишняя инструкция cnt--
В общем оказываться еще чередования между прощением и бинарным сдвигом (что одна из самых дешевых операций) тоже влияет на подсчет.... Ну и разницы нет, таков вердикт
Ещё раз. Тестируется не тело цикла, а условие цикла.
Чтобы замерить выполнение условия, тела циклов должны быть одинаковыми.
Иначе время замеров будет разное, так как тела выполняется с разным временем.
Что и получили в данном случае, так как есть лишняя инструкция cnt--
В обще то тот мой текст был именно про способ с числом пи
Даже боюсь спросить про #define
Давай про дефайн лучше.
Как я понял, он не даёт прироста выполнения в исполняемом файле.
Давай про дефайн лучше.
Как я понял, он не даёт прироста выполнения в исполняемом файле.
Давай. Сначала - дефайн, после - исполняемый файл, дальше - исполнение исполняемого файла.