OSDev

для всех
Текущее время: 17 дек 2017, 18:33

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: 30 ноя 2014, 22:08 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Himik писал(а):
Возможно, что в качестве числодробилки подойдёт Minix-3 - микроядерная система, концепция которой минимализм и модульность. На многопроцессорных компьютерах микроядерные системы рулят.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 30 ноя 2014, 23:05 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Zealint писал(а):
Да, всё было бы было терпимо, если бы она была однозадачной, но масштабировалась бы на сотню-другую 64-битовых ядер. А там только IA-32. И потом, что-то мне не нравится её "юниксовость" (но это не решающий фактор отказа, а просто эмоциональный, в догонку, так сказать). А ещё меня смущает, что она позиционируется как учебная, а значит будет со временем напичкана лишним мусором в угоду благородной цели обучения студентов, как это произошло с Linux. Короче, она не подходит уже по первой указанной причине.
Не знал, что нет 64-битной версии, но уверен, что технически это решаемо. Всё лучше, чем писать нечто с нуля. Но можно поискать и готовые подобные ОС, а так же необычные VxWorks, Plan-9, OS-9, Integrity, LynxOS.
Zealint писал(а):
Там много фишек, направленных на повышение надёжности безотказной работы, но нет ничего, что гарантировало бы эффективность при работе с гигантскими объёмами оперативной памяти и масштабируемость на тысячи и десятки тысяч дымящихся от перенапряжения процессоров
Не вижу здесь противоречий.
Zealint писал(а):
Система, которая нужна мне, должна быть нацелена на решение научных, а не повседневных задач.
В принципе, вашим критериям соответствуют так называемые "серверные" виды ОС. Каждая система выпускается в "настольной" и "серверной" конфигурации (я не про Minix). В серверную конфигурацию по определению не попадает ни чего из настольных свисто-перделок, и они как правило имеют средства тонкой настройки как на этапе установки, так и в эксплуатации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 30 ноя 2014, 23:25 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Zealint писал(а):
Все более менее нормальные решения были успешными только в том случае, когда они решали одну конкретную задачу. Аналогично я считаю, что параллелить можно только одну задачу каким-то особым для неё подходящим способом. Другую нужно параллелить по-другому.

В целом согласен, но могу предположить, что задача распараллеливания может (должна?) решаться за счет модульности.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 01:58 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Zealint писал(а):
Да, всё было бы было терпимо, если бы она была однозадачной, но масштабировалась бы на сотню-другую 64-битовых ядер


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

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

В общем, многозадачность вообще не является проблемой в плане обеспечения высокой производительности системы. Проблемой является куча свистоперделок, а также низкое качество кодирования системы (про проектирование вообще молчу, хотя автор не прав, утверждая, что Винда плохо спроектирована: она в своё время была вполне нормально спроектирована, просто это было это в 1980-х, а с тех пор много воды утекло -- и много костылей приделано для удовлетворения новых требований, которых изначально не возинкало).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 08:13 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Я нахожу не совсем удачным направление беседы. Речь изначально идёт об архитектуре ЭВМ, тогда как мы начинаем обсуждать ОС. Я согласен, что мне может подойти уже существующая ОС, но обозначил критерии, которым ни одна из известных мне систем пока не удовлетворяет.

Himik писал(а):
Но можно поискать и готовые подобные ОС, а так же необычные VxWorks, Plan-9, OS-9, Integrity, LynxOS.

Можно, если кто-то даст гарантию, что они масштабируются без проблем на тысячи ядер и будут поддерживаться их разработчиками. Вот, например, Plan-9, из языков программирования, что на ней доступны, нет C++ и порядочного Assembler'а. Мне писать в техподдержку и требовать портировать компилятор для C++11 и какого-нибудь fasm, yasm? Когда они это сделают, будут ли поддерживать и вообще, когда вышла последняя версия, я так и не смог найти. Я пересмотрел разные системы, везде что-нибудь да плохо (именно для моих целей).

Himik писал(а):
Zealint писал(а):
Там много фишек, направленных на повышение надёжности безотказной работы, но нет ничего, что гарантировало бы эффективность при работе с гигантскими объёмами оперативной памяти и масштабируемость на тысячи и десятки тысяч дымящихся от перенапряжения процессоров

Не вижу здесь противоречий.

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

