Разработчики PSPDFKit представили (https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc.../) новый инструментарий (https://github.com/PSPDFKit-labs/pspdfkit-webassembly-benchmark) для измерения производительности реализации WebAssembly в различных web-браузерах, нацеленный на воспроизведение ситуаций, типичных для реальных проектов на C/C++, скомпилированных в WASM. Напомним, что WebAssembly предоставляет (https://www.opennet.me/opennews/art.shtml?num=46117) не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программирования.При тестировании выполняются различные процедуры обработки PDF-файлов и замеряется как производительность выполнения операций, так и суммарное время с учётом загрузки и компиляции псевдокода WASM.
Лидером при тестировании производительности стал Firefox, который выполнил набор тестов WebAssembly в 2.4 раза быстрее, чем Chrome, в 8.7 раз быстрее Edge и в 6.4 раза быстрее Sagari. В Chrome 69 ожидается рост производительности WebAssembly благодаря включению нового оптимизирующего компилятора для WebAssembly, который пока доступен только через экспериментальный флаг enable-webassembly-baseline. Тем не менее, включение данного флага в текущих экспериментальных выпусках Chrome приводит к увеличению производительности примерно на 20%, т.е. Firefox всё равно остаётся в два раза быстрее.
Примечательно, что в Edge и Sagari из-за длительной фазы компиляции и отсутствия некоторых важных оптимизаций тест WebAssembly выполнялся дольше, чем аналог на JavaScript. Производительность WebAssembly и JavaScript в Chrome отличается незначательно. Наибольшая разница в скорости выполнения тестов WebAssembly и JavaScript зафиксирована в Firefox.URL: https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc.../
Новость: https://www.opennet.me/opennews/art.shtml?num=48919
>Примечательно, что в Edge и Sagari из-за длительной фазы компиляции и отсутствия некоторых важных оптимизаций тест WebAssembly выполнялся дольше, чем аналог на JavaScript.Да в хроме тоже отличие не поражает на повал. WebAssembly пока оправдан только для ff, а как дышаль, а как дышаль.
На математике (image resize) у FF я как-то не заметил прорывов. WA везде примерно на 0-25% пошустрее оптимизированного js, но в FF постабильнее - там js иногда залипает, если тест много раз запускать.
а мы эту хрень придумали вовсе и не для производительности (это мазила, как обычно, повелась на рекламу и неверно поняла задачу).
Просто obfuscated js что-то стали быстро реверсить.
> Просто obfuscated js что-то стали быстро реверсить.Ну расскажи нам, очередной адепт "васм для хакеров, js слишком понятен", что делает вот этот чистый, НЕобфусцированный JS код из боевого проекта:
заодно можешь рассказать чем он более понятен аналогичного wasm кода.$152 = ($143 | 0) == ($141 | 0);
if ($152) {
$153 = 1 << $138;
$154 = $153 ^ -1;
$155 = HEAP32[(gb + 169192 | 0) >> 2] | 0;
$156 = $155 & $154;
HEAP32[(gb + 169192 | 0) >> 2] = $156;
break;
}
$157 = ($143 | 0) == ($145 | 0);
if ($157) {
$$pre441 = $143 + 8 | 0;
$$pre$phi442Z2D = $$pre441;
} else {
$158 = HEAP32[((gb + 169192 | 0) + 16 | 0) >> 2] | 0;
$159 = $158 >>> 0 > $143 >>> 0;
if ($159) {
_abort(), asyncState ? abort(-12) | 0 : 0;
}
$160 = $143 + 8 | 0;
$161 = HEAP32[$160 >> 2] | 0;
$162 = ($161 | 0) == ($10 | 0);
if ($162) {
$$pre$phi442Z2D = $160;
} else {
_abort(), asyncState ? abort(-12) | 0 : 0;
}
}
$163 = $141 + 12 | 0;
HEAP32[$163 >> 2] = $143;
HEAP32[$$pre$phi442Z2D >> 2] = $141;p.s. Как же эти макаки задрали...
Действительно, макакам не понять всей боли, которая ожидает того, кто будет читать ваш код. Как вы да такого вообще дошли и зачем?
Может он бывший фортранист?
Это результат работы Emscripten :-)
то есть по сути того же Wasm, но от другой лавочки.Ну и что вас удивляет? Мы не любим это ваше llvm, и сделали свое - с блэкджеком, небыстрое, потому что нужна была вовсе не скорость - и заставили всех заимплементить, поэтому оно будет работать у всех, хотят они того или нет. Хахахахахаха!
(уходит причинять всем добро)
Нет, это не wasm. Это старый добрый asm.js, который уже 5 лет как вовсю используется в вебе (https://en.wikipedia.org/wiki/Asm.js).И, на минуточку, это именно что JS - он работает на всех без исключения js виртуальных машинах, просто на старых он будет работать медленно, а на новых - очень быстро.
Имея asm.js я бы сказал, что wasm не нужен, ибо толку с него, почти как с козла молока. Но wasm, теоретически, можно транслировать под любую виртуальную машину, в то время как asm.js жестко привязан к джаваскрипту.
дык, не переживайте - теперь точно так же "на всех без исключения" (обоих) будет работать и честный webasm.> Но wasm, теоретически, можно транслировать под любую виртуальную машину
но зачем?
Не будет. Вы не понимаете - asm.js, это тот же JS, просто специально оформленный, что позволяет модным js машинкам его очень быстро исполнять. Но и старые js тоже его будут выполнять, просто "как обычно", без ускорения.Wasm же требует специальное расширение в браузере. Старые браузеры его выполнять не смогут.
Когда код, где все названия переменных представлены числами, называют необфусцированным...Серьёзно???
Да ещё и кусок кода без изначального присвоения значений этим переменным - ну-ка быстро сказали что делает этот кусок кода!...
> p.s. Как же эти макаки задрали...
Еще раз - это нормальный, обычный, необфусцированный JS код, которого в вебе уже 5 лет как полным полно. И который выполняется в любых, даже очень старых (умеющих в js) браузерах, даже под телевизорами.Ну и я, конечно, могу вам предъявить все N-тысяч строк, но смысл? Ведь и так понятно, что от замены вот этого выше на wasm хуже точно не станет.
Ознакомьтесь со значением слов, которыми пытаетесь оперировать:
Обфуска́ция (от лат. obfuscare — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку) или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему её функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции.
Если у тебя asm.js мегабайт на 30 - то аналог в WebAssembly будет меньше раза в два и шустрее запускаться раз в пять.
а выкинуть нахрен то и другое и перенести обработку на сервер, где с ней справится native бинарник на 30 килобайт - уже совсем нельзя?P.S. "зато мы победили npapi и прочие binary plugins". Которые решали эту задачу, хотя бы, эффективно (и заметно для пользователя, а вот это нехорошо)
>выкинуть нахрен то и другое и перенести обработку на сервер, где с ней справится native бинарник на 30 килобайт - уже совсем нельзя?Перенести майнинг на сервер? Смишная шутка
довольно сложно перенести, например, отрисовку сцены игры на сервер
> довольно сложно перенести, например, отрисовку сцены игры на серверавторы doom (и по-моему wolf3d с ними) смотрят на вас с некоторым удивлением.
наоборот же ж ровно - на сервере у тебя есть видеокарта (и не одна, если это такой специальный отрисовочный сервер), а проблемы 60fps over ip давным-давно решены.
>проблемы 60fps over ip давным-давно решеныНе решены только проблемы лага пользовательского ввода. Надо либо сервер ставить ближе (на расстоянии вытянутого провода клавиатуры, например), либо делать игры с учётом лага.
а у вас что - игры еще и однопользовательские (авторы doom...ну вы поняли ;-) ?
в остальных случаях - все равно ж надо их как-то решать.И проблема будет в rtt, а не в полосе.
> а у вас что - игры еще и однопользовательские (авторы doom...ну вы поняли ;-) ?Doom вообще-то однопользовательский. не считая прикрученный проволокой мультиплеер, в котором на 30 минут пострелять.
Можно теоретически. Но:
1) если это игра или даже интерактивный редактор процесс обмена с сервером может оказаться куда более тормозным, чем переживёт пользователь.
2) масштабирование хреновое. А так всё просто - пользователь запустил, у него всё и крутится. И, в общем, ведёт себя прилично даже на мобиле.
3) это надо делать клиент-сервер вместо того, чтобы перетащить готовый десктопный софт сравнительно умеренными усилиями.Причём даже не сказать, что у юзера большой оверхед - WASM нативу в среднем меньше, чем вдвое проигрывает по скорости (есть провалы вроде шифрования, так как на данный момент у WASM нет доступа к SSE сотоварищи). По памяти там вообще ерунда отличие - пракда, есть крайнние случаи, так как отдавать память браузеру и, тем более, системе в процессе работы WASM не умеет. То есть если потребление равномерное - всё ок, но если был пик - отожранное будет держать, пока вкладку не закроют. Но в общем и целом для среднего случая оно на удивление живое.
А плагины имеют слишком много полномочий, чтобы их запускать, не спрашивая, а если спрашивать - то попытка поиграть в очередную попавшуюся в сети игрушку будет слишком напряжной для рядового юзера. И лично я очень рад, что их убили до того, как прилетел тот же Spectre, с которым в браузерах мгновенно справились, загрубив таймер, а что бы делали с плагинами (и сколько бы из них обновилось) - большой вопрос.
И давно у вас браузерные 3D игры строят логику рендереринга на сервере?
> И давно у вас браузерные 3D игры строят логику рендереринга на сервере?на asmjs без доступа к видеокарте им проще это делать?
Почему без доступа? OpenGL ES там сто лет как
> будет меньше раза в два и шустрее запускаться раз в пять.К сожалению, не будет.
https://hacks.mozilla.org/files/2016/10/asmjs-wasm-compariso...
Так у них там ничего крупного и нет. С определённого размера asm.js тупит. Я для живого продакшна это дело гонял, пришлось померить. Там много причин - например, asm.js надо догрузить целиком прежде, чем он начнёт парситься, а для wasm это делается по ходу загрузки, и это никак не лечится.
Посидим, подождем. Рядовым разрабам WASM не нужен. Он скорее нужен для тех, кто компиляторы пишут из божественного Rust, Go, C++ в WASM.А прикладные разрабы будут клепать приложухи на том, на чем хотят, чтобы потом в вебе запускать.
Это как DX/OpenGL/Vulkan никто напрямую не использует, а юзают просто игровые движки и все счастливы.
Пожелаем удачи WebAssembly. Просто хорошая площадка для портирования приложух не JS в окружение, где раньше был JS.
У C# неплохие перспективы тут, у QT.
> Пожелаем удачи WebAssembly. Просто хорошая площадка для портирования приложух не JS в окружение, где раньше был JS.Одна проблема - нечем портировать. Emscripten каждый месяц ломают обратную совместимость и не пишут документацию. Уже заeбался все время под новые сдк переделывать, плюнул - форкнул один из предыдущих полугодичной давности, зафризил и решил на новые совсем забить.
Из самой мякотки - выкинули возможность собрать в один модуль, теперь разных файлов сразу пять штук. Зачем?? Еще обломали динамически подгружаемые модули (точнее выкатили уже седьмую реализацию, совсем сломанную; на четвертой я сдался переделывать и слил все в статику - файл теперь, конечно, приходится сразу весь грузить). Но зато время на посратьcя с разработчиками альтернативных компиляторов (например https://github.com/leaningtech/cheerp-meta/issues/76) у них, конечно, есть.
В общем это выглядит как типичная студенческая RnD - никакого планирования, просто кодим. Пришла новая идея? Нахер все ломаем и переделываем с нуля. С такими разработчиками у WebAssembly будущего нет.
> плюнул - форкнул один из предыдущих полугодичной давности, зафризил и решил на новые совсем забить.Форкнул - это когда продолжаешь развитие. Если зафризил - то можно было и просто сделать checkout того последнего ещё работающего для тебя релиза или даже коммита.
> В общем это выглядит как типичная студенческая RnD - никакого планирования, просто кодим.По приведенной ссылки я вижу, что тот код (по крайней мере cheerp), что доступен всем на гитхабе - просто демка. Оптимизирующие патчи и поддержка POSIX, чтобы можно было не только бенчи компилировать, лежат в закрытых приватных репах и
> We actually provide extended support for POSIX APIs to our commercial customers with an add-on library.Так что уж лучше открытый RnD, чем полуоткрытое непонятно что, которое пишет, что лучше emscripten, а по сути или хуже или практически на том же уровне.
> Так что уж лучше открытый RnD, чем полуоткрытое непонятно что, которое пишет,
> что лучше emscripten, а по сути или хуже или практически на том же уровне.Ну с этим я спорить не буду. Лучше.
Только в данном случае получается "редька вкуснее хрена", а толку?
Да и хрен бы с ним, asm.js у них точно так же менялся всё время, мешало это вполне умеренно. Тупо пишешь в скриптах развёртывания или в доках конкретную версию и в emsdk-portable её и устанавливаешь.
Я конечно с другой планеты, но вот эти конкретные "зафриженые" версии разве потом не имеют проблем с безопасностью?
Помню когда все клали JQuery на сайтики и он абсолютно всегда был старый и дырявый.
Не больше, чам старые "зафриженые" версии gcc. Вообще безопасностью там в основном занимается песочница браузера. Что-то может быть (допустим, если сделать как-то особо тупо загрузку asm.js), но шансов мало по многим причинам.
Firefox стабильно удерживает лидерство по производительности. Хрому пора переходить на spidermonkey.
Судя по графику, spidermonkey уступает V8 на 30% (JavaScript). Это Фурифоксу пора переходить на V8. WASM же быстрее на FF.
Как пользователь Firefox уже в течении лет 10ти могу подтвердить тот факт что ЖАБАскрипт в нем тормознее чем Chrome, даже Edge.Раздражает еще тот факт что по памяти firefox течет не реально жутко, для примера, браузинг с 5-6 вкладками занимает 500-800 мб, но через минут 10 firefox уже весит около 1.9-2гб озу при тех же 5-6 вкладках но другими сайтами. Наводит на тот факт что память за собой ой как лениво он подчищает. Если зайти в about:memory и нажать "Minimize memory usage" внезапно очищается 1.2-1.5 гб мусора.
Я тебе секрет открою, никому не говори: эти 1.2-1.5Гб "мусора" на 100% состоят из кэшированных картинок и прочей медиаинформации, чтобы у тебя при браузинге ничего не тормозило и жесткий диск с сетью не насиловались лишний раз.
Я, как пользователь ФФ со стажем более 10 лет, что нужно бы Вам проверить настройки и расширения - это ненормальное явление для ФФ.
У меня более-менее постоянно висит 30-40 вкладок + 27 расширений - редка за 1 гигабайт ФФ выходит. Конкретно сейчас, 41 вкладка - 764 МБ.P.S. Ах, да, я до сих пор на ESR 52-й версии - из-за старых расширений, которым не могу найти замену, а самому писать лень. Но новые версии, вроде как, даже пошустрее и меньше памяти занимают, но врать не буду :)
Пиши список расширений. Найду отличную замену всем 100%.
Как насчёт чего-нибудь для открывания mht и сохранения в нём же? Ишак и хромоподобные это умеют из коробки, старая опера тоже умела, а вот в файрфоксе оба имевшихся дополнения с переходом на quantum отвалилилсь.
> Как насчёт чего-нибудь для открывания mht и сохранения в нём же? Ишак
> и хромоподобные это умеют из коробки, старая опера тоже умела, а
> вот в файрфоксе оба имевшихся дополнения с переходом на quantum отвалилилсь.А это чем плохо? Умеет сохранять страницу полностью в один файл.
https://addons.mozilla.org/ru/firefox/addon/save-page-we/
Tab Kit 2nd Edition + дополнения к нему.
В свое время искал - отличных замен в упор не было видно. Поделки типа Tree Style Tab не предлагать: знаю, пользовался - до Tab Kit далеко.
SQLite Manager ?
> Если зайти в about:memory и нажать "Minimize memory usage" внезапно очищается 1.2-1.5 гб мусора.У меня так было из-за аддонов. И это был прямо косяк разработчика аддона.
В общем текучесть это не баг, а фича, т.е. какой-то гунокод на JS не делает нормально уборку памяти, заставляя (по логике программы) хранить все эти объекты, а виноват почему-то FF?
p.s. Проблема довольно эффективно решается Tab Suspender-ами, которые тушат все фоновые вкладки.
Кстати, у меня так же сделано и в хроме, который в противном случае ел бы у меня порядка 12-14 Гигабайт за сессию. Но не из-за текучести,а из-за выделения по 150 Мб на каждую вкладку.
Когда проводил различные тесты, JS фокса был в целом чуть быстрее хрома, который был чуть быстрее ноды, которая была в несколько раз быстрее эджа
Так что V8 vs Spider - вопрос спорный
Почему-то тесты проводятся на таком железе как i7 / 32GB. Видимо скоро всем срочно придётся выкинуть на помойку свои девайсы с 4 и 8 ГБ памяти, чтоб не тормозило!
Потому что 16 ГБ уже недостаточно!
ГБ недостаточно
Даешь ТБ в каждый планшет!
8 уже минимум. Причем минимум такой.. не особо комфортный. Новую машину меньше чем с 16 я бы крайне не советовал покупать. Как некоторые живут на 4 и меньше не представляю. Машина будет однозадачной.p.s. я не говорю, что мне это нравится или устраивает, просто это факт.
Вполне комфортно с 4 ГБ одновременно играю в Minecraft (ему выделено 1.5 ГБ вместо стандартного 1 ГБ), сижу в Firefox и общаюсь в Discord. Памяти хватает.
Я не очень понимаю как будет выглядеть исходник веб-страницы с этим вебассембли? Мне предлагают запускать левый исполняемый файл у себя в браузере и молиться, чтобы песочница браузера была не дырявая?
Ты и сейчас загружаешь себе левый JS-файл и молишься, что бы песочница была не дырявая.
>молиться, чтобы песочница браузера была не дырявая?именно так
>>молиться, чтобы песочница браузера была не дырявая?
> именно таки noscript тебе от него не поможет, потому что это не скрипт.
Для того и делали.Ишь, взяли моду, копаться в нашем прекрасном коде!
> и noscript тебе от него не поможет, потому что это не скрипт.С noscript жить в современном мире вообще невозможно. Особенно если речь о современных одностраничных сайтах (что добавляет скорости загрузки страниц, кстати)
> современных одностраничных сайтах (что добавляет скорости загрузки страниц, кстати)с хрена ли? Скорость загрузки страницы - это скорость открытия соединений с мильярдом cdn (вы ж по другому давно разучились, паршивый шрифт, которым вы заменили графические элементы интерфейса, потому что так модно, надо непременно тащить с гугля) и скорость загрузки тонн графического мусора через эти соединения (или через одно, если вдруг случилось чюдо или вы уже получили свою долю от роскомпозора и подготовке чебурнета)
Ну и скорость рендеринга всего этого, что тоже далеко не всегда быстро. Какая нафиг разница, сколько в ем страниц? (нет, не подгружать сразу при открытии неотображаемую графику они научились, давно уже)
noscript, кстати, слегка помогает - если соединения для script src= не открываются ;-)
Запросто можно, я так живу. Этих самых "современных одностраничных" довольно мало, да и там обычно достаточно разрешить полтора домена - это если вообще какое-то взаимодействие с ними нужно, а не открыл - посмотрел/прочёл/закрыл.
>С noscript жить в современном мире вообще невозможно. Особенно если речь о современныхЯ вам скажу крамольную мысль, только пусть, пожалуйста, причастные не обижаются. А ненужны эти современные вебы. Не открылось? Вебмакака сама виновата. Рано или поздно ей прилетит от начальника.
Для юзера сплошная польза: лучше выйти прогуляться, чем на очередной информационный мусор пялиться.
> и noscript тебе от него не поможет, потому что это не скрипт.wasm подгружается из js (да и сам по себе не имеет доступа к большей части api браузера)
На сайте mozilla есть примеры. Либо так <script type='module'>, либо fetch
> левый исполняемый файл у себя в браузереон не исполняемый
Ровно так же, как и сейчас с джаваскриптом. Даже не так - у JS есть доступ к DOM и прочим API браузера, у WASM в текущей реализации его нет, используется джаваскриптовый бридж. Ни в чём у WASM нет больше полномочий, чем у джаваскрипта.
Тут что-то не так.
Буквально неделю назад я собирал сканер qr кодов, который в случае wasm показал количество отсканированных кодов в 11 раз больше чем та же реализация на джаваскрипт.
> в 11 раз больше чем та же реализация на джаваскрипт.Попробуй asm.js; плюсы - будет работать даже в старых телевизорнызх браузерах, минусы - чуть-чуть медленнее васма.
обколются своими веб-приложениями и потом майнят биткойны во вкладках
Что-то не все так просто. У меня тоже тест запощен для декодирования WebPhttps://demo.elibsystem.ru/node/35841
Разницу WebAssembly с JS в Firefox вообще не видно, а в JS заметно быстрее Firefox при первом запуске теста, что наводит на мысли, что Firefox оптимизирует JS заранее, а Chrome при выполнении.
