Комментарии 46
Все идеи и алгоритмы, описываемые в данной статье, являются результатом моей независимой и полностью самостоятельной интеллектуальной деятельности. Как автор, разрешаю свободно использовать, изменять, дополнять все идеи и алгоритмы любому человеку или организации в любых типах проектов при обязательном указании моего авторства.
Засада в том, что на идеи-то и так не требуется разрешений (и потому и потребовать в случае их использования ничего не можете)... Вот если у вас эти идеи запатентованы в качестве технических решений, то да.
Но можете дать разрешение на использование ваших описаний своих идей и алгоритмов - они однозначно защищаются авторским правом. И к ним можно применить "открытую лицензию" (которую вы, похоже, и пытаетесь процитированным обозначить).
Если преследуете этим заявлением какую-то практическую цель, помимо декларации, можем обсудить...
Одобряю, дело полезное.
Но тут как-бы и самой публикации до даты приоритета заявки должно быть достаточно ("Уровень техники для изобретения включает любые сведения, ставшие общедоступными в мире до даты приоритета изобретения."). Так что чем больше всяких идей будет описано в общедоступных источниках - тем лучше в плане возможностей оспаривания патента (или по крайней мере применимости его к конкретному спору, если техническое решение не полностью совпадает с патентом истца).
Правильно сформулированным текстом можно дать разрешение на использование объекта авторского права (т.е. фактически сформулировать лицензию на него). Напоминаю, что алгоритмы авторским правом не защищаются, но зато защищаются их описания (поэтому нельзя просто так взять кусок описания из Интернета и использовать в своих целях просто потому, что он опубликован в Интернете). Также нельзя просто взять и сказать "да пользуйтесь кто хотите" - это в каких-нибудь США работает, например, в виде лицензии BSD - у нас она до 2014г. вообще лицензией не являлась, да и сейчас "на грани" кроме как для программ для ЭВМ и баз данных.
Единственно что я хочу это сильно затруднить жизнь «патентным тролям» различного уровня в выкачивании денег из пользователей, новой вычислительной техники.
Старая со всеми их патентами и привелегиями скоро уйдет в небытие — думаю ничего не останется. Вообще считаю современную систему патентных отношений глубоко порочной, все что должно остаться это имя автора (или коллектива авторов).
Все правообладетели пойдут лесом.
В вопросах разрешения на использование и тд все решают деньги и банально у кого их сильно больше тем и поровну на все патенты и тд.
Зависит от страны. В странах типа США, где выиграть суд может оказаться дороже, чем проиграть, оно примерно так и есть, в других странах уже повеселее (в хорошем смысле этого слова).
Вообще считаю современную систему патентных отношений глубоко порочной
Тут палка о нескольких концах.
По большому счёту если сейчас ликвидировать патентную систему - прогресс не остановится, в основном потому, что "ноу хау" тоже охраняется законом, и всё равно вряд ли вы адекватно воспроизведёте реальный (а не бумажный) патент без подобных "тайных знаний", а заново что-то изобрести не так уж сложно.
Единственное, где это реально имеет общественно-полезный смысл (не путать с бизнес-инструментом уничтожения конкуренции) - это фармация и подобные вещи. Но с оговоркой - при условии, что патентная защита предоставляется в обмен на требование раскрытия информации - надо ж убедиться, например, что лекарство безопасно и на самом деле работает (ну и чтобы там никаких "тайных знаний", без которых оно превращается хорошо если в тыкву)?
Все правообладетели пойдут лесом.
Вот написал статью, и даже еще не опубликовал - но у неё уже есть правообладатель. Радует правда, что авторское право - не патентное, реализовывать те же идеи самостоятельно ничто не мешает.
что-то я не понял как 1000 ядер планирует использовать сериализованную консистентность и при этом быстро работать. Допустим, у нас 1000 тредов, которые что-то там себе молотят, и в нужный момент решают получить мьютекс. Мьютекс в памяти. Вот процессоры [1-500] решили одновременно получить мьютекс, т.е. сделать +1 в байт памяти.
Как это электрически разруливаться будет? Кто и как синхронизирует процессоры, у которых разный размер длины дорожек до контроллера? Как процессоры при этом умудряются быть быстрыми, если всем нужно дождаться ответа от одно и того же контроллера?
Каждый процессор содержит коммутатор, время коммутации примерно 1-2 нс (в зависимости от тактовой чатоты коммутатора). Соответственно соединение проходит через промежуточные коммутаторы (15 для самой длинной).
Основой соединени является канал между передатчиком и от одного до 1000 приемников.
Как получается до 1000 приемников — канал передачи синхронный и каждый коммутатор для него вырождается в регистр. Вся цепочка промежуточных коммутаторов в FIFO. При этом в промежуточном коммутаторе есть возможность записать в несколько регистров одновременно, которые будут отправлены в различные интерфейсы. Получаем дерево — один источник, любое число приемников.
Используя один такой канал «хозяин» оригинала памяти производит рассылку изменений всем держателям копий одновременно.
Если держатель копии хочет изменить слово в памяти, он отправляет «хозяину» оригинала запрос на изменение. У «хозяина» оригинала есть отдельные каналы связи с каждым владельцем копии и он по какому то своему алгоритму преобразовавает поступившие запросы (часть из них могут приходить и совсем одновременно) в единую для всех последовательность изменений. Редактирует содержимое оригинала и формирует канал с уведомленими о изменениях.
LOCK и тд это отдельный вопрос.
Хочу добавить: Если сделать +1 к памяти такая нужная операция, то делать ее нужно не путем блокировки переменной ее изменения и разблокирования, а отправкой «хозяину» оригинала запроса на увеличение данных на 1. Время обработки 500 обращений будет равно времени передачи 500 обновлений памяти. Каждый получит результат исполнения своего запроса (персональное уведомление), ну и еще все сделанные обновления (за время менее мкс сформируется очередь).
Мне страшно вас читать. Скажите, вы модель памяти современных компьютеров знаете? acquire/release семантику и т.д.?
Термины отличаются от программиста, соответственно нам нужно договариваться о значении того или иного термина.
Поясните, что Вам не понравилось: Запись многими процессорами (ядрами, нитями) по одному и тому же физическому адресу данных породит последовательность изменений, обновлений копий.
Для программиста это выразится в чтении случайного варианта изменения.
Для схемотехника произойдет построение последовательности изменений данных, иными словами будет получена очередь доступа к разделяемому ресурсу.
Полученную очередь можно пропустить через систему приоритетов (должна быть одинакова для всех процессоров). И все это происходит за время единичного доступа в память 50нс + Время обновления, время обновления пропорционально производительности скорости сети.
Как работа данного алгоритма будет «состыкована» с конкретной моделью процессора и его системой команд, другой вопрос. Скорее всего прозрачно для программиста и так как это уже реализовано для конкретной вычислительной системы (обеспечение совместимости).
Как пример cc-NUMA, программу не видит принципиальной разницы между своим и чужим кэшем, все алгоритмы выполнены схемотехником и прозрачны для программиста.
Что касается специфических терминов, то их придумали для оптимизации общения специалистов из одной области знаний.
Хотелось бы добавить, что архитектура фон-Неймана по своей природе не предназначена для параллельного программирования, в ней всего одна нить и один процессор. Из-за этого постоянные «танцы с бубном» практически по любому поводу и что самое печальное, неэффективное расходование вычислительных ресурсов.
Никому не нужна последовательность записей. Всем нужна эксклюзивность: если я записал, остальные не записали.
Обычно это делается инструкцией cas: https://en.wikipedia.org/wiki/Compare-and-swap
При этом повторного запроса на запись не потребуется, очередность записей уже построена и будет кооректироваться в моменты поступления дополнительных запросов.
Еще следует отметить возможность вычислить время когда подойдет очередь на доступ к разделяемому ресурсу, что позволит на это время загрузить процессор другой задачей.
Можно добавить функционал таймаута — после прохождения определенного времени ресурс автоматически освобождается для использования следующим в очереди.
Если позволяется параллельное чтение разделяемых ресурсов, то все запросы на чтение будут обслужены параллельно. Понятное дело что с запретом записи в этот момент.
Можно реализовать много усовершенствований позволяющих повысить производительность.
Например: Процессор выполняет «виртуальную» блокировку ресурса, производимые изменения данных не отправляются сразу. Если за время «виртуальной» блокировки не происходит модификации памяти, то процессор выполняет реальную блокировку и разом отправляет все необходимые изменения. Такой подход имеет свои плюсы при преобладании чтений над модификациями.
Что такое "встать в очередь" с точки зрения процессора №499? halt? интеррапт?
Мне кажется, что отсутствие ответа на такие вопросы - это признак того, что вы просто про них не думали. Ответ на этот вопрос определяет, будет ли это быстрый компьютер, или он будет "теоретически 1000 ядерный" а на практике молотить с 1.5х скоростью (относительно скорости одного ядра).
Разговаривал с заместителем директора достаточно большой и известной компании производящей телекоммуникационное оборудование (на хабре статьи про них и их оборудование периодически пишут), он ответил просто:
«Наша компания не занимается „наукой“ это слишком дорого и рискованно, мы покупаем, припаиваем стандартные микросхемы, устанавливаем платы в корпус и продаем». Российский разработчик трансиверов конкретно не ответил, но тема им интересна и потянуть сами они ее не могут. Наш крупный разработчик процессоров (ответ получил устно и с большим трудом): Советом директоров принято решение ничего вам не отвечать. Производитель (разработчик) оптических коммутаторов не ответил, хотя практически наверняка получил все описания по разным каналам. Попытался связываться с различными учеными, абсолютному большинству лень изучать новое направление (среднее ощущение от общения), а профильной научной школы в нашей стране нет.
Сейчас появился прогресс, вроде начал интересоваться университет как темой для научных работ.
По факту все уйдет в Китай, в нашей старане нет заинтересованности в новых разработках, этикетки переклеивают да конструктор из готовых ядер создают.
Сегодняшние статьи это часть огромного проекта и именно поэтому я стараюсь сделать его свободнораспространяемым. По факту я проектирую основу новой технической (технологической) революции. Ну и если очень повезет, то до своей смерти смогу создать описываемое в этой статье ( habr.com/ru/post/489068 ). Звучит как фантастика, но я хочу заниматься чем то действительно большим и сложным.
По поводу производительности: С хорошей вероятностью будет увеличение производительности на три порядка от современных машин (для этого и нужны скорости в сотни триллионов бит в секунду), мне нужно система для исследования и синтеза биологических структур с производительностью эквивалентной 10Е20 FLOPS
Знаете, почему вам директора решили не отвечать? Потому что вы обещаете три порядка увеличения производительности, игнорируете проблемы и излагаете "решение" пропуская критические проблемы, требующие решения.
Прожекторство чистой воды. Особенно, когда вы уверены в увеличении производительности. Математики ноль, опыта разработки компьютеров ноль, апломба - на три порядка.
Первая прочитананная книга по вычислительной технике в 10-12 лет (точно не помню) — белый «кирпичик» IBM 360 ( www.ozon.ru/product/programmirovanie-na-ibm-360-dzhermeyn-k-291587098/?sh=eZaabHMV ) ничего не понял, но очень понравилось. Ну и само оборудование понравилось. Рядом с нашей школой несколько институтов было и у нас информатика была с использованием машин EC10XX, занимающим целый этаж (тогда персоналок еще небыло). Задачи запускались в пакетном режиме, выдача результатов работы программы в виде распечатки на барабанном принтере бумага с перфорацией по краям.
Печатный узел — цилиндр диаметром в 200 мм на котором выгравирован весь алфавит — один оборот одна строка.
А если неудачно руку засунешь, то и руки не станет. Дискетка диаметром в пол метра и высотой в 15 см примерно. Байки ходили, что если плохо установить может пополам разрезать. Фальшпол из аллюминиевых плиток. Кстати успел немного поремонтировать машины CM-1420 (ее ассемблер очень нравится). Интересное время ))))
В этом основная нерешаемая проблема.
..при записи происходит запись одновременно и в удаленные копии памяти и в свою, при чтении чтение производится только из своей копии.
А в удалённую пишут другие, а вы всё равно продолжаете читать свою копию. И где здесь принцип совместной памяти? Ок, вы добавите регулятор когда, куда, после чего итд. Ну те то, что сегодня в принципе уже существуют...
Если бы я изобретал (запомните, это моя идея), то я бы сделал своего рлда RAID Controller для рабочей памяти. Когда пишут все в одну точку, это параллельно сохраняется на несколько компонентов, а читать каждый может на свей части этого RAID Controller(а). Хотя как это реализовать без усложнения и доп. шин данных мне пока не ясно.
И вообще. Моё мнение. Не возможно описать наглядно действия схемы/памяти/большого количества компонентов итд. и при этом не нарисовать ни одного рисунка. Словами создаётся огромное поле для (false) интерпритации . Для себя и других для других.
1. В момент записи процессором в свой локальный кэш формируется запрос на изменение данных «хозяину» оригинала данных, а запись в локальный кэш не производится.
2. Запрос отправляется, а локальном кэш ставится отметка о транзакции, только при попытке прочитать данные по этому адресу процессор остановится и будет ожидать завершения запроса.
3. Запрос передается по сети, попадает в контроллер DSM оригинала данных, он добавляет запрос в последовательность изменений и отправляет уведомление всем держателям копий.
4. Получив уведомление о выполнении своего запроса на изменение данных, локальный DSM контроллер производит запись в локальный кэш.
Между моментами формирования зопроса на изменение данных и ответом на этот запрос могут приходить уведомления о изменении данных инициированные другими процессорами.
«Если бы я изобретал»
Здесь именно так и сделано: Вариант работы сквозная запись, все направляют запросы на запись контроллеру DSM владеющему оригиналом памяти, а он уже параллельно корректирует содержимое всех копий в одинаковой для всех копий последовательности.
по этому адресу процессор остановится и будет ожидать завершения запроса.
Извините, но вы изобретаете то, что уже есть. Уверен, надо идти совсем в другом направлении. Например большое количество ядер всё равно пишет в одно и тоже место. Может быть стоит в этом направлении подумать...
Современные программисты очень плохо реагирует на заявления о том что все их профессиональные навыки скоро станут устаревшими. Много раз повторяемая история с луддитами. ))
Да ладно вам. Сразу на людей, которые с представленными идеями или представлениям не совсем согласны - навешивать ярлыки, сразу переходить на личности. Как в исследование, где изучалось, как быстро в дискуссии один другого фашистом или нацистом обзывает.
Пока не услышал новшества, только что-то ждёт, пока транзакция не закончится. Как она будет реализована, извиняюсь - второстепенно, но будет задержка, которую имеем и сегодня, когда из разных процессов на одни и те же участки памяти происходит обращение. Но, если вы уверены в вашем новшестве, я рад за вас.
Мне нравятся вот эти предсказания о технологических укладах: ru.wikipedia.org/wiki/Циклы_Кондратьева.
Над этим работаю: НБИК-конвергенция (NBIC-конвергенция) — гипотетическое ядро 6-го технологического уклада, основанное на объединении и синергетическом усилении достижений нано-, био-, информационных и когнитивных технологий. Результатом НБИК-конвергенции будет являться полное слияние этих технологий в единую научно-технологическую область знания[1].
Был так же усовершенствован многопортовый лазер SuperNova, который теперь поддерживает до 64 настраиваемых длин волн излучения и до 256 каналов, что даёт суммарную пропускную способность 8,192 Тбит/с. Он стал первым продуктом, совместимым со спецификациями CW-WDM MSA, отраслевого консорциума, который разрабатывает стандарты для передовых оптических коммуникационных и вычислительных приложений. При его создании разработчики использовали лазерные технологии MACOM, оптимизированные для кремниевой фотоники.
Как программист со стажем, успевший поработать и в телеком и High Performance Computing сфере - я не могу придумать реальных задач, которые могли бы извлечь практическую пользу от реализации указанной схемы на уровне "железа". Обычно задачи распараллеливаются либо не распараллеливаются. В случае если задача распараллеливается - это проще, более предсказуемо и дешево выполнить надежный как мир MAP-REDUCE и учитывать вертикальное и горизонтальное масштабирование вычислительной системы. Так что "числомолотилки" в конечном счете не выиграют, либо выиграют очень мало, по сравнению с аппаратными затратами.
ИМХО, в контексте статьи вертикальное и горизонтальное масштабирование сливается в какую-то единую (плохо контролируемую лично для меня) сущность, где получить предсказуемые показатели производительности не представляется возможным. Опять же возникает вопрос отказоустойчивости: что если падает нода с эксклюзивными данными? К кому перейдет право писать-читать потерянный сегмент? Как поведет себя система в целом, если лишится части "процессоров" и распределенных блоков данных?
На практике обычно нет однозначного ответа на эти вопросы, поэтому, исходя из контекста задачи, проектировщик выбирает подходящие software-tools. Это более гибкий и дешевый подход нежели "прожигать" поведение в аппаратной части. Отчасти, поэтому, я почему-то так считаю, производители железа и не собираются решать описанную Вами задачу, в то время как имеется большое количество программных средств, реализующих это пусть и не на скорости света в оптоволокне, но, с учетом распространенных паттернов проектирования, более гибко и надежно.
Прошу прощения, что не вдумывался в каждой предложение в процессе чтения, но опять же что-то мне подсказывает, что в статье не учтены всякого рода тонкости работы с шареными данными, я уверен, что прочитав реализацию базового MESI Cache coherency protocol https://en.wikipedia.org/wiki/MESI_protocol можно почерпнуть много интересного. Отчасти еще и поэтому производители железа, вероятно, не стремятся реализовывать Вашу идею, не ломая при этом существующую совместимость стандартов.
ИМХО, Distributed RAM должна строиться с учетом текущей модели Cache-RAM-DRAM, что с успехом реализуется существующими софтварными решениями.
я не могу придумать реальных задач
Обработка больших данных.
По поводу излишней скорости сети, мягко говоря Вас не поймут.
Вопросы ошибок передачи, в том числе с потерей промежуточных коммутаторов это задача сетевого протокола.
Сбои в работе отдельных процессоров: Думаю это не новая задача, возникшая в момент появления высокоскоростной сети.
При потере узла с оригиналом данным, просто подключится резервный. Он так же получал обновления, значит имеет последнюю версию данных. Произойдет переключение канала обновлений на резерв и все.
Показатели производительности гарантируются самой природой плезиохронного канала. Если канал создан, то с этого момента его производительность никак не зависит от загрузки любых других каналов.
должна строиться с учетом текущей модели
все модели рано или поздно меняются или уточняются. Раньше считали, что солнце вращается вокруг земли, а звезду неподвижно закреплены на хрустальной сфере небес.
се модели рано или поздно меняются или уточняются. Раньше считали, что солнце вращается вокруг земли, а звезду неподвижно закреплены на хрустальной сфере небес.
Не очень подходящая аналогия, на мой взгляд. Вы ведете речь не об уточнении модели, а о полноценной замене. В данном контексте "замена" отрицает накопившийся годами легаси подход существующего стека технологий в организации памяти: система кешей, когерентность кеша, и, как заметил, комментатор @amarao acquire/release семантику.
Текущий стек технологий прекрасно себя чувствует и показывает на имеющемся скопе задач и приносит всем неплохие бабки. В этом плане вносить избыточную сложность в ЦПУ общего назначения и разрабатывать "протоколы синхронизации" и отказоустойчивости на базе железа, а не софта (а ведь именно это предлагает делать автор, если я достаточно внимательно прочитал) в целом не выгодно ради 
% задач по переумножению матриц. Проще сделать специализированное устройство для перемножения матриц :) Хотя... оно уже есть - GPU! И соседствует рядом с Network Interface Controller, на PCI-E. Так что с точки зрения преемственности технологий и имеющего легаси - лучше двигаться в данном направлении коммутации GPU устройств.
Думаю это не новая задача, возникшая в момент появления высокоскоростной сети.
Конечно это не новая задача. Речь идет о реализации этого всего этого в железе (в ЦПУ в том числе) и удорожании и усложнении всего этого комплекса. Также добавит latency к операциям, придется вводить еще слой синхронизации и т.д. В любом случае будет trade-off между гарантией консистентности и производительности. НО, как я уже упомянул в своем первом комментарии - каждое приложение/задача требует индивидуального подхода в этом вопросе.
ИМХО, интересная задумка в качестве "прожекта"
Следущая стаья будет про принципы построения процессора с производительностью на несколько порядков быстрее современных (на порядок быстрее GPU).
А про бабки, то почитайте здесь: tproger.ru/articles/jeksperiment-bazermana-kak-my-ezhednevno-terjaem-dengi/?utm_referrer=https%3A%2F%2Fzen.yandex.com
Сделайте, пожалуйста, умножение распределенно хранимых матриц (по причине, что в память одной машины влезает от силы 1/1024-я часть) на MAP-REDUCE.
Хотя эта проблема давно решена RDMA
Проблема перемножения матриц стара как мир и еще старше, чем MAP-REDUCE. В сети полно алгоритмов перемножения в т.ч. cache-friendly. Классическая задача на GPGPU решается с помощью перемножения матриц по-блочно. И при учете параметров кеша, особенностей вычислительных блоков и некоторых других факторов решается быстрее на GPU, чем на CPU (даже с учетом трансферинга через PCI-E).
С другой стороны, насколько я знаю, распределенные системы для DeepLearning используют MPI (Message Passing Interface) для своей работы (которому также уже лет 40), и перемножение матриц также можно организовать последовательностью allgather/allreduce и тд.
по причине, что в память одной машины влезает от силы 1/1024-я часть
А можно у Вас поинтересоваться, что за область компьютерного знания требует перемножения и хранения матриц таких объемов? Учитывая, что современные серверные ЦПУ, как правило, снабжаются сотнями гигабайт оперативной памяти
>Проблема перемножения матриц стара как мир и еще старше, чем MAP-REDUCE
Именно. И MAP-REDUCE с ней работает плохо.
>А можно у Вас поинтересоваться, что за область компьютерного знания требует перемножения и хранения матриц таких объемов?
Физические расчеты. Квантовая механика/химия, аэро/гидродинамика, сопромат и т.п.. Зависит от размера задачи, конечно. И IRL задача решается с использованием MPI.
Самый тяжелый случай для вычислений: моделирование поведения молекул воды в объеме биологической клетки.
Минимальный размер клетки 5 мкм: объем 4 х 10^-10 грамм или 1.34 х 10^13 молекул воды или 4х10^13 атомов.
Хочется знать сколько вычислительных операций в среднем требуется для моделирования поведения одного атома в «ансамбле» из 4х10^13. Очень надеюсь что для вычисления поведения каждого атома не придется учитывать все атомы «ансамбля». Сколько соседних атомов в среднем участвуют в рассчетах по предсказанию положения конкретного атома при этом за одну итерацию любой атом не изменяет своего положения больше чем на диаметр атома водорода.
поведения одного атома в «ансамбле» из 4х10^13
… не в сути всех ваших умножений, но после того, как слышу огромные числа для определения того или иного результата всегда думаю следующее. А правда, что например именно все матрицы и их числа должны быть перемножены? Или есть в этих результатах такие, которые по количеству и кол-ву операций малы, но сильно дейаствуют на сам результат? И тонна других, которые какие-то оставшие 5-10% результата «весят». Т.е. последними можно пренебречь-? Ведь и падения яблока с дерева можно решать, используя при этом все атомы вселенной, их положение и вектор перемещения, но можно и простой формулой из физики обойтись. Я не то, что-бы ставлю ваши цели под вопрос. Но очень часто стоит ненужными вещами пренебрегать. Хоть это и не всегда легко и повышает неточность.
Часто парметр приобретает критичность только для определенногонабора и значения других параметров. Вычисление этих заисимостей будет более трудоемко, чем просто посчитать результат для всех данных.
Еще важная проблема: современные языки программирования никак не контролируют точность вычислений, разрядность переменных конечна и после какого то соотношения значений результат вычислений приобретает тип точности: «лаптем в небо».
Здесь описывается куда «девать» производительность.
На 57 странице описывается связь межпроцессорного обмена и вычислительной производительности.
В момент первого обращения, запрашиваем у контроллеров DSM участвующих в перемножении матриц создание оптимального адресного пространства (может быть различным для каждого из параллельно работающих процессоров).
Оптимальное значит что перемножаемые числа в этом пространстве будут находиться последовательно (как строки, так и столбцы).
Создаваемое адресное пространство полностью виртуально и совсем не обязательно последовательное. Можно даже сделать множество вариантов взаимного расположения данных, для различных алгоритмов обработки. Например можно расположить данные так что бы оптимально обработать с использованием векторных команд (как самый быстрый способ) и наиболее оптимально (без передачи лишних данных) уложить данные к кэш.
Далее запрос доступа (если подразумевается возможность изменения) и ожидание подтверждения доступа.
Далее происходит чтение необходимых данных (первое данное поступит через 50 нс), далее в свободную кэш страницу поступит нужное для полного заполнения страницы данные. Скорость зависит от производительности сети и скорости кэшрования памяти в узлах содержащих данные матрицы. Преобразование виртуального адреса в локальный физический и адрес производится контроллером DSM задействованного для вычислений процессора и DSM владельца оригинала данных.
В каком порядке производить перемноженожение это «личное дело программиста». Можно строить любые варианты соединений процессоров (пока хватает производительности сети).
Отдельного времени для инициализации заранее вычисленного маршрута не требуется, в момент первого обращения происходит построение канала (более подробно здесь habr.com/ru/post/512652).
Всем стоит взглянуть на идеи Intel PIUMA https://info.tigergraph.com/graph-ai-summit-spring-2021-hardware-considerations-for-faster-and-deeper-insights-from-your-large-scale-graph
Если посмотреть на обещания
производительности, предполагающие, что узел PIUMA превзойдет обычный вычислительный узел на один-два порядка
В моем варианте производительность на 3 порядка больше и задержки передачи очень близкие к времени распространения сигнала в кабелях связи.
Да и связность каждый с каждым в пределах ноды не радует (пусть даже и на одной печатной плате)
По поводу устройства физического интерфейса, думаю будущее за такими решениями: servernews.ru/1041594
Описание сильно урезанное потому что это пока что проект для DARPA HIVE :) Можно еще гуглом поискать, есть вот это https://arxiv.org/pdf/2010.06277.pdf и некоторые картинки из презентаций интересные находит.
Производительность в 10-100 раз, да, немного, но это для графовых задач +10 хопов и сейчас это будет очень существенно.
Я к тому что:
1) все в итоге приходят к shared memory и это будущее, а не спарк на moderate hardware как пишут некоторые комментаторы
2) Судя по их родмапу все должно быть уже готово
Распределенная общая память (DSM — Distributed Shared Memory)