The OpenNET Project / Index page

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

Mozilla развивает WASI для использования WebAssembly вне браузера

28.03.2019 11:11

Разработчики Mozilla представили проект WASI (WebAssembly System Interface), в рамках которого ведётся работа по определению программных интерфейсов, которые можно использовать для организации взаимодействия приложений, поставляемых в формате WebAssembly, с операционной системой. Целью проекта является предоставление API, расширяющего область использования WebAssembly и позволяющего создавать на базе данной технологии обычные программы, выполняемые вне браузера, переносимые на любые платформы и демонстрирующие высокий уровень безопасности.

WASI даёт возможность из окружения для выполнения WebAssembly получить доступ к предоставляемым операционной системой функциям, таким как файлы, файловая система, сетевые сокеты, таймеры и генераторы случайных чисел. API WASI изначально развивается как не привязанный к браузерам и независящий от JavaScript/Web API, но при этом обеспечивающий должный уровень изоляции от основной системы (приложения запускаются в sandbox) и позволяющий явно определять предоставляемые приложению полномочия в стиле CloudABI и Capsicum.

В WASI применяется модель безопасности на основе управления возможностями, в рамках которой программа может выполнять только заведомо разрешённые действия. По аналогии с тем, как WebAssembly ограничивает доступ на уровне импорта функций, в WASI осуществляется контроль доступа к системным возможностям. Файлы, каталоги, сокеты и другие ресурсы ассоциируются со специальным типом файловых дескрипторов (capability), а для выполнения действия с каждым из ресурсов приложению должны быть даны полномочия. Полномочия обрабатываются иерархически, т.е. предоставив доступ к каталогу, автоматически открывается и доступ ко всем файлам в нём.

Так как WebAssembly является платформонезависимым вариантом языка Ассемблер, благодаря применению JIT можно добиться уровня производительности близкого к нативному коду, сохранив при этом возможность выполнения на различных аппаратных платформах и операционных системах. В настоящее время проектом предоставляется модуль wasi-core с реализацией базовых POSIX API (файлы, сокеты и т.п.), в котором пока отсутствует поддержка блокировок и асинхронного ввода/вывода. В дальнейшем планируется создание модулей с реализацией API для выполнения криптографических операций, работы с 3D-графикой, взаимодействия с датчиками, операциями с процессами (пока не поддерживается вызов fork) и обработки мультимедийных данных.

В настоящее время уже доступны для тестирования прототипы следующих компонентов:

  • wasmtime - runtime для выполнения WebAssembly-приложений с расширениями WASI как обычных обособленных приложений. Поддерживается как запуск байткода WebAssembly при помощи специальной утилиты командной строки, так и компоновка готовых исполняемых файлов (wasmtime встраивается в приложение как библиотека). Для достижения должного уровня производительности применяется JIT-компилятор на базе генератора кода cranelift;
  • Lucet - другой вариант runtime от проекта Fastly (код планируется опубликовать сегодня или завтра);
  • WASI SDK - инструментарий для компиляции приложений C/C++ в формат WebAssembly, использующий Clang 8.0;
  • Сборочная цель с поддержкой WASI для языка Rust, позволяющая компилировать код Rust в WebAssembly. В начале апреля поддержку WASI планируется интегрировать в основную кодовую базу и начать тестирование в ночных сборках;
  • wasi-sysroot - реализация стандартной библиотеки libc для WASI, основанная на коде musl, а также runtime-прослойка для трансляции предоставляемых библиотекой функций в системные вызовы различных операционных систем для достижения возможности выполнения одного WASI-приложения в разных ОС.

Проектом также развивается JavaScript-библиотека polyfill с реализацией WASI для выполнения приложений внутри браузера (демонстрация), позволяющая применить к выполняемому в браузере коду модель разграничения доступа на основе "capabilities". Из планов упоминается создание на базе WASI системы модулей для интеграции в приложения изолированных плагинов с дополнительной функциональностью, поставляемой в формате WebAssembly.

