Автор Тема: Простейший тест на производительность.  (Прочитано 1705 раз)

Ivan Denisov

  • Jr. Member
  • **
  • Сообщений: 66
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #45 : Сентябрь 20, 2016, 06:32:55 pm »
Ubuntu 16.04 64 bit
wine 1.6.2
Blackbox 1.6

Но в GNU/Linux 64 разрядной версии Blackbox - http://oberon.molpit.com/packs/bbcb_1.7~a1.8_amd64.deb у меня получился тот же результат.

Как выяснилось, вывод у меня тормозил из-за того, что я использую Terminator в качестве эмулятора терминала. В стандартном гномовском вывод не имеет весомой доли.
Не стоит обманываться названием пакета. Это просто сборка для amd64. Приходится разделять из-за проблем с зависимостями.  А сам ББ внутри 32-битный. Проблема из-за того, что не существует пакета gnome-icon-theme-full:i386. Поэтому пакета для bbcb оказалось теперь два. Но зато человеческий диалог выбора файлов :)


Ivan Denisov

  • Jr. Member
  • **
  • Сообщений: 66
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #46 : Сентябрь 20, 2016, 06:56:42 pm »
У меня на bbcb для Ubuntu 14.04 на Core i5-3337U CPU @ 1.80GHz × 4

С проверкой 6.23
Без проверки 3.23

Алексей, еще бы на топовых компиляторах протестировать
https://software.intel.com/en-us/intel-compilers

А этот тест выдерживает критику QWERTYProgrammer ?
http://forum.oberoncore.ru/viewtopic.php?f=61&t=4482&p=82278&hilit=ifort#p82223

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #47 : Сентябрь 20, 2016, 07:15:46 pm »
У меня на bbcb для Ubuntu 14.04 на Core i5-3337U CPU @ 1.80GHz × 4

С проверкой 6.23
Без проверки 3.23

Алексей, еще бы на топовых компиляторах протестировать
https://software.intel.com/en-us/intel-compilers

А этот тест выдерживает критику QWERTYProgrammer ?
http://forum.oberoncore.ru/viewtopic.php?f=61&t=4482&p=82278&hilit=ifort#p82223

Ну, интелёвый компилер далеко не всегда сильно у актуального gcc or clang выигрывает, иногда даже проигрывает.

Да, и изначально тут тест производительности не столько компиляторов и языков как таковых, а связки человек + язык + компилятор. То есть вот да, в меру криворукий программист написал какой-то код на языке X и собрал это дело компилятором Y, какой результат производительности он получит и насколько нетривиальные шаги ему придется предпринять, чтобы ускорить этот код?

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

Если можно пользоваться стандартным массивом (из языка, или стандартной либы) и он не тормозит, это хоршо. Если приходится искать стороннюю либу для массива - это уже плохо. Если же приходится самостоятельно писать код например на Си, оформлять это дело в либу и подключать к проекту на вашем языке для подобных вещей - это ещё хуже.

Если наивная реализация работает достаточно быстро - это хорошо. Если для скорости приходится полностю переписывать реализацию (при том, что алгоритм остается другой) и он становится уже не столь прозрачным для читателя - это плохо.

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

Ну и так далее.

Ну и тестировал я в первую очередь пригодность ocaml и haskell для подобных алгоритмов (с мутабельными данными, а точнее - массивами), камло оказалось более пригодным, хотя haskell в итоге показал результат (по скорости) не хуже.

PS. не забываем, что этот алгоритм - банальная сортировка пузырьком. простейший алгоритм. Если даже для подобного приходится как-то изворачиваться, тратить кучу времени и экспериментов для достижения производительности, переписывать код в другой манере и так далее, то связка язык + компилятор не очень хороша как минимум для быстрого прототипирования, так как по итогам такого прототипирования сама идея может быть забракована, ибо прототип покажет, что производительность получается СЛИШКОМ низкая. Либо придется тратить время на нетривиальное вылизывание кода в сторону производительности, но это противоречит самой идее быстрого прототипирования - это уже не быстро.
Y = λf.(λx.f (x x)) (λx.f (x x))

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #48 : Октябрь 02, 2016, 11:10:23 am »
Я тут немного пошаманил на предмет замера в А2.

MODULE BubbleTest;

IMPORT Kernel, Heaps, Objects, Commands, Machine;

