OSDev

Я открываю эту тему для того, чтобы поговорить и обменяться мнениями с людьми, которые тоже приходили к выводу о необходимости разработки новой архитектуры для ЭВМ (имеется в виду архитектура на уровне команд, ISA). Факт открытия данной темы вовсе не означает, что лично я собираюсь разрабатывать такую архитектуру, хотя ряд пожеланий обязательно выскажу. Основная цель данной темы – провести беседу, которая нужна скорее лично мне по одним мне понятным причинам, но может оказаться полезной и для людей с похожими трудностями и мыслями.

Я приглашаю в эту тему, конечно, всех, однако в первую очередь людей серьёзных, которым не нужно объяснять, для чего пишется собственная «ещё одна» операционная система (далее ОС), новый компилятор или создаётся новая архитектура, почему язык C++ - плохой язык для реализации сложных, больших и крайне эффективных программ, но лучше него едва ли можно что-то предложить (я не застал времён, когда Fortran играл роль такого языка, поэтому о нём высказаться не смею, но догадываюсь, что там те же проблемы), и почему все современные популярные ОС, включая даже Linux, являются классическим образцом шлака и помоев, если смотреть с позиции человека, пытающегося заниматься научными исследованиями с применением высокопроизводительных вычислений и почему ровно то же самое следует говорить о популярных архитектурах ЭВМ (x86, ARM и пр.). Мне не нужен холивар, так как я уже наигрался в эти игры, поэтому если кто-то не согласен с этими тезисами, то я не советую тратить время на эту тему и даже дочитывать этот длинный пост. Вряд ли эта тема заинтересует тех, кто пишет свой продукт без чёткого понимания целей и задач, которые он будет решать, то есть тех, кто ещё играет в осеписательство в благородной, но единственной надежде глубже понять архитектуру компьютера или даже создать затем учебный ресурс. Этим людям я бы рекомендовал сначала наиграться, а потом вступать в беседу. Здесь я ищу внимания людей, имеющих ясную аргументацию своих разработок. Мотивация которых выросла не на пустом месте, а в силу необходимости, вытекающего из их глубокого жизненного опыта.

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

Итак, однажды мне пришло в голову создать собственную систему компьютерной алгебры (далее СКА или по англ. CAS) типа Maple, Mathematica, Matlab, Maxima и пр.. Повозившись немного, я пришёл к выводу, что система не должна работать с железом через ОС общего назначения или специализированную под какую-либо другую задачу, она сама должна стать ОС для себя. Повозившись и с этим, выяснилось, что процессоры-то чешуёвые (все, что мне были доступны), и для того чтобы эффективно решать свои задачи, нужно что-то совсем другое. Это кратко. А теперь то же самое подробно.

Сейчас, когда пишутся эти строки, мне 30 лет, я преподаю в высшей школе. Трудно однозначно сказать, в чём я считаю себя специалистом. Восемь-девять лет назад я закончил заниматься олимпиадным программированием - вовремя осознал, что в спорте есть некоторый предел, после которого полезное развитие превращается в «натаскивание». Этот этап моей жизни очень важен, так как именно благодаря спортивному программированию я научился кодировать практически любые алгоритмы весьма эффективно и совершенно разными способами. Но мне повезло больше, чем моим более талантливым соперникам по этому виду спорта - я вовремя «соскочил», не превращаясь в фанатика. Вместо этого я начал заниматься фундаментальной наукой, в частности, перечислительной комбинаторикой. В 2012 году успешно защитил кандидатскую диссертацию по направлению «01.01.09 Дискретная математика и математическая кибернетика». В рамках этой диссертации и некоторое время после защиты мне необходимо было решать труднорешаемые задачи (тут я пользуюсь терминологией из книги Гэри и Джонсона «Вычислительные машины и труднорешаемые задачи»). Задачи, которые для своего успешного решения требуют не просто чрезвычайно эффективных алгоритмов, но и их максимально качественной параллельной бинарной реализации. Это задачи класса #P. Мне удалось получить ряд новых результатов, которые не могли получить другие, более известные учёные, пытающиеся реализовать те же алгоритмы. Но почему так легко удалось рассчитать нужные значения, над получением которых специалисты безуспешно бились годами?

