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

[Not]

SGS_67 пишет:

Not пишет:

SGS_67 пишет:
Параллелится

Ну так параллельте!

Готов принять материальное участие с споре, экселенц?

Дятел.

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

Попытки заменить свое невежество трамвайным хамством понятны, но в чем пойнт, сударь? С Вами тут в хамстве никто соревноваться не собирается. Я понятно объяснил? Вас кажется уже предупреждали на оный предмет?

[dmdimon]

SGS_67 пишет:

dmdimon пишет:

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

dmdimon пишет: Хаффман не параллелится нормально, т.е. без потерь в степени компрессии . Запакованный Хаффманом поток не распаковывается в параллель, только последовательно.
хорошо параллелится там только построение дерева при компрессии, и все.

Распаралльельте мне Хаффмана, потом подискутируем дальше. Вы сказали - см. вашу цитату выше - что готовы распараллелить конкретный алгоритм - вот он. Тько давайте без вот этих костылей в виде дополнительного потока с координатами "хвостов" блоков или тупой сегментации - во-первых это снижает степень компрессии, а надо бы распараллелить ФУНКЦИОНАЛЬНО ЭКВИВАЛЕНТНО - т.е. получить на выходе ИДЕНТИЧНЫЙ результат от параллельного и последовательного вариантов.

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

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

Что конкретно значит ваша фраза "я на практическом примере получу код хаффмана путём параллельных вычислений"?
Значит ли она, что вы предложите параллельную реализацию алгоритма Хаффмана упаковки (и распаковки), которая будет давать результат, бит в бит идентичный последовательной реализации, и при этом будет ОСМЫСЛЕННА, т.е. существенно сократит время компрессии/декомпрессии? В том числе для распаковки потока, упакованного по алгоритму Хаффмана? Если да - готов обсудить детали спора.


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

И, кстати, распаковка классического Хаффмана не параллелится, и это не моё слово вовсе. Он последовательно-зависимый. Чисто к сведению.

ps
Да, компрессию (статического) Хаффмана можно распараллелить еще и с выигрышем в скорости. Вот только при этом для обеспечения выигрыша в N раз придется использовать в 8*N раз больше памяти, чем для последовательного алгоритма и 8*N потоков исполнения.

[Ну-и-ну]

SGS_67 пишет:
Современные GPU поддерживают нативно 64-битную плывучку и сложный доступ к локальной памяти (последнее хоть и не комильфо).
С ветвлениями, правда, там всё плохо изначально. Но.
Хороший АЛГОРИТМ (простите за большие буквы) не должен содержать ветвлений. Вообще.
А если он их содержит - значит, это плохой алгоритм, который нужно и можно совершенствовать.
Я в узком смысле... алгоритм, в моём понимании - это пара страничек с формулами в векторном виде.
А ветвистые штуковины произрастают, как правило, от незнания/непонимания природы вещей.

Это ошибочное обобщение от незнания, кмк. К примеру, GTX 1080 - 2560 stream processors кушают float, 80 stream processors кушают double. И так (32:1) в Pascal'е и Maxwell'е (это микроархитектуры такие) везде, кроме экзотики.

Сложный доступ к локальной памяти - не понял фразы. Кто такая локальная память? Что такое сложный доступ?

Ветвистые штуковины - они вообще-то везде. Компиляция, компрессия, AI, почти любая обработка данных. Тот же рендер нынче без if'ов не обходится. Если-то-иначе-всё - наше всё. Как-то так.

[Наперстянка]

dmdimon пишет:
И, кстати, распаковка классического Хаффмана не параллелится, и это не моё слово вовсе. Он последовательно-зависимый. Чисто к сведению.

ps
Да, компрессию (статического) Хаффмана можно распараллелить еще и с выигрышем в скорости. Вот только при этом для обеспечения выигрыша в N раз придется использовать в 8*N раз больше памяти, чем для последовательного алгоритма и 8*N потоков исполнения.

   Видимо это как-то связано с конвейером, ступени которого управляются по распределению памяти, параллелей и прочее

