Ipc это в процессорах

Обновлено: 07.07.2024

IPC – это, понятие, связанное с операционной системой, но есть смысл разобраться в том, что это такое, более подробно.

Этим и займемся.

Cодержание:

Теоретическая страничка

Каждый хоть немного представляет себе работу обычной операционной системы.

А теперь представьте, что привычная для нас работа нашей ОС превратилась в своего злого двойника, который не просто не похож на свой оригинал, но еще и выполняет все свои обязанности.

Рис. 1. Если хотя бы одна шестерня перестанет крутиться, то вся система перестанет работать справно

Такое развитие событий вполне могло происходить, не будь встроен в нашу систему IPC.

Если хорошо изучить вопрос о зависимости программ друг от друга, то можно понять, что приложений, не зависящих друг от друга, довольно малое количество.

Это вполне логично, так как для высокого коэффициента работы любой системы просто необходима передача информации между составляющими.

Рис. 2. Если не будет передачи актуальных данных, то все процессы и вычисления будут неправильны

Например, когда у человека в работе возникает вопрос, который зависит от его работы, он берет нужную ему информацию с какого-то источника, будь то человек или любой другой источник.

Хоть «ядро» нашего компьютера запрограммировано искать информацию в каком-то определенном источнике, принцип роботы по сути тот же.

Рис. 3. Активный поиск информации

Принцип работы

Для правильного функционирования системы приложениям в обязательном порядке нужна беспрерывная коммуникация между большинством процессов, либо они сами обязаны предоставлять нужную информацию по требованию процессов.

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

Такие механизмы или программы носят название «межпроцессорное взаимодействие» – с перевода Inter-process Communication (IPC).

Важно: IPC – это механизм или программа, которая обеспечивает стабильный взаимный обмен данными у потоков информации процесса/процессоров.

Работает данная программа непосредственно в самой операционной системе, и является основой для передачи любой информации.

Рис. 4. Потоки информации

Примеры работы IPC

Еще до развития сетевых технологий актуальным стал вопрос о необходимости в передаче информации от процессора к процессору, работающих на одном компьютере.

Существует просто огромное количество примеров, когда данная программа была использована в довольно примитивных, на сегодняшнее время, механизмах.

Рассмотрим один из ключевых примеров, который наглядно изобразит всю важность IPC даже в очень простых и ранних системах, что уж говорить о его потребности на сегодняшний день.

Более старые версии современного IPC присутствовали еще в MS-DOS.

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

В то время решение данного вопроса было очень проблематичным.

Дело в том, что такая связь могла проводить обмен данными, если только их платформы или операционные системы относились к одинаковым моделям.

В современной сети данные проблемы уже давно никого не беспокоят. Вот вам краткий наглядный пример работы в таких сетях.

Когда вы совершаете любой выход в Интернет, ваш браузер – один процесс (программа) – входит во взаимосвязь с web-сервером – другим процессором (программой).

Данные процессы выполняются на двух разных компьютерах, в двух разных местах:

браузер у вас в системе;
сервер – в любой другой системе или абсолютно в любом месте.

И вы совершенно не задаетесь вопросом, какая у серверов операционная система.

Затрагивая общий принцип работы таких форм как IPC, и не только таких, как она, используется в основном концепция «клиент-сервер».

Понятно, что «клиент» — это приложение, которое запрашивает информацию, а запрос информации идет уже к «серверу» — приложению которое предоставляет нужную информацию.

Рис. 5. Принцип действия сети

Общее положение

Рассмотрев все возможности и примеры использования межпроцессорного взаимодействия, вы сами можете убедиться в том, что данное обеспечение просто необходимо для работы операционной системы, к которой мы так привыкли.

Ниже будут перечислены области взаимодействия IPC, как в одной системе, так и в многопользовательской сети.

На сегодняшний день требования к операционным системам увеличивается пропорционально с ростом уровня технологий.

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

Рис. 6. Чем выше уровень технологии, тем больше на него спрос

Но мало кто знает, что современные операционные системы, которые поддерживают многозадачность своей системы, должны иметь в себе такие программы или механизмы, которые обеспечивают синхронизацию процессоров без взаимоисключений и с минимальными задержками.

Данные критерии имеют очень высокую важность в роботе нашего компьютера.

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

В реальности такая «идеальная» система невозможна, так как рано или поздно возникают ситуации, когда процессам необходим доступ к некоторым общим ресурсам.

Для получения данной возможности, на уровне операционной системы водятся специальные ресурсы, которые предоставляют им данную возможность.

Но тут, конечно же, не без исключений. При выполнении параллельных процессов могут возникать проблемы.

Например: при совместной работе, каждый процесс, обращающийся к разделяемым данным, делает невозможным для всех остальных процессов одновременное обращение к этим данным – данный феномен называется взаимоисключением.

