The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Проект elk развивает компактный JavaScript-движок для микроконтроллеров, opennews (?), 25-Сен-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


15. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 25-Сен-21, 11:46 
Вчера мне рассказали, что JS — наибыстрый скриптовый язык (ц).
Время вычисления 77-го числа Фибоначчи под node.js не впечатлило https://www.opennet.ru/openforum/vsluhforumID3/125336.html#98
Составило (очень грубо) 0m0,069s
Потом порекомендовали использовать JIT, что замедлило вычисление в 10 раз.

Протестировал на обсуждаемом движке:


$ cat fibonacci.c
#include <stdio.h>
#include "elk.h"
char *script =
    "  let n = 77;"
    "  let a = 1;"
    "  let b = 1;"
    "  let i = 3;"
    "  while (i <= n) {"
    "    let c = a + b;"
    "    a = b;"
    "    b = c;"
    "    i++;"
    "  }"
    "  b;";
int main(void) {
  char mem[500];
  struct js *js = js_create(mem, sizeof(mem));
  jsval_t v = js_eval(js, script, ~0);
  printf("result: %s\n", js_str(js, v));
}
gcc -O2 elk.c fibonacci.c -o fibonacci -lm
$ time ./fibonacci
result: 5527939700884757
real    0m0,002s
user    0m0,002s
sys    0m0,000s

На данной задаче он рвёт Ноду как Тузик грелку.
Ответить | Правка | Наверх | Cообщить модератору

24. "Проект elk развивает компактный JavaScript-движок для микрок..."  +3 +/–
Сообщение от Аноним (19), 25-Сен-21, 12:00 
Так там от JS только название осталось
Ответить | Правка | Наверх | Cообщить модератору

25. "Проект elk развивает компактный JavaScript-движок для микрок..."  +2 +/–
Сообщение от Аноним (-), 25-Сен-21, 12:01 
Тебя реально нельзя пускать к телескопу Хабл или обоим Вояджерам. А то земляне получат изображения внеземных гуманоидов аж в 4К.
ИЗЫДИ, чорт.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

69. "Проект elk развивает компактный JavaScript-движок для микрок..."  –1 +/–
Сообщение от n00by (ok), 25-Сен-21, 14:15 
Уже получили https://pbs.twimg.com/media/FAD62lwXMAMX7pw?format=jpg
Ответить | Правка | Наверх | Cообщить модератору

189. "Проект elk развивает компактный JavaScript-движок для микрок..."  +1 +/–
Сообщение от ммнюмнюмус (?), 25-Сен-21, 22:53 
Дети знаменитого Альфа?
Ответить | Правка | Наверх | Cообщить модератору

216. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 10:14 
Там два поколения.)))

JS-программистов некоторые здесь называют "приматами". В данной теме их активно мешают с землицей. Удивительно, что у кого-то из этих самых мешающих картинка вызвала негатив.

Ответить | Правка | Наверх | Cообщить модератору

255. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 16:24 
Почему негатив. Наоборот, весёлая ассоциация с Альфом. Не хватает только его самого :/ .
Ответить | Правка | Наверх | Cообщить модератору

260. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 17:00 
Так и я не знаю, почему у некоторых она вызвала негатив.)) Может себя там увидели.
Ответить | Правка | Наверх | Cообщить модератору

284. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 21:01 
> Так и я не знаю, почему у некоторых она вызвала негатив.)) Может
> себя там увидели.

LOL, Абсолютно ложный комментарий формата "кто не любит XYZ - тот сам XYZ", дешёвый психологический трюк.
По моим наблюдениям - подобные реплики уже в школе парируются / игнорятся на раз (в моём опыте было другое - общеизвестный ветхий дежурный ответ на любое обзывательство).

Ответить | Правка | Наверх | Cообщить модератору

320. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 27-Сен-21, 16:30 
А по моим наблюдениям, я написал "не знаю". Впрочем, можете написать цену вот сюда https://ru.wikipedia.org/wiki/%D0%9F%D1%...)
Ответить | Правка | Наверх | Cообщить модератору

271. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 17:52 
В прочем, оно и видно, почему мешают с землицей.
Европейские юристы разумеется (равно как и цензурные боты) не понимают.
А те, у кого ещё мозг пока на месте, сразу видят имитацию и приучение у разврату без показа оных.
И пусть только кто вякнет - на своей земли завалят сразу, с других - попытаются выманить на свою территорию, после чего задним числом забанят и запретят въезд.
Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

276. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 18:38 
Гуманоиды и есть. Не понимают, что делают. И не дураки ведь, значит можно посмеяться, пока никто не видит.
Ответить | Правка | Наверх | Cообщить модератору

31. "Проект elk развивает компактный JavaScript-движок для микрок..."  +1 +/–
Сообщение от Аноним (31), 25-Сен-21, 12:11 
Ты же понимаешь, что с node измеряешь накладные расходы на запуск V8, а не производительность вычислений?
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

67. "Проект elk развивает компактный JavaScript-движок для микрок..."  –2 +/–
Сообщение от n00by (ok), 25-Сен-21, 14:06 
Правда? А я думал, "их" сумму.
Ответить | Правка | Наверх | Cообщить модератору

82. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Аноним (31), 25-Сен-21, 14:55 
Ну вот теперь вычти из этой суммы time node -e 'console.log(null)'. Потом останется прогреть функцию, чтобы её обработал оптимизирующий компилятор, и получишь примерную производительность вычислений.
Ответить | Правка | Наверх | Cообщить модератору

85. "Проект elk развивает компактный JavaScript-движок для микрок..."  –2 +/–
Сообщение от n00by (ok), 25-Сен-21, 15:09 
Зачем? У меня задача вычислить 77-е число Фибоначчи, а не что-то там прогреть.
Ответить | Правка | Наверх | Cообщить модератору

97. "Проект elk развивает компактный JavaScript-движок для микрок..."  +2 +/–
Сообщение от Аноним (31), 25-Сен-21, 15:56 
Ты лучше 2×2 вычисли, там результаты time тебя ещё больше порадуют. Только какое это отношение имеет к производительности js?
Ответить | Правка | Наверх | Cообщить модератору

166. "Проект elk развивает компактный JavaScript-движок для микрок..."  +1 +/–
Сообщение от n00by (ok), 25-Сен-21, 19:22 
Сейчас угадаю. Ты посмотрел на моё "На данной задаче он рвёт Ноду как Тузик грелку", в этот момент у тебя в голове что-то щёлкнуло и ты увидел "производительности js". Но что именно и почему у тебя в голове щёлкнуло, я судить не берусь. Вероятно, это как-то связанно с радостью.
Ответить | Правка | Наверх | Cообщить модератору

181. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Аноним (31), 25-Сен-21, 21:06 
Ты действительно не понимаешь, что вычисление числа фибоначчи ближе не к 1% от того, что показывает time, а к 0? Его надо вычислить хотя бы миллион раз, чтобы заметить нагрузку, а лучше побольше.
Прежде чем кичиться своим невежеством, попробуй хотя бы так:

function fib(n) {
  let a = 1;
  let b = 1;
  for (let i = 3; i <= n; i++) {
    let c = a + b;
    a = b;
    b = c;
  }
  return b;
}
const res = [];
for (let i = 0; i < 10e6; i++)
  res.push(fib(77));
console.log(res[10e6 - 1]);

Ответить | Правка | Наверх | Cообщить модератору

190. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 25-Сен-21, 23:02 
Иногда есть соблазн разжевать даже если плохо разбираюсь. Но в последнее время начинаю параноить, что некоторые не помощи ищут, а собирают бигдату для болтологической базы, чтоб использовать против реально полезных и умных людей, которые нечаянно могут сломать кому-то хитрый план (могли бы реально такого болто-бота замутить, похлеще психотерапевта в emacs).
Ответить | Правка | Наверх | Cообщить модератору

217. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 10:22 
Вот это в рамочку и на стену можно вешать, что бы пояснить слово "миллени-ум":

const res = [];

for (let i = 0; i < 10e6; i++)
  res.push(fib(77));

console.log(res[10e6 - 1]);

Мало того, что это какой-то программный мусор, так автор не прочитал в новости, что массивы не поддерживаются.

Ответить | Правка | Наверх | Cообщить модератору

244. "Проект elk развивает компактный JavaScript-движок для микрок..."  +1 +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 15:02 
> Вот это в рамочку и на стену можно вешать, что бы пояснить
> слово "миллени-ум":
> const res = [];
> for (let i = 0; i < 10e6; i++)
>   res.push(fib(77));
> console.log(res[10e6 - 1]);
> Мало того, что это какой-то программный мусор, так автор не прочитал в
> новости, что массивы не поддерживаются.

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

Ответить | Правка | Наверх | Cообщить модератору

248. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 15:27 
Стоп, а что тот мусорного, не считая неподдерживаемых массивов?
Обычное дело при бенчмарках - прогнать кусок кода 10 в большой степени раз. Правда, я бы лучше подсчитал время на весь цикл, а потом поделил бы его, чем пытаться мерять каждый проход, искажая результат ненужными получениями времени (по крайней мере в С, хотя и в вируалках - почему бы и нет, если можно).
Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

254. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 16:22 
> Стоп, а что тот мусорного, не считая неподдерживаемых массивов?

Вы же сами ответили в предыдущем сообщении. "Зачем хранить все результаты, когда нужет только один, последний". Наверное, что бы заполнить 4 (или 8?) миллионов байт ОЗУ и измерить время обработки 1000 ошибок страниц (или сколько их будет?).

> Обычное дело при бенчмарках - прогнать кусок кода 10 в большой степени
> раз.

В данном случае может играть роль количество итераций цикла (их 77). Напомню его:

while (i <= n) {
    let c = a + b;
    a = b;
    b = c;
    i++;
}

