LINUX.ORG.RU
Ответ на: комментарий от feofan

Я тут глянул, вроде как конкуренси в clojure основана на йава тредах. Я могу ошибаться конечно, но если нет, я надеюсь ты знаешь о том, что jmv треды кушают карамельки по сравнению с эрланговскими процессами? Причём и т.з. затрат на содержание (512 байт в ерланге емним) и с т.з. скорости создания (тыц)

Ну это так, размышления. Просто если говорить ещё и scalability, то clojure как бы пролетает. Даже не смотря на то, что у неё там всё из коробки.

Что думаешь по этому поводу?

nanoolinux ★★★★
()
Ответ на: комментарий от nanoolinux

помимо этого, зная про jvm-ный classloader, замена кода на лету тоже «выливается в копеечку» :(

yyk ★★★★★
()
Ответ на: комментарий от nanoolinux

Сразу, цифер нету, и я не шарю ни в Кложуре, ни в Эрланге, так что на правах кухонного кукарекания.

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

Erlang масштабируется (т.е. можно и не масштабируемо, но зачем), но это масштабирование дает оверхед.

Кложура работает проще. В Clojure есть Software Transactional Memory (STM) — технология многопоточности, аналогичная транзакциям в БД. Альтернатива синхронизации на lock'ах. Асинхронная модель для STM - это actors. Они интегрированы с STM - сообщения внутри транзакции живут до коммита, и уничтожаются, если с транзакцией стало что-то недоброе. Соответственно, акторы работают быстро, нету никакого императивного цикла и блокирующего receive.

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

В эрланге есть планировщик и легкие процессы, хавающие по 300 байт (или 512 как ты сказал?), это быстро и круто.

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

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

А что жвм нестабильна, и всё написаное на жвм проклято, то эрланговская VM тоже умирает и ее приходится поднимать собакой, Валкин/lionet то ли в ЖЖ пейсал, то ли на конференции какой рассказывал.

stevejobs ★★★★☆
()
Ответ на: комментарий от nanoolinux

основана на йава тредах

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

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Ок, спасибо. Было очень интересно почитать. Очевидно я ошибся, предполагая, что конкуренси clojure основано на йавовских потоках.

nanoolinux ★★★★
()
Ответ на: комментарий от stevejobs

его должно вытеснить, да?

Да, там счётчик есть. Ну и на receive он тоже вытесняеться, если в мейлбоксе нет сообщений, которые можно матчить.

nanoolinux ★★★★
()
Последнее исправление: nanoolinux (всего исправлений: 1)
Ответ на: комментарий от nanoolinux

Очевидно я ошибся, предполагая, что конкуренси clojure основано на йавовских потоках.

да не, не ошибся) Нету нормальных потоков — свелосипедим навороченную memory model. Жавапроблемы)

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

stevejobs ★★★★☆
()
Ответ на: комментарий от feofan

Только вот зачем? Много потоков это супер, но это для поделок. Для нормальных приложений надо использовать не много потоков, а мало :). Вместо потков делается стейтмашина. В результате преимущество эрланга оказывается невостребованным, либо востребованным среди ленивых, либо среди тех, что не знает о стейтмашине.

В результате что-то не видно на эраланге ни софтсвитчей популярных, ни вебсерверов уровня nginx.

vromanov ★★★
()
Ответ на: комментарий от vromanov

Для нормальных приложений надо использовать не много потоков, а мало :)

Что для тебя нормальные приложения?

Остальное комментировать не буду ввиду недостаточности моей компетентности.

И, да, конечные автоматы удобны далеко не всегда.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 1)
Ответ на: комментарий от feofan

