LINUX.ORG.RU

Серверное оборудование на ARM64: версия AMD

 , , ,


2

3

Вчера на конференции Open Compute Summit AMD представила платформу для разработки серверов на новом семействе процессоров AMD® Opteron™ A1100. Предлагаемые индустрии процессоры имеют следующие характеристики:

  • 4 или 8 ядер Cortex™ A57
  • до 4МБ кэша L2 и до 8МБ L3, разделяемого между всеми ядрами
  • двухканальный контроллер памяти DDR3 или DDR4 с поддержкой четности и частот обмена до 1866МГц;
  • до 4 разъемов SODIMM, UDIMM или RDIMM;
  • 8 линий PCI-Express® 3.0;
  • 8 портов SATA3;
  • 2 порта Ethernet 10G;
  • технология ARM TrustZone®;
  • сопроцессоры для ускорения шифрования и сжатия данных;
  • технологические нормы производства 28нм.

Рабочая частота, потребляемая мощность и тип корпуса/разъёма не уточняются; при этом ссылка на страницу продукта ведет на описание семейства Opteron™ 6300, а семейство A1100 поиском на сайте не находится.

Сама платформа включает в себя материнскую плату форм-фактора µATX, содержащую:

  • процессор серии AMD® Opteron™ A1100;
  • 4 слота RDIMM с поддержкой памяти DDR3 объемом до 128ГБ;
  • разъемы PCI Express®, конфигурируемые, как один порт x8 или два порта x4;
  • 8 разъемов SATA;
  • систему питания, совместимую со стандартными БП;
  • стандартный загрузчик UEFI.

Кроме того, в составе платформы предлагается рабочее окружение, построенное на базе Fedora Linux и обеспечивающее разработчиков необходимыми инструментами: стандартным набором ПО GNU toolchain для кросс-сборки на целевую платформу, драйверами устройств целевой платформы, а так же связкой Apache/MySQL/PHP/Java (версий 7 и 8) для веб-разработки.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: Klymedy (всего исправлений: 4)

Ответ на: комментарий от anonymous

Гарантированная десятилетиями бинарная совместимость.
Огромное количество софта.

А open source тебе на что? Чай не на винфаке сидим.

Идеальный баланс компактности кода и сложности декодирования.

4.2, viva la Thumb.

Очень высокая производительность при смешных ценах.

Не является заслугой x86.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

«тормозное» - архитектура набора команд тут ни при чём

Ну почему же? Чрезмерно тупая и низкоуровневая ISA неизбежно диктует и особенности реализации. В x86 просто call и ret, и железо их может оптимизировать как угодно. В ARM же ничего подобно нет, есть низкоуровневая дрочка регистров, и для оптимизации предсказаний вызовов нужно как-то эти конструкции распознавать (чего никто не делает, естественно).

anonymous
()
Ответ на: комментарий от anonymous

Очень высокая производительность при смешных ценах

на энергоносители

anonymous
()
Ответ на: комментарий от ncrmnt

Ничто не мешает сделать. В UEFI консоль работает через два стандартных протокола: EFI SIMPLE TEXT OUTPUT PROTOCOL и EFI SIMPLE TEXT INPUT PROTOCOL.

gadfly ★★
()
Ответ на: комментарий от intelfx

А open source тебе на что?

Ну найди мне open source CAD/CAM/CAE системы адекватные. Посмеемся.

Чай не на винфаке сидим.

Под линукс полно качественного коммерческого софта. Под x86, естественно.

4.2, viva la Thumb.

Thumb все равно менее компакный при прочих равных, чем x86.

Не является заслугой x86.

Является, см. выше про компактность и OoO-декодирование.

anonymous
()
Ответ на: комментарий от anonymous

В ARM же ничего подобно нет, есть низкоуровневая дрочка регистров

Это называется RISC. Давно известно, что такие архитектуры быстрее CISC при прочих равных.

intelfx ★★★★★
()
Ответ на: комментарий от user_id_68054

я вот пока что наблюдаю картинку что для ARM софта маловато...

Да ладно, жить можно.

Достаю свой аргумент в пользу ARM: два года назад вышел ноутбук. 16 часов работы от батареи, вес меньше килограмма, разрешение 1920x1200 на 10", 64 Гб SSD, стоил тогда чуть меньше 1000$. Мощность четырёхъядерной тегры на 1.6ГГц примерно соответствует тогдашним младшим Core и уж всяко быстрее атомов.

Я кончил. Пишу сии строки с него.

Aceler ★★★★★
()
Ответ на: комментарий от intelfx

Это называется RISC.

А в RISC есть смысл только если у тебя один тупой конвейер. Для OoO от RISC одни неприятности.

Давно известно, что такие архитектуры быстрее CISC при прочих равных.

