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

Питон будет тормознее однозначно. Зависит от ожидаемого количества траффика.

гоняешься за скоростью - не мелочись, пиши на фортране. серьёзно.

> То есть, этот решатель будет вызываться при каждом запросе клиента, загружаться-решать-выгружаться.

Лучше «FastCGI». ;-)

Только хотел саркастически предложить написать на питоне, как увидел это среди намерений. Даже не знаю, что предлагать теперь... Как насчёт brainfuck?

Я бы порекомендовал такой подход - сначала пишете все на python, потом анализируете узкие места, - очевидно, что ваше представление о них и реальность могут очень и очень различаться (например, окажется, что основная задержка идет при I/O, а не при вычислениях). Если окажется, что вычисления «тормозят» весь процесс - оформляете «числодробильный» функционал, как C-экстеншены, благо с помощью Cython переход от python-кода к C-коду очень и очень прост.

многопоточно

Если хотите производительности - пишите на ивентах. Тем более, если собираетесь на python писать. Ваша задача - идельный use case для Twisted.

lisp же!

> писать демона, который всё время будет сидеть в памяти, иметь входную очередь, отдавать «присосавшимся» процессам данные по мере обсчета

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

>состыковка и наложение со всякими условиями 100 массивов размером 10x10 элементов

сферические корейские быдлокодерские мыморпэгэ?

пищи на питоне, для массивов, матриц используй numpy, numarray, etc - они быстрые.
насчет twisted - хороший совет, но это не единственный вариант.
ну и да в крайнем случае перепишешь узкие места на c/cython/etc

> lisp же!

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

Без обид, но в наше время за «запустился-посчитал-отвалился», надо бы по жопе...

>> То есть, этот решатель будет вызываться при каждом запросе клиента, загружаться-решать-выгружаться.

Лучше «FastCGI». ;-)

Что вы имеете в виду?

> Что вы имеете в виду?

Имеется в виду то, что в FastCGI, в отличие от CGI (загружаться-решать-выгружаться), на каждый реквест не создается/убивается отдельный процесс.

Короче говоря, создавать на каждый запрос отдельный процесс (да и тред тоже, между нами говоря) - никому не нужная трата ресурсов.

> Без обид, но в наше время за «запустился-посчитал-отвалился»

А чем такой подход плох? Хотя бы пару весомых отрицательных влияний на сервер скажите.

затраты накладные на создание процесса, не?

Без обид, но в наше время за «запустился-посчитал-отвалился»

А чем такой подход плох? Хотя бы пару весомых отрицательных влияний на сервер скажите.

• Никому не нужный оверхед на создание процессов.
• O(n) затраты памяти при обработке фиксированным количеством процессов/тредов против O(?) при создании процесса/треда на каждый запрос

>весь процесс - оформляете «числодробильный» функционал, как C-экстеншены, благо с помощью Cython переход от python-кода к C-коду очень и очень прост.

и чего, нормально интегрируется со стандартным python? Можно поподробнее о схеме взаимодействия?

> Имеется в виду то, что в FastCGI, в отличие от CGI (загружаться-решать-выгружаться), на каждый реквест не создается/убивается отдельный процесс.

А к FastCGI можно легко и просто прикрутить взятую наугад программу, знающую только stdin и stdout? ;)

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

Если хочется очередь и демон решатель. Бери memcacheq и плюсы. Простое и дубовое решение, но работает.

> и чего, нормально интегрируется со стандартным python? Можно поподробнее о схеме взаимодействия?

Ну да, нормально интегрируется. Код, необходимый для взаимодействия с python-рантаймом генерируется автоматически.

Инструмент специально сделан для создания С-экстеншенов для python без обычной рутины со счетчиком ссылок и т.п. Посмотрите документацию - там все очень и очень просто.

>Инструмент специально сделан для создания С-экстеншенов для python без обычной рутины со счетчиком ссылок и т.п. Посмотрите документацию - там все очень и очень просто.

Ну я в FAQ ткнулся одним глазом, там чет все про свой синтаксис, и так далее =).

Вопрос же скорее по самой идее. Это серьезно ускоряет поделку, если выносить в самописные модули сишные модули все самое тормозное? Стоит усилий?

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

> А к FastCGI можно легко и просто прикрутить взятую наугад программу, знающую только stdin и stdout? ;)

Я, конечно, прошу прощения, но я как-то не рассматриваю решения на предмет «прикручивания» чего-либо к ним «наугад».

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

> Я, конечно, прошу прощения, но я как-то не рассматриваю решения на предмет «прикручивания» чего-либо к ним «наугад».

От того что появится конкретика, FastCGI не начнёт работать без переписывания самой программы. Что влом ;)

Хорошо.

Значит, будет серверная часть крутиться на PHP или Питоне. Заодно будет запущена программа-решатель в виде FastCGI сервера.

