Извините, ничего не найдено.

Не расстраивайся! Лучше выпей чайку!
Регистрация
Справка
Календарь

Вернуться   www.boolean.name > Программирование игр для компьютеров > C++

Ответ
 
Опции темы
Старый 20.02.2015, 20:48   #1
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 977
Написано 388 полезных сообщений
(для 630 пользователей)
Автоматический оптимизатор

Некоторое время назад, когда в соседней теме я обcуждал возможность более быстрого преобразования данных используя ассемблерные вставки, я столкнулся с критикой, суть которой в том что автоматическая оптимизация в компиляторах настолько умная что может справиться с любым кодом и не требуется
себе мозги лишний раз ебать
. Однако буквально на днях столкнулся по крайне мере с двумя случаями когда оптимизация была бессильна.

Первый случай это векторная обработка данных. Вроде как говорят "просто включи флаги -O3 -msse2" и всё будет ок. На самом деле так не будет (или будет очень редко). Потому что если в программе нет данных которые можно рассувать по xmm регистрам то и не будет ускорения. А эти самые данные из неоткуда не возникнут. В моём случае у меня была функция (софтварный аналог пиксельного шейдера) которая обрабатывала по одному пикселю. Код был не подходящий для векторной обработки, кое-где были типы наподобие float3 которые возможно местами компилятор могбы оптимизировать, но ускорение было бы не такое большое. Чтобы лучше разделить обработку на 4 потока данных я написал новую функцию которая разом обрабатывает сразу 4 пикселя. По сути это было частичное изменение пайплайна рендера, ведь в месте вызова функции и в месте получения данных тоже пришлось изменять код. Но внутри функции удалось несколько сократить рассчёты и главное разместить соответствующие данные вместе. Теперь на выбор есть два варианта: либо включить флаги -msse2 и компилятор сможет адекватно разместить данные по xmm регистрам или же самому вставить ассемблерные вставки или интринсики. Главное здесь то что 80% процентов работы это написание новой функции обрабатывающей по 4 пикселя и частичное изменение пайплайна рендера, и остальные 20% это то что можно потратить на ассемблерные вставки. Вопрос: нужно ли после уже выполнения 4/5 работы воспользоваться оптимизатором и получить в целом ту же производительность, но обфусцированный ассемблерный код?

Второй случай -- создание карты памяти. Карта памяти это когда программист заранее располагает какие-то критические к производительности данные особым образом, например с учётом выравнивания или уплотнения для избежания кеш промахов. У меня было 3 функции, часть данных передавалась через стек, часть через данные-члены общего объекта. Я создал более продуманную структуру которая отображалась на выровненную область памяти. Удалось сократить количество переменных (а это значит трафик по шине памяти) более чем в два раза. Компилятор этого тоже сделать не может и не должен, потому что если ему сказали создать переменную, он её должен создать. Он не может предположить типа "вон та переменная 100 строками выше видимо больше не понадобиться, давай сохраним значение туда". Задача компилятора оптимизировать вещи локальные, например распределение регистров. Думать глобально он не может из за ограниченной области видимости. В то время как относительно-стратегические решения дают более ощутимый результат в производительности. Оптимизация компиляторов скорее связана больше с издержками внутреннего устройства языков. Например преподавание ООП в целом ничего не говорит о том как данные располагаются в памяти, и что при частом применении механизмов RTTI или обращения к vtable будут возникать кеш-промахи. Только когда сталкиваешься с созданием быстрого кода начинаешь узнавать о подобных правилах типа "не пользоваться наследованием, библиотека std слишком тяжёлая" и т. п. Вот в этих случаях оптимизация немного сглаживает ситуацию. Но в целом согласно DOD подходу можно создавать хорошо структурированный код не прибегая к тяжёлым для компилятора ситуациям, не требующим включения оптимизации, и потратив не более чем столько-же времени.
__________________
Config1: Windows 10 x64 / Linux Ubuntu Xenial x64 (Xfce-4); Default Resolution 1920x1080; Intel Core i7 930 @ 2.80GHz; DDR3 9GB Triple; AMD Radeon R9 290 4GB; SSD Ignition 2 120GB; HDD Seagate 1TB.
Config2: Linux Ubuntu Xenial x64 (Xfce-4); Default Resolution 1366x768; Intel Pentium Dual-Core T4400 @ 2.20GHz; DDR2 2GB; NVIDIA GeForce G105M; HDD WD 250GB.
(Offline)
 
