Сообщество

Честно говоря не люблю ни Яву ни подобные технологии (и всего несколько лет назад узнал что ява и ява-скрипт абсолютно разные вещи, соотвественно JSON сериализация объектов тут не при чём), поэтому в них не разбираюсь. Но вот, до появления смартфонов, основным показателем, того что вы купили не кирпич, было наличие явы и как следствие - ява игр. Видимо одними играми технология не ограничивается и есть ещё куча применений: ну давайте, рассказывайте, кто что знает :-)

Вот буквально пару часов назад с коллегой на эту тему общался. Совершенно случайно (синхронно мысли сошлись, невиноватыйя :-) )

krufter_multiclet wrote:

Портирование виртуальной машины JAVA для Мультиклета. Кто, что думает об этом, есть ли смысл это реализовать?

Вопрос - А ЗАЧЕМ?
Второй вопрос - какую жаву вам надо, ту, что в телефонах, или настольную?
Третий вопрос: а на какой операционной системе и на каком устройстве?
Все три вопроса имеют значение, что бы понять "стОит-нет" ;-)
Третий вопрос помогает ответить на вспомогательные вопросы "кто и как будет этим заниматься"

Да, написанием Джава-машины обычно занимается производитель устройства, на котором работает машина, то есть, если устройство - телефон, то машину пишет производитель телефона, ну как-то так принято, что ли, а владелец Джавы (ранее - Sun Microsystems, сегодня - Oracle) проводит сертификацию виртуальной машины на соответствие спецификации (если я ничего не путаю, а я могу :-) )

Это если делать все формально, правильно, по-взрослому, с наклейками "сертифицировано", "работает как надо" и тд и тп

Ну или бывает так, что производитель оутсорсит написание виртуальной машины в третьи-четвертые-пятые руки, а сам джава-код пишут уж совсем левые люди :-) Так тоже бывает

Лично мое мнение - не повредит. 
Как? Берем openjdk и допиливаем компилятор и операционную систему пока оно не начнет работать. Все. ;-)

VaalKIA wrote:

Честно говоря не люблю ни Яву ни подобные технологии (и всего несколько лет назад узнал что ява и ява-скрипт абсолютно разные вещи, соотвественно JSON сериализация объектов тут не при чём), поэтому в них не разбираюсь. Но вот, до появления смартфонов, основным показателем, того что вы купили не кирпич, было наличие явы и как следствие - ява игр. Видимо одними играми технология не ограничивается и есть ещё куча применений: ну давайте, рассказывайте, кто что знает :-)

С появлением андроидов и яФонов без явно существующей Джавы мобильная жаба ушла и целая ниша освободилась. Теперь эту нишу начнут занимать (есть мнение) телефоны с настольными и браузерными операционными системами, в которых, скорее всего, Джава будет присутствовать в явном виде и, скорее всего, это будет не JaveME, а настольный/энтерпрайз-вариант - JavaSE. Это я фантазирую сейчас, у меня информации нет четкой.
Поэтому, к примеру, в том же криптотелефоне на мультиклете джава нужна (если это не Android-смартфон) и начинать стоит с написания джава-машины ;-)

Aha wrote:

VaalKIA wrote:

Честно говоря не люблю ни Яву ни подобные технологии (и всего несколько лет назад узнал что ява и ява-скрипт абсолютно разные вещи, соотвественно JSON сериализация объектов тут не при чём), поэтому в них не разбираюсь. Но вот, до появления смартфонов, основным показателем, того что вы купили не кирпич, было наличие явы и как следствие - ява игр. Видимо одними играми технология не ограничивается и есть ещё куча применений: ну давайте, рассказывайте, кто что знает :-)

С появлением андроидов и яФонов без явно существующей Джавы мобильная жаба ушла и целая ниша освободилась. Теперь эту нишу начнут занимать (есть мнение) телефоны с настольными и браузерными операционными системами, в которых, скорее всего, Джава будет присутствовать в явном виде и, скорее всего, это будет не JaveME, а настольный/энтерпрайз-вариант - JavaSE. Это я фантазирую сейчас, у меня информации нет четкой.
Поэтому, к примеру, в том же криптотелефоне на мультиклете джава нужна (если это не Android-смартфон) и начинать стоит с написания джава-машины ;-)

Относительно использования в нашем криптотелефоне и не только, думаем на эту тему. Даже при наличии текущего компилятора Си89 мы можем один раз ручками развернуть и подчистить код на ассемблере, а некоторые критичные части написать на ассемблере. На самом деле открытых разновидностей java машины хватает, вопрос только в том, какую реализацию выбрать.

Относительно использования в нашем криптотелефоне и не только, думаем на эту тему. Даже при наличии текущего компилятора Си89 мы можем один раз ручками развернуть и подчистить код на ассемблере, а некоторые критичные части написать на ассемблере. На самом деле открытых разновидностей java машины хватает, вопрос только в том, какую реализацию выбрать.

Не уверен, что достаточно будет какой-то одной:

Java - это объектно-ориентированный язык программирования (первоначальное название языка OAK), использующийся для разработки приложений под java-платформы, которых существует несколько семейств: JavaEE, JavaSE, JavaME, JavaFX и JavaCard. Каждая из платформ направлена на решение определённых задач(JavaSE - создание пользовательских приложений, JavaEE - приложения уровня предприятия, JavaFX - создание GUI, JavaME - создание приложений для устройств с ограниченной мощностью и, наконец, JavaCard - безопасная среда для приложений на смарт-картах).

Разьве что в Андродие своя JAVA и вроде как именно из-за этого Гугл судится с Оракл?

Виртуальная машина Dalvik