Если такое скомпилировать в машинные команды, получится примерно 1 сложение, 2 пересылки, 1 декремент (i++ и i <= n эффективнее заменить уменьшением n и сравнением с 0) и 1 условный переход. 5 команд и 2 зависимости по данным (сложение и 1я пересылка + декремент и переход), то есть процессор потенциально может выполнить по 3-2 команды за такт. В таком случае тело цикла исполняется за 2 такта, а все итерации за 154. Но переход-то условный и на последней итерации предсказатель ошибочно предскажет переход на начало цикла. perf stat про такое выводит примерно следующее:

branch-misses:u           #    4,84% of all branches

Вопрос в том, сколько стоит ошибка предсказателя (branch mispredict penalty) в тактах. Допустим, на современных процессорах 0, а на старых PIV с микроархитектурой NetBurst - 10 (число примерное, точное не помню). 164 отличается от 154 довольно существенно.

Надо понимать, что все цифры я взял от балды, но идея, надеюсь, ясна. Если бы цикл исполнялся 10000 раз, погрешность была бы меньше.

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

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

Это всё так, но якобы ещё Кнут учил: «преждевременная оптимизация — корень всех зол». Я не знаю, зачем этот цикл вообще измерять. Интересно было общее время решения, т.е. включая запуск Ноды.

Когда приходилось заниматься оптимизациями, использовал специальную утилиту. Вот эти цветные прямоугольники на иллюстрации https://studfile.net/html/1357/248/html_3EGMhmYyJl.RtCl/img-...
стадии исполнения команд процессором. То есть можно (было) вполне точно посчитать до тактов без использования команды rdtsc. Ныне процессоры сложнее и подобная симуляция не производится, но профилировщики позволяют находить узкие места. Вот им и стоит уделять внимание. Если узким местом окажется вычисление чисел Фибоначчи, вероятно, эффективнее не измерять цикл, а заполнить предвычисленную таблицу.

Ответить | Правка | Наверх | Cообщить модератору

265. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 17:18 
>> Стоп, а что тот мусорного, не считая неподдерживаемых массивов?
> Вы же сами ответили в предыдущем сообщении. "Зачем хранить все результаты, когда
> нужет только один, последний". Наверное, что бы заполнить 4 (или 8?)
> миллионов байт ОЗУ и измерить время обработки 1000 ошибок страниц (или
> сколько их будет?).

Понятно. В каждом мусоре есть доля мусора))).

>[оверквотинг удален]
>     a = b;
>     b = c;
>     i++;
> }
> Если такое скомпилировать в машинные команды, получится примерно 1 сложение, 2 пересылки,
> 1 декремент (i++ и i <= n эффективнее заменить уменьшением n
> и сравнением с 0) и 1 условный переход. 5 команд и
> 2 зависимости по данным (сложение и 1я пересылка + декремент и
> переход), то есть процессор потенциально может выполнить по 3-2 команды за
> такт.

Это применимо к JS?
Может, на С оно и было, а на JS ещё оверхед на интерпретатор. Если только интерпретатор умеет себя мерять, но я сильно сомневаюсь, что это относится к проекту типа elk-js.
Но и то - на С только при использовании примиттивных неоптимизирующих компиляторов типа tinycc, на gcc и clang без живых измерений не обойтись.

Ответить | Правка | Наверх | Cообщить модератору

269. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 17:44 
>[оверквотинг удален]
>> }
>> Если такое скомпилировать в машинные команды, получится примерно 1 сложение, 2 пересылки,
>> 1 декремент (i++ и i <= n эффективнее заменить уменьшением n
>> и сравнением с 0) и 1 условный переход. 5 команд и
>> 2 зависимости по данным (сложение и 1я пересылка + декремент и
>> переход), то есть процессор потенциально может выполнить по 3-2 команды за
>> такт.
> Это применимо к JS?
> Может, на С оно и было, а на JS ещё оверхед на
> интерпретатор.

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

Ответить | Правка | К родителю #265 | Наверх | Cообщить модератору

215. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 10:07 
Знаешь, как я определил, что ты плаваешь в теме? По двум маркерам:
1. Ты предложил сложить погрешности измерений;
2. Ты понятия не имеешь, как оценить время выполнения предложенного цикла без выполнения.
3. Теперь ты подтверждаешь пункт 2 и вносишь дополнительную погрешность.
Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

257. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 16:38 
Долго сканировал поверхность монитора, пытаясь найти, где там производительность меряется.
Кажется, сейчас тузиком буду я.

1. Вы меряете время на выполнение всей проги, а не конкретного участка кода, который может составлять проценты от всего результата. Бенчмарки используют функции для получения времени в наносекундах вокруг измеряемого кода.
(--)
2. У вас только одно выполнение фибоначи. Нормальные бенчмарки гоняют код миллиарды раз, деля результат на количество этих раз (хотя можно не делить, для сравнения это неважно). В данном случае нужно измерить только время на js_eval().
(--)

Кстати: Нельзя ли выполнить прогу по частям - в несколько js_eval() ? Здесь, разумеется, лучше вам знать - я даже на большом JS пока не пишу.

> 1. Ты предложил сложить погрешности измерений;

o_O Это где такое? Не подтверждаю. (--)
> 2. Ты понятия не имеешь, как оценить время выполнения предложенного цикла без выполнения.

