На чем писать сервер - Java or C/C++

[badger]

Те сервера, что я писал на Python (CPython), справляются с нагрузкой лучше, чем то, что использовалось до того, написанное на Java с потоками.

Плохо написать можно на любом языке, это не очень хороший показатель.

-Maxim

Показатель то, что использовались треды там, где не надо было. На любом можно плохо написать, да. Но написать плохо с тредами проще, чем написать плохо без тредов. Threads are evil, как известно

Ну а Python vs Java я к тому, что Python -- язык более высокого уровня. Опять же, плохо написать на языке более высокого уровня сложнее, чем плохо на языке более низкого.

[sobomax]

Threads are evil, как известно

Это вы их просто готовить не умеете.

-Maxim

[Stanislav]

Те сервера, что я писал на Python (CPython), справляются с нагрузкой лучше, чем то, что использовалось до того, написанное на Java с потоками.

Плохо написать можно на любом языке, это не очень хороший показатель.
-Maxim

Показатель то, что использовались треды там, где не надо было. На любом можно плохо написать, да. Но написать плохо с тредами проще, чем написать плохо без тредов. Threads are evil, как известно

Ыгы, вот у нас один такой написал без тредов - серваки используются на 10-15%. А знаете сколько колокейшн стоит? И электричество?

[sobomax]

Но написать плохо с тредами проще, чем написать плохо без тредов.

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

-Maxim

[badger]

Ыгы, вот у нас один такой написал без тредов - серваки используются на 10-15%. А знаете сколько колокейшн стоит? И электричество?

Ну вот, а у нас 'один такой' написал с тредами так, что всё колом вставало как минимум раз в неделю. Needless to say, серваки не использовались вообще. Не столько даже важно, насколько он был профессионален, треды имеют свои слабые стороны, и этом всем известно. Намного понятнее выглядит Erlang или, скажем, Scala c actors. Согласитесь? За этим будущее (а для Erlang давно настоящее), а не за кошмаром под названием multi-threading programming.

Насчёт моих серверов, всему своё место. Если bottleneck в IO, то асинхронная модель намного более пригодна, чем тредовая. Опять же, программировать и отлаживать её проще.

[badger]

Но написать плохо с тредами проще, чем написать плохо без тредов.

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

-Maxim

У Python есть проблемы, я согласен. Но они решаемы. В конце концов мультиядерность может быть задействована развешиваением Python процессов по ядрам. Это всё решаемо.

Но есть у Python и существенные преимущества -- его высокоуровневость. Здесь уж Java никак не догонит Python, хоть убейся. Напротив, 'улучшение' за 'улучшением' ещё больше испоганивают язык. Scala выглядит намного привлекательней.

[sobomax]

Не столько даже важно, насколько он был профессионален, треды имеют свои слабые стороны, и этом всем известно.

Это вас кто-то обманул, проблема именно в прокладке. Триды конечно имеют свою специфику, но не настолько. Все современные ядра операционных систем написаны на тридах и что? Работают замечательно и не виснут "раз в неделю".

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

А то какая модель придет на смену тридам через 10 лет дело десятое. Пишется то сегодня, на сеодняшних языках и под сегодняшние железо.

-Maxim

[badger]

Threads are evil, как известно

Это вы их просто готовить не умеете.

-Maxim

Это не я готовил. До меня готовили Я их готовить умею, но да, честно говорю, не люблю.

[sobomax]

У Python есть проблемы, я согласен. Но они решаемы. В конце концов мультиядерность может быть задействована развешиваением Python процессов по ядрам. Это всё решаемо.

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

-Maxim

[badger]

Это вас кто-то обманул, проблема именно в прокладке. Триды конечно имеют свою специфику, но не настолько. Все современные ядра операционных систем написаны на тридах и что? Работают замечательно и не виснут "раз в неделю".

Ещё бы ядра висли. Скажете тоже. Ядра хватает кому обкатывать. И то временами, то с Linux threads, то с FreeBSD бывали проблемы в performance. Я уже давно не слежу, ядрами давно не занимаюсь, но бывали точно. Не раз.

Я говорю про конкретный опыт работы с multi-threading в Java. Я знаю, какая это головная боль. Допускаю, что везде, где я работал, хватало непрофессионалов, но мне от этого не легче. То active trading system , то сервер какой-нибудь, то ещё что начинает дурить. И надо в короткие сроки разобраться в этом дермище.

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

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

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

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

Упираетесь в быстродействие одного ядра, разбивайте на процессы. Всё это решаемо. И более прозрачно, чем с тредами.

А то какая модель придет на смену тридам через 10 лет дело десятое. Пишется то сегодня, на сеодняшних языках и под сегодняшние железо.

Через какие десять лет? Все эти модели уже есть. Посмотрите на Erlang, на Clojure, на Scala with Actors.

[CdR]

хотя зря, хороший язык (был).

[imho]Никогда он хорошим не был.
100% написаных на нём приблуд глючили неподетски. Всегда.
Рельсы -- это вообще пример "big fail". [/imho]
можете меня начинать концептуально чмырить...

[sobomax]

hoА зря, хороший язык (был).

[imho]Никогда он хорошим не был.
100% написаных на нём прилуд глючили неподетски. Всегда.
Рельсы -- это вообще пример "big fail". [/imho]
можете меня начинать концептуально чмырить...

Так рельсы то на руби, вроде?

А твой любимый перл это вообще не язык, а недоразумение! awk-мутант.

-Maxim

[badger]

У Python есть проблемы, я согласен. Но они решаемы. В конце концов мультиядерность может быть задействована развешиваением Python процессов по ядрам. Это всё решаемо.

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

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

Опять же, посмотрите на масштабируемость Erlang. Вполне даже 'на практике'. Или на ядро QNX. Вообще трудно найти что-то более ясное и красивое, чем messaging mechanism.

Другое дело, что в Java альтернатив практически нет. Остаётся защищать только многопоточность. Всё остальное выглядит криво на базе Java.

[sobomax]

Через какие десять лет? Все эти модели уже есть. Посмотрите на Erlang, на Clojure, на Scala with Actors.

Ага, очень убедительно. Сравнить например количество кода писанного на жабе и на этих языках. 1,000,000:1 или того меньше?

-Maxim

[badger]

[imho]Никогда он хорошим не был.
100% написаных на нём приблуд глючили неподетски. Всегда.
Рельсы -- это вообще пример "big fail". [/imho]
можете меня начинать концептуально чмырить...

А я не собираюсь Вас чмырить. Рельсы -- это полное дерьмо. Раздутое невесть что в маркетинговых целях.