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 обязательно
Обсуждение (116) Ajax | 1 уровень | Линейный | Раскрыть всё | 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. НЕ учитывают ни системные особенности каждой из ОС. (то есть работают отвратительно -- изнутри).
    2. НЕ учитывают Human Interface Guidelines принятые для каждой конкретной ОС. (то есть выглядят отвратительно снаружи).

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

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

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

     
  • 6.79, Ordu (ok), 19:35, 28/03/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Это хорошо Чем ниже по стеку софта происходит абстракция от железа и ОС, тем лу... текст свёрнут, показать
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У этих ребят обычный 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 +/
    Никакая бинарь не устраивает. Компиляцию вообще следует рассматривать исключительно как кэширование — она нужна только для производительности, а единственной каноничной и пригодной для распространения формой программы является исходный код.
     

  • 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 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так уже нет хипстеров на годе, нода давно не в тренде.
     
     
  • 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 +/
    В следующих версиях это один из приоритетов. Так что если сейчас не умеет, то скоро будет.
     
     
  • 3.127, Урри (?), 06:48, 25/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не факт. Ребята из эмскриптен уже 6 вариант многопоточности изобретают, и все никак нормально не летит.
     

  • 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
    Добавить, Поддержать, Вебмастеру