Требуется разъяснение Специалистов

[pro_berserk]

да, оно и есть.

Но нюанс в том что если не использовать отдельную функцию, результат другой... И не понятно почему...

[Лекс Айрин]

Цель понять почему у меня из-за добавления в алгоритм, операции вычитания двух дат, меняется скорость выполнения циклов вдвое, при чем в лучшую сторону. 560мс против 260мс. Вот что не понятно...

Судя по всему, это заслуга оптимизатора, который во втором случае понимает для чего нужна переменная/ные и просто использует другую, более быструю оптимизацию. Неявные преобразования типов могут как улучшить код, так и сильно просадить время. Тем более, что используется тип cardinal,

[MysticCoder]

Но нюанс в том что если не использовать отдельную функцию, результат другой... И не понятно почему...

я же объяснил почему. потому что при использовании этой твоей отдельной функции перед замером времени выполняется левая функция fpc_get_output которая тоже идет в зачет времени. для проверки влияния этой функции на общий результат предложил тебе использовать вместо Writeln функцию MyWriteln, которая не добавляет эту левую функцию перед вызовом замера времени и предложил провести замеры в этом варианте.

[pro_berserk]

Судя по всему, это заслуга оптимизатора, который во втором случае понимает для чего нужна переменная/ные и просто использует другую, более быструю оптимизацию. Неявные преобразования типов могут как улучшить код, так и сильно просадить время. Тем более, что используется тип cardinal,

Этот результат с выключенной оптимизацией, если включить оптимизацию -03 результат уменьшается еще на 50мс.

я же объяснил почему. потому что при использовании этой твоей отдельной функции перед замером времени выполняется левая функция fpc_get_output которая тоже идет в зачет времени. для проверки влияния этой функции на общий результат предложил тебе использовать вместо Writeln функцию MyWriteln, которая не добавляет эту левую функцию перед вызовом замера времени и предложил провести замеры в этом варианте.

Так эта левая функция fpc_get_output вызывается и без функции Milliseconds в последнем скрине я её отметил, Все что ты посоветовал я сделал результат тот же. Большое Спасибо за советы

[MysticCoder]

Так эта левая функция fpc_get_output вызывается и без функции Milliseconds в последнем скрине я её отметил

да, вызывается, но без функции Milliseconds она вызывается после замера времени и в зачет не идет.

[Лекс Айрин]

Этот результат с выключенной оптимизацией, если включить оптимизацию -03 результат уменьшается еще на 50мс.

Минимальная оптимизация выполняется всегда. Это часть цикла генерации кода. Уже потом, когда код в преобразованном виде, может вызываться отдельный от кодогенератора оптимизатор.

[zub]

write - неппростая функция, изза переменного числа разнотипных аргументов она разворачивается в цепочку вызова нескольких write и получается "ленивое" вычисление параметров. например:

Код: Выделить всё

write('miliseconds: ', SomeFuncWhoReturnMiliseconds(now));

компилятор разверонет в

Код: Выделить всё

write('miliseconds: ');
write(SomeFuncWhoReturnMiliseconds(now));

и время замереется соответственно после write('miliseconds: ');

а если сделать:

Код: Выделить всё

MyCurrentTime:=SomeFuncWhoReturnMiliseconds(now);
write('miliseconds: ', MyCurrentTime);

то время будет замерено перед первым вызовом write, а после него будет только обращение к переменной и вывод ее значения

Вот и вся разница

[pro_berserk]

Большое Всем спасибо, за уделённое мне время.
Единственное, что удалось понять из всего этого дела, что это некий частный случай!
Почему пришел к такому выводу:
Как написал SSerge:

ваш код дал 639..642 на той же машине и компиляторе

Так же запустил сегодня на другом железе: OS: Windows 7 x86, FPC: 3.0.2 i386, Процессор: Intel G620 2.6GHz. И получил одинаковый средний результат с этих двух вариантов кода: 928мс.
Возможно позже, для чистоты эксперимента проверю все это на других Процессорах, OS и архитектурах...
Быть может Лекс Айрин прав и это заслуга оптимизации x64 FPC, а может дело в процессоре...
Возможно я ошибаюсь, но моё мнение: Что на сколько бы ленивой не была функция Write и какие бы доп. функции не вызывала (например fpc_get_output), не может она так влиять на результат выполнения программы (Ускорение выполнения в двое на моем железе Intel i5-4210H).

[SSerge]

это заслуга оптимизации x64 FPC

imho, дело тут не в оптимизации. Навскидку - вот в чем. Есть два очевидных фактора:
1. Программа исполняется достаточно короткий период времени
2. Современный среднестатический процессор работает на пониженной частоте. Чем "продвинутее" - тем на более пониженной. И только с возрастанием нагрузки частота начинает увеличиваться - не сразу, но через некоторое время. Что касается семейства i5, так там аообще волшебная фишка: мало того, что рабочая частота очень сильно занижена, так еще и верхняя частота, до которой он разгоняется, может быть серьёзно выше данных того, что указывается в штатных характеристиках как номинал. Некий маркетинговый ход - "наши 1.6 ГГц Intel делают 2.5 ГГц AMD" (в то время как этот самый интел в процессе разгоняется аж до 3 ГГц, правда ценой перегрева и долго так не удерживается, а АМД лупит от 0,7 до номинальных 2.5-х и выше не может).