O_o Измерение миллиона прогонов чтоли? Стандартный подход всех бенчмарков. Если у вас особый подход, значит надо было его расписать. Не будут же вам на слово верить, должна быть 100% воспроизводимость. (--)
> 3. .....

O_O А третий то зачем? Двух хватит. Что-то суеверием запахло (хотя да, мне тоже число 3 нравится).

Напоминание про отсутствующие массивы в elk-js конечно верно, хотя я подозреваю - не только массивы. Что-то подсказывает, что 'console' должно быть в библиотеке. Или нет?
(++)

-3
Положительных

Ответить | Правка | Наверх | Cообщить модератору

268. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 17:33 
> Долго сканировал поверхность монитора, пытаясь найти, где там производительность меряется.
> Кажется, сейчас тузиком буду я.

Грелка по определению априори горячая. Вопрос в температуре носителя. А ещё бывают электрические грелки. :)))

> 1. Вы меряете время на выполнение всей проги, а не конкретного участка
> кода, который может составлять проценты от всего результата.

Да, поскольку (допустим) я хочу использовать JS вместо калькулятора. Написал в скрипте, что мне требуется посчитать. Нода считает медленнее, чем интерпретатор из новости (но его надо доработать, что бы скрипт можно было размещать в файле).

> Бенчмарки используют функции
> для получения времени в наносекундах вокруг измеряемого кода.

Верно. Вместо этого мне было предложено https://www.opennet.ru/openforum/vsluhforumID3/125354.html#82
отнять от моего первого результата время исполнения пустого скрипта.

Результат всякого измерения включат в себя истинное значение и погрешность измерения. Погрешность измерения не определена, потому при вычитании результатов двух измерений погрешности суммируются.

> Кстати: Нельзя ли выполнить прогу по частям - в несколько js_eval() ?

Можно. Ещё можно вызывать из JS функции Си.

> Здесь, разумеется, лучше вам знать - я даже на большом JS
> пока не пишу.

Я тоже не пишу, в моём первом сообщении есть ссылка на первый тест, там прямо написано.

>> 1. Ты предложил сложить погрешности измерений;
> o_O Это где такое? Не подтверждаю. (--)

См. выше и https://ru.wikipedia.org/wiki/Погрешность_измерения

>> 2. Ты понятия не имеешь, как оценить время выполнения предложенного цикла без выполнения.
> O_o Измерение миллиона прогонов чтоли? Стандартный подход всех бенчмарков. Если у вас
> особый подход, значит надо было его расписать. Не будут же вам
> на слово верить, должна быть 100% воспроизводимость. (--)

Без выполнения. Во его оценка: "вычисление числа фибоначчи ближе ... к 0". Я бы написал "в первом приближении 400 тактов".

>> 3. .....
> O_O А третий то зачем? Двух хватит. Что-то суеверием запахло (хотя да,
> мне тоже число 3 нравится).

Я и написал, что мне хватило двух, а третий из них следствие.

> Напоминание про отсутствующие массивы в elk-js конечно верно, хотя я подозреваю -
> не только массивы.

Ещё for не поддерживается.

> Что-то подсказывает, что 'console' должно быть в библиотеке.
> Или нет?

В исходнике интерпретатора "console" нет. Я не знаю, как там подключать библиотеки, а разбираться с этим мне не интересно. Просто взял готовый пример и адаптировал.

Ответить | Правка | Наверх | Cообщить модератору

282. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от ммнюмнюмус (?), 26-Сен-21, 20:33 
> Грелка по определению априори горячая. Вопрос в температуре носителя. А ещё бывают
> электрические грелки. :)))

Вода в грелке могла остыть, да и забытым на столе бумагам Тузик тоже обрадуется.
Ыххх.... (Двай Нальвай Давадавай)))))))).

>> 1. Вы меряете время на выполнение всей проги, а не конкретного участка
>> кода, который может составлять проценты от всего результата.
> Да, поскольку (допустим) я хочу использовать JS вместо калькулятора. Написал в скрипте,
> что мне требуется посчитать. Нода считает медленнее, чем интерпретатор из новости
> (но его надо доработать, что бы скрипт можно было размещать в
> файле).

Ну вот - думаю, мало кто сразу понял, что интересует время не куска js-кода, а время одиночного запуска движка с этим куском. Другой причины, почему включение JIT увеличило время в 10 раз не вижу. Сомневаюсь, что это имеет интерес кроме академического.

>> Бенчмарки используют функции
>> для получения времени в наносекундах вокруг измеряемого кода.
> Верно. Вместо этого мне было предложено https://www.opennet.ru/openforum/vsluhforumID3/125354.html#82
> отнять от моего первого результата время исполнения пустого скрипта.
> Результат всякого измерения включат в себя истинное значение и погрешность измерения. Погрешность
> измерения не определена, потому при вычитании результатов двух измерений погрешности суммируются.

Эта методика была бы полезна для вашего оригинального кода - меряете время для данного куска, затем для пустого кода. И смотрите разницу.
На счёт мусора - код явно не расчитан на копи-паст - адаптация ложится на вас. Так что если он почему-то не годится - то только потому что не понял цель измерений. Не похоже, что ваши объяснения после старта не достаточно точны. Можно было и по-точнее (я выше попытался).

