Я ждала этого вопроса. Единственный ответ — принципиальных непреодолимых сложностей для QSV под Linux нет. Так что НЕ никогда :)
И — не хотите ставить windows, ставьте Mac OS :)
1.Обещают обновить в ближайшее время
2.В апреле этого года купила Samsung Galaxy Note с тем самым 2.3., соответственно больше месяца до официального обновления прожила с 2.3. И, не поверите, никаких проблем не испытывала
3.Ретро нынче в моде, продается даже дороже современных новинок :)
Я посмотрела, вы немного правы, спасибо. Я прошу прощения, невнимательно посмотрела. Да, компилятор Интел использует 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 По умолчанию. Плюсую ваш комментарий.
Я уже вижу, что без специалистов Intel вы не догадываетесь, что по умолчанию SIMD оптимизация вЫключена у обоих компиляторов (так что это «Чему тогда удивляться что Intel с включенными SIMD оптимизациями быстрее MSVS с выключенными? „-неверно) Так что я сомневаюсь, что вы и про остальное “догадаетесь»
Про второй пункт — это тема для отдельного поста. Посмотрю-подумаю.
Да, это возможно. Пришлите адрес в личку.
Единственное — мне не совсем понятен смысл кручения. Реабилитировать компилятор VS? Так я его ни в чем не обвиняю :)
Такое ощущение, что вас комментарии заставляют писать в качестве наказания, потому, что статью вы, увы, не поняли.
Попробую объяснить медленно и по буквам. Не имеет значения, какой компилятор лучше, какие опции использованы, да и вообще, как именно сделана оптимизация. Важно, что оптимизированный любым способом код, даже таким простейшим, как смена компилятора, может выполняться быстрее на медленном Atome, чем на быстром Core. Всё.
И, судя по рейтингу статьи, многие это поняли.
Только что обнаружила — у меня в лабе, оказывается, есть Core примерно такой же частоты, как и Атом -1.7GHz. Сравнивать надо было их, если найду время, сравню и проапдейчу пост.
Только в одном случае — тест «random», для которого, кстати, получить преимущество не удалось. А все математические тесты, в тч и те, на которых видно преимущество, существовали независимо от и задолго до моего исследования. Они — неспециальные, просто такие от природы.
Сравнивать надо яблоки с яблоками, а не с апельсинами, поэтому частоту масштабировать нужно. Но любопытно, что прирост скорости на паре тестов таков, что он перекрывает масштабирование. Т.е. Атом быстрее в абсолютных цифрах!
Если говорить о математически точных выводах, а точнее, о содержании статьи, то надо даже так: «данная версия компилятора intel оптимизирует НЕКОТОРЫЕ ДАННЫЕ ТЕСТЫ с настройками по умолчанию лучше, чем данная версия MSVS». Но вы на то и человек, чтобы сделать более общие выводы, о которых я говорю в ответах на комментарии выше.
Я абсолютно не в курсе результатов продаж нетбуков с Атомами, если у вас есть соответствующие данные — с интересом посмотрю. Но я уверена, что все вышесказанное относится и к тем Атомам, которые ставят в смартфоны. А про их выдающиеся результаты продаж в Европе я знаю. Там раскуплено всё, народ ждет новых поставок.
И — не хотите ставить windows, ставьте Mac OS :)
2.В апреле этого года купила Samsung Galaxy Note с тем самым 2.3., соответственно больше месяца до официального обновления прожила с 2.3. И, не поверите, никаких проблем не испытывала
3.Ретро нынче в моде, продается даже дороже современных новинок :)
Дело не в перемещении, а в том, что FSB осталось.
Но только дело в том, что компилятор студии даже если я ему принудительно говорю «использовать SSE» Streaming SIMD Extensions 2 (/arch:SSE2), этого должным образом не делает.
Смотрите графики для i5 ниже. Для Атома делать не буду, простите, нет времени.
НО! Я в последний раз говорю, что статья совсем не об этом. Я знаю немало случаев, когда компилятор vs обгоняет Intel и не советую использовать наш компилятор в этих случаях. Но это тоже здесь ни при чем. В общем, дискуссия окончена. Еще раз честное спасибо, что меня поправили про SSE По умолчанию. Плюсую ваш комментарий.
Про второй пункт — это тема для отдельного поста. Посмотрю-подумаю.
Единственное — мне не совсем понятен смысл кручения. Реабилитировать компилятор VS? Так я его ни в чем не обвиняю :)
Попробую объяснить медленно и по буквам. Не имеет значения, какой компилятор лучше, какие опции использованы, да и вообще, как именно сделана оптимизация. Важно, что оптимизированный любым способом код, даже таким простейшим, как смена компилятора, может выполняться быстрее на медленном Atome, чем на быстром Core. Всё.
И, судя по рейтингу статьи, многие это поняли.
всё остальное- ваши ничем не обоснованные домыслы, или поясните пожалуйста вашу мысль
Если говорить о математически точных выводах, а точнее, о содержании статьи, то надо даже так: «данная версия компилятора intel оптимизирует НЕКОТОРЫЕ ДАННЫЕ ТЕСТЫ с настройками по умолчанию лучше, чем данная версия MSVS». Но вы на то и человек, чтобы сделать более общие выводы, о которых я говорю в ответах на комментарии выше.