JRuby 1.1

> Иди напиши на питоне hello world и покажи как она запускается в 100 раз быстрее джавы. На этом тесты можешь закончить ибо мозга у тебя нет.

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

> Кроме того, боюсь, Jython намного тормознее JRuby. Когда я его последний раз бенчил (правда, было это давно) Фибоначи он считал в 29 раз медленнее, чем PHP.

Что, опять бенчим рекурсивным фибоначи? Тем, который на питоне 2.4 после подключения декоратора memoize может стать в миллион раз быстрее?

>жаба не нужна. ты тоже. иди сделай апстену.

во, ламерье полезло - это ты не нужен

>Что, опять бенчим рекурсивным фибоначи?

Хорошо, другой раз буду тестировать рекурсивным Аккерманом :)

>Ты маленький имбецилл. В Ява-машине отличный сборщик мусора, но >если ты говоришь про говно-языки и при этом ссылаешься на сборщик >мусора, то видно в программировании ты также понимаешь как бабушки >которая семечками торгует возле метро.
Ты иди сначала напиши что-нибудь и пусть тебе денег за это заплатят, а потом будем говорить, кто и что и где понимает. Это анонисты на лоре не понимают, что пофиг на каком языке решать задачу, а важны как раз такие вещи как качество библиотек и такие вещи как GC. И именно поэтому никогда никто не будет писать что-нибудь на ваших языках для яйцеголовых студентов линуксоидов. Это языки - поиграться и бросить.

>Язык - это идея, набор средств и абстракция для реализации задачи. А >сборщик мусора одна из компонент для __реализации__ этой идеи. К >языку GC имеет очень отдаленное отношение. Скажем, в Эрланге >сборщик мусора лучше. Но тут сыграло роль, особенность самого >языка(отсутствие деструктивного присваивания, интенсивное >использование процессов).

В мемориз!!! Мальчик, без нормального компилятора, VM, библиотек твой язык нах никому не нужен. Не имеет смысла рассматривать сферичиских коней в вакуме. Реализации говно-языков ужасны, у них тормозит GC/потоки, не отлажены библиотеки и т.д. Это песочница для студентов (и в этом нет ничего плохого).

>> Иди напиши на питоне hello world и покажи как она запускается в 100 раз быстрее джавы. На этом тесты можешь закончить ибо мозга у тебя нет.

>И это все, что ты имеешь сказать? иди уроки учи, школьник


А это все что ты можешь сказать :)
>>>гыгы. быдлокодер с промытыми маркетологами мозгами.

>>>Давай расскажи как ява не тормозит :))))

Напиши еще что-нибудь про тормозящую жабу - я поржу. На самом деле фраза "жаба - тормоз" это признание в собственном тупости и означает что вы не можете понять как работает JVM вообще и GC в частности.

>Это песочница для студентов (и в этом нет ничего плохого).

Я недопонял контекста - это про Эрланг, что ли? :D :D :D

> Я недопонял контекста - это про Эрланг, что ли? :D :D :D

У джабистов - это про все кроме джабы (даже ANSI C, очевидно, попадает под описание).

>А ведь даже были попытки сделать питон без жил, да вот гвидо сказал надо, пионерия ответила, что жил это круто

Пионерия срёт на лоре, не зная сути вопроса. Версия без GIL работала в 2 раза медленнее версии с GIL'ом

>>Это песочница для студентов (и в этом нет ничего плохого).

>Я недопонял контекста - это про Эрланг, что ли? :D :D :D

я из функ. языков поигрался только с прологом, но вот что написано в wiki про ерланг:

Concurrency and distribution oriented language

Erlang's main strength is support for concurrency. It has a small but powerful set of primitives to create processes and communicate between them. Processes are the primary means to structure an Erlang application. Erlang processes are neither OS processes nor OS threads, but lightweight processes somewhat similar to Java's original “green threads” (the JVM now uses native threads). Like operating system processes (and unlike green and O/S threads) they have no shared state between them. The estimated minimal overhead for each is 300 bytes, so many of them can be created without degrading performance (a benchmark with 20 million processes was tried[3]). Erlang has supported symmetric multiprocessing since release R11B of May 2006.

