80 строк на Haskell уделывают в скорости работы сишную портянку

Царь делает MAP_POPULATE, но что-то мне подсказывает что это лишнее для stdin.

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

Для того чтобы нормально набросить делаем так

✦ ❯ cargo install cw  --features runtime-dispatch-simd
✦ ❯ cargo install hyperfine

Генерируем hexdump random где-то на 100 МБ (или на сколько хотите)

✦ ❯ head -10 ./file
0000000 4dbc 568f 002e bc8a 4718 9672 a3b7 4741
0000010 ef41 f6cd d93a cb8a bf52 0baf 68bf 74fa
0000020 2103 815a d351 c595 551d eceb 7c38 767a
0000030 aec3 914c 28a0 666a 7578 2e22 5559 7bb8
0000040 2768 91c5 0cac 3e6e e69e be38 d077 469b
0000050 ec00 bed5 c57e c5c0 6654 08d7 ce1e 29ff
0000060 8c10 d756 7153 5157 ef00 1b8a a2de 5c74
0000070 0d3b 7c91 2797 f1a8 2f6d 0154 bcae f3ed
0000080 a16b b35b 7751 0143 cd2f 9e35 f144 300c
0000090 a131 b6aa a450 2eb6 6126 d9a0 f8d9 5cd8

✦ ❯ wc -lw ./file
  2115840  19042560 ./file
✦ ❯ cw -lw ./file
 2115840 19042560 ./file

✦ ❯ hyperfine "cw -lw ./file" "wc -lw ./file"
Benchmark #1: cw -lw ./file
  Time (mean ± σ):     142.2 ms ±  11.8 ms    [User: 127.2 ms, System: 14.7 ms]
  Range (min … max):   130.0 ms … 170.9 ms    22 runs

Benchmark #2: wc -lw ./file
  Time (mean ± σ):     445.8 ms ±  37.1 ms    [User: 427.9 ms, System: 16.9 ms]
  Range (min … max):   375.8 ms … 492.6 ms    10 runs

Summary
  'cw -lw ./file' ran
    3.13 ± 0.37 times faster than 'wc -lw ./file'

Coreutils wc написано на… https://github.com/coreutils/coreutils/blob/master/src/wc.c

перл сделает это за 1 строку

Слушай, а может Хаскель быстрее еще и Ассемблера? Ты не находил статей где Хаскель уделывает Ассемблер?

Скоро будет еще много интересных срачей и бенчмарков. На shootout например есть такой бенчмарк

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html

regex-redux
source	secs	mem	gz	busy	cpu load
Rust    2.12	153,184	986	3.15	15% 33% 85% 15%
Java   10.25	634,884	740	30.23	68% 95% 67% 65%

Я решил добавить WebAssembly через WASI/wasmtime (http://wasmtime.dev) бенчмарк. Это JIT к WebAssembly плюс системный интерфейс к IO.

Увы проект на ранних стадиях и не умеет в многопоточность, потому чтобы было чесно я убрал rayon из Rust версии и parallelStreams() из Java. Потом собрал Rust бенчмарк з --target=wasm32-wasi

source	          secs	mem
Rust              2.12	153,184
WebAssembly       8.7   328,712 
Java              10.25	634,884

Вот так WebAssembly JIT написаный считай позавчера уделал Java на одном ядре (понятно что отсутсвие многопоточности - сильный минус). До натива еще далеко конечно.

Что интересно, в Java использовался встроеный движек регулярных выражений. В Rust использовался regex crate. В WebAssembly тот же regex был полностью (!!!) скомпилирован в WebAssembly, что означает что мы сделали тест достаточно высокой сложности как для экспериментального рантайма.

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

Наблюдаем. stevejobs, иди защищай Java

а почему на Си и Си++ нет сравнения? Потому что они займут две строчки сверху - и раст окажется на третьей строчке - месте лузера? )

В основном потому что С и С++ меня совершенно не интересуют, а не из-за теории заговора что «от нас скрывают»

regex-redux
source	secs	mem	gz	busy	cpu load
Rust    2.12	153,184	986	3.15	15% 33% 85% 15%
C++ g++ 1.82	203,760	1315	4.43	44% 51% 48% 100%
C gcc   1.46	152,236	1397	3.43	43% 100% 45% 48%

Видим как плюсы отстают по потреблению памяти, но занимают среднюю позицию между Rust и C по производительности. Неплохой результат.