Кому это «известно»? RISC в наше время уместен только в микроконтроллерах, где бюджет регистров очень ограниченный. RISC быстрее при прочих равных только при очень ограниченных размерах кристалла. При росте возможностей преимущества RISC теряются.

anonymous
()
Ответ на: комментарий от Reset

Вы такими повторами готовитесь предъявить аргументы или просто молитесь?

Vit ★★★★★
()
Ответ на: комментарий от anonymous

Thumb все равно менее компакный при прочих равных, чем x86.

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

Под линукс полно качественного коммерческого софта. Под x86, естественно.

См. выше.

Является, см. выше про компактность и OoO-декодирование

И как связаны стоимость процессора, компактность кода и наличие Out-of-Order? Более того, последнее является деталью реализации, а не свойством архитектуры.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ретрансляция кода на лету (слышал, что ядро давно уже RISC?)

то есть получается что новые версии реализаций x86-процессоров — способны менять внутренний формат команд (тот который RISC).. ...и эти изменения не станет убивать обратную совместимость?!

если «ответ да» — то это же получается что «Ретрансляция кода» создаёт не плохое приемущество перед изначально-RISC-процессорами, у которые не могут менять формат команд, чтобы не убить обратную совместимость?!

user_id_68054 ★★★★★
()
Ответ на: комментарий от Dark_SavanT

через веб-морду и сетевую консоль

vovan72
() автор топика
Ответ на: комментарий от user_id_68054

Ответ - да. Дело в том, что это дороже, сложнее и больше жрёт.

Апофеозом обратного можно назвать VLIW - архитектуры с очень длинными и подробными командами, где в рантайме вообще нет никаких оптимизаций, а вся работа по распределению между конвейерами/блоками/etc выполняется компилятором. Такие вещи тоже имеют право на жизнь, и IMHO так даже лучше. Но увы, тогда в каждой системе должен быть JIT/AOT-компилятор :)

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

Зато я с радостью бы расстался с половиной производительности процессора ради того, чтобы этот пыльный гроб не гудел и не дребезжал.

Открой для себя SSD и нормальные кулеры.

yu-boot ★★★★
()

из всего этого только будущая поддержка ддр4 порадовала. Все остальное какое-то нищебродское, несмотря на ARM. Очень, очень ненужно.

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

Ну найди мне open source CAD/CAM/CAE системы адекватные. Посмеемся.
Под линукс полно качественного коммерческого софта. Под x86, естественно.

Ну так, разрабатывается же решение: http://www.youtube.com/watch?v=LScf7GPhQSQ http://www.youtube.com/watch?v=uVknjU7eGbI

uin ★★★
()
Ответ на: комментарий от intelfx

А собственно в чём проблем? Исходники есть, го компилировать.

а почему кстате на форумах частенько попадаются люди которые говорят что компилировать надо на x86-компьетре, а заливать потом на ARM?

(кросскомпиляция).

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

или это всё враки пишут :) , а на самом деле софт хорошо (резво) компилируется на самих же ARM-железках?

user_id_68054 ★★★★★
()
Ответ на: комментарий от anonymous

Для OoO от RISC одни неприятности.

В каком месте?

RISC в наше время уместен только в микроконтроллерах

Опять же, почему?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

Обычно просто девайс на ARM сильно слабее (смартфон или одноплатник <1GHz), чем аппарат на x86.

Ну а ARM-ов, сравнимых по классу с x86, я в руках не держал, поэтому хз.

intelfx ★★★★★
()
Ответ на: комментарий от ncrmnt

посмотрел ценник на атеновские квмы. выходит десятка баксов на одну стойку. пожалуй убедил.

vovan72
() автор топика
Ответ на: комментарий от intelfx

В каком месте?

Тред не читай, сразу отвечай? Выше я описывал, как от компактности кода зависит, сколько микроинструкций выродит за один такт декодер из IC.

Опять же, почему?

Опять же, компактность кода.

anonymous
()
Ответ на: комментарий от Aceler

разрешение 1920x1200 на 10

Вот-вот, $200 за интеловский ULV, можно будет и на оснащение эйров ретина дисплеями пустить, реши эпл перевести их на свой арм.

uin ★★★
()
Ответ на: комментарий от vovan72

и к чему его подключать на стандартной серверной ферме?

Если выводить не TTL, а полноценный (по допустимым напряжениям) RS232, то можно воткнуть в одноюнитовый RS232-to-Ethernet с кучей портов.

Deleted
()
Ответ на: комментарий от anonymous

RISC в наше время уместен только в микроконтроллерах

а ничего, что современный x86 тоже RISC?! У x86 только верхний слой CISC — прослойка для совместимости. Непосредственно перед исполнением они преобразуют CISC-инструкции x86 в более простой набор внутренних инструкций RISC.