Так как аппаратные возможности гаджетов особенно вначале распространения мобильных устройств по сравнению с настольными компьютерами более ограничены, то это потребовало от компании Google по сути пересоздать вирутальную машину Java (JVM) в виде виртуальной машины Dalvik. Dalvik VM принимает сгененрированные файлы классов Java и объединяет их в один или несколько испольняемых файлов Dalvik Executable (.dex). Основное педназначение вирутальной машины Dalvik - оптимизировать выполнение кода Java применительно к свободному пространству и заряду батареи. Поэтому в отличие от десткопных компьютеров финальные исполняемые файлы для операционной системы Android будут состоять не из стандартного байт-кода для JVM, а специальные файлы с расширением .dex

В итоге при нажатии пользователем на иконку приложения Dalvik генерирует машинный код из байт-кода приложения, то есть происходит JIT-компиляция. Затем Android создает процесс, который выделяет память и получает ресурсы CPU, необходимые для работы программы.

Но уже в версии Android 5.0 Lollipop виртуальная машина Android RunTime полностью заменила Dalvik.

Работа Android RunTime коренным образом отличается от Dalvik: Android RunTime использует предварительную компиляцию приложения при его установке на мобильное устройство, а не JIT-компиляцию, что увеличивает производительность приложения.

Не понял я, где отличия, если всё совместимо, то давайте ту яву, на которйо андроид.
P.S.
Вот что пишут:

Выбрав Java, нужно было решить, какую виртуальную машину (JVM) использовать. Ввиду ограниченности ресурсов использование стандартной JVM было затруднено. Единственным возможным выбором было использование Java ME JVM, разработанной для мобильных устройств. Однако счастье Google было бы неполным без разработки собственной виртуальной машины, и появилась Dalvik VM.

Dalvik VM отличается от других виртуальных Java-машин следующим:
Она использует специальный формат DEX для хранения двоичных кодов, в противовес форматам JAR и Pack200, которые являются стандартом для других виртуальных Java-машинах. Компания Google заявила, что бинарники DEX меньше, чем JAR. Я думаю, с тем же успехом они могли бы использовать Pack200, но они решили пойти своим путём.
Dalvik VM оптимизирована для выполнения нескольких процессов одновременно.
Dalvik VM использует архитектуру, основанную на регистрах против стековой архитектуры в других JVM, что приводит к увеличению скорости выполнения и уменьшению размеров бинарников.
Она использует собственный набор инструкций (а не стандартный байткод JVM)
Возможен запуск (если необходимо) нескольких независимых Android-приложений в одном процессе
Выполнение приложения может охватывать несколько процессов Dalvik VM «естественным образом» (позже мы обсудим, что это значит). Для поддержи этого добавлено:
Специальный механизм сериализации объектов, основанный на классах Parcel и Parcelable. Функционально преследуются те же цели, что и Java Serializable, но в результате данные имеют меньший объём и потенциально более терпимы к версионным изменениям классов.
Особый способ для выполнения вызовов между процессами (inter process calls, IPC), основный на Android Interface Definition Language (AIDL).
До Android 2.2 Dalvik VM не поддерживала JIT-компиляцию, что было серьёзным ударом по производительности. Начиная с версии 2.2, скорость выполнения часто используемых приложений заметно возросла.

Ребята из Google также пересмотрели стандартные пакеты Java JDK API. Они удалили некоторые из них (например всё, что касалось Swing) и добавили некоторое количество собственных — их имя начинается с «android».

Также они добавили несколько пакетов с открытым кодом, не являющихся частью стандартного JDK: Bouncy Castle crypto API, HTTPClient с поддержкой разделения HTTP/HTTPS на стороне клиента.

Также Google добавила веб-браузер в уровень инфраструктуры приложения. Это не полноценный Google Chrome для мобильных устройств, но очень близок к нему, поскольку основан на том же движке WebKit и использует движок JavaScript V8 из Chrome. В конце концов, это крайне современный и высокотехнологичный браузер. Он может быть интегрирован в любые Android-приложения.

Да, в Дроиде - своя виртуальная машина, но это не Джава-машина. В bash-е, кстати, тоже есть признаки виртуальной машины ;-) и она тоже не похожа на Джава-машину.

Много где используются виртуальные машины, но Джава-виртуальная машина - это только та, которая прошла сертификацию на соответствие спецификации языка. Поэтому как я и говорил - сначала пишется машина, потом проходится сертификация у Оракла. Там я еще добавлял - это если хочется "по-взрослому", чтобы была наклейка "настоящая Джава"

По поводу разнообразия различных Джав, то зуб не дам - я немного из другой "песочницы", я нативный компиляторщик, но насколько мне известно в данный момент тендении меняются. Рекомендую почитать Readme свежайших релизов джавы, официальные прессрелизы, там должно быть некоторое количество новой информации на эту тему...

VaalKIA wrote:

Не понял я, где отличия, если всё совместимо, то давайте ту яву, на которйо андроид.

Сначала надо ответить на самый главный вопрос:

krufter_multiclet wrote:

Портирование виртуальной машины JAVA для Мультиклета. Кто, что думает об этом, есть ли смысл это реализовать?

Вопрос - А ЗАЧЕМ?

Если ЗАЧЕМ - исполнять любый абстрактные платформо-независмые jar-файлы, то тогда передирать "в ноль" Dalvik и ART бессмысленно и опасно:
1. Они все же могут оказаться несовместимы общей Джавой
2. Они оптимизированы под RISC, под ARM

Ну а если ЗАЧЕМ - это привнесение опыта Джавы, виртуальных машин в мультиклеточное пространство без оглядки на существующий код, создание своего языка MultiсJava, поддержка своего байткода, то тогда можно и на опыт парней из гугля посмотреть, хотя опять-таки зачем:
1. Они оптимизированы под RISC, под ARM
?