Himik писал(а):
В принципе, вашим критериям соответствуют так называемые "серверные" виды ОС. Каждая система выпускается в "настольной" и "серверной" конфигурации (я не про Minix). В серверную конфигурацию по определению не попадает ни чего из настольных свисто-перделок, и они как правило имеют средства тонкой настройки как на этапе установки, так и в эксплуатации.

К сожалению, это не так. Я уже приводил пример, когда на кластер поставили Windows (серверную). Получилась такая лажа, что я с этого кластера тут же ушёл.

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

В моей практике есть случаи, когда замена алгоритма позволяла увеличить эффективность распараллеливания на десятки тысяч процентов.

SII писал(а):
Извините, но однозадачная система по определению работает лишь на одном процессоре (одном ядре). Чтобы задействовать несколько процессоров, нужна именно многозадачная система. Ну а запускать на ней разные программы или одну, исполняемую в несколько потоков -- это уже выбор пользователя.

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

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

Цитата:
(про проектирование вообще молчу, хотя автор не прав, утверждая, что Винда плохо спроектирована: она в своё время была вполне нормально спроектирована, просто это было это в 1980-х, а с тех пор много воды утекло -- и много костылей приделано для удовлетворения новых требований, которых изначально не возинкало)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 14:14 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Zealint писал(а):
Я имею в виду, что не нужна псевдомногозадачность. Многозадачность по одному из моих принципов должна быть чистой, настоящей, то есть обеспечиваться не квантованием, а числом ядер


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

Цитата:
В идеале все сервисы должны крутиться на каких-то слабеньких ядрах, которых много (сотни и больше), а расчёты должны проводиться на мощных процессорных модулях


Уже было: 1960-е годы, машины CDC. ЦП были 60-разрядными, а их система команд прилично смахивала на системы команд современных процессоров обработки сигналов (DSP). ОС же крутилась на 12-разрядных процессорах, которые управляли центральным, выполняли ввод-вывод и всё такое. В результате почти всё время на ЦП выполнялись прикладные задачи. Кстати, если не изменяет память, именно эти машины стали первыми в истории, где была реализована суперскалярность (выполнение нескольких инструкций одним процессором одновременно).

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


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

Цитата:
Хорошо, допустим, что до моего рождения Винда была хорошо спроектирована для тех задач, что решались тогда. Сейчас задачи другие и тот проект под современные реалии не подходит


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

Цитата:
На их месте следовало бы выбросить старую Винду и сделать новую, заложив в проект изначально всё необходимое для пользователей сейчас, а не приклеивать это скотчем сбоку.


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 14:35 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Возможно вам пригодятся сопроцессоры MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2 - для параллельной обработки нескольких массивов данных,
а так же библиотеки для их использования
http://gmplib.org --- https://en.wikipedia.org/wiki/GNU_Multi ... ic_Library
http://www.multiprecision.org
http://www.mpfr.org --- https://en.wikipedia.org/wiki/GNU_MPFR
http://bugseng.com/products/ppl

Касательно опять же использования готовой ОС (в последний раз). Есть ещё FreeBSD, которая всё время была пригодной только для серверов, ни каких "игрушек".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 18:46 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
SII писал(а):
Уже было:

Ну так очень хорошо : ) Я в данном случае не претендую на что-то новое, ибо мои познания в архитектуре пока ограничиваются лишь общим пониманием вещей.

SII писал(а):
К примеру, в приведённом Вами случае есть резон ставить данной программе очень высокий приоритет, чтоб её с процессора система согнала только в случае появления действительно срочной работы.

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

Я, в целом, согласен с замечаниями, у меня нет весомого повода создавать свою ОС с нуля, если я собирался делать это для популярных архитектур ЭВМ. Действительно, ускорение в разы она не даст. Моя основная претензия в этой теме к архитектуре популярных процессоров. Именно её я считаю крайне неэффективной для моих научных расчётов.

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

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

По своему научному опыту могу сказать, что это не только моя проблема. Многие страдают от отсутствия специализированного железа. Чтобы удовлетворить запросы разных учёных из разных областей, я и предложил идею модульной архитектуры с одним процессором общего назначения и возможностью подключать сопроцессоры узкоспециализированного назначения. То есть эта система, я Вас уверяю, будет нужна многим исследователям, кому нужны высокие мощности. То есть речь не идет конкретно о моих задачах. Я считаю, что нечто подобное или близкое к этому предложат и другие специалисты по HPC (высокопроизводительным вычислениям).

Himik писал(а):
Есть ещё FreeBSD, которая всё время была пригодной только для серверов, ни каких "игрушек".

