Pull to refresh

Comments 53

Вывод: использовать компилятор Intel.
и core вместо atom
Ну да. Особенно в телефоне.
а intel уже прикрутила свой компилятор к android?
На самом деле, можно сказать, что да.
Библиотеки NDK x86 сделаны в ходе сотрудничества Intel и Google и специально оптимизированы под Atom, да и некоторые энтузиасты уже пытаются собирать части своих NDK библиотек под icc
Насколько мне известно, от Intel были патчи к gcc для NDK. Вторая ссылка мне кажет 403, но энтузиасты — не Intel, понятное дело.
UFO landed and left these words here
UFO landed and left these words here
При этом, если использовать одинаковый компилятор — Core всегда побеждает Atom. Синяя линия всегда выше зеленой, а красная выше фиолетовой.
Довольно странно сравнивать быстродействие процессоров, используя при этом разные исполняемые файлы.
Похоже, что раз там VS2008, то используется Windows. Странно вообще проводить тесты процессоров в ОС не реального времени. Тем более под виндой — кто знает, что там шедуллер вытворит?

Или всё-таки так можно? %)
Совсем необязательно. Оптимизация — это очень много технологий и инструментов. И, хотя бы что-то из этого набора использовать надо.
Выводы мы конечно сделаем, автору спасибо за труд, но что делать с этой инфой?
Зависит от того, кто вы. Если пользователь системы на Atom или Core, то, выбирая программы, смотреть, насколько они оптимизированы. Если разработчик — сами понимаете, что делать. Мой пост просто показывает, что смысл оптимизировать — есть.
А какая оптимизация в visual studio 2008 и в Intel Compiler в release по умолчанию? И почему не Visual Studio 2010? Intel Compiler вроде свежий взяли :)
Компилятор тоже не самый свежий. Visual Studio — та, что стоит у большинства разработчиков.
Оптимизация по-умолчанию -/O2, не используются SIMD
Извините, хочу уточнить, правильно ли я понял результаты. Получается, что код скомпилированный с оптимизацией на i3 работает все равно быстрее, чем на Atom, ровно также как если в обоих случаях код скомпилирован без оптимизаций?
Никак не пойму, где работает обещанная аналогия с юркостью скутера в пробках?
Да, вы поняли правильно. И отчасти — правы, полной аналогии со скутером в результате не получилось. Т.е. на оптимизированном коде (магистрали) i5 опережает Atom, на неоптимизированном (в пробке или на плохой дороге) — тоже опережает, но если машина едет по плохой дороге, а скутер — по хорошей, то он обгонит машину.
А если машина едет по хорошей, а скутер упал в яму, то машина обгонит скутер.
Гениально!
Да просто недобуки с атомами плохо продаются, вот и заставили человека притянуть за уши эти результаты, чтобы хоть как-то поднять продажи.
Вот и ответ, зачем городить статью про «1000 и один способ попытаться приблизить атом к коре дуба»
Я абсолютно не в курсе результатов продаж нетбуков с Атомами, если у вас есть соответствующие данные — с интересом посмотрю. Но я уверена, что все вышесказанное относится и к тем Атомам, которые ставят в смартфоны. А про их выдающиеся результаты продаж в Европе я знаю. Там раскуплено всё, народ ждет новых поставок.
Как то притянуто. и частоту масштабируем, не смотря на то что это одно из преимуществ core, и оптимизацию выключаем. можно еще например параллельно загрузить чем нибудь core. ненуачо, он же вроде как «машина», значит и груза больше везти во время тестов должен)
Единственный вывод из статьи, это «данная версия компилятора intel оптимизирует с настройками по умолчанию лучше, чем данная версия MSVS»
Сравнивать надо яблоки с яблоками, а не с апельсинами, поэтому частоту масштабировать нужно. Но любопытно, что прирост скорости на паре тестов таков, что он перекрывает масштабирование. Т.е. Атом быстрее в абсолютных цифрах!
Если говорить о математически точных выводах, а точнее, о содержании статьи, то надо даже так: «данная версия компилятора intel оптимизирует НЕКОТОРЫЕ ДАННЫЕ ТЕСТЫ с настройками по умолчанию лучше, чем данная версия MSVS». Но вы на то и человек, чтобы сделать более общие выводы, о которых я говорю в ответах на комментарии выше.
Я читал достаточно много обзоров процессоров на thg.ru и они там часто приводят сравнительную таблицу производительности на ватт. Т.е., суммарно затраченную энергию на решение поставленной вычислительной задачи.
Разумно было бы привести эти данные в статье. Было бы больше конструктива
Только что обнаружила — у меня в лабе, оказывается, есть Core примерно такой же частоты, как и Атом -1.7GHz. Сравнивать надо было их, если найду время, сравню и проапдейчу пост.
Много слышал и читал хорошего об Intel Compiler. Вот только цена кусается: минимум $400 за компилятор Я пока выложить не готов. Если бы Intel выпускал бесплатную урезанную версию (как MSVC Express) или специальный компилятор для использования в OpenSource проектах, то с удовольствием поменял бы свой cl на icl.
afaik, MSVC Express не поддерживает полный набор оптимизаций.
если интел выпустит аналогичный продукт (и также без оптимизаций), то зачем переходить?
Думаю это несколько не то. Open source != non-commercial. Тем более там речь идет о personal non-commercial use.
К сожалению только для Linux, по этому это не конкурент MSVC Express.
> оптимизированный код может выполняться на Atom гораздо быстрее, чем неоптимизированный на Core
Вот так вывод! Особенно учитывая, что не просто не оптимизированный, а деоптимизированный.
неоптимизированный == исходный.
всё остальное- ваши ничем не обоснованные домыслы, или поясните пожалуйста вашу мысль
мысль в том, что вы специально делали код таким образом, чтобы процессор не мог использовать свои преимущества, т.е. де-оптимизировали код для конкретного процессора.
Только в одном случае — тест «random», для которого, кстати, получить преимущество не удалось. А все математические тесты, в тч и те, на которых видно преимущество, существовали независимо от и задолго до моего исследования. Они — неспециальные, просто такие от природы.
Кроме того, у Atom в четыре раза меньше размер кэш-памяти

