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

[SGS_67]

dmdimon пишет:

DiZed пишет:

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

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

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

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

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

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

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

То исключение, которое, по логике древних, опровергает правило (а не подтверждает его, что есть нонсенс).
     
.

[Not]

SGS_67 пишет:

Not пишет:

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

Задрал! Объясняю на пальцах:
у вас есть труба, по которой к вам катятся шарики разных цветов. Доступа к другому концу трубы у вас нет. Шариков много, катятся очень быстро. Ваша задача построить функцию распределения шариков по цветам. Распараллеливайте!    

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


 Скрытый текст Передачу (цифрового) сигнала по каналам связи приводить в пример не рекомендую.
Ибо вы ОЧЕНЬ сильно ошибётесь.  
Параллельные методы обработки здесь рулят, как и везде.

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


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

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

[SGS_67]

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

Это не так; зип отлично параллелится.
Как и любая статистическая задача.

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

[Not]

SGS_67 пишет:

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

Да на здоровье! Алгоритм декомпрессии  gzip - распараллеливайте!  

[Not]

SGS_67 пишет:

Я утверждаю, что задач, не допускающих распараллеливание, не существует.

Все дилетанты одинаковы  :evil:

[Ну-и-ну]

SGS_67 пишет:
Это не так; зип отлично параллелится.

Сегодня дискуссия ещё круче вставляет. Так держать!

[Ну-и-ну]

Какой день!

[SGS_67]

Not пишет:

SGS_67 пишет:

Not пишет:

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

Задрал! Объясняю на пальцах:
у вас есть труба, по которой к вам катятся шарики разных цветов. Доступа к другому концу трубы у вас нет. Шариков много, катятся очень быстро. Ваша задача построить функцию распределения шариков по цветам. Распараллеливайте!    

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


 Скрытый текст Передачу (цифрового) сигнала по каналам связи приводить в пример не рекомендую.
Ибо вы ОЧЕНЬ сильно ошибётесь.    
Параллельные методы обработки здесь рулят, как и везде.

Во-первых разберитесь в своей голове с понятием нуль-мерности. 

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

Во-вторых лоток вы найдете у себя в хлеву, а здесь - труба (канал, очередь). Изменить это вы НЕ можете, как бы ни хотелось.

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

В третьих попробуйте порулить при приеми информации из цифровой оптоволоконной линии. Я с удовольствием выслушаю ваши грандиозные идеи.

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

 Если окажутся прорывными - передам приятелю в Finisar, они вам спасибо скажут, но скорее ваши щеки лопнут до того.         

Мне проще будет пообщаться с вашим приятелем из Finisar. "Спасибом" там не ограничусь; а как минимум - коньяк.  
По поводу моих щёк - см. выше. Больше предупреждений не будет.

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

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

Есть еще и другие нюансы.

Я писал уже: давайте ваши нюансы. Покумекаем, обсудим. Или ни слова более.

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

Вы хоть понимаете, что написали счас??

[SGS_67]

Not пишет:

SGS_67 пишет:

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

Да на здоровье! Алгоритм декомпрессии gzip - распараллеливайте!  

НЕТ такого алгоритма, уважаемый.
Есть только такая программа.
Которая использует несколько различных алгоритмов.
Больше не пЕшите лучше.

[Not]

SGS_67 пишет:
А вот если куриц было хоть бы две, задача стала б одномерной, и распараллеливаемой.    

Если бы, да кабы. В условиях задачи одна труба и вне зависимости от количества куриц, яйца по ней летят с константной скоростью, увы.

SGS_67 пишет:

В третьих попробуйте порулить при приеми информации из цифровой оптоволоконной линии. Я с удовольствием выслушаю ваши грандиозные идеи.

Там применяется как блочная , так и конвейерная обработка.
Для последней, GPU ещё более эффективен, чем для чисто параллельных вычислений.(Об этом, кстати, не писали здесь, а зря).

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

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

Вам столько не проглотить. Вы только что заявили, что НЕ СУЩЕСТВУЕТ непараллелизуемых алгоритмов.

SGS_67 пишет:

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

 
Вы хоть понимаете, что написали счас??

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

[SGS_67]

dfln пишет:

Not пишет:

SGS_67 пишет:

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

Да на здоровье! Алгоритм декомпрессии gzip - распараллеливайте!    

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

Всё верно.