PS. <offtop>
только заметил. исключительно ради улыбки :-)
у вас favicon форумная - http://multiclet.com/community/favicon.ico - она как бы что призвана символизировать?
У меня-таки ассоциируется с верхней челюстью, как ее стоматологи схематично рисуют :-D
Just for fun
Ничего дурного
</offtop>

VaalKIA wrote:

В итоге при нажатии пользователем на иконку приложения Dalvik генерирует машинный код из байт-кода приложения, то есть происходит JIT-компиляция. Затем Android создает процесс, который выделяет память и получает ресурсы CPU, необходимые для работы программы.

Но уже в версии Android 5.0 Lollipop виртуальная машина Android RunTime полностью заменила Dalvik.

Работа Android RunTime коренным образом отличается от Dalvik: Android RunTime использует предварительную компиляцию приложения при его установке на мобильное устройство, а не JIT-компиляцию, что увеличивает производительность приложения.

Не понял я, где отличия, если всё совместимо, то давайте ту яву, на которйо андроид.

JIT-компиляция -- это быстрая компиляция, которая происходит в момент выполнения приложения. Из-за того, что она быстрая -- она не качественная и плохо оптимизирует, потому что нет времени на оптимизацию. А из-за того, что она работает в момент запуска приложения, то в памяти хранится, как байткод, так и сгенерированный машинный код, что приводит к повышенному потреблению памяти и также вычислительных ресурсов на компиляцию в момент каждого запуска приложения.

Новый Android RunTime, как вы уже написали, использует предварительную компиляцию. Предварительная компиляция отличается от JIT тем, что происходит в момент установки или первого запуска приложения и может задействовать оптимизацию под устройство по-максимуму, в результате появляется нативный файл. После его запуска в памяти занимает место только он, а байткод не загружается, даже байткод уже не нужен и его можно удалить с устройства(может он и удаляется после компиляции, я не знаю). Такой подход теоретически может дать выигрышь лучше, чем у заранее скомпилированных С/С++ программ, т.к. качество компиляции зависит только от компилятора, который можно сделать не хуже, чем компиляторы С/С++, но при этом в момент предварительной компиляции под конкретное устройство, компилятор может задействовать все архитектурные преимущества устройства, что и повысит качество компилируемого кода. Для сравнения большинство программ на С/С++ компилируются под определённые архитектуры, например под i386 и i686 и в таком виде распространяются, т.е. получившийся код не задействует всех архитектурных преимуществ современных процессоров.
Так же данный метод эффективней, чем распространять программы в исходниках на С/С++ и компилировать их под устройство. Эффективней потому, что программа перед распространением компилируется в промежуточный байткод и в момент этой компиляции применяется архитектурно-независимая оптимизация, в результате получается оптимизированный байткод. В момент установки же на устройство, этот байткод компилируется в машинный код устройства и применяется уже только архитектурно-зависимая оптимизация, в результате компиляция на устройстве будет проходить намного быстрее, чем если там же компилировать программу из исходников на С/С++.

krufter_multiclet wrote:

Портирование виртуальной машины JAVA для Мультиклета. Кто, что думает об этом, есть ли смысл это реализовать?

Я думаю, что не стоит этим заниматься и лучше потратить силы и время на разборку архитектуры LLVM и попытаться её портировать на вашу архитектуру.

На базе LLVM вы потом сможете реализовать поддержку, как Ява платформы, так и .NET.

Насколько мне известно, в Androoid 5 предварительная компиляция Android RunTime реализована на базе LLVM, т.е. реализовав LLVM вам будет легче портировать Android в будущем.
Так же на базе LLVM создана технология .NET в реализации Mono, а точнее там у них есть обычная реализация и реализация, через LLVM, можно выбирать, какая будет использоваться при компиляции, но в будущем они вроде планировали использовать только LLVM, т.к. с развитием LLVM, нет смысла тратить силы на развития своего компилятора.

Так же под LLVM есть куча языков программирования, которые вам не придётся все реализовывать, но вы получите их поддержку, благодаря поддержке LLVM. Тоже самое произойдёт и с компилятором С/С++ -- реализовав поддержку LLVM, вы автоматически получите компилятор С/С++, поддерживающий самый последний стандарт. И так же ресурсы ваших разработчиков будут уже направлены не на портирование стандартов языков С/С++ под вашу архитектуру, а на улучшение оптимизатора.

И не все разработчики хотят программировать на С/С++. LLVM предоставит им выбор и сделает вашу платформу более привлекательной.

Конечно я помню, о трудностях, которые у вас возникли при портировании LLVM, мы это уже обсуждали в другой ветке. Но так же из других ваших комментариев в других местах, понял, что с технологией LLVM вы не до конца разобрались и возможно её можно приспособить к вашей архитектуре, обратного вы не утверждали.

Просто тут я решил ещё раз упомянуть об этом, т.к. считаю, что LLVM полезней, чем Ява. Если же вам делать Яву, то надо делать компилятор, а не виртуальную машину, а то на вашем медленном процессоре, виртуальная машина будет тормозить и потреблять много памяти, которой у вас мало. А если делать компилятор, то лучше делать его на базе LLVM, а не разрабатывать ещё один новый компилятор с нуля. При этом надо учесть, что это будет компилятор не языка Ява, а её байткода, т.к. программы распространяются в нём. Но не уж-то компилятор байткода Явы сделать легче, чем компилятор байткода LLVM ? Я в этом сомневаюсь.
И если в Android 5 Google реализовал предварительную компиляцию на базе LLVM, то, возможно, у него уже реализован компилятор из байткода Явы в байткод LLVM, а так как Андроид открытый, то этот код можно позаимствовать, а не писать самостоятельно. Точно так же реализация Mono полностью открыта. В результате приходим к выводу, что нужна поддержка LLVM и тогда станет проще.