Вот на это я бы очень даже поставил. В своё время практика показывала, что если отключить у Pentium-III (Katmai, 500 MHz) кэши, то производительность падает до уровня 286 (пользовались этим для игры в некоторые старые игры, которые не на всех 386-х даже запускаются). В то же время, Pentium-M (Dothan, 1.6 MHz), снаряжённый 2-мя мегабайтами кэша работал у меня выше всех похвал до позапрошлого года, пока его ни украли. В общем ещё со времён тех экспериментов с торможением Pentium-3 я выбираю процы прежде всего по кэшу и частоте FSB и на общую частоту смотрю в самую последнюю очередь. А вот ускорение памяти всяческими путями (частоты, тайминги, многоканальный доступ) как раз никогда не давало заметного моему невооружённому (если не мерить специально бенчмарками) глазу практического увеличения шустроты системы. Таково, вот, моё субъективное IMHO.
Да, я с вами соглашусь, кеш — великий «производитель». Но есть ряд тестов и масса реальных приложений, где она не главное.
Немного не в тему, но не удержался. По поводу картинки со знаком в статье, видел подобное в деревне на дороге, где проедут разве что местные тракторы. Там и по сей день стоит знак «кирпич» на одном из съездов куда-то в еще бОльшую глухомань с табличкой ниже «Кроме автотранспорта госконсульства США» )))
Такое ощущение, что у вас в Intel статьи заставляют писать в качестве наказания, поэтому большая их часть получается рекламной водой высосанной из пальца.

Краткое содержание сегодняшней статьи: компилятор Intel использует по-умолчанию более агрессивные оптимизации, чем компилятор MSVS и поэтому код получается быстрее. Ну надо же, а мы-то не знали! Особенно забавны пространные рассуждения о кол-ве ALU не в тему.

