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

Зачем делать один компьютер с кучей ядер если можно сделать несколько?

Потому, что это дешевле.

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

Специальная шина будет гораздо быстрей и по пропускной способности и по латентности.

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

Сколько угодно не могу.

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

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

при чём тут интеловский L3 кэш?
где ты у интела 1000 ядер видел?
в архитектуре, которая обсуждается в этой теме, у каждого ядра есть индивидуальная быстрая память, и общая медленная.

а как поток А узнает, что потокам Б и В эти куски памяти вообще нужны? и какому потоку какой кусок

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

на разделяемый интеловский L3-кэш не надейся - когда будет 1000 ядер, он перестанет быть разделяемым )))

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

У ядер интел-совместимых процов есть быстрая индивидуальная L1/L2 кэш память и разделяемая L3/системная память + протоколы обеспечения кэш-когерентности данных в L1/L2. До Sandy bridge по-моему не было L3, но был общий L2. ARM-процессоры в этом плане устроены примерно так же.

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

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

А на 1000 ядер процессор сделать можно, но стоить будет дорого(стоимость пластины сейчас емнип $300k + что-то надо делать с бракованными ядрами + какая механическая прочность будет у кристалла такого размера), нужно будет отводить много тепла и подводить огромные токи для питания. По этим причинам пока выглядит целесообразнее делать ядер поменьше и набивать нужное кол-во ядер серверами по 112-128 ядер в каждом

насчёт «целесообразности»:
у нас (где я работал 4 года назад) оракловая БД работала на 700+ ядерном сервере (сервер один, не RAC)

А на 1000 ядер процессор сделать можно, но стоить будет дорого(стоимость пластины сейчас емнип $300k + что-то надо делать с бракованными ядрами + какая механическая прочность будет у кристалла такого размера), нужно будет отводить много тепла и подводить огромные токи для питания.

Так ведь сделали уже такое, называется Wafer Scale Engine и у него 400 000 ядер и 18 GB SRAM памяти. Размер 21.5 см х 21.5 см. И эта бандура жрет 20кВт энергии. Сделан по технологии 16нм, так что в перспективе на 7/5/3 нм можно еще нарастить количество процессоров.

О, а как выглядит такой сервер? Или это виртуалка растянутая на сколько то блейдов?

Да, читал об этом монстре, но так и не понял насколько это реальный продукт

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

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

для систем массового обслуживания

системы массового обслуживания - это одно (напр, вебня, где всё более-менее легко параллелится),
а SQL-БД - это совсем другое (операции должны выполняться логически последовательно, блокируя необходимые ресурсы на время выполнения)
это совсем другое на алгоритмическом уровне, тупое шардирование данных помогает очень слабо

пример: в одной конторе, где я работал 10 лет назад, решили 4-нодовый RAC расширить до 8-нодового, чтобы оракловая база стала пошустрее. докупили железа, подключили. расчитывали на увеличение производительности примерно в 2 раза, на практике получили всего +30%
такие дела: бывают труднопараллелящиеся алгоритмы, где девять женщин не могут родить ребёнка за 1 месяц

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

ОП хочет получить 1000-ядер за счёт отключения всего этого.

А на 1000 ядер процессор сделать можно, но стоить будет дорого(стоимость пластины сейчас емнип $300k + что-то надо делать с бракованными ядрами + какая механическая прочность будет у кристалла такого размера), нужно будет отводить много тепла и подводить огромные токи для питания.

Даже классические процессоры уже делают чиплетами. Что убирает все проблемы с размерами и браком. Т.е. ты не вырезаешь 1000-ядерный процессор из одной пластины. Ты вырезаешь из пластины малюсенькие кусочки по одному ядру. Например миллион ядер. Рисуешь одну плату с нужными интерконнектами любого размера и припаиваешь каждое ядро к этой плате. Ровно так же, как делает AMD. Только выйдет дешевле.

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

проблема наращивания числа ядер в процессорах, очевидно, идёт от необходимости иметь общий доступ к оперативной памяти

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

В 2012-13 появился «суперкомпьютер» Adapteva Parallella. 16 ядерный Epiphany III + FPGA в соседи за смешные деньги. А вот за 64-ядерный Epiphany IV люди не хотели заплатить. Так что он не пошёл в массовое производство, но некоторым достались единичные экземпляры. А потом в связи с успехом и выходом в 2016 году 1024-ядерного(!) 64-битного Epiphany V основателя фирмы пригласили вояки, и он намекнул, что о коммерческой доступности можно не мечтать.

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

Не делают? А, может, мы об этом не знаем или не имеем доступа?