Служба\демон под кластер на C#\C++
Стоит такая задача (самостоятельно поставленная): написать серверную часть MMO-игры. По приблизительным прикидкам, она окажется чрезвычайно ресурсоемкой, ввиду чего планируется развертывание на кластере.
Однако, никогда ничем подобным не занимался, в связи с чем вопросы: как и на чем. Последнее интересует в первую очередь.
Писать сие чудо я планирую на C#. Но это накладывает ограничения на ОС - нужна платформа с поддержкой .NET Frmaework.
Альтернативой является С++ (вероятнее всего QT).
Хочется выслушать ваше мнение:
- Возможно ли такое в принципе с использованием C#?
- Какую ОС разворачивать на кластере?
- Нужны ли какие-нибудь дополнительные ухищрения, или достаточно будет использования родных компонентов фреймворка?
Или добавить в программу возможность распараллеливания (например MPICH)
Или добавить в программу возможность распараллеливания (например MPICH)
Ммм... это даст какой-то выигрыш в сравнении с C#?
В принципе, кросс-платформенность меня в С++ очень прельщает, также как гибкость и близость (в сравнении с C#, Java) к машинному языку, но неприятно мне на нем писать. Вот на том же ассемблере - приятно, а С++ вызывает отвращение... =\
Хм... а что делает MPICH? Статья на вики какая-то странная... с середины, без начала и конца. Библиотека для создания параллельных тредов? А что - родных средств в С++ для этого нет?
То есть кластер по сути ничем не отличается от многоядерного процессора? Все то же параллельное программирование без каких-либо изменений?
Как минимум(!!!) скорость больше и размеры меньше.Это как минимум
...
Любой язык компилирующийся в машинные коды даст преимущество по скорости перед байт-кодом
...
В принципе, кросс-платформенность меня в С++ очень прельщает
...
c# в линухе под моно можно крутить. java вообще очень кросс-платформенная. pascal - компилеры есть кросс-платформенные.
...
но неприятно мне на нем писать.
...
C# по синтаксису от него не далеко ушел. Только за памятью надо самому следить.
...
Хм... а что делает MPICH? Статья на вики какая-то странная... с середины, без начала и конца. Библиотека для создания параллельных тредов?
...
Нармальная статья, с ссылками, всё как положено :)
Библиотека не для создания параллельных потоков а для создания параллельных процессов. Используется для параллельных вычислений.
Т.е. у тебя будет запущен не один монолитный сервер на весь кластер, а много процессов сервера, выполняемых на разных узлах.
Отличие MPI от MOSIX прочитай.
...
А что - родных средств в С++ для этого нет?
...
а) Реализация потоков платформозависима и не входит в стандарт c++.
б) Параллельные вычисления != многопоточности
...
То есть кластер по сути ничем не отличается от многоядерного процессора? Все то же параллельное программирование без каких-либо изменений?
В зависимости от реализации кластера.
Java рассматривается в качестве языка для написания клиента (опять же наравне с С++), но о том чтобы писать серверную часть на ней даже и не думал - бессмысленно. Он вобрал в себя все худшее из C#, имеет массу бессмысленных ограничений и не дает даже помыслить о том чтобы навести на юзверя незаряженное ружье (но при этом сохраняя возможность застрелиться, не имея ружья).
С Mono не сталкивался. Погляжу. Но если окажется, что это чудо аля Java, то опять же лучше уж С++. Погуглю, посмпотрю!
Касательно MPICH все еще не до конца понятно. Когда у меня один процесс и тысяча потоков, которые считают каждый свой кусочек данных - это понятно. Посчитали, сложили в кучку, синхронизировали, если надо. А как общаются между собой разные процессы? Не прямым же доступом к физической памяти. Про отличия почитаю.
Большое спасибо за развернутый ответ! Буду гуглить, буду викить. Но вопрос по производительности байт-кода остается открытым. Интересно не только в рамках текущего проекта, но и вообще. И конечно же на реальных проектах, а не тестовом цикле в пару миллионов итераций. :)
...
Если 10% не критично, то кластер ни к чему.
...
Java рассматривается в качестве языка для написания клиента (опять же наравне с С++), но о том чтобы писать серверную часть на ней даже и не думал - бессмысленно. Он вобрал в себя все худшее из C#, имеет массу бессмысленных ограничений и не дает даже помыслить о том чтобы навести на юзверя незаряженное ружье (но при этом сохраняя возможность застрелиться, не имея ружья).
...
Java лет так на 5 раньше c# появилась, такчто кто с кого что собрал - тут вполне понятно.
На java есть например l2j, который вполне шустро работает.
...
С Mono не сталкивался. Погляжу. Но если окажется, что это чудо аля Java, то опять же лучше уж С++. Погуглю, посмпотрю!
...
Это интерпретатор c# для linux. Т.е. сборка c# exe или dll выполняется по средством .net framework под виндой и mono под linux. Накладывает некоторые ограничения на написание кода.
Он вобрал в себя все худшее из C#
При всем своем желании не мог так сделать. =)
и не дает даже помыслить о том чтобы навести на юзверя незаряженное ружье (но при этом сохраняя возможность застрелиться, не имея ружья).
Можно поподробней что вы имеете ввиду. Я понимаю, что вы скорее всего просто поклонник .Net и вражеская програмная платформа вам заведомо представляется в негативнойм свете. Но все же не понятно на чем вы совсем уж такие доводы мрачные строите. )
С Mono не сталкивался.
Да и не стоит - хотите писать под .Net - пишите под винду. Mono довольно кастрированный .Net и практического смысла ориентироваться на него для разработки с нуля нет.
10% действительно не критично. Будет некий глобальный цикл (только не понимай буквально) обсчитываться за 100мс или за 110мс - значения не имеет совершенно. А вот то, что обсчитывать нужно будет порядка 3-4 миллионов объектов и эта цифра будет расти вплоть до 30 миллионов в пике - критично и ресурсов одного компьютера тут явно не хватит.
На java есть например l2j, который вполне шустро работает.
При всем своем желании не мог так сделать. =)
Да, господа, вы совершенно правы. Но тут я говорю просто по мере знакомства с языками. Вначале был С++, затем C#, затем ява. Так что для меня она как раз "вобрала". Тем не менее, за те же пять лет после ничто не мешало ей посмотреть на C# и скомуниздить из него все лучшее (равно как из С++ и других языков, благо они не патентуются). А то что это нужно, наглядно подтверждают различные ее вариации и надстройки:
http://blog.jetbrains.com/kotlin/2012/01/kotlin-web-demo-is-out/
Да и не стоит - хотите писать под .Net - пишите под винду. Mono довольно кастрированный .Net и практического смысла ориентироваться на него для разработки с нуля нет.
Спасибо, понял. :)
Можно. Да, я поклонник .NET. И так уж получилось, что я оказываюсь поклонником всякого продукта мелкомягких (кроме Vista, Win8 и IE :D ), продолжая при этом их материть на чем свет стоит. С учетом всех негативных моментов, их продукты оказываются донельзя приятны в использовании, хотя функциональностью нередко вызывают желание придушить разработчиков.
Вместе с тем, на яве я сейчас пишу (приходится писать по работе) и мрачные доводы возникают по мере освоения.
Во-первых, такое ощущение, что на тебе подарили конструктор "собери сам". При этом не красивую коробочку Lego, а три мешка деталей из разных наборов. И делай с ними что хочешь.
Во-вторых у C# есть одно преимущество - ты не видишь его исходников, пока не залезешь рефлектором. А значит перлы разработчиков остаются за кадром. В Java весь тот ужас, что творится в базовых классах обрушивается, как снег на голову. И вместо того чтобы сесть и спокойно написать программу, я писал свою реализацию обертки потока вывода (аля Console в C#). Писал Linq, и много чего еще.
В процессе выяснилось, что Ява не дает сделать вообще ничего, общаясь с программистом как с клиническим идиотом. И помимо бесконечных throw\catch. Ладно, в процессе выяснилось, что вся ее напускная забота о безопасности - пшик. Чего стоит, например, изменение final static полей? Ну это же бред - запрещать это делать в одной версии. Строго запрещать (в том плане, что один из обходных путей через отражение не работает) в другой. И при этом оставлять возможность через тоже отражение, но с еще большим извратом, таки сделать изменить значение поля! Это нормально?!
Ну и в дополнение откровенный идиотизм, вроде отсутствия беззнаковых чисел, предопределенных параметров в методах и т.д. на фоне бесконечных getProperty / setProperty (неужто сложно было слямзить свойства с .NET? или реализовать скрыто, в том же Eclipse? >_>).
Так что, если бы я придирался только к непривычному мне именованию методов с маленькой буквы и выпирающими забором буквами последующих слов - это одно. Но Java мне представляется кошмарным сном, одинаково страшным и для .NET'овца и для C++'овца. :)
Но эт к теме относится только в той мере, что пока есть альтернативы, я скорее буду писать на плюсах, чем на Яве. :)
...
Во-первых, такое ощущение, что на тебе подарили конструктор "собери сам". При этом не красивую коробочку Lego, а три мешка деталей из разных наборов. И делай с ними что хочешь.
...
Это и есть программирование. Добро пожаловать в наш скромный уголок.
...
И вместо того чтобы сесть и спокойно написать программу, я писал свою реализацию обертки потока вывода (аля Console в C#).
...
Вобще не понял чем стандартные методы не устроили оО
...
В процессе выяснилось, что Ява не дает сделать вообще ничего, общаясь с программистом как с клиническим идиотом.
...
А c# просто уже уверен что прогер идиот, поэтому пристально следит за ним втихаря.
...
И помимо бесконечных throw\catch.
...
А в c# их какбудто нет. Причем их тоже желательно обрабатывать.
...
Чего стоит, например, изменение final static полей?
...
С каждой версией они усиливают защиту от тех идиотов, которые хотят менять такие поля. Да и в C# я уверен тоже есть методы модификации const.
...
Ну и в дополнение откровенный идиотизм, вроде отсутствия беззнаковых чисел, предопределенных параметров в методах и т.д. на фоне бесконечных getProperty / setProperty (неужто сложно было слямзить свойства с .NET? или реализовать скрыто, в том же Eclipse? >_>).
...
В C++ тоже нет свойств как таковых. BCB,MSVC++,Qt на уровне компилятора(препроцессора?) поддерживает. Но тем неменее в vc++ и qt восновном используются getX и setX
...
Но Java мне представляется кошмарным сном, одинаково страшным и для .NET'овца и для C++'овца. :)
...
Несогласен.
Началось все с того, что NetBreans мне сказал, что System.out.print используется для вывода отладочных данных и его использование может являться ошибкой забывчивого программиста. Ну и пошло-поехало. В итоге я пришел к выводу, что родной
Console.WriteLine("Var = {0}", var);
С настраиваемым буффером и кодировкой мне нравится больше, чем
System.out.printf("Var = %s", var);
ну а в конце сделал два варианта вывода - Print выводит в виде текста, Write - байтами. В общем, мне моя реализация нравится больше, чем родная. А учитывая, мои кривые руки и то, что Java я вижу впервые, это значит, что родная реализация до ужаса дурацкая.
Кстати, еще один камень в огород Java: это ж надо было додуматься все сравнивать по ссылкам с невозможностью перегрузки (как и прочих операторов)! В общем, ужас! :)
За что я ему благодарен. :)
Есть. Но они не обязательны. Я могу в шапке программы обрабатывать все поступающие исключения, а откуда они идут (в большинстве случаев) не важно. В Java это бесконечные строки throws в описании методов. Одно дело - отключаемые вонинги. Другое - обязательные к реализации. Ужас.
И при этом сами используют аналогичные варианты для установки тех же System.out/in/err ;)
Это очень печально.
Тем не менее С++ не навязывает инкапсуляцию, в отличии от Java (если верить IDE, которые сильно ругаются, когда используешь поля вместо свойств).
Возможно даже справедливо. У тебя явно опыта больше, и в С++ и в Java, чем у меня. Пожуем - увидим.
P.S. Но мы отклонились от темы. ^_-
Свойста не делают целенаправленно ибо считаетются они вредными и ненаглядными в той идеологии. И это очень хорошо что их нет. И скорее всего никогда не будет.
Но Java мне представляется кошмарным сном, одинаково страшным и для .NET'овца и для C++'овца. :)
Самое смешное, что C# представляется тем же для Java программиста. А все С-подобные языки кошмаром для постигших просветления. =))
Однако не будем разводить тут холиваров - все же ваши доводы это дело привычки, а не объективные факты. )
Тема, похоже, также себя исчерпала, так как по приблизительным прикидкам, для поставленной задачи вполне должно хватить 8-процессорного сервера на базе AMD Opteron. В дальнейшем, если проект приобретет популярность, то для связи серверов таки будет использован кластер из подобных машин. Однако на данный момент это бессмысленно.
Однако, спасибо всем отписавшимся. Я приобрел некое понимание о том, что есть кластер и с чем его едят. В будущем буду знать - в какую сторону копать. :)
1) если софт серверный то речи о кроссплатформенности как правило (а для игрушек в особенности) нету - платформа фиксируется той, на которой лучше всего работает этот софт
2) производительность распределенного приложения - линейная функция от количества серверов: работает медленно? - добавляем еще памяти и процессоров
3) без опыта игростроения начинать разрабатывать можно на чем угодно - почти наверняка первую версию придется выбросить и начать заново :)
4) .NET для разработки 24/7 софта вполне подходит (Erlang, Java и т.п. тоже, но видимо автору ближе .NET) - критичные к производительности участки кода всегда можно вынести в нативный код (это справедливо для любых платформ), но сперва нужно а) получить проблемы с производительностью, а это значит что нужно сначала создать рабочий прототип системы б) выявить проблемные места и понять что они не устраняются алгоритмическими оптимизациями
P.S. Спор о языках особнно доставил :))
P.S. На Erlang гляну - впервые слышу, посмотрю что за зверь.