Как учёному, мне следовало бы взять какую-нибудь СКА и пытаться работать в ней, так как эти СКА, казалось бы, и разрабатываются для научных исследований. И правда, почему учёный, занятый, например, статистической механикой - а мои задачи из этой области - должен программировать что-то на низком уровне? Учёный из этой области должен сосредоточиться на методике получения результата, а не на искусстве программирования. Иначе это всё равно что заставлять строителя самому себе делать инструменты, прежде чем он приступит к своей работе, или печника делать себе кирпичи.

Поэтому западные коллеги и шли по классическому пути – брали популярные СКА и пытались в них что-то посчитать. Но, к сожалению, они либо не догадывались, что ни одна современная СКА не приближается по эффективности к даже наскоро сляпанной на коленках бинарной реализации алгоритма, либо знали, но сами запрограммировать не умели так же хорошо, как это сделает профессионал. Здесь мне и пригодилась олимпиадная подготовка, которой не было у тех западных исследователей. Я реализовал ими придуманные алгоритмы на C++/Assembler так, что они работали быстрее в десятки, сотни и даже тысячи раз, потребляя при этом на порядки меньше оперативной памяти, что и позволило получить новые результаты.

Я задумался: почему Maple, например, не может вывести линейное рекуррентное соотношение или производящую функцию порядком несколько сотен, а моя программа выводит подобные соотношения порядком несколько десятков тысяч? Почему Maple сжирает два с половиной десятка гигабайт оперативной памяти на пустом месте, когда моя программа укладывается в на порядок меньший объём для решения той же задачи?

Сказать, что разработчики Maple глупые люди – это будет ошибкой. Там работают (по крайней мере, раньше работали) профессионалы высокого класса, в этом я не сомневаюсь. Но постепенно Maple начал превращаться в монстра, в котором количество разных пакетов, делающих одно и тоже, начало расти из-за ошибок архитектуры (когда невозможно исправить один пакет, делают новый, а старый нужно оставить из-за обратной совместимости), а бездумное наращивание функционала доделало своё дело. Короче, Maple, превратился в такое же уродство, в которое превратилась на сегодня, например, архитектура x86-64. Почему я говорю про Maple? Всё просто, я проверил полтора десятка СКА и пришёл к выводу, что Maple на моих задачах лучше их всех. На втором месте оказались Mathematica и Maxima, но с таким громадным отрывом, что лучше не говорить здесь, чтобы не позорить данные продукты.

Следующий момент – параллельное программирование. Maple изначально не был рассчитан на работу в параллельном режиме, поэтому примочки, позволяющие распараллелить функцию, смотрятся там так же дебильно, как класс string в ранних версиях языка C++. Видно, что оно как будто просто скотчем примотано и держится кое-как. Кроме того, Maple нельзя запустить на вычислительном кластере, а очень бы хотелось.

Однако самая страшная ошибка руководителей проекта Maple была сделана тогда, когда они решили интерфейс выполнить на Java. Мало того, что каждый мегабайт был на счету, так теперь 300 Мб сжираются сразу при запуске Java-морды, а тормозит она настолько безбожно, что мои производящие функции, имеющие размер в несколько миллионов знаков, вообще не загружались туда (даже в режиме запрета вывода данных на экран). Итак, стараясь идти в ногу со временем, идеологи Maple его просто похоронили в глазах тех людей, которым по роду деятельности нужно выжимать из компьютера максимум.