Вопрос. Как из PHP/Питона обращаться к FastCGI? Содавать TCP/IP соединение с этим FastCGI сервером, и обмениваться данными? Я правильно понял?

Там делается следующее - синтаксис практически полностью соответствует синтаксису python. Плюс добавляется возможность статического объявления переменных C-типов, тогда вместо PyObject, со всеми вытекающими последствиями для производительности, мы получаем «чистые» C-типы. Вообще, cython, по сути своей - это компилятор некого python-подобного языка в C.

Это серьезно ускоряет поделку, если выносить в самописные модули сишные модули все самое тормозное?

Если не просто взять и скопировать python-код в cython, а поработать с типами, то скорость выполнения кода будет близка ко скорости выполнения аналогичного C-кода (т.к. будет, как минимум, убран весь оверхед на работу с python-объектами).

>Пиши клиентскую часть на флексе

флеш сокеты

банальный раб адоба в треде! :)

Большое спасибо!! Очень интересно и надо будет покопаться

>банальный раб адоба в треде! :)
Отставим банальности, опенсорс сдк во все полянки.

флеш/флекс

1) контролируется одной корпорацией
2) имеет единственную полноценную реализацию клиента
3) эта самая реализация - проприетарное дырявое тормозное говно

Что толку от открытых сырцов sdk, если технология несвободна сама по себе?

> Значит, будет серверная часть крутиться на PHP или Питоне. Заодно будет запущена программа-решатель в виде FastCGI сервера.

Не вижу смысла. Если считать, что сервер и «программа-решатель» - две обособленные сущности (что, я считаю, несколько неоправданно, пока вы точно не выяснили, где у вас затык производительности), то достаточно использовать любой из доступных методов IPC (и это совершенно не обязательно должны быть сетевые сокеты) для общения между процессами и никакой FastCGI тут не при чем.

1)Дык многие вещи в опенсорсе тащит одна корпорация
2)Это минус, но зато клиент работает везде
3)Уж лучше многих

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

П.С.
Коль вы уж так осведомлены, предложите замену поддерживающую сокеты.

> Хотя бы пару весомых отрицательных влияний на сервер скажите.

Пару? Пару системных недостатков уже сказали. Теперь об архитектурных.

1.Как при таком раскладе будет осуществляться сессионность, еще одним костылем ? 2.Как при таком раскладе будет осуществляться балансировка? (медленных клиентов в начало очереди быстрых в конец)? 3.Возвращаясь к статистической оптимизации... при варианте «время жизни ==один запрос», про такие вещи можно забыть.

>> Значит, будет серверная часть крутиться на PHP или Питоне. Заодно будет запущена программа-решатель в виде FastCGI сервера.

Не вижу смысла. Если считать, что сервер и «программа-решатель» - две обособленные сущности (что, я считаю, несколько неоправданно, пока вы точно не выяснили, где у вас затык производительности), то достаточно использовать любой из доступных методов IPC (и это совершенно не обязательно должны быть сетевые сокеты) для общения между процессами и никакой FastCGI тут не при чем.

Ну как же, вы же сами сказали, что загружать-решать-выгружать некомильфо. Программа-решатель в виде FastCGI-сервера и будет решать эту проблему - все время находиться в памяти, принимать исходные данные и отправлять решение по TCP/IP или сокету или std-потоками (с std правда, не понял, как это делается).

Почему делать FastCGI решатель нету смысла?

>Дык многие вещи в опенсорсе тащит одна корпорация
хотя бы 3 примера на вскидку давай

Это минус, но зато клиент работает везде

они там 64 бита уже наконец осилили? А с мобильными девайсами как?
Работает везде - это скорее про netbsd :)
А за адобовское «вроде работает» под линуксом надо руки отрывать.

Уж лучше многих

нее, таких дырявых ведер больше нет. Даже творения Баллмера меркнут на его фоне.

нужно еще открыть как можно больше технологий, на которых она базируется. А у флеша много таких.

ага, а самое главное-то и забыли

предложите замену поддерживающую сокеты.

внезапно выскочившая из кустов зондеркоманда адоба не заметила, что тред совсем не о клиентской части

Сделайте модульную архитектуру, с «решателем» на питоне, если окажеться что производительности недостаточно - перепишите на C/C++.

> Сделайте модульную архитектуру, с «решателем» на питоне, если окажеться что производительности недостаточно - перепишите на C/C++.

Но в каком виде потом делать этот C/C++? В виде обычного CGI? В виде модуля, поднимаемого вместе с скриптом питона?

Демон будет думаю быстрее но тут проблемы с сокетами, слежение за памятью и тд. Вызов консольных прог в перле работает достаточно быстро, насчет питона не уверен - в худшем случае запуску проги будет предшествовать запуск полновесного баша. Хотя 100 массивов по сто элементов это смешная цифра, и питон тут достаточно быстр. Короче, дешевле всего считать в самой проге, хотя если сервер многопроцессорный...

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