Ещё подумал о такой вещи -- если вы будете интерпретировать байт-код, то останутся ли преимущества от вашей мультиклеточности ? Скорее всего нет или они будут слабо задействованы, поэтому только скомпилированный машинный код, подогнанный оптимизатором под вашу архитектуру, сможет реализовать полный потенциал вашего процессора.

Как много всего намешано :-)

Я не мультиклет- разработчик. Я так... Сочувствующий...
Начнем с того, что в первом сообщении Yaisis предлагется вместо Just In Time компиляции посмотреть на Ahead Of Time сомпиляцию. Я не знаю уж как гугель договорился с той компанией, но есть организация, которая держит патент на AOT- компидяцию и глядя на тенденции на рынке, эту золотую антилопу она никому не отдаст и из рук не выпустит. В общем за АОТ платить надо будет, если я ничего не путаю.

Далее утверждается, что "большинство программ скомпилировано для старых х86-платворм и не используют преимуществ новых". Мда... В данный момент у мультиклета 1-2-3-4 устройства, для всех можно сделать универсальный бинарник при компиляции с С/С++, подозреваю... (Если нельзя, то через полгода точно можно будет ;-) ). Конечно, если через 10 лет Мультиклет разведет такой же зоопарк устройств, как и интел и уже этот зоопарк станет проблемой, тогда да, но это утверждение похоже на попутку бежать впереди паравоза (напоминаю, я не имею отношения к Мультиклету, я сочувствующий)

Дальнейшее рассуждение про применение только архитектурно-зависимых оптимизаций уже кажется лишним, если му всегда можем изначально получать максимально оптимизированным под любую архитектуру бинарник

В следующем сообщении товарища Yaisis используется очень много слов и выражений, основная мысль которых - "позаимствовать".

Вопрос: прежде чем присать подобные сентенции и выполнять данные действия господа программисты читаю лицензионные соглашения? Если да, то очень хорошо. Чаще всего в них написано "разрешено для некоммерческого использования", а поскольку Мультиклет - компания коммерчская, то многие "заимствования" для нее разрешены либо "с оглядкой", либо "забабло". Этораз

Во-вторых, опять "компилятор для джавы"? Ну да ладно, в любом случае, даже если присутствует Ahead Of Time механизм, язык жабы такой, что без виртуальной машины не обойтись, так что виртуальную машину все равно писать придется, если нужна НАСТОЯЩАЯ ДЖАВА. Так что "компилятор для джавы" - это суть задача оптимизации, а не корректости или наличия функциональности.

Ну а насчет LLVM.... LLVM - это просто инструмент... Кто-то от него фанатеет, кто-то от гыцыцы фанатеет, кто-то от опен64... Кто-то свое пишет. Все зависит от поставленных задач и методов их решения, не мешайте профессионалам. Советовать можно, но не забывайте, что советы нужны только для того, чтобы им НЕ следовать ;-)

Но мы сейчас для совместимости и по требованиям заказчиков стоим на развилке, что сделать LLVM или GCC.
Сейчас прорабатываем данную тему.

Aha wrote:

Как много всего намешано :-)

Я не мультиклет- разработчик. Я так... Сочувствующий...
Начнем с того, что в первом сообщении Yaisis предлагется вместо Just In Time компиляции посмотреть на Ahead Of Time сомпиляцию. Я не знаю уж как гугель договорился с той компанией, но есть организация, которая держит патент на AOT- компидяцию и глядя на тенденции на рынке, эту золотую антилопу она никому не отдаст и из рук не выпустит. В общем за АОТ платить надо будет, если я ничего не путаю.

Такая компиляция есть в .NET, есть в Андроид.
И я не знаю, как это можно запатентовать, т.к. по сути -- это обычная компиляция, только с промежуточным байткодом. В LLVM можно такой трюк провернуть -- можно распространять код в байткоде LLVM, а при установке на устройство компилировать его LLVM умеет компилировать свой байткод и что-то на него никто в суд не подаёт.

Далее утверждается, что "большинство программ скомпилировано для старых х86-платворм и не используют преимуществ новых". Мда... В данный момент у мультиклета 1-2-3-4 устройства, для всех можно сделать универсальный бинарник при компиляции с С/С++, подозреваю... (Если нельзя, то через полгода точно можно будет ;-) ). Конечно, если через 10 лет Мультиклет разведет такой же зоопарк устройств, как и интел и уже этот зоопарк станет проблемой, тогда да, но это утверждение похоже на попутку бежать впереди паравоза (напоминаю, я не имею отношения к Мультиклету, я сочувствующий)

И это утверждение верно. Но вы не поняли всю суть. Это было описано одно из преимуществ данного подхода. Конечно для мультиклета с его двумя версиями процессора компилятор С/С++ выиграет, но в данной ветке идёт речь о портировании туда Явы, а код Явы распространяется в байткоде и такая компиляция будет выгодней интерпретации в любом случае.

И вообще в том комментарии я писал о преимуществах данной техники компиляции по сравнению с остальными, а речи о Мультиклете там не было. Просто человеку рассказал о разнице между JIT, AOT и обычной компиляцией.

но это утверждение похоже на попутку бежать впереди паравоза