По бенчмаркам признаю небольшую неточность во второй таблице. Я там смешал параллельные результаты Rust/Java на их машине и последовательные результаты WebAssembly на моей. Вот все результаты с моей, все однопоточные

source	          secs	mem
Rust              1.85	153,036
WebAssembly       8.7   328,712 
Java              15.21	523,088

Вывод тот же.

Альтернативный вывод - в Java ужасные регексы

Альтернативный вывод - в Java ужасные регексы

Хм. Пол-интернета на них крутится...

Ну я же не говорю что они не работают

А я и не говорю, что быстро работают)

Меня в последнее время из всех приложений на компьютере больше всего стал бесить браузер. Просто неимоверно бесить. Всякие там атомы, слаки из той же серии. Добавив сюда зеплины. Как бы звенья одной цепи.

это просьба скинуться на нейролептики?

Чем это лучше:

fn main() -> std::io::Result<()> {
    let file = std::fs::File::open(std::env::args().nth(1).expect("no input file"))?;
    let buf = unsafe { memmap::Mmap::map(&file)? };
    let mut lines = 0;
    let mut words = 0;
    for (i, b) in buf.iter().enumerate() {
        if b.is_ascii_whitespace() && !buf.get(i+1).map(|c| c.is_ascii_whitespace()).unwrap_or(false) {
            words += 1;
        }

        if *b == b'\n' {
            lines += 1;
        }
    }

    println!(" {} {} {}", lines, words, buf.len());
    Ok(())
}

> wc big.txt
 128457 1095695 6488666 big.txt

> target/release/wc big.txt
 128457 1095695 6488666

> hyperfine 'wc big.txt' 
Benchmark #1: wc big.txt
  Time (mean ± σ):      26.3 ms ±   0.4 ms    [User: 25.6 ms, System: 0.7 ms]
  Range (min … max):    25.4 ms …  27.5 ms    111 runs

> hyperfine 'target/release/wc big.txt'
Benchmark #1: target/release/wc big.txt
  Time (mean ± σ):      10.9 ms ±   0.3 ms    [User: 10.6 ms, System: 0.5 ms]
  Range (min … max):    10.3 ms …  12.2 ms    251 runs

> hyperfine './tsar-wc < big.txt'
Benchmark #1: ./tsar-wc < big.txt
  Time (mean ± σ):       7.2 ms ±   0.2 ms    [User: 5.8 ms, System: 1.7 ms]
  Range (min … max):     6.6 ms …   7.5 ms    383 runs

Я думаю что memmap::Mmap::map не делает MAP_POPULATE

Ну так я и говорю, что только начинает. Уже ошибки начинаешь делать.

Чем это лучше:

Это к Царю.

Так это решение в лоб.

В любом случае это баловство и бред, ибо ASCII микро-бенчмарк и смысла от него 0.

Вот так WebAssembly JIT написаный считай позавчера уделал Java на одном ядре (понятно что отсутсвие многопоточности - сильный минус). До натива еще далеко конечно.

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

WebAssembly конечно нужно подтянуться, иначе он не потеснит натив на серверах

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

Альтернативный вывод - в Java ужасные регексы

Насколько мне известно, в жаве регексы сделаны на самой жаве. А это неизбежно приводит к низкой производительности, потому что регулярки очень насыщены разношерстной гибкотой, которую приходится заворачивать в сложные структуры данных. В отличие от pcre2, который тупо в машинный код компилирует регулярку.

Меня в последнее время из всех приложений на компьютере больше всего стал бесить браузер. Просто неимоверно бесить. Всякие там атомы, слаки из той же серии. Добавив сюда зеплины. Как бы звенья одной цепи.

А есть рациональная причинно-логическая связь бешения и неких наблюдаемых тобой явлений? Или просто «бесит»?

WAsm совсем нечего делать на серверах

Множество разных применений, разберитесь в вопросе

Какая тут рациональность?! Ты че? Я же не робот. Чистейшей выводы иррациональщина. Бесит вот и все, что связано с html и javascript. Ничего не могу с собой поделать.

WAsm совсем нечего делать на серверах

Множество разных применений, разберитесь в вопросе

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

Но WAsm? Да, сишечку можно компилировать в WAsm, но это будет совершенно другое окружение, не похожее ни на обычный клиент, ни на обычный сервер.

