Высокая нагрузка: имеет ли смысл сделать бинарник на C/C++ для вычислений?

>через хттп мы пересылаем данные текстом, а через сокеты бинарно

а я то думал, хттп работает поверх сокетов. век живи, век учись...

лично я щетаю, что сначала определяешь архитектуру, затем пишешь приложение, затем, если производительность не устраивает - профилируешь и оптимизируешь. НИКОГДА не нужно заниматься предварительной оптимизацией. Так завещал нам сам Керниган, емнип.

> НИКОГДА не нужно заниматься предварительной оптимизацией.

Никогда не надо следовать советам дословно, а то сдуру и хер сломать можно. А вопрос, кстати, из разряда проектировочных. В противном случае ТС либо будет постоянно переписывать «не тот вариант реализации», либо обращивать костылями и подпорками глюкодром.

Кстати еще один вариант. Налабать сначала демон на интерпретируемом ЯП и тесткейс к нему, после предварительных модельных замеров уже выбирать инструмент. Правда такой способ немножко дольше.

>серьезно? А чего же мне гугль предлагает загрузить google-chrome-stable_current_amd64.deb ? :)
Если нет версии под семерочку, то не считается.

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

Можно слать, как жпеги, но там в любом случае бинарные данные неудобно и медленно(ну только если не в хроме, который есть далеко не у всех) обрабатывать через яваскрипт и оверхед тот же.
А еще если бы вы прочитали чуть дальше, то прочитали бы, что http обрубает tcp сессии(может и не рвать, но браузеры рвут после полной загрузки страницы). Тут тоже оверхед сильный.

... цифру с потолка, как я и думал :)

Если так, то какой тогда оверхед? С учетом входящего траффика приема гет запросов от браузера, и исходящего.

Кстати, в этом твоем флексе при передаче есть возможность прозрачно сжать данные (gzip например)?

Можно подключить порт zlib, можно использовать встроенную сжималку.

П.С.
Вы просто себе не очень представляете архетиктуру многопользовательской компьютерной игры похоже. Там с легкостью может быть несколько тысяч пользователей(это будет далеко не самая топовая игра), которым нужно заиметь пару, а то и десяток обновлений в секунду.

>а я то думал, хттп работает поверх сокетов. век живи, век учись...
Криво выразился я тут. Просто через сокет можно получить 100 байт сообщение и никаких накладных расходов. А через http приходится создавать tcp сессию, слать заголовок, получать заголовок ответа и потом получать 100 байт.
Да и comet через http тоже печально работает, апач штук 700-1000 коннекшенов может обрабатывать одновременно на нормальном сервере только.

>Сейчас размышляю над устройством программной начинки игрового сервера, на котором должны происходить серверные обсчеты игровой ситуации (состыковка и наложение со всякими условиями 100 массивов размером 10x10 элементов).

ИМХО, для этого С++ - то, что доктор прописал. Скорость + богатые возможности ООП

>А через http приходится создавать tcp сессию, слать заголовок, получать заголовок ответа и потом получать 100 байт.

А с флеша ты по UDP шлёшь? Какую-то кашу ты тут навалил. К тому же, минимальные заголовки весят почти ничего. К тому же, есть gzip. К тому же, HTTP 1.1 умеет слать запросы по одному соединению.

> апач штук 700-1000 коннекшенов может обрабатывать одновременно на нормальном сервере только

Так это же апач. Вы знаете, как его стандартный mpm работает? С такой моделью вы больше (без неразумных затрат) и не обработаете.

Подписываюсь под каждым словом.

>Если нет версии под семерочку, то не считается.
а тут уже другая проблема, на венде тоже еще 64 бита нормально не осилили, даже сами мелкомягкие. Все через кучу костылей, и в итоге как обычно получилась помойка.

но там в любом случае бинарные данные неудобно и медленно(ну только если не в хроме, который есть далеко не у всех) обрабатывать через яваскрипт и оверхед тот же.

а почему обязательно жаваскрипт? HTTP != браузеры

А еще если бы вы прочитали чуть дальше, то прочитали бы, что http обрубает tcp сессии

опять в лужу сел. По стандарту можно не закрывать соединение. Собственно, после твоих заявлений «по хттп передается только текст» дальше разговаривать смешно. Матчасть и баннерописатели, как обычно, не совместимы.

Если так, то какой тогда оверхед?

действительно :) Ну поищи еще, может найдешь

Вы просто себе не очень представляете архетиктуру многопользовательской компьютерной игры похоже.

смешно слышать от человека, который банальный http даже в общих чертах не осилил

>А с флеша ты по UDP шлёшь?