Три основных вида IPC

Этот вид IPC полностью привязан к своему компьютеру, работа осуществляется только в пределах одной системы (компьютера).

Из-за своей ограниченности, в плане коммуникационного пространства, данные IPC, могут работать лишь в пределах своей локальной системы.

Но благодаря такому ограничению для них могут использоваться более быстрые и простые интерфейсы.

Чтобы обеспечить взаимодействие в пределах системы с одним процессором или между программами на различных процессорах, соединенных через одну сеть, используются специальные механизмы, которые предоставляют удаленное IPC.

Последний и, пожалуй, один из самых тяжелых в использовании вид IPC – высокоуровневый.

Данный вид представляет собой пакет программного обеспечения.

Этот пакет данных создает так называемый «промежуточный слой», который предоставляет возможность общения между системной платформой и приложением.

Обеспечение корректной работы обмена данных

Вместе со своей основной функцией, обеспечения взаимодействий процессоров, средства ICP подключены к решению проблем, возникающих при организации параллельных вычислений.

Вот примеры их области деятельности:

1 Конкурентные ситуации между процессами. Можем представить себе идеальную систему, в которой проходит лишь одно действие, это считывание данных с одного файла. Данная система находиться в полном спокойствии до тех пор, пока одному из процессов не понадобиться изменить данный файл. В таком случае между процессами возникает «конкурентная ситуация». Это можно сравнить с камешком в каком-то механизме. 2 Очередь последовательной записи информации. Для того чтобы предоставить пользователям возможность быстрой и надежной записи данных, создаются специальные очереди. Я думаю вам известно, что такое очередь. Но на самом деле создается не одна, а две очереди. Отличаются данные очереди от настоящих только тем, что одна из них используется только для чтения, а другая уже позволяет нам записывать нужную информацию. Данная очередь создается в целях предотвращения тупиков, которые мы обсудим немного ниже.

Рис. 7. Очередь процессов для записи данных

А что насчет тех процессов, которые требуют неотъемлемой скорости своего решения?

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

Через некоторое время была придуманная идея создания очередей, которые осуществляли такой распорядок процессов, которые не мешали основным или более важным процессам.

Также, существует термин, который и в теории, и на практике обоснован своим названием – это тупик.

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

Если проще объяснить, то на практике получается следующее: у нас есть процесс X, когда он получает доступ к файлу X, он начинает ждать, когда освободиться файл Y, для завершения своей роботы. Но вместе с ними процесс Y, получив доступ к файлу Y, ждет, пока освободится файл X.

Данные процессы замыкаются между собой в данный момент и ждут взаимного освобождения файла, при этом, не освобождая свой файл.

Такого «замыкания» можно избежать, если пользователь позаботиться о том, чтобы ресурсы были пронумерованы.

Также они должны быть построены строго в восходящем порядке номеров.

Рис. 8. Наглядный «тупик»

Современные примеры работы ICP

Чтобы наглядно изобразить взаимодействие программ на одном компьютере, существует знакомый нам ресурс – буфер обмена.

Не удивляйтесь, наш старый добрый буфер обмена также является одной из механизмов IPC.

А принцип его работы заключен в следующем: выделенный вами текст из текстового редактора после выделения помещается в электронную таблицу или в ту же программу для верстки.

Вы сами можете убедиться, что следы механизмов межпроцессорного взаимодействия можно обнаружить даже в мелких деталях.

Было множество попыток создания программ или механизмов, которые обеспечили бы быструю и эффективную передачу информации между процессорами.

Хоть было создано довольно много подобных средств, множество из них до сих пор сохранились или послужили в качестве основы для будущих моделей.

Стоит заметить, что множество из них были реализованы в Windows 9x, а еще большее количество в Windows NT/2000.

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

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

Но можем вас уверить в том, что после этой статьи вас больше не затруднит ориентирование в ресурсах, связанных с IPC или выбор того или иного метода роботы, взвешивая все плюсы и минусы.

Для тех людей, которые думают, что развития в данной технологии не предвещается, есть один факт, который изменит ваше мнение.

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

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.

Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:

А на самом деле это выглядит вот так:

«Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.

Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое — лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью. Это особенно актуально в нынешних реалиях облачных платформ, где политики автоматического масштабирования иногда напрямую завязаны на загрузку CPU, а значит каждый лишний такт «холостой» работы стоит нам вполне реальных денег.

Что же такое загрузка процессора на самом деле?

Та метрика, которую мы называем «загрузкой процессора» на самом деле означает нечто вроде «время не-простоя»: то есть это то количество времени, которое процессор провёл во всех потоках кроме специального «Idle»-потока. Ядро вашей операционной системы (какой бы она ни была) измеряет это количество времени при переключениях контекста между потоками исполнения. Если произошло переключение потока выполнения команд на не-idle поток, который проработал 100 милисекунд, то ядро операционки считает это время, как время, потраченное CPU на выполнение реальной работы в данном потоке.