Что мне остаётся делать, когда формула, занимающая несколько мегабайт и записанная в файл, после считывания Мэплом сразу превращается в несколькосотмегабайтное чудовище? А что остаётся делать, когда вдруг при выполнении сложнейших расчётов Maple запускает сборку мусора и всё умирает из-за того, что сборщик мусора то ли не может выделить себе память, то ли просто не может собрать мусор, а система уходит в swap и всё умирает на несколько часов или даже дней? Правильно, плюнуть на Maple. Вот потому и пришлось заниматься программированием на связке C++/Assembler, то есть заниматься весьма абстрактными исследованиями с помощью инструментов весьма низкого уровня. Иными словами, чтобы забить гвоздь, мне нужно было сначала выплавить железный молоток и вырезать ему деревянную ручку.

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

Я понял, что нужен инструмент, который был бы близок к железу, но при этом имел бы высокоуровневый интерфейс. Что-то компромиссное между интерпретатором и компилятором. Некая оболочка, которая позволяет вводить команды как при работе с интерпретатором, но сами команды вызывали бы уже заранее скомпилированные подпрограммы. При этом всё это должно работать как можно ближе к железу, минуя функции операционной системы и масштабироваться на большое число ядер или процессоров. Вот так: включился компьютер, перешёл в 64-битовый режим, определил все ядра, затем система предлагает вводить команды. Не нужна никакая многозадачность – каждое ядро работает на полную мощность своих вычислительных команд и по сути не нужны никакие прерывания, кроме некоторых немаскируемых. Для этого не нужна полноценная ОС в привычном нам смысле. То есть СКА и есть ОС. Но беда в том, что популярные архитектуры вычислительной машины настолько убоги, что особого выигрыша такой подход не даст.

Единственный плюс остаётся в том, что имеется независимость от развивающихся своим путём популярных операционных систем. Я не верю, что монстры вроде Windows или Linux, будучи изначально плохо спроектированными, позволят безболезненно развивать такую СКА. Любое телодвижение разработчиков таких ОС будет оставлять след на работе СКА и придётся считаться даже с самыми идиотскими решениями (то же относится ко всем производным и подражателям в виде KolibriOS, Android и пр.) Система, о которой я говорю, должна быть сама в себе, потому что я за последние 10 лет сильно разочаровался в здравомыслии крупных осеписателей. (Я не имею в виду, что там одни недальновидные люди, но, во-первых, их много, и, во-вторых, они идут неправильной дорогой, гоняясь за универсальностью во всём, когда нужно придерживаться стратегии модульности).

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

Мне удалось поработать на двух кластерах: на одном было 80 ядер, на другом несколько тысяч и... я был глубоко разочарован в обоих. Мой домашний компьютер (Core i7 3960X @3,3 GHz, 24 Gb DDR3-1333), в котором 6 ядер (12 виртуальных) как щенка уделывал 80-ядерный кластер (10 узлов, 2xQuad-Core Intel Xeon 5430 2,66 GHz, 4 Gb DDR2-667 на каждом узле). Как такое может быть? Кластер – большой, а процессор у меня дома – маленький. Пока ядра кластера обмениваются сообщениями, проходит много времени. Я не знаю, чем руководствовались менеджеры, заказывающие такую сборку, но более глупого решения, чем поставить на один узел всего 4 Гб медленной памяти, обслуживающей 8 ядер, я бы не смог и выдумать. Но даже если так, то сборка настолько плохая, что единственная причина, по которой мне пришлось пользоваться этим игрушечным калькулятором, так это чтобы дома компьютер месяцами не гонять. Он шумит, спать мешает. Что касается кластера, на котором несколько тысяч ядер, там была другая проблема: нельзя было запустить задачу больше чем на сутки, а сохранить промежуточные данные невозможно в связи с наложенными на пользователей ограничениями. Кроме того, когда ядер слишком много, программа начинает работать медленнее (обмен сообщениями жрёт всё время).