На графике ясно как день видно, что на коде написанном на SSE intrinsics (те оптимизированном вручную — тесты с _ps) оба компилятора показали идентичный результат. Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными?
Такое ощущение, что вас комментарии заставляют писать в качестве наказания, потому, что статью вы, увы, не поняли.
Попробую объяснить медленно и по буквам. Не имеет значения, какой компилятор лучше, какие опции использованы, да и вообще, как именно сделана оптимизация. Важно, что оптимизированный любым способом код, даже таким простейшим, как смена компилятора, может выполняться быстрее на медленном Atome, чем на быстром Core. Всё.
И, судя по рейтингу статьи, многие это поняли.
И об этом надо было писать статью? Без специалистов Intel мы бы конечно никогда не догадались включить оптимизацию в компиляторе. А то что SSE инструкции быстрее FPU вообще за гранью нашего понимания.

А как на счет разобраться и объяснить почему в тестах sinf, expf и logf ускорение в 6 раз, когда наивно можно предположить в только в 4 раза?
Я уже вижу, что без специалистов Intel вы не догадываетесь, что по умолчанию SIMD оптимизация вЫключена у обоих компиляторов (так что это «Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными? „-неверно) Так что я сомневаюсь, что вы и про остальное “догадаетесь»

Про второй пункт — это тема для отдельного поста. Посмотрю-подумаю.
Я не «догадываюсь», а знаю что
1. в Intel Compiler даже по умолчанию включены некоторые SIMD оптимизации (автоматичекая векторизация например)
2. настройки оптимизации Release весьма далеки от настроек по-умолчанию (кстати, список ключей в студию).

Хотя знать тут вовсе не обязательно, можно и догадаться что 6-ти кратный прирост производительности без SIMD оптимизаций в этих тестах просто не возможен.
Я посмотрела, вы немного правы, спасибо. Я прошу прощения, невнимательно посмотрела. Да, компилятор Интел использует SIMD «поумолчанию». Его опция «Enable Enhanced instruction set» «Not set» на самом деле использует SIMD. Запрещать его надо специально, поставив опцию No enhanced instruction sets (/arch:IA32)
Но только дело в том, что компилятор студии даже если я ему принудительно говорю «использовать SSE» Streaming SIMD Extensions 2 (/arch:SSE2), этого должным образом не делает.
Смотрите графики для i5 ниже. Для Атома делать не буду, простите, нет времени.
image

НО! Я в последний раз говорю, что статья совсем не об этом. Я знаю немало случаев, когда компилятор vs обгоняет Intel и не советую использовать наш компилятор в этих случаях. Но это тоже здесь ни при чем. В общем, дискуссия окончена. Еще раз честное спасибо, что меня поправили про SSE По умолчанию. Плюсую ваш комментарий.
Прошу добавить результаты тестов кода, скомпилированного clang — я видел много коммитов от специалистов Intel в бекенд.
Коллега, а не могли бы вы поделиться проектами с исходниками тестов, использованными в статье, или дать ссылку? Хочется покрутить опции компиляторов самостоятельно.
Да, это возможно. Пришлите адрес в личку.
Единственное — мне не совсем понятен смысл кручения. Реабилитировать компилятор VS? Так я его ни в чем не обвиняю :)
Нет, конечно, не сталкивать лбами Интел и Студию, скорее тут простое любопытство. Хочется покрутить опции интеловского компилятора (влючить/выключить оптимизацию, распараллеливание, SSE, и т.д.) и посмотреть как меняется производительность на разных тестах. В случае резкого повышения производительности можно посмотреть какие конструкции и циклы на что влияют. Это даст пищу для размышлений и поможет писать под интел код чуть более оптимально. Ну то есть такая самообразовательная игрушка на долгие зимние вечера.

Вторая причина — хочу часть бенчмарков переписать на LabVIEW и поиграть с ними. Понятно, что производительность будет заметно ниже, да и не все конструкции переносятся в эквивалентный LabVIEW код, но вот какая будет достигнута производительность — любопытно.
Отличные намеренья. Вышлю код в ближайшее время.
Во-первых, потому, что у Atom сохранилась шина FSB
Должен заметить, что это справедливо только для самых старых атомов.
Начиная с Pine Trail — интегрирован одноканальный контроллер памяти.
Я бы сказал, что контроллер физически в процессоре, но быстрее от этого не стало.
простите, пропустила слово «совсем». Должно было быть вы не СОВСЕМ правы :)
Дело не в перемещении, а в том, что FSB осталось.
Only those users with full accounts are able to leave comments. Log in, please.