Успешные бизнесмены всегда бегут впереди паровоза, иначе они будут отставать и не выдерживать конкуренции, а расход их ресурсов будет неэффективен.
Пусть Мультиклет ещё недоразвитый процессор, но его разработчики должны смотреть в будущее, предвидеть события и выбирать правильные технологии уже сейчас. Для примера -- они могут разрабатывать свой компилятор с нуля и потратят на это кучу времени и денег, а потом создадут десктопный процессор и им уже понадобится GCC или LLVM, и им придётся заново развивать соответствующие компиляторы, т.е. они начнут повторно тратить время и деньги на то, что уже должно быть создано, когда они уже сейчас могут развивать, например, LLVM и использовать его как в нынешних версиях процессора, так и в будущих. При этом, когда понадобиться AOT-компиляция, то не возникнет особых проблем, т.к. на базе LLVM это можно реализовать очень быстро с минимальной тратой ресурсов.
Так же для процессора важно наличие ПО соответствующего ПО, а если самодельный компилятор не поддерживает какие-то технологии, то это потеря каких-то клиентов. Некоторые заместо того, чтобы покупать Мультиклет и приносит соответствующей фирме прибыль, будут отказываться от него в пользу других процессоров, которые удовлетворяют их потребности. Поэтому задача разработчиков Мультиклета удовлетворить как можно больше потребностей своих клиентов, тратя при этом как можно меньше своих ресурсов на разработку.
LLVM, как раз и является такой технологией, которая может удовлетворить много разных потребностей. Например потребности в языках программирования -- неужели клиент должен переписывать все свои программы на С/С++ ? Вряд-ли он это будет делать, он скорее всего выберет другой процессор, который поддерживает его язык. Конечно это просто как пример, т.к. большинство кода итак написано на C/C++, но не весь код. Но факт в том, что разработчики Мультиклета не смогут самостоятельно поддерживать все популярные языки программирования и они должны это осознавать уже сейчас и думать о будущем. Тоже самое касается и других технологий.

Ну конечно, для микроконтроллера хватит и С/С++. Просто я надеюсь, что дело не ограничится только микроконтроллерами.

Дальнейшее рассуждение про применение только архитектурно-зависимых оптимизаций уже кажется лишним, если му всегда можем изначально получать максимально оптимизированным под любую архитектуру бинарник

Это не лишнее, а идёт речь о лучшем подходе. Для сравнения можно привести процессор Эльбрус -- там тоже немного версий и можно было бы заранее скомпилировать под один процессор и распространять там код, но разработчики предусмотрели всё на будущее и программа компилируется там в промежуточный код, который подстраивается под необходимую версию процессора и это было придумано, ещё до создания процессоров Эльбрус.

И вы опять не поняли -- применение только архитектурно-зависимой оптимизации в данном случае тоже даст "максимально оптимизированным под любую архитектуру бинарник".
Максимальная оптимизация никуда не делась, просто она разделилась на два этапа -- архитектурно-зависимая и архитектурно-независимая, которые выполняются в разное время.
Я описывал лучшую модель распространения для десктопов и мобильных устройств, т.е. на будущее. Конечно Мультиклетовские процессоры не являются подходящими для такой модели, т.к. ещё не доросли.

му всегда можем изначально получать максимально оптимизированным под любую архитектуру бинарник

Приведу просто пример -- сейчас у них 4-клеточный процессор, а в будущем выпустят, например, 16-клеточный. И это уже два разных процессора, которым нужна своя оптимизация.
При нынешней их архитектуре код, подогнанный для 4-х клеточного на 16-клеточном будет выполняться не так эффективно, как если бы он был подогнан для 16-клеточного. И не надо утверждать обратного, т.к. при текущей их архитектуре, это так. Другое дело, что можно оптимизировать сразу под 16-клеточный и запускать на 4-клеточном, тогда уже должен получится более универсальный код.

Aha wrote:

В следующем сообщении товарища Yaisis используется очень много слов и выражений, основная мысль которых - "позаимствовать".

Вопрос: прежде чем присать подобные сентенции и выполнять данные действия господа программисты читаю лицензионные соглашения? Если да, то очень хорошо. Чаще всего в них написано "разрешено для некоммерческого использования", а поскольку Мультиклет - компания коммерчская, то многие "заимствования" для нее разрешены либо "с оглядкой", либо "забабло". Этораз

Что вы ко всему предираетесь ? Вам делать что ли нечего ?
Вот Мультиклетовцы и разобрались бы с лицензиями и определили бы на ходу действительно можно позаимствовать или нет. Я нигде не утверждал ни то, что можно позаимствовать, но даже то, что такое действительно есть в открытом доступе, а если есть то ещё и неизвестно как это там реализовано, может через способ, неподходящий Мультиклету.
Но главная мысль была в том, что перед тем, чтобы писать это с нуля, они могли бы посмотреть есть ли уже готовое решение, в открытом доступе и по подходящей лицензии, которое можно использовать.

Ну а насчет LLVM.... LLVM - это просто инструмент... Кто-то от него фанатеет, кто-то от гыцыцы фанатеет, кто-то от опен64... Кто-то свое пишет. Все зависит от поставленных задач и методов их решения, не мешайте профессионалам. Советовать можно, но не забывайте, что советы нужны только для того, чтобы им НЕ следовать ;-)

LLVM -- это не просто инструмент, а это современная технология, сильно облегчающая труд разработчиков. Благодаря ей clang развивается быстрее, чем gcc. Благодаря ей так быстро развились такие языки, как Rust и Go, т.к. их разработчики не писали кучу того, что уже реализовано. GCC по внутренней структуре сильно отстаёт от LLVM и не настолько продуман и гибок.

Кто-то свое пишет.

И тратит на это кучу времени, т.к. этому кому-то надо самостоятельно реализовывать поддержку всех стандартов языка программирования и поддержку всех современных методов оптимизации, когда они могли бы просто дорабатывать существующее.

Все зависит от поставленных задач и методов их решения, не мешайте профессионалам.

Тоже самое я могу посоветовать и вам -- не мешайте профессионалам.