>> Кстати: Нельзя ли выполнить прогу по частям - в несколько js_eval() ?
> Можно. Ещё можно вызывать из JS функции Си.

Я это спрашивал для одной вещи: пока я, как и другие, думал, что цель измерений - время для самой функции фибоначи, прогу можно было бы разбить на 3 части - до измеряемого цикла, цикл, после цикла. И измерять только сам цикл. Это слегка повысило бы точность. Но раз цель другая, то и смысла в этом теперь нет.
Вызов С-функций из JS к этому перпендикулярен.

>>> 2. Ты понятия не имеешь, как оценить время выполнения предложенного цикла без выполнения.
>> O_o Измерение миллиона прогонов чтоли? Стандартный подход всех бенчмарков. Если у вас
>> особый подход, значит надо было его расписать. Не будут же вам
>> на слово верить, должна быть 100% воспроизводимость. (--)
> Без выполнения. Во его оценка: "вычисление числа фибоначчи ближе ... к 0".
> Я бы написал "в первом приближении 400 тактов".

Сразу отвечаю на этот и похожий пост
400 тактов было бы для компилированной версии на С (и то, смотря чем компилировать). Это машинная команда берёт и выполняется. А в интерпретаторе VM - по порядку:
- разбор команды (strlen, strcmp, strtok,...) = выбор операции с установкой её параметров,
- переход по адресу операции (допускаю, что использутся switch).
- операция
- на следующую строку

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

Ответить | Правка | Наверх | Cообщить модератору

321. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 27-Сен-21, 17:00 
>> Грелка по определению априори горячая. Вопрос в температуре носителя. А ещё бывают
>> электрические грелки. :)))
> Вода в грелке могла остыть, да и забытым на столе бумагам Тузик
> тоже обрадуется.
> Ыххх.... (Двай Нальвай Давадавай)))))))).

А ещё британские учёные скрестили Тузика и грелку. Не прошло и пяти минут, как животное порвало само себя.

>[оверквотинг удален]
>>> 1. Вы меряете время на выполнение всей проги, а не конкретного участка
>>> кода, который может составлять проценты от всего результата.
>> Да, поскольку (допустим) я хочу использовать JS вместо калькулятора. Написал в скрипте,
>> что мне требуется посчитать. Нода считает медленнее, чем интерпретатор из новости
>> (но его надо доработать, что бы скрипт можно было размещать в
>> файле).
> Ну вот - думаю, мало кто сразу понял, что интересует время не
> куска js-кода, а время одиночного запуска движка с этим куском. Другой
> причины, почему включение JIT увеличило время в 10 раз не вижу.
> Сомневаюсь, что это имеет интерес кроме академического.

Как говорили в ФИДО, отучаемся говорить за всех. Почитайте ответы Ordu мне (его вообще стоило бы почитать, что бы не тратить время), он рассматривал такой вариант среди прочих (поиск по слову "unix"). Кроме того, именно в этой ветке я прямо указал задачу https://www.opennet.ru/openforum/vsluhforumID3/125354.html#85

>[оверквотинг удален]
>> отнять от моего первого результата время исполнения пустого скрипта.
>> Результат всякого измерения включат в себя истинное значение и погрешность измерения. Погрешность
>> измерения не определена, потому при вычитании результатов двух измерений погрешности суммируются.
> Эта методика была бы полезна для вашего оригинального кода - меряете время
> для данного куска, затем для пустого кода. И смотрите разницу.
> На счёт мусора - код явно не расчитан на копи-паст - адаптация
> ложится на вас. Так что если он почему-то не годится -
> то только потому что не понял цель измерений. Не похоже, что
> ваши объяснения после старта не достаточно точны. Можно было и по-точнее
> (я выше попытался).

Код с массивом мусорный по той причине, которую Вы сами указали: массив на миллион значений лишний. Кроме того, заполнение массива вносит существенную погрешность.

>>> Кстати: Нельзя ли выполнить прогу по частям - в несколько js_eval() ?
>> Можно. Ещё можно вызывать из JS функции Си.
> Я это спрашивал для одной вещи: пока я, как и другие, думал,
> что цель измерений - время для самой функции фибоначи, прогу можно
> было бы разбить на 3 части - до измеряемого цикла, цикл,
> после цикла. И измерять только сам цикл. Это слегка повысило бы
> точность. Но раз цель другая, то и смысла в этом теперь
> нет.

Аналогичную операцию пришлось бы проделать и с Нодой.

>[оверквотинг удален]
>> Я бы написал "в первом приближении 400 тактов".
> Сразу отвечаю на этот и похожий пост
> 400 тактов было бы для компилированной версии на С (и то, смотря
> чем компилировать). Это машинная команда берёт и выполняется. А в интерпретаторе
> VM - по порядку:
> - разбор команды (strlen, strcmp, strtok,...) = выбор операции с установкой её
> параметров,
> - переход по адресу операции (допускаю, что использутся switch).
> - операция
> - на следующую строку

