Comments 228
Все плохо, а как исправить решения нет. Вывод статьи - давайте объединимся и что-нибудь придумаем. Жаль времени на ее прочтение
Решение озвучено в общем, и, согласен, конкретики мало.
Вы прекрасно понимаете, насколько эта тема провокационная, поэтому к обсуждению конкретики хочется быть более готовым, и мы этим занимаемся.
Есть вполне оформленные мысли, которые будут защищены в узком кругу оппонентов в изложены в следующих статьях, чтобы вам было уже не жаль времени читать.
Решение заключается в поиске талантливых и работоспособных профессиональных программистов, которые уже сами разберутся как сделать чип с количеством "вычислителей" как у трёх RTX 4090 и напишут версию CUDA которая будет доступна даже простым пользователям?
Инициативная группа будет предлагать спорные и смелые идеи, которые будем все вместе разбирать, критиковать и симулировать. В этот раз проектирование будет вестись с нуля - с полупроводниковых элементов.
А под каким флагом должна объединиться эта ваша инициативная группа? Какой основой она будет отличаться от других групп?
Идея большого количества ядер или наличие специальных ядер не нова совсем. Чем проектирование с нуля лучше использования существующих наработок? Ведь даже если всё сложится удачно проектирование с нуля займёт время гораздо большее чем та же NVIDIA утроит количество ядер в существующих решениях. И с "законом" Мура и без.
Коллега, мы объединимся под флагом несогласных и предложим участникам несколько гипотез для критики с точки зрения возможностей существующей элементной базы самого низкого уровня.
Как я упоминал уже, тут не про количество ядер история, а про иную архитектуру. Например, есть у мозга ядра? Нет вроде.
Например, есть у мозга ядра? Нет вроде.
Вообще-то есть. Как минимум два. https://ru.wikipedia.org/wiki/Каллозотомия
Но возможно, что и больше.
Это уже решенное решение. К сожалению, оно не подходит для современных процессов. Дело в том, что каждая отдельная задача/поток совершают операции последовательно. Это буквально то, что им нужно делать, иначе никак — сначала нужно вычислить А, и из него вычислить Б; не получится делать это параллельно.
Те задачи, которые хорошо считаются параллельно, и при этом им не хватает SIMD возможностей CPU, уже давно считаются на GPU.
GPU используется для игр и профессиональных или узких задач. Современные процессы, о которых здесь идет речь, также включают обычные персональные компьютеры, которые используются для серфинга в интернете и для подготовки документов. Прямо сейчас я насчитал 59 процессов только гугл-хрома, а общее количество процессов моего ноутбука гораздо больше, и они порождают потоки, которых вообще страшно представить сколько (посмотрел — 3300+). Всё это упирается в 4 физический ядра, которые должны быть достаточно мощными, чтобы в пике обработать все потоки без торможения. Вот на этом поле хотелось бы поработать — дешево выполнять всю эту работу.
Эти процессы близки друг к другу, возможно даже используют какие-то общие переменные, да и выполняют они не что-то сложное, что имеет смысл разносить на разные ядра. Потому что разные ядра в связанных процессах сразу поднимают вопрос синхронизации памяти.
Вообще, кмк, если уж вы про эту проблему имели ввиду, то лучшим решением являются гетерогенные процессоры, где на "маленькие" ядра сгружается всякая бытовуха, и из довольно много (в новых интелах, вроде, 16 маленьких против 8 больших), а большие ядра работают редко но метко, так сказать - считают всякие фотошопы, физические модели и игры.
И даже так слишком увеличивать количество ядер неэффективно, так как у каждого ядра свой L1 кэш, а точный профиль даже простых задач нам до конца неизвестен.
Исследование идет не по пути увеличения количества ядер, а оно про распределение вычислений между агентами, которые ядром-то грех назвать. В статье использовано фото 4-хбитного процессора, а наши ядра будут в разы проще, если не на порядки.
А кто будет раздавать задачи агентам и по какому критерию?
Как понять, нужны ли задаче FPU блоки, или предсказание переходов, например?
Кроме того, какой объем кэша должен быть у такого агента, будет ли он одинаковым у всех агентов или разным? Можно попробовать переложить задачу такого распределения на систему и ИИ какой-нибудь, однако, как мне кажется, такой подход только наоборот увеличит количество транзисторов у CPU, при этом с потерей в производительности. В целом, мне видится, что такая архитектура очень сильно упирается в скорость памяти и шин данных, а их ограничивает не техпроцесс, а физика длинных линий и скорость света.
К тому же стоит рассматривать верные сценарии использования - да, для браузера и офиса сойдёт и старенький i7-4xxx, или даже i5 (а мне его даже для разработки хватает), но как бы и в новых сериях есть аналоги. Какой-нибудь pentium последних поколений или ryzen3, особенно всяких U и HS серий (такие ставятся, например, в мини ПК). Однако обычно люди не запускают браузер и офис одновременно с играми. Почему некоторые люди для офиса покупают игровые процессоры - уже другой вопрос.
Прикладная задача требует фиксированное количество вычислений, если рассматривать её в идеальном мире. Мир ИТ не идеален, и задача сталкивается с прослойкой ОС, фреймворка и всяких библиотек, прежде чем будет выполнена посредством кода, который написал программист.
Все это делается во благо программиста, потому что мы с вами прямо заинтересованное лицо, финансово.
При этом конечное количество вычислений, которые решат вашу задачу, посильно даже процессору из 80-х годов. Он выполнит её за 0.2 секунды, а не за 0.2 микросекунды, но разницу вы на глаз никогда не заметите.
Забавный момент, однако мы замечаем даже разницу между 0.2 и 0.4 мкс. Почему? Потому что таких задач много, и суммарно они дают очень хорошо видимые тормоза.
Кроме того, а про какие задачи речь? Калькулятор обычный? Наверно, конечно, если перейти обратно на дизайн сайтов эпохи web1.0, то их грузить будет гораздо проще, но это такое себе решение. В целом, современные браузеры представляют из себя структуру сложности уровня ядра ОС.
Современные задачи требуют больших мощностей, большой производительности на такт и высоких частот. Из-за большого объёма данных, которые надо обрабатывать в реальном времени. Самая распространенная задача такого рода - игры. Благодаря играм, высокопроизводительные процы являются распространенными, а соответственно дешёвыми, и я как радиоинженер могу позволить себе систему, которая считает модели за пару часов, а не за пару недель, и стоила она мне не несколько миллионов, а пару сотен тысяч.
К сожалению, плохо оптимизированный софт является прямым следствием дешёвого высокопроизводительного железа. Однако тут не новая архитектура нужна, а... Ну не знаю, ГОСТ какой-нибудь (не надо меня проклинать на годы диареи, пожалуйста, это просто шутка). И предлагаемая вами архитектура наоборот ухудшит ситуацию, так как писать код с высоким уровнем параллелизма тяжело, намного тяжелее эффективных околооднопоточных приложений - современная индустрия не простит вам кратного увеличения стоимости и(ли) времени разработки.
К сожалению, плохо оптимизированный софт является прямым следствием дешёвого высокопроизводительного железа. Однако тут не новая архитектура нужна, а... Ну не знаю, ГОСТ какой-нибудь
Если не давать пользователю писать код, то пролема решится сама собой. У нас в Интеграле это всё спрятано под капотом - вся рутинная работа делается автоматически, все стандартные действия написаны, и код собирается из готовых кусочков.
Что значит "не давать". У меня друг Вася пишет по вечерам игру мечты, и собирается опубликовать её в Стиме. И как вы ему собираетесь "не давать"?
и код собирается из готовых кусочков.
Тут ничего не меняется, программирование переходит на уровень выше, на уровень сборки из кусочков. Из оптимальных кусочков несложно создать очень неоптимальное приложение.
В нашем случае мы специально выделили 3 или 4 ситуации, когда, например, запрос к базе из конструктора может быть неоптимален, и это чинится в пару кликов, например, меняется последовательность JOIN-ов таблиц.
О чём я и говорю, что разработка нужна под присмотром специалиста, который поймёт, что в этом месте 200 мс на запрос это многовато, и надо поменять порядок джойнов. Обычный же пользователь скажет "ну, 200 мс это мне подходит". И таких мест с микро-тормозами на 200 мс наделает 500 штук, после чего всё приложение проще переписать заново, чем вылавливать всех этих блох.
В книге clr via c# в главе 26 доступно рассказывается про развитие многопроцессорных систем и как приложения начали использовать их преимущества с помощью потоков.
Также приложения могут выделять несколько потоков заранее для большей отзывчивости, но от сюда вытекает что заранее созданные потоки могут никак не использоваться в течении жизни приложения.
Да убейся ты со своими идеями. Это т. н. послойное программирование, где программист буквально вбивает всё, вплоть до порядка занесения значений в регистры, одновременно уточняя, что будет читаться минуя проц, в память, и что в этот момент будет передаваться на видюху (и что там будет считаться).
Да, даже на современной технике ты получишь минимум увеличение скорости на порядок. Скорее всего, на два, в некоторых случаях три порядка. Но какой ценой? Писать программу сложностью уровня "hello world" в течении двух недель? И при этом без малейшего права на ошибку? Ну, потому что где ты ошибся, ты вряд ли найдешь...
Может, чем так мучить прогеров, пересадить нас хотя б на ассемблер? Ну да, рекорды скорости будут поменьше, зато хотя бы при твоей жизни возможно сделают аналог десятой винды.)))
Правильная мысль.
На деле не надо всей этой чуши. Тут проблема другая.
Текущая парадигма разработки примерно такова - ты работаешь на своём свое абстракции, а под капотом что-то выполняет свои слои. Т.е. твоя команда раскладывается на что-то другое, пока дойдёт до исполнения на процессоре. Следовательно проблематика конкретно разработчиков в качестве их кода на своём уровне и не более того, а остальное ногами и ушами торчит из количество слоёв абстракций и из качества разного рода трансляторов, итнерпритаторов, компиляторов, рантаймов и прочего. И скажем честно, повышение именно качества слоёв дало бы куда больший прирост, чем недельное вылизывание кода.
Прямо сейчас я насчитал 59 процессов только гугл-хрома, а общее количество процессов моего ноутбука гораздо больше, и они порождают потоки, которых вообще страшно представить сколько (посмотрел — 3300+). Всё это упирается в 4 физический ядра
Там такая специфика, что все эти процессы и потоки не работают одновременно, а почти всё время спят. Но когда просыпаются, хотят выполниться очень быстро на очень мощном процессоре. Если вы просто переложите эти потоки на процессор 4004, без существенного изменения их кода, простейшие задачи браузера будут выполняться за годы, а не за секунды.
Для Вашего же понимания: где в списке ТОП500 будет Ваша реализация т.е. согласно тесту линпак, а не иными второстепенными тестами, проще, каков будет максимальный порядок решаемой СЛАУ!
Если твоя цель была создать трафик на свою статью, у тебя получилось, тролина.
А если серьёзно, все эти думы о высоком это не понимание реальной позиции вещей. Если коротко, у тебя есть два варика всё исправить, организационный и архитектурный.
С первым всё просто, потоков много и они требуют разное количество ресурсов, в идеале железка должна содержать в себе несколько ядер разной микроархитектуры заточенные под разные задачи, условно как это сейчас делают intel, но можно и усложнить, добавив ещё более специализированные ядра и заточить логику работы ОС под эту фичу. (Даже для прерываний отдельные ядра делать, в идеале)
Второе это архитектура. Вот эти все риски ириски киски и прочие идеи = мусор. Архитектура должна быть максимально ёмкой на команду и при этом легко декодироваться. Сделать команды слишком сложными = нагрузка на декодер = ботлнек для команд на такт, сделать команды слишком простые = нагрузка на память. В идеале надо найти что-то по середине.
Всё остальное это специальные архитектуры под какие-то конкретные задачи. Даже GPU нельзя считать хорошим примером параллельных вычислений, ведь есть матричные ускорители которые дают на пару порядков больше flops, которые нынче NPU-хами стали.
Куда ты копаешь, юнец? Где там революцию устраивать собрался? Чо по Легаси, куда все эти тонны либ девать собрался?
Тема настолько провокационная, что, отойдя от чисто технических сторон дела, вам просто никто не даст запустить ее на поток в случае успеха.
Надо сделать две вещи:
Не гнаться за конвейерами. Они увеличивают ложность и стоимость процессоров на порядки, а производительность лишь в разы.
Декомпозировать библиотеки. Чтобы калькулятор не весил два гига.
А конкретика есть или только громкими словами решили фон Неймана победить?
10 лет примерно мы ходим вокруг этой идеи, и теперь собираемся создать конкретику. Без громких слов и с огромным уважением к фон-Нейману и коллегам с их наработками.
Кстати, планировал обратиться к авторам некоторых комментариев в личку с предложением обсудить некоторые мысли. И буду рад любым обращениям по теме.
Спешите видеть, ОП изобретает GPU
Про GPU был абзац в статье, как пример того, куда эта инициатива двигаться точно не будет, хотя отдаленная аналогия напрашивается. Убрали по итогам обсуждения с ранними рецензентами.
Возможно, автор переизобретает "Мультиклет"
О, нет, нет.
А почему нет? У меня прямо дежа вю. В чём принципиальное отличие вашей идеи?
В поле вычислителей не будет фиксированных АЛУ, шин и коммутаторов, если коротко.
Так не бывает. Либо у вас есть ALU и коммутаторы, либо нет.
То что описано в статье напоминает Kilocore (Rapport Inc X IBM) с массивом 8-битных вычислительных элементов.
https://en.wikipedia.org/wiki/Kilocore
Они очень хвастались микробенчмарками
Specifically, the KC256 runs a well-known digital security decryption algorithm 4 times faster than a 1.8 GHz Pentium® while consuming less than 150 mW, compared to 75 W for the Pentium, for a 500x power/performance advantage
Но даже наличие тяжеловеса IBM не помогло хоть сколько запустить эту тему.
Если железо сложно программировать - это тупик.
Например как в случае с современным Эльбрус - предсказание условных переходов реализовано в backend компилятора, а не в процессоре (x86_64).
Программы для Эльбрус совершенно ничем не отличаются от программ для х86. Сабж идеологически ближе к fpga, чем к обычным процессорам.
К тому же в современных Эльбрусах есть аппаратный предсказатель ветвлений.
Kilocore (Rapport Inc X IBM)
О, отлично, спасибо, очень интересно!
Даже наличие тяжеловеса IBM не помогло хоть сколько запустить эту тему.
Бывает. Тут вот парни потратили миллионы долларов и годы времени на таблицу из 240+ колонок с 40+ индексами, а мы эту же задачу решили за 3 месяца работы и 1170 строк кода, уложившись в 5 колонок и 3 индекса.
Благодарю. Много нового для себя почерпнул.
Т.е. всё упирается в необходимость программистам обязательно учитывать особенности архитектуру процессора в своих алгоритмах? А есть такая необходимость потому, что невозможно силами компилятора реструктурировать под иную архитектуру?
В принципе, если подумать, действительно не очевидно как сохранить задуманное разработчиком поведение, но переделать на многопоточный код, в котором почти каждая последующая конструкция использует результат вычислений предыдущей...
Наверное эффект будет как в ПК-играх начала 00-х. Когда запускаешь на современном многоядерном процессоре и удивляешься, что игра использует 2 ядра, а остальные не задействованы.
В поле вычислителей не будет фиксированных АЛУ, шин и коммутаторов, если коротко
Ну так, создатели Мултиклета тоже начинали за всё хорошее. Но, они всё же дошли до продукта в железе, наверняка им пришлось зарезать 90% своих идей, чтобы вписаться в реальность.
Я, например, не представляю, как можно сделать без шин и коммутаторв
Внутри кубика множество уровней, по которым перемещаются исполнители и передают задачи, причем перемещаются по желанию, используя общие циклы сдвига
Они что, ножками будут бегать? Если бы мне ставили такую задачу, мне пришлось бы придумывать, как кубики подключать к шине. Даже если сделать связи каждый-с-каждым, как без коммутаторов понять, какая сейчас связь активна.
Насчёт отсутствия "фиксированных АЛУ". Встретившись с реальностью, вы передумаете. Потому что, современный блок 32-битного умножения это шедевр конструкторской мысли, переполненный всевозможными инженерными хитростями, и заменив его готовый на гибкое решение, которое может быть сконфигурировано на всё-что-угодно, вы непременно проиграете в производительности.
Они что, ножками будут бегать?
Вполне удачное сравнение
современный блок 32-битного умножения это шедевр конструкторской мысли, переполненный всевозможными инженерными хитростями, и заменив его готовый на гибкое решение, которое может быть сконфигурировано на всё-что-угодно, вы непременно проиграете в производительности.
Да, проиграем, возможно в 100 или 1000 раз. Это понятно и принято
То есть задачи, которые не смогут распараллелиться, проиграют в 100 или 1000 раз.
Исполнители задач будут слабее в 100-1000 раз, но их будет в десятки тысяч больше и они будут на порядок дешевле.
Процессор универсален и за эту универсальность мы платим, и платим всё больше, получая непропорциональное увеличение производительности.
Эта статья о новой универсальности, за которую тоже придется платить, но в этот раз мы хотим преодолеть предел, к которому вплотную подошли разработчики -- вернуть возможность масштабирования вычислительной мощности.
Непонятно, на какую нишу вы нацеливаетесь.
В HPC, где работают лучшие умы, и там всё вылизано в оптимизациях, всё считается на GPU а то и специализированных ASIC-ах, вам ловить нечего с вашим 100X тормозным умножением.
В классическом десктопе тоже ловить нечего. Машинная автоматизация не сделает автоматом параллельность x100-x1000, а ручная стоит очень дорого (как мне объяснить работодателю, что весь день занимался распараллеливанием накидывания кнопок на тулбар, чтобы форма открывалась 1 мс, а не 5 мс), да и нет таких задач, чтобы параллелить x100.
В бизнес-приложениях узкое место доступ к памяти и хранилищам. База 10 ТБ, которая лежит на RAID или даже в DRAM, не сможет вдруг обеспечить чтение x1000 из хранилища, чтобы все исполнители были заняты.
Пока необходимо проработать концепцию и предложить первое масштабируемое решение.
При нишу пока говорить рано, но далее, как водится, первым клиентом будет широкий потребитель, который получит черный ящик, который стоит копейки, но решает свою задачу и можно делать бэкапы. Так мы продаем сейчас другой, уже готовый, продукт, и это работает.
Какую конкретно задачу, офисной машинки? Я сильно сомневаюсь что вы осилите современный браузер, а это значит, вашу коробочку надо ставить рядом с классическим ПК. И чтобы что? Крутить на ней аналог клиента 1с? Но вы же доказали, что на x64 можете написать быстрое десктопное приложение, без новой архитектуры. Тогда зачем новая коробочка?
Аналог не клиента 1С, а сервера, но повторюсь, об этом пока рано. Даже решенную проблему с унифицированным хранением данных мы пока не продаём массово, а коробочка -- это следующее поколение.
1с покупают не потому что он быстрый или дешёвый (он не быстрый и не дешёвый), а потому что поддерживается. Вам интересно вместо копания в архитектурах увязнуть в нормативных актах, учётных политиках и бухгалтерских регистрах?
В 1С поддерживаются только определенные законом формы и правила, в всё, что клиент нагородит себе, часто безжалостно ломается обновлениями.
Мы делаем дополнения к 1С, типа простых систем учета и планирования, каталогов, трекеров задач, табелей, биллинга, аналитики. В простом случае такие вещи можно сделать за 2 вечера, и клиент сам их может поддерживать. На 1С это будет мега-проект и куча ограничений.
ОП изобретёт ПЛИСы? :)
Да, динамически конфигурируемые
-ОП изобретёт ПЛИСы? :)
-Да, динамически конфигурируемые
Как вот здесь? :)
Функционально похоже, но архитектурно и физически будет выполнено по-другому. Конфигурироваться эти фрагменты будут автономно и самостоятельно, они сами будут принимать решение сообразно задаче, а не получать извне готовую конфигурацию.
Конфигурироваться эти фрагменты будут автономно и самостоятельно, они сами будут принимать решение сообразно задаче, а не получать извне готовую конфигурацию.
Как вот здесь? :)
Так это почти то же, что в прошлой вашей ссылке.
Нет, концептуально всё иначе.
Но вы не можете объяснить, чем именно иначе? )
Я пытался объяснить это в статье: это будет единое поле самых простых исполнителей, даже, я бы сказал, поле кирпичиков, из которых эти исполнители строятся.
Рабочий фрагмент, который делает полезную работу, -- это комбинация кирпичиков, создающая простых исполнителей. Исполнитель работает так:
1. Получает задачу
2. Конфигурируется по очень простым правилам для её выполнения, задействуя соседние поля при необходимости,
3. Выполняет задачу
4. Передает результат заказчику задачи
5. Если пришла новая задача, а исполнитель занят, он передаёт её далее, причем это происходит прозрачно для исполнителя, он не прерывает работу
Пока состав поля и его исполнителей я объяснить не могу, потому что это не готово. Но вы обязательно узнаете о прогрессе, как он будет.
Ничего из описанного не решает проблему фон нейманновского бутылочного горлышка. Более того, я полагаю, что такая конструкция ее только усугубит.
Пока всё выглядит как
Я нашёл поистине чудесное решение, но поля этого форума слишком узки для него.
Подход следует поменять радикально, иначе -- да, стандартным путем идти шансов нет.
Проблемы у современных проводников очень сильно завязанны на взаимодействии элементарных частиц и квантовых эффектах которые пока учёные не до конца понимают и темболее полноценно ими манипулировать не могут. Поэтому всё взаимодействия идут всеми силами в основном на молекулярном уровне и частично на атомном. И то там много пробелов в понимании и умении манипулировать. Крайне сильно не хватает фундаментальных знаний и их прикладной реализации которую можно применить в массовом производстве.
Вот представьте сделать 96 ядерник с потреблением как сейчас 500 вт, только с потреблением 0.5 вт а то и 0.1 вт если оптимизовать все структуры чипов. И тогда можно было бы как HBM 12+ слоёв этих процессоров сделать или вообще как флеш память сотни слоёв таких процессоров наслаивать в будущем, уже сейчас чипы позволили в последнии 10 лет совершить революцию в ИИ, а что будет если увеличить вычислительные мощности в 1000 раз от текущих? Или выше.
FPGA использует конкретные механизмы, конкретные полупроводниковые решения и стандартные коммутации. Мы же применим свои приемы коммутации и оркестрирования, не ограничиваясь существующими решениями в этой области.
Наше решение не будет основано на переконифгурировании FPGA хитрым образом, хотя первый прототип вполне себе может быть собран на существующей элементной базе с гигантскими накладными расходами, как это успешно делает наша квинтетная модель данных в обычной реляционной СУБД.
FPGA использует конкретные механизмы
Это понятно что можно найти более эффективное решение чем которое используется сейчас.
Но у конечных устройств будет частота, будут шины данных которые тоже будут иметь частоту, а следовательно будут идти по ним сигналы и они будут нагреваться и если говорить про современные материалы и решения на которых может быть построенная такая система то там много ограничений особенно в плане токов утечек, деградации материала, тонкие слоих в несколько атомов которые деградируют как например в флеш-памяти и тд. Ещё есть оперативная память у неё тоже есть шина данных, объём частота которые тоже будут ограничивать вычислительный центр, не говоря про ссд или жёсткие диски которые тоже имеют свои шины и скорость отклика.
Так что на пути стоит не только экономические вопросы и совместимость особенно когда идёт речь о таких маштабных изменениях. А куда больше проблемой выступает в первую очередь материаловедение и практическая реализация. Можете ещё почитать про кремний и почему он так плотно занял нишу в полупроводниках, там множество факторов и ограничений, а другие материалы более дорогие, сложные , недолговечные, сложные.
Слишком много переменных чтоб понять всё не хватит человеческой жизни чтоб во всём этом разобраться, надо искать пути продления жизни. Потому что просто осознать весь маштаб надо не только архитектуры и структуры передачи и обработки данных понимать, но ещё и физику, химию. Слишком всего мало у нас (человечества(учёных,инженеров) знаний, и практических методов и инструментов реализации таких сложных систем. Это если ещё отбросить экономику, и организацию производства.
Программисты уже радостно потирают руки - сколько работы у них будет с массовым внедрением принципиально новых архитектур.
Да, всё даже ещё более серьезно. Программировать тоже придется принципиально иначе.
Либо сделать более сложный backend для популярных компиляторов, которые смогут модифицировать структуру кода под новую архитектуру таким образом, чтобы логика поведения программы осталась ожидаемой для программиста. Например как в случае с современным Эльбрус - предсказание условных переходов реализовано в backend компилятора, а не в процессоре (x86_64).
В статье есть ссылка про прикладное программирование. Это часть концепции, и она уже реализована в обычном железе и софте, хотя 15 лет назад нам говорили, что это не заработает и помрет на 1-2 млн записей в базе.
Логику поведения программы мы представляем на самом высоком уровне, чтобы было понятно даже пользователю с программистским складом ума, а не программисту с глубоким бэкграундом.
Ссылку из статьи пришлось убрать, но вот она:
https://habr.com/ru/companies/neoflex/articles/433058/
Получилсь архитектура эффективная для узкого круга задач. Сколько SQL-запросов в секунду сможет обрабатывать Web сервер на такой архитектуре? На сколько быстрее обработается рейтрейсинг на 3 миллиарда треуголников? Будет ли каскад ассоциативных кешей для доступа к RAM?
Скорость выполнения отдельных запросов, очевидно, уменьшится. В начале нулевых все работали на сотнях мегагерц, но отклик сервера был намного быстрее, чем можно было моргнуть глазом. То есть, в прикладном смысле скорость обслуживания пользователей заметно не изменится совсем, хотя для их выполнения понадобится значительно больше тактов псевдо-процессора. На порядки больше.
Не обязательно, что в будущем производительность систем будет измеряться по таким же критериям, как и сейчас: рейтрейсинг 3 миллиардов треугольников, например. Мне представляется, что мерой измерения производительности ИИ систем будет количество когнитивных операций в секунду. Под когнитивной операцией я подразумеваю следующее: если человек задал запрос в систему на естественном языке, в системе запускается процесс моделирования ситуации, соответствующей запросу. Например, если вопрос касается физического мира - запускается аналог физического движка. К примеру, вопрос такой может быть: что будет если кинуть камень в окно? Или что будет если кинуть в окно пакет с орехами? Или еще что-то. В разных случаях результат зависит от условий: скорости, того, что вы кидайте, стекла, из которого состоит окно. Я сейчас предполагаю, что не существует базы данных, включающей все возможные варианты, чтобы условный GPT просто выдал вам то, на чем он обучался. Здесь нужно каждую отдельную ситуацию именно моделировать: то есть, реализовывать аналог воображения и мышления у человека. И вот такие когнитивные операции могут требовать очень много вычислительных ресурсов. И, вероятно, может быть создана архитектура, специально адаптированная под выполнение этих когнитивных операций, которая будет это делать гораздо эффективнее стандартных архитектур. А рейтрейсинг 3 миллиардов треугольников пускай продолжают делать видеокарты.
Про рендеринг согласен, видеокарты делают своё дело очень хорошо.
Мы же смотрим на операционную систему и прикладные программы, которые выполняют простые пользовательские задачи. Как-то так получилось, что пользователь сильно переплачивает за выполнение простейших задач: деньгами, временем, природой. Начиная от драгоценных минут ожидания обновления ОС и заканчивая выделением тепла 8-ю ядрами, молотящими 2,5 млрд тактов в секунду.
Сколько SQL-запросов в секунду сможет обрабатывать Web сервер на такой
архитектуре? На сколько быстрее обработается рейтрейсинг на 3 миллиарда
треуголников?
давайте я вам отвечу! На 4к экране примерно 10 миллионов пикселей. Значит 10 миллионов ядров очень даже пригодятся для рейтрейсинга на 3 миллианрда треугольников. А с учётом двойном буфферизации - 20 миллионов ядер! прекрасный пример же!
------------
сколько sql запросов обрабатывать? Ну смотрите, в таблице - 1 миллиард записей. Прилетает запрос, применяем к каждой из записей фильтр = 1 миллиард ядер для простейшего процессинга нужно. Потом результат объядиняем рекурсивно. на втором этапе рекурсии и объединения по простой аггрегирующей функции (сумма например, или счётчик) - 500 миллионов ядер, на третьем - 250 млн ядер и тд.
Хорошие примеры привели! ещё есть?
А ядра вычислительные? Или каждое каждое ядро имеет пару Гигабайт сверх быстрой памяти, не расшареной с другими ядрами? Я не зря упомянул каскад ассоциативных кешей который на текущей архитектуре занимает основную площадь кристалла процессора.
Первый пример с 4к экраном. Данные общие, пара гигибайт сверх-быстрой памяти на ВСЕ ядра read-only общая, а writable информация (результат вычисления) - 1 пиксель. Норм получилось!
второй пример с sql запросом. В таблице миллиард записей, каждая запись - пару килобайт. И каждому ядру кэш пара килобайт, как раз запись и промежуточные вычисления поместятся. Если нужно запись осуществить в каждую ячейку - ну так записи все независимые, тоже норм ложится в новух архитектуру. Потом можно разом всё выгручить. Вот если сложные аггрегации есть - тогда да, нужно какую-то рекурсивно-каскадную модель вычисления строить, вот это да, интересно как сделать чтобы не тормозило. Но в целом то, если ядер миллион будет вычислительных - уж памяти гигабайт общей и по килобайту каждому ядру персональной можно будет засунуть на пластину.
Это только в фантазиях хорошо работает. Первая же проблема - поступил запрос на поиск ячеек по какому-то критерию. Как все ядра одновременно узнают об этом запросе? Через "пару гигибайт сверх-быстрой памяти"? Она просто крякнет от такой нагрузки на чтение.
Как ядра, нашедшие у себя результат, сообщат об этом владельцу запроса? Да так, чтобы не мешая друг другу. Должен быть сложный протокол согласования, кто с кем и когда говорит, посложнее, чем само примитивное ядро.
В-общем, я не думаю, что кто-то вытянет эту идею до реализации в железе, умрёт оно, поранившись о реальность.
Как я понимаю, это идея создания SISD (single instruction single data) процессора максимально простым и сверх многоядерным. Т.е. предлагаете core i9 с его 12 млрд. транзисторов заменить на кучу atom-ов с таким же количеством транзисторов под одной крышкой.
И упрощение в сторону RISC, чтоб инструкции были одной длины и можно было убрать блок декодирования.
И убрать блок перестановки инструкций. Он только место занимает и нагрев создаёт. Ещё программисты в край обленились, не хотят писать качественный код.
Да, только условный atom должен быть ультра-RISC и как-бы плавать среди своих собратьев в этом вычислительном поле.
С большим количеством ядер, APIC и шина доступа к периферии станут узким местом. В какой-то момент прирост производительности станет менее заметным. А распределение нагрузки за счёт "светофоров" создаст большую пробку (traffic jam), в которой вместо полезной работы будет выполнятся распределение задач за счёт всё того же единственного APIC в системе.
Я пока писал это, обдумал разделение ЦПУ на блоки по прерываниям. Когда поступает прерывание от таймера на переключение задачи, останавливаются не все ядра, а только часть из них, потом другая, потом третья. Следовательно для других блоков это прерывание должно быть замаскировано. И было бы неплохо сделать выделение квантов времени на блок. Например если блок получает 4 кванта времени, то следующие 3 прерывания по таймеру будут замаскированы.
Такой расклад распределит нагрузку APIC во времени, но создаст задержки для периферии и увеличит input lag, что критично в игровых ПК.
Решение полученной проблемы - одни блоки будут обрабатывать исключительно систему и драйверы, из-за чего должны будут реагировать на каждое срабатывание таймера.
В этой идее определённо что-то есть.
Прочитал Синклер асм и вздрогнул, потому что начинал со спектрумовских бейсика и ассемблера.
Представьте себе, что шина у вас – это некий кубик со множеством входов на каждой грани, куда можно подключиться и закачивать задачи. Всю периферию вы подключаете в любой свободный вход, и она там обслуживается. Всё асинхронно, но для простоты у всего одна частота и взаимодействие определяется контрактом при подключении.
Внутри кубика множество уровней, по которым перемещаются исполнители и передают задачи, причем перемещаются по желанию, используя общие циклы сдвига.
Вот примерно так мы это видим в самом первом грубом приближении.
Вот здесь не одобряю.
Шина с куб это уже не упрощение, а усложнение. Множество контактов напоминает HBM память, которая толком не прижилась за более чем 10 лет. Всё из-за большого процента брака и отвалов.
Если исполнитель выбирает сам себе задачу - ему нужно самому для себя выполнять сдвиг, а это время. Если исполнители это делают "по желанию" тогда присутствует фактор рандома и может появиться задача, которая будет выполнена 2 раза подряд, а может и не выполниться вовсе. Такой вариант не подходит игровым ПК и системам точно вычисления зависящим от времени (например нужды ВПК).
Имхо. Должен быть порядок и кто-то отвечающий за него (Возврат к APIC).
Как говорится "За что отвечают двое - за то не отвечает никто".
Вроде я не говорил о разделении ответственности за задачу, и выбор задачи не привязан к перемещению исполнителя, которое нужно для ротации ресурсов - освободить место для следующего исполнителя. Но это пока только наброски.
Множество контактов напоминает HBM память, которая толком не прижилась за более чем 10 лет. Всё из-за большого процента брака и отвалов.
Наверно поэтому её сейчас постоянно ставят в топовые роутеры и GPU, которые на наших глазах творят революцию в ИИ.
дешёвые свичи/роутеры для соединения между N портами прогоняют всё через центральный вычислитель и если вдруг нагрузить не 2 порта из 20 нагрузкой в гигабит, а хотя бы 5 портов - упс, всё начинает лагать.
Дорогие свичи роутеры умеют прямые соединения между 2 портами обрабатывать независимо и все 20 портов могут работать на максимальной поддерживаемой скорости в гигабит, что даёт 20 Гбит суммарную пропусную способность (In + Out если сложить), или намного больше если порты 2.5/10Гбит, или есть 40 штук вместо 20.
А если влепить х*** схемотехнику наотъ***сь, то 2 пользователя пересылающие друг друг файл заставят всех страдать.
Интересно, конечно, а как синхронизировать работу всех этих десятков тысяч простых исполнителей. А к ним же наверняка и кэш разноуровневый прикрутить захочется и другие вкусности. Мне кажется, что инжинерам такое в страшных снах не приснится.
а о чем эта статья?.. да ни о чем! изрядное количество наивной критики сопровождается не менее наивной "идеей", которую автор до конца и не понял. вся идея существует в виде одного предложения. типа раз мало - плохо, сделаем много и будет хорошо.
вообще-то увеличение производительности методом горизонтального масштабирования - этой идее столько же лет, сколько идее однопоточного вычислителя. еще в первой половине 20 века, за неимением компьютеров, сидели считальщицы и крутили ручки арифмометров, рассчитывая то, что им давали инженеры.
так что, спасибо за идею.
И вам спасибо за экспресс-анализ и критику!
Без наивных, как вы говорите, идей прогресса и не было бы. Да, сейчас тут мне пошутят, что я проспал 1 апреля и откроют глаза. Да, мы можем и не преуспеть. Тем не менее, команду мы собираем и результат будет, пусть даже и в виде опровержения возможности задумки.
Но я надеюсь на лучшее.
Ещё раз корректирую: очень будет похоже на японский проект 80г. суперкомпьютеров 5 поколения - ещё раз вспомните его цели и итоги + с законом Амдала, а то нынешнее поколение программистом и ИТ- спецов знает только давно здохший закон Мура!
Надо будет ещё раз почитать про тот японский компьютер. Читал лет 10 назад.
это многомерная структура вычислительного поля с динамическим выделением вычислительных участков и передачей задач и результатов
В статье описано именно такое: единое поле, в котором конфигурируется то, что нужно, из универсальных элементов. Они и шина, и АЛУ нужной разрядности, и роутер, и память, в зависимости от ситуации.
Как бы это необычно ни выглядело.
Никто из уважаемых минусаторов не воспринимает эту концепцию всерьёз, предлагая различные иные существующие решения и инициативы.
Узким местом до сих пор являются не ядра, а шина памяти. И это следствие того, что для процессоров, динамической памяти, и флэш-памяти используются существенно разные техпроцессы, что не позволяет размещать их на одном кристалле так же эффективно как на разных кристаллах, и приводит к появлению этого узкого места как соединения по крайней мере между кристаллами. Кроме того, задействовать все транзисторы одновременно с той же эффективностью, с которой сейчас задействована их малая часть, мешает прямая зависимость тепловыделения от числа реально задействованных в работе транзисторов. Снижение рабочей частоты на 30% не решает эту проблему. В принципе, переход к вычислениям с высокой степенью параллелизма может дать большой эффект не только на простых задачах, для которых он уже произошел в видеокартах, но и на сложных. И он постепенно происходит с появлением центральных процессоров с сотнями ядер. Но с программной точки зрения это сложно.
В первой фазе это видится как драматическое снижение производительности отдельных вычислительных процессов при увеличении количества вычислителей. Одна из проблем, которые нужно решить, это как раз сделать вычислители автономными, имеющими свою память, пусть даже и ограниченную несколькими квази-регистрами.
А подумайье, автор, под другим углом: если в один квант времени работает лишь ничтожно малая часть процессора в нынешних условиях, но имея при этом уже космические тдп в сотни ватт, то что будет с вашей "идеальной" конструкцией, где работают все ядра на полную мощность? Места на кристалле не жалко, большой и большой, а реальная проблема так и осталась за кадром, да ещё и возросла многократно по предлагаемой вами модели)
Если понизить частоту работы схемы, то нынешние технологии позволят снимать достаточно вычислительной мощности с единицы вычислительной площади. Сейчас все эти ватты рассчитаны близко к пределу разрушения, чтобы выиграть проценты мощности, а у нас такой задачи не стоит и мы планируем выиграть не скоростью.
А потом поймёте, что ваши ядра могут решать однотипные задачи и придумаете ГПУ. Потом добавите возможность читать разные инструкции огромными блоками и исполнять их на каждом таком ядре и получите vliw. Против последнего ничего не имею, главное, суметь сделать компилятор)
В любом случае, это интересная задача, хотя пока нет смысла заглядывать так далеко.
Первым результатом будет принципиальная схема встраивания нано-процессора в вычислительное пространство. Он может быть 4- или даже 2-хбитным, это не так важно, как подтверждение концепции конфигурируемого поля вычислителей.
Короче я понял, вы хотите сделать vliw). Советую почитать, про то, как это было сделано в том же итаниуме и других аналогах и их набор инструкций. Не согласен с тем, что суперскалярные процы лучше. Проспойлерю: они погибли из-за жадности одной небезызвестной компании. У них был большой потенциал, но деньги вливали туда, что приносило доход, а что приносило доход, туда и вливали деньги... И после пары десятков лет стало очевидно, что поддерживать догоняющую минорную архитектуру стало нецелесообразно, а жаль...
Эти парни хотели оптимизацию использования железа, когда у них уже было железо и оно частенько простаивало. Мы ещё не дошли до такой развитой стадии, кроме того, я бы желал снять думы о локальной параллелизации с программиста, сделав всю черновую работу за него. Благо делается ведь это достаточно тривиально.
Да, есть огромная проблема, когда для расчета следующих значений нужны предыдущие. За один такт пытаться это решать бессмысленно: низкая тактовая частота и на конвейер не поставить, без хорошего предсказателя ветвлений и приходу к нынешней суперскалярности. По причине зависимости от ещё не вычисленных значений, это дело не выполнить параллельно. ньюансов много, но если чувствуете в себе силы...
Это рекуррентные вычисления, и из тысяч потоков на вашем компьютере их использует, наверное, каждый. Даже в этом случае количество таких потоков в сотни-тысячи раз меньше числа ядер вашего процессора.
Это при условии всех тех сервисов, что наспавнила ОСь, где надо количество, а не качество. Пользовательское приложение, которое он запустил и видит перед собой, должно выполняться на самом "жирном" и быстром ядре. Распараллелить код, логика которого преимущественно последовательна, исключительно железом вряд ли выйдет без "особой" кодовой организации или помощи компилятору
У ОС свое видение приоритетов, а у приложения -- своё. В итоге реклама в боковом меню браузера у меня заливается соловьём в HD, а моя несчастная табличка из 30 строк грузится 20 секунд. Бывало у вас такое? Да, это про сеть и браузер, не про процессор.
Да, но раз с нашими нынешними процессорами табличка из 30 строк грузится 20 секунд, то дело не в процессоре, а в коде) я к тому, что, есть большая вероятность, что вам придется комплексно решать вопрос не только архитектурой, но и бекендом к шлангу или гцц
del
Бэкенд в этой парадигме мы уже сделали, его можно посмотреть:
https://www.youtube.com/watch?v=l0eg2xuC9Ks
и пощупать живьем:
https://ideav.online/sber
и даже творить самому:
https://ideav.online/ru
Выглядит неплохо, но что насчёт кода? На чем это программировать? И, для чистоты эксперимента, посчитайте не параллельные вставки и поиск в таблицах, а Фибоначчи до 1000 элемента. Рекурсивно. Если получится также параллельно все сделать, то будет отлично
Рекурсию в параллель не получится, конечно, а про код это вообще отдельная история. Разработка будет вестись с учетом предельной унификации хранения данных, на квинтетах.
Сейчас мы программируем примерно так -- вот программирование проводки документа в копии 1С Управление учетом:
https://www.youtube.com/watch?v=K7RpGL35k_4
покажите мне GPU где есть хотя бы миллион ядер? ну-ка-ну-ка?
20 млрд ядер, 8080 - 20 тыщ транзисторов (а нам сложнее и не нужно!) = миллион ядер. Ну пусть оверхед 50-90%. тогда 100 тыщ ядер, что тоже сильно больше любого gpu
Я не очень понял посыл. В статье в одну кучу смешаны ядра, транзисторы и невозможность программирования простым пользователем. Плюс ностальгия о том, что раньше пользователи компьютера могли помогать, а теперь это типа сложно, потому что транзисторов много.
Какая связь между пользовательским опытом и архитектурой процессора автор не объяснил.
Два тезиса: раньше компьютеры были дороги ими пользовались только специально обученные люди с интеллектом выше среднего. Сейчас каждая кухарка может управлять компьютером. Это не компы стали сложнее, это просто все более широкие категории пользователей стали ими пользоваться.
По поводу "программировать без программиста" - посмотрите на любые no-code платформы. Ими в итоге тоже пользуются специалисты, а не обычные пользователи.
А это всё у вас действительно с нуля развивается? Может стоит статьи почитать на эту тему? Про Dataflow Architecture, про модели организации вычислений - статьи проекта Ptolemy университета Беркли. Вычисления, управляемые данными не такая уж и простая штука чтобы пользователь мог с ними решать свои разнообразные задачки. В достаточно специальных областях, одной из которых является похеренная Вами GPU, такие подходы работают, но особого прогресса и расширения сферы применения что то не наблюдается.
Статьи читаем с прошлого века, конечно, но даже в комментариях выше есть слова, которые триггерят некоторые новые направления на подумать.
Именно что с прошлого века, когда пытались цвести всякие гиперкубы и торроидальные топологии, когда появилась аппаратная поддержка кластеров, ОС с динамической балансировкой задач по узлам вычислительной сети и прочее. И это были вполне промышленные решения. Однако примерно через поколение интерес к этим решениям поутих совсем. При этом, по сравнению с тем что описываете Вы, эти решения были на пару- тройку порядков проще - задачи гранулярней, вычисления менее связаны, функциональность и асинхронность как залог параллельности. И поставили на этих направлениях крестик в связи со сложностью и отсутствием универсальности. Почему Вы думаете что вот сейчас взлетит? Причём сразу на несколько порядков сложней?
Рискну заявить, что в начале прошлого века не было таких мощнейших средств прототипирования и разработки с одной стороны, и такого количества разношерстных задач с другой стороны. Вспомните количество процессов в Win 95-98 и сравните с сегодняшней картиной.
Вы правы, что задача на порядки сложней, потому что вместо коммутации элементов придется делать дизайн с нуля, однако, инструментарий тоже на порядки круче, чем в былые времена.
Ну, виндусы тут вообще непричём. Средства прототипирования уже были, и даже у нас в РФ. PThreads тоже существовали и кто хотел их использовал.
И что такое коммутация элементов vs дизайн с нуля осталось непонятным.
Вероятно, понадобятся новые простейшие полупроводниковые элементы, и дизайн из них придется делать с нуля.
Это на словах всё так просто, а по факту законы физики, материаловедение и химия вносят свои коррективы и так полупроводники это передний край науки и чтоб получить прорыв в области процессоров нужны научные прорывы в первую очередь.
Например фотонику для ускорения обмена данными, снижение энергопотреления а точнее уменьшить энергию и её потери при работе транзисторов, 3D чипы типо HBM только для процессоров и видеоускорителей, есть куда двигаться ещё на десятилетия вперёд и оптимизировать всё это даже с текущими архитектурами + есть надежны на применение ИИ который поможет оптимизировать многие моменты.
фотонику для ускорения обмена данными
Были ППЗУ с уф-стиранием, а ведь можно тактовую частоту установить морганием светодиодов, не?
Думаю не всё так просто, смысл не в тактовой частоте, а в том что шина данных которая передаёт информацию от ОЗУ к кешу и потом регистрам тоже имеет физические ограничения в плане скорости передачи информации, токи утечки.
А ППЗУ с уф-стиранием это вообще древний костыль из прошлого когда не умели делать нормальную перезаписываемую память, это явно не пр современность, это технология до Флеш памяти вообще.
Частоту тактовую ограничивает опять физика, переключение миллиардов транзисторов вызывают точки утечки и перегрев, досточно посмотреть на ТДП современных процессоров и видеокарт.
Даже если сделать супер крутую и более совершенную архитектуру которая так же потребует миллиарды транзисторов которые так же будут переключаться и так же будут токи утечки и перегрев....
Надо физику и материаловедение подтягивать, совершенствовать транзисторы ну и конечно интерконнект не просто же сделали чип церебрас для ии 1 чип на целую пластину 300мм и всё ради того чтоб быстрее между собой обменивались чипы информацией, советую про него почитать они уже 3 поколения выпустили, возможно такая система это будущее серверов и суперкопьютеров, время покажет что лучше.
Это сравнение сильно упрощенное, но оно отражает суть: один мощный универсальный вычислитель менее эффективен, чем комплекс из десятков тысяч простейших устройств.
Можно ссылку на какие-нибудь теории, исследования, хоть что-то, что бы доказывало этот утверждение? Мне что-то подсказывает что у вас все стоит на нереалистичных допущениях неограниченности какого-то ресурса. И если его вынуть все посыпется. "Эффективность" - понятие весьма относительное.
Мы как раз проводим исследование, чтобы это доказать. В поддержку есть только экспертное мнение инженеров-электронщиков и программистов. Интуитивно чувствуется, что утверждение верно, и кто-то должен быть первым, кто его наконец подтвердит.
Из теорий есть только стишок из детства про шайку зайцев и льва, хотя это фольклор.
Странно. Для меня это как-раз интуитивно на столько неверно, что я ставлю под сомнение экспертность ваших респондентов. Не все параллелится. Нужна координация и синхронизация. Это или невозможно (в общем случае, алгоритмически) или при возрастании узлов будет на столько дорого, что вы перехотите. В таком общем виде как вы написали ваше утверждение неверно. Не тратьте на подобные измышление время, уверен индустрия не зря пришла туда, где она сейчас находится. Было бы все так просто - мы давно имели бы другие архитектуры.
Это ваше право ставить под вопрос экспертность авторов статьи.
Про количество узлов и коммутацию -- вот это серьезный вызов, с этим предстоит работать. Мы делали это ранее, сделаем и теперь надеюсь, с помощью сообщества.
Это не вопрос права, вызова или сообщества. Меня или вас. Это очень суровая действительность, описанная и проверенная на практике не один раз в течение десятилетий развития отрасли. Это данность. Чтобы ее подорвать нужна сильная аргументация. Вы не дали никакой. И, по всей видимости, даже не разобрались в теме. Как там в логике - из ложной посылки может следовать что угодно. Пример: утверждение «если дважды два равно пяти, то снег красный» является истинным.
Где-то я слышал, не помню где, что при распараллеливании задач возрастают затраты на их синхронизацию. Да еще и многие задачи очень плохо параллелятся.
Я-то думал, аффтар хочет выбросить эмулируемое/имитируемое легаси, которого в современных машинах много.
И вернуться в плане простоты и понятности к компам 80-х с Basic и детской радостью познания (не застал).
А автор вместо этого огорошил непониманием закона Амдала.
И вернуться в плане простоты и понятности к компам 80-х с Basic и детской радостью познания
Ня! 640кБ хватит всем. Было дело.
Я-то думал, аффтар хочет выбросить эмулируемое/имитируемое легаси, которого в современных машинах много.
Да-да-да. Вот это постраничное переключение памяти и прочие издержки архитектуры прошлого века. Началась затея именно с размышлений об этом, но, пока размышляли, ситуация качественно поменялась, гротескно, я бы сказал.
Амдал и подумать не мог про 3300+ процессов.
Вот это постраничное переключение памяти и прочие издержки архитектуры прошлого века.
Простите, Вы хоть раз в жизни даже не проектировали - смотрели на реализацию устройств адресной арифметики процессора? Это очень непростая вещь, причем даже со стороны дилетанта в данном вопросе, меня то есть. Подозреваю, в реальном проектировании все гораздо сложнее.
На самом деле все просто. Есть 3 (и это только основных) стены сейчас в проектировании микропроцессорных систем: memory wall, power wall, frequency wall. Ни одна из них не может быть преодолена на текущем уровне развития технологий (и дело тут не в размере транзисторов) и, скорее всего, не будет преодолена в ближайшие 10-15 лет. Вы пытаетесь пробить их при помощи массового параллелизма, и наткнетесь ровно на те же самые 3 вышеописанных стены, что и производители GPU сейчас.
Вы делаете бесшовный переход с частных сложностей к общим постулатам, которые озвучивают проблему в общем. А статья про решение общей проблемы, и в ней нигде не говорится, что это будет просто, но мы ищем именно простое решение, как его нашли разработчики процессора i4004, вот именно на таком уровне - CMOS и технологии ключей
.
Решение точно не будет простым, даже если будет. Вы же сами пишете:
В то же время вычислительная мощность даже самых дешевых бытовых компьютеров, если пересчитать ее в миллиарды операций за единицу времени, многократно превосходит любые потенциальные нужды их пользователей. Просто используется эта мощность крайне неэффективно.
Мы с Вами по-разному понимаем слово "неэффективно". Для Вас неэффективно - означает недоиспользование имеющихся вычислительных мощностей, условно говоря, на мощном процессоре пользователь считает в экселе домашний бюджет. Я же понимаю неэффективность как трату процессорного времени на обсчет объемных кнопочек в том же экселе, за счет чего сам бюджет считается медленно и надо покупать более мощную машину. И никакая "другая" архитектура не изменит факта существования объемных кнопочек, поскольку это не вычислительная и не программистская проблема. Наберите systemd-analyze blame, потом htop и любуйтесь на эту проблему.
А то решение на картинке, что приведено у Вас - это не более чем донельзя стандартное решение "тонкий клиент", которое массово использовалось в первой половине 2000-х и тогда же произошел массовый отказ от него (впрочем, для бухгалтеров и юристов - самое оно, в крупных корпорациях и сейчас это убожество используется). Суть простая: у нас есть несколько серверных стоек, которые обсчитывают множество виртуалок, а у пользователя удаленный рабочий стол, который лишь является простеньким дешевым графическим терминалом к виртуалке (привет мейнфреймам из 70-х).
Из минусов подобных систем стоит выделить:
- по сути, окончательный цифровой Гулаг, когда не только твои данные, но и твое железо тебе не принадлежит, перешел улицу на красный - посиди дома без компа недельку
- единая точка отказа: любая крупная проблема в датацентре, включая атаку извне, приводит ко всеобщему простою, иногда длительному. А уж если у вас будет отозвана любая из сотен лицензий за плохое поведение вашего правительства...
- фактическая немасштабируемость. Тут лучше пояснить на малом объеме: систему строили на 1000 человек, все работало нормально, сейчас в компании 10 000, а так просто объем системы не увеличить: во-первых, это будет дороже не в 10 раз, а этак в 50, но основная проблема даже не в том: чтобы все это перенастроить, надо неделю. Когда к директору компании из 10 000 человек заходят с предложением остановить всю работу на неделю, в предлагающего может что-то полететь: обычно грубые слова, но иногда и стул (вспоминаем Стива Балмера). Итог: у пользователя спустя 5-7 лет вместо Win7, 8 ядер и16G по факту получается Win10, 4 ядра и 4G, что его несколько разочаровывает в плане той самой производительности. Это я на реальном примере жены-бухгалтера иллюстрирую.
Это я все к тому, что для предлагаемого Вами подхода основные проблемы - не в архитектуре, а в сознании людей, в их поведении. Тогда уж параллельно запускайте проект по выведению нового человека, безо всех вот этих текущих проблем в мозгах.
Амдал и подумать не мог про 3300+ процессов.
3295+ из которых, как правило, ничем не занимаются в каждый конкретный момент времени
Что-то такое читал про нейроморфный процессор на мемристорах, но он получался специализированным, для ии
Сложновато для пятницы, и пока слабо осязаемо.
Тем не менее, это ближайший аналог к теме статьи
https://ru.wikipedia.org/wiki/Нейронный_процессор
А в чем проблема?
Скачайте симулятор Icarus Verilog, купите FPGA плату для прототипа, софтвер для синтеза для FPGA и ASIC (OpenLane) для static timing analysis.
Сделайте прототип.
Пойдите к венчурным капиталистам, возьмите у них миллиард рублей и продуктизируйте.
Статья о том, что как раз проблем нет, мы делаем именно это, но только прототипировать (симулировать) будем не FPGA, а чуть ниже уровнем.
Прототипировать как раз хорошо на FPGA. Уровнем ниже стоит реализовывать уже проверенную концепцию.
Я даже больше скажу: можно вообще взять традиционные компьютеры и написать на них хотя бы эмулятор для проверки вашей идеи. И убедившись, что эмулятор делает что-то осмысленное можно копать глубже.
Я не предлагаю "симулировать FPGA", я предлагаю использовать FPGA для прототипирования будущего ASIC-а. Или вы будете реализовывать ваш процессор не на технологии ASIC standard cells?
Нет, не на ней
Вы собрались разработать собственный GAAFET транзистор и строить вычислительное устройство из них, а не из ASIC library?
Да, скорее всего, свой, но для прототипа не GAAFET, а попроще. Начнём вообще с эмуляции, далее технология будет выбрана в зависимости от результатов
Эмуляции? В смысле симуляции? На каком уровне:
Моделирование движения электронов и дырок в материалах
На уровне аналоговых элементов - SPICE
На уровне цифровых транзисторов - switch level
На уровне логических элементов и триггеров - gate-level
На уровне регистровых передач - Register Transfer Level (RTL)
На микроархитектурном уровне - конвейеры, очереди
На архитектурном уровне - инструкции, видимые программисту регистры
На уровне системы на кристалле - IP-блоки, интерконнект
Что-нибудь еще?
Вы бы о себе написали пару слов. Чтобы выдвигать такие смелые идеи стоит иметь определенные регалии в разработке современных высокопроизводительных процессоров.
Пара пунктов о достижениях команды:
1. Алгоритм в 12 строк, работавший публично больше 10 лет, почти каждый год в плюс. Сломался год назад. Не кОрысти ради, а принципа для (пруф https://www.darwinex.com/invest/AUX)
2. Квинтетная модель данных, полмиллиарда записей (https://www.youtube.com/watch?v=l0eg2xuC9Ks)
По п.1 тема раскрыта тут:
https://habr.com/ru/users/Asmodeux/publications/articles
То есть никакого опыта в разработке процессоров нет вообще. Может стоит пойти поработать в соответствующую сферу лет на 5-10? Узнать что люди делают, что делали, как и почему все это работает, как и почему большая часть смелых идей не работает.
Может стоит пойти поработать в соответствующую сферу лет на 5-10
Это плюс в нашей ситуации. Кто-то должен быть со свежим взглядом. Я регулярно смотрю в глаза человеку, кто проектировал процессоры, черпаю оттуда вдохновение. Он работает на два уровня выше, и эта статья не про дефекты разработки процессоров (они почти идеальны с учетом реалий), а про принципиально новую архитектуру построения полупроводниковых вычислителей.
Я тоже ничего не знаю о процессорах. Зато немного знаю про крупный серверный софт. Сфера совсем другая, но тоже сложная с кучей подводных камней и тоже с работающими и неработающими подходами. Человек со стороны который смотрит мне в глаза точно не сможет предложить ничего разумного в этой сфере. Он просто не в курсе что там как устроено и почему сделано именно так. Он даже не сможет спроектировать довольно типичный сервис с не менее типичными требованиями, куда уж там до принципиально новой архитектуры.
Нынче все стало настолько сложным что без минимум десятка лет опыта в сфере никто ничего разумного предложить не сможет. С опытом большая часть тоже не смогут, но как базовый фильтр пойдет.
Я кое-что знаю о процессорах, и программировал те из них, архитектуру которых ещё можно удержать в одной голове.
По теме: Ной был подневольным любителем, когда строил ковчег. Титаник строили профессионалы. Примерно так звучит притча.
У нас есть сотни человеко-лет опыта, на который мы можем опираться, есть конкретная задача и незашоренность. Иными словами, есть всё.
Объединенное поле с моделью уже есть. Minecraft называется, велкам в нём что-нибудь полезное запрограммировать ?
Так может проблема не столько в архитектуре проца, сколько в архитектуре софта? Если в 80-е годы как вы пишите экселевский функционал уже был доступен, то возросшая в "миллионы раз" производительность даёт нам тот же Эксель, который слегка притормаживает?
Software в большинстве своём sucks, и есть даже сайт, где есть список софта, который сделан по человечески
Автор какую-то пургу несёт. Видно что где-то что-то читал. Но мало понимает.
Напоминает статьи разоблачителей ОТО, которые квантовую физику и ОТО через эфир объединяют. Приводя в качестве мысленных экспериментов клубни картошки, дым и ямы на грядках.
"Общая производительность системы из миллионов простых и быстрых устройств должна вырасти на несколько порядков, даже несмотря на значительные накладные расходы на динамическое выделение вычислительных участков, доставку задачи к ним и прием результатов вычислений."
Проблема в том, что современные программы очень часто однопоточные. Им нужен только один процессор. Нет никакого смысла делать миллион простых и быстрых устройств - задачи не распараллеливаются. Процессоры будут простаивать без дела.
А если даже и найдётся задача, которую действительно можно распараллелить, то её можно запустить на видеокарте. У неё внутри хоть и не миллионы "простых и быстрых устройств", но тысячи.
А ещё процессорам нужны данные. Даже если удастся придумать задачу, которая требует для своего решения миллиона процессоров, то окажется, что нужно брать откуда-то данные. А диск, обычно, один. И даже если там SSD, со скоростью чтения в гигабайты в секунду, то эту скорость придётся поделить на миллион читающих данные процессоров. И скорость чтения упадёт до единиц килобайт в секунду.
Проблема в том, что современные программы очень часто однопоточные. Им нужен только один процессор.
Программа не работает в вакууме, она выполняется в среде, хорошо если это не виртуалка, вообще. Чтобы вычисли ваши 2*2 нужно меньше 1 такта процессора, что есть какие-то доли микросекунд. Но вы ждете, пока прокрутится анимация на вашем маке, чтобы с очень серьезным видом показать вам, что машина работала, старалась, и вот ваш результат.
Не проще ли анимацию убрать, вместо изобретения новой архитектуры?
Тогда кроме ожидания будет ещё неопределенность: работает оно или нет. Когда в Windows 2000 появился бесконечный (зацикленный) прогресс-бар, это был лютый треш с точки зрения пользовательского опыта, но то что творится сейчас при загрузки сайтов и приложений, это многократно хуже.
Тогда я не понимаю претензий. Сначала говорите, что при вычислении 2x2 все ресурсы съедает анимация, а не само вычисление, а потом говорите, что без анимации скучно.
Ну и, в догонку. Когда у нас один супер-мощный процессор, который лопатит всё в один поток, намного понятнее, где сейчас прогресс операции. Чем когда у нас 1000 агентов, которые между собой взаимодействуют асинхронно, а потом все результаты должны слиться в одной точке. Делать в такой архитектуре внятные прогресс-бары - задача на 2 порядка сложнее.
Вот здесь в моем комментарии приведен пример мониторинга одного из наших серверов. Там зарегистрировано 1500+ баз клиентов, ежемесячно активны около 150 клиентов, у которых под 300 пользователей суммарно, из которых в пиковые часы работают 30-60 одновременно. Вот они прекрасно параллелятся как между базами, то есть, работают полностью независимо, так и внутри одной базы, когда работают с несвязанными напрямую сущностями.
И им не нужно даже показывать прогресс-бар, потому что даже работая с одной таблицей в БД, они не конфликтуют, ожидая запрос 10-30 мс.
Ну отлично. Я говорю, что в распределённой системе делать прогресс-бары намного сложнее. Вы отвечаете, что у вас есть быстрый супер-сервер, которому прогресс-бар не нужен...
Прогресс-бар на фронте, с бэком и его распределенными вычислениями не связан. Или я не так понял?
Если тема про клиентскую станцию и рендеринг аяксовской крутилки, то это другая тема.
Кто-то кого-то не понимает.
Тут я вижу претензии к текущему положению дел из-за потребления ресурсов на анимацию
Чтобы вычисли ваши 2*2 нужно меньше 1 такта процессора, что есть какие-то доли микросекунд. Но вы ждете, пока прокрутится анимация на вашем маке, чтобы с очень серьезным видом показать вам, что машина работала, старалась, и вот ваш результат
На что я отвечаю: уберите анимацию, и нет проблем.
Вы парируете: "а как тогда юзер узнает о текущем статусе выполнения задачи", параллельно сетуя, что точные прогрессы сейчас заменены бесконечными крутилками.
Тогда я привожу аргумент, что собрать точный прогресс в расределённой системе - задача более сложная и трудоёмкая, чем в централизованной. Намекая на то, что если сейчас тратится много ресурсов, то в вашей прекрасной 100000-юнитной архитектуре придётся тратить ещё больше.
Как-то так...
Всё уже придумано до нас. Гуглите systolic computing.
Я пару лет назад слушал одного инженера из этой области, так с его слов проблема у процессоров скорее в подсистеме памяти и кеше, а так же в скорости света.
Что в будущем ради скачка производительности процессор нужна подситема памяти на основе фотоники, дело не в ядрах и архитектуре в целом это чисто физические ограничения применяемых материалов при росте объёма передаваемых и обрабатываемых данных.
Сначала говорится про то, что мы должны одновременно использовать весь транзисторный бюджет (как то забывая при этом про фактор нагрева - здравствуй avx512 превращающий любой процессор в кипятильник потому что использует много транзисторного бюджета одновременно, а там даже не весь камень), потом приводится в пример мозг - который вообще-то активируется зонами по потребностям.
Про то, что почти все задачи невозможно размазать как единое поле данных протекающее через cpu т.к. они строго последовательны тоже не учтено. Нельзя посчитать x+1 пока не знаешь x - это может быть буквально любое число.
Есть функциональное программирование, где результатом написания программы фактически является функция от данных - фиксированная последовательность битовых манипуляций приводящих к искомому результату из входных данных. Состояние в таком подходе является входным и выходным параметром одновременно и сложность программ с состоянием становится заоблачной.
Т.е. если мы имеем несколько кнопок, то состояние нажатости этих кнопок всегда передаётся на вход, на каждое обновление экрана например, а на выход мы получаем состояние всех элементов интерфеса, картинку и снова передаём это на вход. Вот вам и как будто поле данных которые нужно обрабатывать.
И вот у нас реакт, который вынужден использовать трюки в виде shadowdom и остлеживания где изменения есть, а где нет - потому что считать каждый раз весь результат это медленнее чем только нужный фрагмент.
И после этого мы говорим про программирование силами пользователя. При полном параллелизме. В самой сложный парадигме, когда нужно понимать всю последовательность преобразований над данными, чтобы получить конечный результат и всю модель данных держать в голове одновременно. Ну не знаю, это уже какой-то садизм. Пользователь даже не понимает что такое данные и теория информации, для него закагадка как они хранятся и перечень возможных операций.
Ну и дальше совсем весело "Предлагаемый подход подразумевает стопроцентную точность моделирования предметной области" - предложение вообще не имеет смысла. Модель по определению это некоторое упрощение которое содержит только ключевые параметры и отметает все, что не важно для результата - а 100% точность моделирования это повторение процесса целиком, что невозможно даже физически благодаря принципу неопределённости Гейзенберга.
"Если когда-нибудь человечество изобретет способ запрограммировать настоящий искусственный интеллект, то полученная программа сможет функционировать только в такой среде, о которой рассказывается здесь." - какие-то голословное и бессмысленныое утверждение. Естественный интелект выполняется на том, чему ближайшие аналоги - нейропроцессоры, с чего бы требовалась какие-то непонятные архитектуры для искусственного? Да и вообще причём тут ИИ, и интеллект в целом - там куча своих проблем, тут и без них хорошо.
В общем идея помирает уже на моменте когда мы считаем что проблема современных процессоров в неиспользовании транзисторного бюджета. Проблема в том, что на одном чипе мы столько не охладим а на многих чипах не обеспечим достойный интерконнект для обмена данными, а чип в метр площади не вырастим никогда. И будет у нас не непрерывное поле а куча шоссе с узкими соединяющими дорогами и перекрестками. Где весь этот красивый поток данных будет сминаться и ждать. А там глядишь кольцевую шину изобретем или infinity fabric link.
Последовательная архитектура процессора диктуется последовательностью алгоритмов, которые проектирует человек. Пока не выполнен условный IF, алгоритм никуда не пойдёт. А последовательная структура алгоритмов диктуется,в свою очередь, последовательностью нашего мышления, зависимостями посылов, условий и результатов выполнения операций. Есть процессы принципиально распараллеливаемые, например сбор яблок с дерева и это успешно решается, т.к. подзадачи независимы. А есть процессы последовательные, например беременность. И 9 женщин за месяц ребёнка не родят. Как уже правильно в комментариях заметили, завтрашнее будущее - нейронные сети и технология нейроморфных вычислений - вот, что нам нужно. Там и эффективное использование транзисторного бюджета и массовый параллелизм. Есть конечно вопросы к самой архитектуре современных нейронных сетей, но это отдельная тема.
Правильные рассуждения, но давайте рассуждать глубже. Алгоритм и мышление последовательные и даже детерминированные. Дело в том, что исполнитель алгоритма не обязан быть детерминированным. Он исполняет в других терминах чем сформулировано в алгоритме. отсюда возможность распараллеливания. А вот с оператором If немного сложнее. В алгоритме он расположен для выполнения в каком то конкретном месте, которое и определяет порядок его выполнения. А это расположение подразумевает что состояние исполнителя к этому моменту могло измениться так, что требуется его анализ. Изменение состояния это событие. Если построить систему и архитектуру исполнителя на основе событий ( и программу, естественно), то можно , выполнять If параллельно ибо проверка состояния не изменяет состояния. Это в принципе. А как это сделано можно посмотреть здесь. https://www.youtube.com/channel/UCmYLzFS7e1K9rl50IBIaTkQ. Тут и архитектура и язык решающий эти проблемы. Реально многопроцессорные и реально много шинная.
Нейронки никак не заменяют обычные вычисления и алгоритмы. Они могут их эффективно дополнять и улучшать, но о полной замене речи никогда не было.
Комментарием ниже - очень хороший пример про условные переходы. Нейронка может быть очень эффективным предсказателем ветвлений, но она не может заменить саму проверку условия и ветвление.
Могу ошибаться, но подобное ведь уже делалось. Первым был O2 от Silicon Graphics, вторым Next. Правда, речь шла не о процессоре, а о системе в целом. Центральный процессор выступал в роли диспетчера, не более. Может имеет смысл вернуться к этим древним технологиям? Я древний и давно перестал следить за этой темой, так что не судите строго.
сложное.. вы предлагаете избавиться от костылей, и оптимизировать сложную цепочку простых операций сжав ее в конкретные аппаратные специализированные компоненты?
я в этом вижу появление asic, видеокарт как отдельных от проца модулей, компонентов для ускорения вычислений для нейросетей в SoC , или же появление логарифмической линейки.
т.е. либо специализация, либо универсальность. этот вечный треугольник деньги/скорость/качество.
пока будет потребность от одной и той же машины требовать диаметрально противоположных задач и будут эти костыли.
конечно можно уже сейчас что-то упростить и оптимизировать, но как правило это будет означать отказ от чего-то старого в погоне за новым. и сново возврат к эмуляции/имитации старого, потому что это "новое" не смогло решить старую задачу качественно.
Существующая архитектура и основанные на ней подходы к развитию аппаратного и программного обеспечения, очевидно, устарели.
Очевидно - вместо тысячи аргументов (сарказм). Утверждение в основе статьи на столько же безосновательное, как и все дальнейшие суждения.
Я еще в 5м классе собирал инициативную группу, чтобы строить ракеы нового поколения и расселяться по галактике, потому что астероид. Статья выглядит примерно также.
Я бы предложил сначала научиться писать софт, который на текущих ядрах эффективно работает. А потом и отмасштабировать на много мелких ядер можно при необходимости. Вон сколько ядер у любой видюхи.
Я бы предложил сначала научиться писать софт, который на текущих ядрах эффективно работает.
Мы написали такой софт, и теперь беремся за железо.
Вот профиль нагрузки на одном из серверов за неделю: на сервисе работают десятки пользователей одновременно, 1 ядро ЦПУ, Xeon @ 2.5Ghz. В основном системы учета и загрузка данных.
Предположу, что дествительно эффективно, т.к. нету цели холиварить. Теперь и других бы стоило научить. Вот бы хотя бы половина разработчиков так умела.
А вы пробовали? Тут есть интерактивные уроки ideav.online
Кажется, в итоге мы придем к вычислительному шару (или кубу).
Главная её задача успешно решается уже сейчас — сделать возможным прикладное программирование силами пользователя, а не профессионального программиста, используя существующее системное ПО и средства разработки.
Можно пояснительную бригаду? Вы уверены, что какой-нибудь авиаконструктор/оператор МРТ/дизайнер/бухгалтер хочет программировать, а не заниматься своей работой?
Если же вы говорите о no code и low code решениях, вы вообще в курсе, какой ценой даются такие решения? Чтобы это работало, сначала нужно написать в несколько раз больше кода, а потом это всё будет потреблять в несколько раз больше ресурсов, нежели обычное приложение, сделанное от и до квалифицированными программистами.
Да, конечно, мы в курсе, поскольку no-code платформу мы уже разработали и люди ей пользуются. Вот, двумя ответами выше есть график, который показывает потребление ресурсов no-code конструктором. Если сравнивать с 1С, то ресурсов надо на порядок-два меньше.
И, да, часто наши клиенты своими руками программируют себе сервис по нашим подсказкам, а потом самостоятельно вносят исправления.
Думаю, потребление ресурсов меньше не потому что это no code, а потому что вы сравниваете с 1с
Ок, давайте сравним с чем хотите. Десятки пользователей одновременно, база и сервер на 1 машине, загрузка видна на графике.
Там работают несколько клиентов, у самого большого 100+ пользователей, 40+ виртуальных магазинов, 6000+ товаров, тысячи заказов в работе.
Ну сравните с Airtable для начала. Миллионы юзеров, терабайты даты, вот это всё.
Ок, принято. Попробуйте там вот это.
Ах, там лимит 200к записей, облом.
Чтобы сравнение было честное, вам нужно ваш же софт переписать под нужды конкретного клиента, чтобы он выполнял тот же функционал, что сейчас, только вырезать всё лишнее и убрать возможность глубокой кастомизации пользователем, плюс убрать лишние слои абстракции, связанные с этим. Вот тогда можно будет говорить, что софт работает хорошо (или плохо) из-за того, что он no-code, а не из-за того, что у вас разработчики толковые.
Моему товарищу тут нужно сделать приложение для кальянки (мобильный клиент для гостей, еще 1 для админов и сервер) - чтобы гости могли заходить и в интерактивном режиме видеть какие кресельки заняты а какие нет на каждый час, и осуществлять бронирование конкретных столов, а ресепшен видел это дело, ну и со статистикой загрузки и графиками конечно. Дадите нам вашу nocode платформу чтобы он быстренько в ней сделал себе такое?
Даже и поможем ему накликать. Платформа доступна тут ideav.online. Можно зарегистрироваться в 1 клик и пройти вводные интерактивные уроки.
Я может фигню скажу, но кмк намного лучше себя показывают специализированные сопроцессоры под конкретные задачи. Тот же gpu например, всякие сопроцы для шифрования и прочее. Вместо массива однородных процессоров которые делают все но средне сделать разные которые умеют делать что-то одно но хорошо
Вы не только не сказали фигню, вы в общем то прошли довольно большой отрезок по пути за инженерами intel/amd - если пойти дальше, то вы придете к тому, что можно универсальный процессор разбить на группы специализированных блоков, а перед ними поставить транслятор, специализация которого будет в том, чтобы распределять общую задачу по специализированным блокам. Для этого нужно будет придумать новые наборы команд например хм... 3dAvx или now128, а потом доберетесь до того, что если текущая инструкция занимает только часть специальных блоков, то можно представить физический процессор в качестве двух логических (ммм назовём хм... гипер резьба) и транслятору команд разрешить нагружать блоки параллельно.
В прочем я немного... много утрирую, но уверен - вы на правильном пути)
Вы как-то не учитываете тот факт, что первичен не процессор, а задача, которую он решает. И клиент, который платит деньги за решение этой задачи.
Мы живём в реальном мире, в котором разработка и производство нового процессора стоит миллиарды - и его разработчик должен быть уверен, что он эти миллиарды окупит. И поэтому условный Интел не делает новые процессоры в воздух - а делает их в тесной связке с Майкрософтом, который, под ещё не вышедший процессор, проектирует новые архитектуры в винде, которые будут их потреблять. Вендоры компов заранее придумывают новые компы под них и т.п.
Плюс всё это дело обвязано огромным количеством софта, библиотек, технологий и компетенций разработчиков, которые заточены под ТЕКУЩЕЕ состояние рынка - а переучивание их на новую архитектуру будет стоить огромных денег, которые мало у кого есть.
Вспомните уникальный процессор Cell, который сделали Сони с IBM для третьей плойки. Уникальная машинка, супер-эффективная, простая и мощная. Весь мир предписывал ей колоссальное будущее! И сдулась она ровно по такой же причине - разрабам оказалось слишком сложно разбираться в новой архитектуре, чтобы использовать её на полную мощность. Проще и выгоднее оказалось тупо перевести приставку на обычную x86 архитектуру - да даже и на неё разработчики жалуются и привыкают к ней слишком долго.
Или ещё пример - нейропроцессор IBM TrueNorth. Ну то есть натурально IBM сделала проц, имитирующий нейронные связи - что-то типа нынешних TPU, которые есть в каждом телефоне. Только сделали они его в 2014-м году!!! На не-фонНеймановской архитектуре, кстати.
Это было безумно круто - но никто ничего не понял, потому что массово нейросети и задачи под них появились только лет через десять. И под этот чудесный процессор просто не нашлось задач и деньжат зелёных айбиэму за него никто нести не хотел. Поэтому и продолжать уникальную разработку не было КОММЕРЧЕСКОГО смысла. На на некоммерческой основе такие вещи не сделать никому.
Вот такая вот суровая реальность.
Про Cell (из моих личных ощущениий о "верните мой 2007й") мне кажется было все иначе. В то время симметричная многоядерность только появилась, два ядра было охрененно круто. А cell имел одно базовое ядро и кажется сразу 6 "синергетических" - казалось в то время, что такого уровня параллелизма на симметричной архитектуре не достичь. Но потом Ctrl+V для ядер быстро освоили и стало понятно, что нет никакой нужды возиться с подобными гибридами.
Ойё. В одну кучу намешана новая неведомая архитектура CPU и способность юзера программировать не будучи программарём. В последнем абзаце явно не хватает фразы "С нами бог, а они там все на западе не справятся, засев в своих гендерно-нейтральных туалетах".
Я правильно понял, что вы собираетесь взять «процессор на порядок примитивнее 4004» (даже я, даже на самом грубом качественном уровне не представляю, как это вообще работает), выдать ему 520 байт SRAM, полметра DRAM, а потом «замостить плиточкой» из этого весь чип, чтобы повязать чипы в такой вот куб?
Ха, смело. Такой градус упоризма я ещё не встречал. Даже меня переплюнули — я предполагал этот куб из более традиционных SoC :-D Как минимум, оно сможет работать нейропроцессором, так что впарить кому-то это наверняка получится.
Дедушка старый, так что практической помощи не ждите (не считая того, что я, кажется, вам самим сейчас только что объяснил, чего же именно вы хотели) — но, может, кто-то сжалится и сделает вам эмуляцию сего упоризма на старых добрых шейдерах, чтобы было хотя бы реально оценить, можно ли с помощью хоть какого-то кодогенератора запрограммировать эту миллионопоточную Брейнфак-машину.
Засада там в том, что каждый нано-вычислитель сможет достучаться до нужных данных только через цепочку других таких же, которым для этого придётся прервать свою работу. А плюс — в том, что этих цепочек там, в параллель, доступно ну мягко говоря доуха. Короче, «вскрытие покажет».
И я немного не в курсе, можно ли вообще к двоичной лямбда-машине подключить (без контроллера, который всё сожрёт!) DRAM и адекватные порты к «соседям». И сколько крови выпьет софтовый рефреш силами лямбда-машины. Короче, даже я это весьма туманно представляю себе.
Я правильно понял, что вы собираетесь взять «процессор на порядок примитивнее 4004» (даже я, даже на самом грубом качественном уровне не представляю, как это вообще работает), выдать ему 520 байт SRAM, полметра DRAM, а потом «замостить плиточкой» из этого весь чип, чтобы повязать чипы в такой вот куб?
Нет, неправильно
Засада там в том, что каждый нано-вычислитель сможет достучаться до нужных данных только через цепочку других таких же, которым для этого придётся прервать свою работу.
Вот это надо будет решить, чтобы не прерывать.
Это всё очень грубое описание: про наноисполнителей и передачу задач. Надо будет применить нетривиальные решения.
Фантазёр (об авторе). Сложность идёт от совместимости со всем ПО, включая системное, которое создано за последние 30-40 лет. Никто не готов его выбросить .
Но подвижки есть, см. например архитектуру Intel 86S, которая пока лишь только предложена на бумаге, но возможность ее использования сейчас закладывается в ядре линукса, например.
Машина Кузьмина представляет собой перечислимое множество ячеек (концептов) и перечислимое множество управляющих устройств (можно считать их головками, кому это удобно) назначение которых – адресация (активация) концептов четырех видов (для чтения, записи, выполнения и инициализации). Номер концепта будем называть адресом.
Ячейка (а не головка как у МТ) имеет множество состояний (значений) S (возможно бесконечное). Пока событием будем называть состояние концепта. Это не противоречит интуитивному представлению о событии как о процессе изменения состояния потому что факт изменения состояния определяется анализом на принадлежность новому состоянию (истинность события), и зачастую событие имеет имя этого нового состояния.
Каждое событие может иметь конечное множество подписок. Подписка — номер концепта к которому осуществляется адресация управляющего устройства и при условии истинности события (Т.е. при определенных состояниях концепта.), которому принадлежит подписка.
Работа машина заключается в адресации концепта. При активации концепта, запускается анализ на истинность всех событий концепта (анализ не изменяет состояние концепта и потому может выполняться одновременно для всех событий) имеющих подписки, и при истинности этих событий машина активирует концепты с номерами, указанными в подписках (одновременно, если истинных событий с подписками больше одного). При отсутствии подписок адресация выполняет предназначенную функцию в зависимости от вида адресации (чтение-запись-выполнение-инициализация). Т.е. осуществляется чтение-запись, выполнение арифметической операции или создание нового концепта, используя адресуемый как класс. На чем работа и заканчивается.
Миленниалы изобрели то ли GPU, то ли FPGA, то ли велосипед с квадратными колесами.
Смешались в кучу кони, люди... Автор ничего не слышал про закон Амдала, и (как видно по бреду про три тыщи тредов) даже не удосужился сходить в википедию его понять после нескольких упоминаний в комментах, и то ли пытается изобрести уже изобретённый велосипед Smalltalk и Erlang в железе, то ли просто наглухо упоротый генерирует кликбейтные заголовки. Ибо архитектура фон-Неймана тут вообще абсолютно ни при чем (в каждом "мелком вычислителе" она будет точно такая же), а корни современной беды с плачевным состоянием софта лежат вообще не в технологиях - это организационная проблема. Менеджмент (то есть в конечном счете капитализм) требует выдавать тонны говнопродуктов как можно быстрее, для чего нанимаются толпы наспех недообученных быдлокодеров, которые, разумеется, уже попросту не могут чего-то там наизучать и оптимизировать, а вынуждены брать готовые слои абстракций и наворачивать их еще и еще. Без решения этой проблемы - а другая аппаратная архитектура потребует и изменения концептов программирования - ничего не выйдет: много щас хотя бы на Erlang пишут, не говоря уже о Smalltalk?..
Новая архитектура процессора — уже пора