Эта метрика впервые появилась в таком виде одновременно с появлением операционных систем с разделением времени. Руководство программиста для компьютера в лунном модуле корабля «Апполон» (передовая на тот момент система с разделением времени) называла свой idle-поток специальным именем «DUMMY JOB» и инженеры сравнивали количество команд, выполняемых этим потоком с количеством команд, выполняемых рабочими потоками — это давало им понимание загрузки процессора.

Так что в этом подходе плохого?

Сегодня процессоры стали значительно быстрее, чем оперативная память, а ожидание данных стало занимать львиную долю того времени, которое мы привыкли называть «временем работы CPU». Когда вы видите высокий процент использования CPU в выводе команды top, то можете решить, что узким местом является процессор (железка на материнской плате под радиатором и кулером), хотя на самом деле это будет совсем другое устройство — банки оперативной памяти.

Ситуация даже ухудшается со временем. Долгое время производителям процессоров удавалось наращивать скорость их ядер быстрее, чем производители памяти увеличивали скорость доступа к ней и уменьшали задержки. Где-то в 2005-ом году на рынке появились процессоры с частотой 3 Гц и производители сконцентрировались на увеличении количества ядер, гипертрейдинге, много-сокетных конфигурациях — и всё это поставило ещё большие требования по скорости обмена данных! Производители процессоров попробовали как-то решить проблему увеличением размера процессорных кэшей, более быстрыми шинами и т.д. Это, конечно, немного помогло, но не переломило ситуацию кардинально. Мы уже ждём память большую часть времени «загрузки процессора» и ситуация лишь ухудшается.

Как же понять, чем на самом деле занят процессор

Используя аппаратные счетчики производительности. В Linux они могут быть прочитаны с помощью perf и других аналогичных инструментов. Вот, например, замер производительности всей системы в течении 10 секунд:

Ключевая метрика здесь это "количество инструкций за такт" (insns per cycle: IPC), которое показывает, сколько инструкций в среднем выполнил процессор на каждый свой такт. Упрощённо: чем больше это число, тем лучше. В примере выше это число равно 0.78, что, на первый взгляд кажется не таким уж плохим результатом (78% времени выполнялась полезная работа?). Но нет, на этом процессоре максимально возможным значением IPC могло бы быть 4.0 (это связано со способом получения и выполнения инструкций современными процессорами). То есть наше значение IPC (равное 0.78) составляет всего 19.5% от максимально возможной скорости выполнения инструкций. А в процессорах Intel начиная со Skylake максимальное значение IPC уже равно 5.0.

В облаках

Когда вы работаете в виртуальном окружении, то можете и не иметь доступа к реальным счетчикам производительности (это зависит от используемого гипервизора и его настроек). Вот статья о том, как это работает в Amazon EC2.

Интерпретация данных и реагирование

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

Если у вас IPC > 1.0, то ваше приложение страдает не столько от ожидания данных, сколько от чрезмерного количества выполняемых инструкций. Ищите более эффективные алгоритмы, не делайте ненужной работы, кэшируйте результаты повторяемых операций. Применение инструментов построения и анализа Flame Graphs может быть отличным способом разобраться в ситуации. С аппаратной точки зрения вы можете использовать более быстрые процессоры и увеличить количество ядер.

Как вы видите, я провёл черту по значению IPC равному 1.0. Откуда я взял это число? Я рассчитал его для своей платформы, а вы, если не доверяете моей оценке, можете рассчитать его для своей. Для этого напишите два приложения: одно должно загружать процессор на 100% потоком выполнения инструкций (без активного обращения к большим блокам оперативной памяти), а второе должно наоборот активно манипулировать данным в ОЗУ, избегая тяжелых вычислений. Замерьте IPC для каждого из них и возьмите среднее. Это и будет примерная переломная точка для вашей архитектуры.

Что инструменты мониторинга производительности на самом деле должны показывать

Я считаю, что каждый инструмент мониторинга производительности должен показывать значение IPC рядом с загрузкой процессора. Это сделано, например, в инструменте tiptop под Linux:

Другие причины неверной трактовки термина «загрузка процессора»

Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:

Несколько часов назад в рамках мероприятия Intel Architecture Day 2021 было поведано немало подробностей касательно технических характеристик и некоторых нюансов работы предстоящих процессоров, известных под кодовым именем Alder Lake, сообщает ресурс VideoCardz.

