Dhrystone на WebAssembly

[vak]

В продолжение темы: меряем эффективность WebAssembly. Берём известный тест Dhrystone и компилируем для WASI:

$ make
/opt/wasi-sdk-16.0/bin/clang -O -DNRUNS=100000000 -c -o dhry_1.o dhry_1.c
/opt/wasi-sdk-16.0/bin/clang -O -DNRUNS=100000000 -c -o dhry_2.o dhry_2.c
/opt/wasi-sdk-16.0/bin/clang -o dhrystone dhry_1.o dhry_2.o

$ file dhrystone
dhrystone: WebAssembly (wasm) binary module version 0x1 (MVP) 

Запускаем:

Nanoseconds for one run through Dhrystone: 35.3    
            Million Dhrystones per Second: 28.331  
                                    DMIPS: 16124.6

Для сравнения скомпилим в родной бинарник:

$ make
cc -O -DNRUNS=100000000 -c -o dhry_1.o dhry_1.c
cc -O -DNRUNS=100000000 -c -o dhry_2.o dhry_2.c
cc -o dhrystone dhry_1.o dhry_2.o

$ file dhrystone
dhrystone: Mach-O 64-bit executable x86_64

Запускаем:

Nanoseconds for one run through Dhrystone: 25.4    
            Million Dhrystones per Second: 39.351  
                                    DMIPS: 22396.8 

Получаем скорость 16124.6 на Wasm по сравнению с 22396.8 на родном Интеле. То есть потеря 28% производительности: неплохо! Вполне терпимо для для виртуальной машины такой сложности.

Comments

[juan_gandhi]

Ну неплохо!

Там еще такая фигня, что jit optimization может уделать только так все эти нативные компиляции.

[vak]

Тут не только JIT, но и пред-компиляция.

"Wasmtime is built on the optimizing Cranelift code generator to quickly generate high-quality machine code either at runtime or ahead-of-time."

[x86128]

Сам по себе WebAssembly штука довольно интересная. Он вроде бы и байт-код, но такой что в нем невозможны переходы на произвольный адрес внутри программы - только по границам функций или блоков в условном switch-case. Тоже касается с адресацией массивов в общем случае.

[vak]

Так ведь и классно.
Может, пора изучать AssemblyScript.

https://www.assemblyscript.org/introduction.html

[kondybas]

То-есть, железо-микрокод-инструкции-ОС-ВМ-бинарь.

И это все потому, что никто не хочет отдавать свою ОС или микрокод в паблик домейн или опенсорс? И пусть будет пять слоев накладных расходов для реализации anywhere, но табачок врозь?

А вот интересно было бы прошить тот же Wasm внутрь хеона вместо AMD64...

[dmytrish]

Вроде бы смысл абстракции именно в том, чтобы было все равно, над чем она.

> пять слоев накладных расходов

– вроде как пост о том, что даже при таком раскладе просадка производительности всего -28% по сравнению с машинным кодом.

Касательно реализации в железе: интересно, можно, но зачем? Что это даст, кроме невозможности апгрейда машины иначе, чем через мусорный бак? Впрочем соглашусь, что amd64 в исполнении Intel тоже тот еще софтверный цирк с Intel ME, Minix и все равно багами вроде Spectre/Meltdown внутри.

[ivanrubilo]

Spectre/Meltdown это слегка про другое, я бы даже багами это не назвал - скорее сопутствующие фичи - это из оперы как сделать быстрее - закешировать, а потом опа, а закешированный стейт от одной проги можно выудить из другой проги, ну да, теперь будем стейт зачищать (что медленно и энергоёмко, но можно чикенбитными барьерами сделать) либо как-то тегировать стейты примерно как ASID/VMID.

[kondybas]

Смысл абстракции в том, что объективно существует лютый зоопарк железа, архитектур, осей, и версий софта. И что для обуздания этого зоопарка нужны квалифицированные и недешевые люди. Альтернатива людям - такая же лютая избыточность железа. Лишнее дисковое пространство, лишняя память, лишние ядра, лишние гигабиты/сек.

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

Хороший профит можно бы было получить, устранив зоопарк, но всякое железо, всякая ось и софт - это вендорлокинг, с которого поставщик тоже снимает жырную стружку. Вот прям взять и все, непосильным трудом нажитое, раздать разным нищебродам? Щяз. Тут вон некоторые в поисках вендорлока покрепче перепробовали все - от моторолы и интеля до арма :)

По поводу амд64 поверх микрокода - понятна выгода интеля. Можно рынок насегментировать в мелкий винегрет. Можно продавать фичи процов по подписке. В эконом-пакете можно только отнимать и делить. В премиум пакете включена доступная пользователю плиса для АИ и частота 2х от номинала. По письму от госдепа - отключат анальный зонд (один из, по выбору).
Но вот выгода потребителя тут не вполне понятна. Он платит за товар, который изрядную долю времени работает не в интересах потребителя.

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