Comments 28
перенесите, пожалуйста, пост в блог .net
Ну вы и сравнили…
(тут и ниже выделение моё)
Думаю, тут всё понятно?
Да? И где это у вас в программе проверяется? (А на самом деле это неправда, синхронная посылка — это другое.)
Вы серьёзно считаете отсутствие сборщика мусора в си недостатком MPI?
Pre-ANSI C прототипы. Какой компилятор C++ это соберёт?
Где во второй программе на MPI замер времени? Если он был внешний, то это ни о чём не говорит, так как там есть интерактивное общение с пользователем.
Из тестирования невозможно сделать выводы о возможности (!) разработки, а также о её трудоёмкости. Из тестирования можно сделать выводы по полученным данным тестирования.
Самое важное — сериализация данных скрыта от прграммиста.
Учитывая, что MPI не реализует ни сериализацию, ни вызов удалённых методов, не понятно, к чему это тут.
> А у нас с объектами! — И что?
Не показаны конкретные преимущества ООП при передаче сообщений.
Кроме того, вас не смущает то, что вы взяли «ассемблер» и сравнили его с «перлом» и сделали выводы:
* на ассемблере не удобно использовать регулярные выражения;
* на перле медленно копировать большие массивы?
(тут и ниже выделение моё)
В мире функционального программирования наиболее распространенной технологией создания программ для параллельных компьютеров такого типа является MPI.
Думаю, тут всё понятно?
Перед отправкой данных (MPI_Ssend) необходимо быть уверенным в том, что принимающая сторона явно инициализировала их прием (MPI_Recv), что усложняет процесс разработки.
Да? И где это у вас в программе проверяется? (А на самом деле это неправда, синхронная посылка — это другое.)
влияние указанных ранее недостатков MPI:
…
Кроме того, неприятным моментом, связанным с организацией языка программирования, является необходимость ручного выделения и освобождения памяти.
Вы серьёзно считаете отсутствие сборщика мусора в си недостатком MPI?
Программа на C++ для MPI…
int main(argc,argv)
int argc;
char *argv[];
Pre-ANSI C прототипы. Какой компилятор C++ это соберёт?
Где во второй программе на MPI замер времени? Если он был внешний, то это ни о чём не говорит, так как там есть интерактивное общение с пользователем.
По результатам представленного краткого тестирования можно сделать следующие выводы:
* Разработка приложений на платформе .NET Framework для решения вычислительных задач на системах с распределенной памятью является возможной.
* Технология WCF, предназначенная для построения приложений такого рода, обеспечивает гораздо более простой способ межпроцессной коммуникации, нежели это реализовано в MPI.
Из тестирования невозможно сделать выводы о возможности (!) разработки, а также о её трудоёмкости. Из тестирования можно сделать выводы по полученным данным тестирования.
Представленный код обладает несколькими важными достоинствами относительно MPI, а именно:
* Единообразное и однократное описание форматов передаваемых данных, реализуемое в интерфейсе (контракте).
Самое важное — сериализация данных скрыта от прграммиста.
* Простая реализация вызов удаленных методов.
Учитывая, что MPI не реализует ни сериализацию, ни вызов удалённых методов, не понятно, к чему это тут.
Использование объектно-ориентированного подхода к разработке.
> А у нас с объектами! — И что?
Не показаны конкретные преимущества ООП при передаче сообщений.
Кроме того, вас не смущает то, что вы взяли «ассемблер» и сравнили его с «перлом» и сделали выводы:
* на ассемблере не удобно использовать регулярные выражения;
* на перле медленно копировать большие массивы?
Сравниваю только по той самой причине, что при всей своей странности (словно сравнение авторучек с булочками) вопрос возникал не один раз и не у меня одного. Захотелось покопать чуть глубже.
Насчет проверок Send-Receive: вот именно, что нигде не проверяется, для работоспособности примеров обязано быть по факту.
С некоторой точки зрения (не говорю, что она правильная и тем более — основная) MPI можно рассматривать как интерфейс удаленного копирования данных в память. С такой позиции сборщик мусора невозможен по определению.
Насчет странных кодов и замеров времени: каюсь, часть строк исходников в статье поубивал. Ибо и так слишком много source и слишком мало слов. Замеры времени не внешние.
Насчет краткости тестирования и реальных возможностей разработки. Тут могу сказать следующее: целью было посмотреть (но не досконально изучить и написать десяток книг на тему), насколько хорош может быть WCF, если рассматривать его с позиций MPI, беря последний за эталон. Соответственно, были выбраны достаточно простые примеры программирования на MPI и реализованы через WCF. По-моему, представленные результаты вполне адекватны цели. Разрабатывать? Да, возможно (вопрос «Зачем?» — это уже отдельный вопрос). Код с WCF понятнее? Мне кажется, что да.
Да, MPI не поддерживает сериализацию и вызов удаленных методов. А WCF это может, причем делает это достаточно элегантно. Почему бы в таком случае не записать это в плюс?
Соглашусь, показать преимущества ООП при передаче сообщений было бы полезно. Учту.
А что плохого в этих выводах? Ставят мне задачу в разработке софта по быстрому копированию массиов. Гляжу на выводы и использую то средство, которое удовлетворяет данным потребностям — ассемблер. В другой задаче, где требуется написать не слишком привередливый парсер строк, почему бы не использовать перл.
И ещё раз повторюсь, что мысль о том, можно ли использовать .NET для распределенных вычислений и как, возникла не у меня в голове. Мне лишь захотелось ответить на этот вопрос — желательно с пусть и не сложными, но примерами.
Спасибо за комментарии.
Насчет проверок Send-Receive: вот именно, что нигде не проверяется, для работоспособности примеров обязано быть по факту.
С некоторой точки зрения (не говорю, что она правильная и тем более — основная) MPI можно рассматривать как интерфейс удаленного копирования данных в память. С такой позиции сборщик мусора невозможен по определению.
Насчет странных кодов и замеров времени: каюсь, часть строк исходников в статье поубивал. Ибо и так слишком много source и слишком мало слов. Замеры времени не внешние.
Насчет краткости тестирования и реальных возможностей разработки. Тут могу сказать следующее: целью было посмотреть (но не досконально изучить и написать десяток книг на тему), насколько хорош может быть WCF, если рассматривать его с позиций MPI, беря последний за эталон. Соответственно, были выбраны достаточно простые примеры программирования на MPI и реализованы через WCF. По-моему, представленные результаты вполне адекватны цели. Разрабатывать? Да, возможно (вопрос «Зачем?» — это уже отдельный вопрос). Код с WCF понятнее? Мне кажется, что да.
Да, MPI не поддерживает сериализацию и вызов удаленных методов. А WCF это может, причем делает это достаточно элегантно. Почему бы в таком случае не записать это в плюс?
Соглашусь, показать преимущества ООП при передаче сообщений было бы полезно. Учту.
А что плохого в этих выводах? Ставят мне задачу в разработке софта по быстрому копированию массиов. Гляжу на выводы и использую то средство, которое удовлетворяет данным потребностям — ассемблер. В другой задаче, где требуется написать не слишком привередливый парсер строк, почему бы не использовать перл.
И ещё раз повторюсь, что мысль о том, можно ли использовать .NET для распределенных вычислений и как, возникла не у меня в голове. Мне лишь захотелось ответить на этот вопрос — желательно с пусть и не сложными, но примерами.
Спасибо за комментарии.
Насчет проверок Send-Receive: вот именно, что нигде не проверяется, для работоспособности примеров обязано быть по факту.
Почитайте всё-таки спецификацию MPI. У вас неверное представление. Я вам даже помогу немного. MPI: A Message-Passing Interface Standard, Version 2.2. Стр 42:
synchronous send: The sender sends a request-to-send message. The receiver stores
this request. When a matching receive is posted, the receiver sends back a permission-
to-send message, and the sender now sends the message.
Перевожу: синхронная посылка не буферизируется ни передатчиком, ни приёмником. Передатчик ждёт момента, когда приёмник выйдет на recv(), и затем передаёт. Все синхронизации происходят ватоматиески, «за кулисами», и не важно, первым вызовется send() или recv().
Остаётся вопрос, зачем, тем более не разобравшись и не аргументировав зачем, использовать не-stadard способ передачи и ещё записывать домыслы в минусы MPI?
С такой позиции сборщик мусора невозможен по определению.
Кхм. Во-первых, вполне возможен (даже для immediate посылок, которые неблокирующие, и основной код программы может «терять» ссылку на данные — у MPI-то она будет). А во-вторых, как тогда, по-вашему, работает MPI.NET?
Насчет краткости тестирования и реальных возможностей разработки.
Я не о том говорил. У вас нарушен логический порядок умозаключений в статье. Если делаете разработку программы — делаете выводы по разработке. Если делаете тестирование разработанной программы — выводы по тестированию. Но если вы делаете общие выводы, то нельзя их называть «выводы по тестированию».
А что плохого в этих выводах?
Они самоочевидны и следуют из самого назначения инструментов.
В статье, претендующей на научный стиль, вот такого быть не может:
вот именно, что нигде не проверяется, для работоспособности примеров обязано быть по факту
и этого тоже:
Насчет странных кодов и замеров времени: каюсь, часть строк исходников в статье поубивал. Ибо и так слишком много source и слишком мало слов. Замеры времени не внешние.
И как читатель долен вам верить? Если убрали что-то из кода — замените на троеточие, на комментарий — это стандартная практика. А так — может автор тут код поменял, а может ещё и там результаты тестирования подогнал?
Кроме того, ещё в первом комментарии я подчеркнул древность кода (pre-ANSI прототипы), сейчас так никто не пишет. Вывод? Код, скорее всего, не ваш.
«Передатчик ждёт момента, когда приёмник выйдет на recv()»… при этом приемник должен знать, что будет передавать передатчик, так как в общем случае на самих данных не написано, чем они являются. Например, я ожидаю получить количество элементов некоторого массива, а передатчик мне уже шлет значение какого-нибудь элемента, потому что где-то что-то я пропустил.
MPI.NET может работать аналогично тому, как работает Remoting — на основе объектов аренды, которые относительно неплохо цепляются к идее сборщика мусора. Но это большое и жирное ИМХО, подкрепить слова аргументами не могу.
Насчет самоочевидности выводов не могу согласиться. Есть жизненный пример: нужен софт, который должен удаленно загружать работой компы, собирать данные и отдавать в наглядном виде. Вроде и не кластер, вроде и не облако. Умные и опытные дяди говорят, что тут однозначно «MPI», потому что «распределенные вычисления». Я понимаю, что на .NET это поднять будет намного проще. Закономерный вопрос: что я потеряю, занимаясь вычислениями в .NET, а не в C, и что я потеряю, обмениваясь инфой через WCF, а не MPI. Теперь вижу цифры.
Код на C — не мой. Я за его авторство и не ручался, даже ссылку в списке литературы приложил.
MPI.NET может работать аналогично тому, как работает Remoting — на основе объектов аренды, которые относительно неплохо цепляются к идее сборщика мусора. Но это большое и жирное ИМХО, подкрепить слова аргументами не могу.
Насчет самоочевидности выводов не могу согласиться. Есть жизненный пример: нужен софт, который должен удаленно загружать работой компы, собирать данные и отдавать в наглядном виде. Вроде и не кластер, вроде и не облако. Умные и опытные дяди говорят, что тут однозначно «MPI», потому что «распределенные вычисления». Я понимаю, что на .NET это поднять будет намного проще. Закономерный вопрос: что я потеряю, занимаясь вычислениями в .NET, а не в C, и что я потеряю, обмениваясь инфой через WCF, а не MPI. Теперь вижу цифры.
Код на C — не мой. Я за его авторство и не ручался, даже ссылку в списке литературы приложил.
так как в общем случае на самих данных не написано, чем они являются
Написано. Параметр tag в send() / recv(). Конечно, если его устанавливать везде в одно и то же ничего не значащее число (как в ваших примерах)…
MPI.NET может работать аналогично тому, как работает Remoting — на основе объектов аренды, которые относительно неплохо цепляются к идее сборщика мусора. Но это большое и жирное ИМХО, подкрепить слова аргументами не могу.
MPI [...] С такой позиции сборщик мусора невозможен по определению.
Поспешные выводы — залог ошибок.
Есть жизненный пример: нужен софт, который должен удаленно загружать работой компы, собирать данные и отдавать в наглядном виде.
Тут не MPI или WCF нужен. Тут job queue нужна, а ей всё равно что на узлах запускать.
Хм… Видно, что на обе ваши статьи вы затратили определенное количество времени. Выпускались в качестве статей для университетских сборников?
Угадали.
Но, наверное, эти две статьи пока единственные из всего генерируемого мной потока макулатуры, которые могут быть ещё кому-то в какой-нибудь степени интересны.
Но, наверное, эти две статьи пока единственные из всего генерируемого мной потока макулатуры, которые могут быть ещё кому-то в какой-нибудь степени интересны.
Как я Вас понимаю. Писать статьи потому, что научрук требует их для отчетности наверх, а в итоге такая безполезная макулатура. Полезна разве что итоговая статья ведь, а не тезисы с десятка конференций.
Кстати, а очень хорошая идея публиковать статьи сюда научные. Так сказать, предварительная рецензия. И почитать будет что, а то надоели статьи из серии- я купил айчтототам и увеличил этим длину своего *** на n сантиметров, посмотрите какой я крутой. И несколько адекватных вопросов почерпнете может быть для себя.
Кстати, а очень хорошая идея публиковать статьи сюда научные. Так сказать, предварительная рецензия. И почитать будет что, а то надоели статьи из серии- я купил айчтототам и увеличил этим длину своего *** на n сантиметров, посмотрите какой я крутой. И несколько адекватных вопросов почерпнете может быть для себя.
А в первом примере, как я понимаю, у вас WCF приложения расположены на одной физической машине? Тогда логичнее использовать netNamedPipeBinding вместо netTcpBinding. По идее, так должно работать быстрее.
Спасибо, приятно прочесть приличную статью на хабре. Если бы мог дать грамоту за статью месяца я бы обязательно отдал ее Вам.
А теперь 5 копеек от меня.
Есть реализация обертки над MPI на .Net- как Вы можете догадаться называется MPI.Net сам не пробовал, говорят не без багов была года 2 назад, но обертка есть и причем рабочая.
osl.iu.edu/research/mpi.net/
mpinet.codeplex.com/
www.purempi.net/
Git-это хорошо. Но вопрос- а каким компилятором Вы собирали не .net версию программы? Просто уровень компилятора тоже важен, постоянно вижу как компилятор intel выигрывает у gcc, и компилятора ms. Если собрали не им, то попробуйте им и сравните результаты, если им, то укажите это в статье, а то докапаются когда будите представлять статью на конференции.
Я вот не понял зачем Вы на локальных узлах то тестировали. Просто на сколько я помню MPI- запускать на 1 машине- этот очень плохо. Ведь задача MPI -между машинное взаимодействие по сети. А внутри MPI уже используйте openmp, что бы задействовать все процессоры на машине. Я как бы догадываюсь, что у Вас дома нет целого кластера на 20 машин, но под это дело можно на кафедре выбить компьютерный класс и поставить, было бы желание.
А Вы как я понимаю запустили на каждом ядре по слейву mpiвскому. Память то общаю, они могут еще и бороться за ресурсы там.
Кстати, я очень люблю технологии MS, сам пишу на .Net в основном. Но вот незадача- на большинстве кластеров linux, причем какой нибудь из серии Red Hat Enterprise Linux. И Администратора фиг заставишь поставить тебе туда даже mono. Скорее тебе предложат переписать все на Java(что я сейчас и делаю. переписав свой расчет с C# на Java, а сейчас веселюсь с глючной openjdk и параметрами компиляции, что бы не вылетать по стеку.). Я искренне надеюсь, что скоро появится кластера с HPC SERVER, на котором можно будет использовать .Net и wcf нормально.
На счет скорости канала- на кластерах опять же не совсем то, что у Вас дома ведь. Там скорее всего какой-нибудь infiniband с очень малой латентностью и на самих машинах не какой нибудь медленный tcpip а что нибудь нормальное, что бы не было этой иеархии уровней. В общем все вместе вполне может повлиять на результаты.
Как всегда еще спросят про оптимизированные мат библиотеки из серии MKL, мол на .Net нет таких оптимизированных под архитектуры процессора библиотек, за счет которых можно получить кратный рост производительности. Затем прикопаются на тему оптимизации. Мол на .Net мы не контролируем процесс, нельзя сделать низкоуровневую оптимизацию и прочие такие аргументы.
Поверьте, я не придераюсь к Вам, я бы с радостью дал Вам грамоту за лучшую статью месяца. Но на представлении статью научной будет сидеть кто-нибудь из професуры, который с радостью задаст 10 тупых вопросов и еще 10 по делу. В которых как раз и окажутся все мои комменты.
Еще раз спасибо.
А теперь 5 копеек от меня.
Есть реализация обертки над MPI на .Net- как Вы можете догадаться называется MPI.Net сам не пробовал, говорят не без багов была года 2 назад, но обертка есть и причем рабочая.
osl.iu.edu/research/mpi.net/
mpinet.codeplex.com/
www.purempi.net/
Git-это хорошо. Но вопрос- а каким компилятором Вы собирали не .net версию программы? Просто уровень компилятора тоже важен, постоянно вижу как компилятор intel выигрывает у gcc, и компилятора ms. Если собрали не им, то попробуйте им и сравните результаты, если им, то укажите это в статье, а то докапаются когда будите представлять статью на конференции.
Я вот не понял зачем Вы на локальных узлах то тестировали. Просто на сколько я помню MPI- запускать на 1 машине- этот очень плохо. Ведь задача MPI -между машинное взаимодействие по сети. А внутри MPI уже используйте openmp, что бы задействовать все процессоры на машине. Я как бы догадываюсь, что у Вас дома нет целого кластера на 20 машин, но под это дело можно на кафедре выбить компьютерный класс и поставить, было бы желание.
А Вы как я понимаю запустили на каждом ядре по слейву mpiвскому. Память то общаю, они могут еще и бороться за ресурсы там.
Кстати, я очень люблю технологии MS, сам пишу на .Net в основном. Но вот незадача- на большинстве кластеров linux, причем какой нибудь из серии Red Hat Enterprise Linux. И Администратора фиг заставишь поставить тебе туда даже mono. Скорее тебе предложат переписать все на Java(что я сейчас и делаю. переписав свой расчет с C# на Java, а сейчас веселюсь с глючной openjdk и параметрами компиляции, что бы не вылетать по стеку.). Я искренне надеюсь, что скоро появится кластера с HPC SERVER, на котором можно будет использовать .Net и wcf нормально.
На счет скорости канала- на кластерах опять же не совсем то, что у Вас дома ведь. Там скорее всего какой-нибудь infiniband с очень малой латентностью и на самих машинах не какой нибудь медленный tcpip а что нибудь нормальное, что бы не было этой иеархии уровней. В общем все вместе вполне может повлиять на результаты.
Как всегда еще спросят про оптимизированные мат библиотеки из серии MKL, мол на .Net нет таких оптимизированных под архитектуры процессора библиотек, за счет которых можно получить кратный рост производительности. Затем прикопаются на тему оптимизации. Мол на .Net мы не контролируем процесс, нельзя сделать низкоуровневую оптимизацию и прочие такие аргументы.
Поверьте, я не придераюсь к Вам, я бы с радостью дал Вам грамоту за лучшую статью месяца. Но на представлении статью научной будет сидеть кто-нибудь из професуры, который с радостью задаст 10 тупых вопросов и еще 10 по делу. В которых как раз и окажутся все мои комменты.
Еще раз спасибо.
а сейчас веселюсь с глючной openjdk
Почему не используете обычный JDK? Он ставится даже без прав администратора куда-нибудь в ~/java без проблем.
Я искренне надеюсь, что скоро появится кластера с HPC SERVER, на котором можно будет использовать .Net и wcf нормально.
Не удержался. Vendor lock-in во всей красе. Кто использует MPI — запускает везде, даже под Windows. Кто использует WCF — ищет подходящий кластер.
Ошибся строчкой куда коммент ставить. Вам сообщение ниже адресовано.
+ к нему.
Кстати в jdk тоже кривовато на мой взгляд много чего. В частности работа с файловой системой. Если в JDK на Win взять абсолютный путь до файла, то получишь путь до джава машины, если тот же код запустить на lin, то получить путь до твой программы. Вот и думай, как и где это использовать.
Так, что не надо мне говорить про зацикленность на вендора, я использовал и lin и win. Есть с чем сравнивать, и поработав с HPC Server, мне он понравился. Мы его даже подняли сами нормально, при том, что как поднять кластер на linux я до сих пор считаю шаманством.
+ к нему.
Кстати в jdk тоже кривовато на мой взгляд много чего. В частности работа с файловой системой. Если в JDK на Win взять абсолютный путь до файла, то получишь путь до джава машины, если тот же код запустить на lin, то получить путь до твой программы. Вот и думай, как и где это использовать.
Так, что не надо мне говорить про зацикленность на вендора, я использовал и lin и win. Есть с чем сравнивать, и поработав с HPC Server, мне он понравился. Мы его даже подняли сами нормально, при том, что как поднять кластер на linux я до сих пор считаю шаманством.
Спасибо :)
Обертка действительно рабочая и, наверное, хорошая. Как и HPC Server.
На локальных узлах тестировал в основном из-за спортивного интереса. Соглашусь, что бОльший интерес представляет тестирование именно на удаленных узлах — но оно тоже представлено в не меньшей степени.
Насчет linux-кластеров и windows-программ. Действительно, кластера с Linux — это на сегодняшний момент некий стандарт. Однако можно смотреть на проблему распределенных ресурсов и с другой стороны — есть контора, в которой куча компов с обычной ЛВС. Причем на всех этих компах крутится windows, на которой крутится исключительно word и сапер. При этом есть ряд вычислительных ресурсоемких задач, которые можно как-то распараллелить. Вот и думаешь — а не пригодится ли тут WCF?
А касаемо профессоров… Эх, нам бы таких в провинцию… хотя бы парочку на область.
Обертка действительно рабочая и, наверное, хорошая. Как и HPC Server.
На локальных узлах тестировал в основном из-за спортивного интереса. Соглашусь, что бОльший интерес представляет тестирование именно на удаленных узлах — но оно тоже представлено в не меньшей степени.
Насчет linux-кластеров и windows-программ. Действительно, кластера с Linux — это на сегодняшний момент некий стандарт. Однако можно смотреть на проблему распределенных ресурсов и с другой стороны — есть контора, в которой куча компов с обычной ЛВС. Причем на всех этих компах крутится windows, на которой крутится исключительно word и сапер. При этом есть ряд вычислительных ресурсоемких задач, которые можно как-то распараллелить. Вот и думаешь — а не пригодится ли тут WCF?
А касаемо профессоров… Эх, нам бы таких в провинцию… хотя бы парочку на область.
При этом есть ряд вычислительных ресурсоемких задач, которые можно как-то распараллелить.
А вы не думаете, что у Infiniband не просто так такая высокая просускная способность и низкая латентность? Что многие задачи очень критичны ко времени передачи, и если оно зашкаливает, то последовательная программа быстрее параллельной?
не SUN JDK- Потому, что на кластере я не админ. Надо просить админа, мол поставь мне на 576 узлов JDK нормальную. На нем сейчас есть только openjdk.
Вот представьте себе. Запросил я себе произвольно 100 узлов, и мне что лапками на каждый заходить, и скидывать туда jdk, устанавливать, потом проверять есть ли она там или нет. Вы хоть представьте себе это и любое желание отобьет. Я конечно понимаю, можно в свою home директорию поставить, но тогда будут очень веселые сетевые эффекты с запросом чего то из моей папки на сотню мегабайт. Тем более что права есть только на свою директорию
Ах да, совсем забыл, я могу попасть на любую машину случайную ведь, на которой я не ставил jdk… Вот это fail. А если машину поднимут с золотого образа после падения то я хрен разберу причину почему у меня не стартовал расчет меньше чем за сутки(сначала понять что он не стартовал.я же не в интерактивной сессии сидеть буду в онлайн смотреть что там)
MPI- везде. MPI- это стандарт, а его реализации у всех разные. На Кластере вечно по 2-3 версии сидит. Не когда не знаешь, что тебе попадется на кластере, по этому собираешь из исходников на целевой машине всегда, иначе большая вероятность, что ни черта не запустится. Мы когда на MPI для ImagineCup кодили, дико облажались на том, что у меня на машине была одна mpi, а на счетной машинке другая. В итоге веселились с компиляцией и пере направлением вывода. И черт знает под чем собирется, а под чем нет. Я в Русскую рулетку не играю.
Так, что использоватние- MPI- дело тоже, не самое простое.
И на последок, а Вы на кластере вообще что-нибудь делали? Считали, администрировали? Если да, то расскажите как все просто, а ты мы тут мучаемся очень сильно.
Вот представьте себе. Запросил я себе произвольно 100 узлов, и мне что лапками на каждый заходить, и скидывать туда jdk, устанавливать, потом проверять есть ли она там или нет. Вы хоть представьте себе это и любое желание отобьет. Я конечно понимаю, можно в свою home директорию поставить, но тогда будут очень веселые сетевые эффекты с запросом чего то из моей папки на сотню мегабайт. Тем более что права есть только на свою директорию
Ах да, совсем забыл, я могу попасть на любую машину случайную ведь, на которой я не ставил jdk… Вот это fail. А если машину поднимут с золотого образа после падения то я хрен разберу причину почему у меня не стартовал расчет меньше чем за сутки(сначала понять что он не стартовал.я же не в интерактивной сессии сидеть буду в онлайн смотреть что там)
MPI- везде. MPI- это стандарт, а его реализации у всех разные. На Кластере вечно по 2-3 версии сидит. Не когда не знаешь, что тебе попадется на кластере, по этому собираешь из исходников на целевой машине всегда, иначе большая вероятность, что ни черта не запустится. Мы когда на MPI для ImagineCup кодили, дико облажались на том, что у меня на машине была одна mpi, а на счетной машинке другая. В итоге веселились с компиляцией и пере направлением вывода. И черт знает под чем собирется, а под чем нет. Я в Русскую рулетку не играю.
Так, что использоватние- MPI- дело тоже, не самое простое.
И на последок, а Вы на кластере вообще что-нибудь делали? Считали, администрировали? Если да, то расскажите как все просто, а ты мы тут мучаемся очень сильно.
Вот представьте себе. Запросил я себе произвольно 100 узлов, и мне что лапками на каждый заходить, и скидывать туда jdk, устанавливать, потом проверять есть ли она там или нет. Я конечно понимаю, можно в свою home директорию поставить, но тогда будут очень веселые сетевые эффекты с запросом чего то из моей папки на сотню мегабайт.
for i in $(seq 1 100500); do scp -r java node-$i:~/local/; done
Встречный вопрос: а на Windows фреймворк не надо разве ставить? :)
На Кластере вечно по 2-3 версии сидит.
Неправильный мёд?
Не когда не знаешь, что тебе попадется на кластере, по этому собираешь из исходников на целевой машине всегда
И это правильно. Бинарная переносимость между разными реализациями чего угодно — миф :) А если вдруг на кластере BSD попадётся, тоже будете ругаться, что линуксовые бинарники не стартуют?
Если да, то расскажите как все просто, а ты мы тут мучаемся очень сильно.
Для меня на *nix кластере всё проще, чем вы себе представляете. Что именно рассказать?
Если задачей не стоит написание своих алгоритмов, а использование уже существующих, имеет смысл посмотреть на такие библиотеки как Intel Math Kernel Library, которые уже имеют прямую поддержку MPI и могут быть использованы через P/Invoke.
UFO just landed and posted this here
Сама по себе идея перекладывать заботу о параллельности на плечи программиста — верх идиотизма, этим должна заниматься операционная система. Программисту, в большинстве случаев, абсолютно по барабану сколько ядер у процессора, он хочет одного — чтобы программа работала максимально быстро, и задействовала максимум свободных ресурсов машины в соответствии с профайлом энерго-сбережения.
А почему сравниваются MPI на си и WCF на .NET, как вроде на .NET больше ничего нет — ССR, MC#
Точнее сказать — сравниваются MPI на си и WCF в си# на .NET.
WCF — это технология удаленного взаимодействия, предоставляемая .NET Framework. Язык при этом может использоваться любой, для которого есть .NET-компилятор. И результаты бенчмаркинга от языка к языку сильно (вообще?) отличаться не должны, ибо IL в CLR.
Поэтому C# выбран из персональных предпочтений.
WCF — это технология удаленного взаимодействия, предоставляемая .NET Framework. Язык при этом может использоваться любой, для которого есть .NET-компилятор. И результаты бенчмаркинга от языка к языку сильно (вообще?) отличаться не должны, ибо IL в CLR.
Поэтому C# выбран из персональных предпочтений.
Не могли бы дать ссылки на CCR и MC#? что-то мой гугл этого не находит.
Сори за поздний ответ.
ccr: www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c185a802-5bbe-4f28-b448-aefe63a7eff7
mc# (они переименовались): www.parallelcsharp.com/
ccr: www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=c185a802-5bbe-4f28-b448-aefe63a7eff7
mc# (они переименовались): www.parallelcsharp.com/
Sign up to leave a comment.
Распределенные вычисления на платформе .NET