Ждём Ваших отзывов о материале.

Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
За статью можно проголосовать на странице материала.

Поржал от души! Calxeda тупо обанкротилась по причине отнюдь не непопулярности их платформ, а сугубо из-за непродуманной финансовой политики. На ARM серверы HP очередь на 100 км и все ждут массовый выпуск ARM 64-x битных чипов (например от AMD), а Calxeda еще и глупо прокололась не развивая ARM архитектуру, а снимая сливки и к тому-же ценовая политика была отвратительной. Apache, Hadoop, полностью законченные производительные, надежные и БЕСПЛАТНЫЕ (!) решения от Oracle только и ждут массового распространения таких серверов. Вообще ценовая политика Oracle (например бесплатность готового интернет комплекса до 50 кластерных узлов) позволяют многим компаниям и интернет провайдерам значительно снизить издержки на приобретение и содержание аппаратной инфраструктуры, делая Internet тарифы еще более дешевыми. За ARM серверами будущее и оно приближается как страшный сон для Intel! Например 4-х или 8-ми юнитовый сервер с 288 узлами (1 блок сразу на 4 модуля и сам размером с HDD 3,5") по 2 4-х ядерных процессора ARM x64 2,4 Ггц + короткие инструкции и самый передовой софт на планете. Вы можете себе представить подобную мощь и перевести ее в сотни киловатт в час энергопотребления и море х86 мусора занимающего целый этаж + стоимость закупки сравнимой мощностной Xeon х86 архитектуры?

dvdm Вы так говорите, как будто лично знакомы с людьми из этой очереди. Кто ждет? На рынке серьезных серверов и HPC дохлые ядра никому не нужны. Интел выпилила IBM, oracle, sun, AMD с массового рынка. Напомнить про количество интела в TOP500? На ноябрь 2013 80%(!) серверов на последних-предпоследних xeon. Максимум, что светит ARM - это доля в офисных "серверах", но там есть и атом. И да, кто будет писать самый передовой софт? Слезть с х86 не так то просто, тонны софта надо переписывать. Только некоторых компаний, чей софт используется в серверах уже давно нету. И скорее дешевле выйдет держать кучу стоек и платить за квт/часы, чем слезать с х86(если кто-то на архитектуре ARM начнет делать быстрые ядра)

Знатный белив. Предлагаю сию мощность прежде всего измерить, как в плане энергопотребления, так и производительности.

Ну конечно производительность серверов на арм предложите для честности измерять прогами типа «супер пи»?

Как вариант.

NAS'ы - по сути тоже микросерверы и в большинстве случаев там армы (самосборные не имеются ввиду).

Нет, SPEC. Зачем же Super Pi, там и без тестов ясно, что будет эпичный слив.

В том то и дело что arm-овские 12-15 ваттные печки никому не нужны, когда атом сравнимой производительности потребляет по 5-10.

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


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


Cortex A7 на 1 ГГц потребляет 400 мВт на ядро. Покажите х86 с сопоставимой производительностью и потреблением.

Приведите конкретный пример. Есть какие-нибудь тесты?
То, что работала на серверной винде с x86, заработает на ARM? Покажите подобный софт, очень интересно стало.
А можно глянуть тесты SPEC этого самого Cortex A7? Да и что говорить, Bay Trail давно продается, 0,4 Вт для тормозного A7 - это приговор, подобный хлам можно смело выбрасывать.

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

Но если брать ближе к реальности, то из той же теории СМО один быстрый канал, в которую ждет много очередей всегда быстрее, чем N каналов, при любых N > 1.

Открываете на своей машине 100 копий 7zip, запускаете в них бенчмарк. Суммируете MIPSы. Запускаете один тест. Смотрите MIPSы. Сравниваете, печалитесь...


Любой софт, писаный на .NET. Ибо .NET приложение


http://research.cs.wisc.edu/vertical/pa ... les-tr.pdf к примеру, правда там сиарый А8 - но А7 будет примерно равен по производительности.


Bay Trail с его 5-10 ваттами? Не смешите.