Компания Intel подключилась (http://newsroom.intel.com/community/intel_newsroom/blog/2014... к разработке открытого проекта OpenJDK (http://openjdk.java.net/), в рамках которого развивается официальная открытая реализация Java. Присоединившись к сообществу OpenJDK компания Intel намерена расширить своё участие в развитии Java, которое ранее ограничивалось сотрудничеством с Oracle по оптимизиации работы продукта для систем на базе процессоров Intel. В качестве своего вклада компания
Intel намерена передать сообществу код библиотеки математических функций, рассчитанных на высокопроизводительный анализ больших объёмов данных, при использовании в таких областях как машинное обучение (https://ru.wikipedia.org/wiki/%D0%9C%D0%....
URL: http://newsroom.intel.com/community/intel_newsroom/blog/2014...
Новость: https://www.opennet.ru/opennews/art.shtml?num=40761
Нужен аппаратный жабопроцессор(вроде пытались уже), или хотя-бы её аппаратное ускорение.
Давно есть и используется повсеместно в сотовых телефонах и смартфонах.
Твои данные безнадежно протухли. Уже нифига не повсеместно, гугл этим IIRC не пользуется. Да и толку от того что было - было мало. Потому что ARMы умели напрямую выполнять далеко не все опкоды и выигрыш относительно чисто софтварной реализации получался скромным.Перспективнее смотрится идея гугли с предкомпиляцией. Ну тогда не выделывались бы уже и взяли нечто типа llvm, чтобы софт можно было писать на любом ЯП без гемора.
> Перспективнее смотрится идея гугли с предкомпиляцией.Не особо. У JIT больше возможностей оптимизации за счет информации доступной во время выполнения. Например, сейчас загружена только одна реализация виртуального метода — можно ее не то что связать напрямую, а даже встроить, а потом, если в результате загрузки нового класса появится еще одна реализация, можно разоптимизировать обратно. HotSpot в OpenJDK это делает.
> взяли нечто типа llvm, чтобы софт можно было писать на любом ЯП без гемора.
Без гемора не получится: для каждого языка потребуется FFI и свои привязки к системным библиотекам.
вот именно что hotspot, не хочу подымать холивар, но по сравнению с openjdk у dalvik количество оптимизаций ну совсем капля. по крайней мере там в интерфейсе метода намного дешевле держать уже сразу класс реализации, а не общий интерфейс, так как это дает выигрыш по скорости, а вы тут про линковку и инлайнинг рассказываете. профилирование в далвик тоже еще та песня .....
Так ведь и hotspot на среднестатистических мобильных приложениях ничего не даст (почти), его оптимизации заточены под другое, потому его и нет смысла туда пихать.
p.s. В дополнение :)
> llvm
> на любом ЯП
> без гемораШутник? Или обкурился?
> Перспективнее смотрится идея гугли с предкомпиляцией. Ну тогда не выделывались бы уже и взяли нечто типа llvm, чтобы софт можно было писать на любом ЯП без гемора.Спасибо за совет. На FreeBSD пользуюсь и LLVM, и OpenJDK JIT. Разницы не видно.
Это не эффективно. OpenJDK JIT создаёт нативный код для x86 близкий к совершенному.
Хорош тролить! Он совершенен.
> Нужен аппаратный жабопроцессор(вроде пытались уже), или хотя-бы её аппаратное ускорение.ARM Jazelle, вроде. "Давно есть и никому не нужен."
ещё один аппаратный костыль совсем не повредит совсем не закостыленной х86 :trollface:
> Нужен аппаратный жабопроцессор(вроде пытались уже), или хотя-бы её аппаратное ускорение.Для чего?
Для мобильников? Думаю Intel не из-за них в OpenJDK ввязывается, а для серверов не особо нужен, правильная статистика и перекомпиляция кусков там оптимальней смотрится, и с памятью лучше.
Простите зачем. когда есть отлично работающая JIT компиляция ?
К слову, Вы мне напомнили один момент.
На последнем Java one, была сессия "Java ME not dead".
Так вот там было ряд интересных докладов, в т.ч. по микропроцессорам с аппаратной поддержкой
Смысл виртуальной машины как раз в том, что написанный один раз код будет запускаться независимо от железа и программной прослойки( в виде ОС)...
> Intel намерена передать сообществу кодЭто ещё не новость.
А что это? Дискуссия? Рассказ? Стих?
> А что это? Дискуссия? Рассказ? Стих?Намерение.
Именно! Именно поэтому это "новость" о намерении...
> Именно! Именно поэтому это "новость" о намерении...Я намереваюсь захватить вселенную. Это тема для новости?
> Я намереваюсь захватить вселеннуючем если не секрет ?
Каретой скорой помощи с 1 водителем и бригадой санитаров [а также ионой пушки и экзоскелетов уровня круизиса]
Вряд ли эта новость взбудоражит медсестру, впрочем, как и ваших соседей по палате.
С чего это вдруг?Походу начал метаться...
Каким боком тут процы и джава? Байткод в виде ассемблера?
Не, это хорошо, что присоединились конечно...
Это профессиональное мнение?
> Это профессиональное мнение?Это не мнение, а вопросы.
Профессиональное чтение?
Intel давно уже Java'ой занимается.
Раньше спонсировали и ресурсы выделяли на Apache Harmony (совместно с IBM), в какой-то момент прикрыли развитие, когда OpenJDK взлетела, теперь просто присоединились к OpenJDK. Всё логично.Кстати один из сотрудников Intel в своё время реализовал обвеску для Eclipse позволявшую отлаживать Java код и обёрнутый С/C++ код, в случае если он вызывался. Работало на стыке JDT и CDT плагинов, но фурычило только на Apache Harmony.
ну может посмотрели на порнографию в виде javascript, из которого хотят сделать ассемблер, и решили, что уж лучше java?
> ну может посмотрели на порнографию в виде javascript, из которого хотят сделать
> ассемблер, и решили, что уж лучше java?Посмотрели на покупателей джавва энтерпрайзов и решили, надо им продать больше, бооооОООоольше штеуд чущт-ов.
> ну может посмотрели на порнографию в виде javascript, из которого хотят сделать
> ассемблер, и решили, что уж лучше java?Intel занимается развитием Java уже скоро как 10 лет (еще в 2006 контрибьютили большое количество кода в Apache Harmony). С разморозкой =))
Нормуль-же - 86я архитектура изначально открыта.
"Посмотрим, что из этого выйдет."
(с)