ivanlex ★★★★★
()
Ответ на: комментарий от intelfx

Если доступное тебе дисковое пространство ограничено четырьмя килобайтами,

Не, ну не тупой ли? Причем тут дисковое пространство. Какой ширины у тебя одна линия в IC, а?

anonymous
()
Ответ на: комментарий от intelfx

компактность кода и наличие Out-of-Order? Более того, последнее является деталью реализации, а не свойством архитектуры.

Тупой? Чем компактнее код, тем больше инструкций за такт можно декодировать в OoO.

anonymous
()
Ответ на: комментарий от intelfx

получается (на мой скромный взгляд) — в этом вся проблема и есть:

ARM-железка === слабая && несовместимая{ с другими слабыми железками }

если бы было бы что-то только одно — либо только «слабая», либо только «несовместимая» .. а тут сразу оба недостатка — накладываются друг на друга :-( .

вот например возьмём [гипотетический] x86-телефон. он тоже слабый, но зато на нём совместимый набор команд, который позволяет использовать готовый репозиторий заранее откомпилированного x86-кода :-)

ну это я тут так — развёл теорию, почти на голом месте :-)

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от user_id_68054

Ответ «Да». Внутренняя архитектура, к примеру у AMD и Intel различна. Одинакова только морда прослойки, которая смотрит на пользователя.

ivanlex ★★★★★
()
Ответ на: комментарий от yu-boot

Открой для себя SSD и нормальные кулеры.

SSD никуда не денет жар из системника. Я вот сейчас сижу, и ноги у меня в тепле, так как их горячим воздухом из системника обдувает.

И как бы не были хороши кулеры, гулкий звук от проходящего потока воздуха через системник никуда не денется.

ivanlex ★★★★★
()
Ответ на: комментарий от user_id_68054

То, что железки слабые, не является недостатком ARM. Их просто сейчас делают слабыми (и мало жрущими): рынок мощных десктопов уже занят x86, а поскольку там проприетарщина, перетащить его на ARM возможным не представляется.

И несовместимость тоже нивелируется наличием открытых исходников.

intelfx ★★★★★
()
Ответ на: комментарий от ncrmnt

И да, UEFI сиранэ это не весело. Лучше бы убут.

ага, со своей сборкой uboot и ядра под каждую плату.

Нет чтобы по-человечески вывести TTL UART.

Точно, со своими уровнями и своим разъемом, чтоб не дай бог можно было воткнуться стандартной консолью.

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

AVL2 ★★★★★
()
Ответ на: комментарий от intelfx

Линия чего? Кэша?

Бинго! Раз мозг включил, начинай теперь думать. Может и поймешь, как от количества инструкций в линии IC зависит максимально возможное количество функциональных блоков.

anonymous
()
Ответ на: комментарий от anonymous

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

intelfx ★★★★★
()
Ответ на: комментарий от ivanlex

а ничего, что современный x86 тоже RISC

Тормоз, да? Мы тут про разницу как раз в декодере и в IC говорим. Что там дальше, после декодера, это уже никого не колышет.

anonymous
()
Ответ на: комментарий от intelfx

Ты, видимо, говоришь, что в случае компактных инструкций их можно протолкнуть через шину данных за меньшее количество тактов?

Именно. За один такт читается целиком вся текущая линия из IC. Ширина этой линии ограниченная. Чем больше инструкций в нее попало, тем больше их будет за этот так декодировано, и тем больше порожденных при декодировании микроинструкций можно будет распихать по резервациям и функциональным юнитам.

anonymous
()
Ответ на: комментарий от anonymous

Ширина этой линии ограниченная.

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Orlusha

ARM разрабатывает спеки — эталон. Лицензиаты изменяют/оптимизируют спеки согласно своей идеологии под свои нужды. Если откомпилируешь бинарник под эталон, он будет работать на всех камнях внутри версии. Если откомпилируешь бинарник под, скажем для qualcomm, возможно будет работать только на qualcomm.

ivanlex ★★★★★
()
Последнее исправление: ivanlex (всего исправлений: 1)
Ответ на: комментарий от uin

На веб-серверах очень ждут. А еще ждут на vps/vds. В общем, место для применения есть, где не нужны дикая пиковая производительность, но очень желательно экономичное энергопотребление.

ivanlex ★★★★★
()
Ответ на: комментарий от uin

Ну, это уже пользователю решать, как на него морда процессора смотрит.

ivanlex ★★★★★
()
Ответ на: комментарий от intelfx

Чем и как?

Железом. Скоростью памяти (линия кэша должна заполняться burst-ом, желательно одним). Соображениями энергопотребления, в конце концов.

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

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

anonymous
()
Ответ на: комментарий от Free-Boatman

потому что заводы умеют в неё и она дешевая.

Кого? Интел? Он про интел же

uin ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.