Comments 53
Вывод: использовать компилятор Intel.
и core вместо atom
Ну да. Особенно в телефоне.
а intel уже прикрутила свой компилятор к android?
UFO just landed and posted this here
начните с habrahabr.ru/company/intel/blog/145876/? а скоро и в России увидите.
При этом, если использовать одинаковый компилятор — Core всегда побеждает Atom. Синяя линия всегда выше зеленой, а красная выше фиолетовой.
Довольно странно сравнивать быстродействие процессоров, используя при этом разные исполняемые файлы.
Довольно странно сравнивать быстродействие процессоров, используя при этом разные исполняемые файлы.
Совсем необязательно. Оптимизация — это очень много технологий и инструментов. И, хотя бы что-то из этого набора использовать надо.
Выводы мы конечно сделаем, автору спасибо за труд, но что делать с этой инфой?
А какая оптимизация в visual studio 2008 и в Intel Compiler в release по умолчанию? И почему не Visual Studio 2010? Intel Compiler вроде свежий взяли :)
Извините, хочу уточнить, правильно ли я понял результаты. Получается, что код скомпилированный с оптимизацией на i3 работает все равно быстрее, чем на Atom, ровно также как если в обоих случаях код скомпилирован без оптимизаций?
Никак не пойму, где работает обещанная аналогия с юркостью скутера в пробках?
Никак не пойму, где работает обещанная аналогия с юркостью скутера в пробках?
Да, вы поняли правильно. И отчасти — правы, полной аналогии со скутером в результате не получилось. Т.е. на оптимизированном коде (магистрали) i5 опережает Atom, на неоптимизированном (в пробке или на плохой дороге) — тоже опережает, но если машина едет по плохой дороге, а скутер — по хорошей, то он обгонит машину.
Да просто недобуки с атомами плохо продаются, вот и заставили человека притянуть за уши эти результаты, чтобы хоть как-то поднять продажи.
Вот и ответ, зачем городить статью про «1000 и один способ попытаться приблизить атом к коре дуба»
Вот и ответ, зачем городить статью про «1000 и один способ попытаться приблизить атом к коре дуба»
Я абсолютно не в курсе результатов продаж нетбуков с Атомами, если у вас есть соответствующие данные — с интересом посмотрю. Но я уверена, что все вышесказанное относится и к тем Атомам, которые ставят в смартфоны. А про их выдающиеся результаты продаж в Европе я знаю. Там раскуплено всё, народ ждет новых поставок.
Как то притянуто. и частоту масштабируем, не смотря на то что это одно из преимуществ core, и оптимизацию выключаем. можно еще например параллельно загрузить чем нибудь core. ненуачо, он же вроде как «машина», значит и груза больше везти во время тестов должен)
Единственный вывод из статьи, это «данная версия компилятора intel оптимизирует с настройками по умолчанию лучше, чем данная версия MSVS»
Единственный вывод из статьи, это «данная версия компилятора intel оптимизирует с настройками по умолчанию лучше, чем данная версия MSVS»
Сравнивать надо яблоки с яблоками, а не с апельсинами, поэтому частоту масштабировать нужно. Но любопытно, что прирост скорости на паре тестов таков, что он перекрывает масштабирование. Т.е. Атом быстрее в абсолютных цифрах!
Если говорить о математически точных выводах, а точнее, о содержании статьи, то надо даже так: «данная версия компилятора intel оптимизирует НЕКОТОРЫЕ ДАННЫЕ ТЕСТЫ с настройками по умолчанию лучше, чем данная версия MSVS». Но вы на то и человек, чтобы сделать более общие выводы, о которых я говорю в ответах на комментарии выше.
Если говорить о математически точных выводах, а точнее, о содержании статьи, то надо даже так: «данная версия компилятора intel оптимизирует НЕКОТОРЫЕ ДАННЫЕ ТЕСТЫ с настройками по умолчанию лучше, чем данная версия MSVS». Но вы на то и человек, чтобы сделать более общие выводы, о которых я говорю в ответах на комментарии выше.
Только что обнаружила — у меня в лабе, оказывается, есть Core примерно такой же частоты, как и Атом -1.7GHz. Сравнивать надо было их, если найду время, сравню и проапдейчу пост.
Много слышал и читал хорошего об Intel Compiler. Вот только цена кусается: минимум $400 за компилятор Я пока выложить не готов. Если бы Intel выпускал бесплатную урезанную версию (как MSVC Express) или специальный компилятор для использования в OpenSource проектах, то с удовольствием поменял бы свой
cl на icl.
> оптимизированный код может выполняться на Atom гораздо быстрее, чем неоптимизированный на Core
Вот так вывод! Особенно учитывая, что не просто не оптимизированный, а деоптимизированный.
Вот так вывод! Особенно учитывая, что не просто не оптимизированный, а деоптимизированный.
Кроме того, у 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 с выключенными?
Краткое содержание сегодняшней статьи: компилятор Intel использует по-умолчанию более агрессивные оптимизации, чем компилятор MSVS и поэтому код получается быстрее. Ну надо же, а мы-то не знали! Особенно забавны пространные рассуждения о кол-ве ALU не в тему.
На графике ясно как день видно, что на коде написанном на SSE intrinsics (те оптимизированном вручную — тесты с _ps) оба компилятора показали идентичный результат. Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными?
Такое ощущение, что вас комментарии заставляют писать в качестве наказания, потому, что статью вы, увы, не поняли.
Попробую объяснить медленно и по буквам. Не имеет значения, какой компилятор лучше, какие опции использованы, да и вообще, как именно сделана оптимизация. Важно, что оптимизированный любым способом код, даже таким простейшим, как смена компилятора, может выполняться быстрее на медленном Atome, чем на быстром Core. Всё.
И, судя по рейтингу статьи, многие это поняли.
Попробую объяснить медленно и по буквам. Не имеет значения, какой компилятор лучше, какие опции использованы, да и вообще, как именно сделана оптимизация. Важно, что оптимизированный любым способом код, даже таким простейшим, как смена компилятора, может выполняться быстрее на медленном Atome, чем на быстром Core. Всё.
И, судя по рейтингу статьи, многие это поняли.
И об этом надо было писать статью? Без специалистов Intel мы бы конечно никогда не догадались включить оптимизацию в компиляторе. А то что SSE инструкции быстрее FPU вообще за гранью нашего понимания.
А как на счет разобраться и объяснить почему в тестах sinf, expf и logf ускорение в 6 раз, когда наивно можно предположить в только в 4 раза?
А как на счет разобраться и объяснить почему в тестах sinf, expf и logf ускорение в 6 раз, когда наивно можно предположить в только в 4 раза?
Я уже вижу, что без специалистов Intel вы не догадываетесь, что по умолчанию SIMD оптимизация вЫключена у обоих компиляторов (так что это «Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными? „-неверно) Так что я сомневаюсь, что вы и про остальное “догадаетесь»
Про второй пункт — это тема для отдельного поста. Посмотрю-подумаю.
Про второй пункт — это тема для отдельного поста. Посмотрю-подумаю.
Я не «догадываюсь», а знаю что
1. в Intel Compiler даже по умолчанию включены некоторые SIMD оптимизации (автоматичекая векторизация например)
2. настройки оптимизации Release весьма далеки от настроек по-умолчанию (кстати, список ключей в студию).
Хотя знать тут вовсе не обязательно, можно и догадаться что 6-ти кратный прирост производительности без SIMD оптимизаций в этих тестах просто не возможен.
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 ниже. Для Атома делать не буду, простите, нет времени.
НО! Я в последний раз говорю, что статья совсем не об этом. Я знаю немало случаев, когда компилятор vs обгоняет Intel и не советую использовать наш компилятор в этих случаях. Но это тоже здесь ни при чем. В общем, дискуссия окончена. Еще раз честное спасибо, что меня поправили про SSE По умолчанию. Плюсую ваш комментарий.
Но только дело в том, что компилятор студии даже если я ему принудительно говорю «использовать SSE» Streaming SIMD Extensions 2 (/arch:SSE2), этого должным образом не делает.
Смотрите графики для i5 ниже. Для Атома делать не буду, простите, нет времени.
НО! Я в последний раз говорю, что статья совсем не об этом. Я знаю немало случаев, когда компилятор vs обгоняет Intel и не советую использовать наш компилятор в этих случаях. Но это тоже здесь ни при чем. В общем, дискуссия окончена. Еще раз честное спасибо, что меня поправили про SSE По умолчанию. Плюсую ваш комментарий.
Прошу добавить результаты тестов кода, скомпилированного clang — я видел много коммитов от специалистов Intel в бекенд.
Коллега, а не могли бы вы поделиться проектами с исходниками тестов, использованными в статье, или дать ссылку? Хочется покрутить опции компиляторов самостоятельно.
Да, это возможно. Пришлите адрес в личку.
Единственное — мне не совсем понятен смысл кручения. Реабилитировать компилятор VS? Так я его ни в чем не обвиняю :)
Единственное — мне не совсем понятен смысл кручения. Реабилитировать компилятор VS? Так я его ни в чем не обвиняю :)
Нет, конечно, не сталкивать лбами Интел и Студию, скорее тут простое любопытство. Хочется покрутить опции интеловского компилятора (влючить/выключить оптимизацию, распараллеливание, SSE, и т.д.) и посмотреть как меняется производительность на разных тестах. В случае резкого повышения производительности можно посмотреть какие конструкции и циклы на что влияют. Это даст пищу для размышлений и поможет писать под интел код чуть более оптимально. Ну то есть такая самообразовательная игрушка на долгие зимние вечера.
Вторая причина — хочу часть бенчмарков переписать на LabVIEW и поиграть с ними. Понятно, что производительность будет заметно ниже, да и не все конструкции переносятся в эквивалентный LabVIEW код, но вот какая будет достигнута производительность — любопытно.
Вторая причина — хочу часть бенчмарков переписать на LabVIEW и поиграть с ними. Понятно, что производительность будет заметно ниже, да и не все конструкции переносятся в эквивалентный LabVIEW код, но вот какая будет достигнута производительность — любопытно.
Во-первых, потому, что у Atom сохранилась шина FSBДолжен заметить, что это справедливо только для самых старых атомов.
Начиная с Pine Trail — интегрирован одноканальный контроллер памяти.
Вы не правы. Не поленилась найти вам ссылку на русском www.nix.ru/computer_hardware_news/hardware_news_viewer.html?id=161523
Sign up to leave a comment.
Когда Atom быстрее чем Core?