Я быстро понял проблему архитектуры x86 в плане применимости её к задачам моего типа. Да, никто не спорит, что это мощная архитектура, но для того, чтобы «пробивать» перечислительные задачи не нужно иметь столько команд. У нас всего 4 арифметических операции, да условные переходы и доступ к памяти, а работать на x86 архитектуре – это всё равно что ездить по дому на машине. Слишком мощно. Казалось бы, может поможет GPU? Нет, пробовал, не помогает. На видеокартах мало оперативной памяти, а гонять память с карты и на карту слишком долго, кроме того, сама архитектура GPU не вполне позволяет удачно распараллелить мои алгоритмы, а условные переходы слишком сильно дробят warp'ы, в результате чего эффективность падает.

Ещё одна проблема: почти все задачи оперируют длинными числами, доходит до нескольких миллионов бит. Я не знаю популярных архитектур, которые были бы оптимизированы для работы с длинными числами. Да, поскольку длина числа может быть любой, невозможно вот так просто взять и создать регистр в 640 миллионов бит, считая, что его «всем хватит». Не хватит : ) И оперативной памяти для манипуляции с набором таких чисел тоже не хватит. По этой причине вычисления обычно выполняют в факторкольце Z/(p), а ответ восстанавливают по Китайской теореме об остатках. То есть нужно несколько раз (на практике несколько сотен тысяч раз) запустить программу с разными значениями p. Было бы здорово, чтобы в процессоре имелась возможность аппаратно проводить вычисления по модулю. Например, есть специальный регистр (или несколько таких), в котором все вычисления автоматически приводятся по модулю заданного в каком-то другом регистре простого числа. А операция деления автоматически превращается в умножение на обратный элемент. Вычисление обратного элемента также было бы удобно выполнять какой-то одной операцией. Было бы куда более ценным создать сотни регистров с подобной возможностью, а поддержку «лишних» команд убрать за ненадобностью.

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

Вот мы подходим к основному тезису, определяющему философскую базу новой архитектуры:

Одна задача – одна архитектура.

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

Один класс алгоритмов – одна архитектура.

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

Означает ли это, что мы отказываемся от универсальности? И да, и нет. Следует отказаться от универсальности архитектуры в научных расчётах и создать ряд архитектур, каждая из которых предназначена для одного класса алгоритмов. При этом все эти архитектуры будут подчиняться некоему единому стандарту и, возможно даже, будет некая единая материнская плата, к которой, подобно модулям, можно будет подсоединять нужные процессоры, и на которой изначально находится только один процессор общего назначения для типичных задач (это может быть даже x86 вариация). Естественно, нужен стандарт на разработку всех таких модулей. Например, мне нужен процессорный модуль, в котором, помимо очевидных необходимых операций взаимодействия с внешним миром, будет:

• только 4 арифметические операции с целыми числами.
• как можно более высокая разрядность регистров
• встроен генератор простых чисел, согласованных по размеру с разрядностью регистров
• организована такая арифметика, в которой операции могут работать как в традиционном режиме «с переполнением», так и в классе вычетов Z/pZ.
• аппаратная поддержка некоторых функций теории чисел (НОД, функция Эйлера, и т. д.).
• обеспечена суперскалярность (но не VLIW) в том смысле, что независимые по данным команды выполняются (почти) одновременно, либо какой-то другой класс параллельности выполнения независимых во всех смыслах команд.

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

К сожалению, на данный момент я больше не занимаюсь той наукой, которой посвящена моя диссертация. Чиновники от науки, когда поняли, что у меня есть своё мнение о развитии научного знания и что я хорошо владею основами философии науки, перекрыли мне кислород и обошлись со мной, мягко говоря, по-свински. Слив самый сильный научный коллектив нашего вуза, они лет на 5-7 увеличили своё и так сильное отставание в научной сфере, но зато неплохо распилили денежки. Сказав им «до свидания» в более богатых лексических формах, я нашёл другую работу, оставаясь параллельно преподавателем на полставки на всякий случай. Государственную академическую науку я бросил, но размышления о том, как упростить жизнь учёным, остались.

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

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

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

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

