Здравствуйте, 4058, Вы писали:

4>-O3 включает автовекторизацию в GCC, но для дефолтового профиля x86-64 заиспользует что-то по мелочи из SSE2 (дальше надо ключи указывать)

Я тоже за ключи и автовекторизацию, бо если использовать некие расширения через интристики явно, то мы отрубаем возможность автовекторизации на будущих стандартах SIMD.


V>>MKL даёт прирост от наихудшей наивной реализации в ~10 раз.
4>Это имеет смысл обсуждать при наличии соответствующего теста.

Их есть в сети, разница примерно в 10 раз, как я и звучил.


V>>Но что здесь внушает оптимизм — при улучшении компилятора можно перепрогонять им софт и получать профит, не меняя ни исходники, ни железо.
4>Я не просто чуть ранее упомянул Cell, ибо там тоже делалась ставка на компилятор и SDK

Я на это уже отвечал — сама архитектура Cell не позволяет проектировать код в привычной манере.
А Эльбрус позволяет, поддерживаемый стандарт на сегодня C++14.

Причём, те же трюки, которые могут повысить производительность в amd_x64 (например, удачная стратегия прохода памяти, уменьшение кол-ва записей в нелокальные переменные и т.д.) точно так же даёт профит и для Эльбруса. В этом смысле можно позволять себе работать в привычной манере, вылизывая только по-настоящему горячие числодробительные циклы через профилировщик. Кстате, PGO на Эльбрусе даёт неплохой профит, по слухам. Увы, лично еще не играл.


4>которые постоянно будут улучшать, тем самым постепенно раскрывая потенциал SPE (все уши тогда этим прожужали), в результате следующее поколение консолей PS4/X1 тупо получили AMD64 (причем с в 2 раза меньшей тактовой частотой).

К следующему поколению консолей подоспели уже произвольные вычисления в графических ускорителях и весь тулчейн для этого, в отличие от ограниченного инструмента шейдеров в жестком данном сверху алгоритме рендеринга, как оно было ранее. Т.е. на новых поколениях графики задачи для Cell стало можно решать и без Cell.