krufter_multiclet wrote:

Но мы сейчас для совместимости и по требованиям заказчиков стоим на развилке, что сделать LLVM или GCC.
Сейчас прорабатываем данную тему.

LLVM современней по внутренней структуре, а GCC пока популярней, т.к. он давно развит до нужного уровня. Тут LLVM в роли догоняющего.
Я думаю, что будущее за LLVM, но также разработчики GCC могут переработать структуру своей технологии и сделать её такой же гибкой, как LLVM, они вроде к этому стремятся.

Под LLVM развиваются быстрее языки программирования, например clang быстро обзавёлся поддержкой самого последнего стандарта С/С++. Так же в clang лучше реализованы сообщения об ошибках, они детальней и полезней, это благодаря LLVM. Читал об этом, но не проверял.

LLVM модульный и её промежуточный код не завязан на исходники. В GCC же промежуточное представление кода ссылается на исходники, что неудобно и создаёт зависимости от языка.
В LLVM законченный байткод, а в GCC просто промежуточное представление, которое не может быть байткодом из-за своей недоразвитости.

В LLVM появляется выбор -- компилировать приложения, использовать JIT-компиляцию или AOT-компиляцию. Наличие таких возможностей может вам пригодится в будущем.
Через LLVM реализуются некоторые браузерные технологии, например Adobe Flash, конечно эту технологию пытаются заменить на HTML5, но дело в том, что через GCC подобного реализовать нельзя. Поэтому LLVM может использоваться и в других подобных проектах -- поддержка вами LLVM будет автоматически поддерживать и эти проекты.

В LLVM можно даже провернуть такое -- взять любую скомпилированную программу, например под x86, с помощью специальных средств, которые работают на основе генераторов LLVM преобразовать её обратно в байткод LLVM, а потом этот байткод скомпилировать под любую архитектуру. Конечно вам такое может и не нужно, но тут я продемонстрировал мощь LLVM, больше так никто не умеет делать.

Так же через LLVM реализована технология HSA.
Вы планировали сделать ускоритель вычислений и поддержка HSA будет там не лишней.

Так же, как я уже писал выше, через LLVM реализована Mono и AOT в Андроиде 5 -- они выбрали LLVM, а не GCC, потому что GCC не позволяет создать такое или неудобен для этого. В будущем наличие Mono может пригодится, если создадите десктопный процессор и так же пригодится поддержка LLVM, если захотите выпустить телефон на Андроиде 5 или более поздней версии.
Но смотреть в будущее лучше заранее, чтобы потом было легче.

Думаю, что лучше LLVM выбрать, т.к. это универсальный конструктор, с помощью которого можно создать намного больше, чем с помощью gcc и все новые языки программирования создаются в основном под него, т.к. он более приспособлен.

Но конечно вам решать.

Я не придираюсь, я обращаю Ваше внимание и внимание других людей, в том числе внимание остальных посетителей этого форума, на вещи, которые обычно остаются незаметными, про которые обычно думать не хочется, только и всего.

Нет, у меня хочень много дел, просто сейчас у меня обед и я решил написать ответ Вам в форум.

Я верю, что господа из мультиклета разберутся сами, хотел бы я им помочь в этом, но, увы не могу...

Я лишен восторга по отношению к LLVM, поэтому мне сложно Вас понять

"Доработка существующего" иногда стоит больше, чем разработка "с нуля", в данном случае у меня нет всей информации, поэтому не могу ничего сказать в защиту той или иной позиции.

Я никому не мешаю, надеюсь.

Aha wrote:

Я лишен восторга по отношению к LLVM, поэтому мне сложно Вас понять

А я наоборот за LLVM.
У всех свои предпочтения.
Так же и разработчики тоже сами всё решат, мы оба тут только советуем, каждый свою позицию.

"Доработка существующего" иногда стоит больше, чем разработка "с нуля", в данном случае у меня нет всей информации, поэтому не могу ничего сказать в защиту той или иной позиции.

Полностью согласен с этим, поэтому всё должно оцениваться на месте.

Мои патентные знания ниже среднего, я всего лишь пытаюсь пользоваться google.com

Патент (?) Platform-independent selective ahead-of-time compilation
https://www.google.com/patents/US7213240

И такого добра - ahead of time - там есть еще. И для андроида, и для .Net

Такая компиляция есть в .NET, есть в Андроид.
И я не знаю, как это можно запатентовать, т.к. по сути -- это обычная компиляция, только с промежуточным байткодом. В LLVM можно такой трюк провернуть -- можно распространять код в байткоде LLVM, а при установке на устройство компилировать его LLVM умеет компилировать свой байткод и что-то на него никто в суд не подаёт.

Несколько досужих домыслов, не претендующих на абсолютную истину (пока тесты у меня тут "бегут")
- на "правопреступника" обычно не подают в суд, пока с него нечего взять, то есть пока бизнес не приносит денег, или пока не нанесен прямой денежный ущерб правообладателю
- либо на правопреступника не подают в суд, если он таковым не является, например, просто "договорился" - купил лицензию
- ну и не подают в суд на самих себя, кто основные разработчики clang/llvm из числа больших корпораций? Apple и google, а гугель как раз является держателем парочки патентов на AOT-компиляцию, так что тут все получается законно. А вот как только Apple, google и комьюнити рассорятся и разведутся, так сразу можно ожидать всяких патентных чудесных войнушек (как это было уже вокруг компании SCO и OS UNIX)

Aha wrote:

Мои патентные знания ниже среднего, я всего лишь пытаюсь пользоваться google.com

Патент (?) Platform-independent selective ahead-of-time compilation
https://www.google.com/patents/US7213240

И такого добра - ahead of time - там есть еще. И для андроида, и для .Net

