Опубликован выпуск инструментария Emscripten 4.0, позволяющего компилировать код на C/C++ и других языках, для которых имеются фронтэнды на базе LLVM, в универсальный низкоуровневый промежуточный код WebAssembly. Полученный результат можно использовать для интеграции с JavaScript-проектами, запуска в web-браузере, использования в Node.js или создания обособленных многоплатформенных приложений, запускаемых при помощи wasm runtime. Код проекта распространяется под лицензией MIT. В компиляторе используются наработки проекта LLVM, а для генерации WebAssembly и оптимизации задействована библиотека Binaryen...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62553
Качественный?
сам не пробовал, но слышал что вполне себе норм
на базе шланга качественного не бывает. кое-как работает и ладно - офф девиз шланга.
https://godbolt.org/z/rofYEcYqr - пример подхода в шланге. дело здесь даже не в Werror по дефолту. они просто захардкодили "s" как особый случай.
Но ведь так работает значит все правильно сделали.
https://en.cppreference.com/w/cpp/string/basic_string/operat...
типа статья про std::literals::string_literals::operator""s есть и потому ошибки нет, а про std::literals::string_literals::operator""x нету и потому ошибка есть? Ты это сказать хотел?И судя по набору имен, на которые не ругается (h/min/s/ms/us/ns), авторы костыля читали доку по хроно, а не про строки
> на базе шланга качественного не бывает. кое-как работает и ладно - офф девиз шланга.А как ты вообще представляешь себе качественный релиз либы весом 70 мегабайт бинарного кода? Это LLVM столько весит если что.
Количественный.
Да и давно. На нем в игры можно в браузере играть. Например в Quake. Когда-то давно была демка. Зададим вопрос по другому - только сейчас о нем узнали?
ну так себеhttps://framagit.org/fperrad/lua.wasm
261kB wasm + 77kB jsА без использования их стандартной библиотеки и всевозможных обёрток для fileIO, просто голым шлангом получилось собрать в два раза меньший объём.
Для какого-нибудь многомегабайтного ffmpeg или quake в браузер притащить лишние 100кБ не заметно, а для совсем мелочи слишком много ненужных обёрток, чтобы стандартная библиотека в браузере прозрачно работала.
Для современного веба, с современными скоростями это не проблема
вот поэтому современный веб и выглядит так, как он выгдядит
Реально работает. Я знаю контору, у них достаточно популярная и сложная в реализации мобильная игра (десятки миллионов скачиваний), написана на С с минимум зависимостей.
Почему нельзя было просто сделать джаваскрипт быстрым? Это же так просто.
Ждём пулл реквест в V8 и SpiderMonkey.
А чего тут ждать. Если вебасмембли такой быстрый почему джаваскрипт не может быть точно таким же.
Потому что скриптуха без типизации.А вообще впечатляют масштабы, в которых расплодились клоуны, требующие чтобы им дали ресурсов нахаляву. Даже если это в принципе невозможно - кого интересуют такие мелочи.
> А чего тут ждать. Если вебасмембли такой быстрый почему джаваскрипт
> не может быть точно таким же.Динамическая типизация видите ли идет в комплекте с нехилым оверхедом. Надо все время трекать тип и следить что он не изменился. И быть готовым ко всему.
А вон то - простой, низкоуровневый рантайм, не снабженный таким факапом. Намного более простая и потому шустрая абстракция.
Причём, что забавно - строгая типизация это такая абстракция, которая позволяет компилятору генерировать быстрый код. Потому что pointer aliasing.
Очень часто находятся "умники", которые заявляют, что всякая абстракция лишь замедляет код. Отнюдь.
Это не абстракция, обезьяныч. И никакой "pointer aliasing" тебе не поможет. Как и никакой "строгой" типизации не существует.
> Причём, что забавно - строгая типизация это такая абстракция,Это некий набор правил и/или гарантий когда компилер при генерации кода явно знает что сие и чем оно будет далее. И не должен генерить кучу кода проверяющего на каждый пшик что тип остался прежний.
То-есть при остром желании можно скастовать тип в другой тип - но и это тоже - декларация намерений ДО компиляции. Когда ВСЕ известно заранее. И не надо лепить кучу проверок что тип именно такой, а не что-то еще.
> которая позволяет компилятору генерировать быстрый код. Потому что pointer aliasing.
Это не главное. Главное - если компилер скажем знает что это uint32 - он его вообще в регистр проца впихает, и будет фигачить быстрыми операциями регистр-регистр, за 1 такт. А что либо с pointer там будет вообще только если эта абстракция кому-то где-то в другом месте потребовалась. Иначе это может быть нечто вообще не имеющее никаких адресов в памяти, если все абстракции оговоренные правилами - удерживаются.
Понимаешь ли, процессор не увидит разниц между указателями на int_32_t и строковым типом такой же длины, а вот компилятор, который в одном методе видит разные типы, как раз воспользуется данным преимуществом.
> Понимаешь ли, процессор не увидит разниц между указателями на int_32_t и строковым
> типом такой же длины,Как вы поняли - дереференс указателей вообще не самый быстрый способ работы. Быстрее всего - вгрузить нечто типа:
// a + b, псевдокод на манер асма
(uint32 a) -> r0
(uint32 b) -> r1
add r0, r1И тут вообще - никаких указателей могло не быть. И обращений к потенциально-тормозной памяти. Операции регистр-регистр самые быстрые. А значения операндов могут вообще непосредственно вкодированы - в формате этих команд. Так что не надо никаких дополнительных действий, операнды уже тут.
> а вот компилятор, который в одном методе
> видит разные типы, как раз воспользуется данным преимуществом.Лучший дереференс указателей - которого не было. Лучшая математика - которую вообще не считали (предвычислили все компилтайм). А то и вовсе - заметили что блок кода не имел side effects, вообще аннулировали. Если в том примере a и b заранее известны, компилер сделает mov r0, #10 (a + b == 10). Заскипав действо совсем. А если #10 в r0 никогда никому не надо было - то и это - заскипает! Вообще выпилив блок кода.
...но как вы понимаете, при динамической типизации просчитать подобные вещи заранее будет менее реалистично. Вариантов поведения программы - многократно больше, гарантий поведения тех или иных кусков - сильно меньше. И проситчать все компил тайм, без оверхеда и лишних проверок - да щас.
он может быть таким же, но никто не платит чтобы с этим заморачиваться. Будут платить за джаваскрипт 15 тысяч зелени в месяц, будут делать быстрее, а пока платят нищие 4000 пусть в баню идут, за такие копейки, ещё над чем-то думать.
В старом движке Opera Presto (2012 года) он был быстрый, но проект свернули.Любая математическая операция (синтетический тест) в JavaScript консоли старой Opera обгоняла в сотни раз по производительности тогдашний Chrome, а Firefox и подавно. Я не думаю что и сейчас ситуация изменилась, если протестировать.
> В старом движке Opera Presto (2012 года) он был быстрый, но проект свернули.В твоих фантазиях.
> обгоняла в сотни раз по производительности
В тысячи раз. Правда в фантазиях.
проверь умник, она же доступна для загрузки ещё, если нужно подсказать, что вводить в консоли - пиши, помогу, но по сути любая вычислительная операция с циклами, с массивами.Кстати, в долгих операциях и "в тысячи раз" превышать будет, т.к. там разница в производительности увеличивается по нарастающей.
Даже если они могли что-то стоищее создать, но они опустились до вранья своим пользователям, а потом вообще продали браузер.
А адекватные разработчики ушли в Vivaldi
Быстрым, наверное, можно сделать не JS, а TS. И то, если его компилять сразу в машинные коды. Ага, прямо из браузера компилер вызывать, а то как же кроссплатформенность.
Это называется JIT и давным-давно используется в браузерах.
Я сказал в машинные коды - _инструкции_CPU_, а не какой-то там языковой виртуальной машины. Мы же хотим, чтобы быстро. Да и нет необходимости языку со статической типизацией в этих JIT.
>> Это называется JIT и давным-давно используется в браузерах
> Я сказал в машинные коды - _инструкции_CPU_Чел, JIT *буквально* транслирует в машинные коды 🤦
Но быстро, это когда AOT.
> Я сказал в машинные коды - _инструкции_CPU_, а не какой-то там языковой
> виртуальной машины. Мы же хотим, чтобы быстро. Да и нет необходимости
> языку со статической типизацией в этих JIT.* Just-In-Time (JIT) компиляция в Java — это механизм, который позволяет ускорить интерпретацию байт-кода виртуальной машиной. 1
Простыми словами, механизм JIT компиляции заключается в следующем: если в программе присутствуют части кода, которые выполняются много раз, то их можно скомпилировать один раз в машинный код, чтобы в будущем ускорить их выполнение.
* Java — это статически типизированный язык.
(с) Яндекс Нейро
из того же источника:>[оверквотинг удален]
> rust не имеет статической типизации
>> Rust имеет статическую типизацию. Когда разработчик создаёт переменную в Rust, он должен сразу указать, какого она типа — что будет в ней храниться.
> в rust нет переменных, это скриптуха с gc и ссылками вместо переменных
>> В Rust есть переменные. Для их объявления используется ключевое слово let. По умолчанию переменные неизменяемы, но их можно сделать изменяемыми, добавив перед именем ключевое слово mut. Ссылки в Rust используются для управления памятью. В языке есть два типа ссылок: ссылки на чтение (shared reference) и изменяемые (мутабельные) ссылки. Ссылки подчиняются двум правилам: не должны жить дольше, чем данные, на которые они ссылаются, и мутабельная ссылка должна быть уникальна. Таким образом, Rust сочетает в себе особенности языка с ручным управлением памятью и сборщиком мусора: код получается чистым, как в языке с GC, но в то же время все ресурсы освобождаются максимально быстро, как в языке с ручным управлением.
> покажи мне sizeof от переменной в rust без испоьзования stdlib
>> Для получения размера переменной в Rust используется функция size_of_val. Пример использования: ```let a = 10i32; println!("{}", size_of_val(&a));```. Также для получения размера типа в байтах в Rust можно использовать функцию size_of из пакета std::mem.
> без испоьзования stdlib
>> Не удалось найти информацию о том, как получить sizeof от переменной в Rust без использования stdlib.
> правильно, потому что это невозможно. rust не знает ничего о переменных и их свойствах
>> Да, получить sizeof от переменной в Rust без использования stdlib невозможно, так как для этого используется специальная функция — size_of_val.с жавой будет то же самое. как и с любой другой скриптухой.
Не совсем понятно, что ты хотел сказать.
Да-да, знаем, слышали: "Java способна обогнать код на C++".
А ты замерь насколько он быстрый. Не знаю как проверяют бенчмарки, но мои замеры показывали производительность почти такую же как и на С. Конечно ты можешь вспомнить что-то про многопоточность, но я тоже могу вспомнить про воркеры. Конечно всё-равно это не многопоточность и тем не менее.
в qml и espruino как-то сделали
>>"-sWASM_LEAGCY_EXCEPTIONS"...
Есть тулкит на wasm для экспериментов с фильтрами ffmpeg в браузере. Если не перебарщивать со сложностью, wasm вполне полезная технология.
Кстати, кто не в курсе - SQLite давно портирован под браузер именно благодаря этой технологии.
Ссылка: https://sql.js.org/#/
Нечего тут пропагандировать свои извращения.
Вопрос глупый но всё же, зачем нужен этот ваш wasm? не проще былоб в браузеры встроить qemu\kvm
Google Native Client (NaCl)
кстати, где он (с)
Ну целую операционную систему с сервера грузить это наверное уже слишком. Но создать ABI для запуска блобов с доступом лишь к тому, что разрешили, можно. В хроме оно даже и было, но разрабы лисы надули щеки и сказали, что не будут запускать блобы и предложили asm.js. Но в конечном итоге пришли к wasm, но как бы лишь для реализации быстрых алгоритмов.
> Ну целую операционную систему с сервера грузить это наверное уже слишком.Вообще можете загуглить jslinux. Если дело делает профессионал как Фабрис - то и линух загрузить в браузере - не так уж ужасно как может показаться.
чтобы в нём заустить линукс в котором запустить браузер в котором запустить qemu-kvm .....
Чтобы зум и куча других вредоносных сайтов запустились, а не предложили просто проваливать. Компиляция в код, близкий к нативному, сильно осложняет реверс-инжиниринг. Это обфускация с виртуальной машиной: совмещает недостатки и нативного кода, и скриптов. Для кого-то это является достоинством.
> Компиляция в код, близкий к нативному, сильно осложняет реверс-инжиниринг.Не сильно. Просто для ревёрс-инжиниринга бинарного кода тебе нужны другие инструменты. Обфусцированный js ты будешь разбирать одними тулзами, бинарный wasm код ты будешь разбирать другими. А по-сути одно и то же.
Не проще. Софтварная виртуализация позволяет гораздо более гранулярно ограничивать код. Мало того, что возможно (в качестве глупого примера) ограничить количество операций с памятью в секунду, доступных программе, так ведь ещё и применять эти ограничения можно очень выборочно, для тех частей кода применять, для этих не применять.qemu умеет в софтварную виртуализацию, но он виртуализует огромные и сложные архитектуры, которые заточены под выполнение на железном CPU, а не под jit-компиляцию. Одно только декодирование x86 команд софтварно, это уже само по себе заморока. Это приводит к огромной ненужной (в случае браузера) сложности виртуальной машины.
Кроме этого, qemu не заточен под то, чтобы гонять инородный код в адресном пространстве процессора-хоста, а это значит что либо его надо перетачивать, либо биться с IPC, который мееееедлеееееннныый.
А кто-нибудь начал конвертор пилить из Vulkan в Web GPU для EMS (или пока все только мечты)?
Эти планы, запланированы они или нет можно вычитывать вот тут: https://www.khronos.org/
> Эти планы, запланированы они или нет можно вычитывать вот тут: https://www.khronos.org/1. WebGPU не является частью Khronos, иди учи матчасть;
2. С транслятором GL ES -> WebGL или же тот же ANGLE как-то без помощи хроносовцев обошлись;
3. А они бы что сделали, написали стандарт на трансляцию команд?
искал либу для xxhash64 под WASM, нашел, автор перешел с Emscripten на шлангя не знаю точной причины, может кто и расскажет нам
потому что, чтобы обернуть стандартную библиотеку, чтобы она абсолютно прозрачно работала в wasm там столько костылей, что что-то небольшое проще голым шлангом собрать с nostdlib подставив свои простенькие костылики где надо.
Жаль что готовых сборок компилятора на github не выкладывают. Предлагают какие-то скрипты запускать для скачивания и инсталяции - это не удобно.