Принцип простоты. Система не должна быть сложной, но должна брать лучшее от RISC и CISC архитектур. Так, сложная команда не может иметь произвольную длину, либо может, но эта длина заранее известна процессору до начала декодирования. Например, sum4regs r0, r1, r2, r3, [r8] содержит 4 операнда для сложения (вместо «4» может быть любое другое число) и 5-й параметр для указания того, куда деть результат. Команда как бы заранее говорит процессору, что будет сложено 4 числа. Процессор их складывает, а затем видит, что результат нужно положить по адресу [r8]. Это просто идея, не нужно думать, что я предлагаю реализовать её именно так, пример взят с потолка.

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

[ Представьте, приходите вы в магазин, и говорите: «мне, пожалуйста, модуль линейной алгебры и два модуля дифференциальных уравнений» ]

Таким образом, я вижу некую смутно-интуитивную идею вычислительной среды, в которой процессор, компилятор и ОС-СКА являются элементами единой идеологии и развиваются одновременно, согласованно друг с другом и со своей философией развития.

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

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

Я разработкой архитектур не занимаюсь, просто совет обывателя. До выпуска вычислительного комплекса у вас вряд-ли дело дойдёт, поэтому советую ориентироваться на разработку своих карт расширения, вставляемые в слоты PCI-Express. На современных мат. платах их доходит до 8 штук. Смотрите например как работает математический блок PhysX на видеокарте GeForce.

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

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

Приветствую на нашей земле. Давно слежу за вашей скажем так научной-олимпиадной деятельностью.

А ОС они давно модульная. И вы можете собрать всё что нужно. Или оставить такую сборку за автоматикой.
На самом деле ОС обычно ест мало процессорных ресурсов менее 0.001. Поэтому не думаю что для ваших задач это что-то изменит.

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

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

Да и процессоры есть специализированные. А вот с разработкой собственных сопроцессоров не всё так хорошо. Просто так они прирост не дадут.

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



Согласитесь, что скорость будет выше, если разрядность регистров будет не 64 бита, а 1024, например. Или я не прав? Неплохо было бы иметь строковые команды (префикс rep в x86), которые бегут по двум массивам чисел и складывают их с переносом. Я об этом - реализовывать команды не базовым набором инструкций через микрокод, а чтобы это были как будто RISC- команды делающие то, что от них хотят, как бы одним действием. Там я говорил про сложение чисел по модулю: не нужно отдельно складывать и брать по модулю, нужно сразу сложить и тут же получить ответ по модулю одной командой.



Действительно, мои претензии к ОС сформулированы плохо. Я бы даже сказал, что они во многом не состоятельны в таком виде. Если делать новую архитектуру, то ясно, что должна быть новая ОС для неё. Но если даже не делать: мне не нужна псевдомногозадачность, система не должна жрать лишнюю память как Windows 7, например, мне по сути не нужна даже защита через привилегии на уровне архитектуры, да и менеджер памяти обычно приходится писать свой. Если взять не популярную ОС, а какую-то малоизвестную, то где гарантия, что её будут поддерживать её создатели? Я не знаю, как выразить свою претензию более понятно, но на смутно-интуитивном уровне мне кажется, что в современных популярных системах много лишнего, отчасти эта претензия касается и архитектуры процессора. Далее, я не хочу зависеть от создателей ОС, цели которых обычно идут вразрез с моими. Мне нужна система для научных расчётов, направления развития которой диктуется развитием науки, а не пожеланиями пользователей к интерфейсу. В качестве примера я привел Maple, точнее, то уродство, к которому пришли его создатели, двигаясь в том же направлении, в котором двигаются популярные ОСи.