Process communication is done via a share-nothing asynchronous message-passing system: every process has a “mailbox”, a queue of messages sent by other processes, that are not yet consumed. A process uses the receive primitive to retrieve messages that match desired patterns. A message-handling routine tests messages in turn against each pattern, until one of them matches. When the message is consumed (removed from the mailbox) the process resumes execution. A message may comprise any Erlang structure, including primitives (integers, floats, characters, atoms), tuples, lists, and functions.

ужыс нах, это работать быстро не может, увы. И поддержка SMP аж с 2006 года просто поражает.

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

> В мемориз!!! Мальчик, без нормального компилятора, VM, библиотек твой язык нах никому не нужен. Не имеет смысла рассматривать сферичиских коней в вакуме. Реализации говно-языков ужасны, у них тормозит GC/потоки, не отлажены библиотеки и т.д. Это песочница для студентов (и в этом нет ничего плохого).

Бугога. Малчик, иди лучче вики читай :) может вырастишь когда-нить.

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

что большой мозг не позволяет что либо умное сказать? напишешь на фунц. языке что-нибудь сложнее hello world, или опять газифицируешь лужи? :). Те программисты у которых жаба тормозит получают 75к, а те у которых не тормозит 120к, вот и вся разница :). А ты иди учи другие сверх быстрые языки, а мы уж как-нибудь с явой помучаемся :)

>Бугога. Малчик, иди лучче вики читай :) может вырастишь когда-нить.

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

о! очередной мегапрограммер с межконтинентальными проектами.

> Да вы не беспокойтесь за мое физическое состояние,

Никогда не беспокоился за физическое состояние экспонатов кунсткамеры.

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

А вот куча быдлопрограммеров явовых это не миф. :(

>Никогда не беспокоился за физическое состояние экспонатов кунсткамеры.

мда анонисты стали жалкими

>ужыс нах, это работать быстро не может, увы

Всё с тобой ясно, унылец :D Бегом изучать на каком языке работают телекоммуникации Эрикссона.

>напишешь на фунц. языке что-нибудь сложнее hello world

http://www.ejabberd.im/

Пока что все конкуренты, сорри за тавтологию, конкуренции не составляют :D

>http://www.ejabberd.im/

>Пока что все конкуренты, сорри за тавтологию, конкуренции не составляют :D

а что жаббер сервер это сложная программа или ей нужна большая производительность? Я вот пользуюсь жаббером уже много лет, и как я только что узнал раньше все работало маскимум на одном CPU. Так что фиговый пример :). Тоже относится и к ерику, телекоммуникации они разные бывают и производительность очень часто никому нафиг не упала.

хватит смешить народ, болезный.

>а что жаббер сервер это сложная программа или ей нужна большая производительность?

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

Кстати, и буквально - по производительности в создании процессов равного Эрлангу языка нет. Собственно, потому его в телекоммуникациях так интенсивно и используют. Ещё раз рекомендую посмотреть в сторону Эрикссона.

Как числодробилка Эрланг, конечно, не лидер, где-то на уровне Python+psyco или Lua. Но создание тредов на нём в 20 раз быстрее Java: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=... В 10 раз быстрее, чем на OCaml.

> Но создание тредов на нём в 20 раз быстрее Java

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

>Проще говоря - в других языках все эти десятки тысяч нитей нах не нужны, там состояние хранится по-другому.

И как на Java обслуживать 100 тыс. активных клиентов? Или хотя бы 15 тысяч, как в случае jabber.ru? :) У меня, вот, в Java уже на 1000 клиентов проблемы начинались, 90% машинного времени уходило в nio + создание нитей для обработки событий.

> И как на Java обслуживать 100 тыс. активных клиентов? Или хотя бы 15 тысяч, как в случае jabber.ru?

А на чем, кроме erlang это возможно?

> Или хотя бы 15 тысяч, как в случае jabber.ru? :)

Клиентов, которые ничего не делают? 8) Ну а C10K была написана уже лет 10 назад.

> У меня, вот, в Java уже на 1000 клиентов проблемы начинались, 90% машинного времени уходило в nio + создание нитей для обработки событий.

Ты создавал нити в динамике? По нити на клиента? 8)

>Ну, когда тебе, например, надо обрабатывать 15 тысяч коннектов на весьма древнем железе...

UNIX Network Programming by Richard Stevens :), я не думаю что 15 тысяч людей могут создать сколько-нибудь заметную нагрузку даже если будут срочить как мартышки :).