>хотя бы 3 примера на вскидку давай
Рельсы - 37 signals, Опенофис - оракл(хотя форкнули конечно, но не понятно, что из этого выйдет), Qt - нокиа. Ну собственно даже ту же Mozilla создал, и сначала спонсировал Netskape

они там 64 бита уже наконец осилили? А с мобильными девайсами как?

64 бита вышла превьюшка, не знаю был ли релиз. На симбиан есть флэш лайт, на андроиде стандартный, флэш также можно экспортировать в приложение на айфон(но это уже из платной среды, не знаю есть ли свободный вариант). Ну и на nds, psp, ps 3, wii есть флеш плееры. Да и под линуксом сейчас аппаратное ускорение поддерживает и прочее.

внезапно выскочившая из кустов зондеркоманда адоба не заметила, что тред совсем не о клиентской части

От выбора клиентской сильно зависит выбор серверной. Если делать на простых http запросах, то там на каждом запросе оверхед 0.5 кб. При 4 запросах в секунду и 2000 пользователях одновременно, оно будет требовать канал 4Мб/с только на оверхед. Еще не считаем накладных расходов на установку соединения и прочего. Если делать на long poll, то тут будет проблема в 2000 висящих соединениях к апачу. А до сокетов на html5 пока далеко. То есть вариант клиент через флешевый сокет(само приложение может быть на яваскрипте) и сервер - демон на плюсах, гораздо производительнее. Недаром такую версию клиента использует gmail.

Почему делать FastCGI решатель нету смысла?

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

Имеет смысл использовать Python с numpy - будет не медленнее.
Но если не хочет заморачиваться со связкой языков, и написать на C, тогда используй CGI.

>Опенофис - оракл(хотя форкнули конечно, но не понятно, что из этого выйдет), Qt - нокиа.

И те и другие купили уже ГОТОВЫЙ продукт

>И те и другие купили уже ГОТОВЫЙ продукт
А trolltech и sun были не корпорациями?

>Недаром такую версию клиента использует gmail.

O_o Gmail же без флэша вполне работает.

Похоже я перепутал с каким-то другим сервисом. Гмыло использует обычный бесконечный iframe для этого, а флеш используется там для других вещей, ну и в гмайл чате для видео и аудио.

>Опенофис - оракл

Qt - нокиа. Ну собственно даже ту же Mozilla создал, и сначала спонсировал Netskape

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

64 бита вышла превьюшка, не знаю был ли релиз

7 лет прошло, а воз и ныне там.

Да и под линуксом сейчас аппаратное ускорение поддерживает и прочее.

пруфлинк кинь.

>Если делать на простых http запросах, то там на каждом запросе оверхед 0.5 кб.

цифирь с потолка взял? :)

тролльтех это мелкая компания, фактически стартап-переросток, да и открыли Qt не сразу; а жаба изначально коммерческая технология и тоже изначально закрытая

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

7 лет прошло, а воз и ныне там.

Ну дык тот же хром написанный недавно не поддерживает 64-bit, не так то уж просто переписать некоторые вещи. Но тестовая версия работает на 64-bit сейчас нормально.

пруфлинк кинь.

http://habrahabr.ru/blogs/linux/76454/ - здесь инструкция

цифирь с потолка взял? :)

Нет, на кулькуляторе посчитал. http://ru.wikipedia.org/wiki/HTTP заходим сюда, берем первый пример диалогов http(обычный GET запрос), и считаем количество байт, получаем 436 байт, и это без куков. А можно еще вспомнить, что через хттп мы пересылаем данные текстом, а через сокеты бинарно, то разница в размерах будет еще больше.

>тролльтех это мелкая компания, фактически стартап-переросток, да и открыли Qt не сразу; а жаба изначально коммерческая технология и тоже изначально закрытая
Так я и говорю, что флеш своим развитием довольно похож на развитие этих технологий.

>Там в основном патчи отсылают.
вот о чем и разговор, что реально в разработке никто кроме адоба не участвует. Приводить ту же мозиллу в качестве аналога просто смешно.
Да и у того же опенофиса еще до форка развилась куча достаточно толстых веток.

Ну дык тот же хром написанный недавно не поддерживает 64-bit

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

http://habrahabr.ru/blogs/linux/76454/ - здесь инструкция

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

берем первый пример диалогов http(обычный GET запрос), и считаем количество байт, получаем..

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

А можно еще вспомнить, что через хттп мы пересылаем данные текстом, а через сокеты бинарно

Только сегодня! Экстрасенс вспомнил то, чего никогда не знал :)
man content-encoding, Content-Type
Мог бы для начала дочитать ту статью в педивикии, там ближе к концу есть пример про пересылку жпегов.
Кстати, в этом твоем флексе при передаче есть возможность прозрачно сжать данные (gzip например)?