т-с-с, не ломай психику мальчику. Он думает, что флеш сокеты через астрал работают.
А то вдруг еще разочаруется в любимом адобе и сиганет с крыши

>А с флеша ты по UDP шлёшь?
Tcp, но сессия не рвется.

Какую-то кашу ты тут навалил. К тому же, минимальные заголовки весят почти ничего. К тому же, есть gzip.

А gzip процессорное время из страны эльфов будет брать?

К тому же, HTTP 1.1 умеет слать запросы по одному соединению.

HTTP 1.1 может это делать, как и браузеры поддерживают SVG. То есть стандарт есть, но каждый делает это по своему, и не всегда.

>а тут уже другая проблема, на венде тоже еще 64 бита нормально не осилили, даже сами мелкомягкие. Все через кучу костылей, и в итоге как обычно получилась помойка.
Но тем не менее винда стоит на большинстве юзерских компов, как собственно и флеш.

а почему обязательно жаваскрипт? HTTP != браузеры

А собственно у кого-то есть идеи использовать http в качестве протокола для общения какого-нибудь игрового клиента, кроме браузера?

опять в лужу сел. По стандарту можно не закрывать соединение. Собственно, после твоих заявлений «по хттп передается только текст» дальше разговаривать смешно. Матчасть и баннерописатели, как обычно, не совместимы.

Настолько Ъ что не читаем даже 3 слова рядом? "(может и не рвать, но браузеры рвут после полной загрузки страницы)"

действительно :) Ну поищи еще, может найдешь

Собственно все понятно, отрицаем и смеемся, и ни одного слова по делу, никаких цифр, и ни одной предложенной альтернативы.

В общем использую право ответного пруфа, и жду пруфов на 3 популярные браузерные игры(не MUD-подобные, и не БК-подобные), не использующие флэш.

>как собственно и флеш
ничего, еще десяток дырок опубликуют, и его начнут антивирусы выпиливать, как руткит

А собственно у кого-то есть идеи использовать http в качестве протокола для общения какого-нибудь игрового клиента, кроме браузера?

а кто мешает? Это тебе не флеш, тут выбор клиента никто не ограничивает. Но хттп тут тоже особо не нужен, как и флеш.

может и не рвать, но браузеры рвут после полной загрузки страницы

а браузеры тут при чем?

Собственно все понятно, отрицаем и смеемся

конечно. Что же еще делать, когда ниасилившая матчасть школота делает громкие заявления

>А gzip процессорное время из страны эльфов будет брать?

На твои 100 байт, думаю, можно и оттуда. :)

HTTP 1.1 может это делать, как и браузеры поддерживают SVG. То есть стандарт есть, но каждый делает это по своему, и не всегда.

Мне нечего сказать, кроме УМВР. :(

>и жду пруфов на 3 популярные браузерные игры

эээ.. А я где-то заявлял, что такие есть (хотя они может даже и есть, просто я не играю в такое)? Или может я где-то заявлял, что голый браузер лучше флеша?

Ну называть человека банальным рабом, когда он советует общепринятый принцип, у которого нет приемлимых альтернатив, это подходит под формат такого заявления?

>На твои 100 байт, думаю, можно и оттуда. :)
Ну эти 100 байт нужно будет жать примерно 10 раз в секунду для каждого из 2000-3000 тыс. пользователей, получаем где-то 20000-30000 раз в секунду. При этом сервер собственно и работать еще должен будет.

Селф фикс,

2000-3000 тыс. пользователей

Это надо еще дорасти, вероятнее 2000-3000 пользователей.

>Ну называть человека банальным рабом, когда он советует общепринятый принцип, у которого нет приемлимых альтернатив

в случае написания очередного браузерного фармвилля флеш действительно общепринят, и у него пока что нет развитых альтернатив. Это все так.
Вот только мы же не про браузерный хлам разговариваем, ага?

А за такой же вопрос, но в связке Tcl+R меня здесь не побьют? Можно как-то реализовать обмен данными между Tcl и R скриптом минуя сохранение в файл и загрузку-выгрузку R?

Ну неужто мы говорим про архаичные PC игры, для которых надо еще и качать клиент?

>А за такой же вопрос, но в связке Tcl+R меня здесь не побьют? Можно как-то реализовать обмен данными между Tcl и R скриптом минуя сохранение в файл и загрузку-выгрузку R?
Пару лет назад я в универе с ним работал. Там можно было в качестве базы использовать мускуль вроде. И с помощью его можно осуществить обмен данными.

>Ну неужто мы говорим про архаичные PC игры, для которых надо еще и качать клиент?

а что, на флеше уже можно сделать что-то сложнее игрушек 10 летней давности?

Можно и делают. И вообще, ОП планировал писать серверную часть на PHP, весьма маловероятно, что здесь речь идет о клиенте на С++.

>Ну эти 100 байт нужно будет жать примерно 10 раз в секунду для каждого из 2000-3000 тыс. пользователей

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

Советую принять на веру: сжать 100 килобайт и передать результат будет быстрее, чем передать эти же несжатые данные по TCP.

>Можно и делают.
пример в студию. Что-то сравнимое хотя бы с half-life 2

ОП планировал писать серверную часть на PHP, весьма маловероятно, что здесь речь идет о клиенте на С++.

а кто запрещает писать клиент на плюсах? Я такую связку делал, правда задача была совсем другая, не игрушки.

>пример в студию. Что-то сравнимое хотя бы с half-life 2
Лень искать, чукча писатель, а не читатель, в игры не играю. Да и оценивать уровень игры - графикой, немного (унизительный, но вежливый эпитет подбирать тоже лень, представьте, что он тут был). У флэш игр своя аудитория, и эти игры полностью удовлетворяют потребности этой аудитории. http://en.wikipedia.org/wiki/Don't_Look_Back_(video_game) вот эта игра мне понравилась, например.

а кто запрещает писать клиент на плюсах? Я такую связку делал, правда задача была совсем другая, не игрушки.

Можно конечно собрать такой троллейбус, но зачем?

>Советую принять на веру: сжать 100 килобайт и передать результат будет быстрее, чем передать эти же несжатые данные по TCP.
Не 100 килобайт, а 30000 раз по 100 байт. Тут есть ощутимая разница. Это как поднять одну гантелю, или столько же лежащих на полу спичек.

> входном консольном потоке получать исходные данные, а в выходной поток будет пихать решение.

входном консольном потоке

выходной поток

не кажется ли, что это будет весьма тормозными местами?

>Не 100 килобайт, а 30000 раз по 100 байт. Тут есть ощутимая разница. Это как поднять одну гантелю, или столько же лежащих на полу спичек.

Сжиматься все равно будет неплохо. В любом случае, узкое место будет совсем не в оптимизированном алгоритме сжатия.

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

Да и оценивать уровень игры - графикой, немного

почему только графикой? У второй халвы в техническом плане много плюшек, до которых тормозящему браузерному плагину еще очень далеко. Физика, большие карты.
Так что пока на флеше не осилят сделать хотя бы близкое к этой старой игрушке, говорить о том, что небраузерные игры устарели, могут только самые глупые рабы адоба.

У флэш игр своя аудитория,

вот именно. Пусть там и остается со своими трехмерными тетрисами, ставящими раком двухъядерник.

Можно конечно собрать такой троллейбус, но зачем?

удобно, быстро, качественно. Я бы сильно удивился, если бы мне предложили переписать тот проект на флеше.

>ну так и молчал бы сразу, зачем воздух портить
Кто-то еще ни привел ни одного пруфа, и говорит про порчу воздуха.

почему только графикой? У второй халвы в техническом плане много плюшек, до которых тормозящему браузерному плагину еще очень далеко. Физика, большие карты.

Физика на флешевых играх есть, как и большие карты без подгрузки

вот именно. Пусть там и остается со своими трехмерными тетрисами, ставящими раком двухъядерник.

Ололо, это уже напоминает холивар о том, что лучше, велосипед или танк. http://www.onemorelevel.com/top10/drawing_games вот таких игр хоть парочку кроссплатформенных(чтобы и на андроиде шло) и бесплатных(ну хотя-бы меньше 10$ зарубежом чтобы стоила) перечисли, чтобы было о чем говорить. Не у всех есть многие часы на большие игры, кто-то(которых большинство) играет по полчаса в день, раз в неделю, и не хочет тратить 10-ки $ на полчаса игры.

удобно, быстро, качественно

Клиент на С++ общающийся с сервером на PHP через HTTP - это удобно, быстро, качественно?

>Кто-то еще ни привел ни одного пруфа
кто-то тут так и не смог объяснить, что же я должен все таки доказывать ;)

Физика на флешевых играх есть, как и большие карты без подгрузки

так не стесняйся, показывай

вот таких игр хоть парочку кроссплатформенных(чтобы и на андроиде шло) и бесплатных

зачем? Я же говорю, пусть остаются там где сидят вместе со своим флешем.

Клиент на С++ общающийся с сервером на PHP через HTTP - это удобно, быстро, качественно?

а что удивляет? За пределами рабства адоба есть жизнь. Без багов, тормозов и постоянных дырок.