В телефонах тоже многое что запатентовано и от-сюда вы делаете вывод, что им не стоит разрабатывать свой телефон ?

Выводы делаете неправильные.

Если есть смысл в технологии, то её надо делать, а траты на лицензии -- это издержки, но прибыль от реализации должна окупать все издержки. Это обычный бизнес.

Повторю ещё раз, что я привёл преимущества АОТ-компиляции, но в текущем виде их процессора, она им не нужна, а в будущем может понадобится. Я не советовал им реализовывать АОТ-компиляцию, но я советовал портировать LLVM, на которой можно легко реализовать АОТ-компиляцию, если она понадобится.

И ещё по поводу данного патента -- насколько мне известно, Гугл не зарабатывает на патентах, а зарабатывает на сервисах и рекламе. Патентует он технологии для того, чтобы защищаться от патентных нападений других коммерческих фирм, таких как Эпл и Майкрософт. Гугл своими патентами делится с фондом СПО и не берёт за них лицензионных отчислений(на сколько знаю). Поэтому в этом патенте нет ничего страшного.

Aha wrote:

- ну и не подают в суд на самих себя, кто основные разработчики clang/llvm из числа больших корпораций? Apple и google, а гугель как раз является держателем парочки патентов на AOT-компиляцию, так что тут все получается законно. А вот как только Apple, google и комьюнити рассорятся и разведутся, так сразу можно ожидать всяких патентных чудесных войнушек (как это было уже вокруг компании SCO и OS UNIX)

У LLVM основным разработчиком раньше был Apple, потом она отошла от этих дел или снизила своё участие в данном проекте, сосредоточив силы на развитии языка программирования Swift, который делает на базе LLVM.
Эпл такая фирма, которая конечно могла бы подать в суд и именно из-за таких Гугл и фонд СПО ведут свою патентную базу.

Про патенты Гугла я уже написал выше, с ними не должно быть никаких проблем. В крайнем случае можно связаться с Гуглом и получить подтверждение или опровержение этого. Как я уже писал выше, Гугл делится своими патентами с фондом СПО, а зарабатывает он на рекламе и сервисах, а не на лицензионных отчислениях за патенты.

- на "правопреступника" обычно не подают в суд, пока с него нечего взять, то есть пока бизнес не приносит денег, или пока не нанесен прямой денежный ущерб правообладателю
- либо на правопреступника не подают в суд, если он таковым не является, например, просто "договорился" - купил лицензию

Это я вообще не понял к чему вы. Ни кто никого не заставляет нарушать закон, но в современном мире почти всё запатентовано. Не уж-то это означает, что вообще ничего делать не надо, а то вдруг чей-то патент нарушите ?

Yaisis wrote:

Aha wrote:

Мои патентные знания ниже среднего, я всего лишь пытаюсь пользоваться google.com

Патент (?) Platform-independent selective ahead-of-time compilation
https://www.google.com/patents/US7213240

И такого добра - ahead of time - там есть еще. И для андроида, и для .Net

В телефонах тоже многое что запатентовано и от-сюда вы делаете вывод, что им не стоит разрабатывать свой телефон ?

Простите, но выводы за меня в данном случае делаете Вы

Выводы делаете неправильные.

...и это Вы делаете неправильные выводы. Позвольте прояснить. Я повторюсь, но все же, я просто акцентирую внимание - Ваше и других посетелей форума - на тех вещах, о которых обычно не хочется думать - на дополнительных издержках на лицензионную чистоту.

Если есть смысл в технологии, то её надо делать, а траты на лицензии -- это издержки, но прибыль от реализации должна окупать все издержки. Это обычный бизнес.

Вы это знаете (и это прекрасно), но готов спорить, что половина программистов и подавляющее большинство пользователей даже не задумывалось о лицензиях, патентах и о том какую свинью можно себе подложить, если очень вольно с ними обходиться

Повторю ещё раз, что я привёл преимущества АОТ-компиляции, но в текущем виде их процессора, она им не нужна, а в будущем может понадобится. Я не советовал им реализовывать АОТ-компиляцию, но я советовал портировать LLVM, на которой можно легко реализовать АОТ-компиляцию, если она понадобится.

И ещё по поводу данного патента -- насколько мне известно, Гугл не зарабатывает на патентах, а зарабатывает на сервисах и рекламе. Патентует он технологии для того, чтобы защищаться от патентных нападений других коммерческих фирм, таких как Эпл и Майкрософт. Гугл своими патентами делится с фондом СПО и не берёт за них лицензионных отчислений(на сколько знаю). Поэтому в этом патенте нет ничего страшного.

До поры до времени, до того момента, пока не решит, что ему выгодно получть с какого-либо патента какую-нибудь денежку. Описанное Вами поведение компании Гугл - не правило, записанное в ее уставе, это просто "обычное ее поведение", которое может внезапно "ни с того, ни с сего" поменяться, поэтому не стоит полагаться на текущее положение вещей как на постоянное гарантиованное, вместо этого стоит "решать задачу в общем случае" - когда есть "звериный оскал патентного тролля"

- на "правопреступника" обычно не подают в суд, пока с него нечего взять, то есть пока бизнес не приносит денег, или пока не нанесен прямой денежный ущерб правообладателю
- либо на правопреступника не подают в суд, если он таковым не является, например, просто "договорился" - купил лицензию

Это я вообще не понял к чему вы. Ни кто никого не заставляет нарушать закон, но в современном мире почти всё запатентовано. Не уж-то это означает, что вообще ничего делать не надо, а то вдруг чей-то патент нарушите ?

Экий Вы радикалист... Патент - это не запрет, патент - это чаще всего флаг "смотрите, что я придумал, но я первый, поэтому используйте на здоровье, но мы с вами договоримся, что вы мне за это должны"

