Я бы читал литературу по архитектурам и по оптимизации под них. Ещё по бенчмаркам можно
Потом бы разработал бы тормозов модель для каждой архитектуры.
Ну типа там есть такая-то "крейсерская" производительность на типичной задаче такого-то типа. Есть пиковая.
Чтобы достичь пиковой прога должна продемонстрировать какие-то скилы в этом вопросе (ну, например, правильно использовать объёмы кэшей, ровно загружать ядра и т. п.)
Кроме того, на архитектурах обычно бывают всякие узкие места, которые могут вызвать деградацию производительности по сравнению с "крейсерской".
После этого можно шпионить за прогой на одной, а лучше на нескольких архитектурах и оценивать есть ли в ней источники тормозов или, наоборот, скилы по выходу на пиковую производительность.
Ну а после этого уже можно перейти к гаданиям и экспертным оценкам
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PaulMinelly, Вы писали:
PM>Речь не об этом, речь о том что программа уже откомпилирована — какой в ней алогоритм — не разберешь.
Кстати, если все входные данные априори известны, то по известному алгоритму (данному пусть даже в уже скомпилированном виде) можно восстановить последовательность машинных операций, возникающих при выполнении программы над конкретным набором исходных данных. Такое обычно называется трассой или историей выполнения программы. Тогда задача трансформируется в следующую: есть трасса выполнения программы на заданных исходных данных, надо определить сколько времени займет выполнение этой трассы на нужном процессоре, при заданных временных характеристиках его работы. В такой постановке задача действительно становится гораздо интереснее. Можно достаточно полно учесть архитектурные особенности процессора : влияние всяких разных нелинейностей -- кешей, конвееров, скорости выполнения команд разных типов и прочее.
C>>Другое дело, если нету и откомпилированной программы, а есть только данные о том сколько времени она выполнялась на таком-то процессоре, на таких-то исходных данных. PM>Сейчас по понятнее опишу, может не понятно сказал что программа у нас откомпилированная уже. Так вот. У нас программа откомпилированная есть. По всем набору фиксированных входных данных известно время ее работы. Надо определить сколько она будет работать на другом компе. Вот такой сказ.
Если во внутренности твоей программы "залезть" нельзя, то с позиции твоей задачи можно смело считать что программы у тебя нету совсем. Задача в твоей постановки примерно такая: есть бумажка на которой написано, что на таких-то исходных данных, на таком-то процессоре непонятно какая программа выполнялась столько-то секунд. Надо сказать сколько времени займет выполнение этой программы на другом процессоре на тех же исходных данных.
C>> В принципе, основываясь на статистических данных (на каких-нибудь тестах производительности процессоров), можно приблизительно предсказать сколько она будет выполняться на тех же исходных данных на другом процессоре. Разумеется всякий изврат, типа оптимизации под конкретную архитектуру так не учтешь. PM>Вот это уже интересней.
А че тут интересного то ? Прогноз будет достаточно ущербен. Примерно по такой формуле
T_новое = K_п * T_старое,
где
Т_старое -- известное время выполнение программы на одном процессоре,
T_новое -- искомое время выполнения на другом процессоре,
K_п -- усредненный коэффициент "крутости" одного процессора перед другим.
C>Кстати, если все входные данные априори известны, то по известному алгоритму (данному пусть даже в уже скомпилированном виде) можно восстановить последовательность машинных операций, возникающих при выполнении программы над конкретным набором исходных данных. Такое обычно называется трассой или историей выполнения программы.
Классная идея. Как только залезть во внутренности программы и посмотреть:
статистику использования памяти (в идеале чтения, записи)
статистику использования кеша
ну и еще что-нибудь. Думаю этого уже достаточно (если считать что не используются внешние устройства ввода-вывода).
C>Если во внутренности твоей программы "залезть" нельзя, то с позиции твоей задачи можно смело считать что программы у тебя нету совсем.
Откомпилированная программа есть — можно делать с ней что угодно, мерять ее как угодно, запускать во врапперах, виртуальных машинах и т.п. Нет только исходного кода этой программы. Есть только откомпилированный бинарник.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, PaulMinelly, Вы писали:
PM>>Зная программу и время работы на каждом из входных данных на одном компьютере, можно предсказать как эта же программа будет работать с этими же входными данными но на другом компьютере (процессоре)?
G>Можно. Время увеличится пропорционально разнице результатов известных тестов на этих процессорах. Скажем, на embedded процах популярен простой тест dmips, а на взрослых — SPEC .
Спасибо за идею. Если бы еще подсказали пару разных тестов посмотреть — было бы здорово!
На днях померил — получилось что разные проги дают разный прирост на другом проце. Поэтому набор тестов хотя бы 6 — было бы здорово.
Здравствуйте, Erop, Вы писали:
E>Я бы читал литературу по архитектурам и по оптимизации под них. Ещё по бенчмаркам можно
E>Потом бы разработал бы тормозов модель для каждой архитектуры. E>Ну типа там есть такая-то "крейсерская" производительность на типичной задаче такого-то типа. Есть пиковая. E>Чтобы достичь пиковой прога должна продемонстрировать какие-то скилы в этом вопросе (ну, например, правильно использовать объёмы кэшей, ровно загружать ядра и т. п.) E>Кроме того, на архитектурах обычно бывают всякие узкие места, которые могут вызвать деградацию производительности по сравнению с "крейсерской".
Это идея хорошая. Проблема одна только — как узнать насколько она использует объемы кешей? А если узнать как много данных она пишет-читает из оперативной памяти — было бы вообще круто. Но как это сделать? (не общий объем занимаемой оперативной памяти, а интенсивность использования такой памяти, т.е. занять может всего 512 килобайт, зато писать-читать оттуда очень часто)
Здравствуйте, PaulMinelly, Вы писали:
PM>На днях померил — получилось что разные проги дают разный прирост на другом проце.
Именно так и должно быть.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, PaulMinelly, Вы писали:
PM>Это идея хорошая. Проблема одна только — как узнать насколько она использует объемы кешей? А если узнать как много данных она пишет-читает из оперативной памяти — было бы вообще круто. Но как это сделать? (не общий объем занимаемой оперативной памяти, а интенсивность использования такой памяти, т.е. занять может всего 512 килобайт, зато писать-читать оттуда очень часто)
Ну, например, под ве-тюном погонять.
Если у тебя есть бесконечный бюджет, то можно написать эмулятор проца и погонять прогу на нём...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, PaulMinelly, Вы писали:
PM>кто-нибудь знает как называется направление таких работ и какие статьи почитать на эту тему прогнозирования — было бы круто.
На самом деле проведены глубокие исследования. Накоплена колоссальная статистика. С учетом просто невероятного количества параметров. И эти исследования имеют большое практическое значение.
Здравствуйте, PaulMinelly, Вы писали:
G>>Можно. Время увеличится пропорционально разнице результатов известных тестов на этих процессорах. Скажем, на embedded процах популярен простой тест dmips, а на взрослых — SPEC .
PM>Спасибо за идею. Если бы еще подсказали пару разных тестов посмотреть — было бы здорово! PM>На днях померил — получилось что разные проги дают разный прирост на другом проце. Поэтому набор тестов хотя бы 6 — было бы здорово.
Дык. Дык! Архитектуры-то разные у процов. Влияет очень много чего. В целом, если упрощенно, есть две составляющих.
1) Латентность и производительность подсистемы памяти. Имеет значение ширина канала в память, латентность обращения в память, размер кэша.
2) Исполнительный конвейр проца. Допустим, у вас на тесте 100% попадания в кэш. В этом случае, на скорость влияет качество механизма предсказания ветвлений, размер буфера переупорядочивания, наличие в архитектуре байпасов, и пр, и пр, и пр. Все это сведется к среднему количеству _полезных_ инструкций (то есть арифметики) на такт — это и есть характеристика архитектуры, однако и она плавает от программы к программе.
Тем не менее, вы можете измерить все эти вещи пораздельности отдельными тестами. Скажем, характеристики подсистемы памяти померять довольно просто. Также, несложно написать микротесты, которые работают на кэше, и замеряют качество конвейра.
Тесты я уже назвал — dmips это Drystone MIPS, простейший и самый популярный тест, которым оценивают производительность микроконтроллеров. Есть несколько embedded benchmark, которые более слодны, и состоят из реальных типичных задач.
Для больших компов ничего лучше тестов SPEC человечество не придумало.
Здравствуйте, PaulMinelly, Вы писали:
PM>Классная идея. Как только залезть во внутренности программы и посмотреть: PM>статистику использования памяти (в идеале чтения, записи) PM>статистику использования кеша PM>ну и еще что-нибудь. Думаю этого уже достаточно (если считать что не используются внешние устройства ввода-вывода).
Надо запустить программу на выполнение на виртуальной машине с известными исходными данными и зафиксировать последовательность передачи управления между машинными командами. Также можно дополнительно фиксировать "аргументы" машинных команд: значения регистров, ячеек памяти и т.д. По такой информации можно определить к каким фрагментам памяти и в каком порядке происходило обращение в процессе выполнения. Причем это будет даже не статистика использования памяти, а точная последовательность операций над памятью для выполнения программы на заданном наборе исходных данных. Зная последовательность выполнения машинных команд, можно промоделировать работу программы на любом процессоре (работающего в той же системе команд). В том числе учесть работу работу кеша. Причем тут также речь идет не о статистике, а о точном предсказании работы кеша процессора. Разумеется это все на заданном наборе исходных данных.
Здравствуйте, Gaperton, Вы писали: G>Тесты я уже назвал — dmips это Drystone MIPS, простейший и самый популярный тест, которым оценивают производительность микроконтроллеров. Есть несколько embedded benchmark, которые более слодны, и состоят из реальных типичных задач.
G>Для больших компов ничего лучше тестов SPEC человечество не придумало.
Можно ссылку где SPEC и embedded benchmark скачать, а то гугл выдает консорциум, а где сами тесты — не понятно сразу. Спасибо.
PM>>Спасибо за идею. Если бы еще подсказали пару разных тестов посмотреть — было бы здорово! PM>>На днях померил — получилось что разные проги дают разный прирост на другом проце. Поэтому набор тестов хотя бы 6 — было бы здорово.
G>Дык. Дык! Архитектуры-то разные у процов. Влияет очень много чего. В целом, если упрощенно, есть две составляющих. G>1) Латентность и производительность подсистемы памяти. Имеет значение ширина канала в память, латентность обращения в память, размер кэша.
Можно ли узнать объем свободного места в кеше, управлять им, например сделать чтобы программа работала только в кеше (например, поместить массив только в кеш и делать с них какие-либо операции?