CONST n = 40000;

   PROCEDURE{ALIGNED(16), ALIGNSTACK(16)} DoIt*( context: Commands.Context );
   BEGIN
      DoSafe(context);
      DoUnchecked(context);
   END DoIt;

   PROCEDURE{ALIGNED(16), ALIGNSTACK(16)} DoSafe*( context: Commands.Context );
   VAR
      i, j, tmp: LONGINT;
      mhz, time0, time: HUGEINT;
      arr: ARRAY n OF LONGINT;
   BEGIN
      mhz := EstimateCpuClockrate( );
      time0 := Objects.CurrentProcessTime( );
      FOR i := 0 TO n - 1 DO
         arr[ i ] := n - i;
      END;

      FOR i := 0 TO n - 1 DO
         FOR j := 0 TO n - 2 - i DO
            IF arr[ j ] > arr[ j + 1 ] THEN
               tmp := arr[ j ];
               arr[ j ] := arr[ j + 1 ];
               arr[ j + 1 ] := tmp;
            END;
         END;
      END;
      time := Objects.CurrentProcessTime( );
      
      context.out.String("Safe: ");
      context.out.Int( ( time - time0 ) DIV ( 1000 * mhz), 1 ); context.out.String(" ms");
      context.out.Ln;
   END DoSafe;

   PROCEDURE{ALIGNED(16), ALIGNSTACK(16)} DoUnchecked*( context: Commands.Context );
   VAR
      i, j, tmp: LONGINT;
      mhz, time0, time: HUGEINT;
      arr{ALIGNED(16)}: ARRAY n OF LONGINT;
   BEGIN{UNCHECKED}
      mhz := EstimateCpuClockrate( );
      time0 := Objects.CurrentProcessTime( );
      FOR i := 0 TO n - 1 DO
         arr[ i ] := n - i;
      END;

      FOR i := 0 TO n - 1 DO
         FOR j := 0 TO n - 2 - i DO
            IF arr[ j ] > arr[ j + 1 ] THEN
               tmp := arr[ j ];
               arr[ j ] := arr[ j + 1 ];
               arr[ j + 1 ] := tmp;
            END;
         END;
      END;
      time := Objects.CurrentProcessTime( );

      context.out.String("Unchecked: ");
      context.out.Int( ( time - time0 ) DIV ( 1000 * mhz), 1 ); context.out.String(" ms");
      context.out.Ln;
   END DoUnchecked;

   
   PROCEDURE EstimateCpuClockrate(): HUGEINT;
   VAR
      timer : Kernel.Timer; milliTimer : Kernel.MilliTimer;
      startTime, endTime, timeDiff : HUGEINT;
      nbrOfGcRuns : LONGINT;
   BEGIN
      NEW(timer); nbrOfGcRuns := Heaps.Ngc;
      Kernel.SetTimer(milliTimer, 1000);
      startTime := Machine.GetTimer();
      WHILE ~Kernel.Expired(milliTimer) DO
         timer.Sleep(1);
         IF nbrOfGcRuns # Heaps.Ngc THEN RETURN 0; END;
      END;
      endTime := Machine.GetTimer();
      IF nbrOfGcRuns # Heaps.Ngc THEN RETURN 0; END;
      timeDiff := endTime - startTime;
      RETURN SHORT (timeDiff DIV (1000*1000));
   END EstimateCpuClockrate;

END BubbleTest.

BubbleTest.DoIt ~

BubbleTest.DoSafe~
BubbleTest.DoUnchecked~

SystemTools.Free BubbleTest ~

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1948
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #49 : Октябрь 02, 2016, 05:09:53 pm »
      i, j, tmp: LONGINT;
      arr: ARRAY n OF LONGINT;
У тебя тут длинные целые (64 бита, видимо?), а у валексея и у меня просто целые (32 бита вроде). Это может влиять на скорость...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re: Простейший тест на производительность.
« Ответ #50 : Октябрь 02, 2016, 08:53:35 pm »
      i, j, tmp: LONGINT;
      arr: ARRAY n OF LONGINT;
У тебя тут длинные целые (64 бита, видимо?), а у валексея и у меня просто целые (32 бита вроде). Это может влиять на скорость...
В Обероне LONGINT разве не 32 битные?

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #51 : Октябрь 04, 2016, 11:59:50 am »
      i, j, tmp: LONGINT;
      arr: ARRAY n OF LONGINT;
У тебя тут длинные целые (64 бита, видимо?), а у валексея и у меня просто целые (32 бита вроде). Это может влиять на скорость...
В Активном Обероне LONGINT = SIGNED32, HUGEINT=SIGNED64

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1948
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #52 : Ноябрь 03, 2016, 10:32:07 am »
Попробовал сделать на Rust'е, работает ну очень как-то медленно.
fn print_all(arr: &[i32]) {
    for i in 0..arr.len() {
        println!("{}", arr[i]);
    }   
}


fn main() {
    const N: usize = 40000;
    let mut arr: [i32; N] = [0; N];

    for i in 0..arr.len() { arr[i] = (N-i) as i32; }

    print_all(&arr);
    println!("-----");

    for i in 0..arr.len() {
        for j in 0..arr.len() - 1 - i {
            let tmp = arr[j];
            if  arr[j] > arr[j + 1] {
                arr[j] = arr[j + 1];
                arr[j + 1] = tmp;
            }
        }
    }
    print_all(&arr);
}
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1948
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #53 : Ноябрь 03, 2016, 10:39:06 am »
Попробовал сделать на Rust'е, работает ну очень как-то медленно.
Это я её без опции -O компилил, с этой опцией стало весьма шустро работать.
Алексей, затести и добавь в таблицу результатов ))
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

kkkk

  • Full Member
  • ***
  • Сообщений: 132
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #54 : Ноябрь 03, 2016, 01:20:15 pm »
Можно ещё ускорить с опцией -C ltoВозможно, из-за того, что 0..arr.len()является синтаксическим сахаром для
std::ops::Range {start: 0, end: arr.len()}

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1948
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Простейший тест на производительность.
« Ответ #55 : Ноябрь 04, 2016, 04:14:52 pm »
Нет желающих rust добавить? :-)
Ну я добавил, и что, и где?  :o
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…