Ну так, может быть дело в том, что "быстрый" вариант программы использует CPU на его максимальной частоте, а на остальных частота так и остается на среднерабочей?

[pro_berserk]

Ну так, может быть дело в том, что "быстрый" вариант программы использует CPU на его максимальной частоте, а на остальных частота так и остается на среднерабочей?

Быть может и так, кто эти современные процессоры знает...
Сделал срез производительности процессоров Intel, с установленной Windows 7 x64, запуская на них два варианта этой программки, скомпилированной на FPC 3.0.2 x64 и x86 соответственно:
Часть из них "современными" уже не назовешь...
- G840 2.8 Ghz
- G3220 3.0 Ghz
- E8400 3.0 Ghz
- i3 840 2.8 Ghz
Результат следующий: Время выполнения программки скомпилированной на x64 без вынесенной функции в два раза быстрее. Скомпилированная на x86 время выполнения двух вариантов одинаковое.
Процессоров AMD в распоряжении к сожалению нет. До Linux'a пока не добрался.

И по поводу продолжительности выполнения программы, если счетчик цикла предположим поставить не 10000 а 100000 смысл получается тот же, только время выполнения в 100 раз увеличивается...

[serbod]

GetTickCount64() считает не миллисекунды, а тики, которые могут отличаться от миллисекунд на разных системах. Их периодичность может "плавать" на процессорах с изменяемой частотой и при изменении настроек таймера прерываний. А где-то (в Линуксе, например) вместо тиков считает миллисекунды, запрашивая реальное время у операционной системы.

Используйте Now() и циклы подлинней, на десятки секунд.

[pro_berserk]

GetTickCount64() считает не миллисекунды, а тики, которые могут отличаться от миллисекунд на разных системах.

Данная функция использовалась в самом начале тестов и была использована исключительно для проверки примера из документа по "превосходству" PascalABC.NET
Далее для тестов использовался другой способ, а именно аналог реализации функции Milliseconds из PABC выкладывал в этом сообщении, а по поводу циклов подлиннее писал сообщением выше...
Спасибо за советы...

[SSerge]

Часть из них "современными" уже не назовешь...

вообще-то они все с переменной частотой, исключение, вероятно, составляет только E8400...

Добавлено спустя 2 часа 52 минуты 46 секунд:
pro_berserk
Кстати, подтверждаю разницу во времени исполнения на компиляторе x64 под windows10. Получилась разница 609/875
С одним "но". Опция компиляции -O2 уравнивает скорость исполнения.
И второе "но" - 64 битный компилятор с ключом -al не смог сгенерировать ассемблерный листинг. Компилятор, правда, от CT6.20
32-битная версия отрабатывает строго в два раза медленнее, без разницы между программами.
CPU B970 (2.3 GHz)

[mig-31]

Код: Выделить всё

{$mode objfpc}
Uses sysutils;


var i,j,n:integer;
    s:double;
    tm,tm2:TTimeStamp;

function Milliseconds:LongInt;
begin
  result:=DateTimeToTimeStamp(now).time-tm.time;
end;

begin
  tm:=DateTimeToTimeStamp(now);
  n := 10000;
  s := 0.0;
  for i:=1 to n do
    for j:=1 to n do
      s += 1.0/(i*j);
  writeln(Milliseconds);
end.


CentOS 7 x86-64 551 ms

В Линух вообще процедура замериния не нужна. Можно использовать команду time

Код: Выделить всё

bash-4.2$ time ./project1
real    0m0.565s
user    0m0.564s
sys     0m0.001s


К теме ABCPascalNet, так там у них вообще ничего нового нет. Фактически это Delphi for NET. Любая программа под ним будет с собой тянуть NETFramework или MONO (несколько гигов в придачу). Вся их презентация перекручивание реальных фактов и сокращеннии количества строк кода. Lazarus описали как дизайнер для шлепанья форм а не как RAD IDE, так как у них такого дизайнера нет.Особенно декларация переменных, которая смахивает на Basic, где интерпретатор сам определяет тип переменной, что означает что в определенных участах кода прийдется проверять тип перемемной.

[Vadim]

По поводу плавающей частоты процессора.
Я тестировал эту штуку, правда не на Intel\AMD процессорах, а на ARM, которые в своём стартовом конфиге позволяют указать минимальную-максимальную частоту работы проца. Если указать одно и тоже, максимальное для проца число, то частота плавать не будет.
Так вот, и с плавающей частотой и с фиксированно максимальной, тесты на скорость отрабатывали одинаковое время.