Вот ещё один мой похожий пост https://www.opennet.ru/openforum/vsluhforumID3/125354.html#211
который я написал ранее и указал там, что в первом приближении интерпретатор на порядок медленнее. Прикиньте все эти strcmp(), как раз оно и выйдет.

Впрочем, это не меняет сути. Кто может привести хоть какие-то цифры, тот их приводит (вообще-то они нужны, что бы _проверить_ результаты измерений). Кто не знает откуда они берутся - тот написал "стремится к 0". Кстати, strlen() очевидно лишняя.

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

Ещё возможно посмотреть сорцы, или хотя бы описание почитать.

Ответить | Правка | Наверх | Cообщить модератору

41. "Проект elk развивает компактный JavaScript-движок для микрок..."  +1 +/–
Сообщение от Аноним (113), 25-Сен-21, 12:46 
Ноду купил мс. Посоны, расходимся.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

44. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Аноним (44), 25-Сен-21, 12:59 
Нашёл, чем время измерять. Ручной секундомер такую же точность даст.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

65. "Проект elk развивает компактный JavaScript-движок для микрок..."  –1 +/–
Сообщение от n00by (ok), 25-Сен-21, 14:05 
С одной стороны, да, измеряемая величина 0m0,002s равна погрешности измерений, с другой стороны у Ноды 0m0,069s, и тут уже не важно, в 30 ли оно раз больше, или в 100. Потому я не стал уточнять ни в прошлом сравнении ни в сегодняшнем.
Ответить | Правка | Наверх | Cообщить модератору

88. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Аноним (19), 25-Сен-21, 15:31 
Внутри кортексов есть способ замера кол-ва тактов на блок кода.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

138. "Проект elk развивает компактный JavaScript-движок для микрок..."  –1 +/–
Сообщение от НяшМяш (ok), 25-Сен-21, 17:50 
Запустил тупо в консоли браузера на этой странице, да ещё и в Firefox:


const start = performance.now()
const n = 77;
let a = 1;
let b = 1;
let c = 0;
let i = 3;
while (i <= n) {
  c = a + b;
  a = b;
  b = c;
  i += 1;
}
const end = performance.now();
`Calculated ${b} in ${end - start} milliseconds`

Результат - "Calculated 5527939700884757 in 0.1999999999989086 milliseconds". Для этого даже пришлось privacy.reduceTimerPrecision переключить в false чтобы померить. V8 теоретически должен быть ещё быстрее. Ещё вопросы?

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

145. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Аноним (19), 25-Сен-21, 18:04 
Есть. Надо мерить на Cortex M0. И такой результат должен быть там.
Ответить | Правка | Наверх | Cообщить модератору

164. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 25-Сен-21, 19:16 
Спасибо. У меня пока один вопрос - у кого и почему эти замеры вызывают столь бурную реакцию? :)
Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

337. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от НяшМяш (ok), 28-Сен-21, 22:45 
Не за что. Просто не люблю когда некорректно используют time для замеров (:
Ответить | Правка | Наверх | Cообщить модератору

338. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 29-Сен-21, 07:33 
Мне надо было показать именно время инициализации тяжелого интерпретатора. Просто не люблю, когда кто-то что-то написали поделился, а его предлагают сжечь.
Ответить | Правка | Наверх | Cообщить модератору

150. "Проект elk развивает компактный JavaScript-движок для микрок..."  +1 +/–
Сообщение от Ordu (ok), 25-Сен-21, 18:11 
> Составило (очень грубо) 0m0,069s
> Потом порекомендовали использовать JIT, что замедлило вычисление в 10 раз.

Как мерял? Время компиляции кода jit'ом включено в эти 0,069 сек? Что-то мне подсказывает, что да. Если так, то для "честного" сравнения с C, надо приплюсовать в него время компиляции C'шного кода.

Ну, или если хочешь, я могу сказать иначе: ты взял какой-то искусственный тест производительности, и почему-то считаешь его результаты переносимыми на больший класс ситуаций. Переносимость результатов -- это большая проблема, до недавнего времени её называли "внешней валидностью" исследования, и это было сплошное гуманитарное размахивание руками. Сейчас ты можешь почитать The Book of Why, писанную старым евреем Judea Pearl (я очень рекомендую: он хоть и математик, но писал книгу для ГСМов всяких, поэтому формулы там хоть и есть, но не все, и при этом изложения алгоритмов нет, они лишь упомянуты, и вывода формул нет, и доказательств теорем нет, вместо них рассуждения, которые будут понятны и ребёнку), и он там это "внешней валидности" расширяет, называет "переносимостью" (transportability), и предлагает математические методы оценки этой переносимости.

Но тебе ведь теория побоку? Любишь практику? Возьми реалистичный пример, в двух или более вариантах, определись с тем, как будет разумнее всего измерить параметры производительности в данном случае -- латенси, throughput, энергопотребление, или что? -- померь по всем вариантам и сравни. И сравнивай, обеспечив для каждого измерения хотя бы 30 замеров, чтобы можно было бы говорить о распределении вероятности значения (принято, как правило, находить среднее и стандартное отклонение этого распределения). Это полезно не только для точности измерения, но и для того чтобы отловить влияние всяких эффектов типа кеширования, которые иногда могут катастрофически искажать измерения, но с одного замера ты даже не заметишь искажений.

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

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

162. "Проект elk развивает компактный JavaScript-движок для микрок..."  –1 +/–
Сообщение от n00by (ok), 25-Сен-21, 19:09 
>> Составило (очень грубо) 0m0,069s
>> Потом порекомендовали использовать JIT, что замедлило вычисление в 10 раз.
> Как мерял? Время компиляции кода jit'ом включено в эти 0,069 сек? Что-то
> мне подсказывает, что да.

По ссылке указано.


$ cat fibonacci.js
#!/usr/bin/node
function fib(n) {
  let a = 1;
  let b = 1;
  for (let i = 3; i <= n; i++) {
    let c = a + b;
    a = b;
    b = c;
  }
  return b;
}
console.log(fib(77));
$ time ./fibonacci.js
5527939700884757
real    0m0,069s
user    0m0,041s
sys    0m0,030s
C JIT в следующем сообщении https://www.opennet.ru/openforum/vsluhforumID3/125336.html#132

$ time node --always-opt ./fibonacci.js
5527939700884757

real    0m0,703s
user    0m0,636s
sys    0m0,069s

> Если так, то для "честного" сравнения с
> C, надо приплюсовать в него время компиляции C'шного кода.

Это сравнение не с Си. Интерпретатор встраиваемый, его нет в виде самодостаточного приложения. Что бы исполнить сценарий на JS, надобно файл считать или заэмбеддить; я выбрал последний вариант. Не вполне корректно, поскольку не учитывается чтение файла Нодой, но при такой разнице в результатах погрешностью измерений решил пренебречь.

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

Всё немного проще. Внизу приписка "на данной задаче..." :) Вчера Анонимом (по-моему, Урри) заявил, что JS в браузерах пожёг гигаваты. Ему возразили, что учёные с Питоном потратили больше, а JS самый быстрый. Я взял что подвернулось под руку и сравнил, но не с Питоном, а со своим интерпретатором. Сегодня читаю эту тему, вспомнил вчерашние "тесты" и решал немного разбавить негатив.

