Суперкомпьютеры в ракетно-космической отрасли

[dmdimon]

SGS_67 пишет:

dmdimon пишет:Т.е. это - по сути аналог математического сопроцессора

Ну, вот те раз... Крайне странное сравнение CPU и GPU.
[skip]
То есть, по сути, математический сопроцессор на стероидах.

не понял, что вы хотели сказать и в чем нашли странность

[dmdimon]

Denis Voronin пишет: 
Если я ничего не путаю, это описание корректируемых снарядов Сантиметр, которые реализованы без всяких процессоров. Упс.

И что? Как вопрос возможности осмысленного распараллеливания связан с аппаратной базой в этом случае?

[dmdimon]

DiZed пишет:

dmdimon пишет:
DiZed, распараллельте задачу управления следующим объектом

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

Не понял. Я привел вам практический, осмысленный пример, в котором, с моей точки зрения, распараллеливание ничего не даст. Не согласны? предложите ВАШУ структуру управляющего контура, покажите, при каких граничных условиях распараллеливание даст выигрыш.
Давайте исходить из того, что у нас есть Микрон с уверенно освоенным 90-нм техпроцессом - т.е. нам точно доступны процессоры вот такого примерно уровня:
https://en.wikipedia.org/wiki/90_nanometer#Processors_using_90.C2.A0nm_process_technology
(обратите внимание на две последних позиции)
и почему-то не попавший туда SPARC64 VI например, тоже в тему топика как-бы.
https://en.wikipedia.org/wiki/SPARC64_V#SPARC64_VI
Их вычислительные и прочие возможности можно увидеть по соответствующим ссылкам да и вообще гугл рулит, между нами говоря. Ну и понятно, что если такие вычислительные мощности нам не нужны - а они не нужны в описанной ситуации - то никто не мешает и попроще взять процессор.


С нетерпением жду ответа с ОСМЫСЛЕННЫМ, дающим некий практический выигрыш, распараллеливанием.

[ExDi]

dmdimon пишет:
И что? Как вопрос возможности осмысленного распараллеливания связан с аппаратной базой в этом случае?

а что именно вы хотите распараллелить?
вы  конструируете контур управления, оцениваете его временнЫе параметры, набрасываете структуру алгоритмов управления и начинаете писать их реализацию с учетом характеристик процессора. вот на этом этапе вам и может пригодиться многоядерность; вы находите бутылочные горлышки, т.е. участки алгоритмов, которые определяют скорость счета, смотрите - можно ли их разбросать по разным ядрам, и начинаете выделять потоки, определять критические секции и расставлять мьютексы. условно говоря, если у вас в алгоритме есть строчка типа z=a*x+b*y, то вычисление a*x вы можете отдать одному ядру, b*y - второму, сложение и выдачу результата - третьему. в реальности конечно такое вычисление должно быть оптимизировано конвейером процессора во время исполнения, возможно - не без помощи компилятора, но в реальном алгоритме и особенно в риалтайм многое придется делать руками. если алгоритмы бесхтиростные - то слишком много ядер утилизировать будет сложно, но если вы используете, например, фильтрацию сигналов с датчиков фильтрами высоких порядков, через фурье-преобразование или вейвлеты -то и 100 ядер GPU окажутся очень кстати. т.е. распараллеливание при проектировании системы может реализовываться на высоком уровне абстракции, (бесконечно) далеком от собственно задачи "управление полетом корректируемого снаряда". если у вас очень хороший компилятор и очень хорошие отлаженные библиотеки - то вы о многопоточности можете особо не заботиться, не вспоминать и может даже не догадываться

[dmdimon]

DiZed пишет:

dmdimon пишет:
И что? Как вопрос возможности осмысленного распараллеливания связан с аппаратной базой в этом случае?

а что именно вы хотите распараллелить?

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

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