Aha wrote:

Позвольте прояснить. Я повторюсь, но все же, я просто акцентирую внимание - Ваше и других посетелей форума - на тех вещах, о которых обычно не хочется думать - на дополнительных издержках на лицензионную чистоту.

Тогда вы плохо справляетесь со своей работой, т.к. первым делом в данной ветке вам надо было написать о том, что сама Ява не свободна и принадлежит Ораклу, который поэтому поводу недавно подавал в суд на Гугл.

И вот я также напомню вам ваш комментраий:

Начнем с того, что в первом сообщении Yaisis предлагется вместо Just In Time компиляции посмотреть на Ahead Of Time сомпиляцию. Я не знаю уж как гугель договорился с той компанией, но есть организация, которая держит патент на AOT- компидяцию и глядя на тенденции на рынке, эту золотую антилопу она никому не отдаст и из рук не выпустит. В общем за АОТ платить надо будет, если я ничего не путаю.

Что ж вы не упомянули о том, что JIT-компиляция тоже запатентована ?

До поры до времени, до того момента, пока не решит, что ему выгодно получть с какого-либо патента какую-нибудь денежку. Описанное Вами поведение компании Гугл - не правило, записанное в ее уставе, это просто "обычное ее поведение", которое может внезапно "ни с того, ни с сего" поменяться, поэтому не стоит полагаться на текущее положение вещей как на постоянное гарантиованное, вместо этого стоит "решать задачу в общем случае" - когда есть "звериный оскал патентного тролля"

И вышеназванному Ораклу может тоже внезапно прийти в голову получить денежку со своей Явы...
Она этого и хотела, подавая в суд на Гугл.

К тому времени, когда появится процессор Мультиклет, на котором смогут работать популярные ОС, срок на этот патент истечёт и технология станет свободной. А до появления такого процессора АОТ-компиляция не очень-то и нужна, ведь на микроконтроллерах хватит и С/С++ с обычной компиляцией.
Вообще выше при упоминании АОТ-компиляции, говорилось об Андроиде, а Гугл будет только рада при установке Андроида на телефоны на базе Мультиклета.

Если АОТ-компиляция запатентована, то это не повод не портировать LLVM под Мультиклет.
В данном случае, мне лично не АОТ-компиляция интересна, а наличие LLVM.

Yaisis wrote:

Aha wrote:

Позвольте прояснить. Я повторюсь, но все же, я просто акцентирую внимание - Ваше и других посетелей форума - на тех вещах, о которых обычно не хочется думать - на дополнительных издержках на лицензионную чистоту.

Тогда вы плохо справляетесь со своей работой, т.к. первым делом в данной ветке вам надо было написать о том, что сама Ява не свободна и принадлежит Ораклу, который поэтому поводу недавно подавал в суд на Гугл.

Да, подавал. Воспользуюсь Вашим примером как демонстрацией того, что ничто не является гарантией от патентного судебного разбирательства

И вот я также напомню вам ваш комментраий:

Начнем с того, что в первом сообщении Yaisis предлагется вместо Just In Time компиляции посмотреть на Ahead Of Time сомпиляцию. Я не знаю уж как гугель договорился с той компанией, но есть организация, которая держит патент на AOT- компидяцию и глядя на тенденции на рынке, эту золотую антилопу она никому не отдаст и из рук не выпустит. В общем за АОТ платить надо будет, если я ничего не путаю.

Что ж вы не упомянули о том, что JIT-компиляция тоже запатентована ?

Про JIT речи не было, я предпочитаю придерживаться одной темы в разговоре

До поры до времени, до того момента, пока не решит, что ему выгодно получть с какого-либо патента какую-нибудь денежку. Описанное Вами поведение компании Гугл - не правило, записанное в ее уставе, это просто "обычное ее поведение", которое может внезапно "ни с того, ни с сего" поменяться, поэтому не стоит полагаться на текущее положение вещей как на постоянное гарантиованное, вместо этого стоит "решать задачу в общем случае" - когда есть "звериный оскал патентного тролля"

И вышеназванному Ораклу может тоже внезапно прийти в голову получить денежку со своей Явы...

Я Вас удивлю, но Оракл действительно получает денежку с Джава,

Она этого и хотела, подавая в суд на Гугл.

Но не патентным тролленьем, нет. Постоянный доход - вполне цивилизованый: сертификация, лицензирование, поддержка. Если Товарищи из Мультиклета напишут свою Джаву, то до тех пор как она не будет сертифицирована внутри Оракла его средствами, этот програмный продукт не может быть назыан Джавой.

К тому времени, когда появится процессор Мультиклет, на котором смогут работать популярные ОС, срок на этот патент истечёт и технология станет свободной. А до появления такого процессора АОТ-компиляция не очень-то и нужна, ведь на микроконтроллерах хватит и С/С++ с обычной компиляцией.
Вообще выше при упоминании АОТ-компиляции, говорилось об Андроиде, а Гугл будет только рада при установке Андроида на телефоны на базе Мультиклета.

Если АОТ-компиляция запатентована, то это не повод не портировать LLVM под Мультиклет.
В данном случае, мне лично не АОТ-компиляция интересна, а наличие LLVM.

Этот тред не про LLVM, а про Java, простите... Ради бога, пусть будет llvm хоть 10 раз, но не залипайте, топикстартер задал вопрос про Джава, а не про llvm. Как я уже говорил, я лишен восторга по отношению к llvm и вообще индиферентен к... Любые "рабочие перчатки" имеют право на жизнь, лишь бы не мешали работать.

Но мнение по LLVM нам тоже очень интересно. Так как сейчас запущен процесс проработки стыковки с LLVM.