LINUX.ORG.RU
ФорумTalks

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

 ,


1

2

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

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

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

В итоге можно за разумные деньги делать компьютеры, имеющие тысячи таких ядер. Причём эти компьютеры смогут эффективно выполнять задачи, ложащиеся на модель акторов. Заодно и багов меньше будет.

★★★★★

Последнее исправление: Legioner (всего исправлений: 2)

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

V1KT0P ★★
()

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

Ты предлагаешь на уровне железа жестко разграничить доступ? Но уже сейчас можно это неплохо сделать. Всякие улучшения mmu делались не только для виртуализации, а более универсальны и работают довольно быстро. Если учесть, что у многих мнргоядерников давно numa, то уже довольно близко к твоей модели.

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

boowai ★★★★
()
Последнее исправление: boowai (всего исправлений: 4)

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

Ну перепиши файрфокс на эту модель, ну.

Серьезно, числодробилки так и делают, ниче нового ты не изобрёл.

t184256 ★★★★★
()
Ответ на: комментарий от TooPar

Дык gpu так и работает.

Не совсем, там группа ядер выполняет одинаковые инструкции. Это и создает проблемы переноса разных алгоритмов с ветвлениями на GPU.

V1KT0P ★★
()

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

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

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

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

atrus ★★★★★
()

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

tiinn ★★★★★
()
Последнее исправление: tiinn (всего исправлений: 1)
Ответ на: комментарий от atrus

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

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

tiinn ★★★★★
()

Знаешь что такое numa? вот ты предлагаешь её, только хардкорнее

upcFrost ★★★★★
()

Ты изобрёл RDMA и NUMA. Только там не processor а host и node со своей памятью

Nastishka ★★★★★
()
Ответ на: комментарий от tiinn

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

Если более медленная работа для вас не большая проблема в процессе решения задачи обеспечения более быстрой работы, то я даже не знаю... :)

https://stackoverflow.com/questions/56122923/dma-transfer-taking-more-time-th...

atrus ★★★★★
()
Ответ на: комментарий от TooPar

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

Legioner ★★★★★
() автор топика

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

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

torvn77 ★★★★★
()
Ответ на: комментарий от atrus

Если более медленная работа для вас не большая проблема в процессе решения задачи обеспечения более быстрой работы, то я даже не знаю… :)

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

tiinn ★★★★★
()

Почему не делают - делают. Называется HPC кластер, rdma всего в 100-1000 раз дороже доступа к памяти, может уже даже и лучше. Просто софт то обычный ты не перепишешь весь оперативно на такую парадигму, там с обычными то потоками люди путаются, а тут ещё IPC какой-то приплетается и разные часики в системах.

pon4ik ★★★★★
()
Ответ на: комментарий от tiinn

производительности там хватает.

Нет. Там уже NUMA во все поля. Впрочем на современных многоядерниках тоже локальность памяти приходится учитывать. Начинает иметь значение...

atrus ★★★★★
()

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

но если уж делать независимые ядра, то память должна быть не только быстрая-локальная и медленная-общая, но и третьего типа: «локальная-отчуждаемая»
«локальная-отчуждаемая» память почти такая же быстрая, как локальная, но ядро имеет возможность отдать блок своей локальной-отчуждаемой памяти другому ядру
такое переключение занимает какое-то время (намного быстрее, чем копирование данных между ядрами), и после этого переключения этот блок памяти становится локально-отчуждаемой памятью другого ядра

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

да и фича «пролетарии всех стран, объединяйтесь» (все ядра отдают всю свою «локальную-отчуждаемую» память какому-то одному ядру) была бы очень полезной в некоторых ситуациях

Egor_
()
Ответ на: комментарий от cobold

Проблема в том, что цена поддержания когерентности кеша растёт слишком быстро и съедает производительность. Ощущаться начинает примерно с сотни процессоров, так что в потребительском сегменте пока жить можно. Но учитывая что под 50 ядер уже вроде выпускают, стоит начинать беспокоиться.

atrus ★★★★★
()
Ответ на: комментарий от Egor_

Коллизии в кешах возникают только если по адресу памяти идёт чтение/запись из неск. потоков, так что она, можно сказать и так «локально-отчуждаемая»

next_time ★★★★★
()
Ответ на: комментарий от atrus

Ну так проблема в решаемых задачах и алгоритмах применяемых для решения. Числодробилки особо не страдают. Всякая вебня(rest api) хорошо параллелится в парадигме 1 запрос - 1 процесс

cobold ★★★★★
()

Ты Cell что-ли придумал?

Begemoth ★★★★★
()
Ответ на: комментарий от atrus

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

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

Думаю так.

snizovtsev ★★★★★
()

Есть процессорные архитектуры и без когерентного кэша, если что.

mv ★★★★★
()
Ответ на: комментарий от snizovtsev

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

cobold ★★★★★
()
Ответ на: комментарий от atrus

Спора нет, есть и в численных методах задачи, которые не особо параллелятся из-за связности по данным

cobold ★★★★★
()

Было бы здорово конечно, только весь софт уйдёт на свалку. А главное никто не станет выпускать на рынок цпу, на котором винда не пойдёт.

Да, есть конечно кластеры и numa - какая то подсистема согласования кусков памяти между узлами с учётом скорости доступа. Но я хз как это работает на практике и как условный гмип или файерфокс будет на таком работать.

kirill_rrr ★★★★★
()
Ответ на: комментарий от next_time