Ответить с цитированием
Старый 20.02.2015, 21:56   #2
mr.DIMAS
Дэвелопер
 
Аватар для mr.DIMAS
 
Регистрация: 26.12.2006
Адрес: Санкт-Петербург
Сообщений: 1,569
Написано 544 полезных сообщений
(для 1,527 пользователей)
Ответ: Автоматический оптимизатор

Думать глобально он не может из за ограниченной области видимости
Может:
https://gcc.gnu.org/wiki/LinkTimeOptimization

https://msdn.microsoft.com/en-us/magazine/cc301698.aspx

Вдогонку:
https://ru.wikipedia.org/wiki/%D0%9C...%D0%B8%D1%8 F
__________________
Junior Tools Programmer at Larian Studios
ПеКа: AMD Ryzen 1700X 8@3.4 ГГц, 16 Гб ОЗУ,

NVIDIA GTX 960 4 Гб, SSD Samsung 960 EVO 500 Гб
(Offline)
 
Ответить с цитированием
Старый 20.02.2015, 22:56   #3
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 977
Написано 388 полезных сообщений
(для 630 пользователей)
Ответ: Автоматический оптимизатор

Думать глобально это понимать что происходит, а не выполнять примитивные действия над листингом всей программы.

1 и 2 ссылка это просто штуки которые снимают небольшой оверхед возникающий в случае линковки, компилятор будет видеть код по обе стороны соединения как целое, но это не придает каких то новых качественных изменений в оптимизатор. Первая штука вообще только предоставляет инфу -- там нет оптимизатора, вторая штука работает в бэкенде компилятора, то есть либо с промежуточным трехадресным кодом, либо с ассемблерным кодом, что никак не глобально. Как вариант избежать оверхеда с прилинкованным кодом -- просто не создавать библиотеку в которой находится куча мелких функций вызываемых из программы. Избежание второго -- недопускать неряшливого кода, хотябы чуток думая о том как будет отображаться в памяти и обсчитываться то что ты пишешь. К тому же обе штуки генерят нестандартные объектные файлы что вызовет проблемы с инструментарием который их использует.
3 ссылка ну там описаны действия которые я отнёс к категории "издержки внутреннего устройства языков". Да их можно чуток оптимизировать, но это тоже примитивные действия, которые можно избежать "вручную".

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

Хорошие оптимизаторы появятся тогда, когда изобретут хотябы какой-то ИИ.
__________________
Config1: Windows 10 x64 / Linux Ubuntu Xenial x64 (Xfce-4); Default Resolution 1920x1080; Intel Core i7 930 @ 2.80GHz; DDR3 9GB Triple; AMD Radeon R9 290 4GB; SSD Ignition 2 120GB; HDD Seagate 1TB.
Config2: Linux Ubuntu Xenial x64 (Xfce-4); Default Resolution 1366x768; Intel Pentium Dual-Core T4400 @ 2.20GHz; DDR2 2GB; NVIDIA GeForce G105M; HDD WD 250GB.
(Offline)
 
Ответить с цитированием
Старый 20.02.2015, 23:05   #4
mr.DIMAS
Дэвелопер
 
Аватар для mr.DIMAS
 
Регистрация: 26.12.2006
Адрес: Санкт-Петербург
Сообщений: 1,569
Написано 544 полезных сообщений
(для 1,527 пользователей)
Ответ: Автоматический оптимизатор

Я тебя понял. Вместо того, чтобы взять экскаватор и вырыть траншею, ты берешь детский совочек и роешь ту же траншею в 100 раз медленнее.

А то, что я приводил конкретные цифры в увеличении скорости при автоматической оптимизации ты игнорируешь.

Везде должна быть золотая середина, и автоматическая оптимизация позволяет ее достичь меньшими средствами - то бишь временем.

Неужели нельзя просто взять и использовать оптимизатор, вместо того чтобы доказывать что он ущербный?
__________________
Junior Tools Programmer at Larian Studios
ПеКа: AMD Ryzen 1700X 8@3.4 ГГц, 16 Гб ОЗУ,

