Сколько слоев находится между моей программой и оборудованием?

Question

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

Я думаю о чем-то вроде этого:

1 + 2 >> Верхний уровень ОС >> Библиотека времени выполнения / хелпер / обработчик ошибок >> огромное количество модулей DLL >> Уровень ядра ОС >> Вы действительно хотите запустить всплывающее окно 1 + 2? не принимайте это всерьез) >> Уровень ядра ОС >> Аппаратная абстракция >> Аппаратное обеспечение >> Пройдите по крайней мере 100 миль каналов >> В конечном счете достигните ЦП >> ДОБАВИТЬ 1, 2 >> Пройдите весь путь назад к моему программа

Почти все технические вещи просто неправильны и в некотором случайном порядке, но вы правильно поняли мою точку зрения?

• Насколько длиннее / короче эта цепочка при запуске программы на C ++, которая вычисляет 1 + 2 во время выполнения в Windows?

• Как насчет того, когда я делаю это в переводчике? (Python | рубин | PHP)

• Действительно ли эта цепочка настолько драматична в реальности? Действительно ли Windows пытается «не мешать»? например: прямое подключение моего двоичного <> оборудования?

Answer 1

«1 + 2» в C ++ напрямую переводится в add инструкцию по сборке, которая выполняется непосредственно на CPU. Все «слои», на которые вы ссылаетесь, действительно вступают в игру только тогда, когда вы начинаете вызывать библиотечные функции. Например, простой printf("Hello World\n"); будет проходить через несколько слоев (на примере Windows разные ОС будут отличаться):

1. CRT - среда выполнения C реализует такие вещи, как замены% d, и создает одну строку, а затем вызывает WriteFile в kernel32
2. kernel32.dll реализует WriteFile, замечает, что дескриптор является консолью, и направляет вызов в консольную систему
3. строка отправляется процессу conhost.exe (в Windows 7, csrss.exe в более ранних версиях), который фактически содержит окно консоли
4. conhost.exe добавляет строку во внутренний буфер, который представляет содержимое окна консоли, и делает недействительным окно консоли
5. Диспетчер окон замечает, что окно консоли теперь недействительно, и отправляет ему сообщение WM_PAINT
6. В ответ на WM_PAINT, окно консоли (по-прежнему внутри conhost.exe) выполняет серию DrawString вызовов внутри GDI32.dll (или, возможно, GDI +?)
7. Метод DrawString перебирает каждый символ в строке и:
   1. Поиск определения глифа в файле шрифта для получения контура глифа
   2. Проверяет, находится ли кэш для визуализированной версии этого символа с текущим размером шрифта
   3. Если глифа нет в кеше, он растеризует контур с текущим размером шрифта и кеширует результат на потом
   4. Копирует пиксели из растеризованного глифа в указанный вами графический буфер, попиксельно
8. Как только все вызовы DrawString завершены, окончательное изображение для окна отправляется в DWM, где оно загружается в графическую память вашей видеокарты, и заменяет старое окно
9. Когда рисуется следующий кадр, видеокарта теперь использует новое изображение для рендеринга окна консоли, и ваша новая строка там

Теперь есть много слоев, которые я упростил (например, способ, которым видеокарта рендерит вещи, представляет собой целый «другой слой абстракций»). Возможно, я допустил некоторые ошибки (я, конечно, не знаю, как реализована Windows), но, надеюсь, это даст вам представление.

Важным моментом, однако, является то, что каждый шаг на этом пути добавляет какую-то ценность для системы.

Answer 2

Как сказала Codeka, многое происходит, когда вы вызываете библиотечную функцию, но вам нужно помнить, что печать строки или отображение jpeg или чего-либо еще является очень сложной задачей.Тем более, когда используемый метод должен работать для всех в любой ситуации;сотни крайних случаев.

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

Answer 3

Неважно, сколько существует уровней абстракции, поскольку тяжелая работа выполняется наиболее эффективным способом.

В общем смысле вы страдаете от "эмуляции" вашего самого низкого уровня, например Вы страдаете от эмуляции процессора 68 КБ на процессоре x86, на котором запущено какое-то плохо реализованное приложение, но оно не будет работать хуже, чем оригинальное оборудование. В противном случае вы бы не подражали этому в первую очередь. Например. сегодня большая часть логики пользовательского интерфейса реализована с использованием высокоуровневых динамических языков сценариев, потому что она более продуктивна, а хардкорные вещи обрабатываются оптимизированным низкоуровневым кодом.

Когда дело доходит до производительности, это всегда тяжелая работа, которая в первую очередь попадает в стену. Между ними никогда не возникает проблем с производительностью. Например. обработчик клавиш, который обрабатывает 2-3 нажатия клавиш в секунду, может потратить целое состояние на плохо написанный код, не влияя на работу конечного пользователя, в то время как оценщик движения в кодировщике mpeg полностью потерпит неудачу, просто реализовавшись в программном обеспечении вместо использования выделенного оборудования.