Существующая архитектура и основанные на ней подходы к развитию аппаратного и программного обеспечения, очевидно, устарели. Это приводит к очень низкому КПД используемых ресурсов и неоправданно большим затратам на единицу полезного действия. Большую часть времени современные компьютеры решают искусственно созданные проблемы, порожденные, в частности, привязкой к принципам построения вычислительных машин времен середины прошлого века.
«Искусственная» сложность ПО
Из-за огромной сложности прикладного программирования большинство пользователей находятся в зависимости от разработчиков программного обеспечения (ПО). При этом разрыв в требуемой квалификации программиста и пользователя компьютера постоянно увеличивается. Изначально компьютер предназначен для решения задач, поставленных напрямую пользователем, и необходимо дать пользователю возможность делать это самостоятельно.
Технологические ограничения
Развитие вычислительной техники, уже много лет ведущееся экстенсивным путем, уперлось в технологические ограничения: невозможно бесконечно уменьшать и ускорять компоненты компьютера. В то же время вычислительная мощность даже самых дешевых бытовых компьютеров, если пересчитать ее в миллиарды операций за единицу времени, многократно превосходит любые потенциальные нужды их пользователей. Просто используется эта мощность крайне неэффективно.
Сама собой напрашивается разработка абсолютно новой архитектуры и операционной системы вычислительных машин для массового использования.
Идея
Объединить данные, процессоры и программы в единое масштабируемое поле, моделируя в нем реальные объекты с их свойствами и поведением. То есть, вместо последовательной обработки цепочки команд одним процессором следует создавать модели, самостоятельно работающие в рамках поставленной задачи. Операционная система при этом только координирует процессы, а прикладное программирование сводится к описанию задач простейшим наглядным способом.
Закон Мура
Согласно Закону Мура, количество транзисторов в процессорах удваивается каждые полтора-два года, при этом заметного роста производительности его ядер мы больше не наблюдаем.
Рост производительности при кратном увеличении сложности устройств составляет единицы процентов и продолжает снижаться с годами.
Пришло время в корне пересмотреть архитектуру компьютеров и построить принципиально иное решение, способное кратно масштабироваться с сохранением линейной зависимости сложность/производительность.
Что мы имеем сейчас
Современный процессор содержит миллиарды транзисторов, причем полезную работу в каждый момент времени делает лишь микроскопическая часть из них: за каждый такт процессора выполняется всего несколько команд, обрабатывая десятки байтов информации.
А теперь представьте, что вся эта полупроводниковая «рабочая сила» трудится одновременно в полном составе над всем множеством задач: вместо 2-8 ядер процессора вся вычислительная мощность поделена на участки, автономно делающие свою маленькую работу.
Первый процессор больше полувека назад содержал 2300 транзисторов. Микропроцессоры 80-х годов уже были способны решать сегодняшние задачи (вычисления в таблицах Excel и любая бизнес-логика) и состояли из 20-30 тысяч транзисторов.
Устаревший процессор Intel Core i7 из 2008 года содержит 1.3 млрд транзисторов, а Intel Core i9 из 2022 года – уже 12 млрд транзисторов. Узким местом в них являются ядра – несколько независимых вычислителей, выполняющих всего несколько операций за 1 такт процессора.
Получается несколько миллиардов операций с плавающей запятой в секунду. Это не много, с учетом десятков тысяч потоков выполнения и миллионов байт, которые обрабатываются процессором. При этом самая простая операция, требующая, например, увеличения двузначного числа на единицу, ждет своей очереди и занимает полноценный такт мощнейшего процессора.
Подробнее об архитектуре
Транзисторы, из которых состоит современный процессор, позволяют коммутировать миллионы вычислительных участков, делающих полезную работу одновременно, занимая ресурсы пропорционально сложности задачи – вычисления одно-, двух-, четырех- или восьмибайтовых значений.
Даже при стократных накладных расходах на коммутацию примитивных вычислителей и уменьшении частоты их работы, такая архитектура позволит делать в десятки тысяч раз больше операций в секунду. Что особенно важно, этот подход вернет возможность масштабирования вычислительной мощности.
Общая производительность системы из миллионов простых и быстрых устройств должна вырасти на несколько порядков, даже несмотря на значительные накладные расходы на динамическое выделение вычислительных участков, доставку задачи к ним и прием результатов вычислений.
Это сравнение сильно упрощенное, но оно отражает суть: один мощный универсальный вычислитель менее эффективен, чем комплекс из десятков тысяч простейших устройств.
Главная задача, которую надо будет решить при разработке новой архитектуры, – это многомерная структура вычислительного поля с динамическим выделением вычислительных участков и передачей задач и результатов.
Будет создано единое поле, в котором конфигурируется то, что нужно, из универсальных элементов. Они и шина, и АЛУ нужной разрядности, и роутер, и память, в зависимости от ситуации. Это может звучать необычно, и так точно ещё никто не делал, поэтому нам придется хорошо потрудиться.
Например, компоновка вычислителей и транспортной части может быть как псевдо-многомерная, выполненная в виде плоской схемы, так и трехмерная – как делаются многослойные платы. Второй вариант пока выглядит спорно и требует принципиально нового решения.
Разрабатываемая архитектура, возможно, похожа на устройство мозга человека, в котором несколько управляющих структур содержат многие миллиарды взаимодействующих между собой элементов, работающих одновременно и независимо.
Разумеется, нашу задачу невозможно выполнить, просто перекоммутировав существующую сейчас элементную базу, а необходимо полностью переработать подход к построению вычислительных машин и создать совершенно новые составляющие будущего компьютера. Разработку придется вести с нуля – коммутируя транзисторы.
Современные технологии позволяют создавать достаточно недорогие и мощные устройства, как в виде прототипов, так и серийно. В силу этого бюджет первой фазы проекта (подтверждение концепции, создание прототипа) сравнительно невелик.
Перспективы
Все научные и производственные задачи лучше решать таким инструментом, который наиболее полно может охватить суть их объектов. Предлагаемый подход подразумевает стопроцентную точность моделирования предметной области.
Если когда-нибудь человечество изобретет способ запрограммировать настоящий искусственный интеллект, то полученная программа сможет функционировать только в такой среде, о которой рассказывается здесь.
В мозге есть участки, отвечающие за разное, они поделены на участки, которые выполняют функции, те в свою очередь поделены на группы исполнителей, которые состоят из чего-то ещё и в конце концов всё сделано из нейронов и синапсов – элементарных блоков хранения и реагирования.
В нашей стране много талантливых и работоспособных людей. Необходимо найти их, разъяснить идею и вовлечь в проект, позволив им внести посильный вклад и получая дополнительные идеи по конкретным реализациям стратегии. И всё получится!
Комментарии (187)
edh_krusher
12.04.2024 11:26+11А конкретика есть или только громкими словами решили фон Неймана победить?
ideavi Автор
12.04.2024 11:2610 лет примерно мы ходим вокруг этой идеи, и теперь собираемся создать конкретику. Без громких слов и с огромным уважением к фон-Нейману и коллегам с их наработками.
ideavi Автор
12.04.2024 11:26+1Кстати, планировал обратиться к авторам некоторых комментариев в личку с предложением обсудить некоторые мысли. И буду рад любым обращениям по теме.
Tequila24
12.04.2024 11:26+22Спешите видеть, ОП изобретает GPU
ideavi Автор
12.04.2024 11:26Про GPU был абзац в статье, как пример того, куда эта инициатива двигаться точно не будет, хотя отдаленная аналогия напрашивается. Убрали по итогам обсуждения с ранними рецензентами.
WVitek
12.04.2024 11:26+1Возможно, автор переизобретает "Мультиклет"
ideavi Автор
12.04.2024 11:26О, нет, нет.
qw1
12.04.2024 11:26А почему нет? У меня прямо дежа вю. В чём принципиальное отличие вашей идеи?
ideavi Автор
12.04.2024 11:26В поле вычислителей не будет фиксированных АЛУ, шин и коммутаторов, если коротко.
beeruser
12.04.2024 11:26+3Так не бывает. Либо у вас есть 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, чем к обычным процессорам.
К тому же в современных Эльбрусах есть аппаратный предсказатель ветвлений.
ideavi Автор
12.04.2024 11:26Kilocore (Rapport Inc X IBM)
О, отлично, спасибо, очень интересно!
Даже наличие тяжеловеса IBM не помогло хоть сколько запустить эту тему.
Бывает. Тут вот парни потратили миллионы долларов и годы времени на таблицу из 240+ колонок с 40+ индексами, а мы эту же задачу решили за 3 месяца работы и 1170 строк кода, уложившись в 5 колонок и 3 индекса.
TheR1ddle
12.04.2024 11:26Благодарю. Много нового для себя почерпнул.
Т.е. всё упирается в необходимость программистам обязательно учитывать особенности архитектуру процессора в своих алгоритмах? А есть такая необходимость потому, что невозможно силами компилятора реструктурировать под иную архитектуру?
В принципе, если подумать, действительно не очевидно как сохранить задуманное разработчиком поведение, но переделать на многопоточный код, в котором почти каждая последующая конструкция использует результат вычислений предыдущей...
Наверное эффект будет как в ПК-играх начала 00-х. Когда запускаешь на современном многоядерном процессоре и удивляешься, что игра использует 2 ядра, а остальные не задействованы.
qw1
12.04.2024 11:26В поле вычислителей не будет фиксированных АЛУ, шин и коммутаторов, если коротко
Ну так, создатели Мултиклета тоже начинали за всё хорошее. Но, они всё же дошли до продукта в железе, наверняка им пришлось зарезать 90% своих идей, чтобы вписаться в реальность.
Я, например, не представляю, как можно сделать без шин и коммутаторв
Внутри кубика множество уровней, по которым перемещаются исполнители и передают задачи, причем перемещаются по желанию, используя общие циклы сдвига
Они что, ножками будут бегать? Если бы мне ставили такую задачу, мне пришлось бы придумывать, как кубики подключать к шине. Даже если сделать связи каждый-с-каждым, как без коммутаторов понять, какая сейчас связь активна.
Насчёт отсутствия "фиксированных АЛУ". Встретившись с реальностью, вы передумаете. Потому что, современный блок 32-битного умножения это шедевр конструкторской мысли, переполненный всевозможными инженерными хитростями, и заменив его готовый на гибкое решение, которое может быть сконфигурировано на всё-что-угодно, вы непременно проиграете в производительности.
ideavi Автор
12.04.2024 11:26Они что, ножками будут бегать?
Вполне удачное сравнение
современный блок 32-битного умножения это шедевр конструкторской мысли, переполненный всевозможными инженерными хитростями, и заменив его готовый на гибкое решение, которое может быть сконфигурировано на всё-что-угодно, вы непременно проиграете в производительности.
Да, проиграем, возможно в 100 или 1000 раз. Это понятно и принято
qw1
12.04.2024 11:26То есть задачи, которые не смогут распараллелиться, проиграют в 100 или 1000 раз.
ideavi Автор
12.04.2024 11:26Исполнители задач будут слабее в 100-1000 раз, но их будет в десятки тысяч больше и они будут на порядок дешевле.
Процессор универсален и за эту универсальность мы платим, и платим всё больше, получая непропорциональное увеличение производительности.
Эта статья о новой универсальности, за которую тоже придется платить, но в этот раз мы хотим преодолеть предел, к которому вплотную подошли разработчики -- вернуть возможность масштабирования вычислительной мощности.
qw1
12.04.2024 11:26Непонятно, на какую нишу вы нацеливаетесь.
В HPC, где работают лучшие умы, и там всё вылизано в оптимизациях, всё считается на GPU а то и специализированных ASIC-ах, вам ловить нечего с вашим 100X тормозным умножением.
В классическом десктопе тоже ловить нечего. Машинная автоматизация не сделает автоматом параллельность x100-x1000, а ручная стоит очень дорого (как мне объяснить работодателю, что весь день занимался распараллеливанием накидывания кнопок на тулбар, чтобы форма открывалась 1 мс, а не 5 мс), да и нет таких задач, чтобы параллелить x100.
В бизнес-приложениях узкое место доступ к памяти и хранилищам. База 10 ТБ, которая лежит на RAID или даже в DRAM, не сможет вдруг обеспечить чтение x1000 из хранилища, чтобы все исполнители были заняты.
ideavi Автор
12.04.2024 11:26Пока необходимо проработать концепцию и предложить первое масштабируемое решение.
При нишу пока говорить рано, но далее, как водится, первым клиентом будет широкий потребитель, который получит черный ящик, который стоит копейки, но решает свою задачу
и можно делать бэкапы. Так мы продаем сейчас другой, уже готовый, продукт, и это работает.
qw1
12.04.2024 11:26Какую конкретно задачу, офисной машинки? Я сильно сомневаюсь что вы осилите современный браузер, а это значит, вашу коробочку надо ставить рядом с классическим ПК. И чтобы что? Крутить на ней аналог клиента 1с? Но вы же доказали, что на x64 можете написать быстрое десктопное приложение, без новой архитектуры. Тогда зачем новая коробочка?
ideavi Автор
12.04.2024 11:26Аналог не клиента 1С, а сервера, но повторюсь, об этом пока рано. Даже решенную проблему с унифицированным хранением данных мы пока не продаём массово, а коробочка -- это следующее поколение.
qw1
12.04.2024 11:261с покупают не потому что он быстрый или дешёвый (он не быстрый и не дешёвый), а потому что поддерживается. Вам интересно вместо копания в архитектурах увязнуть в нормативных актах, учётных политиках и бухгалтерских регистрах?
ideavi Автор
12.04.2024 11:26В 1С поддерживаются только определенные законом формы и правила, в всё, что клиент нагородит себе, часто безжалостно ломается обновлениями.
Мы делаем дополнения к 1С, типа простых систем учета и планирования, каталогов, трекеров задач, табелей, биллинга, аналитики. В простом случае такие вещи можно сделать за 2 вечера, и клиент сам их может поддерживать. На 1С это будет мега-проект и куча ограничений.
qw1
12.04.2024 11:26Если вы не претендуете на платформу гос. уровня (типа 1с), то ваши клиенты - единичные шаурмячные и автозаправки. На них столько не заработаешь, чтобы окупить не то что новую архитектуру и тем более тех. процессы на других физ. принципах, а даже новую ОС (а без неё видимо вам никак).
nerudo
12.04.2024 11:26+2Программисты уже радостно потирают руки - сколько работы у них будет с массовым внедрением принципиально новых архитектур.
ideavi Автор
12.04.2024 11:26Да, всё даже ещё более серьезно. Программировать тоже придется принципиально иначе.
TheR1ddle
12.04.2024 11:26Либо сделать более сложный backend для популярных компиляторов, которые смогут модифицировать структуру кода под новую архитектуру таким образом, чтобы логика поведения программы осталась ожидаемой для программиста. Например как в случае с современным Эльбрус - предсказание условных переходов реализовано в backend компилятора, а не в процессоре (x86_64).
ideavi Автор
12.04.2024 11:26В статье есть ссылка про прикладное программирование. Это часть концепции, и она уже реализована в обычном железе и софте, хотя 15 лет назад нам говорили, что это не заработает и помрет на 1-2 млн записей в базе.
Логику поведения программы мы представляем на самом высоком уровне, чтобы было понятно даже пользователю с программистским складом ума, а не программисту с глубоким бэкграундом.
DimPal
12.04.2024 11:26+8Получилсь архитектура эффективная для узкого круга задач. Сколько SQL-запросов в секунду сможет обрабатывать Web сервер на такой архитектуре? На сколько быстрее обработается рейтрейсинг на 3 миллиарда треуголников? Будет ли каскад ассоциативных кешей для доступа к RAM?
ideavi Автор
12.04.2024 11:26Скорость выполнения отдельных запросов, очевидно, уменьшится. В начале нулевых все работали на сотнях мегагерц, но отклик сервера был намного быстрее, чем можно было моргнуть глазом. То есть, в прикладном смысле скорость обслуживания пользователей заметно не изменится совсем, хотя для их выполнения понадобится значительно больше тактов псевдо-процессора. На порядки больше.
FOH
12.04.2024 11:26В нулевые? Быстрее? Да вы шутить изволите, батенька.
Даже то что тогда было, не было мгновенным. А современное там скорость, ну вот никак, совсем не покажет.
ideavi Автор
12.04.2024 11:26Запросы к базе, которые сейчас выполняются за полмиллисекунды на ssd, тогда (в 2003) отрабатываали за 10-15 мс
Heartofhill
12.04.2024 11:26Не обязательно, что в будущем производительность систем будет измеряться по таким же критериям, как и сейчас: рейтрейсинг 3 миллиардов треугольников, например. Мне представляется, что мерой измерения производительности ИИ систем будет количество когнитивных операций в секунду. Под когнитивной операцией я подразумеваю следующее: если человек задал запрос в систему на естественном языке, в системе запускается процесс моделирования ситуации, соответствующей запросу. Например, если вопрос касается физического мира - запускается аналог физического движка. К примеру, вопрос такой может быть: что будет если кинуть камень в окно? Или что будет если кинуть в окно пакет с орехами? Или еще что-то. В разных случаях результат зависит от условий: скорости, того, что вы кидайте, стекла, из которого состоит окно. Я сейчас предполагаю, что не существует базы данных, включающей все возможные варианты, чтобы условный GPT просто выдал вам то, на чем он обучался. Здесь нужно каждую отдельную ситуацию именно моделировать: то есть, реализовывать аналог воображения и мышления у человека. И вот такие когнитивные операции могут требовать очень много вычислительных ресурсов. И, вероятно, может быть создана архитектура, специально адаптированная под выполнение этих когнитивных операций, которая будет это делать гораздо эффективнее стандартных архитектур. А рейтрейсинг 3 миллиардов треугольников пускай продолжают делать видеокарты.
ideavi Автор
12.04.2024 11:26Про рендеринг согласен, видеокарты делают своё дело очень хорошо.
Мы же смотрим на операционную систему и прикладные программы, которые выполняют простые пользовательские задачи. Как-то так получилось, что пользователь сильно переплачивает за выполнение простейших задач: деньгами, временем, природой. Начиная от драгоценных минут ожидания обновления ОС и заканчивая выделением тепла 8-ю ядрами, молотящими 2,5 млрд тактов в секунду.
knstqq
12.04.2024 11:26+1Сколько SQL-запросов в секунду сможет обрабатывать Web сервер на такой
архитектуре? На сколько быстрее обработается рейтрейсинг на 3 миллиарда
треуголников?давайте я вам отвечу! На 4к экране примерно 10 миллионов пикселей. Значит 10 миллионов ядров очень даже пригодятся для рейтрейсинга на 3 миллианрда треугольников. А с учётом двойном буфферизации - 20 миллионов ядер! прекрасный пример же!
------------
сколько sql запросов обрабатывать? Ну смотрите, в таблице - 1 миллиард записей. Прилетает запрос, применяем к каждой из записей фильтр = 1 миллиард ядер для простейшего процессинга нужно. Потом результат объядиняем рекурсивно. на втором этапе рекурсии и объединения по простой аггрегирующей функции (сумма например, или счётчик) - 500 миллионов ядер, на третьем - 250 млн ядер и тд.
Хорошие примеры привели! ещё есть?
singular_asm
12.04.2024 11:26+5Как я понимаю, это идея создания SISD (single instruction single data) процессора максимально простым и сверх многоядерным. Т.е. предлагаете core i9 с его 12 млрд. транзисторов заменить на кучу atom-ов с таким же количеством транзисторов под одной крышкой.
И упрощение в сторону RISC, чтоб инструкции были одной длины и можно было убрать блок декодирования.
И убрать блок перестановки инструкций. Он только место занимает и нагрев создаёт. Ещё программисты в край обленились, не хотят писать качественный код.
ideavi Автор
12.04.2024 11:26Да, только условный atom должен быть ультра-RISC и как-бы плавать среди своих собратьев в этом вычислительном поле.
singular_asm
12.04.2024 11:26С большим количеством ядер, APIC и шина доступа к периферии станут узким местом. В какой-то момент прирост производительности станет менее заметным. А распределение нагрузки за счёт "светофоров" создаст большую пробку (traffic jam), в которой вместо полезной работы будет выполнятся распределение задач за счёт всё того же единственного APIC в системе.
Я пока писал это, обдумал разделение ЦПУ на блоки по прерываниям. Когда поступает прерывание от таймера на переключение задачи, останавливаются не все ядра, а только часть из них, потом другая, потом третья. Следовательно для других блоков это прерывание должно быть замаскировано. И было бы неплохо сделать выделение квантов времени на блок. Например если блок получает 4 кванта времени, то следующие 3 прерывания по таймеру будут замаскированы.
Такой расклад распределит нагрузку APIC во времени, но создаст задержки для периферии и увеличит input lag, что критично в игровых ПК.Решение полученной проблемы - одни блоки будут обрабатывать исключительно систему и драйверы, из-за чего должны будут реагировать на каждое срабатывание таймера.
В этой идее определённо что-то есть.
ideavi Автор
12.04.2024 11:26+1Прочитал Синклер асм и вздрогнул, потому что начинал со спектрумовских бейсика и ассемблера.
Представьте себе, что шина у вас – это некий кубик со множеством входов на каждой грани, куда можно подключиться и закачивать задачи. Всю периферию вы подключаете в любой свободный вход, и она там обслуживается. Всё асинхронно, но для простоты у всего одна частота и взаимодействие определяется контрактом при подключении.
Внутри кубика множество уровней, по которым перемещаются исполнители и передают задачи, причем перемещаются по желанию, используя общие циклы сдвига.
Вот примерно так мы это видим в самом первом грубом приближении.singular_asm
12.04.2024 11:26Вот здесь не одобряю.
Шина с куб это уже не упрощение, а усложнение. Множество контактов напоминает HBM память, которая толком не прижилась за более чем 10 лет. Всё из-за большого процента брака и отвалов.
Если исполнитель выбирает сам себе задачу - ему нужно самому для себя выполнять сдвиг, а это время. Если исполнители это делают "по желанию" тогда присутствует фактор рандома и может появиться задача, которая будет выполнена 2 раза подряд, а может и не выполниться вовсе. Такой вариант не подходит игровым ПК и системам точно вычисления зависящим от времени (например нужды ВПК).
Имхо. Должен быть порядок и кто-то отвечающий за него (Возврат к APIC).
Как говорится "За что отвечают двое - за то не отвечает никто".
ideavi Автор
12.04.2024 11:26Вроде я не говорил о разделении ответственности за задачу, и выбор задачи не привязан к перемещению исполнителя, которое нужно для ротации ресурсов - освободить место для следующего исполнителя. Но это пока только наброски.
Brak0del
12.04.2024 11:26+1Множество контактов напоминает HBM память, которая толком не прижилась за более чем 10 лет. Всё из-за большого процента брака и отвалов.
Наверно поэтому её сейчас постоянно ставят в топовые роутеры и GPU, которые на наших глазах творят революцию в ИИ.
knstqq
12.04.2024 11:26дешёвые свичи/роутеры для соединения между N портами прогоняют всё через центральный вычислитель и если вдруг нагрузить не 2 порта из 20 нагрузкой в гигабит, а хотя бы 5 портов - упс, всё начинает лагать.
Дорогие свичи роутеры умеют прямые соединения между 2 портами обрабатывать независимо и все 20 портов могут работать на максимальной поддерживаемой скорости в гигабит, что даёт 20 Гбит суммарную пропусную способность (In + Out если сложить), или намного больше если порты 2.5/10Гбит, или есть 40 штук вместо 20.
А если влепить х*** схемотехнику наотъ***сь, то 2 пользователя пересылающие друг друг файл заставят всех страдать.
myswordishatred
12.04.2024 11:26+6Интересно, конечно, а как синхронизировать работу всех этих десятков тысяч простых исполнителей. А к ним же наверняка и кэш разноуровневый прикрутить захочется и другие вкусности. Мне кажется, что инжинерам такое в страшных снах не приснится.
ideavi Автор
12.04.2024 11:26+2Я, как инженер, тоже всякое повидал, поэтому мы будем не прикручивать, а отстреливать и всячески упрощать. Как раз кэш - одна из таких вещей. А можно сказать и так: всё - кэш.
alysnix
12.04.2024 11:26+14а о чем эта статья?.. да ни о чем! изрядное количество наивной критики сопровождается не менее наивной "идеей", которую автор до конца и не понял. вся идея существует в виде одного предложения. типа раз мало - плохо, сделаем много и будет хорошо.
вообще-то увеличение производительности методом горизонтального масштабирования - этой идее столько же лет, сколько идее однопоточного вычислителя. еще в первой половине 20 века, за неимением компьютеров, сидели считальщицы и крутили ручки арифмометров, рассчитывая то, что им давали инженеры.
так что, спасибо за идею.
ideavi Автор
12.04.2024 11:26+4И вам спасибо за экспресс-анализ и критику!
Без наивных, как вы говорите, идей прогресса и не было бы. Да, сейчас тут мне пошутят, что я проспал 1 апреля и откроют глаза. Да, мы можем и не преуспеть. Тем не менее, команду мы собираем и результат будет, пусть даже и в виде опровержения возможности задумки.
Но я надеюсь на лучшее.
Ababaj
12.04.2024 11:26Ещё раз корректирую: очень будет похоже на японский проект 80г. суперкомпьютеров 5 поколения - ещё раз вспомните его цели и итоги + с законом Амдала, а то нынешнее поколение программистом и ИТ- спецов знает только давно здохший закон Мура!
ideavi Автор
12.04.2024 11:26Надо будет ещё раз почитать про тот японский компьютер. Читал лет 10 назад.
это многомерная структура вычислительного поля с динамическим выделением вычислительных участков и передачей задач и результатов
В статье описано именно такое: единое поле, в котором конфигурируется то, что нужно, из универсальных элементов. Они и шина, и АЛУ нужной разрядности, и роутер, и память, в зависимости от ситуации.
Как бы это необычно ни выглядело.
Никто из уважаемых минусаторов не воспринимает эту концепцию всерьёз, предлагая различные иные существующие решения и инициативы.
Sun-ami
12.04.2024 11:26+4Узким местом до сих пор являются не ядра, а шина памяти. И это следствие того, что для процессоров, динамической памяти, и флэш-памяти используются существенно разные техпроцессы, что не позволяет размещать их на одном кристалле так же эффективно как на разных кристаллах, и приводит к появлению этого узкого места как соединения по крайней мере между кристаллами. Кроме того, задействовать все транзисторы одновременно с той же эффективностью, с которой сейчас задействована их малая часть, мешает прямая зависимость тепловыделения от числа реально задействованных в работе транзисторов. Снижение рабочей частоты на 30% не решает эту проблему. В принципе, переход к вычислениям с высокой степенью параллелизма может дать большой эффект не только на простых задачах, для которых он уже произошел в видеокартах, но и на сложных. И он постепенно происходит с появлением центральных процессоров с сотнями ядер. Но с программной точки зрения это сложно.
ideavi Автор
12.04.2024 11:26В первой фазе это видится как драматическое снижение производительности отдельных вычислительных процессов при увеличении количества вычислителей. Одна из проблем, которые нужно решить, это как раз сделать вычислители автономными, имеющими свою память, пусть даже и ограниченную несколькими квази-регистрами.
tttinnny
12.04.2024 11:26+9А подумайье, автор, под другим углом: если в один квант времени работает лишь ничтожно малая часть процессора в нынешних условиях, но имея при этом уже космические тдп в сотни ватт, то что будет с вашей "идеальной" конструкцией, где работают все ядра на полную мощность? Места на кристалле не жалко, большой и большой, а реальная проблема так и осталась за кадром, да ещё и возросла многократно по предлагаемой вами модели)
ideavi Автор
12.04.2024 11:26Если понизить частоту работы схемы, то нынешние технологии позволят снимать достаточно вычислительной мощности с единицы вычислительной площади. Сейчас все эти ватты рассчитаны близко к пределу разрушения, чтобы выиграть проценты мощности, а у нас такой задачи не стоит и мы планируем выиграть не скоростью.
tttinnny
12.04.2024 11:26+1А потом поймёте, что ваши ядра могут решать однотипные задачи и придумаете ГПУ. Потом добавите возможность читать разные инструкции огромными блоками и исполнять их на каждом таком ядре и получите vliw. Против последнего ничего не имею, главное, суметь сделать компилятор)
ideavi Автор
12.04.2024 11:26+1В любом случае, это интересная задача, хотя пока нет смысла заглядывать так далеко.
Первым результатом будет принципиальная схема встраивания нано-процессора в вычислительное пространство. Он может быть 4- или даже 2-хбитным, это не так важно, как подтверждение концепции конфигурируемого поля вычислителей.tttinnny
12.04.2024 11:26+1Короче я понял, вы хотите сделать vliw). Советую почитать, про то, как это было сделано в том же итаниуме и других аналогах и их набор инструкций. Не согласен с тем, что суперскалярные процы лучше. Проспойлерю: они погибли из-за жадности одной небезызвестной компании. У них был большой потенциал, но деньги вливали туда, что приносило доход, а что приносило доход, туда и вливали деньги... И после пары десятков лет стало очевидно, что поддерживать догоняющую минорную архитектуру стало нецелесообразно, а жаль...
ideavi Автор
12.04.2024 11:26Эти парни хотели оптимизацию использования железа, когда у них уже было железо и оно частенько простаивало. Мы ещё не дошли до такой развитой стадии, кроме того, я бы желал снять думы о локальной параллелизации с программиста, сделав всю черновую работу за него. Благо делается ведь это достаточно тривиально.
tttinnny
12.04.2024 11:26+1Да, есть огромная проблема, когда для расчета следующих значений нужны предыдущие. За один такт пытаться это решать бессмысленно: низкая тактовая частота и на конвейер не поставить, без хорошего предсказателя ветвлений и приходу к нынешней суперскалярности. По причине зависимости от ещё не вычисленных значений, это дело не выполнить параллельно. ньюансов много, но если чувствуете в себе силы...
ideavi Автор
12.04.2024 11:26Это рекуррентные вычисления, и из тысяч потоков на вашем компьютере их использует, наверное, каждый. Даже в этом случае количество таких потоков в сотни-тысячи раз меньше числа ядер вашего процессора.
tttinnny
12.04.2024 11:26+1Это при условии всех тех сервисов, что наспавнила ОСь, где надо количество, а не качество. Пользовательское приложение, которое он запустил и видит перед собой, должно выполняться на самом "жирном" и быстром ядре. Распараллелить код, логика которого преимущественно последовательна, исключительно железом вряд ли выйдет без "особой" кодовой организации или помощи компилятору
ideavi Автор
12.04.2024 11:26У ОС свое видение приоритетов, а у приложения -- своё. В итоге реклама в боковом меню браузера у меня заливается соловьём в HD, а моя несчастная табличка из 30 строк грузится 20 секунд. Бывало у вас такое? Да, это про сеть и браузер, не про процессор.
tttinnny
12.04.2024 11:26Да, но раз с нашими нынешними процессорами табличка из 30 строк грузится 20 секунд, то дело не в процессоре, а в коде) я к тому, что, есть большая вероятность, что вам придется комплексно решать вопрос не только архитектурой, но и бекендом к шлангу или гцц
ideavi Автор
12.04.2024 11:26Бэкенд в этой парадигме мы уже сделали, его можно посмотреть:
https://www.youtube.com/watch?v=l0eg2xuC9Ks
и пощупать живьем:
https://ideav.online/sber
и даже творить самому:
https://ideav.online/ru
tttinnny
12.04.2024 11:26Выглядит неплохо, но что насчёт кода? На чем это программировать? И, для чистоты эксперимента, посчитайте не параллельные вставки и поиск в таблицах, а Фибоначчи до 1000 элемента. Рекурсивно. Если получится также параллельно все сделать, то будет отлично
ideavi Автор
12.04.2024 11:26Рекурсию в параллель не получится, конечно, а про код это вообще отдельная история. Разработка будет вестись с учетом предельной унификации хранения данных, на квинтетах.
Сейчас мы программируем примерно так -- вот программирование проводки документа в копии 1С Управление учетом:
https://www.youtube.com/watch?v=K7RpGL35k_4
knstqq
12.04.2024 11:26покажите мне GPU где есть хотя бы миллион ядер? ну-ка-ну-ка?
20 млрд ядер, 8080 - 20 тыщ транзисторов (а нам сложнее и не нужно!) = миллион ядер. Ну пусть оверхед 50-90%. тогда 100 тыщ ядер, что тоже сильно больше любого gpu
koreychenko
12.04.2024 11:26+3Я не очень понял посыл. В статье в одну кучу смешаны ядра, транзисторы и невозможность программирования простым пользователем. Плюс ностальгия о том, что раньше пользователи компьютера могли помогать, а теперь это типа сложно, потому что транзисторов много.
Какая связь между пользовательским опытом и архитектурой процессора автор не объяснил.
Два тезиса: раньше компьютеры были дороги ими пользовались только специально обученные люди с интеллектом выше среднего. Сейчас каждая кухарка может управлять компьютером. Это не компы стали сложнее, это просто все более широкие категории пользователей стали ими пользоваться.
По поводу "программировать без программиста" - посмотрите на любые no-code платформы. Ими в итоге тоже пользуются специалисты, а не обычные пользователи.
ideavi Автор
12.04.2024 11:26Посыл — пришло время кое-что упростить.
No-code платформу мы и сами делаем, и многие наши клиенты сами управляются, без программиста. Хотя начальный импульс в правильную сторону им придать надо.koreychenko
12.04.2024 11:26+1Дык чтобы кому-то было просто, кто-то другой должен был очень сильно поработать. Просто оно нахаляву не бывает.
nv13
12.04.2024 11:26+1А это всё у вас действительно с нуля развивается? Может стоит статьи почитать на эту тему? Про Dataflow Architecture, про модели организации вычислений - статьи проекта Ptolemy университета Беркли. Вычисления, управляемые данными не такая уж и простая штука чтобы пользователь мог с ними решать свои разнообразные задачки. В достаточно специальных областях, одной из которых является похеренная Вами GPU, такие подходы работают, но особого прогресса и расширения сферы применения что то не наблюдается.
ideavi Автор
12.04.2024 11:26Статьи читаем с прошлого века, конечно, но даже в комментариях выше есть слова, которые триггерят некоторые новые направления на подумать.
nv13
12.04.2024 11:26+1Именно что с прошлого века, когда пытались цвести всякие гиперкубы и торроидальные топологии, когда появилась аппаратная поддержка кластеров, ОС с динамической балансировкой задач по узлам вычислительной сети и прочее. И это были вполне промышленные решения. Однако примерно через поколение интерес к этим решениям поутих совсем. При этом, по сравнению с тем что описываете Вы, эти решения были на пару- тройку порядков проще - задачи гранулярней, вычисления менее связаны, функциональность и асинхронность как залог параллельности. И поставили на этих направлениях крестик в связи со сложностью и отсутствием универсальности. Почему Вы думаете что вот сейчас взлетит? Причём сразу на несколько порядков сложней?
ideavi Автор
12.04.2024 11:26Рискну заявить, что в начале прошлого века не было таких мощнейших средств прототипирования и разработки с одной стороны, и такого количества разношерстных задач с другой стороны. Вспомните количество процессов в Win 95-98 и сравните с сегодняшней картиной.
Вы правы, что задача на порядки сложней, потому что вместо коммутации элементов придется делать дизайн с нуля, однако, инструментарий тоже на порядки круче, чем в былые времена.nv13
12.04.2024 11:26Ну, виндусы тут вообще непричём. Средства прототипирования уже были, и даже у нас в РФ. PThreads тоже существовали и кто хотел их использовал.
И что такое коммутация элементов vs дизайн с нуля осталось непонятным.
ideavi Автор
12.04.2024 11:26Вероятно, понадобятся новые простейшие полупроводниковые элементы, и дизайн из них придется делать с нуля.
inoonwt
12.04.2024 11:26Это на словах всё так просто, а по факту законы физики, материаловедение и химия вносят свои коррективы и так полупроводники это передний край науки и чтоб получить прорыв в области процессоров нужны научные прорывы в первую очередь.
Например фотонику для ускорения обмена данными, снижение энергопотреления а точнее уменьшить энергию и её потери при работе транзисторов, 3D чипы типо HBM только для процессоров и видеоускорителей, есть куда двигаться ещё на десятилетия вперёд и оптимизировать всё это даже с текущими архитектурами + есть надежны на применение ИИ который поможет оптимизировать многие моменты.
bkint
12.04.2024 11:26фотонику для ускорения обмена данными
Были ППЗУ с уф-стиранием, а ведь можно тактовую частоту установить морганием светодиодов, не?
inoonwt
12.04.2024 11:26Думаю не всё так просто, смысл не в тактовой частоте, а в том что шина данных которая передаёт информацию от ОЗУ к кешу и потом регистрам тоже имеет физические ограничения в плане скорости передачи информации, токи утечки.
А ППЗУ с уф-стиранием это вообще древний костыль из прошлого когда не умели делать нормальную перезаписываемую память, это явно не пр современность, это технология до Флеш памяти вообще.
Частоту тактовую ограничивает опять физика, переключение миллиардов транзисторов вызывают точки утечки и перегрев, досточно посмотреть на ТДП современных процессоров и видеокарт.
Даже если сделать супер крутую и более совершенную архитектуру которая так же потребует миллиарды транзисторов которые так же будут переключаться и так же будут токи утечки и перегрев....
Надо физику и материаловедение подтягивать, совершенствовать транзисторы ну и конечно интерконнект не просто же сделали чип церебрас для ии 1 чип на целую пластину 300мм и всё ради того чтоб быстрее между собой обменивались чипы информацией, советую про него почитать они уже 3 поколения выпустили, возможно такая система это будущее серверов и суперкопьютеров, время покажет что лучше.
AlexunKo
12.04.2024 11:26+3Это сравнение сильно упрощенное, но оно отражает суть: один мощный универсальный вычислитель менее эффективен, чем комплекс из десятков тысяч простейших устройств.
Можно ссылку на какие-нибудь теории, исследования, хоть что-то, что бы доказывало этот утверждение? Мне что-то подсказывает что у вас все стоит на нереалистичных допущениях неограниченности какого-то ресурса. И если его вынуть все посыпется. "Эффективность" - понятие весьма относительное.
ideavi Автор
12.04.2024 11:26Мы как раз проводим исследование, чтобы это доказать. В поддержку есть только экспертное мнение инженеров-электронщиков и программистов. Интуитивно чувствуется, что утверждение верно, и кто-то должен быть первым, кто его наконец подтвердит.
Из теорий есть только стишок из детства про шайку зайцев и льва, хотя это фольклор.
AlexunKo
12.04.2024 11:26+3Странно. Для меня это как-раз интуитивно на столько неверно, что я ставлю под сомнение экспертность ваших респондентов. Не все параллелится. Нужна координация и синхронизация. Это или невозможно (в общем случае, алгоритмически) или при возрастании узлов будет на столько дорого, что вы перехотите. В таком общем виде как вы написали ваше утверждение неверно. Не тратьте на подобные измышление время, уверен индустрия не зря пришла туда, где она сейчас находится. Было бы все так просто - мы давно имели бы другие архитектуры.
ideavi Автор
12.04.2024 11:26Это ваше право ставить под вопрос экспертность авторов статьи.
Про количество узлов и коммутацию -- вот это серьезный вызов, с этим предстоит работать. Мы делали это ранее, сделаем и теперь надеюсь, с помощью сообщества.AlexunKo
12.04.2024 11:26Это не вопрос права, вызова или сообщества. Меня или вас. Это очень суровая действительность, описанная и проверенная на практике не один раз в течение десятилетий развития отрасли. Это данность. Чтобы ее подорвать нужна сильная аргументация. Вы не дали никакой. И, по всей видимости, даже не разобрались в теме. Как там в логике - из ложной посылки может следовать что угодно. Пример: утверждение «если дважды два равно пяти, то снег красный» является истинным.
Asmodeux
12.04.2024 11:26+1Чтобы ее подорвать нужна сильная аргументация
Давайте дождёмся фактов. Кому интересна аргументация
evgenyk
12.04.2024 11:26+1Где-то я слышал, не помню где, что при распараллеливании задач возрастают затраты на их синхронизацию. Да еще и многие задачи очень плохо параллелятся.
lealxe
12.04.2024 11:26+2Я-то думал, аффтар хочет выбросить эмулируемое/имитируемое легаси, которого в современных машинах много.
И вернуться в плане простоты и понятности к компам 80-х с Basic и детской радостью познания (не застал).
А автор вместо этого огорошил непониманием закона Амдала.ideavi Автор
12.04.2024 11:26+2И вернуться в плане простоты и понятности к компам 80-х с Basic и детской радостью познания
Ня! 640кБ хватит всем. Было дело.
Я-то думал, аффтар хочет выбросить эмулируемое/имитируемое легаси, которого в современных машинах много.
Да-да-да. Вот это постраничное переключение памяти и прочие издержки архитектуры прошлого века. Началась затея именно с размышлений об этом, но, пока размышляли, ситуация качественно поменялась, гротескно, я бы сказал.
Амдал и подумать не мог про 3300+ процессов.
DarkTiger
12.04.2024 11:26+2Вот это постраничное переключение памяти и прочие издержки архитектуры прошлого века.
Простите, Вы хоть раз в жизни даже не проектировали - смотрели на реализацию устройств адресной арифметики процессора? Это очень непростая вещь, причем даже со стороны дилетанта в данном вопросе, меня то есть. Подозреваю, в реальном проектировании все гораздо сложнее.
На самом деле все просто. Есть 3 (и это только основных) стены сейчас в проектировании микропроцессорных систем: memory wall, power wall, frequency wall. Ни одна из них не может быть преодолена на текущем уровне развития технологий (и дело тут не в размере транзисторов) и, скорее всего, не будет преодолена в ближайшие 10-15 лет. Вы пытаетесь пробить их при помощи массового параллелизма, и наткнетесь ровно на те же самые 3 вышеописанных стены, что и производители GPU сейчас.ideavi Автор
12.04.2024 11:26Вы делаете бесшовный переход с частных сложностей к общим постулатам, которые озвучивают проблему в общем. А статья про решение общей проблемы, и в ней нигде не говорится, что это будет просто, но мы ищем именно простое решение, как его нашли разработчики процессора i4004, вот именно на таком уровне - CMOS и технологии ключей
.
DarkTiger
12.04.2024 11:26+1Решение точно не будет простым, даже если будет. Вы же сами пишете:
В то же время вычислительная мощность даже самых дешевых бытовых компьютеров, если пересчитать ее в миллиарды операций за единицу времени, многократно превосходит любые потенциальные нужды их пользователей. Просто используется эта мощность крайне неэффективно.
Мы с Вами по-разному понимаем слово "неэффективно". Для Вас неэффективно - означает недоиспользование имеющихся вычислительных мощностей, условно говоря, на мощном процессоре пользователь считает в экселе домашний бюджет. Я же понимаю неэффективность как трату процессорного времени на обсчет объемных кнопочек в том же экселе, за счет чего сам бюджет считается медленно и надо покупать более мощную машину. И никакая "другая" архитектура не изменит факта существования объемных кнопочек, поскольку это не вычислительная и не программистская проблема. Наберите systemd-analyze blame, потом htop и любуйтесь на эту проблему.
А то решение на картинке, что приведено у Вас - это не более чем донельзя стандартное решение "тонкий клиент", которое массово использовалось в первой половине 2000-х и тогда же произошел массовый отказ от него (впрочем, для бухгалтеров и юристов - самое оно, в крупных корпорациях и сейчас это убожество используется). Суть простая: у нас есть несколько серверных стоек, которые обсчитывают множество виртуалок, а у пользователя удаленный рабочий стол, который лишь является простеньким дешевым графическим терминалом к виртуалке (привет мейнфреймам из 70-х).Из минусов подобных систем стоит выделить:
- по сути, окончательный цифровой Гулаг, когда не только твои данные, но и твое железо тебе не принадлежит, перешел улицу на красный - посиди дома без компа недельку
- единая точка отказа: любая крупная проблема в датацентре, включая атаку извне, приводит ко всеобщему простою, иногда длительному. А уж если у вас будет отозвана любая из сотен лицензий за плохое поведение вашего правительства...
- фактическая немасштабируемость. Тут лучше пояснить на малом объеме: систему строили на 1000 человек, все работало нормально, сейчас в компании 10 000, а так просто объем системы не увеличить: во-первых, это будет дороже не в 10 раз, а этак в 50, но основная проблема даже не в том: чтобы все это перенастроить, надо неделю. Когда к директору компании из 10 000 человек заходят с предложением остановить всю работу на неделю, в предлагающего может что-то полететь: обычно грубые слова, но иногда и стул (вспоминаем Стива Балмера). Итог: у пользователя спустя 5-7 лет вместо Win7, 8 ядер и16G по факту получается Win10, 4 ядра и 4G, что его несколько разочаровывает в плане той самой производительности. Это я на реальном примере жены-бухгалтера иллюстрирую.Это я все к тому, что для предлагаемого Вами подхода основные проблемы - не в архитектуре, а в сознании людей, в их поведении. Тогда уж параллельно запускайте проект по выведению нового человека, безо всех вот этих текущих проблем в мозгах.
1dNDN
12.04.2024 11:26+1Амдал и подумать не мог про 3300+ процессов.
3295+ из которых, как правило, ничем не занимаются в каждый конкретный момент времени
YuriPanchul
12.04.2024 11:26+9А в чем проблема?
Скачайте симулятор Icarus Verilog, купите FPGA плату для прототипа, софтвер для синтеза для FPGA и ASIC (OpenLane) для static timing analysis.
Сделайте прототип.
-
Пойдите к венчурным капиталистам, возьмите у них миллиард рублей и продуктизируйте.
ideavi Автор
12.04.2024 11:26Статья о том, что как раз проблем нет, мы делаем именно это, но только прототипировать (симулировать) будем не FPGA, а чуть ниже уровнем.
JustMoose
12.04.2024 11:26+4Прототипировать как раз хорошо на FPGA. Уровнем ниже стоит реализовывать уже проверенную концепцию.
Я даже больше скажу: можно вообще взять традиционные компьютеры и написать на них хотя бы эмулятор для проверки вашей идеи. И убедившись, что эмулятор делает что-то осмысленное можно копать глубже.
ideavi Автор
12.04.2024 11:26На традиционном компьютере мы и будем моделировать поведение полупроводниковых соединений (даже не элементов!), чтобы заставить наше информационное поле выполнять простейшие задачи.
YuriPanchul
12.04.2024 11:26Я не предлагаю "симулировать FPGA", я предлагаю использовать FPGA для прототипирования будущего ASIC-а. Или вы будете реализовывать ваш процессор не на технологии ASIC standard cells?
ideavi Автор
12.04.2024 11:26Нет, не на ней
YuriPanchul
12.04.2024 11:26Вы собрались разработать собственный GAAFET транзистор и строить вычислительное устройство из них, а не из ASIC library?
ideavi Автор
12.04.2024 11:26Да, скорее всего, свой, но для прототипа не GAAFET, а попроще. Начнём вообще с эмуляции, далее технология будет выбрана в зависимости от результатов
YuriPanchul
12.04.2024 11:26+4Эмуляции? В смысле симуляции? На каком уровне:
Моделирование движения электронов и дырок в материалах
На уровне аналоговых элементов - SPICE
На уровне цифровых транзисторов - switch level
На уровне логических элементов и триггеров - gate-level
На уровне регистровых передач - Register Transfer Level (RTL)
На микроархитектурном уровне - конвейеры, очереди
На архитектурном уровне - инструкции, видимые программисту регистры
На уровне системы на кристалле - IP-блоки, интерконнект
-
Что-нибудь еще?
ideavi Автор
12.04.2024 11:26Начнем анализ на уровне 1 - перемещение зарядов. Надеюсь, быстро выберем что-то готовое и поднимемся выше, иначе -- будем тут изобретать решения.
BugM
12.04.2024 11:26Вы бы о себе написали пару слов. Чтобы выдвигать такие смелые идеи стоит иметь определенные регалии в разработке современных высокопроизводительных процессоров.
ideavi Автор
12.04.2024 11:26+1Пара пунктов о достижениях команды:
1. Алгоритм в 12 строк, работавший публично больше 10 лет, почти каждый год в плюс. Сломался год назад. Не кОрысти ради, а принципа для (пруф https://www.darwinex.com/invest/AUX)
2. Квинтетная модель данных, полмиллиарда записей (https://www.youtube.com/watch?v=l0eg2xuC9Ks)ideavi Автор
12.04.2024 11:26+1По п.1 тема раскрыта тут:
https://habr.com/ru/users/Asmodeux/publications/articles
BugM
12.04.2024 11:26+4То есть никакого опыта в разработке процессоров нет вообще. Может стоит пойти поработать в соответствующую сферу лет на 5-10? Узнать что люди делают, что делали, как и почему все это работает, как и почему большая часть смелых идей не работает.
ideavi Автор
12.04.2024 11:26Может стоит пойти поработать в соответствующую сферу лет на 5-10
Это плюс в нашей ситуации. Кто-то должен быть со свежим взглядом. Я регулярно смотрю в глаза человеку, кто проектировал процессоры, черпаю оттуда вдохновение. Он работает на два уровня выше, и эта статья не про дефекты разработки процессоров (они почти идеальны с учетом реалий), а про принципиально новую архитектуру построения полупроводниковых вычислителей.
BugM
12.04.2024 11:26+1Я тоже ничего не знаю о процессорах. Зато немного знаю про крупный серверный софт. Сфера совсем другая, но тоже сложная с кучей подводных камней и тоже с работающими и неработающими подходами. Человек со стороны который смотрит мне в глаза точно не сможет предложить ничего разумного в этой сфере. Он просто не в курсе что там как устроено и почему сделано именно так. Он даже не сможет спроектировать довольно типичный сервис с не менее типичными требованиями, куда уж там до принципиально новой архитектуры.
Нынче все стало настолько сложным что без минимум десятка лет опыта в сфере никто ничего разумного предложить не сможет. С опытом большая часть тоже не смогут, но как базовый фильтр пойдет.
ideavi Автор
12.04.2024 11:26Я кое-что знаю о процессорах, и программировал те из них, архитектуру которых ещё можно удержать в одной голове.
По теме: Ной был подневольным любителем, когда строил ковчег. Титаник строили профессионалы. Примерно так звучит притча.
У нас есть сотни человеко-лет опыта, на который мы можем опираться, есть конкретная задача и незашоренность. Иными словами, есть всё.
dsoastro
Все плохо, а как исправить решения нет. Вывод статьи - давайте объединимся и что-нибудь придумаем. Жаль времени на ее прочтение
ideavi Автор
Решение озвучено в общем, и, согласен, конкретики мало.
Вы прекрасно понимаете, насколько эта тема провокационная, поэтому к обсуждению конкретики хочется быть более готовым, и мы этим занимаемся.
Есть вполне оформленные мысли, которые будут защищены в узком кругу оппонентов в изложены в следующих статьях, чтобы вам было уже не жаль времени читать.
Glays
Решение заключается в поиске талантливых и работоспособных профессиональных программистов, которые уже сами разберутся как сделать чип с количеством "вычислителей" как у трёх RTX 4090 и напишут версию CUDA которая будет доступна даже простым пользователям?
ideavi Автор
Инициативная группа будет предлагать спорные и смелые идеи, которые будем все вместе разбирать, критиковать и симулировать. В этот раз проектирование будет вестись с нуля - с полупроводниковых элементов.
Glays
А под каким флагом должна объединиться эта ваша инициативная группа? Какой основой она будет отличаться от других групп?
Идея большого количества ядер или наличие специальных ядер не нова совсем. Чем проектирование с нуля лучше использования существующих наработок? Ведь даже если всё сложится удачно проектирование с нуля займёт время гораздо большее чем та же NVIDIA утроит количество ядер в существующих решениях. И с "законом" Мура и без.
ideavi Автор
Коллега, мы объединимся под флагом несогласных и предложим участникам несколько гипотез для критики с точки зрения возможностей существующей элементной базы самого низкого уровня.
Как я упоминал уже, тут не про количество ядер история, а про иную архитектуру. Например, есть у мозга ядра? Нет вроде.
Netguy
Вообще-то есть. Как минимум два. https://ru.wikipedia.org/wiki/Каллозотомия
Но возможно, что и больше.
ideavi Автор
Нас интересует максимум
lazbaphilipp
Это уже решенное решение. К сожалению, оно не подходит для современных процессов. Дело в том, что каждая отдельная задача/поток совершают операции последовательно. Это буквально то, что им нужно делать, иначе никак — сначала нужно вычислить А, и из него вычислить Б; не получится делать это параллельно.
Те задачи, которые хорошо считаются параллельно, и при этом им не хватает SIMD возможностей CPU, уже давно считаются на GPU.
ideavi Автор
GPU используется для игр и профессиональных или узких задач. Современные процессы, о которых здесь идет речь, также включают обычные персональные компьютеры, которые используются для серфинга в интернете и для подготовки документов. Прямо сейчас я насчитал 59 процессов только гугл-хрома, а общее количество процессов моего ноутбука гораздо больше, и они порождают потоки, которых вообще страшно представить сколько (посмотрел — 3300+). Всё это упирается в 4 физический ядра, которые должны быть достаточно мощными, чтобы в пике обработать все потоки без торможения. Вот на этом поле хотелось бы поработать — дешево выполнять всю эту работу.
lazbaphilipp
Эти процессы близки друг к другу, возможно даже используют какие-то общие переменные, да и выполняют они не что-то сложное, что имеет смысл разносить на разные ядра. Потому что разные ядра в связанных процессах сразу поднимают вопрос синхронизации памяти.
Вообще, кмк, если уж вы про эту проблему имели ввиду, то лучшим решением являются гетерогенные процессоры, где на "маленькие" ядра сгружается всякая бытовуха, и из довольно много (в новых интелах, вроде, 16 маленьких против 8 больших), а большие ядра работают редко но метко, так сказать - считают всякие фотошопы, физические модели и игры.
И даже так слишком увеличивать количество ядер неэффективно, так как у каждого ядра свой L1 кэш, а точный профиль даже простых задач нам до конца неизвестен.
ideavi Автор
Исследование идет не по пути увеличения количества ядер, а оно про распределение вычислений между агентами, которые ядром-то грех назвать. В статье использовано фото 4-хбитного процессора, а наши ядра будут в разы проще, если не на порядки.
lazbaphilipp
А кто будет раздавать задачи агентам и по какому критерию?
Как понять, нужны ли задаче FPU блоки, или предсказание переходов, например?
Кроме того, какой объем кэша должен быть у такого агента, будет ли он одинаковым у всех агентов или разным? Можно попробовать переложить задачу такого распределения на систему и ИИ какой-нибудь, однако, как мне кажется, такой подход только наоборот увеличит количество транзисторов у CPU, при этом с потерей в производительности. В целом, мне видится, что такая архитектура очень сильно упирается в скорость памяти и шин данных, а их ограничивает не техпроцесс, а физика длинных линий и скорость света.
К тому же стоит рассматривать верные сценарии использования - да, для браузера и офиса сойдёт и старенький i7-4xxx, или даже i5 (а мне его даже для разработки хватает), но как бы и в новых сериях есть аналоги. Какой-нибудь pentium последних поколений или ryzen3, особенно всяких U и HS серий (такие ставятся, например, в мини ПК). Однако обычно люди не запускают браузер и офис одновременно с играми. Почему некоторые люди для офиса покупают игровые процессоры - уже другой вопрос.
ideavi Автор
Прикладная задача требует фиксированное количество вычислений, если рассматривать её в идеальном мире. Мир ИТ не идеален, и задача сталкивается с прослойкой ОС, фреймворка и всяких библиотек, прежде чем будет выполнена посредством кода, который написал программист.
Все это делается во благо программиста, потому что мы с вами прямо заинтересованное лицо, финансово.
При этом конечное количество вычислений, которые решат вашу задачу, посильно даже процессору из 80-х годов. Он выполнит её за 0.2 секунды, а не за 0.2 микросекунды, но разницу вы на глаз никогда не заметите.
lazbaphilipp
Забавный момент, однако мы замечаем даже разницу между 0.2 и 0.4 мкс. Почему? Потому что таких задач много, и суммарно они дают очень хорошо видимые тормоза.
Кроме того, а про какие задачи речь? Калькулятор обычный? Наверно, конечно, если перейти обратно на дизайн сайтов эпохи web1.0, то их грузить будет гораздо проще, но это такое себе решение. В целом, современные браузеры представляют из себя структуру сложности уровня ядра ОС.
Современные задачи требуют больших мощностей, большой производительности на такт и высоких частот. Из-за большого объёма данных, которые надо обрабатывать в реальном времени. Самая распространенная задача такого рода - игры. Благодаря играм, высокопроизводительные процы являются распространенными, а соответственно дешёвыми, и я как радиоинженер могу позволить себе систему, которая считает модели за пару часов, а не за пару недель, и стоила она мне не несколько миллионов, а пару сотен тысяч.
К сожалению, плохо оптимизированный софт является прямым следствием дешёвого высокопроизводительного железа. Однако тут не новая архитектура нужна, а... Ну не знаю, ГОСТ какой-нибудь (не надо меня проклинать на годы диареи, пожалуйста, это просто шутка). И предлагаемая вами архитектура наоборот ухудшит ситуацию, так как писать код с высоким уровнем параллелизма тяжело, намного тяжелее эффективных околооднопоточных приложений - современная индустрия не простит вам кратного увеличения стоимости и(ли) времени разработки.
ideavi Автор
Если не давать пользователю писать код, то пролема решится сама собой. У нас в Интеграле это всё спрятано под капотом - вся рутинная работа делается автоматически, все стандартные действия написаны, и код собирается из готовых кусочков.
qw1
Что значит "не давать". У меня друг Вася пишет по вечерам игру мечты, и собирается опубликовать её в Стиме. И как вы ему собираетесь "не давать"?
Тут ничего не меняется, программирование переходит на уровень выше, на уровень сборки из кусочков. Из оптимальных кусочков несложно создать очень неоптимальное приложение.
ideavi Автор
В нашем случае мы специально выделили 3 или 4 ситуации, когда, например, запрос к базе из конструктора может быть неоптимален, и это чинится в пару кликов, например, меняется последовательность JOIN-ов таблиц.
qw1
О чём я и говорю, что разработка нужна под присмотром специалиста, который поймёт, что в этом месте 200 мс на запрос это многовато, и надо поменять порядок джойнов. Обычный же пользователь скажет "ну, 200 мс это мне подходит". И таких мест с микро-тормозами на 200 мс наделает 500 штук, после чего всё приложение проще переписать заново, чем вылавливать всех этих блох.
ideavi Автор
Из практики, с этим проблем нет особо. Неудачно делают 1 запрос из 100, и это заметно сразу, до того как его скопируют много раз.
yri066
В книге clr via c# в главе 26 доступно рассказывается про развитие многопроцессорных систем и как приложения начали использовать их преимущества с помощью потоков.
Также приложения могут выделять несколько потоков заранее для большей отзывчивости, но от сюда вытекает что заранее созданные потоки могут никак не использоваться в течении жизни приложения.
Vladicus
Да убейся ты со своими идеями. Это т. н. послойное программирование, где программист буквально вбивает всё, вплоть до порядка занесения значений в регистры, одновременно уточняя, что будет читаться минуя проц, в память, и что в этот момент будет передаваться на видюху (и что там будет считаться).
Да, даже на современной технике ты получишь минимум увеличение скорости на порядок. Скорее всего, на два, в некоторых случаях три порядка. Но какой ценой? Писать программу сложностью уровня "hello world" в течении двух недель? И при этом без малейшего права на ошибку? Ну, потому что где ты ошибся, ты вряд ли найдешь...
Может, чем так мучить прогеров, пересадить нас хотя б на ассемблер? Ну да, рекорды скорости будут поменьше, зато хотя бы при твоей жизни возможно сделают аналог десятой винды.)))
qw1
Там такая специфика, что все эти процессы и потоки не работают одновременно, а почти всё время спят. Но когда просыпаются, хотят выполниться очень быстро на очень мощном процессоре. Если вы просто переложите эти потоки на процессор 4004, без существенного изменения их кода, простейшие задачи браузера будут выполняться за годы, а не за секунды.
Ababaj
Для Вашего же понимания: где в списке ТОП500 будет Ваша реализация т.е. согласно тесту линпак, а не иными второстепенными тестами, проще, каков будет максимальный порядок решаемой СЛАУ!
yatanai
Если твоя цель была создать трафик на свою статью, у тебя получилось, тролина.
А если серьёзно, все эти думы о высоком это не понимание реальной позиции вещей. Если коротко, у тебя есть два варика всё исправить, организационный и архитектурный.
С первым всё просто, потоков много и они требуют разное количество ресурсов, в идеале железка должна содержать в себе несколько ядер разной микроархитектуры заточенные под разные задачи, условно как это сейчас делают intel, но можно и усложнить, добавив ещё более специализированные ядра и заточить логику работы ОС под эту фичу. (Даже для прерываний отдельные ядра делать, в идеале)
Второе это архитектура. Вот эти все риски ириски киски и прочие идеи = мусор. Архитектура должна быть максимально ёмкой на команду и при этом легко декодироваться. Сделать команды слишком сложными = нагрузка на декодер = ботлнек для команд на такт, сделать команды слишком простые = нагрузка на память. В идеале надо найти что-то по середине.
Всё остальное это специальные архитектуры под какие-то конкретные задачи. Даже GPU нельзя считать хорошим примером параллельных вычислений, ведь есть матричные ускорители которые дают на пару порядков больше flops, которые нынче NPU-хами стали.
Куда ты копаешь, юнец? Где там революцию устраивать собрался? Чо по Легаси, куда все эти тонны либ девать собрался?
MadLynx911
Тема настолько провокационная, что, отойдя от чисто технических сторон дела, вам просто никто не даст запустить ее на поток в случае успеха.
ideavi Автор
Это было первое, о чем меня предупредил трекер нашего стартапа, когда я рассказал про этот проект. Дадут, но есть нюансы.
cortl
Надо сделать две вещи:
Не гнаться за конвейерами. Они увеличивают ложность и стоимость процессоров на порядки, а производительность лишь в разы.
Декомпозировать библиотеки. Чтобы калькулятор не весил два гига.
ideavi Автор
Полностью согласен