В предыдущем посте вот даже постарался и дал вам ссылки для оценки имеющейся в вашем распоряжении вычислительной мощности. Хотите конкретики? ну так ее можно оценить же из приведенных мной условий. Например, одно из граничный условий, очевидно же, это скорость модуляции мощности отклоняющего двигателя. Можно с точностью до порядка оценить? да никаких проблем! А, забыл сказать - он химический, а не плазменный там или еще какой ЭРД. Бутылочное горлышко реальности, так сказать, я вам обозначил. Одно из. Вы же инженер, я так понимаю? Ну или ученый, старой, так сказать, школы? Так подумайте сами, я же вам навстречу иду - не задаю какой-то свой контур управления, а полностью развязываю руки. Придумайте что-нибудь, сопрягающееся с реальностью, хотя-бы при первичной оценке.

[Denis Voronin]

dmdimon пишет: 

Denis Voronin пишет: 
Если я ничего не путаю, это описание корректируемых снарядов Сантиметр, которые реализованы без всяких процессоров. Упс.

И что? Как вопрос возможности осмысленного распараллеливания связан с аппаратной базой в этом случае?

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

[dmdimon]

Denis Voronin пишет:

dmdimon пишет:

Denis Voronin пишет:
Если я ничего не путаю, это описание корректируемых снарядов Сантиметр, которые реализованы без всяких процессоров. Упс.

И что? Как вопрос возможности осмысленного распараллеливания связан с аппаратной базой в этом случае?

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

1) девайс был приведен в качестве простого, наглядного, практического примера бессмысленности распараллеливания. Могу привести другой пример, цифровой - ничего не изменится.
2) Я вас удивлю - аналог прекрасно можно распараллелить. Принципиально вопрос целесообразности распараллеливания в некоей задаче зависит лишь от задачи, а не от используемых аппаратных средств, вплоть до цифра/аналог там или электричество/пневматика/гидравлика/механика. Правильный выбор аппаратных средств - лишь вопрос оптимизации. Здесь есть нюансы, но в целом, упрощенно - это именно так.
Весьма странно учавствовать в (оффтопной) дискуссии о параллелизме в рамках ветки о процессорах, не зная таких основ.
Упс.

ps первый ответ улетел куда-то в нирвану, так что если дубль - простите.

pps. Кстати, вот в Игле, например, как минимум в одном месте есть аналоговое распараллеливание, и еще в одном - аж аналогово-механическое, прикиньте.

[ExDi]

dmdimon пишет:

так я же вам привел пример, зачем вы спрашиваете?

ни фига себе.. вы вот так вот прямо всерьез мне предлагаете вот прямо здесь и сейчас набросать проект корректируемого снаряда, контуры управления и алгоритмы с учетом архитектур процессоров, и сравнить возможный выигрыш - или таки риторически? гм, правслово, я найду как потратить сегодняшний вечер интереснее и продуктивнее. мне достаточно собственной уверенности, что доведись (недайбох) таки этим заниматься - я бы в этом снаряде GPU нашел к чему приспособить.. хотя начал бы с того - нельзя ли это все на 10 MHz PIC реализовать ; )
нет, я не инженер (хотя опыт инжиниринга имею довольно разнооборазный); а учеными, как говаривал Дау, бывают только коты и секретари. я научник - к тому же академический, по фундаментальной тематике, приборы конструировать-строить-модернизировать (для себя и не только) - это типа хобби. а что такое "старая школа"?

[Denis Voronin]

dmdimon пишет:
Упс.

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

[ExDi]

"Принципиально вопрос целесообразности распараллеливания в некоей задаче зависит лишь от задачи" - неужто вы решили, что с этим кто-то спорить будет?? я выше написал - если задачка решается на PIC и результат вас устраивает, если и при этом бутылочное горлышко не в вычислительном устройстве, а в латентности двигателя/датчика и невоспроизводимости управляющего воздействия, то делать ее надо на PIC (и не выеживаться с эльбрусами за 200K). разговор о распараллеливании начинается ровно с того момента, когда этим бутылочным горлышком оказывается вычислительный блок

[dmdimon]

DiZed пишет:
"Принципиально вопрос целесообразности распараллеливания в некоей задаче зависит лишь от задачи" - неужто вы решили, что с этим кто-то спорить будет??

Ну вот Денис Воронин постом выше этого не понимает. А в дискуссии вполне учавствует.

DiZed пишет:
я выше написал - если задачка решается на PIC и результат вас устраивает,

