Разгоняем JS-парсер с помощью WebAssembly (часть 1: базовые возможности)

[RPG18]

Моё почтение, если вы действительно пошли путём написании через wat.

[Kilor]

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

[RPG18]

Это извечный вопрос. Будет ли вручную написанный код быстрее, чем сгенеренный и оптимизированный компилятором.

[Kilor]

Если учишься у компилятора, а не просто пользуешься им — со временем будет. Вопрос, найдется ли это время в достаточном количестве.

[slonopotamus]

Чтобы приблизиться к возможностям «железа»...

Я правильно понимаю что в результате получилось порядка 500MB/s? Это не больше 10% от возможностей железа.

[Kilor]

Приблизиться, а не достичь.
Чтобы выжимать из железа максимум, нужно решать очень специфические задачи — матрицы перемножать, например. А на задачах «среднестатистических» упор много чаще происходит в слабую эффективность предсказания переходов в CPU, чем в предельную пропускную способность.
Даже в нашем примере CPU никак не может заранее сказать, какой из ключей ему встретится дальше в файле.

[slonopotamus]

удалено

[Kilor]

складывать в хэшмэп со строковым ключом в процессе парсинга совершенно ни к чему, обычного массива более чем достаточно

Это очень сильное и некорректное допущение, которое слишком легко позволяет свести ситуацию к единственному .match из предыдущей статьи.
Еще момент — если нам надо не просто «пропарсить файл», а все-таки по ходу куда-то отдавать эти результаты в JS/any-other-lang, то сам вызов этих функций передачи добавит накладных расходов.

[slonopotamus]

Удалил свой комментарий, потому что понял что решаю немного другую задачу — агрегирую результаты по нескольким строкам, а вы заворачиваете в скобочки каждую строку. Про отдавание результатов — ну так и вы их никуда не отдаёте. Давайте добавим вывод в stdout и посмотрим что произойдёт со скоростью?

[Kilor]

Я имел в виду передачу результата из высокопроизводительного C-кода в JS. По условию задачи результат каждой строки нам нужен именно на JS-стороне.

[slonopotamus]

По условию задачи результат каждой строки нам нужен именно на JS-стороне.

Ну так-то C может жить в том же процессе, что и JS. Например: создаём два буфера, в один пишем парсером, второй в это время обрабатывается обработчиком. Когда оба закончили (парсер забил данными весь свой буфер, а обработчик вычитал весь свой), меняемся буферами. Но ваша процедура последующей обработки на JS готова получать на вход пару ГБ данных в секунду?

[Kilor]

Я не про межпроцессную передачу данных, а про передачу управления/контекста — каждый jmp/call, да с обвязкой сохранения-наполнения стека — это дорого.

В нашем случае контекст с объектом должен попасть в JS при окончании разбора строки — в целом, у нас задача «распарсить набор строк, некоторые из которых имеют такой вот формат, который разбирается относительно долго», а не «распарсить весь файл, а дальше уж как заберут». Поэтому после каждой строки надо отдавать результат.

Но идея с потоковым заполнением буфера, безусловно, здравая.

[slonopotamus]

Ну короче, мой поинт: 500MB/s — это очень мало. Тем более что у вас же обработчик распаршенного будет в том же потоке, да?