Comments 86
А почему вы прересчитываете на ГГц процессора? У компьютеров и память разная. Тот же 2й тест — я думаю он упирается не в частоту а в память.
Мы не учитывали различия по памяти, поскольку у Эльбрус-4С и Core i7 не только разная скорость ОЗУ, но и разная структура кэш-памяти, алгоритмы кэширования, есть array prefetch buffer на Эльбрус. Поэтому мы использовали более наглядную и простую характеристику.
У них не только память разная, у них разные архитектуры. Было бы удивительно, если бы архитектура VLIW давала меньшую производительность на такт в задачах, которые явно хорошо параллелятся.
Логичнее сравнивать отношение производительности к потребляемой мощности, но Эльбрус проиграет.
А Вы учитываете, что у современных Intel частота сильно плавающая? К примеру у меня на i5-6600K она при небольшой нагрузке опускается до 800 МГц, в то время как при нагрузке включается еще и TurboBoost.
Это распространенное заблуждение, TDP у Intel очень часто далёк от реального потребления. К примеру, у того же i5-6600K тоже TDP 91 Вт, получается они одинаково «едят»? Так что сравнивать по TDP бессмысленно. Тем более, что TDP для Intel учитывает ещё и встроенную видяху, чего у Эльбруса нет. Вы бы ради интереса взяли померили потребление от розетки для системы
и в два раза меньшей потребляемой мощности по сравнению с Core i7
Это распространенное заблуждение, TDP у Intel очень часто далёк от реального потребления. К примеру, у того же i5-6600K тоже TDP 91 Вт, получается они одинаково «едят»? Так что сравнивать по TDP бессмысленно. Тем более, что TDP для Intel учитывает ещё и встроенную видяху, чего у Эльбруса нет. Вы бы ради интереса взяли померили потребление от розетки для системы
Действительно, энергопотребление мы сравнивали только по TDP, что не совсем корректно, и было бы интересно измерить реальную потребляемую мощность. Возможно мы проведем и такой эксперимент. TurboBoost при замерах мы отключили.
TDP для Intel учитывает ещё и встроенную видяху
Он вообще не понятно что учитывает, потому что мой 4790K по паспорту имеет TDP 88 Вт, а по факту в FPU stress test потребляет 120 Вт. И это без учета встроенного видео.
Из вики: Требования по теплоотводу (TDP) показывают не максимальное теоретическое тепловыделение процессора, а лишь требования к производительности системы охлаждения.
FPU stress test это не типичная нагрузка для процессора, поэтому давно не указывают максимальное потребление процессора. Он его почти никогда не достигает, кроме как в таких тестах, в которых нет ожидания памяти и вся работа только через кэш или даже просто регистры, т.е. никаких простоев, максимум нагрузки.
FPU stress test это не типичная нагрузка для процессора, поэтому давно не указывают максимальное потребление процессора. Он его почти никогда не достигает, кроме как в таких тестах, в которых нет ожидания памяти и вся работа только через кэш или даже просто регистры, т.е. никаких простоев, максимум нагрузки.
Есть же штатные тулы для сравниения быстродействия — SPEC 2000/2006 CPU, зачем изобретать синтетические велосипеды?
+ Все примеры на счетные циклы, что явно не слишком репрезентативно.
+ Среди примеров нет ни одного с ветвлениями внутри цикла.
P.S. Всегда умиляла любовь поклонников Эльбруса нормировать показатели на частоту.
+ Все примеры на счетные циклы, что явно не слишком репрезентативно.
+ Среди примеров нет ни одного с ветвлениями внутри цикла.
P.S. Всегда умиляла любовь поклонников Эльбруса нормировать показатели на частоту.
Цель данного поста не сравнить производительность Эльбрус и Core i7, для этого наши примеры не очень подходят. Мы хотели показать, что несмотря на VLIW-архитектуру Эльбруса и написанный специально для нее оптимизирующий компилятор, простые методы оптимизации на нем работают также, как и на Core i7, и в этом смысле разработка программ для Эльбруса не требует дополнительных затрат на специфичную оптимизацию.
Цель данного поста не сравнить производительность Эльбрус и Core i7
Ага, и в каждом примере шаблонные строчки
Пример 1. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает значительно эффективнее Core i7 с учетом отношения частот.
Пример 2. Кроме того, Эльбрус работает эффективнее Core i7 с учетом отношения частот.
Пример 3. Кроме того, заметно, что Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.
Пример 4.Кроме того, 32-битная команда popcnt на Эльбрусе работает быстрее, чем на Core i7 с учетом отношения частот. А вот в 64-битной случае времена работы на Core i7 и Эльбрусе сравнялись.
Пример 5 Код с зависимостью по данным отработал на Эльбрусе медленнее, чем на Core i7 в пересчете на 1 ГГц, а вот без зависимости Эльбрус всего в 4 раза медленнее Core i7 (при различии частот в 5 раз).
Пример 6 Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.
Кстати, тут неправда. Вы подменяете сравнение производительности процессоров сравнением мощности ядер, но у i7 8 виртуальных ядер и при большом количестве потоков он работает в 2.6*2 = 5.2 раз быстрее. (например, в параллельном варианте для n=32 у вас время больше 10 сек для Эльбруса и всего лишь 2 сек для i7)
рассмотренных элементарных примерах для оптимизации кода Эльбрус показал себя просто замечательно с учетом тактовой частоты в 800 МГц и в два раза меньшей потребляемой мощности по сравнению с Core i7
Вы всю статью хвалите Эльбрус и во все таблицы пихаете отнормированные на частоту числа, вы бы ещё на "подгоночный коэффициент" их домножали, оно быть хоть честнее было.
Если бы целью было сравнение эффектов от оптимизаций, можно было бы неоптимизированный вариант брать за эталон и с ним уже сравнивать: "вот, такие-то действия ускоряют программу в 9 раз на i7 и в 20 раз на Эльбрусе".
В том то и вопрос, что данные тесты изначально достаточно неплохо ложатся на VLIW. Если говорить про SPEC, то там есть примеры другого класса, например gcc или perl, где поток управления превалирует над числодробительными цикловыми вычислениями.
По Эльбрус-4С уже опубликовано немало обзоров с результатами более или менее стандартных тестов производительности, 7-zip сжатие/распаковка, например. Для Эльбрус-2С+ есть результаты на SPEC 2000 на сайте МЦСТ. Поскольку мы занимаемся обработкой изображений и распознаванием, нам интереснее рассматривать профильные для нас задачи, которые довольно просто распараллеливаются и хорошо подходят для VLIW-архитектур.
А что скажет конечный пользователь системы?
Ничего страшного что я подождал результата в 2,6-10 раз дольше на Эльбрусе, чем на iCore, ведь в переводе на частоту, Эльбрус всё равно быстрее?
Вполне возможно что для оцифровки литерратуры советского периода в фоновом режиме Эльбрус покажет себя замечательно. Ведь возможно энерго-эффективнее справится с задачей.
Но если говорить о рамках пограничного контроля в аэропортах с большим потоком — то уж лучше iCore. Любой простой и любая задержка стоят денег.
Брюссель
Осло
Надо сравнивать деньги и время, необходимые для расчета одной и той же задачи.
Мне из статьи не стало понятнее, существуют ли задачи, в которыхсовокупная стоимость владения…
Электричество = деньги.
Железо = деньги.
Время = деньги.
Мне из статьи не стало понятнее, существуют ли задачи, в которых
Электричество = деньги.
Железо = деньги.
Время = деньги.
Я всё жду того когда они откроют свои форки gcc и glibc как того требует лицензия. Тогда и будет понятнее про оптимизации и прочее.
А кто говорил про gcc на Эльбрусе? У них свой компилятор.
Так только слухи и есть. Как раз пишут что у них форк gcc. Хотя сейчас уже логичнее llvm пилить во всю.
У них свой компилятор, именуют они его не иначе как lcc. Фронтенд у него с gcc по большей части совместим, бэкенд свой. По glibc же напишите им запрос соответствующий, будет интересно узнать что напишут в ответ.
lcc и есть форк gcc даже если не полностью то куски от туда они взяли… GPL лицензия требует открытие всего проекта если вы хоть что то взяли от GPL.
Про glibc, gcc они уже отвечали что "мы типо пилим для военных и мы чихали на ваш GPL".
Кроме того они правили Mesa, DRM и т.д. то же без фидбека сообществу. Короче пока они будут красть чужой труд я однозначно против их конторы. (пару раз был у них в гостях к слову пока учился в универе)
У них модифицированный lcc, а не gcc.
По слухам, ллвм они пилят, но пока все в очень ранней стадии
Им надо всё открывать и выпускать(думаю не без гос.поддержки) что-то вроде Raspberry Pi с минимальным процессором, ну и не дорого распродать. Тогда в стране появятся люди знакомые с архитектурой. И дело с инструментарием пойдёт и развитие побыстрее. Наверно. Иначе это всё так и останется в печальном состоянии, а жаль.Свой процессор это здорово, я бы и сам поковырялся.
Замечание по таблице. Сейчас данные располагаются так:
Эльбрус абс | Эльбрус/ГГц | Intel абс | Intel/ГГц
Но ведь сравнение идет между Эльбрусом и Intel, а не между Эльбрус абс и Эльбрус/ГГц. Последнее всегда дает отношение 0.8, зачем держать эти колонки вместе. Правильный порядок:
Эльбрус абс | Intel абс | Эльбрус/ГГц | Intel/ГГц
Что касается перерасчета на ГГц. А зачем это вообще? Ну так, забавный факт, который не имеет реального применения. У вас есть задача, есть ресурсы: кол-во процессоров/денег на процессоры либо киловатты энергии. Т.е. имеет смысл знать реальное время и перерасчет на стоимость или потребление. Но перерасчет на какие-то внутренние технические характеристики ничего полезного не дает.
Эльбрус абс | Эльбрус/ГГц | Intel абс | Intel/ГГц
Но ведь сравнение идет между Эльбрусом и Intel, а не между Эльбрус абс и Эльбрус/ГГц. Последнее всегда дает отношение 0.8, зачем держать эти колонки вместе. Правильный порядок:
Эльбрус абс | Intel абс | Эльбрус/ГГц | Intel/ГГц
Что касается перерасчета на ГГц. А зачем это вообще? Ну так, забавный факт, который не имеет реального применения. У вас есть задача, есть ресурсы: кол-во процессоров/денег на процессоры либо киловатты энергии. Т.е. имеет смысл знать реальное время и перерасчет на стоимость или потребление. Но перерасчет на какие-то внутренние технические характеристики ничего полезного не дает.
Хотел бы заметить, что метрика на МГц или ГГц более правильная чем просто метрика производительности для процессоров изготовленных по разным топонормам, ведь очевидно, что переход на новую топонорму сделает процессор более производительным, поэтому на МГц это более точная метрика, но она всё равно очень долека от правды. К примеру, такой комментарий в аналогичной статье: https://habrahabr.ru/post/307512/#comment_9748816
Народу, безусловно, интересен потенциал архитектуры, а не конкретно этот камень, поэтому было бы логичным сравнить с топовым процессором от Intel на архитектуре 65нм, предлагаю два варианта:
Intel Pentium EE 955 3,46 ГГц. Presler
Intel Core 2 Quad Q6700 2,67 ГГц Kentsfield
оба 65нм второй вышел позже и как раз харктеризуется тем что метрика на ГГц тут будет не корректна, потому что производиельность у него должна быть не ниже. Вот хотелось бы узнать сравнение именно с этими процессорами. А так же ключевой вопрос (к эльбрусовцам): когда Эльбрус-8С выйдет, который до конца 2015г. «сделан»?
http://mcst.ru/vosmiyadernyj-mikroprocessor-s-arkhitekturoj-elbrus
Народу, безусловно, интересен потенциал архитектуры, а не конкретно этот камень, поэтому было бы логичным сравнить с топовым процессором от Intel на архитектуре 65нм, предлагаю два варианта:
Intel Pentium EE 955 3,46 ГГц. Presler
Intel Core 2 Quad Q6700 2,67 ГГц Kentsfield
оба 65нм второй вышел позже и как раз харктеризуется тем что метрика на ГГц тут будет не корректна, потому что производиельность у него должна быть не ниже. Вот хотелось бы узнать сравнение именно с этими процессорами. А так же ключевой вопрос (к эльбрусовцам): когда Эльбрус-8С выйдет, который до конца 2015г. «сделан»?
http://mcst.ru/vosmiyadernyj-mikroprocessor-s-arkhitekturoj-elbrus
Так 8С и сделан. Сейчас тестируются предсерийные материнки с процессором, т. е. уже готовая платформа со всей обвязкой. Во втором квартале 2017 уже серийные системы на 8С, скорее всего даже на 8С1, уже будут в продаже. В общем, как я понимаю, то самая свежая инфа будет вот тут на тытрубе точно:
С учётом того что уже показали чип выглядит хорошо.
P.S. канал, можно сказать, первоисточник.
P.P.S. посмотрим какой ценник будет и какие условия для продажи серийных машин.
С учётом того что уже показали чип выглядит хорошо.
P.S. канал, можно сказать, первоисточник.
P.P.S. посмотрим какой ценник будет и какие условия для продажи серийных машин.
del, не туда. прошу прощения.
Ну серьёзно, полное игнорирование тестов SPEC наводит на плохие мысли. Когда уже сделаете?
И раз уж тут про оптимизацию, где купить попробовать и где взять компилятор? У МЦСТ всё ведь закрыто. Зачем статья если её вообще не к чему применить? Интереснейший проект и всё закрыто.
Тем кто понимает про архитектуры процессов и так всё это знают — дайте тесты! В конце концов Intel Itanium тот же VLIW. А для него куча всего доступно.
И раз уж тут про оптимизацию, где купить попробовать и где взять компилятор? У МЦСТ всё ведь закрыто. Зачем статья если её вообще не к чему применить? Интереснейший проект и всё закрыто.
Тем кто понимает про архитектуры процессов и так всё это знают — дайте тесты! В конце концов Intel Itanium тот же VLIW. А для него куча всего доступно.
Itanium не умер? :)
Чего вдруг.
А, это видимо я слышал звон об:
Windows XP 64-bit Edition — это издание разрабатывалось специально для рабочих станций с архитектурой IA-64 и микропроцессорами Itanium. Это издание Windows XP более не развивается с 2005 года, после того, как HP прекратил разработку рабочих станций с микропроцессорами Itanium.:)
Вот +1 ну и где доступ к железу? Ладно, не могут продавать и раздавать компиляторы, не надо! Но блин, есть же доступ по сети!!! Просто давали бы терминальный доступ интересующимся, чтобы скомпилить, запустить, потестить хоть что нибудь.
А можно расскладку производительность на ватт? А то в пересчетах на гигагерцы 65 нанометров выглядит, наверное — не плохо…
Мыши плакали, кололись, но продолжали жрать кактус
1. Нормировка к частоте это пустой звук, т.к. Эльбрус именно из за своей архитектуры никогда не достигнет частоты i7.
2. SSE для i7? Серьезно? А теперь давайте возьмем AVX2+FMA.
3. Где результат для сравнения EML vs MKL?
4. Где результат для double операций?
2. SSE для i7? Серьезно? А теперь давайте возьмем AVX2+FMA.
3. Где результат для сравнения EML vs MKL?
4. Где результат для double операций?
на Эльбрусе использовался 32-битный режим адресациии
Можно видеть, что обработка по 8 байт работает быстрее на Эльбрус-4С
То есть в 32 разрядной ОС Эльбрус сможет работать с 64 байтными числами нативно? :)
Интелы (x86) вроде так не умеют. :)
Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.
В вебе (nginx | php7 | mysql 5.7) используется simd-арифметика или обычная? :)
Вроде больше текст (обычная целочисленная?).
Было бы выгодно их использовать в веб-серверах. :)
Какая максимальная частота Эльбруса? :)
Какие цены по сравнению с примерно равным по производительности Интелом? :)
Есть поддержка последних линуксов? :)
С сайта Эльбруса:
А есть ли нативная поддержка? :)
И какой оверхед эмуляции? :)
И даже в режиме эмуляции? :)
Качество эмуляции архитектуры х86 подтверждается успешным запуском на платформе Эльбрус более 20 операционных систем (в том числе несколько версий Windows) и сотен приложений.
А есть ли нативная поддержка? :)
И какой оверхед эмуляции? :)
Стоит отдельно отметить, что в настоящее время вирусов для платформы «Эльбрус» просто не существует.
И даже в режиме эмуляции? :)
Накладные расходы эмуляции видимо незначительные, так как 300 МГц проц сделал 500 МГц Pentium M. :)
С вики о планах на будущее в 2009 (2013?) году (офф сайт):
С вики о планах на будущее в 2009 (2013?) году (офф сайт):
«Эльбрус-8С» — 250 ГФлопс, 28 нм к 2015 г. — восьмиядерный микропроцессор с архитектурой Эльбрус.Вышла чуток задержка, на оф. сайте его еще нет. :)
С их осью доводилось недавно сталкиваться.
Их железо раздобыть не так просто, правда у них есть виртуалки с возможностью компиляции исходников под платформу эльбруса, но опять же это обычные привычные нам дистрибутивы линуха для x86.
Сама ось Эльбрус последних версий — релиз Debian с вполне неплохим набором пакетов хотя и не очень полным. Правда крупные пакеты они собирают сами из исходников и там наблюдаются проблемы с тем как могут быть расположены скрипты, конфиги и прочее. К примеру сборка апача меня удивила тем, что привычных a2ensite и иже с ним не было, зато был один здоровый конфигурационный файл) И таких мелочей довольно много.
Правда есть и плюсы. У них есть багтрекер где они вполне лояльно относятся к замечаниям и вполне адекватно реагируют.
Их железо раздобыть не так просто, правда у них есть виртуалки с возможностью компиляции исходников под платформу эльбруса, но опять же это обычные привычные нам дистрибутивы линуха для x86.
Сама ось Эльбрус последних версий — релиз Debian с вполне неплохим набором пакетов хотя и не очень полным. Правда крупные пакеты они собирают сами из исходников и там наблюдаются проблемы с тем как могут быть расположены скрипты, конфиги и прочее. К примеру сборка апача меня удивила тем, что привычных a2ensite и иже с ним не было, зато был один здоровый конфигурационный файл) И таких мелочей довольно много.
Правда есть и плюсы. У них есть багтрекер где они вполне лояльно относятся к замечаниям и вполне адекватно реагируют.
Intel Core i7
Число ядер 4 (8 c Hyper-Threading)
при N = 8 показал ускорение в 8 раз.
То есть при N = 4 процессор был загружен не на 100%? :)
Или на 100%, но нашлись дополнительные вычислительные блоки для Hyper-Threading? :)
Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.
А почему тут не приводили к 1 ГГц? :)
Можно видеть, что развертывание циклов работает как на современном Core i7, так и на Эльбрус-4С. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает значительно эффективнее Core i7 с учетом отношения частот.
Кобыла может тянуть телегу со скоростью 8 км/ч, автомашина может ехать со скоростью 180 км/ч. Мощность кобылы — 1 л.с, мощность двигателя автомашины — 308 л.с. С поправкой на мощность, кобыла эффективнее в 13,7 раз
1. Кобыла может проехать там, где ваши 308 л.с. застрянут, хоть их и 308 :)
2. Кобыла может ехать и больше 8 км/ч. :)
3. Кобыла обходится условно бесплатно.
4. Расскажите это жителям моего села, что им нужна машина 308 л.с., а не кобыла. :)
5. Кобылу можно использовать и как легковик (верхом) и как грузовик (с телегой). :)
6. Не под каждую машину запрежешь плуг. Как-то глупо орать поле Жигулем, а тем более Бентли. :)
2. Кобыла может ехать и больше 8 км/ч. :)
3. Кобыла обходится условно бесплатно.
4. Расскажите это жителям моего села, что им нужна машина 308 л.с., а не кобыла. :)
5. Кобылу можно использовать и как легковик (верхом) и как грузовик (с телегой). :)
6. Не под каждую машину запрежешь плуг. Как-то глупо орать поле Жигулем, а тем более Бентли. :)
Это демагогия уровня «раньше компьютеров не было и жить было лучше» (с) моя бабушка
Почему же демагогия. :)
Или ты уже электричество употребляешь вместо еды? :)
Или ты в лес по грибы поедешь на Бентли? :)
Кстати, с твоей бабушкой можно частично и согласиться.
Не было компов — не было и проблем с компами, ну люди выходили на улицу. :)
А так да, можно залипать в компе.
У меня открыли были интернет клуб когда-то. Так один чувак там все летние каникулы провел, а потом говорил — «ах какие афигенные у миня каникулы были» :)
Я ж не спорю, что есть плюсы и у авто (как бы несомненные, поэтому и не описывал их, можете сделать это Вы :) ).
Просто не нужно так надменно смотреть на коня. :)
И для коня найдем применение.
Или ты уже электричество употребляешь вместо еды? :)
Или ты в лес по грибы поедешь на Бентли? :)
Кстати, с твоей бабушкой можно частично и согласиться.
Не было компов — не было и проблем с компами, ну люди выходили на улицу. :)
А так да, можно залипать в компе.
У меня открыли были интернет клуб когда-то. Так один чувак там все летние каникулы провел, а потом говорил — «ах какие афигенные у миня каникулы были» :)
Я ж не спорю, что есть плюсы и у авто (как бы несомненные, поэтому и не описывал их, можете сделать это Вы :) ).
Просто не нужно так надменно смотреть на коня. :)
И для коня найдем применение.
по третьему пункту вроде кобыла стоит как ферарри, не?
А почему все еще 65нм? Или его разрешено производить только в России? Очень бы хотелось увидеть это чудо на 22нм хотя бы и еще меньше. Ну и на больших частотах. Заказать изготовление на стороне нельзя?
Не всё сразу. На вики со ссылкой на некий документ «Российские технологии «Эльбрус» для пер-
сональных компьютеров» пишут, что «к 2020 году планирует[ся] выпускать 14-нм процессор Эльбрус-32С». Нужно ещё четыре годика подождать. Не дешёвое это дело — уменьшать нанометры. Technologic gap в два прыжка не перепрыгнуть.
Во-первых, сама идея Эльбрусов заключается в том, чтобы своё и себя делать. Если заказывать — то легче сразу готовые процессоры закупать. Во-вторых, как я понимаю, Эльбрусы использует во многом военка. А там народ строгий — ану как враг прослушки какие-то в процессоры засунет. Поэтому, думаю, такое решение проблемы не подойдёт.
Надеюсь, автор статьи поправит если чего-то не так сказал.
сональных компьютеров» пишут, что «к 2020 году планирует[ся] выпускать 14-нм процессор Эльбрус-32С». Нужно ещё четыре годика подождать. Не дешёвое это дело — уменьшать нанометры. Technologic gap в два прыжка не перепрыгнуть.
Заказать изготовление на стороне нельзя?
Во-первых, сама идея Эльбрусов заключается в том, чтобы своё и себя делать. Если заказывать — то легче сразу готовые процессоры закупать. Во-вторых, как я понимаю, Эльбрусы использует во многом военка. А там народ строгий — ану как враг прослушки какие-то в процессоры засунет. Поэтому, думаю, такое решение проблемы не подойдёт.
Надеюсь, автор статьи поправит если чего-то не так сказал.
В такой простой синтетике обычно сравнивают не разные процессоры, а достигнутую производительность с теоретически возможной.
Сооветственно, как интерпретировать приведённые результаты?
вот берём «Пример 1. Развертывание циклов»
результат для i7: Время, мс 5-255.
Это что, 64000 итераций такого простого цикла много миллисекунд считаются? — как-то очень сомнительно.
Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию, т.е. ждём время исполнения этого кода существенно меньше одной миллисекунды (что не так-то просто и померить, кстати ;)).
Короче, взял Ваш код, обернул тестируемый цикл во внешний с числом итераций 100000 (дабы привести время к человеческим временам, а заодно и исключить краевые эффекты, типа непрогретого кэша), и прогнал на Intel® Core(TM) i5-4460 CPU @ 3.20GHz
то есть имеем 7.7/1.5/0.5 тактов процессора на одну итерацию цикла в зависимости от уровня оптимизации.
Первые два более-менее соответствуют ожиданиям, а вот последний — несколько выходит за рамки теории.
Дальше надо разбираться .
Там довольно много интересното:
Короче вопрос: как именно Ваши результаты соотносятся с написанным мной?
Сооветственно, как интерпретировать приведённые результаты?
вот берём «Пример 1. Развертывание циклов»
результат для i7: Время, мс 5-255.
Это что, 64000 итераций такого простого цикла много миллисекунд считаются? — как-то очень сомнительно.
Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию, т.е. ждём время исполнения этого кода существенно меньше одной миллисекунды (что не так-то просто и померить, кстати ;)).
Короче, взял Ваш код, обернул тестируемый цикл во внешний с числом итераций 100000 (дабы привести время к человеческим временам, а заодно и исключить краевые эффекты, типа непрогретого кэша), и прогнал на Intel® Core(TM) i5-4460 CPU @ 3.20GHz
результаты
$ g++ -O3 -o t1 t1.cpp; time ./t1
real 0m0.973s
user 0m0.968s
sys 0m0.000s
$ g++ -O2 -o t1 t1.cpp; time ./t1
real 0m2.834s
user 0m2.828s
sys 0m0.000s
$ g++ -O1 -o t1 t1.cpp; time ./t1
real 0m2.796s
user 0m2.792s
sys 0m0.000s
$ g++ -O0 -o t1 t1.cpp; time ./t1
real 0m14.453s
user 0m14.444s
sys 0m0.000s
real 0m0.973s
user 0m0.968s
sys 0m0.000s
$ g++ -O2 -o t1 t1.cpp; time ./t1
real 0m2.834s
user 0m2.828s
sys 0m0.000s
$ g++ -O1 -o t1 t1.cpp; time ./t1
real 0m2.796s
user 0m2.792s
sys 0m0.000s
$ g++ -O0 -o t1 t1.cpp; time ./t1
real 0m14.453s
user 0m14.444s
sys 0m0.000s
то есть имеем 7.7/1.5/0.5 тактов процессора на одну итерацию цикла в зависимости от уровня оптимизации.
Первые два более-менее соответствуют ожиданиям, а вот последний — несколько выходит за рамки теории.
Дальше надо разбираться .
с ассемблером
-O0:
-O2, -O1:
[code]
.L4:
addl $1, %edx
addl (%rcx), %eax
addq $4, %rcx
movl %edx, -4(%rcx)
cmpl $64000, %edx
jne .L4
[/code]
-O3:
[code]
.L4:
movdqa %xmm0, %xmm2
paddd (%rdx), %xmm1
addq $16, %rdx
paddd %xmm3, %xmm0
paddd %xmm4, %xmm2
movaps %xmm2, -16(%rdx)
cmpq %rcx, %rdx
jne .L4
[/code]
.L6:
movl -16(%rbp), %eax
cltq
movl -256016(%rbp,%rax,4), %eax
addl %eax, -4(%rbp)
movl -16(%rbp), %eax
leal 1(%rax), %edx
movl %edx, -16(%rbp)
movl -16(%rbp), %edx
cltq
movl %edx, -256016(%rbp,%rax,4)
.L5:
cmpl $63999, -16(%rbp)
jle .L6
-O2, -O1:
[code]
.L4:
addl $1, %edx
addl (%rcx), %eax
addq $4, %rcx
movl %edx, -4(%rcx)
cmpl $64000, %edx
jne .L4
[/code]
-O3:
[code]
.L4:
movdqa %xmm0, %xmm2
paddd (%rdx), %xmm1
addq $16, %rdx
paddd %xmm3, %xmm0
paddd %xmm4, %xmm2
movaps %xmm2, -16(%rdx)
cmpq %rcx, %rdx
jne .L4
[/code]
Там довольно много интересното:
- Видно, что для достижения около-теоретической производительности никакой раскрутки цикла не потребовалось.
- в -O3 использована автовекторизация, потому результат получился выше теоретического предела
- никаких ускорений на порядки раскрутка циклов дать не может
Короче вопрос: как именно Ваши результаты соотносятся с написанным мной?
Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию
Почему?
потому что там навскидку видно 5 команд:
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.
Мы использовали внешний цикл в каждом примере. Конкретно в примере 1 было сделано 10000 итераций внешнего цикла. На Core i7 компиляция выполнялась на Microsoft Visual Studio, оптимизация /О2. Одна итерация цикла заняла ~1.5 такта.
Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
Смотрим ассемблер
:
000000013F1D6780 xor eax,eax
000000013F1D6782 mov dword ptr [k (013F1EF280h)],eax
000000013F1D6788 test r8d,r8d
000000013F1D678B jle main+10Bh (013F1D67ABh)
000000013F1D678D mov rcx,r13
000000013F1D6790 add edx,dword ptr [rcx]
000000013F1D6792 mov dword ptr [rcx],eax
000000013F1D6794 inc eax
000000013F1D6796 lea rcx,[rcx+4]
000000013F1D679A cmp eax,r8d
Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
Таким образом, самый плохой результат (255мс) — это реально 1.5 такта на итерацию, что уже соответствует околотеоретической производительности.
Хорошо.
Осталось понять чему именно соответствует результат 5мс (32 итерации за такт)?
Очевидно, сохранения 32 интов за такт одно ядро i7 сделать не сможет, даже при полной векторизации на AVX2.
Отсюда понимаем, что паттерн оптимизации «Пример 1. Развертывание циклов» соответствует замене приведённого кода каким-то другим, где не надо делать столько сохранений.
конкретно речь о строчке
a[kpp] = k; (тут я специально заменил k++ на kpp, чтобы не рассматривать лишнюю операцию сложения)
Суть:
в исходном коде эту операцию надо сделать 64000*10000=0.64*10^9 раз.
Утверждение: на одном ядре i7 это невозможно сделать за 5мс.
PS: «эффективное использование конвейера,… несколько АЛУ, усовершенствованный кэш, Out of Order Execution» — на это утверждение никак не влияют.
Хорошо.
Осталось понять чему именно соответствует результат 5мс (32 итерации за такт)?
Очевидно, сохранения 32 интов за такт одно ядро i7 сделать не сможет, даже при полной векторизации на AVX2.
Отсюда понимаем, что паттерн оптимизации «Пример 1. Развертывание циклов» соответствует замене приведённого кода каким-то другим, где не надо делать столько сохранений.
конкретно речь о строчке
a[kpp] = k; (тут я специально заменил k++ на kpp, чтобы не рассматривать лишнюю операцию сложения)
Суть:
в исходном коде эту операцию надо сделать 64000*10000=0.64*10^9 раз.
Утверждение: на одном ядре i7 это невозможно сделать за 5мс.
PS: «эффективное использование конвейера,… несколько АЛУ, усовершенствованный кэш, Out of Order Execution» — на это утверждение никак не влияют.
Вы правы, никакого ускорения с помощью раскрутки цикла в данном примере получить нельзя. Обновили результат в посте, спасибо :)
хорошо.
Теперь применяем те же рассуждения к Эльбрусу.
получаем 2 итерации цикла за такт, откуда сразу же следуют два вывода, находящиеся в противоречии с Вашей статьей:
Теперь применяем те же рассуждения к Эльбрусу.
получаем 2 итерации цикла за такт, откуда сразу же следуют два вывода, находящиеся в противоречии с Вашей статьей:
- раскрутка цикла делается компилятором Эльбруса автоматически (за такт ядро Эльбруса может сделать только один переход — см доки)
- в «расчете на гигагерц» в этом тесте производительность Эльбруса и core-i одинаковые — две итерации за такт (если использовать максимальный уровень оптимизации компилятором)
Видно, что для достижения около-теоретической производительности никакой раскрутки цикла не потребовалось.
Во-первых «около» — это на 50% медленнее? Отличная история — поймать результат лсд и рассуждать об «раскрутка не потребовалась» особенно вкупе с тем, что собственно поймали его ограничение. Вот ведь дураки пацаны — апаратный анроллер запилили, а у экспертов на хабре случилось «не потребовалось».
И даже не самое важно — стоит его зантроллить и он покажет максимальный трупут.
никаких ускорений на порядки раскрутка циклов дать не может
Слишком не хочу на это отвечать. Могу только сказать — могут. Сраться на эту тему мне лень — слишком сложно и долго — можете просто игнорировать этот пункт.
>Во-первых «около» — это на 50% медленнее?
это на пол-такта медленнее оценки.
>поймать результат лсд
какой результат?
>Отличная история… Вот ведь дураки пацаны— апаратный анроллер запилили
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
>поймали его ограничение
Кто поймал? Если Вы о 1.5 тактах вместо 1, то никаких сложных объяснений тут искать не надо. Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
>стоит его зантроллить и он покажет максимальный трупут.
исключительно за счёт ликвидации накладных расходов на саму организацию цикла (сравнение и переход), которые для такого простого цикла на 4 содержательные операции — весьма велики.
Но в общем и целом, после появления в интеловских процессорвах кэша предекодированных uop-ов, раскрутку циклов надо делать очень осторожно — велика вероятность в него не вписаться, и в результате попасть на ограничения куда более узкого места — декодера.
>Могу только сказать — могут
Моя сентенция относилась к конкретному примеру, где было показано ускорение в 30 что ли раз за счёт раскрутки. В данном случае это было явно следствие ошибки, что уже давным-давно выяснили.
А насчет «могут или не могут» — я за время своей практики многое встречал.
Тем не менее — пример приветствуется.
это на пол-такта медленнее оценки.
>поймать результат лсд
какой результат?
>Отличная история… Вот ведь дураки пацаны— апаратный анроллер запилили
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
>поймали его ограничение
Кто поймал? Если Вы о 1.5 тактах вместо 1, то никаких сложных объяснений тут искать не надо. Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
>стоит его зантроллить и он покажет максимальный трупут.
исключительно за счёт ликвидации накладных расходов на саму организацию цикла (сравнение и переход), которые для такого простого цикла на 4 содержательные операции — весьма велики.
Но в общем и целом, после появления в интеловских процессорвах кэша предекодированных uop-ов, раскрутку циклов надо делать очень осторожно — велика вероятность в него не вписаться, и в результате попасть на ограничения куда более узкого места — декодера.
>Могу только сказать — могут
Моя сентенция относилась к конкретному примеру, где было показано ускорение в 30 что ли раз за счёт раскрутки. В данном случае это было явно следствие ошибки, что уже давным-давно выяснили.
А насчет «могут или не могут» — я за время своей практики многое встречал.
Тем не менее — пример приветствуется.
это на пол-такта медленнее оценки.
Оценки в один такт один такт. Что является на 50% медленнее.
какой результат?
Полученный.
Такое впечатление, что Вы беседуете с голосами в своей голове.
Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
Когда нечем крыть — обвини. Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд? Ситуация в целом типичная — человек не понимает что и почему происходит. Он получает результат и на делает выводы не учитывая того, чего он не видит и не понимает.
Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).
Ну пошли объяснения уровня детского садика. Что такое «ширина конвейера»? И почему её не хватает? Почему же эта ширина конвейера не учитывалась при:
есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
В частности, только один для сохранения данных. Так что навскидку получается такт.
А я скажу почему — это всё просто пустой трёп. Эксперт рассчитывал на то, что на разницу между его выводами и реальностью он ответит «не у теоретическая производительность недостижима», либо как-то так.
Моя сентенция относилась к конкретному примеру
Враньё. Если бы она относилась — она бы на это указывала. Относительно к примеру она вообще не имеет смысла. Вроде как у нас есть «теоретическая производительность» и реальная и разница между ними +50%, то зачем повторять ещё раз то, что итак из этого следует при этом в обобщенной форме?
где было показано ускорение в 30 что ли раз за счёт раскрутки.
Меня мало волнует что там написано. Зачем сливаться на это? Я где-то хоть раз упомянул статью и её выводы? Нет. А если нет — зачем мне про это писать?
А насчет «могут или не могут» — я за время своей практики многое встречал.
Но ведь ваши выводы глупы, а понимание слабо. Толку с такой практики? Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт. Да, это моя ошибка — что-то я решил не вытягивать из вас подобные заявления, а они были бы.
По поводу примеров. В данном случае каждая итерация зависит от счётчика, который имеет трупут 1 значение/такт. Не учитывая того, о чём я не буду сейчас говорить, чтобы не давать вам пути для съезжания. В этот примере это нивелируется тем, что это совпало собственно с трупутом записи. Чисто случайно.
Если бы это было чтение, то мы бы получили -100%, а если учитывать всё остальное — 150%. А если нам надо чуть больше на итерации считать?
Ну и конечно же юзкейсы уровня нескольких итераций.
>Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд?
1. Эксперт — это кто?
2. C ЛСД Вам надо завязывать — тогда глядишь и перестанет чудиться то, чего нет на самом деле.
>Что такое «ширина конвейера»? И почему её не хватает?
число портов запуска, я это уже писал
> Почему же эта ширина конвейера не учитывалась при:
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Компилируем то же на icc и
как говорится — найдите отличия ;)
ну и заодно — угадайте, сколько именно тактов работает такой цикл
>А я скажу почему — это всё просто пустой трёп
Знаете, в чём Ваше отличие от автора статьи — в отсутствии рефлексии. Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.
>Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт.
На самом деле, до того как Вы пришли — я этого не говорил.
Поскольку я последние три года занимался в основном оптимизацией для GPU. А там анролл циклов действительно нужен в подавляющем числе ситуаций (хотя конечно ни о каких ускорениях на порядки речи тоже нет).
Но если Вы настаиваете, то я таки сформулирую своё мнение на unroll:
Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
1. Эксперт — это кто?
2. C ЛСД Вам надо завязывать — тогда глядишь и перестанет чудиться то, чего нет на самом деле.
>Что такое «ширина конвейера»? И почему её не хватает?
число портов запуска, я это уже писал
> Почему же эта ширина конвейера не учитывалась при:
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Компилируем то же на icc и
получаем:
..B1.5: # Preds ..B1.4 ..B1.5
addl (%rsp,%rdx,4), %edi #13.3
movl %edx, (%rsp,%rdx,4) #14.3
incq %rdx #14.5
cmpq $64000, %rdx #11.21
jl ..B1.5 # Prob 99% #11.21
как говорится — найдите отличия ;)
ну и заодно — угадайте, сколько именно тактов работает такой цикл
>А я скажу почему — это всё просто пустой трёп
Знаете, в чём Ваше отличие от автора статьи — в отсутствии рефлексии. Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.
>Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт.
На самом деле, до того как Вы пришли — я этого не говорил.
Поскольку я последние три года занимался в основном оптимизацией для GPU. А там анролл циклов действительно нужен в подавляющем числе ситуаций (хотя конечно ни о каких ускорениях на порядки речи тоже нет).
Но если Вы настаиваете, то я таки сформулирую своё мнение на unroll:
Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
число портов запуска, я это уже писал
у современных core-i 7 портов выполнения (>5), но они неуниверсальны
Дак больше 5?
Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
Да нет, просто кто-то не осилил спастить код и написать его вменяемо.
ну и заодно — угадайте, сколько именно тактов работает такой цикл
И сколько же?
Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.
В чём же заключается моя ошибка?
На самом деле, до того как Вы пришли — я этого не говорил.
Собственно намекал и моя ошибка была в том, что я это не вытянул. Да.
Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
Очень смешно когда «экперт» с познанием уровня 20летний давно рассуждает о чём-то. Я кстати даже не заметил перлов выше. Надо ответить на них.
Все таки импорт-замещение работает)))
Ничего не понимаю. Почему вы разделяете Эльбрус-МЦСТ и SPARC? Это ведь одна и та же архитектура клманд.
Есть Эльбрус-SPARC и Эльбрус-Эльбрус:
оф. сайт :)
оф. сайт :)
«Время в пересчете на 1 ГГц» — это очковтирательство чистой воды. Напишите один и тот же алгоритм для 1Mhz и 1Ghz — это будут принципиально разные вещи по архитекруте, по площади кристалла или FPGA, по… всему! Интерес вызывает только абсолютное время выполнения задачи. Чем меньше тем лучше.
а что с JVM и CLR? сразу транслируется в VLIW коды или в x86 потом VLIW?
Про JVM доклад был: https://www.youtube.com/watch?v=yOwvNykK__o
Естественно, никакого x86 там нет.
Я никак не вижу интригующих данных по главному вопросу: сам VLIW то дает преимущество?
Вы анализировали, какие широкие команды генерируются в вашем коде? Может где-то переставили местами, запараллелили два процесса и всё стало быстрее в разы?
Вы анализировали, какие широкие команды генерируются в вашем коде? Может где-то переставили местами, запараллелили два процесса и всё стало быстрее в разы?
Мы рассмотрели простые примеры на С++ и сравнили результаты работы на Эльбрус-4С и Intel Core i7-6700K. На Эльбрусе использовался компилятор lcc версии 1.20.17, для Core i7 — Microsoft Visual Studio Community 2015. Для lcc мы использовали флаги компиляции -O3 и -ffast-math.
У меня вот этому месту очень большие претензии! Почему не выставили аналогичные оптимизации для MSVC?
Вы же сравниваете дальше, фактически тёплое с мягким т. е. не результат работы кода на разных архитектурах с одинаковым уровнем оптимизации у компиляторов, т. е. фактически для x86 без каких либо оптимизаций со стороны компилятора. Не надо так делать :(
Такими «тестами» в глазах специалистов вы только дискредитируете платформу. Это в чистом виде антимаркетинг. Особенно с учётом того что Эльбрусы не пойти и не купить, а потому провести аналогичный тест у себя не представляется возможным.
Очень прошу: укажите параметры MSVC, а лучше выставите там соизмеримые с -O3 и тоже включите fast-math оптимизации и проведите тесты заново ;)
Жду исправления статьи ибо пока выводы на основе таких «тестов» видятся неадекватными и откровенно ненаучными.
P.S. а ещё гораздо больше интересен тест 8С1 (именно модификация, а не чистого 8С) ибо 8C1 за счёт более оптимального размера кэша L2 должен быть явно энергоэффективнее 8С. В общем слежу за архитектурой, а адекватных тестов без ахинеи всё нет и нет, а самое обидное: заказать и купить его даже нельзя :( Знаю что 8С ещё в предсерийке, но в серию пойдут во 2 квартале 2017 и я очень сильно сомневаюсь, что не юрлицу их можно будет купить.
У разных компиляторов различный набор настроек оптимизации и эти настройки могут быть по-разному реализованы, поэтому выставить полностью идентичный набор параметров затруднительно. Так, дефолтные значения флагов lcc предполагают довольно сильные ограничения floating-point оптимизаций. Флаг -ffast-math (отличается от -ffast-math в gcc) включает некоторые оптимизации, например, подстановку операций вместо вызова библиотечных функций. И только с флагами -ffast и -ffast-math задействуется полный набор floating-point оптимизаций, которые могут приводить к значительным изменениям результатов вычислений.
В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.
В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.
Sign up to leave a comment.
Оптимизация кода для платформы Эльбрус на простых примерах