вы не поняли. Вы там распараллеливали "абстрактно" трубу с шариками Not-а и как-бы намекали на его безграмотность, а он вам - на вашу. Я лично его пример понял, и, для того, чтобы пример Not-а для вас прояснить, привел вам практическую систему с "трубой с шариками" на входе и выходе и обработкой, которую бессмысленно В РЕАЛЬНОСТИ распараллеливать между трубами. 

[ExDi]

dmdimon пишет:
вы не поняли. Вы там распараллеливали "абстрактно" трубу с шариками Not-а

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

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

[Denis Voronin]

dmdimon пишет:
Ну вот Денис Воронин постом выше этого не понимает. А в дискуссии вполне учавствует.

У вас проблемы, сломался хрустальный шар, отнесите его в ремонт.

[dmdimon]

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

Да что такого-то в первичной оценке? Ну пусть у нас модуляция возможна на фантастической, завышенной на полтора порядка минимум, частоте в килогерц. То-есть наша система должна успевать с частотой килогерц успевать выдавать управляющее воздействие. То-есть при вдвое заниженной практически достижимой на полностью отечественной технологической базе тактовой частоте в 1 ГГц, отбрасывая конвейеризацию, у нас есть запас в МИЛЛИОН циклов на одно управляющее воздействие. Хорошо.

Предположим, мы можем модулировать двигатель аж в два бита - выключен и три степени мощности
Предположим, у нас есть 256 градаций угла поворота (что избыточно)
Предположим, мы имеем 5 (ПЯТЬ!) входных параметров с неких сенсоров, да еще и с плавающей точкой (Охренеть, ну ладно)
Итого, мы имеем что? мы имеем табличку, заранее просчитанную, пятимерную на входе и двумерную на выходе. Поскольку мы можем смело позволить себе дать ну 10000 циклов (щедро!) на нормирование на входе, то мы табличку на входе получаем с шагом в 1% вместо float, т.е. 100 в пятой степени БИТ, если не изгаляться т.е. 10 гигабит (не байт!). Многовато, верно? Ну и хрен с ним (хотя гигабайт с копейками ОЗУ - вообще ниочем по нынешним временам, а табличку можно хоть на суперкомпьютере численным моделированием посчитать)
Ладно, делаем табличку с шагом 5 процентов - 20 в пятой - 3,2 мегабита, 400 килобайт. Отлично. Заметьте, считать вообще не надо - надо просто перебирать адреса и читать-писать значения, ПЯТЬ нормированных значений писать и ДВА читать, 1000 раз в секунду.

Ок, видим при моделировании, что 5% - грубо, что же делать? (не верю, ну да ладно)
А давайте на оставшиеся в запасе 998000 циклов купим себе сплайновую интерполяцию, например как здесь, для простоты:
интерполяция
на сдачу нам дадут ну тысяч девятьсот циклов точно. Купим на них фильтра Кальмана себе, ложные экстремумы фильтровать. Ну тысяч двести максимум потратим. Итого - сдача в 700000 тактов.

Резюме - при быстрой оценке оказывается, что при явно завышенных характеристиках исполнительной и сенсорной системы и явно заниженных характеристиках железа системы управления мы получили 70% избыточность в вычислительной мощности при однопоточном исполнении. И то только потому, что экономили память. Если же память не экономить, используя полную таблицу - то вычисления, по факту, будут вообще не нужны.

Вот чего-то в духе такой прикидки я от вас ожидал, только в пользу параллелизма. Времени потрачени минут десять.

[ExDi]

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

[ExDi]

dmdimon пишет:

Вот чего-то в духе такой прикидки я от вас ожидал, только в пользу параллелизма. Времени потрачени минут десять.

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

[ExDi]

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

[dmdimon]

DiZed пишет:
т.е. изначально дискуссия возникла из того, существуют ли вычислительные задачи, которые не поддаются ускорению посредством распараллеливания

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

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

[Ну-и-ну]

Товарищи и господа, последние страницы темы - ни с чем не сравнимый пир духа. Низкий поклон за доставленное удовольствие.Лишь немногие оценят данный концентрат по достоинству.

PS: По-крайней мере один программист видеоигр со стажем 23 года (жуть-то какая), последние лет десять много занимавшийся оптимизацией, оценил. Спасибо!

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

[ExDi]

dmdimon пишет:

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

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