Эрланг сейчас развивает эриксон. Для эриксона основным направленеим является телеком. Вот типичные примеры приложений - софтсвитчи, IMS, PCRF, PCEF, MME, SGW и куча других абревеатур из области 3gpp стандартов. Возьмем за образец то что мне близко - PCRF. Это такая железка, которая управлет доступом пользователя. Когда пользователь подключается к сети, в ней создается запись о сесси пользователя. Там хранится всевозможная инофрмация и текущее состояние пользователя. Периодически от оборудования в pCRF приходят сообщения. Например, пользователь перешел на другоую базовку или скачал очередные 10 мб. Иногда сам PCRF посылает сигнал оборудованию, что надо, например, поменять доступ пользователю т.к. он нажал турбокнопку или у него кончился оплаченный пакет.

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

Количестов потоков делаем равным количеству ядер и получаем уменьшение затрат на переключение потоков.

Можно, конечно, что-то подобное делать на java - но производительность упадет весьма существенно. Да и всякие другие особенности С/C++ позволяют писать более быстродействующие приложения. Например, в телекоме принято не злоупотряблять динамическим выделением памяти. В качестве примера, в нашем приложении за несколько лет не было проблем связанных с утечкой памяти. Единственный случай, когда просто битый пакет полученный по сети привел к закцикливанию и выжирании памяти (там как раз был случай с использованием vector).

vromanov ★★★
()
Ответ на: комментарий от vromanov

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

slackwarrior ★★★★★
()
Ответ на: комментарий от vromanov

Почему бы не переложить написание стейтмашин на автоматику? Сколько стейтмашин ты сможешь написать руками?

stevejobs ★★★★☆
()
Ответ на: комментарий от vromanov

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

Количестов потоков делаем равным количеству ядер и получаем уменьшение затрат на переключение потоков

про green threads в эрланге что-нибудь слышал?

feofan ★★★★★
()
Ответ на: комментарий от stevejobs

Можно поручить и автомату. Но это стоит денег, и обычно стейтмашин нужно не так и много. У нас их штуки три-четыре вроде. Короче, написать вручную будет бустрее и дешевле с точки зрения затрат. Если бы их было больше, я бы конечно подумал об использовании какого-либо инструмента для автоматизации создания стейтмашины.

vromanov ★★★
()
Ответ на: комментарий от feofan

Их PCRF не использует их же эрланга. Там используется С++ и java. Для гугления можно использовать строчку «ericsson service-aware policy controller opensaf»

vromanov ★★★
()
Ответ на: комментарий от SAA

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

vromanov ★★★
()
Ответ на: комментарий от vromanov

Гугление показывает твою правоту. Впрочем, я уже говорил, это выходит как за рамки моей компетенции, так и за рамки моих интересов. А тут на ЛОРе был один регистрант, который пишет на эрланге для телекома (видел его в лиспотредах). К сожалению, не помню ник.

feofan ★★★★★
()
Ответ на: комментарий от SAA

Думаю, что если решение работает на 10000 сессиях оно может не работать на ляме. Т.е. наступил предел масштабирования по потокам. А если потоки не работают то в чем кайф эрланга?

vromanov ★★★
()
Ответ на: комментарий от vromanov

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

Valgrind юзали?

nerdogeek
()
Ответ на: комментарий от vromanov

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

Да? Ммм.. А в фейсбуке чат на нем написан

nerdogeek
()
Ответ на: комментарий от nerdogeek

Нет. Просто стараемся не использовать динамическую память. Сейчас есть несколько крупных мест, где используется динамическая память (vector, string). Думаю, как от нее избавиться, но пока это тяжело. Там что-то вроде парсинга бинарного XML (Diameter) c валидацией и поддержкой вложенных структур. Также гоняем нагрузку и стабильность. Т.е. вот прямо сейчас идет 8-й день работы новой версии сервера под нагрузкой в 8 тысяч в секунду. Обработано 4 841 408 819 запросов, в лог записано 9684686618 строчек.

vromanov ★★★
()
Ответ на: комментарий от nerdogeek