Она не жирная? Там по умолчанию GCC установлен, а это поклёп тот ещё. Мы как-то издевались над ним (не помню, над какой версией), делали программы, которые он, сожрав всю оперативку, не смог скомпилировать. Intel C++ же эти программы компилировал за несколько секунд. Но компилятор Intel для FreeBSD я не знаю, есть ли. Есть ли гарантия, что эта система "ровно" встанет на кластер из нескольких тысяч узлов?

Himik писал(а):
Возможно вам пригодятся сопроцессоры MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2 - для параллельной обработки нескольких массивов данных,
а так же библиотеки для их использования

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 23:00 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Zealint писал(а):
Она не жирная? Там по умолчанию GCC установлен, а это поклёп тот ещё. Мы как-то издевались над ним (не помню, над какой версией), делали программы, которые он, сожрав всю оперативку, не смог скомпилировать. Intel C++ же эти программы компилировал за несколько секунд. Но компилятор Intel для FreeBSD я не знаю, есть ли. Есть ли гарантия, что эта система "ровно" встанет на кластер из нескольких тысяч узлов?

Ну при чём здесь GCC, он ведь работает только во время компиляции. И что за мощные сервера такие, что на GCC не хватает памяти, требуется всего 256МБ. Хотя, может вы имели ввиду рантайм-библиотеку GLIBC, то здесь есть варианты - многие ОС вместо неё используют оптимизированную версию EGLIBC, такие как Debian, Fedora, Suse, Slackware, FreeBSD, Ubuntu. Недавно было объявлено, что проект EGLIBC будет объединён с GLIBC, чтобы не распылять усилия.

2. Я полагаю, гарантии качества вам могут дать только производители ОС.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 01 дек 2014, 23:57 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
Zealint писал(а):
Поэтому западные коллеги и шли по классическому пути – брали популярные СКА и пытались в них что-то посчитать. Но, к сожалению, они либо не догадывались, что ни одна современная СКА не приближается по эффективности к даже наскоро сляпанной на коленках бинарной реализации алгоритма, либо знали, но сами запрограммировать не умели так же хорошо, как это сделает профессионал. Здесь мне и пригодилась олимпиадная подготовка, которой не было у тех западных исследователей. Я реализовал ими придуманные алгоритмы на C++/Assembler так, что они работали быстрее в десятки, сотни и даже тысячи раз, потребляя при этом на порядки меньше оперативной памяти, что и позволило получить новые результаты.

Лет 15-20 тому назад я интенсивно занимался нейростями (было очень популярное направление и многие ими не на шутку загорелись), и пришёл к аналогичному выводу касательно СКА. В частности, я использовал для своей работы Matlab. Мне нужно было обучать нейросеть, но прямолинейные методы обучения даже относительно небольшой нейросети на большой выборке данных могло занимать совершенно невозможное количество времени. Использование алгоритма Левенберга-Марквардта в Матлабе позволяло сократить обучение до нескольких дней прогона ПК. Каково же было моё удивление, когда ручная реализация алгоритма Левенберга-Марквардта на С++ укладывалась по времени на той же выборке примерно в час-два работы!

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

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

Zealint писал(а):
Я понял, что нужен инструмент, который был бы близок к железу, но при этом имел бы высокоуровневый интерфейс. Что-то компромиссное между интерпретатором и компилятором. Некая оболочка, которая позволяет вводить команды как при работе с интерпретатором, но сами команды вызывали бы уже заранее скомпилированные подпрограммы.

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

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

То, что вы сейчас написали, в общем-то и является отличительными чертами хорошей ОС, а никак не отсутствия ОС. Операционная система должна перевести процессор в 64-битный режим (то, что вам надо), определить все ядра, всю доступную память и по максимуму предоставить приложению все имеющиеся ресурсы. Многозадачность в данном контексте означает не кучу запущенных сервисов, которые толкаются локтями, а возможность запустить несколько процессов и (что важно!) - потоков. Без поддержки многопоточности ваша программа не сможет задействовать параллельную работу на нескольких ядрах и разные потоки не смогут обмениваться данными. Без ОС нельзя, так как она выполняет чрезвычайно важные функции - абстрагирует существующее железо и предоставляет возможности ввода/ывода. Без абстрагирования вам придётся самому писать все драйверы устройств и вы быстро повеситесь, даже всего лишь попытавшись вывести на дисплей "Hello, World!". А без ввода/вывода потребуется, например, самому писать драйверы файловых систем (ведь не будете же писать данные посекторно) и стек протоколов TCP/IP (для передачи ваших данных по сети с кластера на ваш ПК). Всё это - как раз прямые функции ОС. Другое дело, что настольные ОС больше ориентированы на обилие свистоперделок, а не на HPC (high performance computing).

