OberonCore
https://forum.oberoncore.ru/

Отключение проверок
https://forum.oberoncore.ru/viewtopic.php?f=2&t=515
Страница 1 из 1

Автор:  PGR [ Вторник, 12 Июнь, 2007 14:45 ]
Заголовок сообщения:  Отключение проверок

Некоторые модули, скомпилированные с отключенными проверками ( DevCompiler.CompileOpt('!!') ) работают медленнее! :?: :?: :?:

Автор:  Илья Ермаков [ Среда, 13 Июнь, 2007 00:31 ]
Заголовок сообщения: 

Надо смотреть конкретный случай... И еще возможны погрешности измерений. Особенно, если идет выделение памяти - тогда иногда инициируется сборка мусора, она сильно сбивает результат от замера к замеру...

Автор:  PGR [ Среда, 13 Июнь, 2007 09:53 ]
Заголовок сообщения: 

Вот конкретный пример -- модуль генерации случайных чисел.
Время выполнения -- 1.8 с, с отключенными проверками -- 3.9 c.

Код:
MODULE RandomNet; (* From Microsoft .NET Framework 2.0 *)

  VAR
    inext, inextp: INTEGER;
    SeedArray: ARRAY 56 OF INTEGER;

  PROCEDURE Random* (): REAL;
  VAR index, inextp1, num: INTEGER;
  BEGIN
    index := inext;
    inextp1 := inextp;
    INC(index);
    IF index >= 56 THEN index := 1 END;
    INC(inextp1);
    IF inextp1 >= 56 THEN inextp1 := 1 END;
    num := SeedArray[index] - SeedArray[inextp1];
    IF num < 0 THEN INC(num, 2147483647) END;
    SeedArray[index] := num;
    inext := index;
    inextp := inextp1;
    RETURN num * 4.6566128752457969E-10;
  END Random;

  PROCEDURE InitSeed* (seed: INTEGER);
  VAR num2, num3, i, j, k, index: INTEGER;
  BEGIN
    num2 := 161803398 - ABS(seed);
    SeedArray[55] := num2;
    num3 := 1;
    FOR i := 1 TO 54 DO
      index := (21 * i) MOD 55;
      SeedArray[index] := num3;
      num3 := num2 - num3;
      IF num3 < 0 THEN INC(num3, 2147483647) END;
      num2 := SeedArray[index]
    END;
    FOR j := 1 TO 4 DO
      FOR k := 1 TO 55 DO
        DEC(SeedArray[k], SeedArray[1 + ((k + 30) MOD 55)]);
        IF SeedArray[k] < 0 THEN INC(SeedArray[k], 2147483647) END
      END
    END;
    inext := 0;
    inextp := 21;
  END InitSeed;

BEGIN
  InitSeed(314159)
END RandomNet.


Код:
MODULE RandomTest;

  IMPORT Log, R := RandomNet, WinApi;

  CONST n = 3000;

  VAR M: ARRAY n, n OF REAL;

  PROCEDURE Sum (): REAL;
  VAR i, j: INTEGER; s: REAL;
  BEGIN
    FOR i := 0 TO n-1 DO
      FOR j := 0 TO n-1 DO
        M[i,j] := R.Random();
      END;
    END;
    s := 0;
    FOR i := 0 TO n-1 DO
      FOR j := 0 TO n-1 DO
        s := s + M[i,j];
      END;
    END;
    RETURN s;
  END Sum;

  PROCEDURE Do*;
  VAR tc1, tc2: INTEGER; r: REAL;
  BEGIN
    tc1 := WinApi.GetTickCount();
    r := Sum();
    tc2 := WinApi.GetTickCount();
    Log.Real(r); Log.Ln;
    Log.Int(tc2-tc1); Log.Ln;
  END Do;

END RandomTest.

Автор:  Евгений Темиргалеев [ Среда, 13 Июнь, 2007 18:16 ]
Заголовок сообщения: 

Извиняюсь за оффтопик. ИМХО, правильнее использовать платформенно независимые Services.Ticks() и Services.resolution для замера времени.

Автор:  Евгений Темиргалеев [ Среда, 13 Июнь, 2007 21:08 ]
Заголовок сообщения: 