Напомним, WebAssembly во многом напоминает Asm.js, но отличается тем, что является бинарным форматом, не завязанным на JavaScript и позволяющим выполнять в браузере низкоуровневый промежуточный код, скомпилированный из различных языков программирования. Среди основных задач WebAssembly выделяется обеспечение переносимости, предсказуемость поведения и идентичности выполнения кода на разных платформах. По сравнению с JavaScript использование WebAssembly также позволяет существенно сократить размер приложений, благодаря компактному промежуточному коду, и увеличить скорость декодирования. В WebAssembly не требуется применение сборщика мусора, так как применяется явное управление памятью.

  1. Главная ссылка к новости (https://hacks.mozilla.org/2019...)
  2. OpenNews: Предварительный выпуск Qt для WebAssembly
  3. OpenNews: Запуск WebAssembly runtime как модуля ядра Linux
  4. OpenNews: В Chrome развивается API для создания полноценных пользовательских приложений
  5. OpenNews: Сравнение производительности различных реализаций WebAssembly
  6. OpenNews: В рамках проекта Nebulet развивается микроядро для запуска WebAssembly
Лицензия: CC-BY
Тип: Интересно / К сведению
Ключевые слова: webassembly, wasi
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (115) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Попугай Кеша (?), 12:18, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Так-так-так. JVM? CLR? Так-так-так. WebAssembly в массы? Чем их обычная бинарь не устраивает?
     
     
  • 2.3, proninyaroslav (ok), 12:22, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +10 +/
    А бинарь кроссплатформенный?
     
     
  • 3.12, Аноним (12), 13:02, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какое мне, как пользователю, удобство с кроссплатформенного бинаря?
     
     
  • 4.36, Аноним (36), 14:14, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +20 +/
    Теперь вирусы, чтобы запустить, не придется компилять и устанавливать для них Wine. Очевидный профит же.
     
     
  • 5.68, Аноним (68), 17:15, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    То, что это не бинарь, не означает, что он не будет win специфичный апи юзать. Ваш кеп
     
  • 4.46, Аноним (46), 15:22, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Меньше денег платить за ПО / больше качественных вещей появится за то же время.

    легенда: "коммерческое ПО"/"свободное ПО".

     
     
  • 5.71, X4asd (ok), 17:33, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Меньше денег платить за ПО

    верно!

    > больше качественных вещей появится за то же время.

    НЕ верно.

    кросплатформенные программы как правило УСТУПАЮТ в качестве своим НЕкросплатформенным собратьям.

    кросплатформенные:
    1. НЕ учитывают ни системные особенности каждой из ОС. (то есть работают отвратительно -- изнутри).
    2. НЕ учитывают Human Interface Guidelines принятые для каждой конкретной ОС. (то есть выглядят отвратительно снаружи).

    // P.S.: а вообще (даже если неважно речь про кросплатформенность или нет) -- выбери из трёх любые два пункта:
    //       сделать быстро!
    //       сделать дёшево!
    //       сделать качественно!

     
     
  • 6.74, Аноним (74), 18:19, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > как правило УСТУПАЮТ в качестве своим НЕкросплатформенным собратьям.

    Примеры собратьев можно?

     
  • 6.79, Ordu (ok), 19:35, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > 1. НЕ учитывают системные особенности каждой из ОС. (то есть работают отвратительно -- изнутри).

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

    > 2. НЕ учитывают Human Interface Guidelines принятые для каждой конкретной ОС. (то есть выглядят отвратительно снаружи).

    Вот уж на что мне плевать, так это на эти гайдлайны. Ещё не хватало жертвовать архитектурой или скростью в пользу всей этой хрени.

     
     
  • 7.115, mickvav (?), 12:32, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тебе-то может и плевать, особенно если ты пилишь софт для себя. А вот юзеры, которые плотют денюжку
    за софт (или тратят время, разглядывая рекламку в "бесплатном"), голосуют за нативное.

    Это-вот-всё уже есть в Java EE- кросс-платформенность, "универсальный" UI, байт-код, компилирующийся в натив. Оно взлетело, но ниша у него весьма своеобразная - кровавый ынтырпрайз, где юзеры - наемные манагеры (люди подневольные) и софт для управления экзотическими железками. Ну и какое-то количество серверного ПО в том же кровавом ынтырпрайзе. Чтобы "откомпилил-работает-не трожь".

     
  • 7.116, mickvav (?), 12:33, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тебе-то может и плевать, особенно если ты пилишь софт для себя. А вот юзеры, которые плотют денюжку
    за софт (или тратят время, разглядывая рекламку в "бесплатном"), голосуют за нативное.

    Это-вот-всё уже есть в Java EE- кросс-платформенность, "универсальный" UI, байт-код, компилирующийся в натив. Оно взлетело, но ниша у него весьма своеобразная - кровавый ынтырпрайз, где юзеры - наемные манагеры (люди подневольные) и софт для управления экзотическими железками. Ну и какое-то количество серверного ПО в том же кровавом ынтырпрайзе. Чтобы "откомпилил-работает-не трожь".

     
  • 6.113, Аноним (113), 10:41, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    кроссплатформенность означает только то, что разработчик озаботился наличием возможности собрать и запустить приложение на разных платформах. это с интеграцией не связано ни как. ни что не мешает написать по отдельному модулю на каждую платформу для учета как системных, так и UI особенностей
     
     
  • 7.119, X4asd (ok), 16:23, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в уме теоретика может и не мешает на практике это необосноанно усложняет програ... текст скрыт, показать
     
  • 4.62, Аноним (62), 16:33, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    JIT-компилятор будет использовать оптимальные инструкции для твоего проца, а не для самого стаорого из поддерживаемых
     
     
  • 5.66, Crazy Alex (ok), 17:05, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    в свободном софте это решается компиляцией
     
     
  • 6.99, axredneck (?), 22:06, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    которая занимает время и системные ресурсы (речь ведь идет о компиляции на целевой системе?)
     
     
  • 7.103, Аноним (103), 23:59, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    JIT тоже "занимает время и системные ресурсы". Только если с AOT один раз собрал бинарник и потом запускай сколько хочешь с минимальным оверхедом, то JIT вынужден при каждом запуске по-новой, "каждый раз как в первый раз", компилировать один и тот же код.
     
  • 7.104, Гентушник (ok), 00:05, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    emerge и все дела. Не вручную же сидеть и каждую программу собирать.
     
  • 5.86, АнонимГоним (?), 20:08, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >JIT-компилятор

    Мы ведь все знаем что можно легко доставить памяти куда угодно. Падажжи...

     
  • 5.95, irinat (ok), 21:18, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У JIT-компилятора обычно на это нет времени.
     
  • 4.70, proninyaroslav (ok), 17:29, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Какое мне, как пользователю, удобство с кроссплатформенного бинаря?

    Для разрабов удобно.

     
     
  • 5.72, X4asd (ok), 17:38, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Какое мне, как пользователю, удобство с кроссплатформенного бинаря?
    > Для разрабов удобно.

    а какое удобство для пользователя?

    // P.S.: или хочешь намекнуть что "ды плевать на пользователя!"?

     
     
  • 6.81, proninyaroslav (ok), 19:40, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Какое мне, как пользователю, удобство с кроссплатформенного бинаря?
    >> Для разрабов удобно.
    > а какое удобство для пользователя?
    > // P.S.: или хочешь намекнуть что "ды плевать на пользователя!"?

    Ну будет у пользователя один бинарник универсальный для всех платформ. Как минимум неудобств из-за этого не будет

     
  • 4.75, Аноним (74), 18:22, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не знаю, какое Вам лично удобство. Но мне как разработчику представляется, что сегодня заниматься некроссплатформенными проектами (особенно вновь создаваемыми) - глупость и пустая трата времени. Хотя не исключаю, что профит от таких проектов иметь можно. С другой стороны, мошенники тоже имеют профит от глупости клиентов. Но мы же их не уважаем?
     
     
  • 5.102, Имя (?), 22:34, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://ru.wikipedia.org/wiki/POSIX

    Зачем тут бинарь?

     
  • 4.98, axredneck (?), 22:04, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я понял, пользователю удобство в том, что этот бинарь точно запустится, а не скажет, что в системе не хватает такой-то версии такой-то библиотеки. Но в основном удобство не для пользователя, а для разработчика, которому не придется создавать и распространять кучу бинарей, и при этом он продолжит писать на своем любимом С/С++.
     
  • 4.109, anonymous (??), 07:03, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  Какое мне, как пользователю, удобство с кроссплатформенного бинаря?

    Не будет утекать в сутки по 500 метров оперативки, как у замечательного бинаря leechcraft. Количество разработчиков ограничено, они не могут осилить всё и сразу. Разработчики leechcraft, например, не осилили. А пользовались бы виртуальной машиной со сборкой мусора - хоть JVM, хоть CLR, хоть электроном - смогли бы написать неглючный софт своими силами.

     
  • 2.8, Аноним (8), 12:46, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У этих ребят обычный NIH синдром. Лет 5 теперь будут копировать функционал из Java и .NET
     
     
  • 3.50, VEG (ok), 16:10, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У них немного разные цели. Байт-код Java и .NET несколько более высокоуровневый.
     
  • 3.78, Аноним (78), 19:05, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Из LLVM…
     
     
  • 4.80, Ordu (ok), 19:36, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что, например, они оттуда будут копировать, мне очень интересно? Ты можешь привести пример?
     
  • 3.100, axredneck (?), 22:09, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И как этот функционал использовать в С/С++, не копируя его?
     
  • 2.17, Аноним (17), 13:11, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Теперь можно сделать кроссплатформенный systemd.
     
     
  • 3.29, nobody (??), 13:49, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Всмысле под любой линукс?
     
     
  • 4.31, Аноним (17), 13:52, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Даже под чайник и кофеварку.
     
  • 2.105, Аноним (105), 02:25, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    not invented in Mozilla
     
  • 2.117, Аноним (117), 13:00, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Никакая бинарь не устраивает. Компиляцию вообще следует рассматривать исключительно как кэширование — она нужна только для производительности, а единственной каноничной и пригодной для распространения формой программы является исходный код.
     
  • 1.2, Аноним (-), 12:22, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +43 +/
    Васян - отличное название для проекта!
     
  • 1.4, Аноним (4), 12:23, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    это вместо провалившейся ноды-жс?
     
     
  • 2.11, Аноним (11), 12:58, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это вообще из другой оперы.
     
  • 2.14, НяшМяш (ok), 13:09, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > провалившейся ноды-жс

    А хипстеры и не знали

     
     
  • 3.34, Аноним (34), 13:59, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так уже нет хипстеров на годе, нода давно не в тренде.
     
     
  • 4.82, Аноним (82), 19:41, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не уверен, что мне правда хочется это знать, но всё же спрошу: что сейчас в тренде у HDD-хипстеров?
     
  • 2.85, Аноним (85), 19:55, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То-то оно для разработки половины сайтов в сети используется. Сразу видно проволилось.
     
  • 1.7, Аноним (7), 12:27, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А васян умеет в многопоток? мне кажется что пока нет
     
     
  • 2.9, WebMonkey (?), 12:53, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В браузере ты можешь запускать WebAssembly в отдельном Worker thread'е.
     
     
  • 3.110, Ydro (?), 07:41, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И на сцену вновь выходит привязка к JavaScript.
     
  • 2.23, Иваныч (??), 13:27, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В следующих версиях это один из приоритетов. Так что если сейчас не умеет, то скоро будет.
     
  • 1.10, Аноним (10), 12:53, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А вот это уже годнота. WASI за единую VM с единым WASM. Это хорошо. Учитывая, что это идет от браузеров, то с их толщиной слоя разработчиков может стать стандартом де-факто для клиентских приложений, не требующих заточку производительности под определенную платформу.
     
     
  • 2.15, Аноним (17), 13:10, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это убийца Electron-а?
     
     
  • 3.42, Попугай Кеша (?), 15:14, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Нет, это убийца вашей оперативки и нервов руководителей проектов
     
  • 2.47, Аноним (46), 15:25, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если это сможет вытеснить жс с нодой - то я двумя руками за. Даешь веб/десктоп на своем любимом языке и на любой платформе.

    p.s. Если бы ЖС не был таким уeбищным... А пока обходимся православным С и богомерзким эмскриптен.

     
     
  • 3.53, YetAnotherOnanym (ok), 16:19, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если это сможет вытеснить жс с нодой

    Дадада, это примерно как смыть с одежды содержимое кишечника содержимым мочевого пузыря.

     
  • 3.106, Ан (??), 03:18, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты просто не умеешь его готовить
     
  • 3.124, Аноним (124), 19:14, 31/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы ЖС не был таким уeбищным...
    > ES6 is better than all the other popular dynamic languages (Python, Ruby, Perl and PHP) and has far better implementations. Add on Typescript and it's not even close.
    > The only dynamic languages better than ES6 are languages that nobody uses (Smalltalk, Scheme, Common Lisp, Clojure, Erlang etc.).
     
  • 1.16, Аноним (16), 13:11, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > wasi-sysroot - основанная на коде musl,

    А как же чудесная libc на Rust из Redox? На Rust решила забить уже даже Мозила?

     
     
  • 2.54, Аноним (54), 16:21, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Сборочная цель с поддержкой WASI для языка Rust, позволяющая компилировать код Rust в WebAssembly.

    Redox компилять в WASI. Redox будет поддерживать море железа.

     
     
  • 3.83, Аноним (-), 19:42, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это пет-проект какого-то alexcrichton.
     
  • 3.111, Ydro (?), 07:46, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ...Rust в WebAssembly - это ваш код, а не не интерпретатор/компилятор WebAssembly реализованный на Rust.
     
  • 1.18, Аноним (18), 13:13, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Сколько ГБ оперативки надо еще докупать?
     
     
  • 2.55, YetAnotherOnanym (ok), 16:21, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    (Ёмкость самого большого доступного модуля)*(Число слотов в Вашей МП)
    Ваш К.О.
     
     
  • 3.76, Аноним (74), 18:24, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Благодаря вполне демократичным ценам ... Вы правы.
     
     
  • 4.94, Аноним (94), 20:58, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У вас за МКАДОМ эти может и можно назвать демократичными, а у нас в России это по пол зарплаты за планку 8ГБ.
     
     
  • 5.114, Аноним (114), 10:55, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну так, если предки отстёгивают бабки, чтобы у сыночка был такой компьютер, который ему нужен для учёбы (как они думают) - почему бы сыночку не считать любую цену демократичной?
     
  • 5.126, rex (??), 11:25, 08/04/2019 [^] [^^] [^^^] [ответить]  
  • +/
    35$*2
    правда?
     
  • 2.56, Аноним (54), 16:22, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Неужели оно не экономичнее Электрона?
     
  • 2.67, Crazy Alex (ok), 17:08, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    само оно жрёт процентов на 20 больше натива, как ни странно. Всё остальное - браузернве фишки вроде DOM. Но идея запускать что-то, чему ты не доверяешь - всё равно дурная
     
  • 1.19, Аноним (19), 13:16, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    WebAssembly в браузере пока никто и не использует, о каком "вне браузера" вообще может идти речь?
     
     
  • 2.20, Иваныч (??), 13:24, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Об элементарном. Хотя бы использование C/C++/D/... в Sandbox окружении для системы дополнений к приложению которые не требуют пересборки. Пример - игровая логика в Quake 3 & QVM, где логика была на C, но в Sandbox, практически с идетичной скоростью работы. Да, есть LLVM, но Web Assembly заметно проще, плюс ещё и возможность использовать тот же модуль использовать в Web при необходимости.
     
  • 2.41, Kuromi (ok), 15:11, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вообще-то используют. Печально известный Coinhive использовал WASM для того чтобы майнить крипту в браузерах. Зато инновационно.
     
     
  • 3.58, Аноним (54), 16:25, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное, и загрубление точности таймеров в браузерах WebAsm-у не помешает спектрить.
     
     
  • 4.88, Crazy Alex (ok), 20:39, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    помешает. Таймер - это внешний по отношению к васму сервис, загрубление повлияет ровно так же, как и на джаваскрипт какой-нибудь
     
  • 1.21, Аноним (82), 13:25, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Неееет! Остановите их кто-нибудь, хватит с нас нодыжс!
     
     
  • 2.24, Аноним (16), 13:35, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Нода божественна! И она тоже умеет в васм.
     
  • 2.25, Аноним (11), 13:36, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не пользуйся, тебя никто не заставляет.
     
  • 2.26, Иваныч (??), 13:39, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Казалось бы, что общего между JS интерпретором и виртуальной машиной для выполнения кода на C/C++ с практически одинаковой (близкой и ещё ближе в следующих версиях) скоростью исполнения?
     
     
  • 3.28, Аноним (28), 13:45, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То и другое написано на C++.
     
  • 3.30, Аноним84701 (ok), 13:52, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Казалось бы, что общего между JS интерпретором и виртуальной машиной для выполнения
    > кода на C/C++ с практически одинаковой (близкой и ещё ближе в следующих версиях) скоростью исполнения?

    Клятвенные обещания и торжественные заверения (причем, еще со времен JIT для первых Жабо-Не-Скрипт-VM), что "еще немного, совсем чуть-чуть и оно совсем уже скоро почти догонит и  многократно перегонит нативный Васюк^W код по скорости исполнения!1!"?
    https://arxiv.org/abs/1901.09056
    > (Submitted on 25 Jan 2019)
    > We then use BROWSIX-WASM to conduct the first large-scale evaluation of the performance of WebAssembly vs. native.
    > Across the SPEC CPU suite of benchmarks, we find a substantial performance gap: applications compiled to
    > WebAssembly run slower by an average of 50% (Firefox) to 89% (Chrome), with peak slowdowns of 2.6x (Firefox) and 3.14x (Chrome).

    .

     
     
  • 4.33, Иваныч (??), 13:58, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    LLVM & QVM (Quake 3 VM, но только Pure C) давно умеют в 10% разницы от силы. У We Assembly есть все шансы стать стандартизипрванным LLVM который также умеет в браузере. С поддержкой нескольких крупных производителей. Что есть не плохо.
     
     
  • 5.37, Аноним84701 (ok), 14:18, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > LLVM & QVM (Quake 3 VM, но только Pure C) давно умеют в 10% разницы от силы.

    Только вот VM в LLVM эдакий "исторический прикол" и ни разу не VM в "привычно-традиционном" смысле.
    Таким макаром можно и GCC в VM записать, c его GIMPLE/RTL и прочими промежуточными представлениями.

     
     
  • 6.38, Иваныч (??), 14:34, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я в курсе. Но я немного не об этом, не об использовании LLVM для генерации кода, а о возможности использования LLVM BitCode (Target) как библиотеки вне зависимости от операционной системы и ограничения такого модуля от доступа к системным вещам вне предоставленного API приложения которое такой модуль занрузило в качестве изолированной библиотеки.
     
     
  • 7.60, Аноним (54), 16:30, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так, всё-таки, LLVM BitCode или WebAsm?
     
  • 7.97, Ordu (ok), 21:48, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    http llvm org docs BitCodeFormat html Отсюда видно, что это эффективно _пром... текст скрыт, показать
     
  • 4.89, Crazy Alex (ok), 20:44, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    WASM и так почти нативен по скорости, вот прямо сейчас. За исключением случаев, когда в нативе используются какие-нибудь специфические инстукции типа AES-NI. Но, в отличие от джаваскриптов/джав, который можно на лету оптимизировать, не "перегонит" никогда.
     
  • 3.77, Аноним (82), 19:01, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Казалось бы, что общего между JS интерпретором и виртуальной машиной для выполнения кода на C/C++ с практически одинаковой (близкой и ещё ближе в следующих версиях) скоростью исполнения?

    Например то, что их вытащили из браузера и используют не по назначению.

     
  • 1.22, Аноним (22), 13:26, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    если сделают компилятор pascal в wasi будет круто
     
     
  • 2.40, Аноним (40), 15:04, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > если сделают компилятор pascal в wasi будет круто

    pasiwasi

     
     
  • 3.61, Аноним (54), 16:31, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    pascwasi
     
  • 2.43, Аноним (43), 15:14, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    http://forum.lazarus.freepascal.org/index.php?topic=37474.0
     
  • 1.27, kiwinix (?), 13:43, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Развитие Васи уже сильно продвинулось
     
  • 1.32, Аноним (32), 13:57, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теперь это надо прикрутить к проекту, в котором "всё URL" ;)
     
     
  • 2.44, Попугай Кеша (?), 15:15, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы про Redox OS? )
     
  • 1.35, AnonPlus (?), 14:05, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если оно будет близко по производительности к нативному коду, то почему бы и нет?
     
     
  • 2.63, Аноним (54), 16:33, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Будет ли по производиьтельности близко или нет, а вот песочницу обходить точно будет.
     
  • 1.39, Аноним (39), 14:43, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    electron 2.0 ?
     
  • 1.45, Kuromi (ok), 15:16, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ой, опять Мозилла за старое. Подобных прожектов у Мзиллы была уже тонна, самых разных калибров. Большинство потом отправляются известно куда - в забвение. Призм для десктопов, Телефон в браузере, FirefoxOS и так далее.
    И это не смотря на то, что пару лет назад они приняли принцип "great or dead" на вообружение, не распыляться, а делать что-то в малом кол-ве, но хорошо, мы все равно видим что все по прежнему. Может быть какая-то польза от проекта и будет, но имхо лучше бы они работали над браузером.
     
     
  • 2.49, Аноним (49), 15:46, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Бюджет сам себя не распилит.
     
  • 2.73, Аноним (73), 17:44, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >great or dead

    Сам догадаешься, куда качнулись чаши весов?

     
  • 1.51, Аноним (54), 16:12, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, сколько нам уязвимостей чудных готовит WASI-друг...
     
  • 1.57, Аноним (-), 16:22, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    я правильно понимаю, что теперь кроссплатформенные приложения будут сначала писаться на полноценных языках, потом транслироваться в жс и превращаться в нативные?

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

     
     
  • 2.64, Аноним (54), 16:40, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну возьмём, к примеру, GUI. В Linux их по факту два. Так что, как кроссплатформенно ни старайся, либо гномеры будут недоволны, либо кдешники.
     
     
  • 3.87, Ordu (ok), 20:25, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > либо гномеры будут недоволны, либо кдешники.

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

     
  • 2.90, Crazy Alex (ok), 20:48, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Неправильно. WASM с JS связывает только то, что оно в браузерах есть. А так - просто платформенно-нейтральное представление, довольно низкоуровневое. Ожидаемые мозиллой плюшки - отсутствие необходимости отдельно компилировать под несколько аппаратных платформ и песочница (которую, правда, и так можно сделать, и делают).
     
  • 1.59, Анонимс (?), 16:26, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    10% разницы с нейтивом - это терпимо. Wasm-core встроить в каждую ОС и не нужно больше компилять.  
     
     
  • 2.65, Аноним (54), 16:42, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И вирусы будут кроссплатформенными.
     
  • 2.69, X4asd (ok), 17:15, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Wasm-core встроить в каждую ОС и не нужно больше компилять.  

    всё это приведёт к тому же говну к которому пришла Java (JVM).

    1. программисты вместо того чтобы выдавать ПОЛНЫЙ исходный код проекта (даже если проект ВЕСЬ опенсурсный) -- предлагают компилировать из исходников только ядро-программы.

    2. пользователь (или мэйнтейнер дистрибутива) компилирует проект. а на самом деле не проект, а только его ядро-программы, но декларирует будто скомпилировал проект.

    3. программа запущенная пользователем -- по мере своей работы докачиает из интернета БИНАРНИКИ остальных своих частей.

    4. скачивание НЕ удаётся так как:
      
        a) пользователь НЕ сидит круглосуточно в интернете.

        b) пользователь СИДИТ в интернете но НЕ все ip-адреса доступны и хорошо работают из Чебурашки (или из VPN-против-Чебурашки, так как ряд CDN-провайдеров намеренно блокируют VPN. типа защищая сервера от "хакеров"). вобщем есть кучу причин почему ДОкачаться из интернета может НЕ удасться.

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

    6. всех проблем можно было бы избежать если бы НЕ было бы уверенности у разработчика что "скомпилируй один раз и запускай везде": в этом случае у разработчика врядли зародилось бы желание ВТЮХИВАТЬ бинарники (докачивая из интернета) прямо во время работы программы.

    // P.S.: примеры java-говна смотри: Apache Netbeans (в исходниках одно, а скачивется дополнительно другое, прямо во время работы) и Maven (без интернета вообще не заработает, неважно что ты установил его из репозитория).

    // P.P.S.: в чём вообще проблема компилирования? и если не хочешь заставлять компилировать то почему бы не решить это через например flatpak?

     
     
  • 3.92, Crazy Alex (ok), 20:52, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то тут перепутаны автоматическое затягивание зависимостей и закрытость кода.

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

    Хочешь иметь все исходники - берёшь GPL-софт. А если лицензия позволяет закрытый код - какие претензии?

     
     
  • 4.118, X4asd (ok), 13:16, 29/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что-то тут перепутаны автоматическое затягивание зависимостей и закрытость кода.

    нет. не перепутаны. а взаимосвязаны.

    возможность запускать бинарники без компиляции -- тенят за собой СТРАННОЕ жедание разработчиков делать "затягивание зависимостей (бинарников)".

    "мы будем автоматически закачивать к клиенту недостающие бинарники, ведь всё равно мы уверены что не будет проблем с их запуском!" -- видимо так думают разработчики.

    то есть речь о том что эта возможность портит "культуру".

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

    вот как раз python не тянет зависиомси пока ты не попросишь его явно об этом. (а можно устроить себе даже так что вообще не попросит НИКОГДА -- если делать самому вручную ''python setup.py install'')

    * можешь поставить зависимость из репозитория
    * можешь скачать исходники (настоящие! а не исходники "ядра-программы") и сделать ''python setup.py ...''
    * можешь в ЯВНОМ виде попросить накачать из python-овского pypi.

    любой из трёх способов в конечном итоге приведёт к рабочему результату.

    > Хочешь иметь все исходники - берёшь GPL-софт. А если лицензия позволяет закрытый код - какие претензии?

    опять-двадцать-пять! всё что с казал КАК ОРАЗ И ОТНОСИТСЯ К GPL/APACHE СОФТУ! софту который имеет открытые исходники, но который всё равно скачивает тебе бинарники (бинарники мимо репозитория и собранные неясно из каких исходников -- из тех которые на github или из каких-то других -- фиг проверишь)

     
  • 3.93, Crazy Alex (ok), 20:54, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема комиляции - что надо компилировать под разные платформы. В основном боль проприетарщиков, конечно, но и просто держать систему сборки, умеющую собирать под всё и вся - та ещё морока.
     
     
  • 4.101, _Vitaly_ (ok), 22:18, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я под ноду запиливал порт гугловского конвертора woff2, на WebAssembly. Ляпота! Один раз собрал, и везде работает, и по мере выхода новых нод не ломается.

    Правда оно ориентировочно раза в 2 медленнее сишного. Но это приемлемая цена за полное отсутствие гимора. Сейчас наверное уже побыстрее должно быть.

    У нативных бинарных модулей обычно раз в год-два чего-нибудь разъезжается.

     
  • 3.96, Анонимус2 (?), 21:30, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Maven

    Отлично работает без интернета

     
  • 1.84, Аноним (84), 19:46, 28/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прободение песочницы. Саша Грей в безопасности.
     
  • 1.107, Тот_Самый_Анонимус (?), 05:28, 29/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Адоб закрывает флэш. Ява так и не взлетела на настольных компах. А эти думают что ухватили бога за бороду и их поделие будет самым крутым.
     
  • 1.123, Аноним (123), 12:09, 31/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Неплохая инициатива. Хотя можно было просто открыть Flash. Но...адоби - онаж идейная.
     
  • 1.125, Брат Анон (?), 08:30, 02/04/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Люся... Вася... Наши люди везде штале?
    Тогда и Валеру давайте ужо!
     

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



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

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