[SGS_67]

Ну-и-ну пишет:

SGS_67 пишет:
Это не так; зип отлично параллелится.

Сегодня дискуссия ещё круче вставляет. Так держать!

Типо, вы орЁлом в небесах.
Заземлиться опасений нет, случайно?
Бо мы, внизу, тут злобные весьма.  

[Ну-и-ну]

SGS_67 пишет:
Типо, вы орЁлом в небесах.

Не, в партере

[Not]

SGS_67 пишет:
Бо мы, внизу, тут злобные весьма.    

Ну так чаво, "приведите конкретный алгоритм зипа и я его распараллелю" алгоритм декомпрессии gzip распараллеливать будете или как?

[Not]

SGS_67 пишет:

Not пишет:

SGS_67 пишет:

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

Да на здоровье! Алгоритм декомпрессии gzip - распараллеливайте!    

НЕТ такого алгоритма, уважаемый.
Есть только такая программа.
Которая использует несколько различных алгоритмов.
Больше не пЕшите лучше.

Да нет уж, я напишу с Вашего позволения. Распараллеливайте алгоритм Deflate из программы gzip  

[Ну-и-ну]

Not пишет:
Ну так чаво

Да привели же - bzip2. Я даже грешным делом думал, что там принципиально другой алгоритм, который допускает распараллеливание.

А оказалось - алгоритм, в натуре, другой, но ничего в части параллелизуемости не даёт.

Но, внезапно, формат файла - блочный, а компрессия блоков независимая. Ура, победа в споре

PS: Полагаю, на задачу распараллеливания компилятора С++ решение будет - а возьмите make (jam), который параллельно много экземпляров компилятора запустит Нету методов против Коли Сапрыкина

[Not]

SGS_67 пишет:

dfln пишет:

Not пишет:

SGS_67 пишет:

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

Да на здоровье! Алгоритм декомпрессии gzip - распараллеливайте!    

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

Всё верно.

Верно, но в частном случае, то есть не ВСЁ как тут брешут некоторые литераторы
Верно тогда, когда вам доступен весь упакованный файл, целиком. Если же данные к вам идут "по трубе" (оно же pipe для особо одаренных курощупов), то bzip2 исключительно неэффективен, поскольку вам нужно
1) принять весь файл - одно ядро, увы.
2) его распаковать - все ядра в дело и догонять! - но опять увы, на шаге 1 вы все прос.али.

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

[TAU]

SGS_67 пишет: распараллеливание всегда возможно там, где СУ регулирует что-то посложней сортирного бачка

Чушь. Вы что, элементарного не понимаете - что использование "вычислительной" техники НЕ сводится к чисто вычислительным задачам? Что СУЩЕСТВУЮТ задачи, решаемые шаг за шагом - последовательные по своей природе - кои нельзя сделать параллельными?

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

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

[SGS_67]

Not пишет:

SGS_67 пишет:
А вот если куриц было хоть бы две, задача стала б одномерной, и распараллеливаемой.    

Если бы, да кабы. В условиях задачи одна труба и вне зависимости от количества куриц, яйца по ней летят с константной скоростью, увы. 

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

SGS_67 пишет: 

В третьих попробуйте порулить при приеми информации из цифровой оптоволоконной линии. Я с удовольствием выслушаю ваши грандиозные идеи.

Там применяется как блочная , так и конвейерная обработка.
Для последней, GPU ещё более эффективен, чем для чисто параллельных вычислений.(Об этом, кстати, не писали здесь, а зря).

GPU в конвейерной обработке эффективнее GPU в блочной.

Откуда вам это известно, кроме как из моего поста, позвольте полюбопытствовать?
Я ведь мог и ошибиться. Докажите, плиз.    

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

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

Ну, или контрольный выстрел.
Допустим, мне надо обмолотить радарную решётку порядка 1000+ элементов. Модуляция простая - ЛЧМ.
Кто быстрее справится: самый навороченный Эльбрус или Nvidia Tegra X1? Учитывая, что последний проц сделан для мобильных применений, и жрёт энергии в несколько раз меньше.

[Not]

dfln пишет:

Not:
Да нет уж, я напишу с Вашего позволения. Распараллеливайте алгоритм Deflate из программы gzip    

Так есть же давным давно готовое решение pgzip. Не вижу смысла обсуждать то, что уже изобретено другими.

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