Zealint писал(а):
Мне удалось поработать на двух кластерах: на одном было 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 ядер, я бы не смог и выдумать.

Судя по конфигурации, 80-ядерный кластер не первой свежести. Я могу сказать, что выбор конфигурации - ответственный момент и стоит его учитывать до запуска расчётов. Дело в том, что память - не дешёвый ресурс и разработчики кластера (или сервера) часто вынуждены идти на компромисс: поставишь мало памяти - не хватит, много - выкинешь деньги зря. Особенно это характерно для суперкомпьютеров, поэтому узлы СК часто имеют разную конфигурацию и задача решается на тех узлах, которые подходят максимально хорошо. Тут не стоит винить создателей кластера, - вероятно, во время создания память стоила дорого, а 4ГБ на узел вполне хватало для конкретных расчётов.

Zealint писал(а):
Я быстро понял проблему архитектуры x86 в плане применимости её к задачам моего типа. Да, никто не спорит, что это мощная архитектура, но для того, чтобы «пробивать» перечислительные задачи не нужно иметь столько команд. У нас всего 4 арифметических операции, да условные переходы и доступ к памяти, а работать на x86 архитектуре – это всё равно что ездить по дому на машине. Слишком мощно.

Судя по описанию, вам подошёл бы RISC-процессор, - операций мало, ничего лишнего, но есть всё, что вам необходимо. Ошибка в том, что на самом деле скорость выполнения программ не коррелирует с набором инструкций. Даже если речь идёт всего-лишь о 4 арифместических операциях, условных переходах и доступе к памяти! В данном случае "слишком мощно" быть не может, ведь вам нужна максимальная скорость выполнения.

Zealint писал(а):
Ещё одна проблема: почти все задачи оперируют длинными числами, доходит до нескольких миллионов бит. Я не знаю популярных архитектур, которые были бы оптимизированы для работы с длинными числами. Да, поскольку длина числа может быть любой, невозможно вот так просто взять и создать регистр в 640 миллионов бит, считая, что его «всем хватит». Не хватит : )

Тут проблема в том, что железо вообще не терпит гибкости. Резиновый регистр сделать, вероятно, возможно, но для этого потребуется масса аппаратной логики, бОльшая часть которой будет простаивать, занимая полезную площадь, а программная реализация той же работы не сильно уступала бы аппаратной. Смотрите, проблема в данном случае не в регистрах, есть процессоры, которые могут брать операнды непосредственно из памяти и возвращать результат обратно в память. Проблема в том, что аппаратная реализация определённых действий оказывается неоправданно сложна и чревата весьма неприятными проблемами. Как, например, поступать в следующей ситуации: мы одной инструкцией складываем два миллионобитных числа и вдруг оказывается, что последняя тысяча бит отсвоплена на диск? Откатывать миллион бит обратно и выкидывать промежуточные результаты? А где хранить почти миллион бит промежуточного результата, если есть вероятность отката операции? Останавливать процессорное ядро, пока другое ядро занимается вводом-выводом? А если во втором ядре при этом тоже случился page fault? В общем, поверьте, предполагаемая гибкость порождает больше проблем, нежели сулит выгоды.

Zealint писал(а):
И оперативной памяти для манипуляции с набором таких чисел тоже не хватит. По этой причине вычисления обычно выполняют в факторкольце Z/(p), а ответ восстанавливают по Китайской теореме об остатках. То есть нужно несколько раз (на практике несколько сотен тысяч раз) запустить программу с разными значениями p. Было бы здорово, чтобы в процессоре имелась возможность аппаратно проводить вычисления по модулю.

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

Zealint писал(а):
Одна задача – одна архитектура.

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

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

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

Zealint писал(а):
Каждый класс требует определённого набора операций, а значит нужно сделать максимальный упор на то, чтобы эти операции выполнялись бы как можно эффективнее, а остальные операции уже как получится. То есть мы делаем отдельный процессор для линейной алгебры, отдельный для работы с рациональными числами, отдельный для теории чисел и т. д.

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

Zealint писал(а):
* только 4 арифметические операции с целыми числами.

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

Zealint писал(а):
* как можно более высокая разрядность регистров