ты не понял
отчуждаемая память отчуждается вместе со своим содержимым
данные остаются физически на своих местах (в той же микросхеме памяти)
просто мультиплексор отсоединяет эту микруху от одного ядра и подключает к другому

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

Egor_
()

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

Если разработчики не могут эффективно утилизировать даже относительно небольшие многоядерные системы, то сколько же уйдёт времени, пока они научатся эффективно писать код для систем с тысячами ядер?

Возможно, дело в слишком узкой нише для таких систем? Для сервера, обрабатывающего один запрос на одном ядре такая архитектура, наверное, подошла бы хорошо, но как быть с десктопами?

kmeaw ★★★
()

Текущая архитектура процов самая тупорылая и все это начинают понимать. Раньше не было кешей. Само наличие оперативной памяти уже увело нормальные мозги в сторону и им уже тяжело представить, как проц может работать без всего этого. Для отвода глаз придумали проект The Machine, но нам чешут, якобы усё эта сложнаа.
Отсюда следует, что нужно менять основу, а не придумывать очередные костыли...

xwicked ★★☆
()
Последнее исправление: xwicked (всего исправлений: 1)
Ответ на: комментарий от pon4ik

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

Совершенно всё неправильно. Модели акторов делаются с целью упростить программирование. Они гораздо проще чем «обычные потоки». В этом их смысл.

fsb4000 ★★★★★
()
Ответ на: комментарий от cobold

терминология:
«медленная общая память» = оперативка
«быстрая локальная память» = кеш
«быстрая локальная отчуждаемая память» = кеш, подключаемый к любому выбранному ядру

твой вопрос: «как данные из кэша попадут в кэш?»
ответ: они уже там!

Egor_
()
Последнее исправление: Egor_ (всего исправлений: 1)
Ответ на: комментарий от Egor_

Вот у тебя есть поток А, он загрузил свои данные в «отчуждаемую» память и с ними работает. Есть поток Б, он тоже захотел эти данные. Хочешь, чтобы поток Б когда ему надо отбирал данные у потока А? Так всё сломается

next_time ★★★★★
()
Ответ на: комментарий от Egor_

в последней ссылке полубайт (ниббл) называют «клев»

интересно, откуда этот русский термин?

Хе-хе, по-моему, это просто тупой перевод слова nibble. :) Кто-то тупо переводил. «Институт белки». Я, если честно, никогда не встречал использование слова «клев». Нибл - да, полубайт - да, тетрада еще.

Zubok ★★★★★
()
Ответ на: комментарий от fsb4000

Было бы это проще при той же эффективности давно бы уже софт переписали бы, или хотя бы новый писали в рамках этой парадигмы. Не спорю, скорее всег, для определённого класса ПО это и правда лучший путь.

pon4ik ★★★★★
()

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

Сейчас самая большая проблема распределенных вычислений, насколько понимаю - это именно что задачи класса NUMA, и вся эта орда ученых пытается их решить и придумать алгоритмы для вот этого, поэтому первыми выстрелят именно NUMA

И кстати, есть идея, что и прямо сейчас можно сделать архитектуру, которую ты хочешь - это архитектура с кучей отдельных дырок под процессоры, то что называют «серверной материнской платой», и включенной NUMA. Можно прямо сейчас пойти купить такую.

Проблема, что стоит это ДОХРЕНА, т.е. твое предположение что всё будет дешево и круто не выполняется! Что же могло пойти не так!?

Вторая перспективная штука в работе с памятью - это Persistent Memory, вроде Intel Optane DC Persistent Memory. Для неё тоже нужны свои алгоритмы, которые потом осядут в библиотечном коде, и только потом ими можно будет воспользоваться.

К сожалению, Intel Optane DC доступен вообще в люто малом количестве процов - кажется, это только какие-то Xeon Platinum и всё. Это всё еще можно купить в магазине, но ты не захочешь.

stevejobs ★★★★☆
()

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

Shadow ★★★★★
()
Ответ на: комментарий от next_time

Хочешь, чтобы поток Б когда ему надо отбирал данные у потока А?

ох уж эти коммуняки, им лишь бы отнять и поделить!
нет, тут всё по-буржуински, все уважают чужую собственность
когда поток А хочет запустить потоки Б и В и каждому передать свой буфер данных, он передаёт этим потокам ПРАВО СОБСТВЕННОСТИ на эти куски памяти. соответственно, из адресного пространства потока А эти куски исчезают.

Egor_
()
Ответ на: комментарий от Egor_

Ну так L3 кэш так и работает, он шарится между ядрами. Непонятен смысл операции отчуждения, ну не обращайся к данным по адресу XXX из ядра 0 и обращайся из ядра 1

cobold ★★★★★
()

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

cobold ★★★★★
()
Ответ на: комментарий от stevejobs

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

cobold ★★★★★
()

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

x3al ★★★★★
()
Ответ на: комментарий от cobold

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

Принципиально отличается тем, что сейчас между кешами пересылаются все изменения, которые попали в кеш. Вот тебе пример, пусть и вырожденный, но для демонстрации проблемы подойдёт. У меня есть массив из 16 4-байтовых чисел. Это размер кеш-линии, насколько я помню. У меня есть Ryzen на 16 ядер, на каждом ядре я запускаю поток. Каждый поток обрабатывает отдельное число по какому-нибудь там алгоритму и меняет его. Этим потокам не нужны значения соседних чисел. Но процессор будет усердно гонять трафик между ядрами при каждом изменении, синхронизируя это всё в кешах. Если же ты пишешь актор, трафик пойдёт исключительно полезный. Исключительно тот, который ты будешь посылать.

Legioner ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.