The OpenNET Project / Index page

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



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

Оглавление

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

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


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
Добавить, Поддержать, Вебмастеру