Ещё я считаю, что ОС должна быть сразу кластерной. Сейчас роль ОС на кластерах играет обычно либо Linux, либо Windows. Причём во втором случае кластер настолько безбожно тормозит, что проще взять канцелярский калькулятор - толку будет больше. В случае с Linux ситуация куда лучше, но вот я однажды, запустил команду, которая пишет все запущенные процессы на каждом узле. Оказалось, что помимо моей программы там висела куча демонов, причём жрали они порядочно, где-то полпроцента-процент от мощности, да ещё и хапали память, каждый мегабайт которой был на счету. Нафига? Я считаю, что практика современного осеписательства порочна в своей основе. Принцип универсальности должен быть заменён принципом модульности и минимальности. Тут я говорю только о научных расчётах! В случае, когда мне нужно посмотреть фильм, я вполне доволен Windows 7, жадно сожравшей у меня несколько десятков гигабайт на диске : )

Я согласен лишь отчасти, более подробно в предыдущем посте.


Проблема не с задержками между ядрами, а с задержками между узлами кластера. Контроллер не справляется с пересылкой терабайт информации туда-сюда.


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


Можно согласиться, однако далеко не всегда целесообразно из кожи вон лезть, чтобы придумать схему вычисления с возможностью 100%-го распараллеливания, равносильную по сложности защите 2-3 докторских диссертаций. Часто проще попытаться создать кластер с максимально большим числом ядер на одном узле и быстрой общей памятью. Но такие мало кто себе делает.

1024 быстрее 64 бит. Но до тех пор пока не упрёшься в шину. А в шину вы упрётесь. Так как заранее неизвестно какой её делать. ДА и трудно физически сделать её большой. Поэтому в видео картах она кольцевая, что-бы хоть как-то повысить её ширину.
Команду такую неплохо иметь. Но когда вы начнёте проектировать вы поймёте что не всё так просто.
- Для справки.
В i7 есть хитрый кэш который фактически превращает связку adc + loop в одну команду.
В процессорах от TI к примеру умножение сделано отдельным сопроцессором с DMA.
- Конец справки.
Шина общая не годится. Нужно больше памяти и так чтобы это команда копировала данные из одного чипа в другой. И не блокировала общую шину. В процессорах от TI мало сопроцессоров 1-2 да и обчёлся поэтому шину никто не блокирует.
Получается нужен потоковый процессор.
Недостатки потокового процессора средние(скорее короткие) циклы.

Совмещать или делать гибридные устройства. Но проблема в пересылке из одного устройства в другое. Транслирования команд.
Да и получаются такие устройства дорогими.
Короче говоря замкнутый круг.


Золотое правило программиста. Проигрываешь в памяти выигрываешь в скорости. И наоборот.
Конечно есть лишнее, но кто-же знает что потребуется в следующей момент? Кому-то важнее что-бы планирование происходила на каждом ядре самостоятельно. А кто-то хочет памяти по больше. Кому-то важна знать температуру и регулировать нагруку, а у кого-то свои потребности. Вот и приходится съемщикам держать всё так как клиентов у них много. У кого-то лучше в одной области у кого-то в другой. Это нормальное явление.


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

pavia,
Спасибо за справку.

К сожалению, я убеждён, что общего единого подхода для распараллеливания не существует в рамках современной архитектуры ЭВМ и нашей науки в целом. Откуда такая уверенность? Из следующей аналогии. Я имею весьма большой опыт решения однотипных труднорешаемых задач перечислительной комбинаторики. Не смотря на то, что задачи однотипны, каждая решается индивидуальным подходом. Я видел попытки разных учёных создать "универсальный решатель", которые решает любую задачу определённого класса. К сожалению, у них у всех получился поклёп, который лично мне было бы даже стыдно показывать. Все более менее нормальные решения были успешными только в том случае, когда они решали одну конкретную задачу. Аналогично я считаю, что параллелить можно только одну задачу каким-то особым для неё подходящим способом. Другую нужно параллелить по-другому. Либо изобретать принципиально другую архитектуру ЭВМ или даже другую математику. В общем, идея единого распараллеливателя так же утопична, как идея автоматического переводчика текста с одного естественного языка на другой, распознавателя музыки (перевод в ноты) или создание искусственного интеллекта методом обучающихся нейронных сетей. Почти полувековой опыт не дал существенных результатов в этих областях и я не думаю, что что-то изменится в ближайшие полвека, поскольку сама научная база здесь видится мне чрезвычайно ущербной в своей основе. Это другой разговор из области философии науки.

