Разное > Оффтопик
Дискуссия на тему производительности DF
Holkin:
--- Цитата: Dj007I от 19 Августа 2015, 22:13:08 ---всё это говно
--- Конец цитаты ---
На минуточку одна из игр с самой глубокой механикой, которую пытались клонировать, но не смогли.
Holkin:
--- Цитата: Andys от 21 Августа 2015, 06:20:39 ---Я в печали... и зачем я писал "возможно" и "Зависит, конечно, от того, насколько ДФ похожа на ту программу, для которой составлялся график", если это никто не читает?
--- Конец цитаты ---
Так как раз прочли. Одну лишь ссылку на рекламный проспект я бы не комметировал. А так мне стало интересно что там в деталях и как это в принципе можно было сделать. Запостить решил только затем, что это Интернет и всегда рядом может пробежать какой-нибудь эксперт в экзотических областях, поразиться неведению обывателей (т.е. моему) и рассказать много интересного. Да и изначальная ссылка на материал наверное с той же целью была.
Andys:
--- Цитата: Holkin от 21 Августа 2015, 21:35:17 ---
--- Цитата: Andys от 21 Августа 2015, 06:20:39 ---Я в печали... и зачем я писал "возможно" и "Зависит, конечно, от того, насколько ДФ похожа на ту программу, для которой составлялся график", если это никто не читает?
--- Конец цитаты ---
Так как раз прочли. Одну лишь ссылку на рекламный проспект я бы не комметировал. А так мне стало интересно что там в деталях и как это в принципе можно было сделать. Запостить решил только затем, что это Интернет и всегда рядом может пробежать какой-нибудь эксперт в экзотических областях, поразиться неведению обывателей (т.е. моему) и рассказать много интересного. Да и изначальная ссылка на материал наверное с той же целью была.
--- Конец цитаты ---
"В принципе" - имо, ускорение выполнения вполне реально, но не за счет некоей фиктивной технологии, а за счет ручной оптимизации машинных команд. В силу своего хобби, мне часто приходится дизассемблировать и дебагить экзешники. И, из того, что я видел - процесс компиляции вполне мог бы выиграть за счет человека, проглядывающего конечный бинарник и тупо вырезающего лишнее. Чего стоят встреченные мной (не в дф) последовательности команд типа:
--- Код: ---mov eax, [xxxxx]
mov ecx, [xxxxx]
mov ecx, eax
// ну то есть, вторая команда - абсолютно лишняя, ибо в ecx слежующей строчкой записывается другое значение
--- Конец кода ---
И это не считая ненужных в некоторых местах DIV и MUL (за которые меня трахали на сдаче зачета в универе, ибо они жрут дохера тактов...). Но это я так, отвлекся.
На самом деле - нам нужна жертва, которую мы заставим потратить 28к на процессор и 10к на матплату, ибо они уже продаются. И тогда мы все узнаем из первых рук :)
А так, по хорошему - что мешает написать некий алгоритм, который прочтет весь машинный код, выделит некие области кода, которые могут выполняться параллельно, и запустит их на разных ядрах одновременно (без вмешательства этого исходного процесса). Дело только за этой обработкой и сложностью исходного алгоритма.
Возможно, что авторы теста запускали что-то типа "обычной офисной нагрузки", а не калькулятор с расчетом 999999!. Поскольку деталей теста нет, а ДФ все же посложнее расчета факториала, то остается надеяться, о чем я и говорил раньше. Я предпочитаю надеяться, да.
Holkin:
DIV и MUL должны много жрать на микроконтроллерах и старых процессорах. Умножение точно можно за два такта сделать и оно уже наверняка сделано, с делением так красиво не получается, но оптимизация тоже есть. По тактам эти операции можно считать быстрыми, т.к. кеш промах это на порядок или два больше, а страничный промах это еще на два-три порядка сверху.
Компиляторы неидеальны, это действительно так. Но все эти оптимизации, которые можно сделать просто посмотрев на код, в компилятор добавляются постоянно. Ну по крайней мере почему бы разработчикам компиляторов этого не делать.
Еще есть такая штука, что 90% кода выполняется 10% всего времени, так что нужно знать где оптимизировать. И если человек столько лет уже разрабатывает игру и она у него уперлась в производительность, то он наверняка над этим думал.
Анализировать исполняемый код на возможность распараллеливания это идея интересная. В прицнипе это то чем занимается вычислительная техника последние лет 40. Просто я тут на позициях скептика, который считает что все уже давно придумано, а реализовано только то, что экономически выгодно. Оно вероятно не так.
insolor:
--- Цитата: Holkin от 23 Августа 2015, 12:15:12 ---DIV и MUL должны много жрать на микроконтроллерах и старых процессорах. Умножение точно можно за два такта сделать и оно уже наверняка сделано, с делением так красиво не получается, но оптимизация тоже есть. По тактам эти операции можно считать быстрыми, т.к. кеш промах это на порядок или два больше, а страничный промах это еще на два-три порядка сверху.
Компиляторы неидеальны, это действительно так. Но все эти оптимизации, которые можно сделать просто посмотрев на код, в компилятор добавляются постоянно. Ну по крайней мере почему бы разработчикам компиляторов этого не делать.
Еще есть такая штука, что 90% кода выполняется 10% всего времени, так что нужно знать где оптимизировать. И если человек столько лет уже разрабатывает игру и она у него уперлась в производительность, то он наверняка над этим думал.
Анализировать исполняемый код на возможность распараллеливания это идея интересная. В прицнипе это то чем занимается вычислительная техника последние лет 40.
--- Конец цитаты ---
Соглашусь, оптимизировать нужно не код, а алгоритмы. Если выбран неоптимальный алгоритм, то идеальный машинный код тут не спасет. И даже суперумный компилятор заменить неоптимальный алгоритм на оптимальный не сможет.
По поводу оптимизаций компилятором - иногда хочется убить тех, кто их реализовывал. Вот, например, функция на 200 строк, которая пытается учесть все варианты оптимизаций тупо кода инициализации строки. >:(
--- Цитата: Holkin от 23 Августа 2015, 12:15:12 ---Просто я тут на позициях скептика, который считает что все уже давно придумано, а реализовано только то, что экономически выгодно. Оно вероятно не так.
--- Конец цитаты ---
А вот это не понял. Взаимоисключающие параграфы?
Навигация
Перейти к полной версии