https://www.youtube.com/watch?v=2EDH-TxSo6U

https://youtu.be/RUAXPOSVV1A?t=1562

https://www.youtube.com/watch?v=CMB6AlE1QuI

В основном этим упарываются сейчас Cloudflare и Fastly

Ставки повышаются. Эта статья попала в рассылку O'Reilly Programming Newsletter.

В основном этим упарываются сейчас Cloudflare и Fastly

Конечно упарываются. Потому что они это продают. Как минимум последняя ссылка рассказывает о том, что «покупайте наших слонов». AWS Lambda прекрасно работает без WAsm и не собирается его вводить, зато уже имеют поддержку Java, Go, PowerShell, Node.js, C#, Python и Ruby.

https://www.youtube.com/watch?v=CMB6AlE1QuI

Ну хорошо хоть этот веселый очкарик, приводящий шутки не в тему, признался, что работает в cloudflare, а не просто сказал, мол «я слышал про cloudflare, мне говорили, что это классный сервис. Я не поверил, забыл на два года, а потом случайно увидел, и вау - это лучший сервис на свете, только им и пользуюсь».

https://www.youtube.com/watch?v=2EDH-TxSo6U
https://youtu.be/RUAXPOSVV1A?t=1562

А эти помои просочились к нам из Mozilla/Fastly.

А теперь еще раз, трезво, скажи мне: зачем нужен WAsm на серверах?

Они нужны для архитектурно-независимой так называемой нативщины (ее очень) в npm пакетах. Причем без танцев с бубном как сейчас. По сути хотят джава байткоды здорового человека. Не заточенные ни на язык, ни на обязательность GC. Байткод не зависимый ни от Oracle, ни от MS.

А вот товарища выше хотят через wasm закопать докер. По крайней мере как артефакт, предоставляемый пользователем. Стандартные бд и тд, могут жить в докере.

Они нужны для архитектурно-независимой так называемой нативщины (ее очень) в npm пакетах

Доступ к родным интерфейсам? Это уже WASI, если чо. И как бы никто не запрещает делать интерфейсы к самому JS - при чем тут WASM вообще? Чем ближе ты к системе, тем больше твой байткод становится зависим от оракла, MS, Linux, AWS, etc. И ты никуда от этого не денешься, потому что разные системы различны.

А вот товарища выше хотят через wasm закопать докер.

Никуда его уже не закопают. Контейнеры - это уже принятый и хорошо работающий стандарт, который, на самом деле, возник еще до докера, а WAsm/WASI - это еще непонятно что с непонятно какими перспективами. Да, WASI создаст некоторую конкуренцию контейнерам, но я должен заметить, что Docker разорилась еще раньше, не сумев монетизировать свою разработку. Как я понимаю, аргумент подразумевал, что докер разорился бы еще быстрее, если бы на рынке уже был WASI.

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

И как бы никто не запрещает делать интерфейсы к самому JS

Вот его пора бы прикопать, м лучше бетоном залить чтобы не вылез. Как язык, API в браузере можно оставить.

Чем ближе ты к системе, тем больше твой байткод становится зависим от оракла, MS, Linux, AWS, etc

Да делали уже нормальные интерфейсы сто раз. WASI могут новым Posix сделать.

Что такого есть в wasm, что заставит его взлететь выше llvm? Ну кроме слова «web» в названии.

Насколько я знаю - это более высокоуровневый LLVM IR.

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

Разве он комилируется?

И как бы никто не запрещает делать интерфейсы к самому JS

Вот его пора бы прикопать, м лучше бетоном залить чтобы не вылез. Как язык, API в браузере можно оставить.

И баш тоже закопать?

Чем ближе ты к системе, тем больше твой байткод становится зависим от оракла, MS, Linux, AWS, etc

Да делали уже нормальные интерфейсы сто раз. WASI могут новым Posix сделать.

Пардон, а чем тебя линукс не устроил? Я имею в виду именно линукс, а не POSIX. Тот самый, на который ориентировались контейнеры гугла и докера.

Что такого есть в wasm, что заставит его взлететь выше llvm? Ну кроме слова «web» в названии.

Нужно было назвать его WebCloudServerlessContainer, ага.

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

WebAssembly не имеет отношения ни к вебу, ни к ассемблеру, как ни странно. Время компиляции зависит от компилятора, а для серьезной оптимизации оно будет большое. Вспомни ту же жаву, у которой байткод, казалось бы, низкоуровневый, а что у нас там со временем запуска?...