> Переносимость результатов -- это большая проблема, до недавнего времени её
> называли "внешней валидностью" исследования, и это было сплошное гуманитарное размахивание
> руками. Сейчас ты можешь почитать The Book of Why, писанную старым
> евреем Judea Pearl (я очень рекомендую: он хоть и математик, но
> писал книгу для ГСМов всяких, поэтому формулы там хоть и есть,
> но не все, и при этом изложения алгоритмов нет, они лишь
> упомянуты, и вывода формул нет, и доказательств теорем нет, вместо них
> рассуждения, которые будут понятны и ребёнку), и он там это "внешней
> валидности" расширяет, называет "переносимостью" (transportability), и предлагает математические
> методы оценки этой переносимости.

Спасибо.

Ответить | Правка | Наверх | Cообщить модератору

168. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Ordu (ok), 25-Сен-21, 19:31 
> Всё немного проще. Внизу приписка "на данной задаче..."

Да, но начал ты пост с:

> Вчера мне рассказали, что JS — наибыстрый скриптовый язык (ц).

Для того, чтобы тест был релевантен этой заявке, должны быть хоть какие-то намёки на валидность. Я подозреваю, что утверждение, что js -- самый быстрый скриптовый язык, вполне может быть верным, просто потому, что в его оптимизации вливается груда инженерного гения, и потому что есть как минимум две конкурирующие реализации. И твои проверки вот нисколько мне не добавляют сомнений в том, что js -- самый быстрый.

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

Ещё не учитывается время запуска ноды: сколько времени нода, при твоём способе измерений, будет выполнять пустую программу? А в случае jit-компилятора, ещё и время компиляции остаётся неучтённым. И это уже погрешность, которая на такой задаче в 77 сложений превзойдёт измеряемое значение на несколько порядков, я подозреваю. От 2 и выше. Время завершения ноды? Она может не просто дёргать exit, а выполнять цикл сборки мусора, с тем, чтобы а) закрыть все файлы правильно, сбросить все буфера, и в целом вызвать все деструкторы, и б) проверить, что не было утечек памяти. Кроме того, если избавиться от этого косяка, тут может оказаться, что разница в скорости вывода в консоль окажется доминирующей.

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

Ответить | Правка | Наверх | Cообщить модератору

171. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 25-Сен-21, 19:52 
>> Всё немного проще. Внизу приписка "на данной задаче..."
> Да, но начал ты пост с:
>> Вчера мне рассказали, что JS — наибыстрый скриптовый язык (ц).
> Для того, чтобы тест был релевантен этой заявке, должны быть хоть какие-то
> намёки на валидность. Я подозреваю, что утверждение, что js -- самый
> быстрый скриптовый язык, вполне может быть верным, просто потому, что в
> его оптимизации вливается груда инженерного гения, и потому что есть как
> минимум две конкурирующие реализации.

