Эндрю Хейли (Andrew Haley), работающий в компании Red Hat, объявил (http://www.advogato.org/article/1067.html) о работе по подготовке порта Java для 64-разрядной архитектуры AArch64 (ARM64), реализованной в процессорах, поддерживающих набор команд ARMv8. Результаты портирования будут развиваться как одни из подпроектов OpenJDK, что позволит заинтересованным энтузиастам и компаниям присоединиться к процессу разработки.
В настоящее время поддержка в OpenJDK архитектуры ARM оставляет желать лучшего. Для 32-разрядных систем ARM доступны две реализация JIT-компилятора для виртуальной машины HotSpot, используемой проектом OpenJDK: проприетарная разработка от компании Oracle и свободный JIT-компилятор, который сильно отстаёт по производительности от варианта Oracle в силу использования упрощённой архитектуры. Чтобы недопустить подобной ситуации для 64-разрядных систем ARM, компания Red Hat приняла решение создать своими силами полноценный и высокопроизводительный JIT-компилятор для архитектуры AArch64, который будет распространяться свободно.
Интересно, что из-за того, что устройства на базе ARMv8 пока не выпущены на рынок, для разработки порта HotSpot VM был создан простой симулятор процессора ARMv8. Использование симулятора не даёт полной гарантии, что при выполнении порта на реальном оборудовании не возникнет проблем, но позволяет подготовить работающий прототип к моменту поступления в продажу первых процессоров ARMv8. В настоящее время уже близка к завершению реализация интерпретатора шаблонов для ARM64, который является первым этапом портирования HotSpot на новые архитектуры.
Первый рабочий прототип планируется сформировать к рождеству, после чего код будет опубликован публично. Прототип будет поддерживать все необходимые возможности для запуска Java на AArch64, но не будет отличатся высокой производительностью из-за отсутствия JIT-компилятора. Для решения данной проблемы сразу после публикации кода начнётся процесс создания нескольких вариантов JIT-компиляторов: "клиентского" C1, а затем и "серверного" C2.
JIT-компилятор C1 обеспечит обработку только базового набора типовых ситуаций без углубления в специфику выполнения кода, поэтому он прост в создании и позволит разработчикам досконально проанализировать особенности архитектуры ARM64. После этого опыт, накопленный в процессе разработки C1, будет применён для создания более сложного и высокопроизводительного JIT-компилятора C2. Кроме того, создание C1 позволит реализовать двухфазную схему JIT-компиляции, при которой на начальной стадии выполняется C1, после чего наиболее часто используемые участки кода рекомпилируется при помощи более сложных методов C2.Дополнительно можно отметить публикацию (http://www.spinics.net/lists/kvm/msg81669.html) набора патчей с реализацией поддержки системы виртуализации KVM для процессоров ARM Cortex A15. Это третья попытка обеспечения работы KVM на архитектуре ARM, которая скорее всего будет утверждена для включения в состав ядра Linux 3.8. Напомним, что в состав тестовых версий ядра 3.7 были включены (http://www.opennet.me/opennews/art.shtml?num=35085) патчи поддержкой с механизмов виртуализации Xen для систем на базе процессоров ARM Cortex A15.
URL: http://www.advogato.org/article/1067.html
Новость: http://www.opennet.me/opennews/art.shtml?num=35174
Полноценный сервер размером с флешку уменьшает прозрачность до 87%. Ждём массового производства SoC с процессором на архитектуре ARMv8.
А если эта "флэшка" в прозрачном корпусе?
Тогда на 87.5% :D
Ждём облака на ARM.
С серверами размером с флешку каждый сможет создать себе свое облако сам.
Дороговато будет, ибо производительность на ватт у арм пока хромает.
Так то да. Ибо x86 очень сильно развилась, но несёт в себе огромную избыточность инструкций, которой RISC-процессоры не страдают. ИМХО, думаю в ближайшее время эффективность ARM значительно повысят.
Я диванный аналит^W^W не специалист, но своим дилетантским умом понимаю, что аппаратная реализация этой "избыточности" суммарно занимает очень небольшую площадь кристалла, гораздо меньшую чем например кэш. А экономия на переходах между состояниями энергосбережения (x86 действительно не умеют спать эффективно) не играет никакой роли на серверных нагрузках. Так что х86 относительно к серверам может спокойно тянуть балласт в виде избыточности системы команд, никому от этого вреда не будет.
Насчёт потребления Кэша, тут ты прав. Таки в новых AMD будет фича, которая отрубает часть кэша и подключает при необходимости. Плюс у ARM(или всех RISC) есть бескостыльность с конвейером: при неверном угадывании перехода, сбрасывается конвейер, у RISC же, если не ошибаюсь, он не сбрасывается, а не выполняется определённое количество инструкций до необходимых. Ну природе то будет урон. :3
>при неверном угадывании перехода, сбрасывается конвейер, у RISC же, если не ошибаюсь, он не сбрасывается, а не выполняется определённое количество инструкций до необходимыхВы в серьез в это верите? Pentium 2 внутри RISC, снаружи только перекодировщик из x86 кода в uops. А уж как конвейер реализован, это вообще никак не относится к сложности команд что реальных (uops) что виртуальных. А теперь прикинь сколько времени прошло со времен пентиума2, там внутри давно уже аппаратный многомашинный комплекс соединенный шинами и коммутаторами. Конвейер, блин.
Есть сервера бОльшую часть жизни проводят в спячке - файлопомойки к примеру.
Если оно будет слегка дороже аналогичной по мощности виртуалки на Xen - вполне приемлемо. Всё же с распределением ресурсов(особенно диска) в виртуалках пока совсем не фонтан.
Ну как минимум бесплатный колокейшен для ARM уже есть :)
http://www.edis.at/en/server/colocation/austria/raspberrypi/
Даешь облако нано-ботов выковыривающих козявки :)
Уже. См. персонал РОСНАНО.
По какому принципу объединили эти новости???
По принципу "и там, и там ARM", очевидно
> Red Hat приняла решение создать своими силами полноценный и высокопроизводительный JIT-компилятор для архитектуры AArch64Хорошая шутка. Они так заоптимизировали gcc для ARM что в оконцовке оказалось что если вообще не использовать SIMD (да-да - armhf на котороый сейчас все дистрибутивы перешли) производительность вырастает в разы.
>> Red Hat приняла решение создать своими силами полноценный и высокопроизводительный JIT-компилятор для архитектуры AArch64
> Хорошая шутка. Они так заоптимизировали gcc для ARM что в оконцовке оказалось
> что если вообще не использовать SIMD (да-да - armhf на котороый
> сейчас все дистрибутивы перешли) производительность вырастает в разы.Дадада, нет чтобы кнопочки GUI передвинуть, или с самолета диски RedHat сбросить над тайгой, умора просто с них. И естесственно баргепорт регрессии оптимазатора надо постить на opennet, тут тусуются разработчики GCC круглые сутки.
>>> Red Hat приняла решение создать своими силами полноценный и высокопроизводительный JIT-компилятор для архитектуры AArch64
>> Хорошая шутка. Они так заоптимизировали gcc для ARM что в оконцовке оказалось
>> что если вообще не использовать SIMD (да-да - armhf на котороый
>> сейчас все дистрибутивы перешли) производительность вырастает в разы.
> Дадада, нет чтобы кнопочки GUI передвинуть, или с самолета диски RedHat сбросить
> над тайгой, умора просто с них. И естесственно баргепорт регрессии оптимазатора
> надо постить на opennet, тут тусуются разработчики GCC круглые сутки.тут вообще разрабов серьезных не бывает, одни трепачи диванные. Максимум "продвинутые пользователи Убунту"