Вот я смотрю эту презентацию - http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatF... на 13-й странице вижу следующие цифры - 800 000 000+ сообщений в день. 100+ серверов. Охренеть!!! Просто супер производительность! Мы для такой-же нагрузки используем кластер из ДВУХ десктопов. Причем, у нас сообщения это не «привет!», а существенно более сложные. И алгоритмы посложнее. Итого эрланг в 50-100 раз тормознее с/с++.

vromanov ★★★
()
Ответ на: комментарий от vromanov

Да, дурачки. К чему такая избыточность, если можно написать на плюсах и использовать пару машин загруженных на 100%, которые физически никогда не упадут. И еще, гляньте в jabberd на обработку «привет!»-логики.

nerdogeek
()
Ответ на: комментарий от nerdogeek

использовать пару машин загруженных на 100%, которые физически никогда не упадут

предлагаешь везде ставить в 50+ раз больше серверов для надежности?

wota ★★
()
Ответ на: комментарий от vromanov

А если потоки не работают то в чем кайф эрланга?

тов. unfo довольно точно заметил. Я бы ещё добавил сетевую прозрачность между нодами и встроеный маршалинг.

Вот тут ты описал идеальную задачу для эрланга. Все требования и идея, которые ты описал, в эрланге есть из коробки. Кроме того, имхо, всякие syslogd и dbusd и всё остальное ивент бейсейд идеально вписывается в то, что могло бы быть написано на нём за более короткие сроки и работало бы не хуже и стабильнее. Я не говорю, что его надо пихать куда только можно, я о том, что возможности, которые он предоставляет очень часто начинают велосипедить на том же спп. Я даже уверен, что многие фичи, которые есть в твоей pcrf, точно так же навелосипедены. Вот тебе ещё баянистая и знаменитая success story и ещё тред на почитать (он правда 3х годичной давности), если интересно конечно.

Имхо, проблема эрланга в том, что он очень сильно не похож на скобочкоподобные языки. Отсутсвие циклов и изменяемых переменных заставляет ломать мозги, а на это не каждый програмист способен. Даже есть захочет.

nanoolinux ★★★★
()
Последнее исправление: nanoolinux (всего исправлений: 1)
Ответ на: комментарий от wota

Вероятно, не такая уж легкая обработка этих чат-запросов. И сама логика чатов падучая при требованиях быстрой разработки. Плюс оверхед на греп по ключевым словам для сотрудников АНБ :)
Лучше рекорды пепякомерки смотреть в приложениях, использующих RabbitMQ.

nerdogeek
()
Ответ на: комментарий от nerdogeek

Покажите мне бенчи этого jaberd и я посмеюсь вместе с вами.. То что я видел, и что тестировала моя жена, выглядело очень плохо. 100 серверов то они сделали не потому, что хотят держать нагрузку в 1%, а потому что иначе не тянет.. Метод такой - выбрать говнотехнолoгию, а потом компенсировать это количеством железа. В телекоме так не получается. Причины следующие:

  • Более дорогое железо. В связи с высокими требованием к надежности используется дорогое оборудование с резервными питанием итд. Например, погуглите на слово ATCA.
  • Снова требования надежности. Например, у оператора может быть несколько узлов по стране. В каждом узле ставится по комплекту оборудования, чтобы в случае падения межгородских линков все продолжало работать локально. Предложите ставить рядом с каждой корой по 100 серверов? не поймут.
  • И еще аспект надежности.. Если в чатике не доставится сообщение - ничего старшного. Если пользователю не будет дан доступ к интернету - уже хуже. Если у него спишутся деньги еще хуже. Т.е. просто цена ошибки и прстоя становится выше.
vromanov ★★★
()
Ответ на: комментарий от nanoolinux

у vromanov руками накоженные 3-4 стейт-машины на двух десктопах. Даже вектора и то использует с осторожностью. Т.е. он совершенно не экономит размер кода и время разработки, зато результат у него работает в 10 раз быстрее. Звучит справедливо, не?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

Да, абсолютно согласен. Я тогда его сообщение не прочитал ещё.