Прежде всего, Intel напомнила о гетерогенной природе процессоров семейства Alder Lake: в основу новинок, которые будут производиться по технологическому процессу Intel 7, ляжет очередная итерация гибридной архитектуры, предполагающей наличие «больших» и «малых» ядер в составе одного продукта — CPU обзаведутся как производительными ядрами (P-core) с поддержкой технологии гиперпоточности, так и энергоэффективными (E-core), лишённым оной.

Таким образом, флагманский десктопный процессор Intel 12-го поколения сможет располагать 16 ядрами, 8 из которых будут принадлежать к производительной группе, а остальные 8 — к энергоэффективной, а общее количество потоков будет равно 24. При этом новинки смогут получить до 30 Мбайт кэш-памяти третьего уровня.

В мобильном же сегменте Intel сможет предложить как CPU, имеющие в своём распоряжении до 6 «больших» и 8 «малых» ядер, так и модели, оснащённые 2 производительными и 8 энергоэффективными ядрами.

Для связи между компонентами предусмотрено три шины, Compute Fabric, I/O Fabric и Memory Fabric, характеризующихся значениями суммарной пропускной способности в 1000, 64 и 204 Гбайт/с.

Для эффективной работы продуктов с гетерогенной структурой компания наделила свои новые процессоры поддержкой технологии Intel Thread Director, призванной следить за характером нагрузки на каждый поток и оперативно передавать эти данные операционной системе, что подразумевает необходимость наличия поддержки со стороны последней.

Напомнила Intel и о наличии 16 линий PCIe версии 5.0 и 4 линий PCIe 4.0 на стороне CPU, а также 12 и 16 линий PCIe 4.0 и 3.0 от чипсета. Также не стоит забывать о поддержке оперативной памяти DDR5-4800 и DDR4-3200.

Что касается информации об уровне производительности процессоров семейства Alder Lake, то она, вероятно, способна воодушевить большинство почитателей продукции «синей команды»: как утверждает Intel, конфигурация, включающая в себя 4 энергоэффективных ядра, на 80 % производительнее двухъядерного CPU поколения Skylake с поддержкой гиперпоточности и при этом требует на 80 % меньше энергии на равной частоте, в то время как общий прирост IPC новых продуктов составит внушительные 19 % по сравнению с моделями 11-го поколения.

Журналисты веб-издания WCCFTech продолжают публиковать разнообразные утечки и результаты тестирования процессоров AMD Ryzen. Теперь им в руки попала информация о числе исполняемых за такт инструкций (IPC) для модели AMD Ryzen 7 1700X, полученная в тесте UserBenchmark.

Показатель IPC представляет собой стандарт, по которому мы можем оценить количество инструкций, выполняемых процессором на одном ядре за такт. Иными словами, это мера, показывающая эффективность каждой конкретной микроархитектуры CPU. Очевидно, что чем выше этот показатель, тем лучше итоговая производительность процессора. Руководство AMD неоднократно заявляло, что их целью являлось увеличение IPC на 40% по сравнению с архитектурой Piledriver, что позволяло бы достичь уровня процессоров Intel поколений Haswell и Broadwell. А на недавней презентации, Лиза Су (Lisa Su) сообщила, что им удалось перевыполнить первоначальные планы, и итоговое улучшение составило 52%.

Итак, тестируемый AMD Ryzen 7 1700X постоянно функционировал на частоте 3,4 ГГц, с отключенной функцией Turbo Boost. «Синий» лагерь представлял Intel Core i5-7500 (3,4/3,8 ГГц) с активной Turbo Boost, т.е. фактически происходило сравнение производительности одного ядра Rysen 7 на 3,4 ГГц против одного ядра Core i5 на 3,8 ГГц. В итоге оба участника набрали по 111 баллов. Если же провести масштабирование результатов до частоты 3,8 ГГц, то получим 124 очка для процессора из «красного» лагеря.

Далее журналисты отмечают, что Ryzen 7 обладает на 33% большим кэшем L3, в пересчете на одно ядро — 2 МБ против 1,5 МБ. Для устранения этого недостатка, они взяли стоковый Intel Core i7-7700K (4,2/4,5 ГГц) который также оперирует 2 МБ кэша L3 на ядро, и набирает в тесте 140 баллов. А результаты Rysen 7 аналогично отмасштабировали до 4,5 ГГц, и получили 147 пунктов. Таким образом, увеличение объёма кэш-памяти, позволило старшему представителю семейства Kaby Lake сократить отставание с 12% до 5%, по сравнению со младшей моделью.

Пока остаётся открытым вопрос об итоговом частотном потенциале AMD Ryzen. Смогут ли они с лёгкостью достигать тех же 4,5 ГГц или нет, покажет время. Однако уже сейчас очевидно, что инженерам из Саннивейла удалось проделать отличную работу, и достичь сравнимой производительности с решениями Intel.

Читайте также: