Комментарии 18
И ни слова про главную драму последних лет (с Интел в главной роли), под названием «SMP мёртв, да здравствует NUMA». Со всеми вытекающими смешными эффектами (учитываешь NUMA — огребаешь глюки рескедулинга и своппинг на ровном месте, игорируешь NUMA — получаешь неожиданные пенальти за доступ к нелокальной памяти).
Ну так статья-то и называется «Процессоры, ядра и потоки», а не «Процессоры, ядра, потоки, NUMA, распределённая память, RDMA, их влияние на планировщик задач, Винни-пух и все-все-все». Надо и читателя пожалеть, в конце концов; да и автор рано или поздно поймает себя на том, что ушёл в дебри, которые он совсем не знает и про которые рассказывать не должóн.
А вот может быть вы расскажете: возможно ли построение систем с двумя различными процессорами? Например, один процессор поддерживает SSE4, а другой нет, но при этом они установлены в одну «материнку»? Или же оба процессора должны быть полностью идентичны?
Например, представьте себе поведение шедуллера на такой системе :)
Формально, ни в одной спецификации, способной вносить ограничения на существование подобных систем (конфигурация BIOS MP-систем, протокол загрузки MP-систем, описание структур ACPI, работа APIC) я не находил запретов на их построение. Поэтому ограничения тут могут прийти только со стороны софта (firmware и OS), который может быть не готов правильно управлять ресурсами в таком случае.
Так как практическая ценность подобных конфигураций пониженная, а вот число комбинаций, на которых пришлось бы тестировать работоспособность софта, возрастает при этом существенно (из-за комбинаторного взрыва при снятии ограничения на идентичность всех узлов), я не уверен, что многие вендоры операционок готовы затрачивать ресурсы на их поддержку, сертификацию и т.п.
Так как практическая ценность подобных конфигураций пониженная, а вот число комбинаций, на которых пришлось бы тестировать работоспособность софта, возрастает при этом существенно (из-за комбинаторного взрыва при снятии ограничения на идентичность всех узлов), я не уверен, что многие вендоры операционок готовы затрачивать ресурсы на их поддержку, сертификацию и т.п.
Спасибо! Значит, будет расчитывать на идентичные ядра :-) А как упадет — бежать туда и смотреть на эту экзотику :-)
Так как практическая ценность подобных конфигураций пониженная
Спорно. Типичнейший пример — ОС, а на ней крутится тяжёлая задача, скажем компилятор. Гетерогенная система со спецядром под ось вполне могла бы что-то принести в теории. Сложность обеспечения возрастает недопустимо, это да.
что-то вида big.LITTLE или nVidia Optimus для процов?
например музычка-браузер-итд — обычный холодный проц, атом...i3
серьезные нагрузки — перещелкиваемся/растормаживаем второй кристалл уровня i7...xeon
например музычка-браузер-итд — обычный холодный проц, атом...i3
серьезные нагрузки — перещелкиваемся/растормаживаем второй кристалл уровня i7...xeon
Безусловно, гетерогенные системы имеют право быть. Более того, у Intel есть как минимум два примера таких сценариев для IA-32. Интересно, что они находятся по разные стороны от «классических» десктопных/серверных систем в компьютерном континуме.
1. HPC-системы с процессорами Xeon в сокетах ЦПУ и Xeon Phi — в слотах PCIe. Низкоуровновое взаимодействие между ними происходит по протоколам стандарта PCIe (Memory mapped IO для запросов от ЦПУ к сопроцессору и DMA/прерывания для ответов с сопроцессора к ЦПУ). А так — на каждом крутится своя ОС, и информация о топологии должны передаваться более верхнеуровневыми протоколами между этими ОС.
2. Встраиваемая система Intel Edison c процессорами Intel Atom и Intel Quark. На первом крутится Linux, на втором — RTOS. Я, к стыду своему, пока ещё не знаю, как устроено низкоуровневое взаимодействие между ними, но опять же наличие двух ОС означает, что оно должно проходить через протокол высокого уровня, понятный обеим.
Мой ответ выше был, скорее, о системах с несколькими различными процессорами общего назначения. В обоих случаях описанных выше гетерогенных систем «весовая категория» входящих в них ядер разная, и между ними находятся довольно высокие барьеры к взаимодействию на аппаратном уровне. Однако, они оборачиваются удобством для задач прикладного программирования, от которого эта гетерогенность или прячется, или же чётко артикулируется и контролируется самой ОС и выбранной парадигмой программирования.
1. HPC-системы с процессорами Xeon в сокетах ЦПУ и Xeon Phi — в слотах PCIe. Низкоуровновое взаимодействие между ними происходит по протоколам стандарта PCIe (Memory mapped IO для запросов от ЦПУ к сопроцессору и DMA/прерывания для ответов с сопроцессора к ЦПУ). А так — на каждом крутится своя ОС, и информация о топологии должны передаваться более верхнеуровневыми протоколами между этими ОС.
2. Встраиваемая система Intel Edison c процессорами Intel Atom и Intel Quark. На первом крутится Linux, на втором — RTOS. Я, к стыду своему, пока ещё не знаю, как устроено низкоуровневое взаимодействие между ними, но опять же наличие двух ОС означает, что оно должно проходить через протокол высокого уровня, понятный обеим.
Мой ответ выше был, скорее, о системах с несколькими различными процессорами общего назначения. В обоих случаях описанных выше гетерогенных систем «весовая категория» входящих в них ядер разная, и между ними находятся довольно высокие барьеры к взаимодействию на аппаратном уровне. Однако, они оборачиваются удобством для задач прикладного программирования, от которого эта гетерогенность или прячется, или же чётко артикулируется и контролируется самой ОС и выбранной парадигмой программирования.
В принципе всё верно. Моя мысль в том, что гетерогенность была бы часто востребована, будь она более управляема. В разных сценариях, вот навскидку идея: есть у intel-а Galileo, типа Arduino с атомом вместо атмеги. Теперь покупателю надо выбирать либо то либо это, либо еще какую Arduino Due (с армом). Почему бы не добавить на кристалл Galileo атмегу и не сказать «вот вам плата полностью Arduino- совместимая но с возможностью попробовать более производительный Атом». Тут даже необязательно разрешать одновременную работу двух ядер. Почему плохо? А непонятно, под кого периферию точить.
Конечно возможно. Например, одновременные вычисления на CPU и GPGPU.
Чтобы задействовать GPU нужно сделать более сложные вещи, чем «Создать 1 поток на ядро, запустить». Гораздо более сложные вещи…
1. Давно пора уходить от создания потоков вручную. Есть специальные технологии и стандарты, например OpenCL или Cilk Plus. С точки зрения Cilk Plus добавить пару строк не должно быть очень сложной проблемой, чтобы получить гетерогенный код.
2. Вопрос был «возможно ли?..», ответ на этот вопрос был дан однозначный.
2. Вопрос был «возможно ли?..», ответ на этот вопрос был дан однозначный.
А как же приснопамятные Pentium D, почему этот любопытный вариант не разобрали :)?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процессоры, ядра и потоки. Топология систем