Так же и в Python.

> И твои проверки вот нисколько мне не
> добавляют сомнений в том, что js -- самый быстрый.

У меня нет задачи заставить тебя сомневаться. Мне интересен был ответ заявителя, почему в первом попавшемся частном случае "самый быстрый" проиграл, но заявитель куда-то пропал.

>> Не вполне корректно, поскольку не учитывается чтение файла Нодой, но при такой разнице в результатах погрешностью измерений решил пренебречь.
> Ещё не учитывается время запуска ноды: сколько времени нода, при твоём способе
> измерений, будет выполнять пустую программу?

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

> А в случае jit-компилятора, ещё и
> время компиляции остаётся неучтённым.

Время компиляции можно оценить при запуске в ключём --always-opt (пусть специалисты по Ноде поправят).

> И это уже погрешность, которая на такой
> задаче в 77 сложений превзойдёт измеряемое значение на несколько порядков, я
> подозреваю. От 2 и выше. Время завершения ноды? Она может не
> просто дёргать exit, а выполнять цикл сборки мусора, с тем, чтобы
> а) закрыть все файлы правильно, сбросить все буфера, и в целом
> вызвать все деструкторы, и б) проверить, что не было утечек памяти.
> Кроме того, если избавиться от этого косяка, тут может оказаться, что
> разница в скорости вывода в консоль окажется доминирующей.

По-моему, ты не прочитал про --always-opt в предыдущем моём сообщении, потому не увидел, что JIT увеличивает время получения результата на порядок.

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

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

Ответить | Правка | Наверх | Cообщить модератору

173. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от Ordu (ok), 25-Сен-21, 20:06 
> Вот у меня реальная, пусть и бесполезная, задача: вычислить 77-е число Фибьоначчи,
> запуская интерпретаторы в стиле юниксовых скриптов.

И ты считаешь, что ты кого-то убедил в результате?

> У меня нет задачи заставить тебя сомневаться.

Есть. Если бы ты не пытался влиять на мнение окружающих, ты бы не заморачивался идти на такие сложности, как написание комментов.

Может быть, ты не понимаешь фразу? Ты не интересовался байесианством? Оно измеряет веру/сомнение вероятностями. Логарифмы этих вероятностей оказываются битами информации в сообщении. Таким образом фразу "сообщение не вызвало ни грамма сомнения" можно читать как "в сообщении ноль бит информации". То есть что прочитал я сообщение, что не читал его, моё видение мира не изменилось.

Ответить | Правка | Наверх | Cообщить модератору

211. "Проект elk развивает компактный JavaScript-движок для микрок..."  +/–
Сообщение от n00by (ok), 26-Сен-21, 09:55 
>> Вот у меня реальная, пусть и бесполезная, задача: вычислить 77-е число Фибьоначчи,
>> запуская интерпретаторы в стиле юниксовых скриптов.
> И ты считаешь, что ты кого-то убедил в результате?

Не, я считаю, сколько тут набралось минусов. Мой комментарий про Rosa Tresh набрал традиционные два минуса (что там можно отрицать? вывели из страны сладкий шекель, уволили французов-создателей, наняли аналог JS-программистов, которых тут как бы не любят).

Комментарий НяшМяш https://www.opennet.ru/openforum/vsluhforumID3/125354.html#138
где он по сути выполнил рекомендаций нивелировать влияние запуска интерпретатора
набрал два минуса (там 1 мой плюс). Это не то, что я измеряю, но это именно то, чего хотят от меня несогласные. Кроме того, там достаточно хороший результат. В первом приближении 77 итераций цикла с 5-ю операциями исполняются порядка 400 тактов (без суперскалярности и т.п.). Интерпретатор медленнее на порядок, грубо, 4000 тактов. На процессоре 4ГГц получилось 0,2 мс, что в 5 раз быстрее (я нередко теряю значащие нули, так что лучше перепроверить), как раз за счёт спаривания команд.

Так я могу утверждать, что в теме присутствует некоторое количество малахольных.

>> У меня нет задачи заставить тебя сомневаться.
> Есть. Если бы ты не пытался влиять на мнение окружающих, ты бы
> не заморачивался идти на такие сложности, как написание комментов.

Я и повлиял. Посмотри начало темы, где идут призывы кого-то сжечь. Что это за трэш? В ответ на мои "тесты" появляется твой комментарий с кратким курсом метрологии. Эта информация несёт пользу. Ответ в начале ветки, как минимум, 10 человек его прочли.

> Может быть, ты не понимаешь фразу? Ты не интересовался байесианством? Оно измеряет
> веру/сомнение вероятностями. Логарифмы этих вероятностей оказываются битами информации
> в сообщении. Таким образом фразу "сообщение не вызвало ни грамма сомнения"
> можно читать как "в сообщении ноль бит информации". То есть что
> прочитал я сообщение, что не читал его, моё видение мира не
> изменилось.

Нафига мне менять твоё видение мира? Что бы вместо ссылки на Judea Pearl ты написал "гыы, лол", или предложил суммировать погрешности, как Аноним выше? Тут таких и так с лихвой.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру