Автор Тема: Еще один тест на производительность.  (Прочитано 23528 раз)

trurl

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Еще один тест на производительность.
« : Сентябрь 23, 2016, 10:59:41 am »
Известная задача о ферзях и простой алгоритм.
#include <stdio.h>
#include <time.h>
 
int board[32], count;

int can_place(int row,int col) {
  int i = 1;
  while((i < row) && (board[i] != col) && (abs(board[i]-col) != abs(i-row))) ++i;
  return (i == row);
}

void queen(int row,int n) {
  int col;
  for(col=1; col<=n; ++col)  {
    if(can_place(row,col)) {
       board[row] = col;
       if(row==n) ++count; else queen(row+1, n);
    }
  }
}

void solve(int n) {
  count = 0;
  queen(1,n);
}

int main(int argc, char **argv) {
  int N;
  clock_t starttime, endtime; float runtime;
  N = 13;
  if (argc == 2) N = atoi(argv[1]);
 
  printf("Solving %d Queens Problem ... \n", N );
  starttime = clock();
  solve(N);
  endtime  = clock();
  runtime  =  (endtime-starttime)/1000.0;
  printf(" %d solutions found, t = %f \n", count, runtime );
  return 0;
}
Запускал на разных компьютерах и усреднял относительное время среднепотолочно. За попугая принято время выполнения на BlackBox.
Разные компиляторы от ETH дали сравнимые результаты: 80-90%.
Oberon-07 от akron1 - 40%.
Oxford oberon - 40%, а с выключенным JIT всего 6%.
XDS - 100%, с оптимизацией и отключением проверок - 170%.

Компиляторы С без оптимизации 50-90%, но это неинтересно.
Лучший результат у clang - 220%.
Потом идет PellesC - 200%.
GCC и старенький Watcom - по 160%.
lcc немного не дотянул - 90%.
TinyC -  50%. 

JavaScript от гугла (V8): 100%,от мозиллы: 70%, и просто для интереса, JavaScript без JIT: от 5 до 20%.
LuaJit: 75%, просто Lua 4%.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #1 : Сентябрь 23, 2016, 10:27:01 pm »
Погодите-ка, тут проценты надо считать не по времени, а по скорости расчётов, что ли? Потому-то непонятно, почему 220% времени лучше, чем 50%, ведь это в 4.4 раза медленнее должно быть...
to iterate is human, to recurse, divine

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

trurl

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #2 : Сентябрь 24, 2016, 10:13:46 am »
Ну да, по скорости. 200% - это вдвое быстрее BB, а 50% - вдвое медленнее.

kkkk

  • Full Member
  • ***
  • Сообщений: 135
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #3 : Сентябрь 24, 2016, 12:35:29 pm »
Где версия для Оберона?

trurl

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #4 : Сентябрь 24, 2016, 02:12:49 pm »
MODULE Queens;
IMPORT Out:=StdLog, Kernel;

VAR count:INTEGER;
    board: ARRAY 32 OF INTEGER;

PROCEDURE canplace(row,col:INTEGER):BOOLEAN;
  VAR i:INTEGER;
BEGIN
  i:=1; 
  WHILE  (i < row) & (board[i] # col) & (ABS(board[i]-col) # ABS(i-row)) DO
    INC(i)
  END;
  RETURN i = row
END canplace;

PROCEDURE queen(row, n:INTEGER);
  VAR col:INTEGER;
BEGIN
  FOR col := 1 TO n DO
    IF canplace(row,col)  THEN
      board[row] := col;
      IF row = n THEN count := count + 1 ELSE queen(row+1, n)  END
    END
  END
END queen;

PROCEDURE solve(n:INTEGER);
BEGIN
  count := 0;
  queen(1,n);
END solve;

PROCEDURE Do*(N:INTEGER);
VAR  starttime, endtime:LONGINT;
BEGIN
  Out.String("Solving "); Out.Int(N); Out.String(" Queens Problem") ;Out.Ln;
  starttime := Kernel.Time();
  solve(N);
  endtime  := Kernel.Time();
  Out.Int(count); Out.String(" solutions found t ="); Out.Real((endtime-starttime)/1000); Out.Ln;
END Do;

END Queens.
Вот для BB. Для других приходится переделывать немного.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #5 : Май 07, 2018, 06:17:45 am »
Говорят, Мозилла со свим Rust'ом оченно сильно ускорила свой JS-движок, какие сейчас там результаты этого теста?
to iterate is human, to recurse, divine

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

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #6 : Май 08, 2018, 12:12:07 am »
Говорят, Мозилла со свим Rust'ом оченно сильно ускорила свой JS-движок, какие сейчас там результаты этого теста?
Разве? Вроде бы в servo развивают не js-движок, а рендеринг. Соответственно в FF вошел многопоточный рендеринг из servo, который реально СИЛЬНО ускорил процессинг и отрисовку веба, но js VM тут не приделах.
Y = λf.(λx.f (x x)) (λx.f (x x))

trurl

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #7 : Май 10, 2018, 08:10:10 am »
Да, js в FF быстрее не стал. И в хроме уже не ускоряется. Что интересно, wasm в хроме не быстрее js, а вот в ФФ заметно быстрее, немного обгоняет js хрома.
Пробовал и asm.js через Emscripten. В ФФ заметно ускорение (небольшое, меньше чем от wasm), а в хроме сильные тормоза.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #8 : Май 10, 2018, 09:32:14 am »
А OberonJS даёт какие-то торможения по сравнению с обычным JS?
to iterate is human, to recurse, divine

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

trurl

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #9 : Май 10, 2018, 09:19:13 pm »
Раза в 2 примерно.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Еще один тест на производительность.
« Ответ #10 : Май 10, 2018, 11:28:22 pm »
А OberonJS даёт какие-то торможения по сравнению с обычным JS?
Это смотря как на js писать :-)
Y = λf.(λx.f (x x)) (λx.f (x x))