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

[Not]

Кстати говоря, раз уж SGS уперся рогом за косяк, совокупность алгоритмов программы - это тоже алгоритм, могу вам предложить распараллелить функцию main() из программы gunzip() но только чтобы быстрее была в K раз, где К - количество ядер вашего GPU    

P.S. простите, алгоритм функции main(int argc, char** argv),
(это чтобы рог не цеплялся)  

[SGS_67]

dfln пишет:
Была нормальная тема, шло обсуждение, тут появились вы с бесконечными оскорблениями. Нормальные люди терпели вас, а потом просто ушли. Я последую их примеру, ибо читать тут больше нечего кроме флуда вашей шайки.

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

[SGS_67]

Not пишет:
Кстати говоря, раз уж SGS уперся рогом за косяк, совокупность алгоритмов программы - это тоже алгоритм  

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

[Not]

ну так что там с распараллеливанием Deflate ? Или вы там клинья перебором в глубину ищете?  

[SGS_67]

Not пишет:
Мне вот интересно, когда бот попадает в ситуацию, когда он не имеет права сказать НЕТ, а ДА логически не может, он сгорает, или его отправляют на перепрограммирование?    

Мне это тоже интересно:

SGS_67 пишет: 

Not пишет: 

Denis Voronin пишет: 
Узкоспециализированные? Майнинг, криптография, нейросети - первое что пришло на ум, ничего так "узкая" специализация.

Совершенно верно, узкая, поскольку для перечисления тех задач, где используются универсальные процессоры, и где граф. платы использоваться НЕ могут, вам ума не хватит.

Отдаёт галимой демагогией, уважаемый.
Назовёте хоть ОДНУ серьёзную, на ваш взгляд, научную или техническую задачу, где нельзя использовать ресурсы GPU для ускорения вычислений.

Я весь внимание. 

Так ума хватило, или всё же на перепрошивку, дятел? 

[Ну-и-ну]

SGS_67 пишет:
Читайте выше; всё написано.

Алгоритмы компрессии семейства LZ (словарные) не параллелятся простым образом, а скорее всего - никак. Могу попробовать объяснить, почему оно так.

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

Вообще, тезис, что "параллелизуется всё" - он реально смелый. Если умеете распараллеливать любые пару миллионов строк кода ядер на восемь, да чтобы работало равномерненько, без idle time и излишних lock'ов - поищите работу с очень, очень хорошей зарплатой.

[Not]

SGS_67 пишет:

Назовёте хоть ОДНУ серьёзную, на ваш взгляд, научную или техническую задачу, где нельзя использовать ресурсы GPU для ускорения вычислений.

Я весь внимание.    

Так ума хватило, или всё же на перепрошивку, дятел?    

В смысле, распаковка больших массивов данных для вас задача нетехническая и несерьезная?
deflate на GPU ускорять будем? Я весь внимание  

[Ну-и-ну]

SGS_67 пишет:
Назовёте хоть ОДНУ серьёзную, на ваш взгляд, научную или техническую задачу, где нельзя использовать ресурсы GPU для ускорения вычислений.

Разрешите встрять. Компиляция С++ сойдёт за серьёзную техническую задачу?

[SGS_67]

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

SGS_67 пишет:
Читайте выше; всё написано.

Алгоритмы компрессии семейства LZ (словарные) не параллелятся простым образом, а скорее всего - никак. Могу попробовать объяснить, почему оно так.

Ну вот, хотяб до алгоритма добрались, сквозь тучу вони.

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

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

Главный затык там - скорость доступа к данным. Ну, это вообще везде, и я об этом писал.

[SGS_67]

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

SGS_67 пишет:
Назовёте хоть ОДНУ серьёзную, на ваш взгляд, научную или техническую задачу, где нельзя использовать ресурсы GPU для ускорения вычислений.

Разрешите встрять. Компиляция С++ сойдёт за серьёзную техническую задачу?

Со скрипом, но сойдёт!   

[Not]

dfln пишет:
Собственно, на вопрос «можно ли распаралелить deflate » ответ однозначный - да.

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

Вы уже определитесь, "однозначный" - да, или "концепцию нужно сменить"?

Вы же себе противоречите в одном сообщении    

dfln пишет:
В сети можно встретить

Вот! В этом ваша главная проблема - вместо того, чтобы чуточку подумать, что в случае зависимости двух блоков данных друг от друга посчитать второе, не обработав перед этим первое - НЕВОЗМОЖНО, вы лезете в сеть и тащите оттуда всякую гадость!

[Ну-и-ну]

Про GPU - участники в курсе, как там ветвление работает? Ну вот запустили мы kernel по массиву 64х64. А kernel сложный, только прочитает данные - и давай ветвиться в разные стороны, хошь - налево, хошь - направо. Вот что там будет происходить с ветвлениями?

[Ну-и-ну]

dfln пишет:
Когда Not аннигилируется, можно будет обсудить распаралеливание Deflate.

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

[SGS_67]

Not пишет
P.S. простите, алгоритм функции main(int argc, char** argv),
(это чтобы рог не цеплялся)    

Ты забыл puts ("Hello, world!") ;  , придурок.   

[Ну-и-ну]

SGS_67 пишет:
Оно и делается так реально. В этом и суть.

Я писал архиваторы и pak-менеджеры. Разбивка файла на блоки - очевидная вещь, так делают много лет. Это никак не аргумент, что LZ-алгоритмы параллелизуемы. Увы.

Как и то, что правильный make (в широком смысле) умеет параллельно запускать много компиляторов - не аргумент о параллелизуемости компиляции.

[SGS_67]

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

dfln пишет:
Когда Not аннигилируется, можно будет обсудить распаралеливание Deflate.

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

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

[Not]

dfln пишет:

- можно ли распараллелить deflate? Ответ - да.
- можно ли эффективно распараллелить deflate ( добиться по крайней мере схожей производительности? Ответ - нет.

По крайней мере на текущий момент это никто не сделал. Но идеи пока не исчерпаны

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

Чо сказать то хотели, что демагог вы профессиональный?

[Not]

SGS_67 пишет:
Тут сейчас бьют с носка, и могут невзначай зацепить.

Вы уже deflate распараллелили, или никак от косяка отцепиться не можете ?  

[Ну-и-ну]

SGS_67 пишет:
Тут сейчас бьют с носка, и могут невзначай зацепить.

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

Вот тупым хамам рассказывать точно бесполезно, но Вы же не из них

[SGS_67]

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

SGS_67 пишет:
Оно и делается так реально. В этом и суть.

Я писал архиваторы и pak-менеджеры. Разбивка файла на блоки - очевидная вещь, так делают много лет. Это никак не аргумент, что LZ-алгоритмы параллелизуемы. Увы.

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