суперкомпьютинг имеет много гитик
Dec. 15th, 2004 05:39 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jayrandomСегодня был на курсах повышения квалификации - рассказывали о том, как пользоваться 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. Того, кто этот запрет нарушит, постигнет суровая участь: его имя будет раскрыто остальным (разъярённым) пользователям суперкомпьютера :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-12-16 06:14 am (UTC)Запаковка ввода-вывода перед передачей -- интересная идея.
А вот за что они так Жабу нелюбят? Нешто у них нету нормальной JVM, которая будет треды по узлам раскладывать?
no subject
Date: 2004-12-16 07:58 am (UTC)Поскольку "дух каждой задачи нужно облечь в реализующую материю", то весь этот пре- и пост-процессинг становится боллнеком, когда задач много и они мелкие.
Насчёт запаковки я ещё такую штуку придумал. Можно же заливать на суперкомп исходник. А там его компилировать (для разноархитектурных блинов в разный код) и сразу же запускать. Жалко, юниксовый шелл не умеет такие штуки делать - "запустить слинкованный код, переданный по пайпу" :)
Насколько я знаю, для Жабы нет специального внутреннего шедуляйзера, вся планировка работает через LSF. А LSF не предназначена для внутреннего дробления процессов. Она просто берёт процесс как целое, меряет его разными мерками и запускает на подобающем железе.
Но даже не multi-shitty-threading - проблема Жабы. А неэффективный garbage collector, который "отложил и неизвестно". Вот это действительно ужас ужасов, особенно при разделяемых ресурсах. По сравнению с ним в Перле сборка мусора осуществляется достаточно эффективно: как только на объект исчезла последняя ссылка, он ресайклится. Конечно, его можно обмануть (например, слить ссылку в файл, как число, и стереть из памяти), но в основном такие примеры искусственны.
no subject
Date: 2004-12-17 12:57 am (UTC)