>Кстати, и буквально - по производительности в создании процессов равного Эрлангу языка нет.

Это конечно хорошо, но вот поддержка SMP в 2006 году все равно выглядит очень подозрительно. А для потоков, как и для БД все используют пулы.

>И как на Java обслуживать 100 тыс. активных клиентов? Или хотя бы 15 тысяч, как в случае jabber.ru? :) У меня, вот, в Java уже на 1000 клиентов проблемы начинались, 90% машинного времени уходило в nio + создание нитей для обработки событий.

Мы обрабатываем ~2.5 тысячи сообщений в секунду идущих с messaging server'а nirvana. Средний latency от клиента до сервера ~0.5-1, клиентов 2.5тысячи. Так что просто писать надо по другому :)

http://www.my-channels.com/products/nirvana.html

>И как на Java обслуживать 100 тыс. активных клиентов? Или хотя бы 15 тысяч, как в случае jabber.ru? :) У меня, вот, в Java уже на 1000 клиентов проблемы начинались, 90% машинного времени уходило в nio + создание нитей для обработки событий.

Ну у нас в большой сиситеме было два сервера - наш на Java и какое-то барахло на С++ с которым надо работать. В конце концов ботлнек ушел на С++ сервер, который при большом количестве запросов уходил в даун - нам пришлось троттлер приделывать.

>Ты создавал нити в динамике? По нити на клиента? 8)

Нить создавалась по необходимости реакции на событие. Пакет -> Нить -> Обработчик.

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

>Это конечно хорошо, но вот поддержка SMP в 2006 году все равно выглядит очень подозрительно

А я так и не понял, зачем ему вообще SMP? Поднимаешь на машине с N ядрами/процессорами N нод, по ноде на каждое ядро. Эрлангу пофиг, запускать процесс на ноде на этой же машине или на удалённой. Это, всё же, распределённый язык.

...

Вот, кстати, известный и интересный бенч Apache2 vs Yaws (Erlang): http://www.sics.se/~joe/apachevsyaws.html

> Нить создавалась по необходимости реакции на событие. Пакет -> Нить -> Обработчик.

А потом уничтожалась? Выше по треду уже советовали пул. Или адаптивный пул.

>А потом уничтожалась? Выше по треду уже советовали пул. Или адаптивный пул.

Пул у нас, пул :)

> Пул у нас, пул :)

ы; а как же "90% машинного времени уходило в nio + создание нитей для обработки событий" - зачем постоянно создавать нити, если есть пул?

Сказал неточно. Под «созданием нитей» имелось в виду создание runnable-объектов и исполнение их в пуле нитей.

>А я так и не понял, зачем ему вообще SMP? Поднимаешь на машине с N ядрами/процессорами N нод, по ноде на каждое ядро. Эрлангу пофиг, запускать процесс на ноде на этой же машине или на удалённой. Это, всё же, распределённый язык.

накладные раскходы на передачу данных в таком случае намного выше (пара порядков как минимум). Но для Jabber это скорее всего не критично. Все эти красивые идеи (нет общей памяти -> нет кучи concurrent issue, сообщения и т.п.) хороши только на бумаге. В реальной жизни SMP и обычные нити ОС дают фору всему остальному.

>В реальной жизни SMP

Ну так посмотри на тест выше :)

>>В реальной жизни SMP

>Ну так посмотри на тест выше :)

Ну так они там и тестят коня в вакуме, мало того это там ниже даже явно написано. Преимущетва и недостатки не нативных потоков обмусоливались в разных языках программирования уже 100 раз. На данном этапе развития выгодно использовать нативные потоки.



I'm speculating here.

The problem with Apache is not related to the Apache code per se but is due to the manner in which the underlying operating system (Linux) implements concurrency. We believe that any system implemented using operating system threads and processes would exhibit similar performance. Erlang does not make use of the underlying OS's threads and processes for managing its own process pool and thus does not suffer from these limitations.

а non-blocking io не пробовали? ТОгда каждая нить может обслуживать многих клиентов одновременно. Это убирает необходимость держать множество потоков (даже при наличии пула это не эффективно). Размер пула в этом случае будет зависеть от кол-ва железа сервера, а не от кол-ва клиентов.

>а non-blocking io не пробовали?

«nio» в одном из предыдущих сообщений - и есть non-blocking input :)