[Denis Voronin]

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

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

dfln пишет:
А, оказывается, в ходу максимально топорные решения

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

[dmdimon]

Denis Voronin пишет:
Если задача стоит в том чтобы похерить все данные, то их просто надо шифровать, а ключик хранить на флешке. Уничтожаем флешку - ноут превращается в кирпич, вместе со всеми секретами Родины.

Quantum computing is still in its infancy, but it may already be time to start worrying about your data today. As a warning sign, the NSA backed off of its previous recommendations because they weren't robust to quantum computing attacks. For sheer Schadenfreude, read the following excerpt from this August update to their website:

For those vendors and partners that have already transitioned to Suite B [elliptic curve cryptography], we recognize that this took a great deal of effort on your part, and we thank you for your efforts. ... Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, which has made it clear that elliptic curve cryptography is not the long term solution many once hoped it would be. Thus, we have been obligated to update our strategy.

© https://hackaday.com/2015/09/29/quantum-computing-kills-encryption/

[SGS_67]

dmdimon пишет:

SGS_67 пишет:

dmdimon пишет:

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

dmdimon пишет: Хаффман не параллелится нормально, т.е. без потерь в степени компрессии . Запакованный Хаффманом поток не распаковывается в параллель, только последовательно.
хорошо параллелится там только построение дерева при компрессии, и все.

Распаралльельте мне Хаффмана, потом подискутируем дальше. Вы сказали - см. вашу цитату выше - что готовы распараллелить конкретный алгоритм - вот он. Тько давайте без вот этих костылей в виде дополнительного потока с координатами "хвостов" блоков или тупой сегментации - во-первых это снижает степень компрессии, а надо бы распараллелить ФУНКЦИОНАЛЬНО ЭКВИВАЛЕНТНО - т.е. получить на выходе ИДЕНТИЧНЫЙ результат от параллельного и последовательного вариантов.

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

В принципе не против. Только давайте уж уточнимся - что значит "я на практическом примере получу код хаффмана путём параллельных вычислений"?

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

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

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

Что конкретно значит ваша фраза "я на практическом примере получу код хаффмана путём параллельных вычислений"?
Значит ли она, что вы предложите параллельную реализацию алгоритма Хаффмана упаковки (и распаковки), которая будет давать результат, бит в бит идентичный последовательной реализации,..

Естественно.
Об том и речь.

 и при этом будет ОСМЫСЛЕННА, т.е. существенно сократит время компрессии/декомпрессии? В том числе для распаковки потока, упакованного по алгоритму Хаффмана? Если да - готов обсудить детали спора.
Кстати, обращаю ваше внимание на то, что это было ВАШЕ предложение без всяких дополнительных условий:
"Если есть желание подискутировать - приведите конкретный алгоритм зипа, и я его распараллелю "
У меня возникло желание, и я предложил алгоритм. Вы тут-же принялись менять ваши собственные условия дискуссии, что, вообще говоря, не комильфо, ну да ладно.

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

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

И, кстати, распаковка классического Хаффмана не параллелится, и это не моё слово вовсе. Он последовательно-зависимый. Чисто к сведению.

Так мы про упаковку или распаковку, уважаемый?
Следите за руками...

ps
Да, компрессию (статического) Хаффмана можно распараллелить еще и с выигрышем в скорости. Вот только при этом для обеспечения выигрыша в N раз придется использовать в 8*N раз больше памяти, чем для последовательного алгоритма и 8*N потоков исполнения.

Это не так, хоть и не суть.
Так спорим, или уже не о чем?

[SGS_67]

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

SGS_67 пишет:
Современные GPU поддерживают нативно 64-битную плывучку и сложный доступ к локальной памяти (последнее хоть и не комильфо).
С ветвлениями, правда, там всё плохо изначально. Но.
Хороший АЛГОРИТМ (простите за большие буквы) не должен содержать ветвлений. Вообще.
А если он их содержит - значит, это плохой алгоритм, который нужно и можно совершенствовать.
Я в узком смысле... алгоритм, в моём понимании - это пара страничек с формулами в векторном виде.
А ветвистые штуковины произрастают, как правило, от незнания/непонимания природы вещей.

Это ошибочное обобщение от незнания, кмк. К примеру, GTX 1080 - 2560 stream processors кушают float, 80 stream processors кушают double. И так (32:1) в Pascal'е и Maxwell'е (это микроархитектуры такие) везде, кроме экзотики.

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

Сложный доступ к локальной памяти - не понял фразы. Кто такая локальная память? Что такое сложный доступ?

Локальная память - это ресурс доступный GPU.
Сейчас выполняется в виде GDDR с "немыслимой" скоростью - порядка нескольких гигавыборок в секунду, и имеющий объём, сравнимый с системной памятью (памятью CPU).
Сложный доступ - это произвольный доступ к данному ресурсу, обеспечиваемый программой, заложенной в GPU. В отличие от системной памяти, куда ей доступа, как правило, нет (спец. случаи просьба не рассматривать).

Ветвистые штуковины - они вообще-то везде. Компиляция, компрессия, AI, почти любая обработка данных. Тот же рендер нынче без if'ов не обходится. Если-то-иначе-всё - наше всё. Как-то так.

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

Да и приведённые Вами примеры тоже отлично параллелятся.
В том числе, и компиляция, и сжатие.

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

[SGS_67]

Not пишет:

SGS_67 пишет:

Not пишет:

SGS_67 пишет:
Параллелится

Ну так параллельте!

Готов принять материальное участие с споре, экселенц?

Дятел.

Вам уже трое объяснили, что есть множество классов алгоритмов, которые или не параллелятся принципиально, или параллелятся с серьезным ухудшением характеристик. Кодирование Хаффмана - один из них.

Мнения троих здесь явно недостаточно.
Так спорим, или уже нет?

[SGS_67]

Наперстянка пишет: 
 Видимо это как-то связано с конвейером, ступени которого управляются по распределению памяти, параллелей и прочее

Круто завернули. Я так даже и не понял ничего. 

[dmdimon]

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

А что не так с руками и кому надо за ними следить? Изначальная цитата ваша и ответная моя:

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

dmdimon пишет: Хаффман не параллелится нормально, т.е. без потерь в степени компрессии . Запакованный Хаффманом поток не распаковывается в параллель, только последовательно.
хорошо параллелится там только построение дерева при компрессии, и все.

Допускаю, что могло возникнуть некоторое недопонимание - вы рассчитывали только на упаковку, а я явно не написал, что меня интересует Хаффман для упаковки И распаковки.
Однако выше, в вашей цитате, ва сами написали - БЕЗ ОГРАНИЧЕНИЙ - приведите конкретный алгоритм. Я выбираю статического Хаффмана, упаковку и распаковку. Классика.

Я, кстати, тут подумал - и готов сам распараллелить распаковку Хаффмана, только цена будет чудовищной. Так что формально вы правы в случае моего примера. Только практически это бессмысленно.

Уточню, что я имею в виду. В ситуации практически неограниченных ресурсов это имеет смысл. Например в вашем тесте (современный компьютер, 1 против двух потоков) очень просто получить выигрыш тупо в лоб порядка 12,5 % по скорости, даже думать не надо.  Моя ошибка в диалоге с вами в том, что я всегда подразумеваю ситуацию с дефицитом ресурсов.

Итак, формально вы правы. Практически, для частного случая отсутствия дефицита ресурсов - тоже правы. Спорить не буду.

[Василий Ратников]

подробности насколько в ПФР обделался эльбрус

http://d-russia.ru/wp-content/uploads/2016/10/pic1-1.png

интересно что адепты бредят СВ вариантом не существующим,
а 8С несмотря на наличие в инженерных образцах все еще в инженерных образцах
и может быть в 2018 году пойдут хоть какие нибудь серии, а может и нет

