The OpenNET Project / Index page

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

Сравнение производительности различных реализаций WebAssembly

06.07.2018 11:32

Разработчики PSPDFKit представили новый инструментарий для измерения производительности реализации WebAssembly в различных web-браузерах, нацеленный на воспроизведение ситуаций, типичных для реальных проектов на C/C++, скомпилированных в WASM. Напомним, что WebAssembly предоставляет не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программирования.

Лидером при тестировании производительности стал Firefox, который выполнил набор тестов WebAssembly в 2.4 раза быстрее, чем Chrome, в 8.7 раз быстрее Edge и в 6.4 раза быстрее Safari. В Chrome 69 ожидается рост производительности WebAssembly благодаря включению нового оптимизирующего компилятора для WebAssembly, который пока доступен только через экспериментальный флаг enable-webassembly-baseline. Тем не менее, включение данного флага в текущих экспериментальных выпусках Chrome приводит к увеличению производительности примерно на 20%, т.е. Firefox всё равно остаётся в два раза быстрее.

Примечательно, что в Edge и Safari из-за отсутствия некоторых важных оптимизаций тест WebAssembly выполнялся дольше, чем аналог на JavaScript. Производительность WebAssembly и JavaScript в Chrome отличается незначительно. Наибольшая разница в скорости выполнения тестов WebAssembly и JavaScript зафиксирована в Firefox. При тестировании выполнялись различные процедуры обработки PDF-файлов и замерялось как производительность непосредственного выполнения операций, так и суммарное время с учётом загрузки и компиляции псевдокода WASM.

  1. Главная ссылка к новости (https://pspdfkit.com/blog/2018...)
  2. OpenNews: В рамках проекта Nebulet развивается микроядро для запуска WebAssembly
  3. OpenNews: Предварительный выпуск Qt для WebAssembly
  4. OpenNews: Mozilla развивает прослойку для обеспечения переносимости между JavaScript и Rust
  5. OpenNews: Технология WebAssembly признана готовой для включения в браузерах по умолчанию
  6. OpenNews: Для GCC представлен бэкенд c реализацией WebAssembly
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48919-webassembly
Ключевые слова: webassembly
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (70) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, хрю (?), 11:38, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Примечательно, что в Edge и Sagari из-за длительной фазы компиляции и отсутствия некоторых важных оптимизаций тест WebAssembly выполнялся дольше, чем аналог на JavaScript.

    Да в хроме тоже отличие не поражает на повал. WebAssembly пока оправдан только для ff, а как дышаль, а как дышаль.

     
     
  • 2.10, _Vitaly_ (ok), 12:42, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На математике (image resize) у FF я как-то не заметил прорывов. WA везде примерно на 0-25% пошустрее оптимизированного js, но в FF постабильнее - там js иногда залипает, если тест много раз запускать.
     
  • 2.11, хрюгль (?), 12:43, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    а мы эту хрень придумали вовсе и не для производительности (это мазила, как обычно, повелась на рекламу и неверно поняла задачу).
    Просто obfuscated js что-то стали быстро реверсить.

     
     
  • 3.14, Урри (?), 13:05, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Просто 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. Как же эти макаки задрали...

     
     
  • 4.15, Илья (??), 13:24, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Действительно, макакам не понять всей боли, которая ожидает того, кто будет читать ваш код. Как вы да такого вообще дошли и зачем?
     
     
  • 5.17, Аноним (17), 13:36, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Может он бывший фортранист?
     
  • 5.20, sklsmgw (?), 14:00, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это результат работы Emscripten :-)
     
     
  • 6.26, хрюгль (?), 15:07, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    то есть по сути того же Wasm, но от другой лавочки.

    Ну и что вас удивляет? Мы не любим это ваше llvm, и сделали свое - с блэкджеком, небыстрое, потому что нужна была вовсе не скорость - и заставили всех заимплементить, поэтому оно будет работать у всех, хотят они того или нет. Хахахахахаха!

    (уходит причинять всем добро)

     
     
  • 7.47, Урри (?), 18:52, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, это не wasm. Это старый добрый asm.js, который уже 5 лет как вовсю используется в вебе (https://en.wikipedia.org/wiki/Asm.js).

    И, на минуточку, это именно что JS - он работает на всех без исключения js виртуальных машинах, просто на старых он будет работать медленно, а на новых - очень быстро.

    Имея asm.js я бы сказал, что wasm не нужен, ибо толку с него, почти как с козла молока. Но wasm, теоретически, можно транслировать под любую виртуальную машину, в то время как asm.js жестко привязан к джаваскрипту.

     
     
  • 8.51, пох (?), 19:02, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    дык, не переживайте - теперь точно так же на всех без исключения обоих будет... текст свёрнут, показать
     
     
  • 9.68, Аноним (68), 15:25, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не будет Вы не понимаете - asm js, это тот же JS, просто специально оформленный... текст свёрнут, показать
     
  • 4.70, Аноним (70), 21:23, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Когда код, где все названия переменных представлены числами, называют необфусцированным...

    Серьёзно???

    Да ещё и кусок кода без изначального присвоения значений этим переменным - ну-ка быстро сказали что делает этот кусок кода!...


    > p.s. Как же эти макаки задрали...

     
     
  • 5.74, Аноним (68), 17:07, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Еще раз - это нормальный, обычный, необфусцированный JS код, которого в вебе уже 5 лет как полным полно. И который выполняется в любых, даже очень старых (умеющих в js) браузерах, даже под телевизорами.

    Ну и я, конечно, могу вам предъявить все N-тысяч строк, но смысл? Ведь и так понятно, что от замены вот этого выше на wasm хуже точно не станет.

     
     
  • 6.76, Аноним (70), 09:22, 11/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ознакомьтесь со значением слов, которыми пытаетесь оперировать:



    Обфуска́ция (от лат. obfuscare — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку) или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему её функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции.


     
  • 2.31, Crazy Alex (ok), 15:32, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя asm.js мегабайт на 30 - то аналог в WebAssembly будет меньше раза в два и шустрее запускаться раз в пять.
     
     
  • 3.34, нах (?), 15:59, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а выкинуть нахрен то и другое и перенести обработку на сервер, где с ней справится native бинарник на 30 килобайт - уже совсем нельзя?

    P.S. "зато мы победили npapi и прочие binary plugins". Которые решали эту задачу, хотя бы, эффективно (и заметно для пользователя, а вот это нехорошо)

     
     
  • 4.37, Аноним (37), 16:04, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >выкинуть нахрен то и другое и перенести обработку на сервер, где с ней справится native бинарник на 30 килобайт - уже совсем нельзя?

    Перенести майнинг на сервер? Смишная шутка

     
  • 4.40, sklsmgw (?), 16:51, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    довольно сложно перенести, например, отрисовку сцены игры на сервер
     
     
  • 5.52, пох (?), 19:04, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > довольно сложно перенести, например, отрисовку сцены игры на сервер

    авторы doom (и по-моему wolf3d с ними) смотрят на вас с некоторым удивлением.

    наоборот же ж ровно - на сервере у тебя есть видеокарта (и не одна, если это такой специальный отрисовочный сервер), а проблемы 60fps over ip давным-давно решены.

     
     
  • 6.55, Аноним (55), 20:21, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >проблемы 60fps over ip давным-давно решены

    Не решены только проблемы лага пользовательского ввода. Надо либо сервер ставить ближе (на расстоянии вытянутого провода клавиатуры, например), либо делать игры с учётом лага.

     
     
  • 7.56, пох (?), 20:50, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а у вас что - игры еще и однопользовательские (авторы doom...ну вы поняли ;-) ?
    в остальных случаях - все равно ж надо их как-то решать.

    И проблема будет в rtt, а не в полосе.

     
     
  • 8.69, Xasd (ok), 16:14, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Doom вообще-то однопользовательский не считая прикрученный проволокой мультипле... текст свёрнут, показать
     
  • 4.41, Crazy Alex (ok), 17:11, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно теоретически. Но:
    1) если это игра или даже интерактивный редактор процесс обмена с сервером может оказаться куда более тормозным, чем переживёт пользователь.
    2) масштабирование хреновое. А так всё просто - пользователь запустил, у него всё и крутится. И, в общем, ведёт себя прилично даже на мобиле.
    3) это надо делать клиент-сервер вместо того, чтобы перетащить готовый десктопный софт сравнительно умеренными усилиями.

    Причём даже не сказать, что у юзера большой оверхед - WASM нативу в среднем меньше, чем вдвое проигрывает по скорости (есть провалы вроде шифрования, так как на данный момент у WASM нет доступа к SSE сотоварищи). По памяти там вообще ерунда отличие - пракда, есть крайнние случаи, так как отдавать память браузеру и, тем более, системе в процессе работы WASM не умеет. То есть если потребление равномерное - всё ок, но если был пик - отожранное будет держать, пока вкладку не закроют. Но в общем и целом для среднего случая оно на удивление живое.

    А плагины имеют слишком много полномочий, чтобы их запускать, не спрашивая, а если спрашивать - то попытка поиграть в очередную попавшуюся в сети игрушку будет слишком напряжной для рядового юзера. И лично я очень рад, что их убили до того, как прилетел тот же Spectre, с которым в браузерах мгновенно справились, загрубив таймер, а что бы делали с плагинами (и сколько бы из них обновилось) - большой вопрос.

     
  • 4.44, Ydro (?), 17:55, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И давно у вас браузерные 3D игры строят логику рендереринга на сервере?
     
     
  • 5.53, пох (?), 19:05, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > И давно у вас браузерные 3D игры строят логику рендереринга на сервере?

    на asmjs без доступа к видеокарте им проще это делать?


     
     
  • 6.63, Crazy Alex (ok), 11:59, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Почему без доступа? OpenGL ES там сто лет как
     
  • 3.48, Урри (?), 18:56, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > будет меньше раза в два и шустрее запускаться раз в пять.

    К сожалению, не будет.
    https://hacks.mozilla.org/files/2016/10/asmjs-wasm-comparison.png

     
     
  • 4.64, Crazy Alex (ok), 12:02, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так у них там ничего крупного и нет. С определённого размера asm.js тупит. Я для живого продакшна это дело гонял, пришлось померить. Там много причин - например, asm.js надо догрузить целиком прежде, чем он начнёт парситься, а для wasm это делается по ходу загрузки, и это никак не лечится.
     

  • 1.3, Попугай Кеша (?), 11:45, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Посидим, подождем. Рядовым разрабам WASM не нужен. Он скорее нужен для тех, кто компиляторы пишут из божественного Rust, Go, C++ в WASM.

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

    Это как DX/OpenGL/Vulkan никто напрямую не использует, а юзают просто игровые движки и все счастливы.

    Пожелаем удачи WebAssembly. Просто хорошая площадка для портирования приложух не JS в окружение, где раньше был JS.

    У C# неплохие перспективы тут, у QT.

     
     
  • 2.12, Урри (?), 12:49, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Пожелаем удачи WebAssembly. Просто хорошая площадка для портирования приложух не JS в окружение, где раньше был JS.

    Одна проблема - нечем портировать. Emscripten каждый месяц ломают обратную совместимость и не пишут документацию. Уже заeбался все время под новые сдк переделывать, плюнул - форкнул один из предыдущих полугодичной давности, зафризил и решил на новые совсем забить.

    Из самой мякотки - выкинули возможность собрать в один модуль, теперь разных файлов сразу пять штук. Зачем?? Еще обломали динамически подгружаемые модули (точнее выкатили уже седьмую реализацию, совсем сломанную; на четвертой я сдался переделывать и слил все в статику - файл теперь, конечно, приходится сразу весь грузить). Но зато время на посратьcя с разработчиками альтернативных компиляторов (например https://github.com/leaningtech/cheerp-meta/issues/76) у них, конечно, есть.

    В общем это выглядит как типичная студенческая RnD - никакого планирования, просто кодим. Пришла новая идея? Нахер все ломаем и переделываем с нуля. С такими разработчиками у WebAssembly будущего нет.

     
     
  • 3.24, Андрей (??), 14:53, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > плюнул - форкнул один из предыдущих полугодичной давности, зафризил и решил на новые совсем забить.

    Форкнул - это когда продолжаешь развитие. Если зафризил - то можно было и просто сделать checkout того последнего ещё работающего для тебя релиза или даже коммита.

     
  • 3.29, Андрей (??), 15:15, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В общем это выглядит как типичная студенческая RnD - никакого планирования, просто кодим.

    По приведенной ссылки я вижу, что тот код (по крайней мере cheerp), что доступен всем на гитхабе - просто демка. Оптимизирующие патчи и поддержка POSIX, чтобы можно было не только бенчи компилировать, лежат в закрытых приватных репах и
    > We actually provide extended support for POSIX APIs to our commercial customers with an add-on library.

    Так что уж лучше открытый RnD, чем полуоткрытое непонятно что, которое пишет, что лучше emscripten, а по сути или хуже или практически на том же уровне.

     
     
  • 4.49, Урри (?), 18:57, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Так что уж лучше открытый RnD, чем полуоткрытое непонятно что, которое пишет,
    > что лучше emscripten, а по сути или хуже или практически на том же уровне.

    Ну с этим я спорить не буду. Лучше.
    Только в данном случае получается "редька вкуснее хрена", а толку?

     
  • 3.42, Crazy Alex (ok), 17:14, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да и хрен бы с ним, asm.js у них точно так же менялся всё время, мешало это вполне умеренно. Тупо пишешь в скриптах развёртывания или в доках конкретную версию и в emsdk-portable её и устанавливаешь.
     
     
  • 4.59, mumu (ok), 01:34, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я конечно с другой планеты, но вот эти конкретные "зафриженые" версии разве потом не имеют проблем с безопасностью?
    Помню когда все клали JQuery на сайтики и он абсолютно всегда был старый и дырявый.
     
     
  • 5.65, Crazy Alex (ok), 12:08, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не больше, чам старые "зафриженые" версии gcc. Вообще безопасностью там в основном занимается песочница браузера. Что-то может быть (допустим, если сделать как-то особо тупо загрузку asm.js), но шансов мало по многим причинам.
     

  • 1.4, Аноним (4), 11:52, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Firefox стабильно удерживает лидерство по производительности. Хрому пора переходить на spidermonkey.
     
     
  • 2.7, Аноним (7), 12:07, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по графику, spidermonkey уступает V8 на 30% (JavaScript). Это Фурифоксу пора переходить на V8. WASM же быстрее на FF.
     
     
  • 3.9, Аноним (9), 12:29, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как пользователь 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 гб мусора.

     
     
  • 4.28, Аноним (28), 15:11, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я тебе секрет открою, никому не говори: эти 1.2-1.5Гб "мусора" на 100% состоят из кэшированных картинок и прочей медиаинформации, чтобы у тебя при браузинге ничего не тормозило и жесткий диск с сетью не насиловались лишний раз.
     
  • 4.38, Иван (??), 16:21, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я, как пользователь ФФ со стажем более 10 лет, что нужно бы Вам проверить настройки и расширения - это ненормальное явление для ФФ.
    У меня более-менее постоянно висит 30-40 вкладок + 27 расширений - редка за 1 гигабайт ФФ выходит. Конкретно сейчас, 41 вкладка - 764 МБ.

    P.S. Ах, да, я до сих пор на  ESR 52-й версии - из-за старых расширений, которым не могу найти замену, а самому писать лень. Но новые версии, вроде как, даже пошустрее и меньше памяти занимают, но врать не буду :)

     
     
  • 5.67, Почти Аноним (?), 13:39, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Пиши список расширений. Найду отличную замену всем 100%.
     
     
  • 6.71, Аноним (71), 23:13, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как насчёт чего-нибудь для открывания mht и сохранения в нём же? Ишак и хромоподобные это умеют из коробки, старая опера тоже умела, а вот в файрфоксе оба имевшихся дополнения с переходом на quantum отвалилилсь.
     
     
  • 7.72, Почти Аноним (?), 04:54, 08/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Как насчёт чего-нибудь для открывания mht и сохранения в нём же? Ишак
    > и хромоподобные это умеют из коробки, старая опера тоже умела, а
    > вот в файрфоксе оба имевшихся дополнения с переходом на quantum отвалилилсь.

    А это чем плохо? Умеет сохранять страницу полностью в один файл.
    https://addons.mozilla.org/ru/firefox/addon/save-page-we/

     
  • 6.75, Аноним (75), 23:38, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Tab Kit 2nd Edition + дополнения к нему.
    В свое время искал - отличных замен в упор не было видно. Поделки типа Tree Style Tab не предлагать: знаю, пользовался - до Tab Kit далеко.
     
  • 6.77, OldFart (?), 11:07, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    SQLite Manager ?
     
  • 4.60, mumu (ok), 01:37, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если зайти в about:memory и нажать "Minimize memory usage" внезапно очищается 1.2-1.5 гб мусора.

    У меня так было из-за аддонов. И это был прямо косяк разработчика аддона.
    В общем текучесть это не баг, а фича, т.е. какой-то гунокод на JS не делает нормально уборку памяти, заставляя (по логике программы) хранить все эти объекты, а виноват почему-то FF?

     
     
  • 5.61, mumu (ok), 01:40, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    p.s. Проблема довольно эффективно решается Tab Suspender-ами, которые тушат все фоновые вкладки.
    Кстати, у меня так же сделано и в хроме, который в противном случае ел бы у меня порядка 12-14 Гигабайт за сессию. Но не из-за текучести,а  из-за выделения по 150 Мб на каждую вкладку.
     
  • 3.45, Аноним (45), 18:19, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Когда проводил различные тесты, JS фокса был в целом чуть быстрее хрома, который был чуть быстрее ноды, которая была в несколько раз быстрее эджа
    Так что V8 vs Spider - вопрос спорный
     

  • 1.16, Аноним (16), 13:29, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Почему-то тесты проводятся на таком железе как i7 / 32GB. Видимо скоро всем срочно придётся выкинуть на помойку свои девайсы с 4 и 8 ГБ памяти, чтоб не тормозило!
     
     
  • 2.19, 123 (??), 14:00, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что 16 ГБ уже недостаточно!
     
     
  • 3.30, Аноним (30), 15:15, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ГБ недостаточно
    Даешь ТБ в каждый планшет!
     
  • 2.33, Аноним (33), 15:47, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    8 уже минимум. Причем минимум такой.. не особо комфортный. Новую машину меньше чем с 16 я бы крайне не советовал покупать. Как некоторые живут на 4 и меньше не представляю. Машина будет однозадачной.

    p.s. я не говорю, что мне это нравится или устраивает, просто это факт.

     
     
  • 3.36, Аноним (36), 16:02, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вполне комфортно с 4 ГБ одновременно играю в Minecraft (ему выделено 1.5 ГБ вместо стандартного 1 ГБ), сижу в Firefox и общаюсь в Discord. Памяти хватает.
     

  • 1.18, Аноним (33), 13:45, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я не очень понимаю как будет выглядеть исходник веб-страницы с этим вебассембли? Мне предлагают запускать левый исполняемый файл у себя в браузере и молиться, чтобы песочница браузера была не дырявая?
     
     
  • 2.21, Алексей (??), 14:20, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +17 +/
    Ты и сейчас загружаешь себе левый JS-файл и молишься, что бы песочница была не дырявая.
     
  • 2.22, Аноним (22), 14:23, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >молиться, чтобы песочница браузера была не дырявая?

    именно так

     
     
  • 3.27, хрюгль (?), 15:10, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>молиться, чтобы песочница браузера была не дырявая?
    > именно так

    и noscript тебе от него не поможет, потому что это не скрипт.
    Для того и делали.

    Ишь, взяли моду, копаться в нашем прекрасном коде!

     
     
  • 4.46, Аноним (45), 18:22, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > и noscript тебе от него не поможет, потому что это не скрипт.

    С noscript жить в современном мире вообще невозможно. Особенно если речь о современных одностраничных сайтах (что добавляет скорости загрузки страниц, кстати)

     
     
  • 5.54, пох (?), 19:11, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > современных одностраничных сайтах (что добавляет скорости загрузки страниц, кстати)

    с хрена ли? Скорость загрузки страницы - это скорость открытия соединений с мильярдом cdn (вы ж по другому давно разучились, паршивый шрифт, которым вы заменили графические элементы интерфейса, потому что так модно, надо непременно тащить с гугля) и скорость загрузки тонн графического мусора через эти соединения (или через одно, если вдруг случилось чюдо или вы уже получили свою долю от роскомпозора и подготовке чебурнета)

    Ну и скорость рендеринга всего этого, что тоже далеко не всегда быстро. Какая нафиг разница, сколько в ем страниц? (нет, не подгружать сразу при открытии неотображаемую графику они научились, давно уже)

    noscript, кстати, слегка помогает - если соединения для script src= не открываются ;-)

     
  • 5.66, Crazy Alex (ok), 12:11, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Запросто можно, я так живу. Этих самых "современных одностраничных" довольно мало, да и там обычно достаточно разрешить полтора домена - это если вообще какое-то взаимодействие с ними нужно, а не открыл - посмотрел/прочёл/закрыл.
     
  • 5.73, Аноним (-), 16:24, 09/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >С noscript жить в современном мире вообще невозможно. Особенно если речь о современных

    Я вам скажу крамольную мысль, только пусть, пожалуйста, причастные не обижаются. А ненужны эти современные вебы. Не открылось? Вебмакака сама виновата. Рано или поздно ей прилетит от начальника.

    Для юзера сплошная польза: лучше выйти прогуляться, чем на очередной информационный мусор пялиться.

     
  • 4.62, kaa (??), 10:58, 07/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и noscript тебе от него не поможет, потому что это не скрипт.

    wasm подгружается из js (да и сам по себе не имеет доступа к большей части api браузера)

     
  • 2.23, анонимтут (?), 14:35, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На сайте mozilla есть примеры. Либо так <script type='module'>, либо fetch
     
  • 2.25, Xasd (ok), 14:58, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > левый исполняемый файл у себя в браузере

    он не исполняемый

     
  • 2.32, Crazy Alex (ok), 15:37, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ровно так же, как и сейчас с джаваскриптом. Даже не так - у JS есть доступ к DOM и прочим API браузера, у WASM  в текущей реализации его нет, используется джаваскриптовый бридж. Ни в чём у WASM нет больше полномочий, чем у джаваскрипта.
     

  • 1.35, demimurych (ok), 16:00, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тут что-то не так.
    Буквально неделю назад я собирал сканер qr кодов, который в случае wasm показал количество отсканированных кодов в 11 раз больше чем та же реализация на джаваскрипт.
     
     
  • 2.50, Урри (?), 19:00, 06/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > в 11 раз больше чем та же реализация на джаваскрипт.

    Попробуй asm.js; плюсы - будет работать даже в старых телевизорнызх браузерах, минусы - чуть-чуть медленнее васма.

     

  • 1.57, Аноним (57), 20:56, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    обколются своими веб-приложениями и потом майнят биткойны во вкладках
     
  • 1.58, Аноним (58), 21:44, 06/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что-то не все так просто. У меня тоже тест запощен для декодирования WebP

    https://demo.elibsystem.ru/node/35841

    Разницу WebAssembly с JS в Firefox вообще не видно, а в JS заметно быстрее Firefox при первом запуске теста, что наводит на мысли, что Firefox оптимизирует JS заранее, а Chrome при выполнении.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру