Comments 11
По моему скромному мнению, довольно жестоко такую статью на Хабр вставлять, потому что от силы 0.05% посетителей её смогут понять.
Разве не хардкорные статьи делают хабр тортом?
Помимо возможности насыпать минусов в карму комментатору в знак несогласия с его мнением, тортом Хабр делают научпоп-статьи + хардкорные статьи написанные о какой-то вещи, знакомой и ковыряемой многими. Будь то ЯП или БД.
Ну либо чистый интеллект, алгоритмы и вот это всё. А в статье вышше чуть ли не RFC выложили — достатчно сухой технический текст, который реально может быть интересен и понятен сотрудникам Интела + нескольким чувакам из МЦСТ и СМ Варе.
Я понимаю что статья опубликована в блоге Интела, и размещать они имеют полное право — но вот не форматная она всё равно, это я и хочу сказать.
Ну либо чистый интеллект, алгоритмы и вот это всё. А в статье вышше чуть ли не RFC выложили — достатчно сухой технический текст, который реально может быть интересен и понятен сотрудникам Интела + нескольким чувакам из МЦСТ и СМ Варе.
Я понимаю что статья опубликована в блоге Интела, и размещать они имеют полное право — но вот не форматная она всё равно, это я и хочу сказать.
Абсолютно не согласен. Эта статья очень полезна людям занимающимся высокопроизводительными вычислениями. Их не так уж мало.
Плюс. Даже если уравнения в частных производных — не то, чем человек занимается каждый день — на этом примере можно многое понять об используемых инструментах, стратегиях, возможных увеличениях производительности. О самой задаче здесь 5%. Анализ отчетов компилятора и вспомогательных инструментов — 95%.
Плюс. Даже если уравнения в частных производных — не то, чем человек занимается каждый день — на этом примере можно многое понять об используемых инструментах, стратегиях, возможных увеличениях производительности. О самой задаче здесь 5%. Анализ отчетов компилятора и вспомогательных инструментов — 95%.
Ммм, статья вроде про то, как найти узкие места в коде, и выжать побольше производительности. Не всем это будет интересно, конечно, но в целом тема более чем актуальна.
И да, возможно статья «суховата», но лучше сухая статья чем очередная реклама гаджета или перевод очередного туториала по базовым структурам данных.
И да, возможно статья «суховата», но лучше сухая статья чем очередная реклама гаджета или перевод очередного туториала по базовым структурам данных.
Возник вопрос: почему CPI=0.75 сигнализирует о полном использовании возможностей конвейера для данной (?) архитектуры? Как это считается?
Однако, у опции –no-prec-div имеется одна проблема. Иногда после этой оптимизации полученные значения не так точны, как при использовании обычного деления по стандарту IEEE. Если для целей приложения важна точность, используйте эту опцию для отключения оптимизации, что приведёт к более точным результатам с некоторым падением производительности.
Несколько странный абзац. Насколько я понимаю, опция -no-prec-div позволяет использовать доп. оптимизации с потерей точности. И, следовательно, наоборот: если для целей приложения важна точность, не нужно использовать эту опцию. Наоборот, можно поставить опцию -prec-div (идет по дефолту, вроде как).
Эти испытания показали, что чем больше сетка – тем больше и рост производительности, достигаемый благодаря автоматической векторизации. Это важный вывод, так как реальные задачи требуют большей точности, а значит, и больших сеток.
Чуть-чуть позанудствую, скорее всего, имеется ввиду не больших сеток — а более плотных (dense) сеток. Дабы узлов для аппроксимации производных было больше. Большая сетка — я читаю больше как большая по физическому размеру.
И, вдобавок, для достижения большей точности — увеличение плотности сетки не единственный способ. Увеличение порядка аппроксимации производных часто приводит к большему эффекту. Хотя это вопрос не об оптимизации кода, а вопросы численного анализа.
Какой компилятор использовали?
Насколько я понял, эту тему особо не поддерживают.
Практически уверен, что использовался компилятор Intel Fortran\Intel C++ из Intel Parallel Studio.
Таким образом это Intel Fortran Composer XE 2015 — версия 15, точный номер зависит от установленного апдейта.
(ибо инструменты анализа Intel VTune, Intel Parallel Advisor входят в этот комплект и в основном работают с этим компилятором и упоминается Intel Parallel Studio XE 2015)
Практически уверен, что использовался компилятор Intel Fortran\Intel C++ из Intel Parallel Studio.
Таким образом это Intel Fortran Composer XE 2015 — версия 15, точный номер зависит от установленного апдейта.
(ибо инструменты анализа Intel VTune, Intel Parallel Advisor входят в этот комплект и в основном работают с этим компилятором и упоминается Intel Parallel Studio XE 2015)
Sign up to leave a comment.
Инструменты Intel для оптимизации приложений и задача о течениях в пористых средах