![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
суперкомпьютинг имеет много гитик
Сегодня был на курсах повышения квалификации - рассказывали о том, как пользоваться LSF (Load Sharing Facility) на суперкомпьютере - как правильно и как неправильно распараллеливать процессы, как выделять ресурсы, избегать дедлоков и проч.
В качестве плохого распараллеливания был приведён пример, где пользователь (лектор отказался называть имя, но проболтался, что это была she) запустила 15000 задач на полсекунды каждую. Пять часов ушло только на то, чтобы заслать все эти процессы в очередь, а остальное время - to cool down the administrators :). Если бы задачу не распараллеливать вовсе, то друг за дружкой она бы посчиталась за 7500 секунд, т.е. примерно за два часа.
Ещё из любопытного: можно значительно сэкономить время вычислений, если ввод и вывод каждого процесса паковать на ходу, например, пайпить через gzip, а потом уже передавать по сети или записывать на диск. Запаковку/распаковку на лету узел суперкомпьютера осуществляет практически прозрачно, а вот взаимодействие с носителями и сетью для него - наиболее узкое место. Несмотря на гигабитный ethernet.
Ещё на суперкомпьютере не рекомендуется запускать программы на языке программирования Java. Того, кто этот запрет нарушит, постигнет суровая участь: его имя будет раскрыто остальным (разъярённым) пользователям суперкомпьютера :)
В качестве плохого распараллеливания был приведён пример, где пользователь (лектор отказался называть имя, но проболтался, что это была she) запустила 15000 задач на полсекунды каждую. Пять часов ушло только на то, чтобы заслать все эти процессы в очередь, а остальное время - to cool down the administrators :). Если бы задачу не распараллеливать вовсе, то друг за дружкой она бы посчиталась за 7500 секунд, т.е. примерно за два часа.
Ещё из любопытного: можно значительно сэкономить время вычислений, если ввод и вывод каждого процесса паковать на ходу, например, пайпить через gzip, а потом уже передавать по сети или записывать на диск. Запаковку/распаковку на лету узел суперкомпьютера осуществляет практически прозрачно, а вот взаимодействие с носителями и сетью для него - наиболее узкое место. Несмотря на гигабитный ethernet.
Ещё на суперкомпьютере не рекомендуется запускать программы на языке программирования Java. Того, кто этот запрет нарушит, постигнет суровая участь: его имя будет раскрыто остальным (разъярённым) пользователям суперкомпьютера :)
no subject
no subject
no subject
no subject
"Вы не любите кошек? Вы просто не умеете их готовить!";)))
no subject
;))))
Re: ;))))
no subject
no subject
Хотя по поводу последних двух тоже слышилось поскрипывание зубами :)
Меня огорчило отсутствие любимого мной Матлаба. Но оказалось, что для запуска такой штуки на суперкомпьютере нужно много-премного индивидуальных лицензий :) Продажные твари...
no subject
а в бытность мою аспирантскую она поставлялась бесплатно самой MathWorks
слушай ну я фигею
"даже"
без ПерлА как можно жить вообще? :) а на шелловский скрипт там тоже скрипят зубами? :)
no subject
Мне вот подумалось как-то, что если бы удалось красиво реализовать понятие хэш-таблицы на уровне компилятора Си, то Перл бы не имел такой популярности, как сейчас.
no subject
там reg-exps..да и вообще обработка строк
си надо просто хорошую библиотеку для обработки строк
ну вот как на Яве сделали
no subject
no subject
--
Интересно как там будет летать Doom 3. 8)
no subject
Кроме того, насколько я понимаю, bottleneck'ом тут станет как раз пропускная способность канала с видеокартой. Нарисовать-то нарисовали в памяти, а дальше это всё надо быстро-быстро успевать отображать. А это не самая сильная сторона суперкомпьютера.
no subject
А ведь и верно, простым алгоритмом пакуют нынешние машины несколько быстрее, чем прокачивают в винт/сетевуху... Но чтобы _значительно_ускорить_ этим?.. Разве что надо очень большие объемы гнать и пропускной способности не хватает физически... ну так это от задачи зависит.
А эта рекомендация насчет зипа - она безусловная? Что-то тут явно не то.
no subject
Кстати,
Оно что, пока в очередь все на запихает, работать не начнет?%)
Re: Кстати,
no subject
Запаковка ввода-вывода перед передачей -- интересная идея.
А вот за что они так Жабу нелюбят? Нешто у них нету нормальной JVM, которая будет треды по узлам раскладывать?
no subject
Поскольку "дух каждой задачи нужно облечь в реализующую материю", то весь этот пре- и пост-процессинг становится боллнеком, когда задач много и они мелкие.
Насчёт запаковки я ещё такую штуку придумал. Можно же заливать на суперкомп исходник. А там его компилировать (для разноархитектурных блинов в разный код) и сразу же запускать. Жалко, юниксовый шелл не умеет такие штуки делать - "запустить слинкованный код, переданный по пайпу" :)
Насколько я знаю, для Жабы нет специального внутреннего шедуляйзера, вся планировка работает через LSF. А LSF не предназначена для внутреннего дробления процессов. Она просто берёт процесс как целое, меряет его разными мерками и запускает на подобающем железе.
Но даже не multi-shitty-threading - проблема Жабы. А неэффективный garbage collector, который "отложил и неизвестно". Вот это действительно ужас ужасов, особенно при разделяемых ресурсах. По сравнению с ним в Перле сборка мусора осуществляется достаточно эффективно: как только на объект исчезла последняя ссылка, он ресайклится. Конечно, его можно обмануть (например, слить ссылку в файл, как число, и стереть из памяти), но в основном такие примеры искусственны.
no subject