а пока они тока тока стали поставлять 4С вариант, тот самый который за 200 тыщ рублей
предлагает производительность меньше чем старенький Атом ))
потому что кто то не умеет в частоту своих схем ))))

писать ОСь с нуля пупок надорвется, портировать в говно код эльбруса тоже не весело
вот и выходит что сейчас там перепиленный линух 2.6.14 чей енд-оф-лайф наступил в 2006 году.
и содержит тучу багов и уязвимостей.
З - защищенность )))

PS в современном интеле I7-8700k если сопли положенные туда осознанно производителем убрать
реально получить 4.7-5.1 ГГц )
PS2 принципе если бы говно эльбрус стоил бы для МВД и ПФР тыщ 20 рублей за системник, то можно было бы сказать - ну вот мы говна тут сделали, зато оно наше и дешево. Но он стоит как пара ксеонов на 22 ядра+3д видюха на 10 000 гфлопс, а работает как атом ) это фиаско братан ангара.

[Denis Voronin]

Василий Ратников пишет:
реально получить 4.7-5.1 ГГц )

Нестабильных, а они никому не нужны.

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

[Василий Ратников]

Denis Voronin, это как раз стабильные.

а азот и не стабильные это уже совсем другие частоты
Статистика экстремального разгона была возглавлена результатом оверклокера по имени Kovan Yang с Тайваня, который разогнал процессор Core i7-8700K при помощи жидкого азота и материнской платы MSI Z370 Godlike Gaming до 7405 МГц, не жертвуя при этом ни активностью ядер, ни активностью Hyper-Threading.

это заслуга третьего поколения 14нм+++ , оптимизация структур, техпроцесса. Это же не эльбрус ) с его не имеющей аналогов архитектурой и который в рамках импортозамещения выпускается на Тайване, и комплектуется импортными SSD и импортными DIMM. Импортозамещение оно такое импортозамещающее, кадило крутится, лавеха мутится.

[mahor11]

Российские ученые разработали процессор ELISE для систем компьютерного зрения, за который получили приз «Золотой чип», сообщает пресс-служба компании «ЭЛВИС-НеоТек».

Компания-разработчик обошла десятки претендентов на пути к победе в престижном конкурсе. Новейшая разработка ELISE – мультиплатформенная система на кристалле (СнК), созданная по принципиально новым, инновационным принципам с огромным количеством транзисторов. Технологический процесс 28 нм позволяет добиться крайне высокой производительности разработки. Система ELISE позволяет обрабатывать большое количество видеопотоков, обеспечивая стереоизображение и выполнение широкого спектра задач высокой интенсивности.

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

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

Автор: Артём Колчин...
Источник: https://politexpert.net/74969-zolotoi-chip-rossii-processor-elise-dlya-sistem-budushego

[mahor11]

интересно что адепты бредят СВ вариантом не существующим,
а 8С несмотря на наличие в инженерных образцах все еще в инженерных образцах
и может быть в 2018 году пойдут хоть какие нибудь серии, а может и нет

а пока они тока тока стали поставлять 4С вариант, тот самый который за 200 тыщ рублей
предлагает производительность меньше чем старенький Атом ))
потому что кто то не умеет в частоту своих схем ))))

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

[Denis Voronin]

mahor11 пишет:
Эльбрус разрабатывался для военных применений.

И поэтому его отправили в пенсионный фонд))))))))))))

[Denis Voronin]

mahor11 пишет:
созданная по принципиально новым, инновационным принципам

Там на фото два D-SUB и один IDE?

[mahor11]

Там на фото два D-SUB и один IDE?

Скорее всего.Это ведь для систем распознавания лиц, видеорегистраторов и охранных систем.

[Наперстянка]

SGS_67 пишет:

Наперстянка пишет:
 Видимо это как-то связано с конвейером, ступени которого управляются по распределению памяти, параллелей и прочее

Круто завернули. Я так даже и не понял ничего.  

  Это я написал по мотивам динамических предсказаний ответвлений и адресов с использованием разного рода кэшей и драйверов.