Что дороже? Переключатель контекста или вызов функции?

Question

На голой металлической системе (встроенный микроконтроллер, без MMU, без подкачки), что дороже? Полный контекстный переключатель (восстановление регистра &) или вызов функции (выделение записи активации)?

Я понимаю, что это сильно зависит от возможности конференц-связи и аппаратного обеспечения, но как бы я оценил это?

EDIT:

Чтобы обеспечить больше контекста, я пытаюсь моделировать две схемы планирования. Первый из них является упреждающим планировщиком с переключением контекста между задачами. Вторая - очередь запуска указателя функций, где задачи - это машины состояний, разбитые на несколько вызовов, зависящих от enque (где enqueing происходит на основе событий, основанных на IO).

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

Answer 1

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

Это пахнет проблемой XY - почему вы спрашиваете об этом? Контекстные коммутаторы и вызовы функций почти ортогональны - один является механизмом на основе стека, другой выбирает другой стек целиком.

Answer 2

Вы бы оценили это, противопоставив методы и их фактические воздействия на общее перемещение данных.

Например, на 6502 импульс прерывания: счетчик программ, X, Y, A и регистр состояния. Это 6 байтов фактических данных и занимает 7 циклов ЦП.

Конечно, 6502 - это гораздо более простой процессор, чем современный дизайн, но он является основным примером проблемы.

Теперь вызов функции может быть таким же простым, как и подпрограмма перехода, которая просто подталкивает текущий компьютер к стеку, а затем переключает ПК в новое место. На 6502, JSR стоил 6 циклов.

Если вы считаете JSR и BRK (программное прерывание на 6502) в качестве примитивов, JSR дешевле BRK на 1 цикл. Это выходит за рамки стояния кадра вызова.

Большинство переключателей контекста выполняются автоматически (через таймер или что-то еще) для имитации многопроцессорной обработки. Но некоторые системы используют примитив для захвата CPU для системных вызовов (например, INT в MS-DOS и TRAP в старой Mac OS). Таким образом, мягкое прерывание по-прежнему должно стоять в кадре стека, как и обычная подпрограмма.

В конце концов, JSR, вероятно, будет дешевле любого из механизмов переключения более высокого уровня, просто потому, что он такой легкий. Механизмы прерывания обычно имеют механизм косвенности (именно поэтому они так часто используются в системном вызове), что подпрограмма не имеет. Компилятор управлял адресами подпрограмм во время компиляции.

Но это соображения, чтобы оценить производительность сырья.