После года разработки состоялся (http://blog.leaningtech.com/2017/02/cheerp-13-up-to-30-faste...) релиз Cheerp 1.3 (http://leaningtech.com/cheerp/) (бывший Duetto), открытого инструментария для разработки клиентских и серверных web-приложений на языке C++, а также для портирования существующих C++ программ для работы в Web-браузере. Код распространяется (https://github.com/leaningtech) под свободной лицензией UI/NCSA (http://llvm.org/releases/2.8/LICENSE.TXT), также используемой в проекте LLVM. Библиотеки поставляются под лицензией GPLv2+.
По своей сути Cheerp напоминает систему Emscripten (https://www.opennet.ru/opennews/art.shtml?num=35313) и также использует наработки LLVM для обеспечения компиляции кода C++ в представление на языке JavaScript. Ключевым отличием Cheerp от Emscripten является (https://github.com/leaningtech/cheerp-meta/wiki) ориентация на достижении более высокой производительности получаемого JavaScript-кода и предоставление средств для использования из С++ программ всех возможностей DOM, браузерного API и HTML5, в том числе WebGL. Cheerp не пытается, как Emscripten, эмулировать традиционное адресное пространство при помощи типизированных массивов, а обеспечивает прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты. Cheerp также поддерживает использование стандартных библиотек libc и libc++, и позволяет применять инструменты сборки cmake/autotool.По поставленным перед проектом задачам Cheerp позиционируется как платформа для создания интегрированных клиент/серверных web-приложений на языке C++. В существующей практике, обычно используется выполняемый в браузере фронтэнд, написанный на языке JavaScript или компилируемый в JavaScript из CoffeScript, Microsoft TypeScript, Google Dart, Google GWT, с раздельной серверной частью на языках PHP, Python, Ruby или JavaScript/node.js. Cheerp предоставляет средства для создания целостных web-приложений на языке C++, в которых бэкенд и фронтэнд поддерживаются в единой кодовой базе. В процессе компиляции серверная часть компилируется в нативный код, а интерфейс преобразуется в JavaScript-представление. Отладка всех компонентов проекта, в том числе преобразуемых в JavaScript, осуществляется по исходным текстам на языке C++ с использованием технологии Source Map (при возникновении ошибки можно увидеть участок кода на C++, поддерживается установка точек останова в коде C++ и построчного пошагового выполнения С++ кода).
В новом выпуске отмечено значительное увеличение производительности кода, скомпилированного с использованием Cheerp. Значительного ускорения удалось добиться не только оптимизацией кода компилятора, но и благодаря совместной работе с разработчиками движка SpiderMonkey, используемого в Firefox. В итоге, по сравнению с прошлым выпуском код проектов на языке C++, скомпилированный в JavaScript при помощи Cheerp 1.3, стал выполняться в Firefox в среднем на 11% быстрее. В ресурсоёмких тестах выигрыш составляет около 25%, в тесте на основе физического движка Bullet - 33%, а в тесте Box2D - 20%.
При сравнении со скоростью выполнения нативного кода, собранное в Cheerp представление на JavaScript работает в среднем в 2.5 раза медленнее приложения, скомпилированного в машинный код. Если сузить выборку до крупных тестов (Bullet, Box2D), то в 3.7 раза.
Результирующий размер сгенерированного в новой версии кода стал в среднем на 25% меньше, чем при использовании Cheerp 1.2, и на 5-40% меньше по сравнению с результатами компиляции в Emscripten.В новой версии также проведена работа по улучшению работы генератора кода, расширению спектра поддерживаемых конструкций C++ и улучшению переносимости с JavaScript. Улучшена работа алгоритма PreExecuter (http://blog.leaningtech.com/2016/02/cheerp-preexecuter-compi...), обеспечивающего упреждающее выполнение порций кода на этапе компиляции. Например, в текущей реализации PreExecuter используется для исключения запуска консрукторов во время выполнения в браузере. Конструкторы, используемые для инициализации глобальных объектов C++, можно вычислить на этапе компиляции и добавить в JavaScript в виде инициализированного среза памяти. В новой версии подобный метод упреждающей инициализации стал доступен и для сложных структур данных.
В области переносимости между C++ и JavaScript/Web API улучшена поддержка тега "[[cheerp::jsexport]]", который теперь может применяться для отдельных функций, а не только для классов, что позволяет отразить в объекты JavaScript любую часть приложения C++. В новой версии также сняты ограничения по определению глобальных переменных в пространстве имён клиента, улучшена поддержка вариативных аргументов и расширена поддержка объединений (union). В компилятор добавлены две новые опции (-cheerp-bounds-check и -cheerp-defined-members-check) для выполнения дополнительных проверок, упрощающих выявление некорректно сгенерированного JavaScript-кода.
URL: http://blog.leaningtech.com/2017/02/cheerp-13-up-to-30-faste...
Новость: http://www.opennet.ru/opennews/art.shtml?num=46011
Не судите строго, но вот у меня вопрос. Язык программирования подбирается под конкретную задачу. Нарисовать график из бигдаты (и блевануть от отвращения) - R. Нужен магазин - похапе (куришь электронные сигареты - тогда Ruby). Но вот такие транспайлеры (ок, инструмент для портирования существующих C++ программ для работы в Web-браузере) - он для чего? Можно пример?
Ну вот мой случай - подробности не могу разгласить, но общая суть такова. Был некий компонент на C, разработанный для мобил. И его заказчику очень захотелось иметь в вебе. Переписать - ресурсов не хватит, оно БОЛЬШОЕ, писалось не один год и далеко не одним человеком. Emscripten выручил.
Есть опыт юзанья эмскриптена.
Вот ни за что не поверю, что большой проект на С удалось таким образом в вебе запустить легче, чем переписать все с нуля. Хоть тресни, но не поверю.
Скажем так - на переписывание ушло бы минимум в сто раз больше времени. Что было бы совершенно неподъёмно.Но недоверие понимаю - самого оторопь иногда ебрёт, что мы это таки смогли учудить. Оно не просто большое - оно монстр, больше 50 мегабайт минифицированного (но не жатого) JS на выходе.
И таки вы хотите убедить нас, что оно работало "в вебе"?
Говорю же - сам диву даюсь. Единственное, что его не пережило - IE11, в edge - и то нормально. Грузится, конечно, пару минут при первом запуске, дальше - побыстрее, а сама работа - максимум втрое медленнее натива. Оверхед по памяти по сравнению с сями тоже на удивление приемлемый - мегабайт 50-70 (оно и в нативе редко меньше ста жрёт).
Напиши интерпретатор питона с нуля.
Благодаря компилятору появился такой проект как pypyjs (http://pypyjs.org)
> Хоть тресни, но не поверю.Тресну. https://epicport.com/en/ttd
netfilter, LVM можно туда запихать?
Куски ядра туда записать? Не, ну если совсем не дружить с головой или развлекаться по полной, как Беллард...Основной вопрос - зачем? Вот зачем туда нужно засунуть монолитное гуёвое приложение, в которое вложена куча ресурсов - я хоть примерно понимаю.
Чтобы переписать всё на JS и запускать ОС в браузере. И ничего с этим трендом не поделаешь - такими категориями мыслит молодое поколение айтишников.
А самое страшное, что вылечить такой тотальный маразм сможет лишь глобальный звиздец бизнеса, построенного на всей этой ВЕБ-хрени. Т.е., когда все эти школо-плебеи от ВЕБ-а, гордо и бессмысленно понтующиеся знакомством с Over100+ ВЕБ-фреймворков, всей сапой дружно и крупно попадут на деньги.То, ради чего на самом деле разрабатывалась Java, было отправлено к чертям в угоду низкого порога вхождения на HTML+JS+CSS. И всё для чего? Чтоб из трактора сделать бомбардировщик? Понаписать этой хрени, провозгласить браузер средой исполнения??? До они просто БОЛЬНЫЕ ПСИХИ!!! Теперь, вот, на C/C++ покушаются. Только этого не хватало...
Я, конечно, всегда знал, что бизнес падок на громкие "технологии", как африканский туземец на бусы, но это уже — откровенный маразм... Вон уже даже Microsoft решили Skype продвигать в виде ВЕБ-приложения без нативной альтернативы... Зафига тогда вообще все эти гигагерцы с террабайтами???
Это не вам лично вопросы. Просто крик души программиста, знающего устройство ПК, пишущего на C/C++ с применением иногда Assembler-а. Человека, который помнит, какие чудеса автоматики делались на Z80.
это уже не тот скайп. там от скайпа остался "вебчатик с войсом и видео" и этому гогвну самое место в браузере, а вот нативную программу писать под него - верх идиотизма.
> это уже не тот скайп. там от скайпа остался "вебчатик с войсом
> и видео" и этому гогвну самое место в браузере, а вот
> нативную программу писать под него - верх идиотизма.К сожалению, лучше пока ничего не придумали. Альтернативодеятели копируют от скайпа не самые лучшие черты.
Например, чего НЕ копируют, а стоило бы:
* Возможность редактировать и удалять сообщения в течении N-го времени после их написания;
* Поддержку тегов для форматирования текста, управления чатом, группами, использования скрытых смайлов;
* Возможность нативной отправки файлов через Torrent-сеть;
* Локальное кэширование сообщений и контактов в БД;
* Трансляция рабочего стола в момент разговора;
* И т.д. и т.п...
За редактирование и удаление надо руки выкручивать.
Я помню под скайп писал программку которая ловит сообщения и логает отдельно, т.к. общался с человеком который любил заниматься удалением и перевиранием.
Должно быть как в реальности - сказал так сказал, обратно не заберешь.
> За редактирование и удаление надо руки выкручивать.
> Я помню под скайп писал программку которая ловит сообщения и логает отдельно,
> т.к. общался с человеком который любил заниматься удалением и перевиранием.
> Должно быть как в реальности - сказал так сказал, обратно не заберешь.Таким образом лишать пользователей возможности исправлять ошибки в тексте? Я бы откручивал руки, а заодно и голову за ОТСУТСТВИЕ возможности редактировать и удалять. Не нужно гробить столь нужный функционал из-за отдельно взятых идиотов. А логи не являются доказательством, кстати. Они легко могут быть поддельными. Можно предоставить функцию просмотра исходного варианта сообщения, в том числе и удалённого.
#include "jquery.h"
А через пяток лет #include <jquery>
Что за ужасы вы пишите! Это могут читать дети!!!
Эта технлогия имеет смысл, если уже есть проект на С++ (изначально написанный не под web) и его хочется запустить в браузере.
А так ждем WebAssembly. Тогда уже можно говорить об использовании этой технологии только для web.
> А так ждем WebAssembly.Че там ждать то? Бери и юзай, уже все готово.
Где оно готово? В Chrome Canary? Или в ночных сборках файрфокса? Готово оно будет, когда окажется хотя бы процентов в 80 пользователей.
Мне почему - то всегда казалось что скомпелировать можно только в машинный код, il, а в друной яп - это называется транслировать
Тоже недоумеваю от заголовка. Я ещё в ВУЗ курсе на 3-4 писал именно транслятор с С на Фортран в качестве курсовой...
Я в свое время (лет 25 назад) писал конвертер из Basic на asm для ZX-Spectrum на его же встроенном Basic`е. Получилось только циклы оптимизировать.
Да, да. И не хакеры, а кракеры. И не пинги, а латентность сети.
Что уж тут поделать, если ошибки так часто повторяются, что все привыкли...
и не скомпелировать, а скомпилировать
> и не скомпелировать, а скомпилироватьЭто ещё что. На албанских форумах я видел вариант "сканпелять". Вот уж что звучало дико. :)
Это они на ксерокс ругались.
А что считать машинными инструкциями? Внутри процессоров Intel команды интерпретируются в нечто risc-подобное
> А что считать машинными инструкциями? Внутри процессоров Intel команды интерпретируются
> в нечто risc-подобноеАрхитектурные команды. Другой апи только у интела
Так это они что ли продвигают MS Office Online? (сарказм)
Я одного не понимаю, а как же гуй? Вот есть десктопная софтина, работает с gtk, qt, whatever. Как оно в браузере заработает?
А где-то есть сравнение бенчмарков с Emscripen?
я не понимаю, зачем. есть же emscripten