Форум Dwarf Fortress

Разное => Оффтопик => Тема начата: Andys от 19 Августа 2015, 13:51:11

Название: Дискуссия на тему производительности DF
Отправлено: Andys от 19 Августа 2015, 13:51:11
Увидел вот это : В процессорах Intel Skylake реализован «обратный Hyper-Threading» (http://www.3dnews.ru/918787?from=related-grid&from-source=918860)
Возможно, фпс-смерть нам не грозит, см. график и разницу в производительности при одном нагруженном потоке.
Если раньше это было в виде идеи, не доходящей до масс, то сейчас уже появились реальные процессоры, которые можно будет купить без продажи почки.
Зависит, конечно, от того, насколько ДФ похожа на ту программу, для которой составлялся график, но появилась хотя бы надежда...
Пока что не вижу в инете, чтобы кто-то тестировал ДФ на новых процах, придется ждать появления в продаже
Название: Re: Дискуссия на тему производительности DF
Отправлено: Midas от 19 Августа 2015, 14:24:55
Andys, интересно.
Вот узнает Тоади про такую штуку, купит, обрадуется возросшей производительности ДФ и с хихиканьем добьет ФПС до привычного уровня, но уже на новом навороченном процессоре.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Holkin от 19 Августа 2015, 15:08:34
Увидел вот это : В процессорах Intel Skylake реализован «обратный Hyper-Threading» (http://www.3dnews.ru/918787?from=related-grid&from-source=918860)
Имея некоторый знания в области, нифига не могу понять чего нового и радикального они придумали и главное чем оно может помочь ДФ.
Что бы вы понимали, гипертрединг это штука, которая может быстро переключить контекст между потоками выполнения. Пока один поток ожидает выполнения длинной команды, процессор мог бы перемножить сотню (а то и тысячу пар чисел). Вот это время простоя можно заполнить если по-умному переключать потоки выполнения. Беда в том, что само переключение затратное. Ну им удалось это сделать менее затратным, да еще и уровнем пониже операционной системы (это всегда считалось круто, но часто экономически нецелесообразно).
Теперь они хотят сказать, что они собираются один поток раздробить как только можно? Так это вроде уже давно все сделано. Пока команда выполняется там рядом уже загружена и подготовлена следующая. Именно поэтому они пишут частоту 3 ГГц когда там реально на порядок меньше. А распределить 100 однообразных операций на два потока может и не получиться, если там имеется зависимость по данным. А если там зависимость или нет лучше всего определяется на этапе компиляции программы, в рантайме это не то чтобы нереально, но крайне маловероятно что кто-то когда-то этим будет заниматься (если покопаться, то можно найти чудесное направление развития вычислительной техники, которое зашло в тупик, можно даже фильм снять как мировые корпорации сговорились против dataflow).
Единственных их шанс это избыточность вычислений для ситуаций типа "если А то Б иначе В", когда А, Б и В выполняются параллельно, а потом А решает кто из Б или В прав. Но это в свою очередь гарантирует конфликты  для Б и В (а может и А) доступа к ресурсам.
Если у них получится, то ДФ можно будет повысить производительность. Но это фокусы высшего пилотажа.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Dj007I от 19 Августа 2015, 22:13:08
Может не подбирать процессоры под дф, а поймать и заставить жабу переписать к следующему релизу всё это говно под многопоточность.
Название: Re: Дискуссия на тему производительности DF
Отправлено: insolor от 20 Августа 2015, 00:53:52
Может не подбирать процессоры под дф, а поймать и заставить жабу переписать к следующему релизу всё это говно под многопоточность.
Ага, и ждать следующего релиза лет десять.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Holkin от 20 Августа 2015, 10:25:16
всё это говно
На минуточку одна из игр с самой глубокой механикой, которую пытались клонировать, но не смогли.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Holkin от 21 Августа 2015, 21:35:17
Я в печали... и зачем я писал "возможно" и "Зависит, конечно, от того, насколько ДФ похожа на ту программу, для которой составлялся график", если это никто не читает?
Так как раз прочли. Одну лишь ссылку на рекламный проспект я бы не комметировал. А так мне стало интересно что там в деталях и как это в принципе можно было сделать. Запостить решил только затем, что это Интернет и всегда рядом может пробежать какой-нибудь эксперт в экзотических областях, поразиться неведению обывателей (т.е. моему) и рассказать много интересного. Да и изначальная ссылка на материал наверное с той же целью была.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Andys от 22 Августа 2015, 01:56:33
Я в печали... и зачем я писал "возможно" и "Зависит, конечно, от того, насколько ДФ похожа на ту программу, для которой составлялся график", если это никто не читает?
Так как раз прочли. Одну лишь ссылку на рекламный проспект я бы не комметировал. А так мне стало интересно что там в деталях и как это в принципе можно было сделать. Запостить решил только затем, что это Интернет и всегда рядом может пробежать какой-нибудь эксперт в экзотических областях, поразиться неведению обывателей (т.е. моему) и рассказать много интересного. Да и изначальная ссылка на материал наверное с той же целью была.
"В принципе" - имо, ускорение выполнения вполне реально, но не за счет некоей фиктивной технологии, а за счет ручной оптимизации машинных команд. В силу своего хобби, мне часто приходится дизассемблировать и дебагить экзешники. И, из того, что я видел - процесс компиляции вполне мог бы выиграть за счет человека, проглядывающего конечный бинарник и тупо вырезающего лишнее. Чего стоят встреченные мной (не в дф) последовательности команд типа:
mov eax, [xxxxx]
mov ecx, [xxxxx]
mov ecx, eax
// ну то есть, вторая команда - абсолютно лишняя, ибо в ecx слежующей строчкой записывается другое значение
И это не считая ненужных в некоторых местах DIV и MUL (за которые меня трахали на сдаче зачета в универе, ибо они жрут дохера тактов...). Но это я так, отвлекся.
На самом деле - нам нужна жертва, которую мы заставим потратить 28к на процессор и 10к на матплату, ибо они уже продаются. И тогда мы все узнаем из первых рук :)

А так, по хорошему - что мешает написать некий алгоритм, который прочтет весь машинный код, выделит некие области кода, которые могут выполняться параллельно, и запустит их на разных ядрах одновременно (без вмешательства этого исходного процесса). Дело только за этой обработкой и сложностью исходного алгоритма.
Возможно, что авторы теста запускали что-то типа "обычной офисной нагрузки", а не калькулятор с расчетом 999999!. Поскольку деталей теста нет, а ДФ все же посложнее расчета факториала, то остается надеяться, о чем я и говорил раньше. Я предпочитаю надеяться, да.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Holkin от 23 Августа 2015, 12:15:12
DIV и MUL должны много жрать на микроконтроллерах и старых процессорах. Умножение точно можно за два такта сделать и оно уже наверняка сделано, с делением так красиво не получается, но оптимизация тоже есть. По тактам эти операции можно считать быстрыми, т.к. кеш промах это на порядок или два больше, а страничный промах это еще на два-три порядка сверху.
Компиляторы неидеальны, это действительно так. Но все эти оптимизации, которые можно сделать просто посмотрев на код, в компилятор добавляются постоянно. Ну по крайней мере почему бы разработчикам компиляторов этого не делать.
Еще есть такая штука, что 90% кода выполняется 10% всего времени, так что нужно знать где оптимизировать. И если человек столько лет уже разрабатывает игру и она у него уперлась в производительность, то он наверняка над этим думал.
Анализировать исполняемый код на возможность распараллеливания это идея интересная. В прицнипе это то чем занимается вычислительная техника последние лет 40. Просто я тут на позициях скептика, который считает что все уже давно придумано, а реализовано только то, что экономически выгодно. Оно вероятно не так.
Название: Re: Дискуссия на тему производительности DF
Отправлено: insolor от 23 Августа 2015, 13:54:19
DIV и MUL должны много жрать на микроконтроллерах и старых процессорах. Умножение точно можно за два такта сделать и оно уже наверняка сделано, с делением так красиво не получается, но оптимизация тоже есть. По тактам эти операции можно считать быстрыми, т.к. кеш промах это на порядок или два больше, а страничный промах это еще на два-три порядка сверху.
Компиляторы неидеальны, это действительно так. Но все эти оптимизации, которые можно сделать просто посмотрев на код, в компилятор добавляются постоянно. Ну по крайней мере почему бы разработчикам компиляторов этого не делать.
Еще есть такая штука, что 90% кода выполняется 10% всего времени, так что нужно знать где оптимизировать. И если человек столько лет уже разрабатывает игру и она у него уперлась в производительность, то он наверняка над этим думал.
Анализировать исполняемый код на возможность распараллеливания это идея интересная. В прицнипе это то чем занимается вычислительная техника последние лет 40.
Соглашусь, оптимизировать нужно не код, а алгоритмы. Если выбран неоптимальный алгоритм, то идеальный машинный код тут не спасет. И даже суперумный компилятор заменить неоптимальный алгоритм на оптимальный не сможет.

По поводу оптимизаций компилятором - иногда хочется убить тех, кто их реализовывал. Вот, например, функция на 200 строк (https://bitbucket.org/dfint/dfrus-py/src/d6d65a64ba6ce15059c497d9de03d856bc01b3e3/patchdf.py?at=default#patchdf.py-109), которая пытается учесть все варианты оптимизаций тупо кода инициализации строки. >:(
Просто я тут на позициях скептика, который считает что все уже давно придумано, а реализовано только то, что экономически выгодно. Оно вероятно не так.
А вот это не понял. Взаимоисключающие параграфы?
Название: Re: Дискуссия на тему производительности DF
Отправлено: FearOfTheLight от 23 Августа 2015, 18:10:45
вечный двигатель и многоразовая бумага давно придумана, но её никто не производит т.к. прибыль это не несёт(долгосрочную по крайней мере). так и с процами/компиляторами. компилятор с++ от intel стоит много, компилит хорошо но начинает "высчитывать смысл жизни" если завидит AMD или другие. да и многие алгоритмы после изобретения покрываются NDA чтобы конкуренты не прознали, а другим приходится заново изобретать похожее во имя прогресса или профита.
Название: Re: Дискуссия на тему производительности DF
Отправлено: nadeys от 26 Августа 2015, 16:50:20
Продолжу ваш оффтоп грустной новостью - "Intel представила новый Xeon E7 v4 24 ядра и частота 2500 МГц."

Если шас на одном ядре у меня 30 бород при 100 фпс, то при 24 ядрах... это... это... 720 бород! Вот такая грустная новость D:
Название: Re: Дискуссия на тему производительности DF
Отправлено: insolor от 26 Августа 2015, 17:03:28
Продолжу ваш оффтоп грустной новостью - "Intel представила новый Xeon E7 v4 24 ядра и частота 2500 МГц."

Если шас на одном ядре у меня 30 бород при 100 фпс, то при 24 ядрах... это... это... 720 бород! Вот такая грустная новость D:
Ну да, все правильно: 720 бород при 4 фпс.
P.S. Если бы "бороды" были абстрактными акторами, общающимися со внешним миром только посредством посылки сообщений - то они отлично бы распараллелились на все 24 ядра. А так - 24 ядра не означают увеличения производительности в 24 раза.
Название: Re: Дискуссия на тему производительности DF
Отправлено: FearOfTheLight от 26 Августа 2015, 18:00:50
нужно заразить жаба эрлангом. слава многопоточность! слава параллелизм!
https://www.youtube.com/watch?v=xrIjfIjssLE
Название: Re: Дискуссия на тему производительности DF
Отправлено: Holkin от 27 Августа 2015, 04:16:37
P.S. Если бы "бороды" были абстрактными акторами, общающимися со внешним миром только посредством посылки сообщений - то они отлично бы распараллелились на все 24 ядра. А так - 24 ядра не означают увеличения производительности в 24 раза.

Хотите ликбез на тему производительности?
Все конечно есть в интернете, но кто будет специально искать.

Если вкратце, то 24 ядра это бред. Меня учили, что больше 16 не стоит, и моя интуиция с этим согласна. 16 это конечно не закон природы, а просто число, но это наверное ближайшое число степерь двойки к тому что уже математически можно посчитать. А причина в доступе к памяти. Даже если нет зависимости по данным память имеет ограниченно количество каналов доступа к ней. Одноканальной явно будет мало.
Так что маркетинг это все. У видеокарты там тысячи ядер внутри, но их видимо продают по количеству видеопамяти. А вот процы по ядрам и гигагерцам, как когда-то фотики по мегапикселям.
Название: Re: Дискуссия на тему производительности DF
Отправлено: Echo-Six от 27 Августа 2015, 07:07:41
Хотите ликбез на тему производительности?
Все конечно есть в интернете, но кто будет специально искать.
Хотим!!!  >>(
Но хочется услышать (увидеть) не копипасту, а собственное мнение, собственное понимание, собственную точку зрения живого человека. Я считаю, это дорого стоит. 8-)
Название: Re: Дискуссия на тему производительности DF
Отправлено: Holkin от 27 Августа 2015, 15:24:42
Главная проблема в том, что сигнал во вселейнной не может распрастраняться быстрее скорости света. По крайней мере пока нет технологии, которая этот барьер перешагнет. А это значит, что если ваш компьютер имеет компоненты в разных точках пространства, то сигнал будет проходить какое-то время. Отсюда получается, что производительность не может быть бесконечно в принципе, чем меньше компьютер тем она теоретически может быть больше, но есть предел.
Транзисторы сейчас вроде уже делают слоями в три атома. Меньше уже вряд ли можно. Может какие-то графеновые технологии и дадут некоторый прорыв, но дно там уже близко.
Вторая проблема это прохождение сигнала по проводнику. Так получается, что чем больше частота и длина проводника, тем больше искажается сигнал и становится труднее понять где ноль, а где единица. Можно конечно поднять напряжение и немножко эту границу по частоте отодвинуть, но резко возрастает энергопотребление. А поскольку энергия никуда не девается, то излучается она в виде тепла, отводить которое часто бывает нелегко. Оверклокинг это больше частоты/напряжение и резко больше тепла, производители хотят чтобы оно отслужило гарантийный срок, потому могут занижать возможности.
Еще насколько мне известно есть сама проблема в физических транзисторах. В процессорах сейчас уже наверное используются полевые тразисторы, а там есть какая-то ненулевая емкость затвора (или хз что, я не эксперт в тразисторах), которая влияет на скорость переключения. Я пока не видел тразисторов, работающих на гигагерцах. 500 МГц это хорошие тразисторы.
Таким вот образом работает ваш процессор на 500 МГц на низком напряжении.
Процессор сам по себе это сумматор, хранение состояния  и коммутация. Сумматор это простая штука. Удивительно простая.
Вычитание делается просто добавлением отрицательного числа. Если у вас скажет 3 десятичных разряда, то 10-271 будет 1000-(10+1000-271) = 1000-(10 + 729) = 1000-739 = -261. Операция 1000-Х это инверсия цифр +1. В двоичном коде это тупо нули на единицы заменить и наоборот, в десятичном просто цифру от 9 отнять. Т.е. -271 это 728+1. Процессор будет работать с числом 729, а перед запись в память оно будет превращено обратно в отрицательное. Вот и вся магия. Умножение тоже можно на одних сумматорах собрать, с делением так красиво не выходит, поэтому эта операция занимает много времени. Если вам жалко сумматоров (т.е. тразисторов, коммутации и питания), то умножение тоже можно сделать более длинным по времени. 32-битный процессор это будет делать в 32 такта. 500 МГц это по-хорошему 500 млн тактов.
Люди достаточно давно поняли, что пока команда читается с памяти, процессор определяет какую именно операцию он будет делать и загрузит для нее данные, то отдельные части просто стоят без дела. Решили поставить это все на конвеер. Теперь сумматор не ждет пока устройство управления поймет какую команду делать, он уже берет готовую команду. И пока поток идет непрерывно все идет отлично. Но есть еще условное ветвление, так что 100% эффективность конвееров мы не получаем. Если команда проходила весь цикл за 100 тактов, то она и будет проходить, не важно если в среднем за 2 проходила.
Идеально было бы конечно иметь прямые проводки от процессора к каждой ячейке памяти. Но реально это вряд ли хорошая идея. Потому в вас платка памяти на миллиарды байт, а контактов там всего штук 300, среди которых питание и все прочее. Как вы можете догадаться там внутри стоит коммутатор, а это задержка. Да и память пишется не мгновенно.
В новой памяти там внутри вероятно тоже стоят конвееры. Вряд ли оно будет только по одной ячейке читать, оно вам целый блок выдаст. И теперь еще вишенка сверху: кеш. Память реально построена в яруса четыре, а может и больше. Процессор думает что в два: собственные регистры и оперативная память. Но реально процессор за данными бежит в кеш, который отдает данные если у него они уже есть, либо бежит на уровень ниже и так далее. Поскольку высока вероятность того что обрабатываемые данные и программный код будут находиться близко от прошлых, этот фокус прокатывает и очень даже хорошо. Но весь процесс похода в глубины памяти это тысячи процессорных тактов.
Но тут магия еще не кончается. Есть еще виртуальная память. Это по многим причинам хорошо, но тоже не бесплатно. Те данные, которые процессор ожидает видеть в оперативной памяти, реально могут лежать где-нибудь еще, например на диске (файл подкачки). Оперативная память дала неиспользованное пространство другому процессу и все работет просто отлично. Но как только процесс такую страницу просит, оперативная память посылает запрос на диск, контроллер диска читает в свой кеш блок с ФИЗИЧЕСКИ_ДВИЖУЩЕГОСЯ диска (вот почему ССД лучше, там просто микросхемы), блокирует доступ к памяти (и все, в т.ч. проссеро ждут пока этот блок кончится) и пишет данные в нужное место. Потом ОС эти данные (страницу памяти) берет и модифицирует. Потому что в коде написано "перемножить ячейку 50 с 52, перейти на ячейку 101", реально физически эта 52 ячейка будет лежать где-нибудь в 122143451 ячейке. Но теперь есть аппаратная поддержка виртуально памяти и эта вся магия уже должна вычисляться внутри процессора, точно так же конвеером.
Беда начинается когда у ОС много процессов и они постоянно замещают свои странцы. Потому рекомендуют перед тем как играть в игры повыключать все что только можно.
Это что касается однопроцессорных систем.
Есть конечно другие подходы, их достаточно много, но они специфические. Например, вычислять графику. Так работа с координатами по известных алгоритмам, так что целый массив координат может обрабатывать одновременно. Там тысячи ядер. Конечно не общего назначения, а более простых, но суть та же: сумматор, состояние и коммутация. Раньше суперкомпьютеры делали на обычных процессорах, а потом решили на видеокартах делать. И что, в астрономии тоже куча координат по известных агоритмам. Это как раз то место где Минский был неправ. Есть задачи, для которых еще можно много чего сделать.
Кстати, элементы этих специфических процессоров используются и в обычных. Современный интел это такая навороченная фигня, что я наверное и не смогу понять всей глубины инженерной мысли. Но все эти вещи достаточно просты сами по себе. Там никакого секрета мироздания не лежит.
С многопроцессорными системами главная проблема это взаимодействие. Две главных модели предполагают либо общую память либо посылку сообщений. Простая модель когда десять процессоров делят одну память достаточно ограничена. В промышленных целях так навереное никто не делает, у каждого есть своя собственная, а в общую он бежит при крайней необходимости. На обычном десктопе вероятно примерно тот же результат за счет кешей. Но кеши относительно маленькие. И при 10 процессорах вы только представьте, если всем сразу понадобятся данные из разных кусков. Это 9 раз нужно ждать полный поход в глубины памяти. Возможно, если бы эти процессы работали по два на одно ядро, то каждый бы из них выиграл за счет кеша памяти и это было бы быстрее. А одновременный доступ давать нельзя, потому что будут нехорошие баги. Потому я считаю, 8 ядер для домашнего использования более чем. Кстати, показать эти 8 ядер как 16 это навреное гипертрединг и есть, как раз для случая парой строчек выше.
Так вот эта самая маркетинговая пиковая проивзодительность считается по самому оптимистичному сценарию. Реальная будет отличаться и реально зависит от исполняемого кода и условий экплуатации. 8 ядер по 3 ГГц это может быть что-то типа 400 млн операций в секунду реально.
Перспективы конкретно такого подхода с разделяемой памятью я вижу в поиске таких всяких трюков, возможно каких-то графеновых технологий и/или оптимизации самого кода, выдаваемого компилятором. Но часто так вглубь ходить не нужно, того что есть уже достаточно. Хотеть больше могут всякие сервера, а это уже более другие задачи, чем симулятор вселенной.
Кстати, может еще одну хитрую штуку вам открою, не знаю имеет ли отношение. Все те прелести что в процессоре могут быть уже там вероятно есть. Вот прям все. А чтобы иметь разные ценовые категории, некоторые части просто выключаются. Реально дешевле в серию пустить хороший процессор, чем десяток разных.