До определённого предела (64-бита для целых чисел) выигрыш действительно есть, дальше он исчезает.

Zealint писал(а):
* встроен генератор простых чисел, согласованных по размеру с разрядностью регистров

Простите, не понял. Генератор простых чисел, это не описка? Может быть случайных?

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

Вы затронули довольно интересную тему, однако, мне кажется, что тут (как и в арифметике над полем по модулю) довлеет стереотип, что аппаратная реализация обязательно быстрей программной. Она действительно быстрей, но только в том случае, если самый быстрый существующий алгоритм, который только допускает аппаратную реализацию, не может быть разбит на последовательные части или параллельные однородные части. Иначе аппаратная реализация представляет собой ничто иное, как координацию уже реализованных аппаратных блоков. Рассмотрите каждую из предложенных функций и посмотрите, существуют ли такие специфические неделимые (или параллельные неоднородные) действия для них. Кстати, современные суперскалярные процессоры способны параллельно выполять даже неоднородные действия.

Zealint писал(а):
* обеспечена суперскалярность (но не VLIW) в том смысле, что независимые по данным команды выполняются (почти) одновременно, либо какой-то другой класс параллельности выполнения независимых во всех смыслах команд.

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

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

А вам продавец в ответ - а какая частота шины? а в каком корпусе нужен модуль, LGA1234 или LBGA4321? А на какое напряжение питания? А для какого поколения ЦП? С вас 3000$ (по тыще за каждый модуль). А когда вы приходите домой, то оказывается, что они не совместимы с вашей материнской платой (хотя исправны) и возврату не подлежат как "технически сложные изделия", тогда вы бежите искать совместимую материнку :D. Нет уж, увольте, никаких модулей IMHO быть не должно. Надо делать ЦП изначально таким, чтобы задачи любого класса работали на нём хорошо.

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

С удовольствием обсужу.

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

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

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

Вот как раз это - самый эффективный способ, если требуется что-то совсем неординарное. Берём отладочную карту с мощным FPGA и PCI-E слотом, устанавливаем в комп и программируем наши функции непосредственно в железе. Также существуют реконфигурируемые суперкомпьютеры на FPGA именно для таких случаев. Однако, заметьте, большого распространения они не получили именно по той причине, что базовые операции нужны везде одни и те же. Считайте, что производительность шины PCI-E 16x - это примерный максимум того, что вы можете получить на нелокальной шине, т.е. установка ПМ на другую шину вам принципиально нового ничего не даст кроме проблем совместимости.

Zealint писал(а):
В Вашем предложении меня лично не устраивает скорость взаимодействия карты с процессором.

Ага, вот он важный пункт! Повод для размышления - как вы думаете, почему скорость маленькая, потому что процессор слабый, видеокарта слабая или есть какие-то другие важные причины? Подсказка уже есть выше.

Zealint писал(а):
Согласитесь, что скорость будет выше, если разрядность регистров будет не 64 бита, а 1024, например. Или я не прав?

Не правы. Если брать, например, операцию умножения, то полная аппаратная реализация пропорциональна квадрату размера чисел плюс значительный довесок на ускоренные переносы. Таким образом 1024-битный умножитель будет в 256 раз больше! На самом деле часто умножители большой разрядности часто делают на умножителях меньшей с сохранением промежуточных результатов. Если рассматривать операцию сложения, то оказывается, что начиная с какого-то значения N мы не можем сделать эффективный N-разрядный сумматор, по той причине, что он будет превышать пропускную способность памяти, т.е. не сможем обеспечить его загрузку.

Zealint писал(а):
Неплохо было бы иметь строковые команды (префикс rep в x86), которые бегут по двум массивам чисел и складывают их с переносом.

Так это уже есть.

Zealint писал(а):
Ещё я считаю, что ОС должна быть сразу кластерной.

Безусловно.

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

Каким образом??? У вас есть проверенные на практике идеи?

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

Вы совсем не правы. 2-3 докторские диссертации - мизерная плата за такую важную работу. Подумайте, например, о том, что счёт за электроэнергию для суперкомпьютера "Ломоносов" составляет порядка миллиона рублей в месяц по оптовым ценам (я даже не беру прочие эксплуатационные расходы) и вы поймёте, что даже 10% экономия - это огромный успех! Небольшие кластеры - совсем не тот рынок, на котором стоит акцентировать своё внимание.

Zealint писал(а):
Либо изобретать принципиально другую архитектуру ЭВМ или даже другую математику.

Есть конкретные идеи?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB