Сообщение Re[4]: Emscripten: LLVM to JavaScript compiler (C++ to JS) от 21.06.2015 9:47
Изменено 26.06.2015 19:58 Evgeny.Panasyuk
Здравствуйте, kr510, Вы писали:
K>>>Круто! Только зачем?
EP>>* портирование готовых библиотек и приложений
EP>>* создание веб-приложений в которых и для клиентского и для серверного кода используется C++
K>Техническая сторона понятна, но по прежнему не понятно в чем "business case". На JS масса билиотек и фрейморков для написания UI, зачем еще надо вставлять в него C++.
Чтобы получить доступ к ещё большему колличеству библиотек. Например.
K>Люди пишут на С++, чтобы оптимизировать приложение для платформы.
Не только. Иногда это просто кросс-платформенность.
K>Как раз для того, чтобы сократить время загрузки runtime, убрать микро лаг при обработки событий и уменьшить потребляемую память. Всё это вернётся при конвертации.
Ты думаешь JS->C++ будет хуже чем ручной JS?
EP>>* создание быстрого JS кода — там выходной JS получается со многими C++ оптимизациями
K>В это не верится совсем. Есть код на C++ скомпилированный в машинный код, теперь его конвертируешь в JS и интерпретируешь браузером. Странно очень звучит, что JS-посредником исполнение будет быстрее. Вероятно, это ошибка измерения.
Я не сказал что C++ -> JS работает быстрее native C++.
Я говорю что JS -> C++ (UPD: опечатка, должно быть "C++ -> JS") получается очень быстрым, быстрее чем ручной JS, и даже быстрее чем C#.
EP>>* кросс-платформенные приложения работающие на десктопах, мобильных устройствах и веб
K>Это громкое заявление. На мобильных устройствах использование HTML5+JS чтобы запускать конвертируемый C++ не сработает. Просто HTML5+JS — это тормоза и тупо проигрывает нейтив коду (ObjectiveC, Java). Не шансов что производительность HTML5+JS смогут подтянуть и это еще не считая интерпретатора C++ сверху всего.
Я имел в виду использование C++ как ядра приложения. То есть будет отдельно web-приложение, отдельно приложение для мобильных устройств (не-web), отдельно для десктопа. И везде ядро на C++.
K>>>Круто! Только зачем?
EP>>* портирование готовых библиотек и приложений
EP>>* создание веб-приложений в которых и для клиентского и для серверного кода используется C++
K>Техническая сторона понятна, но по прежнему не понятно в чем "business case". На JS масса билиотек и фрейморков для написания UI, зачем еще надо вставлять в него C++.
Чтобы получить доступ к ещё большему колличеству библиотек. Например.
K>Люди пишут на С++, чтобы оптимизировать приложение для платформы.
Не только. Иногда это просто кросс-платформенность.
K>Как раз для того, чтобы сократить время загрузки runtime, убрать микро лаг при обработки событий и уменьшить потребляемую память. Всё это вернётся при конвертации.
Ты думаешь JS->C++ будет хуже чем ручной JS?
EP>>* создание быстрого JS кода — там выходной JS получается со многими C++ оптимизациями
K>В это не верится совсем. Есть код на C++ скомпилированный в машинный код, теперь его конвертируешь в JS и интерпретируешь браузером. Странно очень звучит, что JS-посредником исполнение будет быстрее. Вероятно, это ошибка измерения.
Я не сказал что C++ -> JS работает быстрее native C++.
Я говорю что JS -> C++ (UPD: опечатка, должно быть "C++ -> JS") получается очень быстрым, быстрее чем ручной JS, и даже быстрее чем C#.
EP>>* кросс-платформенные приложения работающие на десктопах, мобильных устройствах и веб
K>Это громкое заявление. На мобильных устройствах использование HTML5+JS чтобы запускать конвертируемый C++ не сработает. Просто HTML5+JS — это тормоза и тупо проигрывает нейтив коду (ObjectiveC, Java). Не шансов что производительность HTML5+JS смогут подтянуть и это еще не считая интерпретатора C++ сверху всего.
Я имел в виду использование C++ как ядра приложения. То есть будет отдельно web-приложение, отдельно приложение для мобильных устройств (не-web), отдельно для десктопа. И везде ядро на C++.
Re[4]: Emscripten: LLVM to JavaScript compiler (C++ to JS)
Здравствуйте, kr510, Вы писали:
K>>>Круто! Только зачем?
EP>>* портирование готовых библиотек и приложений
EP>>* создание веб-приложений в которых и для клиентского и для серверного кода используется C++
K>Техническая сторона понятна, но по прежнему не понятно в чем "business case". На JS масса билиотек и фрейморков для написания UI, зачем еще надо вставлять в него C++.
Чтобы получить доступ к ещё большему колличеству библиотек. Например.
K>Люди пишут на С++, чтобы оптимизировать приложение для платформы.
Не только. Иногда это просто кросс-платформенность.
K>Как раз для того, чтобы сократить время загрузки runtime, убрать микро лаг при обработки событий и уменьшить потребляемую память. Всё это вернётся при конвертации.
Ты думаешь JS->C++ (UPD: опечатка, должно быть "C++ -> JS") будет хуже чем ручной JS?
EP>>* создание быстрого JS кода — там выходной JS получается со многими C++ оптимизациями
K>В это не верится совсем. Есть код на C++ скомпилированный в машинный код, теперь его конвертируешь в JS и интерпретируешь браузером. Странно очень звучит, что JS-посредником исполнение будет быстрее. Вероятно, это ошибка измерения.
Я не сказал что C++ -> JS работает быстрее native C++.
Я говорю что JS -> C++ (UPD: опечатка, должно быть "C++ -> JS") получается очень быстрым, быстрее чем ручной JS, и даже быстрее чем C#.
EP>>* кросс-платформенные приложения работающие на десктопах, мобильных устройствах и веб
K>Это громкое заявление. На мобильных устройствах использование HTML5+JS чтобы запускать конвертируемый C++ не сработает. Просто HTML5+JS — это тормоза и тупо проигрывает нейтив коду (ObjectiveC, Java). Не шансов что производительность HTML5+JS смогут подтянуть и это еще не считая интерпретатора C++ сверху всего.
Я имел в виду использование C++ как ядра приложения. То есть будет отдельно web-приложение, отдельно приложение для мобильных устройств (не-web), отдельно для десктопа. И везде ядро на C++.
K>>>Круто! Только зачем?
EP>>* портирование готовых библиотек и приложений
EP>>* создание веб-приложений в которых и для клиентского и для серверного кода используется C++
K>Техническая сторона понятна, но по прежнему не понятно в чем "business case". На JS масса билиотек и фрейморков для написания UI, зачем еще надо вставлять в него C++.
Чтобы получить доступ к ещё большему колличеству библиотек. Например.
K>Люди пишут на С++, чтобы оптимизировать приложение для платформы.
Не только. Иногда это просто кросс-платформенность.
K>Как раз для того, чтобы сократить время загрузки runtime, убрать микро лаг при обработки событий и уменьшить потребляемую память. Всё это вернётся при конвертации.
Ты думаешь JS->C++ (UPD: опечатка, должно быть "C++ -> JS") будет хуже чем ручной JS?
EP>>* создание быстрого JS кода — там выходной JS получается со многими C++ оптимизациями
K>В это не верится совсем. Есть код на C++ скомпилированный в машинный код, теперь его конвертируешь в JS и интерпретируешь браузером. Странно очень звучит, что JS-посредником исполнение будет быстрее. Вероятно, это ошибка измерения.
Я не сказал что C++ -> JS работает быстрее native C++.
Я говорю что JS -> C++ (UPD: опечатка, должно быть "C++ -> JS") получается очень быстрым, быстрее чем ручной JS, и даже быстрее чем C#.
EP>>* кросс-платформенные приложения работающие на десктопах, мобильных устройствах и веб
K>Это громкое заявление. На мобильных устройствах использование HTML5+JS чтобы запускать конвертируемый C++ не сработает. Просто HTML5+JS — это тормоза и тупо проигрывает нейтив коду (ObjectiveC, Java). Не шансов что производительность HTML5+JS смогут подтянуть и это еще не считая интерпретатора C++ сверху всего.
Я имел в виду использование C++ как ядра приложения. То есть будет отдельно web-приложение, отдельно приложение для мобильных устройств (не-web), отдельно для десктопа. И везде ядро на C++.