Насколько я вижу, в треде wasm представлен вами как новый универсальный instruction set. Но если заменить все вхождения wasm на llvm, мы получим те же сказки, что видели 15 лет назад, когда llvm только появился. А если заменить на java, то откатимся на 25 лет и получим write once, run everywhere. Каких-то преимуществ именно в технологическом плане лично я не вижу. Отличия, разве что, с маркетологической точки зрения - тогда были c++-обезъяны, а теперь стали javascript-обезъяны.

же сказки, что видели 15 лет назад, когда llvm только появился

Какие сказки?

портабельный машинный код

архитектурно-независимой так называемой нативщины

Не заточенные ни на язык, ни на обязательность GC

Ну оно так и есть, как бы.

Оно так и есть, но изначальный вопрос был:

Что такого есть в wasm, что заставит его взлететь выше llvm?

Так вот на мой взгляд, wasm ничем принципиально не отличается от llvm. И мой прогноз таков. Судя по тому, что clang+llvm, при всей поддержке, за все эти годы так и не вытеснил ниоткуда gcc, а команда clang занимается в первую очередь портированием багов gcc «чтоб не смущать пользователей», разработчикам wasm как платформы для других языков предстоит то же самое. А, скорее, их ждёт куда больше веселья, с учётом того, что основной их аудиторией будут разработчики на js, с приколами из серии «я прибавил к массиву строку, а получилось 42, нидхелп».

Ну транслируется, боже мой

LLVM уперся в то что это тулкит для компиляторов. Плюс в нем не было sandbox afaik.

Давай так, скажи, как Rust компиляют в wasm? Правильно, через LLVM IR. Wasm тут target. LLVM делает множество оптимизаций на этом уровне. Потом лёгкие вещи остаются за JIT

Вот недостаточно низкоуровневый получается.

Вот матчасть

https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf

Почему не jvm bytecode и не LLVM IR написано. JVM байткоды сложно верифицировать например

Тут тоже

https://webassembly.org/docs/faq/

LLVM уперся в то что это тулкит для компиляторов. Плюс в нем не было sandbox afaik.
Давай так, скажи, как Rust компиляют в wasm? Правильно, через LLVM IR. Wasm тут target.

LLVM IR потенциально можно выполнить на любой машине. Но проблема в том, что бесполезно выполнять IR, сгенерированный под одну платформу, на другой платформе. Слишком уж глубокие отличия. Потому Java создала свою универсальную платформу, которая не зависит от хоста. Можно сделать LLVM IR под универсальную платформу, но проблема в том, что он, опять же, будет работать только под универсальной платформой и не будет запускаться под другими. Потому LLVM IR под WAsm не работает ни на чем, кроме WAsm.

за все эти годы так и не вытеснил ниоткуда gcc

Шта? Браузеры собираются только clang. Все новые языки на llvm. Всякие там компиляторы шейдеров тоже.

Это gcc так и не вылез за пределы линя.

wasm ничем принципиально не отличается от llvm

wasm - это байт-код. llvm - оптимизирующий компилятор. Если вы про IR, то он намного ниже и сложнее. В wasm, насколько я знаю, доступа к железу вообще нет. Это скорее аналог байт-код а JVM.

я прибавил к массиву строку, а получилось 42, нидхелп

При чем тут приколы js к wasm?! Вы хоть сишку можете в него транслировать.

Вот недостаточно низкоуровневый получается.
Почему не jvm bytecode и не LLVM IR написано. JVM байткоды сложно верифицировать например

Наоборот, JVM байткод слишком низкоуровневый и позволяет творить что попало, из-за чего крайне тяжело с ним осмысленно работать. LLVM IR просто не предполагалось использовать в качестве байткода для выполнения в виртуалке - с этим можно было поработать, на самом деле, но никому эта идея не пришлась по душе.

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

При чем тут приколы js к wasm?! Вы хоть сишку можете в него транслировать

При том, что есть абстрактные влажные мечты, а есть суровые реалии, где под каждую прикладную сферу нужно тщательно специализироваться, чтобы быть конкурентноспособным. И не исключено, что спустя небольшое время возникнут немного отличающиеся ветки WAsm отдельно для браузеров и отдельно для всего остального.

Не, ну если с козырей заходить, то я и на перле могу)