NVIDIA GTX 960 4 Гб, SSD Samsung 960 EVO 500 Гб
(Offline)
 
Ответить с цитированием
Старый 20.02.2015, 23:54   #5
Samodelkin
Мастер
 
Регистрация: 12.01.2009
Сообщений: 977
Написано 388 полезных сообщений
(для 630 пользователей)
Ответ: Автоматический оптимизатор

Сообщение от mr.DIMAS Посмотреть сообщение
Я тебя понял. Вместо того, чтобы взять экскаватор и вырыть траншею, ты берешь детский совочек и роешь ту же траншею в 100 раз медленнее.

А то, что я приводил конкретные цифры в увеличении скорости при автоматической оптимизации ты игнорируешь.

Везде должна быть золотая середина, и автоматическая оптимизация позволяет ее достичь меньшими средствами - то бишь временем.

Неужели нельзя просто взять и использовать оптимизатор, вместо того чтобы доказывать что он ущербный?
Нет ты не понял. Я говорю что экскаватор это интрумент и что нужно читать "Технику безопасности при работе на экскаваторе". На нём лучше не заезжать в песочницу строить замки из песка.

Я не игнарирую цифры -- я уже сказал что возможно в код был грязным вот оптимизатор и нашёл достаточно простые ошибки, а может было много данных типа векторов которые удачно легли в соответствующие регистры. В Буллет может вообще флаг оптимизации просто подставляет готовую SSE функцию -- это конкретный случай, надо смотреть.

А вот ты игнарируешь -- я говорю что имея опыт, писать хороший код сразу и сделать асмовставки там где надо займет не больше времени, буков в асме даже иногда меньше печатать. В тоже время в моём случае оптимизация стала возможно после изменения 80% кода вручную.

Если бы я делал всё на ассембелере -- тогда было бы странно, я сделал 2% кода на ассембелере, который занимает до 95% процессорного времени -- вот это Золотая середина.
__________________
Config1: Windows 10 x64 / Linux Ubuntu Xenial x64 (Xfce-4); Default Resolution 1920x1080; Intel Core i7 930 @ 2.80GHz; DDR3 9GB Triple; AMD Radeon R9 290 4GB; SSD Ignition 2 120GB; HDD Seagate 1TB.
Config2: Linux Ubuntu Xenial x64 (Xfce-4); Default Resolution 1366x768; Intel Pentium Dual-Core T4400 @ 2.20GHz; DDR2 2GB; NVIDIA GeForce G105M; HDD WD 250GB.
(Offline)
 
Ответить с цитированием
Старый 20.02.2015, 23:56   #6
mr.DIMAS
Дэвелопер
 
Аватар для mr.DIMAS
 
Регистрация: 26.12.2006
Адрес: Санкт-Петербург
Сообщений: 1,569
Написано 544 полезных сообщений
(для 1,527 пользователей)
Ответ: Автоматический оптимизатор

Далее вести дискуссию считаю бессмысленной тратой времени. Покеда.
__________________
Junior Tools Programmer at Larian Studios
ПеКа: AMD Ryzen 1700X 8@3.4 ГГц, 16 Гб ОЗУ,

NVIDIA GTX 960 4 Гб, SSD Samsung 960 EVO 500 Гб
(Offline)
 
Ответить с цитированием
Старый 21.02.2015, 08:23   #7
Mr_F_
Терабайт исходников
 
Аватар для Mr_F_
 
Регистрация: 13.09.2008
Сообщений: 3,907
Написано 2,157 полезных сообщений
(для 5,843 пользователей)
Ответ: Автоматический оптимизатор

В описанных случаях соглашусь про нужность ручной оптимизации. Автоматическое SSE какое-то вялое и бесполезное, векторный код лучше явно прописывать. Данные раскладывать для наименьших миссов вообще главная задача оптимизации ( https://twitter.com/tom_forsyth/stat...10626462560256 )
__________________
бложик | geom.io | твиттер | faded | демо 1 2 | роботы | лайтмаппер
(Offline)
 
Ответить с цитированием
Ответ


Опции темы

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


Часовой пояс GMT +1, время: 08:08.


vBulletin® Version 3.6.5.
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Перевод: zCarot
Style crйe par Allan - vBulletin-Ressources.com