Лично я вообще не вижу возможности создать универсальную архитектуру "на все случаи жизни". Думается, любая архитектура, подходящая для любых задач, будет более-менее одинаково плохо подходить для этих самых "любых задач". Что же конкретного вида задач, решаемых автором темы, то это -- явно узкоспециализированная область. Если такого рода задачи имеют достаточно широкую практическую направленность (пускай и в узких кругах), для их решения есть смысл создавать специализированную архитектуру. Если же это -- теоретические исследования в чистом виде, не имеющие никакого практического смысла в сколько-нибудь обозримой перспективе, то, как по мне, овчинка выделки не стоит. Понятно, что я не обладаю необходимыми познаниями, чтобы судить о полезности и перспективности подобного вида работ.

Для задач же "общего назначения", будь то офисные программы, бизнес-приложения или "домашний" софт (игры, медиаплееры и т.д.), предлагаемый автором "мегаразрядный" процессор абсолютно бесполезен. Конечно, решать эти задачи можно и на нём, но это неэффективно и в плане производительности (огромная разрядность будет невостребованной, и сожранные ею ресурсы лучше пустить на что-то другое), и в плане энергопотребления (биты есть, а ничего полезного не хранят -- однако энергию жрут). Любые современные более-менее известные и популярные архитектуры (IA-32, ARM, MIPS, PowerPC, SPARC и т.д.) для задач общего назначения подходят лучше -- что, безусловно, не отменяет того факта, что они глубоко порочны по самим идеям, положенным в их основу.

Наконец, пару слов про ОС. Автор глубоко заблуждается, думая, что ОС как таковая создаёт проблемы для решения его задач. Проблемы создаются не самой абстрактной системой, а кучей бесполезных "свистоперделок", которыми набиты современные версии систем, а также принципиально порочным подходом к созданию прикладных задач, особенно требующих высокой производительности. Собственно, автор сам это ярко показал на примере Maple. Взваливать на прикладную по сути программу (например, "решатель" описанных автором задач) сугубо системные функции (управление вводом-выводом и т.п.) -- откровенно порочный путь. На самом деле, нужно иметь эффективную ОС, пожирающую минимум ресурсов и предоставляющую максимум реально полезного функционала, и на ней уже делать прикладные программы.

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

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

Далее, мне кажется, Вам не вполне удалось понять меня правильно.


Я предложил не мегаразрядный процессор общего назначения, а мегаразрядный процессорный модуль, который, конечно, никому нафиг не нужен, кроме тех, кому позарез нужна длинная арифметика. Делаем модуль, содержащий 100500 здоровенных регистров операцию сложения с переносом для них организуем. Базовый же процессор, к которому подключён этот мегаразрядный модуль, вполне может быть 64-битовым.


Я не знаю, может это не не слишком понятно из моего многостраничного опуса, но я имел в виду, что проблемы создаёт популярная ОС, а не ОС вообще. Я перепробовал разные Виндоусы и Линуксы, ничего не подходит. Пытаться сделать СКА на непопулярных системах тоже трудно по двум причинам - они либо мало чем отличаются от популярных по своей природе, либо нет гарантии, что их будут поддерживать. Вот, например, какой-нибудь DOS-64 для кластера существует? Я не видел : ( Потому-то и пришёл к выводу, что систему придётся писать самому. А чтобы не было в ней ничего лишнего, как Вы верно заметили, нужно чтобы эта СКА и была сама себе операционной системой. По сути там нужно-то: командная строка, минимальный интерфейс (если захочется выводить небольшие формулы, например, как в TeX), да базовые команды ввода-вывода и работы с диском. За основу можно было бы взять тот же BareMetalOS, но, как я и ожидал, энтузиазм у его создателя как-то уменьшился за последние два года, он даже исходники спрятал недавно.