Это кстати одна из фич спп, которую походу никак и ничем не заменить. Оптимизация.

nanoolinux ★★★★
()
Последнее исправление: nanoolinux (всего исправлений: 1)
Ответ на: комментарий от stevejobs

У меня куча автогенеренного C++ кода, генератор написан на баше :). Есть еще один прием, который тяжело использовать в других языках типа явы. Например, вам надо распарсить заголовок HTTP запроса. В java у вас будет класс, который содержит срочки с КОПИЕЙ того что пришло в запросе. Правильный парсер на С/C++ для каждого поля будет содержать указатель и длинну поля. Указатель будет указывать на месте в буффере, где лежит весь полученный запрос. Тем самым есть возможность не использовтаь динамическую память, не грузить сборщик мусора и не получать утечек! Профит!

vromanov ★★★
()
Ответ на: комментарий от unsigned

вот так указатели можно использовать в С++:

...
const char* method() const { return method_; }
const char* url() const { return url_; }
...
printf( "Method: %s, URL: %s\n", conn.method(), conn.url() );

покажи аналог на яве

wota ★★
()
Последнее исправление: wota (всего исправлений: 1)
Ответ на: комментарий от unsigned

Основная проблема в том, что это «неправильный» для java путь. Большую часть функций придется писать вручную итд. Т.е. и производительности не получишь, а гемора огребешь еще больше. А если так, то зачем java?

vromanov ★★★
()
Ответ на: комментарий от wota
class Connection {
	public String method() { return method_; }
	public String url() { return url_; }
	private String method_ = "METHOD";
	private String url_ = "URL";
}

public class Main {
	public static void main(String[] args)
	{
		Connection conn = new Connection();
		System.out.printf("Method: %s, URL: %s\n", conn.method(), conn.url());
	}
}

Где подвох?

unsigned ★★★★
()
Ответ на: комментарий от nanoolinux

Как называется этот способ именования полей класса?

без понятия :)

wota ★★
()
Ответ на: комментарий от unsigned

Где подвох?

подвох в том, что в случае С++ ты читаешь заголовок запроса целиком - это одна область памяти, а потом, когда парсишь, просто выставляешь значения указателей + расставляешь \0 прямо в буфере, в итоге нет никаких копирований и ненужных выделений/освобождений памяти

wota ★★
()
Ответ на: комментарий от wota

нет никаких копирований и ненужных выделений/освобождений памяти

Но есть нетривиальная и не проверяемая компилятором семантика владения.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Но есть нетривиальная и не проверяемая компилятором семантика владения.

идеальных решений на данный момент не существует

wota ★★
()
Ответ на: комментарий от tailgunner

Как раз она очень тривиальная и простая - время обработки запроса. Это на самом деле общепринятая модель. Примеры, где делается так - OpenSER, SER (это сип сервера), nginx

vromanov ★★★
()
Ответ на: комментарий от wota

1) Компилятор и рантайм Java оптимизирует. В т.ч. есть всякие AtomicReference<T>, есть volatile, о которых компилятор и рантайм знают специально

2) Если нужен буфер, то есть
http://www.docjar.com/docs/api/sun/misc/Unsafe.html
Но за его использование будут ненавидеть, т.к. только садомазо и авторы гиперкластеров на Windows 3.11 вручную работают с буфером

3) А еще куски кода можно написать на си и цеплять по JNI

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

3) А еще куски кода можно написать на си и цеплять по JNI

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

Pavval ★★★★★
()
Ответ на: комментарий от wota

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

unsigned ★★★★
()
Ответ на: комментарий от unsigned

Терминаторы не используются, например, когда надо получить не только целое но и части. Например в буфере «Вася Пупкин» и есть методы - getFullName, getFirstName, getLastName. В этом случае можно возвращать std::string

vromanov ★★★
()
Ответ на: комментарий от wota

то-то парсеры XML, например, на Java такие тормозные

тормозные это слабо сказано

quest ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.