Как программно имитировать более низкие частоты процессора?

Я заинтересован в запуске программы на определенной частоте (например, 25 МГц) на моем процессоре 2GHz+. Единственный метод, который я могу придумать для чего-то подобного, - это использование функции сна с точностью до микросекунды, но я не уверен, как вычислить, как долго поток должен спать, чтобы соответствовать определенной частоте. Любые советы или другие идеи? Я делаю это в C на ОС X86 Linux.

6 ответов


здесь есть пара проблем. Это первое, что вы пытаетесь моделировать. Современные процессоры работают на 2 ГГц, но инструкции конвейера, поэтому индивидуальная инструкция может занять 10-30 часов. Засыпая нить, вы разрываете трубопровод. Во-вторых, насколько гранулированным вы хотите иметь симуляцию. Вам нужно иметь время уровня инструкции, можем ли мы подделать его, поместив некоторое пространство между функциями.

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


редактировать:

Итак, как я теперь понимаю, вы хотите выполнить инструкцию на виртуальном процессоре 25M раз a второй. Я могу попробовать адаптивный подход. У вас есть много времени, чтобы "возиться" между инструкциями. начните с размещения некоторого интервала, сон, вероятно, будет работать между каждой инструкцией. Обратите внимание, что в массиве с максимальной точностью, когда каждый виртуальный часы начали держать скользящее среднее, скажем, последние 25, 100 или 1000 циклов. Если среднее значение поднимается выше 25 МГц, начните добавлять больше места. Если он слишком медленный, уменьшите пространство.

Как я сказал Изначально, это очень трудно вычислите количество времени, которое инструкция занимает на современном процессоре. Первый набор инструкций может работать слишком быстро или медленно, но такой метод должен держать его так близко к правильной скорости, как типичный генератор на сопоставимой аппаратной реализации.


Я бы предложил архитектуру, управляемую событиями: на каждом шаге (1/Гц) срабатывает инструкция 1.


Я бы просто запускал симуляцию в очередях. Например, вы можете запустить 250 тысяч циклов, а затем спать в течение оставшейся части интервала 10 мс. Вы можете настроить вид часов, которые видит симуляция, чтобы сделать это полностью прозрачным, если только он не взаимодействует с каким-то внешним оборудованием, с которым нужно взаимодействовать с определенной скоростью (в этом случае это становится гораздо более сложной проблемой).


чтобы подвести итог вышеизложенным ответам, Если вы находитесь в пользовательском режиме, пытаясь эмулировать виртуальный процессор на определенной частоте, вы должны реализовать какое-то ручное "планирование" потока, который обрабатывает инструкции процессора либо через вызовы сна, либо более продвинутые функции и функции, такие как волокна в Windows. Предостережение, на которое вы должны обратить внимание, заключается в том, что некоторые вызовы сна ОС не спят в течение указанного вами точного времени, поэтому вам может потребоваться добавить дополнительный код откалибруйте отклонение от компьютера к компьютеру, чтобы приблизиться к целевой частоте. Чаще всего вы не сможете точно запланировать запуск виртуального процессора на устойчивой частоте 25 МГц (22-28 МГц более вероятно). В любом случае, я согласна и с Натаном, и с идеей взрыва. Удачи, в котором когда-либо путь вы используете!


для виртуальной машины все виртуальное, включая время. Например, за 123 реальные секунды можно эмулировать 5432 виртуальные секунды обработки. Общий способ измерения виртуального времени-увеличивать (или добавлять что-то) счетчик "количество циклов" каждый раз, когда виртуальная инструкция эмулируется.

время от времени вы пытаетесь синхронизировать виртуальное время с Реальным временем. Если виртуальное время слишком далеко впереди реального времени, вы вставляете задержку, чтобы позволить Реальному времени догнать. Если виртуальное время отстает от реального времени, то вам нужно найти какое-то оправдание для замедления. В зависимости от эмулируемой архитектуры вы ничего не можете сделать; но для некоторых архитектур есть функции управления питанием, такие как термическое дросселирование (например, вы можете притвориться, что виртуальный процессор стал горячим и работает медленнее, чтобы остыть).

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

следующий шаг-определить места, где имеет значение время, и синхронизировать только виртуальное время с Реальным временем в этих конкретных местах. Если эмулируемая машина выполняет тяжелую обработку и не делает ничего, что видно внешнему наблюдателю, то у внешнего наблюдателя нет никакого способа чтобы сказать, если виртуальное время близко к реальному времени или нет. Когда виртуальная машина делает что-то, что видно внешнему наблюдателю (например, отправляет сетевой пакет, обновляет видео/экран, делает звук и т. д.), Вы сначала синхронизируете виртуальное время с Реальным временем.

шаг за этим - использование буферизации для отделения, когда вещи происходят внутри эмулятора, от того, когда они видны внешнему наблюдателю. Для (преувеличенного) примера представьте, что эмулируемая машина думает, что это 8: 23 в утром и он хочет отправить сетевой пакет, но на самом деле это только 8:00 утра. Простое решение-отложить эмуляцию на 23 минуты, а затем отправить пакет. Это звучит хорошо, но если (после того, как виртуальная машина отправляет пакет) эмулятор пытается идти в ногу с Реальным временем (из-за других процессов, запущенных на реальном компьютере или по любой другой причине) эмулятор может отстать, и у вас могут возникнуть проблемы с поддержанием иллюзии, что виртуальное время такое же, как и реальное время. В качестве альтернативы вы можете притвориться, что пакет был отправлен, и поместить пакет в буфер и продолжить эмуляцию других вещей, а затем отправить пакет позже (когда это на самом деле 8:23 утром в реальном мире). В этом случае, если (после отправки пакета виртуальной машиной) эмулятор пытается идти в ногу с Реальным временем, у вас все еще есть 23 минуты свободы.


посмотреть Fracas эмулятор процессора для подхода к этому. Авторы представили об этом на Heteropar семинар, часть EUROPAR 2010. Они существенно изменяют планировщик ОС, чтобы разрешить использование только фракций реального процессора freq для использования пользовательскими программами.