Нет. Это важная часть информации о бенчмарке, позволяет понять что в реальном мире и реальных приложениях результаты могут отличаться.
И оставлено всё нужное. Это как-то делает из реальных приложений синтетические?
Зависит от вмешательств. В целом - да, делает.
Сложно ли? По сути, вам говорят что карьерный экскаватор гораздо лучше подходит для рытья карьеров чем детская лопатка. Ваш ответ «подожду доказательства», «сложно согласиться».
Аналогия не валидна.
Вы хотя бы понимаете, что сортировка массива в изоляции на тестовом массиве не показывает как будет вести себя этот код в реальной ситуации с реальными данными?
Конечно, но вы читали главную страничку сайта, и то не целиком (судя по цитатам дальше). Почитайте whitepaper, плюс код есть в открытом доступе.
В реальной программе тысячи алгоритмов, которые нагружают все блоки процессора. Более того, разные программы нагружают их совершенно по разному. По этому полноценный тест должен включать мегабайты кода и гигабайтные working sets. Только так можно оценить производительность подсистемы памяти, возможности OoO.
В реальной программе все зависит от программы. Такие выводы не верны в общем случаи (большинство софта практически не нагружает FP, весомый кусок софта не будет использовать современный SIMD и так далее). Также как не верен вывод про мегабайты кода и гигабайты working sets. Но с тем, что разные программы нагружают их соверешенно по разному - спорить не буду.
Также есть микроархитектурные тесты, направленные на изучение работы блоков процессора. Coremark не является ни тем, ни другим. «EEMBC’s CoreMark® is a benchmark that measures the performance of microcontrollers (MCUs) and central processing units (CPUs) used in embedded systems.»
Читайте целиком первую страницу, а лучше почитайте их paper.
Как и Интел. Что логично, потому как в SPEC входят популярные приложения.
Из этого я сделаю вывод, что список тестов SPECа вы не видели (или забыли), а утверждение про МЦСТ не читали, как и прошлые статьи. Почитайте, полезно будет.
Про утверждение про Intel - понимаете какое дело - утверждение про МЦСТ было что оптимизации идут не под реальные приложения, а именно под бенчмарки, что есть намек что это немного читы, не дающие особых преимуществ в реальных приложениях. Тут утверждение на совести автора статьи, но у меня как-то нет причин не верить ему. В то же время c Intel/AMD это не так важно, притом сразу по двум причинам - во первых архитектурно, а во вторых - потому что их компиляторы не так чтоб очень популярны (основная масса разработчиков использует сторонние компиляторы, типа gcc, clang, msvc) . Поэтому заявления про то что Intel специально оптимизирует компиляторы чтобы они показывали хорошие результаты в SPEC - мягко говоря необосновано. (читайте: нужно сослаться на что-то)
Для этого есть Octane и Sunspider. Но они показывают связку CPU+VM в первую очередь.
Для этого есть своя куча бенчмарков, да. Но в статье по ссылке некоторые из их прогоняли. И да, показывают связку CPU + VM, но это то что увидит большинство пользователей. Так что увы и ах, это важнее.
Тесты для микроконтроллеров, с которыми вы тут носитесь, ничего не показывают.
Я ношусь не с тестами для микроконтроллеров, а указываю на некорректные заявления человека и излишний карго-культ вокруг SPEC'а в первую очередь.
Если вы зайдёте в процессорный раздел ixbt и будете бряцать coremark-ом, вас… не поймут.
Вы так говорите, как будто на ixbt сидят такие люди с которыми об этом имеет смысл говорить. Простите за некоторый снобизм, но ixbt в текущем его состоянии даже как источник новостей не годится. Соответственно адекватных людей на форуме осталось крайне мало.
Вам. Забыл добавить ссылку. Но несложно найти это место поиском.
Тогда не вырывайте фразы из контекста, пожалуйста и не переходите на личности.
Я не могу написать отдельный пост, потому как могу комментить только 1 раз в день.
Я заметил сильно отрицательную карму, да.
Напомню, что этот тред начался с попытки оспорить заявления автора, который возвёл «микроархитектурную скорость» в абсолют(с)
Да, я помню.
Я читал об этом процессоре в тот же день как появился его анонс. Под высокопроизводительным я подразумеваю текущий уровень лидеров рынка. Уровень старого смартфонного 2-wide чипа Cortex-A73 не является таковым.
Тогда вас явно незатруднит показать у какого смартфонного A73 пусть в синтетике, но 600 GFLOPS (SP). Жду пример. Не помню правда писали ли они какой конкретно бенчмарк использовали, так что хоть какой-то)
"Самое производительное RISC-V ядро в мире — это новое ядро P550 от SiFive. И они только сейчас достали уровень Cortex-A75."
Вы тред перечитайте. Сейчас вы пытаетесь мои слова притянуть к другому аргументу. Там был отдельный момент, где человеку пытались доказать (автор статьи и я потом его поддержал), что OoO ядро уровня Cortex A57 сделать не сложно. Вот отсюда и пример.
Сколько нам открытий чудных…
Вы подменяете корреляцию для конкретной железки в исследовании на казуацию. Там автор статьи в конце обосновывает почему это корреляция и в каких случаях так нельзя делать.
В общем читайте свои же пруфы целиком, пожалуйста.
От того, что SPEC имеет Bzip2 и GCC, а GB имеет LZMA и Clang особо ничего не меняется.
Читайте состав бенчмарков (обоих) целиком. И учтите пару моментов про GB:
Он работает крайне недолго (минуты, а не часы)
Его нельзя оптимизировать в отличии от SPECа (отсюда кстати вполне очевидный вывод - сравнивать с тем, что заявляет вендор - нельзя, потому что вендор всегда применяет максимум оптимизаций, какие смог найти и прменить)
В GB есть тесты, которые умеют использовать аппаратные блоки (то же шифрование, например), в отличии от SPECа.
Результаты GB получены в неизвестных условиях.
Для этого существует статистика. Если есть тысяча корректных результатов и несколько фейковых, то эти фейки легко отбрасываются.
Когда у тебя буквально сотни и тысячи результатов с разбросом в десятки процентов (как это на популярных системах) - какой из них будет корректный? А что делать с тем, что ты в принципе не знаешь какой из результатов на сайте проведен в каких условиях? Кто-то прогонит бенчмарк в холодильнике, кто-то в пустыне и получит два разных числа. У кого-то параллельно будет крутиться какая-нибудь штука и жрать ресурсы и тоже получится кривой результат. Исследование результатов GB с целью выбора наиболее характерного - это отдельная тема и возможна на больших выборках, и то с некоторыми допущениями.
И не поймите меня неправильно - GB достаточно разумный бенчмарк, но у него есть свои области применимости и его результатам стоит верить либо когда авторы публикуют методологию, либо когда ты сам проводишь тестирования и знаешь хорошол среду. Во всех остальных случаях - слишком много мест где можно сделать не так и получить искаженные результаты.
GCC это один из тестов SPEC.
Да, только вот Ваша фраза "Куда уж компилятору GCC до такой сложной задачи!" не вяжется с утверждениями про spec.
Но я рад что вы наконец начали читать о бенчмарках, о которых говорите.
Не совсем, я человеку говорил про применимость бенчмарков много раз, а также человеку много раз указывали (вот не помню я делал или нет, но точно было), что МЦСТ под тот же SPEC делает оптимизации (а значит доверие результатам Эльбруса тут будет никакое). Я наивно понадеялся что человек таки пойдет и почитает про то что пишет и перестанет говорить странные вещи (особенно когда хватает свидетельств странному поведению).
Нет, это клоунада какая-то. SPEC состоит из них, этих самых, реальных приложений.
Авторы SPECа с вами не согласны. Бенчмарк базируется на реальных приложениях, но не обязательно состоит из них (какие-то используют приложение без изменений, в каких-то используются модифицированные версии из которых выкинуто лишнее). Почитайте их FAQ (Q7) и описания самих бенчмарков. И можно при желании найти еще кучу вещей, которые SPEC не покрывает от слова совсем, либо покрывает ограниченно. Это важно понимать и учитывать, вне зависимости от того индустриальный ли это стандарт или нет (тем более мягко говоря не все производители железа публикуют результаты spec'а, в том числе не просто так).
Coremark это настолько примитивная и бессмысленная синтетика, что к реальному софту она не имеет ни малейшего отношения.
Тут тоже сложно согласится, вы сами чуть ниже процитировали что оно тестирует. По вашему - в реальном софте не бывает валидаций, работ со списками и прочего что они тестируют?
И еще раз перечитайте всю ветку. Человек возводит (совершенно некорректно) SPEC в абсолют (как единственный показатель), притом ловко подменяет SPECint на fp когда ему это выгодно. Я изначально на coremark начал ссылаться как на пример, который явно опровергает его заявления.
А, ну и один немаловажный момент касательно конкретно Эльбрусов - ходят слухи что МЦСТ оптимизирует компилятор под нормальное выполнение SPEC'а. В таком контексте доверия к их результатам нет никакого (тем более они не публикуют в нормальном виде, как того требуют правила, эти результаты, поэтому строго говоря ссылаться на SPECи для них в принципе некорректно).
И я напомню, что Coremark по результатм куда больше на Эльбрусе напоминает результаты для более типичных для пользователя юз-кейсов (а я напомню - в современном мире это браузер и js, а в серверном мире - код на интерпретируемых языках или в виртуальных машинах).
Можно. Нужно смотреть результаты тестов, а не одну циферку. Одна циферка это довольно тупо.
Вы вырываете фразу из контекста, либо ответ предназначался не мне, но тогда лучше делайте отдельный пост. Если таки Вы уверены, что отвечали мне, то напомню, что вырывание фраз из контекста может быть отнесено к троллингу, а это запрещено правилами хабра.
Но есть один нюанс(с). Для серверного процессора реальная производительность одного ядра гораздо меньше, потому что загружены все ядра.
Есть не один, а много нюансов. Если подходить не как это делает человек, с которым этот тред был, то начинать надо с рассмотрения конкретно юз-кейса, потому что есть классы задач, где надо брать железо с малым количеством быстрых ядер, есть задачи где надо брать много медленных и целый спектр задач между. Просто взять самый дорогой процессор - не выйдет. Более того, я это и тут и в соседних топиках говорил - важно учитывать как на самом деле работает процессор (в плане буст частот). Современное железо в том числе от AMD - в этом плане сложное и некорректно просто брать базовую частоту и смотреть результаты на ней: AMD имеют тенденцию выдавать в boost'е частоты выше заявленных, например, а также intel'ы и как минимум десктопные amd при отсутствии внешних ограничений не будут опускаться до базовой частоты в принципе. Собственно поэтому реальная частота сильно зависит от условий и нагрузки на различные блоки, а не только ядра. И кстати не надо считать, что серверный процессор всегда загружен под заявзку по ряду причин:
Забить сервер задачами - очень сложно, если делать эффективно. И даже только утилизировать процессор - крайне непросто, если делать это эффективно.
Если делать неэффективно - выбор очень простой - либо недоутилизировать ресурсы (соответственно частоты будут выше), либо жертвовать latency (что не для любых задач в принципе допустимо)
С учетом того что я сказал выше, я думаю, достаточно очевидно что сказать на какой частоте будет работать процессор в среднем - практически невозможно.
А потом - почитайте еще раз аргументацию. Я по-прежнему настаиваю что если хочется оценить потенциал микроархитектуры на 1 ядро то надо брать однопоточный тест на наиболее быстром представителе (а это как минимум декларируемая цель автора). Если хочется получить что-то разумное - по хорошему надо смотреть на однопоток и многопоток как минимум характерных представителей микроархитектуры (более того - там есть место и для нормированных результатов на МГц или ГГц, но применимость у таких результатов очень ограничена) и предоставлять небольшой вагончик результатов.
И это подтверждается отсутствием высокопроизводительных процессоров RISC-V, даже несмотря на доступ к достаточно серьёзным ресурсам.
Высокопроизводительных RISC-V нет (и то спорно, смотрите всю ветку и примеры той же алибабы) в первую очередь потому что версия 1.0 спецификации на ISA была опубликована несколько лет назад.
Потом речь шла не о лидерах, а он процессоре по эффективности сопоставимым с A57, почитайте тред еще раз. Тому же A57 до лидеров как до луны, но вот с нуля до его уровня толпа аспирантов сделала ядро за пару лет (от прошлого in-order до первого out-of-order у boom'ов прошло несколько лет).
GB5 имеет широкий набор тестов и его результаты линейно можно преобразовать в SPEC и обратно, без шума и пыли(с)
С первой частью не спорю - имеет широкий набор тестов. А вот о преобразовании в SPEC и обратно - не согласен. Тесты в GB5 напрямую не конвертируются, как минимум потому что они не совпадают (gb5 не тестирует часть вещей из spec'а, и наоборот). Это раз.
Во вторых - gb как наборы тестов открыты для отправки всем, поэтому детали про условия тестирования неизвестны (также как и есть заведомо недостоверные результаты в базе, строго говоря я открыл топ и первые 7 результатов там - фэйк, а на самом деле таких куда больше), в то время как тесты от производителя предполагают наилучшие условия для их железа (впрочем 100% гарантии отсутствия читов или фэйков тоже нет, но тут производитель железа хотя бы свою репутацию на кон ставит).
Куда уж компилятору GCC до такой сложной задачи!
Отличный уровень аргументации. Посмотрите буквально чуть выше замечание про правила хабра и троллинг.
Ну и вопрос "причем тут GCC?" я пожалуй задавать не буду.
Здесь вы просто выкинули сервера с большим количеством ошибок и после этого считаете среднее. Нормально, чо. Очень качественный подход :D. Очевидно, что на самом деле среднее арифметическое и даже геометрическое будет выше
Моя ошибка в другом - я выкинул 90% серверов где было 0 ошибок.
Хотя на базе этого можно сказать, что космическое излучение вызывает меньше 1 ошибки в 14 месяцев. (Насколько меньше- нужно знать количество серверов).
То есть все ошибки памяти - это строго брак железа.
Ну и среднее арифметическое по опредению бесполезно в такого рода исследованиях, о чем там пара абзацев и есть (оно склонно переоценивать вклад единичных выбросов, то есть в случае статьи это сервера с серьёзно побитой памятью)
Я вам показал уже слайды ARM, где утверждается что быстрее в int и memory workloads. Поэтому обращайтесь к ним за разъяснениями что они имели в виду. В анонсах компании обычно не врут (им это черевато исками).
A73 - это лучшее ядро, которое имеет только два декодера. Но никто больше не смог повторить на 2 декодерах такую высокую производительность.
Я предполагаю что вы забыли включить ссылку на анализ всех когда либо выпущенных 2-issue (если я правильно понимаю что вы подразумеваете под двумя декодерами) процессорами. Надеюсь вы будете так любезны ее предоставить?
Но производительность ниже, чем у A75.
В данном месте я предлагаю вам доказать это на практике и привести какой-нибудь бенчмарк, где A75 показал бы результат выше чем 600 GFLOPS (напомню, столько заявлена производительность 4-х кластерного XT-910 в плавучке).
А ядра Эльбрус уже на том уровне для INT, и даже выше для FP нагрузок.
Вы тут ошибаетесь, это опровергнуто бенчмарками в реальных приложениях, где в ряде нагрузок Эльбрус отстает в разы от равночастотного А57. Ссылки были в треде.
Один бенчмарк - плохо.
Средний результат из 10 нагрузок - уже хорошо. Этого достаточно для точных оценок.
Без понимания что делает бенчмарк и как некоторые производители могут читерить - это чистой воды cargo cult.
Coremark я не доверяю. Известно, что там даже простейшие мипсы без OoO накручивали до высокого уровня. Это слишком специфичный и мелкий бенчмарк, где научились хорошо прокачивать слабые ядра.
Вы можете его исходный код почитать или документацию с обоснованием подхода. Так как Ваше недоверие абсолютно беспочвенно, он хорош для своих задач, надо просто понимать что он показывает (как и spec).
В целом, извините, я уже слегка подустал вам твердить одно и то же. Начинает казаться что вы просто не понимаете о чем ведете речь.
Нет, недопустим. Это разные бенчмарки, совершенно не факт что их оценки будут совпадать.
Как я уже сказал - давайте я тогда возьму какой-то XML Benchmark с того же anandtech где разница между A53 и A57 всего 30% и буду на его базе говорить что разница между A53 и A57 - 30%, следуя вашей же логике.
И единственная надежная оценка производительности для SCR7 - это тот слайд про 20%.
Вы еще забыли слайд с 5.00 Coremark/mhz, например.
Когда не хватает конкретных конечных выводов, надо уметь пользоваться инструментами и данными, которые доступны.
Проблема в том, что вы постоянно забываете границы применимости инструментов и поэтому начинаете делать неверные выводы, но крайне категорично.
Если сомневаетесь в моих выводах, попробуйте самостоятельно определить или найти информацию про то, как отличаются A57 и A53 по производительности.
Сомневаюсь, потому что на практике разница в производительности очень сильно зависит от задачи, до такой степени что покопавшись достаточно вам удастся найти задачу где A53 обгонит равночастотный A57 (это будет узкий класс задач, впрочем).
Поэтому корректное сравнение производительности железа - это крайне сложный процесс и там недостаточно взять один какой-то бенчмарк и в нем все смотреть (причины и я и другие вам уже говорили многократно). Также как делать то, что вы сейчас творите - тоже недопустимо и приведет к неверным выводам.
SCR7- это 2 декодера и OoO.
Извините, я не понимаю что вы имеете в виду под "2 декодера". Используйте пожалуйста общепринятую терминологию.
Я могу попробовать догадаться что вы имеете в виду что он dual-issue, но я тут напомню что это само по себе не является показателем производительности, так как Cortex A73 тоже dual-issue, но при этом быстрее чем A72. Микроархитектуру нельзя упрощать до количества декодируемых команд за такт, к сожалению. Да и в целом только по теоретическим выкладкам анализировать производительность - в корне неверно.
A57 примерно на 70% быстрее, чем A53 на одинаковой частоте.
Тут нужно доказательство что в SpecINT 2017 A57 быстрее чем A53 на 70% на одинаковой частоте. Иначе связать результаты с SCR7 не удастся (разные бенчмарки могут и будут вести себя по-разному, а то следуя вашей же логике я могу привести по такой логике пример с парсингом XML где на равной частоте A53 отстает на 30% от A57)
Тут сравнение Байкала и Raspberry Pi 3B+, который A53:
Изначально речь была про то, что A57 якобы способен на более высокие частоты, чем 1500.
Ну так способен? Способен. Вот A1170 на 2 ГГц работает. Кажется тезис доказан.
Вот те ссылки и показывают, что даже в смартфонах, где важен каждый Вт, потребовалось 1175mV для 1800MHz.
Вы приводите ссылки на другие процессора с другим техпроцессом (а я специально выбирал наиболее высокие частоты для 28 nm TSMC).
Сам A1170 тут уже не играет большой роли для анализа частоты A57.
Вы сами сказали, цитирую:
A1170 работал с повышенным напряжением.
Я и поинтересовался с каким конкретно. Раз вы сделали такое заявление, значит у вас есть точная цифра. Иначе заявление сделано неправомерно (в таком ультимативном ключе). Я по-прежнему жду от Вас точную информацию на ваше утверждение о повышенном напряжении. Притом что то что я сказал примерно там же что-то в духе "да какая разница, вот есть примеры где работает на более высокой частоте, этого достаточно чтобы показать что может" - вы проигнорировали. Так что считаю что с этим тезисом вы согласны.
Повторюсь в последний раз - вы говорили про сложность создания OoO процессора. Вот пример. По эффективности - лучше чем A72. Цифры это явным образом доказывают.
Я написал свое доказательство.
Я не увидел от вас доказательства, только множественные манипуляции данными и попытки поменять подход как только Ваш начал разваливаться.
Эльбрусы выигрывают на FP у Байкалов на одинаковых частотах.
Вам несколько человек уже повторило:
Людям в среднем FP нафиг не сдался. Большинство задач FP блоки не нагружают.
Результаты в реальном мире и в синтетике будут разными (даже если синтетика - хорошая). Посмотрите на результаты в SPECах, и сравните их же с результатами в реальных приложениях. Кстати, тут Coremark показывает числа ближе к тому что увидят пользователи в процессе использования оборудования. И даже про сложности работы с FP вы можете наблюдать на примере Блендера (где разница между 8СВ и М1 практически отсутствует).
Но никакой RISV-V в ближайшее время не выиграет по производительности у ядер Байкалов на одинаковых техпроцессах.
Этому утверждению требуется доказательство.
Лучший перспективный мировой - SiFive P550 - на уровне A75.
Вернитесь к началу обсуждения и посмотрите список. Вы слишком категоричны, поэтому даже фраза "лучший мировой" является ложной (все зависит от того с какой стороны рассматривать).
Ок, хотя вы заявляли про A53 и я все таки хотел бы увидеть цифры от Вас про него. (я в курсе что его не тестируют, но вы сами аппелировали к цифрам).
И таки давайте вернемся к тому что у Байкала-М1 - 4.94 coremark/mhz а у scr7 - 5.0. А то вы что-то прицепились к specint'у сейчас.
EDIT: Читая статью внимательнее я кстати заметил, что вы меня смогли ввести в заблуждение и начать сравнивать несравнимое:
One continuing issue with SPEC CPU 2017 is the Fortran subtests; due to a lacking compiler infrastructure both on iOS and Android, we’re skipping these components entirely for mobile devices. What this means also, is that the total aggregate scores presented here are not comparable to the full suite scores on other platforms, denoted by the (C/C++) subscript in the score descriptions.
Так что я продолжу настаивать на том, что это ваша задача предоставить корректные цифры для SpecINT 2017 для A55 (кстати учтите, это общая фишка Spec тестов на anandtech'е если речь идет про мобильные устройства, что для SpecINT 2006, что для 2017), поэтому из мобильных обзоров результаты сравнивать с платами и не мобильными - нельзя.
Рассматривать можно для любой частоты.
Повторюсь еще раз - вы в одном месте говорите про эффективность архитектуры как бенчмарки нормированные на ГГц, а как вам принесли цифры которые выглядят хорошо то сразу дали заднюю и начали говорить что надо смотреть еще и на частоту.
Определитесь уже. Пока это считать еще одним примером манипуляции с вашей стороны (буквально как только нашелся удобный пример который по вами определенным метрикам выглядел слишком хорошо, вы на ходу поменяли подход и еще отказываетесь это признать).
Но ядер RISV-V с высокой частотой и высокой производительностью вообще нет.
Я напомню, что SonicBOOM я привел в контексте сложности создания эффектинвых OoO ядер. Мне кажется, лучше примера чем OpenSource ядро которое делают в академии несколько аспирантов с научником (для SonicBOOM команда это 3 аспиранта и их научник, но строго говоря они использовали наработки прошлых команд аспирантов по прошлым версиям) и они за несколько лет (между in-order boomv2 и OoO sonicboom'ом - 3 года) сделали ядро эффективнее чем Cortex A57 (вы сами согласились про IPC). Кажется вполне подтверждает тезис про то что это немного легче, чем вы пытались это выставить.
В статье написали только про 1 GHz у SonicBOOM на FinFET
В статье строго говоря написано что они пытались сматчить частоты с BOOMv2 и это у них получилось. Строго говоря у них не сказано up to сколько они могут достичь.
А Finfet - это 16 нм, как минимум
Если вы чуть-чуть покопаетесь, то найдете что они использовали 22нм техпроцесс для синтеза (это есть на гитхабе в одном из репозиториев в обсуждении как достичь больших тактовых частот на SMIC 40nm, но ссылку давать вам не буду, так как от вас я достаточно много манипуляций информацией уже видел).
Но в других источниках есть и про 0.9 В у Эльбрус-8СВ. Вероятно разные экземпляры отличаются по качеству, и поэтому могут завышать до 1.0В, чтобы добиться стабильности.
Я подожду пока вы приведете ссылку где это будет объяснено. Пока буду довольствоваться ссылкой выше.
Ссылку на pdf байкала все еще жду.
Напряжение ядер A57 и частоты есть тут:
Там есть для Exynos 5433, но не для A1170 о котором речь. К тому же для самсунговского 28нм техпроцесса, который считается хуже чем TSMC 28nm (в целом считается что самсунговские техпроцессы заметно хуже по ряду показателей чем аналогичные нанометры на TSMC).
Где-то были графики и для других техпроцессов. Для байкаловского напряжения 0.95В там и должно быть 1.5 GHz на 28 нм.
Я предпочту все еще подождать пока вы ссылку найдете и принесете. А то простите, но я вам на слово не верю (слишком много попыток манипуляции данными с вашей стороны тут было).
Ну посмотрите чем типично люди занимаются (как на работе так и дома). Вот обобщенно-собирательный образ и будет этим "типичные задачи" (строго говоря большая часть это браузер и js для среднестатистического юзера).
И я не говорил что А57 их будет хорошо тянуть, просто 8СВ будет еще хуже.
Я подожду ссылок с чиселками, чтобы убедиться. На картинки про Байкал и Эльбрус - тоже. Без ссылок и чисел, кажется, говорить не о чем (тем более вторую часть вы снова проигнорировали).
A73 делали не ради высокой производительности, а ради низкого потребления, А основные производительные ядра были A57, A72 и A76.
Ваши заявления расходятся с заявлениями самого ARM. Не читайте русских газет, читайте нормальные источники, если хотите вменяемый анализ.
Собственно по ссылке есть слайды презентации Cortex A73 и там завялялось "Up to 30% higher performance" в сравнении с A72 (на практике имея в виду подсистему памяти, но 5-10% в других бенчмарках было в налчии). Шаг был меньше чем между A57 -> A72, это правда (и тут правда причина в том, что в мобильных телефонах A57 получился тем еще кипятильником), но говорить что A73 было не основным производительным ядром - это в высшей степени некорректно (также как и исключать A75 из этого списка).
Нет. Это важная часть информации о бенчмарке, позволяет понять что в реальном мире и реальных приложениях результаты могут отличаться.
Зависит от вмешательств. В целом - да, делает.
Аналогия не валидна.
Конечно, но вы читали главную страничку сайта, и то не целиком (судя по цитатам дальше). Почитайте whitepaper, плюс код есть в открытом доступе.
В реальной программе все зависит от программы. Такие выводы не верны в общем случаи (большинство софта практически не нагружает FP, весомый кусок софта не будет использовать современный SIMD и так далее). Также как не верен вывод про мегабайты кода и гигабайты working sets. Но с тем, что разные программы нагружают их соверешенно по разному - спорить не буду.
Читайте целиком первую страницу, а лучше почитайте их paper.
Из этого я сделаю вывод, что список тестов SPECа вы не видели (или забыли), а утверждение про МЦСТ не читали, как и прошлые статьи. Почитайте, полезно будет.
Про утверждение про Intel - понимаете какое дело - утверждение про МЦСТ было что оптимизации идут не под реальные приложения, а именно под бенчмарки, что есть намек что это немного читы, не дающие особых преимуществ в реальных приложениях. Тут утверждение на совести автора статьи, но у меня как-то нет причин не верить ему. В то же время c Intel/AMD это не так важно, притом сразу по двум причинам - во первых архитектурно, а во вторых - потому что их компиляторы не так чтоб очень популярны (основная масса разработчиков использует сторонние компиляторы, типа gcc, clang, msvc) . Поэтому заявления про то что Intel специально оптимизирует компиляторы чтобы они показывали хорошие результаты в SPEC - мягко говоря необосновано. (читайте: нужно сослаться на что-то)
Для этого есть своя куча бенчмарков, да. Но в статье по ссылке некоторые из их прогоняли. И да, показывают связку CPU + VM, но это то что увидит большинство пользователей. Так что увы и ах, это важнее.
Я ношусь не с тестами для микроконтроллеров, а указываю на некорректные заявления человека и излишний карго-культ вокруг SPEC'а в первую очередь.
Вы так говорите, как будто на ixbt сидят такие люди с которыми об этом имеет смысл говорить. Простите за некоторый снобизм, но ixbt в текущем его состоянии даже как источник новостей не годится. Соответственно адекватных людей на форуме осталось крайне мало.
Тогда не вырывайте фразы из контекста, пожалуйста и не переходите на личности.
Я заметил сильно отрицательную карму, да.
Да, я помню.
Тогда вас явно незатруднит показать у какого смартфонного A73 пусть в синтетике, но 600 GFLOPS (SP). Жду пример. Не помню правда писали ли они какой конкретно бенчмарк использовали, так что хоть какой-то)
Вы тред перечитайте. Сейчас вы пытаетесь мои слова притянуть к другому аргументу. Там был отдельный момент, где человеку пытались доказать (автор статьи и я потом его поддержал), что OoO ядро уровня Cortex A57 сделать не сложно. Вот отсюда и пример.
Вы подменяете корреляцию для конкретной железки в исследовании на казуацию. Там автор статьи в конце обосновывает почему это корреляция и в каких случаях так нельзя делать.
В общем читайте свои же пруфы целиком, пожалуйста.
Читайте состав бенчмарков (обоих) целиком. И учтите пару моментов про GB:
Он работает крайне недолго (минуты, а не часы)
Его нельзя оптимизировать в отличии от SPECа (отсюда кстати вполне очевидный вывод - сравнивать с тем, что заявляет вендор - нельзя, потому что вендор всегда применяет максимум оптимизаций, какие смог найти и прменить)
В GB есть тесты, которые умеют использовать аппаратные блоки (то же шифрование, например), в отличии от SPECа.
Результаты GB получены в неизвестных условиях.
Когда у тебя буквально сотни и тысячи результатов с разбросом в десятки процентов (как это на популярных системах) - какой из них будет корректный? А что делать с тем, что ты в принципе не знаешь какой из результатов на сайте проведен в каких условиях? Кто-то прогонит бенчмарк в холодильнике, кто-то в пустыне и получит два разных числа. У кого-то параллельно будет крутиться какая-нибудь штука и жрать ресурсы и тоже получится кривой результат. Исследование результатов GB с целью выбора наиболее характерного - это отдельная тема и возможна на больших выборках, и то с некоторыми допущениями.
И не поймите меня неправильно - GB достаточно разумный бенчмарк, но у него есть свои области применимости и его результатам стоит верить либо когда авторы публикуют методологию, либо когда ты сам проводишь тестирования и знаешь хорошол среду. Во всех остальных случаях - слишком много мест где можно сделать не так и получить искаженные результаты.
Да, только вот Ваша фраза "Куда уж компилятору GCC до такой сложной задачи!" не вяжется с утверждениями про spec.
Но я рад что вы наконец начали читать о бенчмарках, о которых говорите.
Не совсем, я человеку говорил про применимость бенчмарков много раз, а также человеку много раз указывали (вот не помню я делал или нет, но точно было), что МЦСТ под тот же SPEC делает оптимизации (а значит доверие результатам Эльбруса тут будет никакое). Я наивно понадеялся что человек таки пойдет и почитает про то что пишет и перестанет говорить странные вещи (особенно когда хватает свидетельств странному поведению).
Авторы SPECа с вами не согласны. Бенчмарк базируется на реальных приложениях, но не обязательно состоит из них (какие-то используют приложение без изменений, в каких-то используются модифицированные версии из которых выкинуто лишнее). Почитайте их FAQ (Q7) и описания самих бенчмарков. И можно при желании найти еще кучу вещей, которые SPEC не покрывает от слова совсем, либо покрывает ограниченно. Это важно понимать и учитывать, вне зависимости от того индустриальный ли это стандарт или нет (тем более мягко говоря не все производители железа публикуют результаты spec'а, в том числе не просто так).
Тут тоже сложно согласится, вы сами чуть ниже процитировали что оно тестирует. По вашему - в реальном софте не бывает валидаций, работ со списками и прочего что они тестируют?
И еще раз перечитайте всю ветку. Человек возводит (совершенно некорректно) SPEC в абсолют (как единственный показатель), притом ловко подменяет SPECint на fp когда ему это выгодно. Я изначально на coremark начал ссылаться как на пример, который явно опровергает его заявления.
А, ну и один немаловажный момент касательно конкретно Эльбрусов - ходят слухи что МЦСТ оптимизирует компилятор под нормальное выполнение SPEC'а. В таком контексте доверия к их результатам нет никакого (тем более они не публикуют в нормальном виде, как того требуют правила, эти результаты, поэтому строго говоря ссылаться на SPECи для них в принципе некорректно).
И я напомню, что Coremark по результатм куда больше на Эльбрусе напоминает результаты для более типичных для пользователя юз-кейсов (а я напомню - в современном мире это браузер и js, а в серверном мире - код на интерпретируемых языках или в виртуальных машинах).
Вы вырываете фразу из контекста, либо ответ предназначался не мне, но тогда лучше делайте отдельный пост. Если таки Вы уверены, что отвечали мне, то напомню, что вырывание фраз из контекста может быть отнесено к троллингу, а это запрещено правилами хабра.
Есть не один, а много нюансов. Если подходить не как это делает человек, с которым этот тред был, то начинать надо с рассмотрения конкретно юз-кейса, потому что есть классы задач, где надо брать железо с малым количеством быстрых ядер, есть задачи где надо брать много медленных и целый спектр задач между. Просто взять самый дорогой процессор - не выйдет. Более того, я это и тут и в соседних топиках говорил - важно учитывать как на самом деле работает процессор (в плане буст частот). Современное железо в том числе от AMD - в этом плане сложное и некорректно просто брать базовую частоту и смотреть результаты на ней: AMD имеют тенденцию выдавать в boost'е частоты выше заявленных, например, а также intel'ы и как минимум десктопные amd при отсутствии внешних ограничений не будут опускаться до базовой частоты в принципе. Собственно поэтому реальная частота сильно зависит от условий и нагрузки на различные блоки, а не только ядра. И кстати не надо считать, что серверный процессор всегда загружен под заявзку по ряду причин:
Забить сервер задачами - очень сложно, если делать эффективно. И даже только утилизировать процессор - крайне непросто, если делать это эффективно.
Если делать неэффективно - выбор очень простой - либо недоутилизировать ресурсы (соответственно частоты будут выше), либо жертвовать latency (что не для любых задач в принципе допустимо)
С учетом того что я сказал выше, я думаю, достаточно очевидно что сказать на какой частоте будет работать процессор в среднем - практически невозможно.
А потом - почитайте еще раз аргументацию. Я по-прежнему настаиваю что если хочется оценить потенциал микроархитектуры на 1 ядро то надо брать однопоточный тест на наиболее быстром представителе (а это как минимум декларируемая цель автора). Если хочется получить что-то разумное - по хорошему надо смотреть на однопоток и многопоток как минимум характерных представителей микроархитектуры (более того - там есть место и для нормированных результатов на МГц или ГГц, но применимость у таких результатов очень ограничена) и предоставлять небольшой вагончик результатов.
Высокопроизводительных RISC-V нет (и то спорно, смотрите всю ветку и примеры той же алибабы) в первую очередь потому что версия 1.0 спецификации на ISA была опубликована несколько лет назад.
Потом речь шла не о лидерах, а он процессоре по эффективности сопоставимым с A57, почитайте тред еще раз. Тому же A57 до лидеров как до луны, но вот с нуля до его уровня толпа аспирантов сделала ядро за пару лет (от прошлого in-order до первого out-of-order у boom'ов прошло несколько лет).
С первой частью не спорю - имеет широкий набор тестов. А вот о преобразовании в SPEC и обратно - не согласен. Тесты в GB5 напрямую не конвертируются, как минимум потому что они не совпадают (gb5 не тестирует часть вещей из spec'а, и наоборот). Это раз.
Во вторых - gb как наборы тестов открыты для отправки всем, поэтому детали про условия тестирования неизвестны (также как и есть заведомо недостоверные результаты в базе, строго говоря я открыл топ и первые 7 результатов там - фэйк, а на самом деле таких куда больше), в то время как тесты от производителя предполагают наилучшие условия для их железа (впрочем 100% гарантии отсутствия читов или фэйков тоже нет, но тут производитель железа хотя бы свою репутацию на кон ставит).
Отличный уровень аргументации. Посмотрите буквально чуть выше замечание про правила хабра и троллинг.
Ну и вопрос "причем тут GCC?" я пожалуй задавать не буду.
Моя ошибка в другом - я выкинул 90% серверов где было 0 ошибок.
Хотя на базе этого можно сказать, что космическое излучение вызывает меньше 1 ошибки в 14 месяцев. (Насколько меньше- нужно знать количество серверов).
То есть все ошибки памяти - это строго брак железа.
Ну и среднее арифметическое по опредению бесполезно в такого рода исследованиях, о чем там пара абзацев и есть (оно склонно переоценивать вклад единичных выбросов, то есть в случае статьи это сервера с серьёзно побитой памятью)
Я вам показал уже слайды ARM, где утверждается что быстрее в int и memory workloads. Поэтому обращайтесь к ним за разъяснениями что они имели в виду. В анонсах компании обычно не врут (им это черевато исками).
Я предполагаю что вы забыли включить ссылку на анализ всех когда либо выпущенных 2-issue (если я правильно понимаю что вы подразумеваете под двумя декодерами) процессорами. Надеюсь вы будете так любезны ее предоставить?
В данном месте я предлагаю вам доказать это на практике и привести какой-нибудь бенчмарк, где A75 показал бы результат выше чем 600 GFLOPS (напомню, столько заявлена производительность 4-х кластерного XT-910 в плавучке).
Вы тут ошибаетесь, это опровергнуто бенчмарками в реальных приложениях, где в ряде нагрузок Эльбрус отстает в разы от равночастотного А57. Ссылки были в треде.
Без понимания что делает бенчмарк и как некоторые производители могут читерить - это чистой воды cargo cult.
Вы можете его исходный код почитать или документацию с обоснованием подхода. Так как Ваше недоверие абсолютно беспочвенно, он хорош для своих задач, надо просто понимать что он показывает (как и spec).
В целом, извините, я уже слегка подустал вам твердить одно и то же. Начинает казаться что вы просто не понимаете о чем ведете речь.
Нет, недопустим. Это разные бенчмарки, совершенно не факт что их оценки будут совпадать.
Как я уже сказал - давайте я тогда возьму какой-то XML Benchmark с того же anandtech где разница между A53 и A57 всего 30% и буду на его базе говорить что разница между A53 и A57 - 30%, следуя вашей же логике.
Вы еще забыли слайд с 5.00 Coremark/mhz, например.
Проблема в том, что вы постоянно забываете границы применимости инструментов и поэтому начинаете делать неверные выводы, но крайне категорично.
Сомневаюсь, потому что на практике разница в производительности очень сильно зависит от задачи, до такой степени что покопавшись достаточно вам удастся найти задачу где A53 обгонит равночастотный A57 (это будет узкий класс задач, впрочем).
Поэтому корректное сравнение производительности железа - это крайне сложный процесс и там недостаточно взять один какой-то бенчмарк и в нем все смотреть (причины и я и другие вам уже говорили многократно). Также как делать то, что вы сейчас творите - тоже недопустимо и приведет к неверным выводам.
Извините, я не понимаю что вы имеете в виду под "2 декодера". Используйте пожалуйста общепринятую терминологию.
Я могу попробовать догадаться что вы имеете в виду что он dual-issue, но я тут напомню что это само по себе не является показателем производительности, так как Cortex A73 тоже dual-issue, но при этом быстрее чем A72. Микроархитектуру нельзя упрощать до количества декодируемых команд за такт, к сожалению. Да и в целом только по теоретическим выкладкам анализировать производительность - в корне неверно.
Смотрите на слайды по приведенной мной ссылке, там EEMBC, nBench и производительность в плавучке.
В SpecINT 2017
Тут нужно доказательство что в SpecINT 2017 A57 быстрее чем A53 на 70% на одинаковой частоте. Иначе связать результаты с SCR7 не удастся (разные бенчмарки могут и будут вести себя по-разному, а то следуя вашей же логике я могу привести по такой логике пример с парсингом XML где на равной частоте A53 отстает на 30% от A57)
Перенос результатов другого бенчмарка в принципе недопустим. Поэтому если приводите geekbench 5 - покажите его результаты для SCR7
Ну так способен? Способен. Вот A1170 на 2 ГГц работает. Кажется тезис доказан.
Вы приводите ссылки на другие процессора с другим техпроцессом (а я специально выбирал наиболее высокие частоты для 28 nm TSMC).
Вы сами сказали, цитирую:
Я и поинтересовался с каким конкретно. Раз вы сделали такое заявление, значит у вас есть точная цифра. Иначе заявление сделано неправомерно (в таком ультимативном ключе). Я по-прежнему жду от Вас точную информацию на ваше утверждение о повышенном напряжении. Притом что то что я сказал примерно там же что-то в духе "да какая разница, вот есть примеры где работает на более высокой частоте, этого достаточно чтобы показать что может" - вы проигнорировали. Так что считаю что с этим тезисом вы согласны.
Тоже подожду доказательства.
Повторюсь в последний раз - вы говорили про сложность создания OoO процессора. Вот пример. По эффективности - лучше чем A72. Цифры это явным образом доказывают.
Я не увидел от вас доказательства, только множественные манипуляции данными и попытки поменять подход как только Ваш начал разваливаться.
Вам несколько человек уже повторило:
Людям в среднем FP нафиг не сдался. Большинство задач FP блоки не нагружают.
Результаты в реальном мире и в синтетике будут разными (даже если синтетика - хорошая). Посмотрите на результаты в SPECах, и сравните их же с результатами в реальных приложениях. Кстати, тут Coremark показывает числа ближе к тому что увидят пользователи в процессе использования оборудования. И даже про сложности работы с FP вы можете наблюдать на примере Блендера (где разница между 8СВ и М1 практически отсутствует).
Этому утверждению требуется доказательство.
Вернитесь к началу обсуждения и посмотрите список. Вы слишком категоричны, поэтому даже фраза "лучший мировой" является ложной (все зависит от того с какой стороны рассматривать).
Для меня характеристики по прошлой ссылке выглядят более официально, чем отрывок из какой-то статьи непонятно когда писавшийся.
Я повторю еще раз - вы заявили что для A1170 оно больше. Приведите цифру с источником. Не надо, пожалуйста, пихать сюда Smasung'овские процессоры.
Ок, хотя вы заявляли про A53 и я все таки хотел бы увидеть цифры от Вас про него. (я в курсе что его не тестируют, но вы сами аппелировали к цифрам).
И таки давайте вернемся к тому что у Байкала-М1 - 4.94 coremark/mhz а у scr7 - 5.0. А то вы что-то прицепились к specint'у сейчас.
EDIT: Читая статью внимательнее я кстати заметил, что вы меня смогли ввести в заблуждение и начать сравнивать несравнимое:
Так что я продолжу настаивать на том, что это ваша задача предоставить корректные цифры для SpecINT 2017 для A55 (кстати учтите, это общая фишка Spec тестов на anandtech'е если речь идет про мобильные устройства, что для SpecINT 2006, что для 2017), поэтому из мобильных обзоров результаты сравнивать с платами и не мобильными - нельзя.
Повторюсь еще раз - вы в одном месте говорите про эффективность архитектуры как бенчмарки нормированные на ГГц, а как вам принесли цифры которые выглядят хорошо то сразу дали заднюю и начали говорить что надо смотреть еще и на частоту.
Определитесь уже. Пока это считать еще одним примером манипуляции с вашей стороны (буквально как только нашелся удобный пример который по вами определенным метрикам выглядел слишком хорошо, вы на ходу поменяли подход и еще отказываетесь это признать).
Я напомню, что SonicBOOM я привел в контексте сложности создания эффектинвых OoO ядер. Мне кажется, лучше примера чем OpenSource ядро которое делают в академии несколько аспирантов с научником (для SonicBOOM команда это 3 аспиранта и их научник, но строго говоря они использовали наработки прошлых команд аспирантов по прошлым версиям) и они за несколько лет (между in-order boomv2 и OoO sonicboom'ом - 3 года) сделали ядро эффективнее чем Cortex A57 (вы сами согласились про IPC). Кажется вполне подтверждает тезис про то что это немного легче, чем вы пытались это выставить.
В статье строго говоря написано что они пытались сматчить частоты с BOOMv2 и это у них получилось. Строго говоря у них не сказано up to сколько они могут достичь.
Если вы чуть-чуть покопаетесь, то найдете что они использовали 22нм техпроцесс для синтеза (это есть на гитхабе в одном из репозиториев в обсуждении как достичь больших тактовых частот на SMIC 40nm, но ссылку давать вам не буду, так как от вас я достаточно много манипуляций информацией уже видел).
Я подожду пока вы приведете ссылку где это будет объяснено. Пока буду довольствоваться ссылкой выше.
Ссылку на pdf байкала все еще жду.
Там есть для Exynos 5433, но не для A1170 о котором речь. К тому же для самсунговского 28нм техпроцесса, который считается хуже чем TSMC 28nm (в целом считается что самсунговские техпроцессы заметно хуже по ряду показателей чем аналогичные нанометры на TSMC).
Я предпочту все еще подождать пока вы ссылку найдете и принесете. А то простите, но я вам на слово не верю (слишком много попыток манипуляции данными с вашей стороны тут было).
Ну посмотрите чем типично люди занимаются (как на работе так и дома). Вот обобщенно-собирательный образ и будет этим "типичные задачи" (строго говоря большая часть это браузер и js для среднестатистического юзера).
И я не говорил что А57 их будет хорошо тянуть, просто 8СВ будет еще хуже.
В типичных для людей задачах - и его тоже, в несколько раз притом.
Вы привели ссылки на график, где SpecInt на A57 и A72 прогоняли авторы Maxion'а, а для A55, A75, A76 они взяли estimate числа от аналитиков.
Вы всерьез считаете, что это адекватный надежный источник данных?
Тем не менее, выкидывать A73, A74, A75, A78, X1, X2 и A710 из списка "основных" ядер в высшей степени некорректно, кажется я ясно пояснил почему.
Приведите число, пожалуйста со ссылкой на источник.
Картинка кстати не в тему, там не тест, а цифра от балды (aka Estimate). К тому же вы говорили про SpecINT 2017, а привели картинку с SpecINT 2006.
Я правильно понимаю, что вы решили посреди дискуссии согласится с тем, что надо смотреть на производительность на максимально возможной частоте?
Я подожду ссылок с чиселками, чтобы убедиться. На картинки про Байкал и Эльбрус - тоже. Без ссылок и чисел, кажется, говорить не о чем (тем более вторую часть вы снова проигнорировали).
Блин, я что-то когда читал этот момент упустил. Спасибо за поправку. Так что да, еще меньше выходит.
Ваши заявления расходятся с заявлениями самого ARM. Не читайте русских газет, читайте нормальные источники, если хотите вменяемый анализ.
Собственно по ссылке есть слайды презентации Cortex A73 и там завялялось "Up to 30% higher performance" в сравнении с A72 (на практике имея в виду подсистему памяти, но 5-10% в других бенчмарках было в налчии). Шаг был меньше чем между A57 -> A72, это правда (и тут правда причина в том, что в мобильных телефонах A57 получился тем еще кипятильником), но говорить что A73 было не основным производительным ядром - это в высшей степени некорректно (также как и исключать A75 из этого списка).