Представлен компилятор Cheerp 3.0, позволяющий скомпилировать любой код C/C++ в WebAssembly или JavaScript. Новая ветка примечательна переводом компилятора и сопутствующих библиотек на использование пермиссивных лицензий Apache 2.0 и LLVM, вместо ранее применяемой ограниченной лицензионной политики, предлагающей вариант с лицензией GPLv2 для некоммерческих проектов и проприетарную лицензию для коммерческих. Код компилятора основан на наработках LLVM и Clang, и включает дополнительные оптимизации для повышения производительности и уменьшения размера скомпилированного результата...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58807
это скорей интерпритатор, чем компилятор.
Это скорее компилятор, чем интерпритатор (орфография автора сохранена).
Это скорее компилятор интерпретатора, чем интерпретатор.
Это медленнее
Интертрепатор.
А есть транслятор из ассемблера в пайтон?
Конечно есть сначала ассемблерный код через Ida Pro перегоняешь в Си код. Потом через c2py перегоняешь в питон. Можно даже онлайн https://www.javainuse.com/c2py
далее через CPython собираешь бинарник и цикл можно повторять, до тех пор пока не сойдётся
Не факт, что сойдётся. В лучшем случае потребуется доопределение для сходимости, а в худшем - будет расходиться. Может быть, даже экспоненциально.
Есть. Эффективность поченного кода другой вопрос. Но есть.
> Есть. Эффективность поченного кода другой вопрос. Но есть.Можно будет получить выразительность ассемблера и скорость питона. Суперкомбо :)
Осторожне с такими шутками. А то я чуть не подавися, и кофе пролил.
Emscripten это не только компилятор в wasm, но и эмуляция окружения (сокеты через websocket, printf в консоль браузера) и набор портированных библиотек (pthread, sdl2, openal и т.д.).Как дела с этим у Cheerp? Выполнение абстрактного кода в вакууме не интересует.
> сокеты через websocket, printf в консоль браузераПредставляю, какой там оверхед при пересечении границы между WASM и DOM. Запомните, дети: если нужно общаться с внешним миром, манипулировать элементами на странице, посылать туда-сюда запросы, ну и вообще -- если хочется интерактив, то яваскрипт в разы (в разЫ, Ы в конце) быстрее, чем WASM. Единственный сценарий, где WASM быстрее JS -- это числодробилка, которая ровно один раз получила число на вход, погоняла над ним алгоритм в течение часа и ровно один раз отдала результат обратно яваскрипту.
Ну, вообще есть радикальная альтернатива этому подходу - не использовать DOM дерево, а вместо него - QML
реинкарнация апплетов
> Представляю, какой там оверхед при пересечении границы между WASM и DOM.200нс из доки emscripten, т.е. можно забить. Жиснявая вебня куда дольше ворочаться будет.
> яваскрипт в разы (в разЫ, Ы в конце) быстрее, чем WASMРади интереса запускал какой-то свой helloworld на Qt в emscripten. Там была табличка QTableView с раскраской (пара сотен строк и пара десятков столбцов). Таких шустрых сайтов на JS я никогда не видел! Т.е. wasm, рисующий на канве через прослойку emscripten, работает быстрее "классического" HTML + JS.
Да, там были небольшие глюки с перерисовкой (мерцающий чёрный фон при ресайзе виджета), но в целом очень шустренко работало в firefox.
Тут возможно фишка в том, что нужно обеспечить вывод уже отрисованной картинки (которая полностью сформирована внутри wasm без всяких сборщиков мусора, но правда с эмуляцией чего-то похожего на MMU внутри браузера) и всё что требуется от emscripten - энцать раз в секунду обновить картинку на канве.
Не подсказывай ему, пиши свой стартап.
Канва работает быстрее DOM? No shit, Sherlock! Правда решение "WASM + канва" нужно сравнивать с аналогичным "JS + канва", но ты настолько глубоко копать не стал. Давай я тебе немного напомню про то, что даже чтобы отправить строку из WASM в JS, нужно эту строку: 1) упаковать в UTF на стороне WASM, 2) посигналить яваскрипту, что ему нужно бы забрать строку вот отсюда, 3) распаковать из UTF на стороне JS при помощи TextDecoder. Отправка из JS в WASM делается аналогично. Это дорогостоящая операция в сравнении с JS-only-решением, где никакой boundary crossing не требуется. Примерно по этой же причине биндинги сишной libxml к node.js работают гораздо медленнее, чем xml-парсеры, написанные целиком на JS.Я еще молчу про то, что канва сама по себе имеет кучу проблем, например отсутствие нативного контекстного меню для инпутов и невозможность обеспечить accessibility.
> нужно сравнивать с аналогичным "JS + канва"Предъяви, сравним.
> чтобы отправить строку из WASM в JS, нужно эту строку:
Нет не нужно, на стороне c++ принимаешь строку как std::wstring и дальше с ним и работаешь.
> wasm, рисующий на канве через прослойку emscripten, работает быстрее "классического" HTML + JS.
> Предъяви, сравним.Так ты и предъявляй. Так-то я тебе тоже могу показать, как JS-гриды на канве работают существенно быстрее JS-гридов на DOM. И никакой васм для этого не понадобился.
> Нет не нужно, на стороне c++ принимаешь строку как std::wstring
А откуда этот твой std::wstring возьмется без копирования данных из JS-строки в память WASM?
> Так ты и предъявляйИзи. Я сравнивал ffmpeg.wasm и ffmpeg.js и разрыв в скорости перекодирования одного и того же файла просто чудовищный, wasm в разы быстрее.
> откуда этот твой std::wstring возьмется без копирования
Куча у wasm общая с js, копировать не обязательно. Typed arrays те точно не копируется, с чего бы стрингам вести себя иначе, ведь в js это то же самое, что массив.
> разрыв в скорости перекодирования одного и того же файла просто чудовищный, wasm в разы быстрееПравильно, ибо это и есть тот самый единственный сценарий, где васм быстрее. Потому что не приходится перегонять данные отсюда-туда сотни и тысячи раз, как это было бы в интерактивном приложении.
> Typed arrays те точно не копируется
Ну так проведи эксперимент: 1) сформируй в васме мутабельную строку, 2) прими ее на стороне JS и сохрани в переменную, 3) в васме измени первый символ уже отправленной строки, 4) убедись, что на стороне JS строка не изменилась, ergo память была скопирована. Те, кто в курсе, что строки в JS - это примитивы, всегда передающиеся по значению, знают это и без экспериментов. DOM ничего кроме строк не принимает, нету там никакого element.setAttributeFromSomeShittySharedArrayBuffer(ptrAttrName, ptrValue).
Пока так, возможно потом оптимизируют и дадут прямой доступ к dom, на второе планы точно есть. Браузеры очень медленно развиваются к сожалению, взять хотя бы поддержку современных форматов изображений - браузероделы годами их внедряли и то недовнедрили.
> Потому что не приходится перегонять данные отсюда-туда сотни и тысячи раз, как это было бы в интерактивном приложении.Это в каких таких _интерактивных_ приложениях тысячи раз в секунду что-то гоняется? Человеки (интерактивное же!) не будут успевать кнопки жмакать и вообще осознавать что на экране творится, что там мельтешит. Нас за такое ругали. Очень грубый пример стародревних костылей, наверное уже неактуальных и не модных: когда бежишь в гриде (да-да, плохой, неправильный, дизайн) по строчкам мастер-списка, ты на каждый переход со строки на строку НЕ тянешь данные с сервера для кучки детэйл-гридов пока не остановишься на какой-то конкретной строке (по маленькому таймауту начинается подгрузка). А то бухгалтер для прокрутки задумчиво утопил стрелку вниз в гриде, а сервер усирается от лавины запросов на каждый переход от строки к строке, за каждым из которых на самом низу кучка селектов к базе. Или другой пример - когда в визуальный контрол подгружается относительно увесистая пачка данных, то, чтобы не перегружать его отрисовкой по мере загрузки этих данных (там ведь куча событий стреляет) контрол дизейблится или отключается от перерисовки (уж и не вспомню точно как там лет 15 назад было) на время загрузки и перерисовывается в финале за один прием.
>распаковать из UTF на стороне JS при помощи TextDecoderЧего, JS не может напрямую работать с UTF-8?
V8 хранит строки в формате WTF-16. Если хочется принять буфер, в которой лежит UTF-8, то нужно перекодировать (TextDecoder). Напрямую с буфером будешь работать именно как с массивом байт, но если тебе эту строку нужно показать пользователю, то придется перегнать в WTF-16.
В JavaScript единственная кодировка utf-16
> Представляю, какой там оверхед при пересечении границы между WASM и DOM.Поэтому рисовать куданить в канвас и IO через вебсокеты всякие. Чтобы с вебтормозилками минимально пересекаться.
Интересная ситуация получается.
GPL используют те, кто хотят рубить бабло, типа Qt, а вот некоторые переводят код на понастоящему свободные лицензии.
Так делают когда проект закрывается. Ну будем честны проект и раньше был мало кому нужен так как есть альтернативы.
> Ну будем честны проект и раньше был мало кому нужен так как есть альтернативыбудем честны - просто это псевдо IT для смузихлёбов, на острие прогресса совсем другое направление
Это для разного. То, что в теме - это про Web, А HLS - это для FPGA.
Сейчас как раз раздумываю над выбором инструмента для написания новой кросс платформенной игрушки. И если выбор платформ традиционный Desktop - Web(HTML5) - Android, то там где-то должен быть С++. Но я скорее склоняюсь к написанию игры на Haxe (этот язык ближе к ActionScript/TypeScript), кото рый умеет компилировать как в C++ , так и в JavaScript. И у которого уже есть графические фреймворки (OpenFL) и фреймворки для создания UI (HaxeUI), есть и разные bindings типа Raylib для Haxe. Кроме того у Haxe есть сборщик мусора и не надо напрямую работать с памятью, что облегчит создание прототипа и обеспечит быструю итерацию.
> Кроме того у Haxe есть сборщик мусора и не надо напрямую работать с памятью, что позволитПозволит фигурно по...ться в профайлере с малоустранимыми лагами этого самого GC, что в игроделе самая мякотка. И пока у плюсера все будет просто работать, вон тот будет пыхтеть в профайлере доказывая всем что не так уж оно и дергается, и вообще :)
Используй Kotlin MPP + rsocket, если нужен онлайн.
Конференций на тему использования KMPP куча, половина есть на ютюбе и даже на русском.
Скомпилить код сможешь даже нативно на тостер, не говоря о простой компиляции в js.
Даже игровой движок под это есть.
>Даже игровой движок под это есть.Какой?
Б-гмеркзая проприетарь.
> Скомпилить код сможешь даже нативно на тостерИ давно на тостерах 2 ядра 2 гига игровая видеокарта?
Шмотлин в wasm пытался, но не шмог, и компилится в обычный медленный js.
Сайты и веб-приложения на C++ — это именно то, чего нашим коллегам так не хватало. Зато теперь на любые претензии в духе "а у вас электрон" можно будет с умным лицом возразить: "Заткнись! У нас C++, поэтому мы умнее, и у нас всё эффективно."
Пиши на Rust, кто не мешает?
На: https://www.webtoolkit.eu/
Какое бы не было качество кода. Код на C++ будет быстрее и надо для производительности на нагруженных сайтах. Как на той же самой Фигме.
вообще для трансляции в js есть nim, который уделывает по всем параметрам раст и по некоторым плюсы
Вообще то хорошие развивающиеся проекты на лицензию апач никто не переводит.
ох уж эти любители поспорить о лицензиях вместо того, чтобы проги писать
Бесплатно ублажать корпов - такое себе счастье. Тут им патентных прав, там прав сорц зажимать, а они взамен дырок от бублика насыпят. И все как бы честно. А, еще вы можете к ним рабом на галеру прийти, только хотя код пишете вы, командовать будут они и все как бы честно. Или таки нет?
Цеых 2 корпа не одобряют отсутствие халявы.
> есть nimЭто ненужное еще шевелится?
Вообще есть много чего, что можно транслировать с js, тут фишка что можно транслировать именно с/с++ из-за накопленной огромной кодовой базы.
> именно с/с++ из-за накопленной огромной кодовой базы.Это-то и пугает: в вебе уже достаточно своего мусора на не менее уродливых, но более простых ЯП, а если добавится ещё приплюснутый, то может случиться переполнение кучи. Впрочем, меня сейчас, как обычно, заминусют, потому что местные приплюснутые свято верят в то, что уж они-то говно не пишут, потому что раз для знания всего С++ нужен гигантский ум, то если пишешь на С++, автоматически являешься интеллектуальным гигантом, даже если твой IQ всего на 10 баллов выше, чем у "вебмакак". Тут же каждый второй — сын Страуструпа и Кнута.
С одной стороны - да.
А с другой стороны - за счет старости кодовой базы и ее повсеместного использования в либах могли поисправлять самые злобные баги и их может быть меньше на момент релиза, чем при написании с нуля на напр. JS. Тут уже нужно рассматривать конкретные ситуации и оценивать риски.
По некоторым действительно уделывает. Но уж точно не по всем. Nim - язык с GB и не такой хорошей поддержкой конкурентности, как у Rust. Также программистов на Nim, пишут, гораздо меньше, чем программистов на Rust.
> Также при компиляции используется PartialExecuter, который на основе анализа параметров функций удаляет код, который гарантированно не используется при выполнении.ААААА... Где мой код?!!!!
Волобуев, вот ваш... код!
Сейчас бы в 2023 смешивать js и плюсы.
Лёгкий способ превратить жизнь того, кто этот код будет поддерживать в ад.
Твоему сайте визите C++ не нужен.
Минус на минус даёт плюс, а минусминус на минусминус — плюсплюс.
Ничё нипонил!
Перводить С++ - в ДжаваСкрипт?!
Что народ курит?
А во что переводить, если нужно приложение для браузера? В ActiveX?
я чистый плюсовик, я не знаю эти ваши жээсы и хтмл. Мне проще функционал описать внутри консольного экзешника и сделать обращение к порту программы.
Как мне прикрутить веб-морду чтобы пользователь тык-тык и доволен?
Куда копать? Есть примеры?
libmicrohttpd