Comments 27
Очень правильно сравнивать последний C++ Compiler с древним GCC 4.1.
А что насчёт GCC 5.0? Clang? Стало страшно?
А что насчёт GCC 5.0? Clang? Стало страшно?
Спасибо, очень полезная информация. Лишний раз убеждаюсь, что в эти дебри лучше не лезь, а полагаться на BLAS-библиотеки.
Однако не всегда данные и алгоритмы можно свести с операциями над матрицами и тут уже библиотеки не помогут. Когда-то я занимался стохастическим моделированием, основная проблема была в асинхронности операций. Т.е. кусок данных в двумерном/трехмерном массиве выбирался случайным образом и только после его обработки можно было бы переходить к следующей порцие данных, поэтому параллельно обрабатывать весь массив нельзя, а кэш процессора постоянно обновляется. :( Тут бы пригодилась какая-то страничная организация кэша.
Однако не всегда данные и алгоритмы можно свести с операциями над матрицами и тут уже библиотеки не помогут. Когда-то я занимался стохастическим моделированием, основная проблема была в асинхронности операций. Т.е. кусок данных в двумерном/трехмерном массиве выбирался случайным образом и только после его обработки можно было бы переходить к следующей порцие данных, поэтому параллельно обрабатывать весь массив нельзя, а кэш процессора постоянно обновляется. :( Тут бы пригодилась какая-то страничная организация кэша.
Имхо, делать оптимизации учитывающие особенности архитектуры процессора, которые [скорее всего?] скрыты стандартом языка в с++ коде — просто ужасно.
Это не ужасно, это мир High Performance Computing.
Глупо было бы не воспользоваться деталями архитектуры и выжать максимум производительности там, где это оправдано и даёт существенную выгоду.
Это реальность не только High Performance Computing, но и многих интерактивных приложений типа игр.
Оставьте ваш юношеский романтизм и идеализм :-)
Это реальность не только High Performance Computing, но и многих интерактивных приложений типа игр.
Оставьте ваш юношеский романтизм и идеализм :-)
Всё-таки, я считаю, лучше тогда уж писать на ассемблере или пользоваться библиотеками, на нем написанными. В примере с матрицами, скорее всего, лучший результат дал бы алгоритм Штрассена (но применительно к разностным уравнениям вопросов нет =)
Человек не сможет оптимизировать на ассемблере лучше компилятора.
Компилятор знает и длины инструкций, размеры кэша и прочие параметры.
Грамотно написанная функция на C++ транслируется в лучший ассемблерный код.
Компилятор знает и длины инструкций, размеры кэша и прочие параметры.
Грамотно написанная функция на C++ транслируется в лучший ассемблерный код.
Человек не сможет оптимизировать на ассемблере лучше компилятора.
Какое категоричное заявление!
А ничего, что люди, писавшие компилятор решали общую задачу, которая значительно сложнее чем те частные случаи, которые стоит писать на ассемблере? Не приходило в голову, что вылизать до идеала (например, с помощью того же Intel VTune Amplifier'а) 100 — 150 строк значительно проще, чем написать компилятор, который будет генерировать сопоставимый по производительности код?
Не задумывался на тем что люди вообще делают с помощью Intel VTune? Зачем они его покупают?
Если компилятор не может что-то соптимизировать — это проблемы компилятора :)
Я согласен, что есть кейсы, когда требуется решение, а компилятор не может его дать — приходится писать разработчикам, попутно используя собственный код на ассемблере.
Я и сам периодически использую VTune — как раз чтобы посмотреть, что сгенерировалось, и как можно улучшить оригинальный код на Си, чтобы сгенерировалось что-то лучше. Чаще всего редактирование именно Си-кода позволяет достичь нужных результатов.
Я согласен, что есть кейсы, когда требуется решение, а компилятор не может его дать — приходится писать разработчикам, попутно используя собственный код на ассемблере.
Я и сам периодически использую VTune — как раз чтобы посмотреть, что сгенерировалось, и как можно улучшить оригинальный код на Си, чтобы сгенерировалось что-то лучше. Чаще всего редактирование именно Си-кода позволяет достичь нужных результатов.
1) Какие ваши доказательства?©
Человек может задать любую последовательность инструкций. Компилятор крайне ограничен.
2) Человек знает куда больше, включая контекст. Компилятору сейчас максимум конкретную микроархитектуру можно задать, но размер L2/LLC везде разный.
3) см п.1
Человек может задать любую последовательность инструкций. Компилятор крайне ограничен.
2) Человек знает куда больше, включая контекст. Компилятору сейчас максимум конкретную микроархитектуру можно задать, но размер L2/LLC везде разный.
3) см п.1
это если:
а. человек — профессионал, который гарантированно не допустит ошибку, не пропустит возможность оптимизации и отлично знает особенности архитектуры
в. существует достаточное количество выделенных на проект часов, чтобы писать его на асме, под каждую отдельно взятую целевую платформу и архитектуру.
а. человек — профессионал, который гарантированно не допустит ошибку, не пропустит возможность оптимизации и отлично знает особенности архитектуры
в. существует достаточное количество выделенных на проект часов, чтобы писать его на асме, под каждую отдельно взятую целевую платформу и архитектуру.
Если бы лучше было писать на ассемблере, никто бы не изобретал С или С++. Не стоит вдаваться в крайности, лучше использовать каждый инструмент гибко там, где это необходимо. Писать всё подряд на ассемблере неоправдано по времени. Правильный подход такой: С++, профилирование программы, определение «узких мест», оптимизация одним из возможных способов. И да, самые быстрые библиотеки для линейной алгебры написаны на C++ с небольшим добавлением intrinsics
Не менее чем делать треугольную крышку для квадратной банки.
А где же кодстайл хоть какой-то? То есть пробелы после операторов, то нет
Читаю очередную статью про оптимизацию, и возникает странное чувство что люди их читают и сознательно делают все наоборот.
Запускаем практически любую игрушку (онлайн с клиентом на ПК), и уже на экране ввода логина-пароля комп начинает взлетать на вентиляторах :).
По ощущениям, половина этих игрописателей, не знают даже про оптимизацию на уровне циклов и подпрограмм. Вынесение 1й формулы за тело цикла может дать прирост производительности сравнимый со всем описанным в статье. Отимизировать надо в первую очередь алгоритмы и код.
p.s. Это критика не статьи, а современных тенденций в программировании, когда сначала лажают в коде со словами «компилятор сам соптимизирует», а потом удивляются «а чё оно тормозит?».
Запускаем практически любую игрушку (онлайн с клиентом на ПК), и уже на экране ввода логина-пароля комп начинает взлетать на вентиляторах :).
По ощущениям, половина этих игрописателей, не знают даже про оптимизацию на уровне циклов и подпрограмм. Вынесение 1й формулы за тело цикла может дать прирост производительности сравнимый со всем описанным в статье. Отимизировать надо в первую очередь алгоритмы и код.
p.s. Это критика не статьи, а современных тенденций в программировании, когда сначала лажают в коде со словами «компилятор сам соптимизирует», а потом удивляются «а чё оно тормозит?».
Про онлайн не скажу, не имел опыта, но во многих игрушках для меня сейчас более загадочно то, что все по прежнему (похоже) пишут под однопроцесорные калькуляторы с считанными байтами оперативки. Куча игр, в которых весь игровой уровень можно впихнуть в десяток килобайт и при этом загрузки каждого приходится ждать ооочень ощутимое время. Особенно доставляет при линейном порядке прохождения.
Какая оптимизация того, чего мы не видим, если никто не задумывается о том, что отлично видно?
Какая оптимизация того, чего мы не видим, если никто не задумывается о том, что отлично видно?
По моему наоборот. Если бы писали под «калькуляторы», то на современном железе все летало бы. А так тормозит даже то, где тормозить нечему абсолютно (выше пример с экраном логина).
И, в основном связано это с тем убеждением, что время программиста афигеть какое дорогое чтоб еще и с оптимизацией заморачиваться, а современное железо все стерпит. (тормозит тетрис — докупите еще 16 Гб памяти :))
Это что это за игрушки такие?
Сходу вспоминаются Nuclear throne, например, или Enter the gungeon. Там уровни генерятся, но вполне последовательно. Что мешает делать это параллельно игре в низкоприоритетном треде непонятно.
Broforce вообще линеен, уровни побольше, но тоже должны читаться в момент даже без лишних заморочек. Это что сразу вспомнил.
Собственно в любой игре, в которой имеется ограниченное количество проходов в другие локации — предзагрузка не проблема. Хотя ГТА, Ведьмак или Minecraft отлично демонстрируют, что и с неограниченным количеством это тоже вполне решаемо.
Broforce вообще линеен, уровни побольше, но тоже должны читаться в момент даже без лишних заморочек. Это что сразу вспомнил.
Собственно в любой игре, в которой имеется ограниченное количество проходов в другие локации — предзагрузка не проблема. Хотя ГТА, Ведьмак или Minecraft отлично демонстрируют, что и с неограниченным количеством это тоже вполне решаемо.
Я то думал вы о каких-то ААА играх, где я проблем с выжимкой последних флопсов из железа не припомню. Этот то шлак инди конечно, может тормозить и тупить на ровном месте. Broforce вон на консоли так портировали, что аж 15 фпс бывает. Люди не особо способные делают, плюс технология частенько мешает. Тот же юнити довольно тормозная штука.
Ну шлаком бы я их не назвал. Весьма неплохие игрушки. По мне так с точки зрения собственно игрового процесса многие ААА как раз коммерческий шлак, но это дело вкуса.
ААА? Да любые практически обвиняют в лагах и тормозах. Некоторые вроде Бэтмена даже снимали временно с продажи из-за того что играть невозможно.
ААА? Да любые практически обвиняют в лагах и тормозах. Некоторые вроде Бэтмена даже снимали временно с продажи из-за того что играть невозможно.
Ну если говорить о том, о чем изначально речь «не знают даже про оптимизацию на уровне циклов и подпрограмм», то это к крупным проектам никак не относится. Там все это прекрасно знают и, собственно, являются авторами многих как раз оптимизации, потому что именно ААА студии и их R&D отделы двигают эту отрасль.
Бетмен же — консольные версии там работали отлично, где я и играл. А ПК версию делали как получится, поэтому и получилось как получилось. ПК все еще не является приоритетной платформой во многих случаях.
Бетмен же — консольные версии там работали отлично, где я и играл. А ПК версию делали как получится, поэтому и получилось как получилось. ПК все еще не является приоритетной платформой во многих случаях.
А еще есть страшный враг векторизации который называется «указатели». иногда компилятор не может доказать что массивы не пересекаются и отказывается генерировать хороший код.
При уровне оптимизации O2 и компилятор Intel, и gcc* создают векторизованный код, использующий регистры SIMD
А разве не надо явно указывать -msse -msse2?
Так когда же наконец у вас там выйдут процессора с поддержкой AVX512?
Sign up to leave a comment.
Приводим данные и код в порядок: оптимизация и память, часть 1