Массив сделал 5000х5000 динамич. Вычисления в Sum обернул циклом - повторить 30 раз.

Пробовал: оба модуля компилировать (!!) и с обычными опциями. При компиляции без проверок идет потеря 3 команд (CMP, JA, "TRAP") на каждый индекс. Код без проверок выполнился быстрее. На 100 тиков. При таком-то объеме вычислений.

Потом я переделал n-1 на n во внешнем цикле (для первого индекса). Код поработал-поработал (нарушил структуру кучи скорее всего), потом вылезло illegal memory read, trap в HostFiles (при записи в Log) и BB помер.

Итого: рост производительности стремится к нулю (что вообще-то не новость). А надежность тю-тю... И как Вы думаете, почему у DevCompiler.CompileOpt документация отсутствует? :wink:

Автор:  PGR [ Четверг, 14 Июнь, 2007 00:02 ]
Заголовок сообщения: 

Евгений Темиргалеев писал(а):
Массив сделал 5000х5000 динамич. Вычисления в Sum обернул циклом - повторить 30
раз.

У меня массив сначала тоже был динамическим. Чтобы не было вопросов о влиянии сборщика мусора сделал его статическим.

Евгений Темиргалеев писал(а):
Код без проверок выполнился быстрее. На 100 тиков. При таком-то объеме вычислений.

Непонятно, почему у меня тогда он выполняется медленнее...

Евгений Темиргалеев писал(а):
Потом я переделал n-1 на n во внешнем цикле (для первого индекса). Код
поработал-поработал (нарушил структуру кучи скорее всего), потом вылезло illegal
memory read, trap в HostFiles (при записи в Log) и BB помер.

Ну и чего ещё можно ожидать при отключенных проверках и некорректном цикле?

Евгений Темиргалеев писал(а):
И как Вы думаете, почему у DevCompiler.CompileOpt
документация отсутствует?

А как вы думаете, почему DevCompiler.CompileOpt вообще присутствует в BlackBox? :)

Автор:  Илья Ермаков [ Четверг, 14 Июнь, 2007 00:26 ]
Заголовок сообщения: 

Там есть другие опции, кроме отключения проверок. В частности - включение контроля переполнения элементарных типов. Или исключение символьной информации из объектника.

Автор:  Евгений Темиргалеев [ Четверг, 14 Июнь, 2007 08:08 ]
Заголовок сообщения: 

PGR писал(а):
У меня массив сначала тоже был динамическим. Чтобы не было вопросов о влиянии сборщика мусора сделал его статическим.
Замер времени после создания массива и вопросов нет.
PGR писал(а):
Ну и чего ещё можно ожидать при отключенных проверках и некорректном цикле?
Ничего не ожидать и не отключать проверки :)
PGR писал(а):
А как вы думаете, почему DevCompiler.CompileOpt вообще присутствует в BlackBox? :)
Например, чтобы включить проверку на переполнение. :)

Автор:  Борис Рюмшин [ Четверг, 14 Июнь, 2007 08:13 ]
Заголовок сообщения: 

PGR писал(а):
А как вы думаете, почему DevCompiler.CompileOpt вообще присутствует в BlackBox? :)

В Dev много чего присутствует. :) Однако что-то может быть необходимо разработчикам компилятора и среды, но противопоказанно к применению на практике.

Автор:  PGR [ Четверг, 14 Июнь, 2007 15:54 ]
Заголовок сообщения: 

Попробовал на другом компьютере (Pentium 2, 366 MHz), с проверками и без проверок ~3.5 с. Ранее результаты приводились для Pentium 4, 2.8 Ghz. :? :? :?

Автор:  Борис Рюмшин [ Четверг, 14 Июнь, 2007 16:02 ]
Заголовок сообщения: 

PGR писал(а):
Попробовал на другом компьютере (Pentium 2, 366 MHz), с проверками и без проверок ~3.5 с. Ранее результаты приводились для Pentium 4, 2.8 Ghz. :? :? :?

Показательно. Это означает, что P4 работает хуже P2. :) Код же генерируется один и тот же - для i486. Возможно этот эффект связан с количеством команд попадающих на конвейер... хм...

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/