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


Скорость еще не выросли до взрослых решений именно по скорости.

Угу, берем компилятор А, который генерит код только для х86, но сгенеренный код на 50% быстрее х86 кода компилятора Б, который хоть и не такой эффективный, но кросс-платформенный. Сравниваем результат, и кричим вовсю о превосходстве х86, хотя на деле оказалось что прирост - из-за компилятора, а сам х86 уже давно слился...


Скорость в чем/где? В однопоточных вычислениях? В серверах это мало кого волнует (посмотрите частоты топовых зионов).

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


Ну вы же сами себе противоречите? Зачем писать "быдлокод + левый компилятор" и кричать, что медленный проц. Если есть решения показывающие, что проблема только в программистах. Мне как пользователю наплевать на то какой компилятор, но быстрые приложения это всегда хорошо.

Это вам так кажется. Частоты снижены для чего, не напомните? Кажется нужно вписаться в тепловой пакет. Или ошибаюсь?

Повторяю в очередной раз - да потому, что тестируем производительность процессора, а не компилятора.


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


Зачем сравнивать медленный код с быстрым и кричать, что процессор медленный - не подскажете?


А зачем впихивают 18 медленных ядер в тепловой пакет вместо 6-8 быстрых на 4ГГц, и просят за это огромные деньги - как думаете?

а если нас производительность нужна, то зачем медленный компилятор? Из принципа просто? Нафиг ненужно никому. Или может формулу 1 будете заправлять 80-м бензином ибо у для сравнения запорожец есть? А что не менять же колонку заправочную.


Это по вашемутак. привязываем неэффективный компилятор для х86 и кричим что проц тормозит.


Тоже похоже. Поэтому я все время и пишу, что для тесты просто обязаны выжимать все из процессора, для этого и код можно поменять если другой код более эффективен. И смысл считать 2+2+2+2+2+2+2+2+2+2 вместо 2*10 только из-за того, что калькулятор не умеет больше? Зато калькулятор возможно умеет другие вещи выполнять удобнее и быстрее.

Как сами то думаете? наплмню, что прирост тепловыделения штука не линейная. Поэтому 8-мь ядер на частоте 4Ггц проблемно. Лучше 16 на частоте 2,5-3Ггц. Но это справедливо только для приложений способных выдавать кучу потоков, а так вот знаю где серверная часть грузящая 1!!! ядро на 8-ми ядерном серваке. Там частота уже нужна. Не зря пошли сейчас динамические разгоны.

Не важно какой компилятор - медленный или быстрый. Важно чтобы был один и тот же.


Не потому, что калькулятор не умеет больше, а потому, что сидящий за калькулятором (компилятор) умеет только так.
По-вашему, лучше в одном случае считать 2+2+2+2+2+2+2+2+2+2 , во втором - 2*10, и на основании этого утверждать что второй калькулятор в 10 раз быстрее посчитал?


Вот потому в серверах и приживется арм, который при сопоставимой с х86 производительности жрет в разы меньше.


Жопорукие программисты есть везде.

только в очень далекой перспективе. Вы просто никогда не сталкивались с большими и высокопроизводительными ДЦ. Там один из главных параметров это производительность на юнит. Еще в 13 году когда я работал в яндексе на тесте под поисковый движок были первые калхеды и они совсем не прижились .
Это неплохое решение под вебсерверы да файлопомойки но не более. Задумайтесь над тем сколько стоит процессор интел. И сколько серверов покупает гугл, ФБ или амазон. Если бы всё было так прекрасно как нам пытается показать АРМ, то эти гиганты уже давно запилили бы кастомные процы на арм ядрах под свои задачи, но они продолжают покупать процы интела.

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


Cortex A9 с лимитом в 4 гига памяти и4 ядра на ноду - неудивительно. Было бы 32-64 ядра на кристалл, + ARMv8 - совсем другое дело было бы.

ссылку можно на тестирование в серверных задачах с измерением площадей и жора и скорости

Площади/жор - http://techreport.com/review/28189/insi ... itecture/2
Реального тестирования сабжа пока по понятным причинам нет (не вышел еще).

вот когда выйдет и затестят то, что даёт выигрыш в серверных задачах в сравнении с х86-тогда и приходите с заявлениями о крутизне армов. который год кушаем заявления (

По скорости А57 имеющиеся уже быстрее силвермонтов (которые лепят в сервера между прочим), и по потреблению экономичнее. И площадь ядра заметно меньше.
А72 - площадь ядра с кешем в 4 раза меньше бродвелла.

Как раз важно. Если это тест, то будь добр выжать все. А не сказать ну и пофиг, что производительность ниже на 20-50%, за то типа это православный компилятор.
вам в машинных командах? Это для людей, что бы было видно что омжно сделать что-то быстрее и медленнее.


Где там у нас тесты производительности? Пока все, что находил не в пользу АРМ.


+100

Ключевое слово - перспективы.

Тогда о чем спор? А по ссылке нет тестов, есть сравнение непонятно в чем. Это маркетологи пока выдают данные, но тестов как таковых нет.

Да-да, в одну машину загрузим картошки в багажник, в другой из салона выбросим все, и будем сравнивать скорость... Бред же, не?


В пользу. В датацентрах интересует производительность на ватт - и армы здесь вне конкуренции. Впрочем, и в производительности на мегагерц они близко к х86.


По ссылке, если вы не заметили, есть инфа и о размере ядер, и об ожидаемом потреблении (или вы считаете что тестовых образцов ядер в кремнии не существует?). Из чего вывод - на том же кристалле в том же тепловом пакете можно разместить в 4 раза больше арм ядер. Которые по производительности будут сопоставимы с х86.

да не правда все это, хватит эту охинею писать. Производительность на ватт важна разве что для распределенных хранилищ. Для высоконагруженных ДЦ намного важнее производительность на юнит. Вы хоть раз видели высоконагруженный дц? Представляете что такое 100 000 серверов в одном месте? Сейчас абсолютно непонятно на кого направленны системы АРМ. Под виртуализацию идут мимо, а значит рынок крупных неIT компаний они просрали. В пиковой производительности тоже идут мимо, остаются только облачные хранилища, но и тут вопрос как оно будет работать с несколькими дисковыми полками.

Производительность на юнит и упирается в проблему теплоотвода от этого всего добра. Иначе бы делал интел склейки по 36 ядер на сокет с тепловыделением в 250Вт. Но пока более 150Вт зионов нет.


С виртуализацией у армов все в порядке.


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

я бы посмотрел как Вы на арме эксченж поднимите или SAP или любой другой корпоративный софт.

я пока не вижу альтернативу интеловским 4-х сокетовым системами с 4 по 12 ядер.

покажите мне такое решение

Скомпиль нам полноценную винду и Exchange под ARM, а мы поднимем. Тоже самое касается и SAP... Мощи A72 вполне на это хватит. Просто разработчики софта пока не подтянулись. А без них полная труба. Будь у тебя хоть на порядок более быстрая процессорная архитетура, но без софта и поддержки она ничто!!!

Так бы и писали - невозможно поделки майкрософта запустить
А SAP/Exchange никакого отношения к виртуализации не имеют. Вообще.


Зионы по 18 ядер уже какбы есть...


http://www.ixbt.com/news/ht/188892 - 96 ядер на платформу (скорее всего - лезвие блэйда, либо 1U половинной длины).