Что почитать по типизации сообщений?
>>340248
> http://stackoverflow.com/questions/5547947/why-are-messages-to-akka-actors-untyped
>asked Apr 5 '11
яснопонятно
дальше твой высер не читал.
>>340256
А что изменилось с тех пор? То что мало кому известный (тогда) проект стал частью стандартной библиотеки? И только? Положительных изменений в плане архитектуры нет и теперь уже не будет.
Хули ты делаешь в моем динамически типизированном интернете, фанатик?
>>340254
Есть же много реализаций акторов на Скала, большинство поддерживает типизацию естественным образом. Но так называемые "typed-actors" в Акка - это жуткие костыли. См. - http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.html
>>340259
Можно исользовать тайпед чэнел' но там тоже есть проблемы.
Остальные твои претензии глупы.
>>340260
>в моем динамически типизированном интернете
Завязывал бы ты с травой в своем гипертекстовом фидонете.
>>340265
>тайпед чэнел
Один костыль охуительнее другого.
Все это не меняет сути, в сердце акка лежит динамическое говно.
>>340267
Ммм, ты пришел пояснить за статическое говно или просто так кукарекаешь от скуки?
>>340269
>статическое говно
WOT?
>ты пришел пояснить
Если тебе приятнее долбиться в сраку с динамическим любрикантом, то мне нечего тебе пояснять.
>>340275
Не думаю что ты смог пояснить' за все твои посты я не услышал ни слова, о том почему динамическая типизация плохо. Но перед этим дай определение дин. Тип. И найди те признаки в акке.
>>340271
Очень хорошее сравнение.
Остается вопрос: Почему они засунули в стандартную библиотеку 2.10 самое днище?
>Akka Actors: Actor[Any]
>>340276
Актор (как Promise[T] ) должен быть параметризован типом сообщений, которые он принимает. Это же очевидное решение. Разные сообщения могут наследовать один trait, который указывает на принадлежность сообщения к актору. Если сообщение - внешний класс, то его можно заворачивать в Either. В крайнем случае можно сделать Actor[Any]. Но в Акка же выбрали самый уебанский вариант в стиле бэйсика, короче слепили все как проще: "Нахуя нам параметризация, если и без нее все работает?" Если бы так же рассуждали авторы самой скалы, то у них бы вышел бы какой-то groovy.
Скаланы, поясните, где лучше всего использовать скалу? Например, написать масштабируем сервер мморпг - подходящая задача или лучше подыскать что-нибудь другое из языков?
Посоны, вам не кажется, что скала и джава это как с++ и с? Там и там наворотили прибамбасов, что черт ногу сломит и что со всем этим делать - не ясно.
ниасилятор
>>340296
>Скаланы, поясните, где лучше всего использовать скалу?
Почти везде, где используют джаву + кое-где, где джава сосет: т.е. почти все от андроида до серверов и кластеров.
>Например, написать масштабируем сервер мморпг
>мморпг
В геймдеве я плохо разбираюсь, но вот
>масштабируемый
Так скала рождена для для этого.
>>340316
Скала изначально разрабатывалась не как Джава 2.0 с блэкджэком и шлюхами. А как реализация идей ФП на платформе JVM. Чистого функционального языка не получилось. Дальше уже совместимость с джава продиктована необходимостью использовать рантайм от jvm.
>что со всем этим делать - не ясно
Тебя притягивает красота и лаконичность самого языка? Если нет, значит это просто не твое, возвращайся на родную жабу или попробуй еще раз через пару лет (когда тебя реально стошнит от жабы).
P.S. Кстати С и С++ так похожи только с виду из далека.
>>340323
Ты меня совсем не понял.
>С и С++ так похожи только с виду из далека
>Скала изначально разрабатывалась не как Джава
именно об этом я и говорю.
>Тебя притягивает красота и лаконичность самого языка?
Единственный язык, подходящий под это определение - Лисп.Меня же отталкивает невероятное количество свистелок и перделок что в С++ что в Скала.
На С нельзя писать то, что пишут на С++. Первый подходит только для программирования сливных бачков, в то время как на втором пишут сложные и, одновременно с этим, очень требовательные системы: графические/физические движочки, операционные системы, рантаймы языков программирования, и так далее. Понятно, что не у нас, и не нашего ума это дело - нам, в лучшем случае, сливные бачки доверят. Вот с Java и Scala ситуация похожая, но оные находятся в альтернативной вселенной софта - где веб и корпоративное говно, и где вместо примитивных и сложных систем бывают сложные и очень сложные, а требования (к эффективности) гораздо ниже.
>>340347
>Первый подходит только для программирования сливных бачков
Апач
Все операционки
Квейки
>>340348
Это не значит, что С для этого подходит. Вот если ты с нуля напишешь на С, с нуля напишешь на С++, при этом используя на полную катушку возможности каждого языка, и сравнишь - и вдруг окажется что на ассемблере не гораздо хуже - тогда да. Но этого никто до сих пор не делал.
В какой-то языкосрач скатились, как всегда. Вопрос был такой
>Посоны, вам не кажется, что скала и джава это как с++ и с? Там и там наворотили прибамбасов, что черт ногу сломит и что со всем этим делать - не ясно.
>>340354
> наворотили прибамбасов, что черт ногу сломит и что со всем этим делать - не ясно.
Это значит, что ты ошибся разделом.
>>340248
Поясняю:
1. Данные идущие по проводам нетипизрованы по своей сути. Все попытки натянуть на них типы приводят к фейлам, т.к. привязывают систему к конкретному языку и технологиям, усложняют любые изменения и рост системы. CORBA, DCOM, Java RMI - это кошмары 90х, забытые как страшный сон и заменённые на protobuf, thrift, avro, json и т.д.
2. Одна из "киллер-фич" акторов - одинаковая семантика для внутрипроцессного, межпроцессного и даже сетевого взаимодействия, т. е. отправка сообщений.
Из 1 и 2 следует, что если не хочешь стрелять себе в ногу, нужно делать сообщения динамически типизоравнными.
Также, после этого становится очевидным, насколько глупым является пункт 2 - для сохранения иллюзии одинаковой семантики мы делаем взаимодейсвия внутри процесса жутко неудобным: нет статической проверки типов, любой локальный запрос памяти мы вынуждены делать как отправку сообщения и приём ответа, даже если данные иммутабельны.
Есть два вида людей, которые рассказывают о "переусложнённости":
- те, кто осознал ущербность/неортогональность каких-то фич
- те, кто нихуя не понял
Вторых очень легко детектировать по отсутствию конкретики. У них часто бывает так: самим им разбираться лень, они видят где-нибудь мнение первых, охотно верят наслово и с тех пор кукарекают, как только представляется возможность. При этом, какие именно фичи лишние, или переусложнённые, или сделанные не так, как хотелось бы, и уж тем более на вопросы, а как же надо было, чтобы было ок, ответить не смогут.
>>340361
Что плохого во втором типе. Иногда проще выбросить говно, чем копаться в нём.
тред не читал
>>340292
А если нужно в рантайме сменить тип сообщений принимаемый актором?
>>340362
Тем, дебилушка, что, как правило, это говно всё-равно несоизмеримо лучше чем всё то, что используете вы. Просто у людей, критикующих эти вещи, планка настолько высока, что ваше говно критиковать им вообще не представляется необходимым - его полная и беспросветная говённость и так очевидна.
>>340361
Второй тип - суровые практики. Если что-то требует слишком много времени для изучения и нет оснований считать, что оно принесет какой-то профит - ну его нахуй.
Правильные выводы из критики Scala таковы:
- если вы хотите разобраться в таких вещах просто из интереса, лучше уж выбирайте хаскель в качестве игрушки на досуге
- если хотите писать промышленно на чём-то лучше, чем остальное, и не являетесь джавистом - на Scala вам писать не удастся, а раз так, см. пункт 1
- если хотите писать промышленно на чём-то лучше, чем остальное, и являетесь джавистом, тогда Scala - ваш выбор
>>340248
Я предлагаю взять базуку побольше и признать одной большой динамической парашей языки с сабтайпингом, такими-то нулами и тайпкастами как нормой жизни.
>>340377
> тайпкастами
Не пиши так больше, а то дети с тайпклассами перепутают.
>>340366
умри, сука
будь добрее, сука
не оскорбляй людей, сука
>>340377
>тайпкастами как нормой жизни
Тайпкасты - не хуя не норма для скалы.
>такими-то нулами
Имеешь в виду Nothing ? Отчасти ты прав, это издержки jvm. Но все таки он не так опасен, как null в джаве (за счет того, что представляет собой отдельный тип).
>признать одной большой динамической парашей языки с сабтайпингом
>сабтайпинг
>динамическая параша
ВУУУУТ??? А ну-ка быстро пояснил за базар!11
>>340368
>если хотите писать промышленно на чём-то лучше, чем остальное, и не являетесь джавистом - на Scala вам писать не удастся
Обоснуй.
>>340361
Согласен с тобой в целом. Есть неасиляторы, которые критикуют Акку потому, что просто не могут в красоту акторов. Я же знаком с пятью разными реализациями акторов. Раньше использовал акторы из 2.9 в одном своем проекте, нарекания к ним есть, но такого отвращения они не вызывают. Еще раньше на джаве писал свой аналогичный велосипед (я тогда даже слова "актор" еще не знал). Короче мне есть с чем сравнивать и я ответственно заявляю, что реализация Акка - самая конченая из всех широко распространенных (я не считаю всякие малоизвестные). Поэтому я так жидко обосрался когда узнал, что именно это говно они влепили в стандартную библиотеку в 2.10, да еще винрарный Promise/Future на нее перетащили.
глядите, раки:
http://ru-scala.livejournal.com/47591.html#
>>340358
>1. Данные идущие по проводам ... CORBA, DCOM, Java RMI ... protobuf, thrift, avro, json и т.д.
Причем тут все это? Речь идет о конкретном языке, о конкретной технологии (акторы) и о выборе годной ее реализации.
>2. Одна из "киллер-фич" акторов - одинаковая семантика для внутрипроцессного, межпроцессного и даже сетевого взаимодействия, т. е. отправка сообщений.
Акроты изначально - это просто технология параллелизма (наряду с promise/future и др.) без синхронизации, блокировок и ожиданий, разрабатывалась как средство от кошмара java concurrency. До сих пор используется на 95% в этом качестве. Все остальные фичи, как отказоустойчивость, сетевая транспарентность и др. - просто плюшки, которые выдаются бесплатно в одних реализациях и требуют дополнительных телодвижений в других. Тем более физическое расположение sender и destination в разных процессах/машинах никак не мешает статической проверке типов при компиляции.
>если не хочешь стрелять себе в ногу, нужно делать сообщения динамически типизоравнными.
Ну бред же полный. Динамическая типизация как раз дает возможность прострелить ногу.
>>340445
Дело в том, что Scala используют только в компаниях, где всё давно на JVM, и все вакансии, что мне встречались ранее, предполагали, что соискатель - как минимум Senior Java. Вот это - >>340459 - первое исключение, которое мне встретилось. Хотя раньше я в рашке не смотрел, может у вас там нередко такое бывает.
>>340335
Я в работе акторы постоянно использую. В основном, Reactor[T] из 2.9 (не блеск, конечно, сыроватые какие-то, то с типизацией проблем нет). Вот когда они стали deprecated в 2.10, а вместо них всунули это днище, тут мой анус реально воспламенился.
>>340466
По юзабильности: Scala Actors из 2.9 - вполне годные.
По красоте: Scalaz Actors - вне конкуренции. Иммутабильность + лаконичность. Сама концепция у них мощная: "актор - это просто функция" (параллельное выполнение не отменяется). Но на практике я ими почти не пользовался, так как Scalaz - жирная либа, зависимостей куча (не хотеть подключать) + мутная она довольно, мозг под нее придется сильно перепиливать + мало документации + лень моя. Может теперь на 2.10 придется на нее перелезать.
бамп1
/** Given a list of futures fs, returns the future holding the value of the future from fs that completed first.
* If the first completing future in fs fails, then the result is failed as well.
*
* E.g.:
*
* Future.any(List(Future { 1 }, Future { 2 }, Future { throw new Exception }))
*
* may return a Future succeeded with 1, 2 or failed with an Exception.
*/
def any[T](fs: List[Future[T]]): Future[T] = {
val p = Promise[T]()
for(f ← fs) yield f.onComplete { v => if(!p.isCompleted) p.complete(v) }
p.future
}
Есть такой код. Почему все равно Promise иногда завершатся два раза (Promise already completed.)? Вызываю
Future.any(List(Future { 1 }, Future { 2 }, Future { throw new Exception }))
>>340527
>Почему
А чего ты ждал? Один Промис комплитят одновременно несколько Фьюч из разных потоков => он будет скомпличен многократно, это же очевидно.
Hint: Используй tryComplete
>>340363
А если нужно в рантайме сменить тип переменной?
- Преходи на ПХП и меняй;
А если нужно нагнуться за мылом?
- Расслабь булки и нагибайся;
Я тут вам покушать принес ПравильныхЪ акторов на Scalaz
http://files.meetup.com/1443989/Scalaz%20Actors.pdf
http://zvozin.github.io/blog/2013/05/12/non-blocking-pipelines-with-scalaz-actors/
Они проще пишутся и работают быстрее, чем в этой навороченной тормознутой Акке.
Что только не придумают лишь бы на эрланге не писать. Сажи долбоебам.
>>340566
Вот ты и попался, эрлядок. Сейчас за весь эршланг перед нами отвечать будешь. Готов или зассал?
1. Чо я вот так прямо в рантайме могу получить нэндл (или как там у вас называется) любого актора по его имени (строке) ? Области видимости, энкапсуляция, все достижения ООП, нет не слышали?
2. Я вот так прямо на месте объявляю тип Huy и посылаю сообщение этого типа актору YourAnus, который нашел по имени, методом (1), и этот актор так спокойно примет это сообщение и будет обрабатывать?
3. Ты когда кодишь актор YourAnus, ты всегда предусматриваешь такую ситуацию (2) и пишешь для всех таких ситуаций обработчики? Или все сообщения типа Huy тихо пролетают в YourAnus и ты, разраб, даже не знаешь где и с каким актором это происходит прямо в этот момент?
4. Может входная очередь сообщений актора YourAnus уже забита сообщениями типа Huy, поток висит перемалывая миллиарды хуев (сообщений), память течет, а ты даже не знаешь обо всем этом, потому что ты не можешь к каждому анусу прописывать обработчики для всех хуев.
>>340582
Давай, давай, чеши отсюда и корешам своим передай, чтоб на нашем районе больше не светились.
>>340580
>(строке)
Апофеоз зашкваренного говноеда, дальше не читал.
Одному мне кажется, что акторы - это такая питушинна ООП-ешная хуйня, которая в нормальных языках не нужна?
>>340248
Joe мне передал что тебя поймает после школы и отпиздят всем эрриксоном
>>340604
Скаланы, что мне делать? Тут у подъезда машина стоит с номерами OTP-999. Я из дома выходить боюсь.
>>340590
Вроде человек не глупый, а не видит разницы между самим языком и паттернами, на нем реализуемыми.
>>340586
>дальше не читал.
У тебя какое-то РАННЕЕ ЗАЖИГАНИЕ. Сожми анус покрепче и дочитай до конца. Дальше там самая мякота идет. Настоящий ВЗРЫВ возможен на последних строчках.
>>340580
1. Под атомом регистрируют только пару долгоживущих акторов, а так pid'ы запрашиваются у процесса-сервиса через API. Более того, модульность никто не отменял.
2. Будут обрабатываться только те сообщения, которые описаны в receive (паттерн-матчингом). Чтобы майлбокс не засырался сообщениями, не совпавшими ни с одним шаблоном, пишут финальную клаузу, игнорирующую сообщение, но при этом оно удаляется.
3, 4 - см. 2
Зато я могу прямо в рантайме заменить весь код актора, все его распознавание сообщений и их обработку. Одной командой.
>>340590
Old-style imperative multithreading (synchronizing, locking, control flow) < Actors (data flow beginning here) < Promise/Future (composition beginning here) < Pure functional
>>340722
Если это о том, на какой технологии написано меньше софта, тогда верно.
>>340732
Вот я и пишу.
Переврем стрелки, получим:
Pure functional > Promise/Future (composition beginning here) > Actors (data flow beginning here) > Old-style imperative multithreading (synchronizing, locking, control flow)
Я написал:
>на какой технологии написано меньше софта
Т.е Pure functional имеет меньше всего софта, а imperative multithreading больше всего.
>>340735
Лапша > Пельмени > Шашлык > Фуа-гра
Это - Соотношение объяемов производства продуктов питания. Качество этих продуктов имет обратное соотношение.
>>340717
>pid'ы запрашиваются у процесса-сервиса
Не по строке с именем ли?
>модульность никто не отменял
(В 2013 году) Ну спасибо, что хоть модульность то не отменили.
>Будут обрабатываться только те сообщения, которые описаны в receive
Значит остальные бутут тихо игнорироваться.
>Чтобы майлбокс не засырался сообщениями, не совпавшими ни с одним шаблоном, пишут финальную клаузу, игнорирующую сообщение
Игнорирование сообщений при обработке никак не спасет от засирания ими мэйлбокса.
В общем, пункты (2), (3) и (4) из >>340580 полностю подтверднись. Пункт (1) похоже тоже.
>Зато я могу прямо в рантайме заменить весь код актора, все его распознавание сообщений и их обработку. Одной командой.
Как что-то хорошее.
>>340808
>Игнорирование сообщений при обработке никак не спасет от засирания ими мэйлбокса.
Ты в глаза ебешься? Я же написал
>>но при этом оно удаляется
Любое совпавшее с шаблоном сообщение по прочтению удаляется. У нас любое совпадает.
>>>Энкапсуляция
Под именем регистрируется только пару персистентных порождающих акторов, которые только лишь делегируют задачи.
То есть не:
{ok, Pid} = players:get_pid(Id),
Pid ! {self(), privateMessage, "Lol"}
а
players:private_message(Id, "Lol")
И видимость тоже ограничивается.
>>340894
Бро, ты всё правильно пояснил этому выблядку, но что это у тебя за камелкейс в эрланге?
Просто jvm-мирок зашкварен уже давно и основательно, и никакой Typesafe не спасёт. Прочитал ОП-пост и почему-то не удивился даже. Это ж джава, как всегда всё проебали.
>>340931
Переменные в эрланге пишутся камелкейсом же.
Правда там я провтыкал и атом тоже камелкейсом написал
>>340580
пиздец ты поехавший
>1. Чо я вот так прямо в рантайме могу получить нэндл (или как там у вас называется) любого актора по его имени (строке) ? Области видимости, энкапсуляция, все достижения ООП, нет не слышали?
могу, gproc
>4. Может входная очередь сообщений актора YourAnus уже забита сообщениями типа Huy, поток висит перемалывая миллиарды хуев (сообщений), память течет, а ты даже не знаешь обо всем этом, потому что ты не можешь к каждому анусу прописывать обработчики для всех хуев.
могу подключиться к ноде и посмотреть что внутри мэйлбокса процесса, а так же обоссать тебя прямо из консоли
>>340995
>могу, gproc
Родина им области видимости дала, ООП им дало инкапсуляцию, ФП дало первоклассные функции, нет не хотим все это, хотим динамическое говно жрать, в рантайме все получать по строке без тайпчекинга, чтоб компилятор не мешал говнокод писать. Построили они свое ПХП с акторами и шлюхами.
>могу подключиться к ноде и посмотреть что внутри мэйлбокса процесса
Я говорю, что левое говно не должно попадать в мэйлбокс, а ты говоришь, что можешь открыть свой мэйлбокс и понюхать любое говно в нем.
>а так же обоссать тебя прямо из консоли
Вот она - привычка в рантайме свой говнокод вилкой чистить. В нормальных языках, где компилятор сам выполняет все проверки, НИНУЖНО ничего в рантайме чистить вилкой.
>пиздец ты поехавший
Поехавшие - те, кто считают динамическое говно сладким хлебом.
>>340894
>Ты в глаза ебешься? Я же написал
>>но при этом оно удаляется
>Любое совпавшее с шаблоном сообщение по прочтению удаляется. У нас любое совпадает.
Совсем уже мозг потек на 100500 потоков/нитей (которые и не потоки не разу, а голимые функции последовательно в потоке исполняемые) ? Ты вообще не чувствуешь разницу между попаданием сообщений в мэйлбокс (реальная причина засирания) и их обработкой? Как, скажи, как, блядь, клоз в обработчике может помешать попаданию сообщения в мэйлбокс? По твоей логике: Часто стирать штаны == не срать под себя. Если ты так считаешь, то ты уже обосрался.
>>340931
>всё правильно пояснил
Из 4 серьезных предъяв:
- Ответил за 0.5 (что область видимости актора даже может быть как-то ограничена (ну нихуя себе));
- Полностью признал остальные 3.5;
>всё правильно пояснил
И под шконку уполз.
>>341094
Так ты же тупой как бревно.
Ещё раз объясняю, читай по слогам что ли.
Попавшее в майлбокс сообщение сопоставляется со всеми шаблонами из receive. Если оно совпадает хотя бы с одним, выполняется соответствующая инструкция и ЭТО СООБЩЕНИЕ СРАЗУ УДАЛЯЕТСЯ ИЗ МАЙЛБОКСА. Засирание майлбокса возможно только если актору приходит сообщение, которое он не знает как обрабатывать. Такие сообщения актор игнорирует и не удаляет. Чтобы этого избежать пишут:
receive
{huita, _, HuitaMessage} → huita(HuitaMessage);
{govno, Pid, GovnoMessage} → govno(Pid, GovnoMessage);
Unknown → log(self(), unknown, Unknown), ignore
end
Когда актор получает сообщение, он поочередно сверяем его со всеми шаблонами. Последний шаблон Unknown сработает в любом случае, что значит, что СООБЩЕНИЕ ГАРАНТИРОВАННО БУДЕТ УДАЛЕНО ИЗ МАЙЛБОКСА.
>>341084
>В нормальных языках, где компилятор сам выполняет все проверки, НИНУЖНО ничего в рантайме чистить вилкой.
Есть статический анализатор, который по такому-то http://www.it.uu.se/research/group/hipe/papers/succ_types.pdf success typing'у так же все проверит до запуска.
>>340936
[Фэйспалм.жпг] - с кем я говорю. Ты оказывается не можешь в самые основы акторов. Что такое по-твоему мэйлбокс? Ты никогда не слышал, что в нем хранится ОЧЕРЕДЬ сообщений? Или ты думаешь обработка сообщений происходит в момент его отправки (попадания в мэйлбокс)? Что такое засирание мэйлбокса? Это ни когда в нем лежит что-то, что актор не желает обрабатывать, а когда сообщения поступают в него быстрее, чем обрабатываются. Сечешь? А теперь скажи еще что ты не понимаешь какое отношение ко всему этому имеет быстрый вброс левых сообщений в мэйлбокс нагруженного (теперь ты понимаешь значение этого слова?) актора ? А как можно выдавить из очереди нагруженного актора любое ценное/значимое сообщение с помощью вбросал перед ним лкучи левого говна, ты тоже не понимаешь? Короче, RTFM, я тут не собираюсь лекции по теории акторов читать.
>>341109
Интересно, почитаю, когда время будет. Ты сам то можешь вкратце пояснить суть? Например, как понимать это:
>It is important to point out that although Erlang is dynamically typed, it is type safe
>>341123
>dynamically typed
>type safe
Строгая, динамическая типизация.
мимо
>>341130
Неправда, ведь звучность строгой динамической типизации не сильно выше звучности слабой. Различие только в том, что слабая динамическая типизация старается помочь, спасая в некоторых случаях программу от краха и додумывая ее за программиста, а сильная сразу валит ее, отрицательно влияя на безотказность.
>>341136
>а сильная сразу валит ее, отрицательно влияя на безотказность.
А вот и нихуя. Программа должна падать при малейшем подозрении что что-то не так. Это безопаснее всего. Потому что если она продолжит работу, то есть риск что это будет при некорректных данных, которые приведут к некорректным действиям. Если некорректные действия программы опаснее её выключения, то лучше её выключить.
>>341160
> Программа должна падать при малейшем подозрении что что-то не так.
Это было бы абсолютно правильно при нулевой цене падения программы.
> Если некорректные действия программы опаснее её выключения, то лучше её выключить.
А если не опаснее? Ведь нету же статистички сравнения случаев "программа охуячилась и выдала неправильный результат - скоко $ потеряли" vs "программа охуячилась из-за ошибки тепезации - скоко $ потеряли из-за простоя". Или, может быть, ты меня обрадуешь, обвинишь в соснульстве, и в качестве четкого и дерзкого доказательства этому приведешь ссылку на такую статистичку?
>>341168
Но ведь дискурс идет в контексте динамической. Зачем ты сюда со своей статикопатокой влез?
>>341167
Статистику такую трудно сделать, потому что она будет дорогой. Последствия останова программы очень легко просчитать. А вот последствия её дальшейшей некорректной работы - нет. Потому что работать она может как угодно и все варианты просчитать невозможно. Риск в случае останова просчитываем, а риск в случае неостанова становится неопределенным. В этой ситуации нормальные люди выбирают первый вариант.
Я играл на бирже и пришел к тому что программа должна останавливаться при малейшем чихе (торговый робот). Хотя раньше всегда был сторонником либерального отношения к ошибкам.
Моя стата простая - из-за неостанова программы проебал 5К рублей (повезло что так мало).
Из-за нескольких остановок сохранил возможно приличные деньги (точно узнать нельзя, т.к. неизвестно что бы сделала программа будучи неостановленной, но то что набрала бы позиций на чужие деньги - это 100%. Возможно они оказались бы прибыльными и я бы даже заработал, но если убыточными, то влетел бы прилично и потенциально выше собственных активов, проще говоря полное банкротство и с долгами впоследствии).
Видел примеры как один робот слил 2 ляма рублей на фортс в 2009 году за 10-15 минут, и 2-4 млн долларов где-то в 2011 за 2 минуты. Вот там роботы не останавливались. Если бы они остановились, то они бы просто ничего не заработали, но и не потеряли бы. На всякий случай скажу что деньги это всё довольно большие и за такое время не зарабатываются за какое они были проиграны, по крайней мере теми алгоритмами.
Простой (отсутствие активности) на бирже это вещь очень и очень неопасная (перестает генерироваться прибыль при сохранении волатильности, если простой очень долгий, то там волатильность может несколько возрасти потом), в сравнении с ошибочными действиями, убытки от которых могут быть колоссальны на самом деле. Но это касаемо биржи. Может в других областях иначе, но я таких областей не видел и буду рад если ты приведешь примеры, желательно из своего опыта.
>>341172
Какая мне разница, что у вас тут обсуждалось?
Я увидел, что какой-то идиот утверждает, что ошибки типов при статической типизации в рантайме всплывают, и я поспешил его поправить.
>>341176
Это были ошибки типизации или ошибки алгоритмов?
>>341176
> Статистику такую трудно сделать, потому что она будет дорогой. Последствия останова программы очень легко просчитать.
Тока больно уж печально получается, а в вот во втором случае можно еще надеяться на авось.
> А вот последствия её дальшейшей некорректной работы - нет. Потому что работать она может как угодно и все варианты просчитать невозможно. Риск в случае останова просчитываем, а риск в случае неостанова становится неопределенным.
Риск в обоих случаях снижаем как дешевыми методиками, вроде наделать еще немного всяких там проверок, так и дорогими вроде диверсификации.
> В этой ситуации нормальные люди выбирают первый вариант.
А аппликативные и нуждающиеся люди какой выбирают? (:
Вообще если серьезно, то без статистички ничего определенного по поводу этих двух случаев сказать нельзя, и тот, кто занимается подобным - пытается делать значимые выводы на основе недостаточного количества информации. То есть занимается паранойей.
>>341184
Ты заблуждаешься, утверждалось что ошибки типов динамической типизации всплывают в рантайме, а не статической.
>>341189
Я не утверждал про ошибки динамической типизации ничего. Я утверждал лишь то, что ошибки типов при статической типизации отлавливаются на этапе компиляции.
>>341176
> Может в других областях иначе, но я таких областей не видел и буду рад если ты приведешь примеры, желательно из своего опыта.
Из моего опыта приводить я ничего не буду.
Но если пофантазировать, то какова будет цена падения самолетного ПО в случае ошибки типизации (оно конечно по ватчдогу перзапустится, но будем считать что падение было обусловлено IO и после перезапуска оно снова падает и снова и снова). Против цены неправильного управления, когда у пилотов есть возможность заметить, что компьютер врет и перейти на ручное управление?
> Из-за нескольких остановок сохранил возможно приличные деньги
То есть у тебя типизировались математические расчеты? Какие формальные методы применял для верификации и валидации?
>>341190
> Я утверждал лишь то, что ошибки типов при статической типизации отлавливаются на этапе компиляции.
На что тебе было совершенно справедливо указано не лезть в дискурс про динамическую.
>>341187
>а в вот во втором случае можно еще надеяться на авось.
>Вот это и есть ошибка.
>>341185
В моем случае ошибки были в данных, которые поставлял терминал (я не знаю конкретно из-за чего, терминал писал не я, код закрыт) и ошибки брокера (человеческий фактор). Робот на C#, компилятор там отловил все ошибки типизации еще на компиляции. На языках с динамической типизацией пишут только веб-макаки и самоубийцы.
>>341195
>Но если пофантазировать, то какова будет цена падения самолетного ПО в случае ошибки типизации (оно конечно по ватчдогу перзапустится, но будем считать что падение было обусловлено IO и после перезапуска оно снова падает и снова и снова). Против цены неправильного управления, когда у пилотов есть возможность заметить, что компьютер врет и перейти на ручное управление?
В такой ситуации нужен останов однозначно. Автопилот подает сигнал что он выключился и перестает портить ситуацию. Если же он продолжит действовать то есть риск сваливания в штопор, из которого выйти практически невозможно на пассажиских лайнерах.
>>341199
Ну ладно, уговорил, всё дело в невнимательности.
>>341200
> В моем случае ошибки были в данных, которые поставлял терминал
Ясно.
> Автопилот
Система управления самолетом. Не существует пути управления кроме как через нее и она постоянно падает из-за ошибок типизации. Не во всех системах автоматизированного управления машинами и механизмами существует путь непосредственного управления, через веревочки.
Впрочем здесь
> На языках с динамической типизацией пишут только веб-макаки и самоубийцы.
мы опять таки вышли из дискурса динамической типизации и достаточно быстро дошли до твоего внутреннего догмата, беседовать далее бесполезно.
>>341120
Ебать ты не умеешь выражать мысли, так бы сразу и писал.
Во-первых, всякие "нагруженные" акторы - это уже проеб дизайна, к одному актору не должно ломиться много сообщений. Этого легко добиться, если ты соблюдаешь простые правила, типа один актор, одна роль, и пишешь действительно конкурентную программу, где много мелких акторов, а не хуергу с 5 god-акторами делающими все. Если таких частей в программе не избежать, то делается пул акторов, разгребающих очередь, который можно контролировать.
Во-вторых, это опять проеб дизайна, что любая хуйня может послать любому актору любую хуйню. Реестр pid'ов заинкапсулирован и прямой доступ к нему есть только у одного процесса-модуля (и может быть у процессов порожденных им) предоставляющего api для внешнего мира.
>с помощью вброса перед ним
Это очередь, а не стек, сообщения дописываются в конец. Те сообщения, что уже были в майлбоксе никуда не вынесутся. Единственная проблема, что из-за вброса говна, сообщения идущие после него, будут обработаны чуток позже, чем обычно, ведь придется потратить время на удаление предшествующего говна. Актор читает подряд все сообщения, пока не дойдет до дна или не исчерпает свой бюджет редукций в рамках щедулера. Хорошо, что есть тот же PO Box, контролирующий message rate.
Скала отсосет у ерланга в сетевом I/O (там вообще есть захват актором сокета, автоматическая ивент-обертка, передача управления?), в хвостовой рекурсии (какие-то ограничения, вообще охуеть, в ерланге она Just Works), в отсутствии нормального remote shell'а.
RemoteActor/Terracotta не даст тех возможностей в плане распределенки, что у ерланга искоропке. У скалы тред-акторы - жирные треды ОС, более пару тысяч не запустишь, ивент-дривен акторы - это вообще какая-то насмешка, выполняются последовательно, один лочит всю VM, пиздец. Использование автоматически ресайзящегося тред-пула конечно забавно, но все равно нет лоу-латенси и разделения ресурсов поровну, более того, если все акторы будут вызывать блокировку, это приведет к разрастанию тред-пула до точки, где он не сможет дать более пары тысяч тредов.
В эрланге это произойти не может, там по щедулеру на ядре, простаивающие процессы не дают оверхеда.
В скале можно передавать в сообщении объекты ссылочного типа, и вот блять снова привет sharing data и race conditions, никаких гарантий. И сколько бы ты не говорил, что hot code swaping нинужно, он охуенен, jvm дает только кастрированное подобие. Скала по конкуренси не может даже кложуру догнать, что там говорить про ерланг, это для вас jvm-петухов недосягаемая роскошь. Я ещё понимаю хаскелитный Spark, там действительно можно померятся пипками, а так, пиздуй отсюдова, мальчик.
Рис № 42. "Сорта динамической типизации".
(сверху вниз, слева направо) 1.Строгая; 2.Нестрогая; 3.Полустрогая; 4.5.6...ect.
>>341212
Блядь, ведь хотел же подробно твой пост разжевать, на все по порядку ответить. Но тут у меня БОМБАНУЛО.
>У скалы тред-акторы - жирные треды ОС, более пару тысяч не запустишь, ивент-дривен акторы - это вообще какая-то насмешка, выполняются последовательно, один лочит всю VM, пиздец.
НУ ЛОЖЬ ЖЕ, БДЯДЬ. НАГЛАЯ ЛОЖЬ!111111111111111
Вся как сказано >>340248
>анальный раб Тайпсэйфа, который дрочит на реактивное программирование и молиться на Акку. Он уперт, религиозен, фанатичен, не имеет собственного мнения и только повторяет заученную пропаганду Тайпсэйфа
Точнее не скажешь
Сейчас успокоюсь и попробую все подробно расписать.
>>341212
>Скала отсосет у ерланга в сетевом I/O
Это тебе менеджер из эриксона таких охуительных историй нарасказывал?
>там вообще есть захват актором сокета
Что захуйню я читаю? Что такое по-твоему актор? Это что нода? - ХУЙОДА! АКТОР (для тех кто не в курсе) - это просто ФУНКЦИЯ не возвращавшая значения и выполняемая асинхронно (отсюда все фитчи) в цикле. Какой, блядь, захват сокета (теперь)?
>автоматическая ивент-обертка, передача управления
Что это? Еще один маркетинговый ход ериксона? Наверняка какой-то велосипед, который давно валяется в библиотеках многих языков и никто такой ерундой не хвастается.
>в хвостовой рекурсии (какие-то ограничения
Хвостовая рекурсия в скале ВСЕГДА компилируется в максимально быстрый код (где возможно через цикл, где невозможно через вызов на стеке). Все ограничения - просто ворнинги для байтоебов, которые хотят засунуть свой нос в сам механизм компиляции. Могу поспорить, в ерланге компилятор устроен так-же (все другие варианты - не оптимальны), только ты об этом даже не знаешь.
>У скалы тред-акторы - жирные треды ОС
Такую хуйню мог написать только человек, очень далекий от скалы или с полностью промытыми пропагандой мозгами. Мимо же люди проходят, ведь поверить же могут, лол. Поясняю еще раз: Актор - просто функция (НЕ НОДА, НЕ ПОТОК, еще раз это прочти), которую вызывает шедуллер и передает ей сообщение из очереди. Сам шедуллер может быть устроен как угодно, почти все реализации акторов (даже акка) позволяют внутри себя выбирать реализацию шедуллера (ерланг и тут соснул). Можно, например взять ExecutionService с пулом потоков, он нагружает все потоки пула по максимуму: Как только один актор отработал сообщение в это же потоке запускается другой активный актор, в очереди у которого есть сообщения. Это практически наиболее ОПТИМАЛЬНЫЙ из возможных вариантов распределения нагрузки между потоками ОС. Или давай придумай что-то лучше (если можешь в многопоточноть в ОС), только для начала выкинь из своей башки весь этот маркетинговый чес про СУПЕРБЫСТРЫЕ-ОЛОЛО-ПОТОКИ, забудь эти сказки. Там внутри OTP все реализовано точно так же, потому что иначе это реализовать невозможно. Разница только в том, что OPT закрыта и тебе приходится верить/не_верить сказкам маркетологов, а на скала ты можешь сам выбирать/настраивать/крутить-на-хую шедуллер или писать свой.
>Скала по конкуренси не может даже кложуру догнать
Одно история охуительнее другой. Даебали уже такие пиздобольские заявления без пруфов. Особенно от человека с промытыми мозгами ("Акторы = потоки ОС" - не перестаю лоллировать).
>>341136
Отрицательно это "додуманное" поведение или нет, зависит от приложения конечно, но вообще это ошибка. На всякий случай для прояснения терминолгии:
>http://en.wikipedia.org/wiki/Type_safety
>In computer science, type safety is the extent to which a programming language discourages or prevents type errors. A type error is erroneous or undesirable program behaviour caused by a discrepancy between differing data types for the program's constants, variables, and methods (functions), e.g., treating an integer (int) as a floating-point number (float).
Чем строже типизация, тем меньше вероятность таких ошибок (inb4 кэп). В некоторых реализациях динамических яп тоже есть возможность проанализировать код до рантайма и поймать там ошибки типов. Что касается нежелательного краха и простоя программы - это не обязательно должно решаться смягчением типизации, гораздо лучше иметь возможность перезапустить процесс в случае ошибки и получить новый, корректно работающий вместо некорректно работающего старого.
>>341241
То есть актов это простой калбак? Хуле вы тогда свою хуйню развели?
Смотрите, что думает о Скалке создатель Lift, после того, как он слегка познакомился с Clojure:
http://skillsmatter.com/podcast/java-jee/some-musings-on-scala-and-clojure-by-a-long-time-scala-dude
>>341228
Насколько я знаю, нормальный мультитаскинг реализован только в Эрланго-VM, в GHC и в Go. Подразумевается, что для этого нужна вытесняющая многозадачность, никакое кооперативное говно на такое претендовать даже не может.
GHC переключает процесс - когда нужна память, Go просто переключает контекст канала, так что затяжной луп может зойхавать ядро.
Только эрланг переключает процессы по исчерпыванию ими бюджета (~1ms) и только он дает чистый fair use.
В остальных моделях, в Ocaml, Node.js, Twisteded etc такого нет, у их щедулер не умеет двигать процессы, они не могут быть приоретезированы и т.д.
>>341244
Актор - это паттерн проектирования. См >>340722, т.е. вся concurrency может быть исполнена:
1. Старомодно на потоках, синхронизациях, блокировках;
2. На акторах (если смешать их с (1), то весь смысл теряется);
3. На Promise/Future;
4. Чисто (+лениво) функционально. Все проблемы concurrency тут снимаются, и шедуллер может сам запускать все ленивые вычисления как ему покайфу без последствий.
5. В принципе не исключены другие варианты, если они не сводятся к (1).
Но сам одиночный актор, по сути своей - это просто функция, которую шедуллер крутит в цикле, подавая ей на вход сообщения из мэйлбокса (очереди). Но эта функция нигде не вызывается непосредственно, а только через отправку ей иммутабльных (это важно) сообщений. Все вместе это решает проблемы concurrency без синхронизаций и блокировок.
>>341241
Дааа, на горелом заду адекватный пост не напишешь.
>Что это?
>Какой, блядь, захват сокета
Такой, что твой процесс-актор становится владельцем сокета, теперь он обменивается с ним сообщениями, как с другим актором.
>КО-КО-КО АРРРГХ МАРКЕТОЛОГИ!!1
Scala has two types of Actors: thread-based and event based. Thread based actors execute in heavyweight OS threads. They never block each other, but they don't scale to more than a few thousand actors per VM. Event-based actors are simple objects.
http://lampwww.epfl.ch/~phaller/doc/haller07actorsunify.pdf
>>341254
The difference with Erlang processes is that within each OS thread, event based actors execute sequentially without preemptive scheduling. This makes it possible for an event-based actor to block its OS thread for a long period of time (perhaps indefinitely).
In Erlang processes are guaranteed to be switched approximately each 1000 reductions. In such a naive framework as Scala/Akka agent owns a scheduler until it finishes work in receive. Checkmate. Game over. Hasta la vista:) People, do not waste your time on pseudo techs. I shocked that guys here compare Scala with Erlang.
Also there are many other so called "killer features", but here is my advice, do not think in terms of features, think about idioms that enables particular language. Scala steals "best features", Erlang enables/implements you with right idioms to build systems reliably, with high level language that driven from those right idioms. When you learn Erlang you are rebuilding your mind, your way of thinking about distributed reliable system, Erlang teaches you and upgrades you. Scala is just another one imperative (oh, sorry, multiparadigmal, funny word) language that tries to steal good features from other languages.
>>341256
А че шах и мат то? Ты так говоришь будто у нас на нативоговне байтобляди не городят преемптив планировщики. Неужели на нейтиврговне можно а на жвм нельзя?
>>341250
Давай поаккуратней с терминологией. Ты говоришь о threads (потоках/нитях/тредах), процессы ОС - это отдельные адресные пространства, виртуальная машина (ВМ) работает внутри процесса ОС и не может его переключать.
>вытесняющая многозадачность
Реализуется на уровне ОС. ВМ чаще всего не должна этим заниматься. Вычисления внутри ВМ обычно распараллельиваются так - ВМ сразу закупает несколько десятков потоков ОС (можно и несколько сотен, не таки они и тяжелые, как говорят) и распределяет свои мелкие задачи (акторы, например) между этими потоками. Нагруженные потоки ОС шедуллит между ядрами ЦП, заблокированные/ожидающие занимают только поток ОС, но ни как иначе не тормозят систему. Опасность тут только в том, что выделенных потоков ОС может тупо не хватить на все задачи (много мелких акторов) и их придется прикупать/продавать походу, а это накладные расходы и тормоза. Отсюда идея об Асинхронности. Смысл - закупать у ОС потоки по количеству ядер ЦП (или чуть больше), если задачи не будут блокировать потоки на время IO, то потоков должно хватить.
>Только эрланг переключает процессы по исчерпыванию ими бюджета (~1ms)
Такое поведение можно написать и для акторов на скала. Только нет особого смысла перекидывать легковесные "потоки" между потоками ОС, кроме как в моменты получения сообщения актором, все эти таймеры, пуски/остановки - это только дополнительный оверхед. Если большинство акторов отрабатывают за время в сотни наносекунд, то квант времени в миллисекунду - лишен всякого смысла. Возможно все это придумано, как лекарство от зависаний для ериксоновского железа на котором ОСи (что там кроме самой OPT?) не имеют собственного шедуллера вытесняющей многозадачности, а потом уже широко распеарено.
>>341254
Хуйню какую-то нагуглил и мне в глаза ее тычишь. Нахуй убери это отсюда. Хватит уже заученную хуйню твердить. Пора включать собственный мозг и начинать думать без посторонней помощи. Ты изучаешь языки по туториалам и сторонним обзорам, а я в первым делом вычитываю исходники библиотеки, прежде чем подключить ее к проекту. А я наподключал "scala.actors" во много проектов. И "scalaz.concurrent" я тоже не раз перечитал. Я знаю как они устроены до последнего винтика. Я бы свою библиотеку акторов на коленке написал бы с закрытыми глазами, вот только нахуй нужен еще один велосипед. Ты бы немного для начала ознакомился с тем, что в треде уже было >>340558 а потом бы попиздел про свои heavyweight-потоки.
>Дааа, на горелом заду адекватный пост не напишешь.
Но в этом ты прав, СУКА!!111
>>341256
>Checkmate. Game over. Hasta la vista:)
Показывает уровень того школьника. От того, что он англоговорящий, умнее он не станет.
>rebuilding your mind, your way of thinking
Ты и теперь тут не видишь высера маркетологов?
>Erlang teaches you and upgrades you.
Похоже на пиздежь менеджера продавана из Мвидео. "Вы еще кипятите (на скала) тогда мы (ерланг) идем к вам". Только дебилы могут на это вестись.
>>341256
На самом деле 2к редукций, но это настраивается, да.
-Erlang does copy-on-send
- Akka uses shared memory.
>shared memory
И на этом месте настоящая модель акторов заканчивается.
>>341258
В эрланге процессы - это треды VM, но они не совсем треды, так как у каждого - свой стек, свой хип, есть приоритет, и они вытесняют друг друга, прямо как процессы ОС, но живут внутри VM. Эрланг запускает на каждом ядре по инстансу, за счет прозрачности передачи данных, процессы общаются между ними, так, как будто они внутри одного инста. Каждый инст - контролирует переключение своих процессов, по исчерпанию бюджета, если процесс не доделал свою задачу, он бросается в конец очереди, таким образом все получают поровну, сборка мусора кстати тоже. Эрланговское IO живет в ОС процессах. Нить весит ~0.5 Кб, создается за 3-5 мкс. Такая дешевизна позволяет ебошить чуть ли не на каждую сущность по процессу. Если нужна оптимизация и контроль памяти - делается пул процессов, растаскивающая очередь.
>>341266
>Ты и теперь тут не видишь высера маркетологов?
Это просто какой-то хуй со стековерфлоу. Вангую что он фанатик, а это всегда хуево, но тут он прав же.
Что примечательно, почти в любом бложике, иксперт сравнивающий Scala и Erlang, говорит, что ирлонг лучше в плане конкурентности/распределености. Неужели эриксоновские маркетологи настолько вездесущи? А ну загляни под кровать.
Вон fb отписывались по поводу своего чата на эрланг, что он работает, как они и хотели. Разраб с ласт.фм, тоже писал, воу парни это охуенно один сервер свободно держит 1кк соединений, попробуйте. Они тоже куплены?
>>341256
Ладно, копнем по глубже этот маркетинговый высер.
>>341256
>In Erlang processes are guaranteed to be switched approximately each 1000 reductions.
Т.е. акторы работают по 1 миллисекунде в среднем. За это время можно перебрать несколько миллионов хэшей (это за один цикл работы актора, т.е. на убработка одного сообщения). Если ты реально пишешь такие тяжелые акторы, то ты точно наркоман. Нормальный актор в несколько (десятков) строк должен отрабатывать в несколько десятов/сотен наносекунд. Значит реальная скорость переключения между "задачами" (акторами) на два порядка быстрее (и на скале, и на эрланге и на хую моржевом), чем этот квант времени в 1 мс. Вопрос: Нахуй тогда нужно это ограничение в 1 мс, если реально оно не может быть достигнуто никогда или только по ошибке кодера, который проебал условие цикла?
Вопрос №2. Современные ОСи в реализации своей вытесняющей многозадачности используют квант времени >10мс. Т.е. не станут трогать полностью зависший поток как минимум 10 мс. Что мы имеем: проги виснут, это случается, но система при этом субъективно только "притормаживает", мы нигде не замечаем скачков и дерганий (кривые драйвера на видео в шиндос таки умеет это). Значит кванта времени в 10мс за глаза хватает для очень плавного распределения нагрузки. теперь вопрос: квант = 1 мс? Это мы перед кем решили повыебываться?
>>341264
Ладно, я согласен с тем, что не могу быть объективен, так как хорошо знаю только ирлонг, скалу знаю поверхностно. Но совершенно очевидно, что многое зависит от платформы. Если beam.smp заточена под акторов и конкуренси, то jvm - нет, что значит, что создание хорошей модели поверх неё - задача сложная и по своей сути - костыль. Делать на уровне языка/библиотеки, то, что должно быть выполнено на уровне платформы - это никак не хорошее решение. Учу сейчас скалу, мне нравится удобная система типов, наличие хуевой тучи либ, улучшенное еба ООП, гора синтаксического сахара для ФП.
>>341274
1. Актор ограничен только верхним пределом. Если он справляется быстрее 2к редукций, ок молодец, переключаемся на следующего. Бюджет в ~1 ms выделяется на все в рамках щедулера. Сборка мусора, отправка сообщения, выборка из таблицы, I/O в порт, посылка сообщения на другую ноду, абсолютно все. Ещё раз, только верхний предел.
2. Квант можно настроить. В некоторых системах провисание > 5мс - уже плохо. Но опять таки, это все настройки рантайма.
>>341267
>В эрланге процессы - это треды VM
Очень сомневаюсь в этом. Тысяча нитей под нагрузкой положат всю ОСь так, что курсор мыши не отрисуется. А акторы могут работать десятками тысяч (те самые хваленые "Легковесные" потки). В Скале также могут работать (а не просто болтаться в ожидании) десятки тысяч акторов, при этом они работают на пуле в 16 (например) потоков ОС.
>>341267
>Эрланг запускает на каждом ядре по инстансу
Лол. Так прям в руководстве написано? Ну начнем с того, что процесс в юзерспэйсе к ядрам ЦП доступа имеет нихуя. Все что он может, это создать несколько потоков ОС (по колличеству ядер или в два/четыре раза больше) и надеяться на то, что ОС-шедуллер разложит эти потоки по ядрам (в лучшем случае) когда на всей ОС нет других активных потоков.
>Нить весит ~0.5 Кб, создается за 3-5 мкс
Это подтверждает, что к потокам ОС эти потоки отношения не имеют.
Ну в общем все что ты описал соответствует (грубо) шедулленгу "задач" на ExecutionService (кстати прочитай про него), который используется в шедуллере акторов "scalaz.concurrent" и в акка. В "scala.actors" используется ForkJoin, который устроен чуть по-хитрее, но на том же принципе (быстрое переключение "задач" на пуле потоков ОС).
>>341269
>Неужели эриксоновские маркетологи настолько вездесущи?
Допускаю что большая часть проектов на ерланге более производительна, чем большая часть проектов на скала.
Этому могут быть разные причины.
1. Многие скалисты - бывшие джависты, привыкли пердолиться абстрактными фабриками абстрактных адаптеров во имя энтерпрайза.
2. Скала еще не полностью оторвалась от рантайма джавы. А большинство крупных (сегодня) проектов начинали писаться в те времена, когда скала еще плотно сидела на жаберном рантайме. Все эти переходники/адаптеры вносят значительный оверхед.
3. Скала - мультипарадигменный это охуительно низкая производительность в реальных проектах показывает, что это очень плохо, когда разрабов не принуждают к определенному стилю.
4. Ерланг - В чем-то препятствует написанию быдлокода. (Но вот динамическая сущность сообщений, наоборот способствует).
5. Возможны еще варианты.
Все это не означает, что что-то мешает писать на скале такие же крутые веши, как на эрланге. Все зависит от кодера.
>>341283
Так, ещё раз по-порядку.
Инстанс VM - процесс ОС.
Если ты запускаешь рантайм с no-smp их будет всего 2, один из них - под IO. Если запускаешь как обычно, с smp - их будет ровно столько, сколько ядер на машине + 1 под IO.
Больше процессов OС нет.
Эрланговские "процессы" - это треды внутри инстанса, с процессами ОС ничего общего не имеющие ВООБЩЕ.
Называются они процессами, по той причине, что они не похожи на треды VM в обычном понимании. Они не разделяют данных, у каждого свой хип, они вытесняют друг друга и имеют приоритеты.
>>341286
И за щедулинг отвечает не ОС, а только VM.
Более того, "процессы" мигрируют между инстансами.
Там встроенный балансировщик, следящий за тем, чтобы ядра были нагружены равномерно. Если тасков меньше, чем надо, он старается освободить ядро, перевести инстанс на нем в пауер сэйф моде. Так же щедулер может воровать таски у других инстансов, если ему нехуй делать.
>>341281
>Делать на уровне языка/библиотеки, то, что должно быть выполнено на уровне платформы - это никак не хорошее решение.
Если платформа как-то мешает этому, то да. Но jvm сама почти не в вмешивается в эти вопросы (кроме сборщика мусора). Нативный класс Thread - очень тонкая обертка вокруг потока ОС, а более низкого уровня не существует. Библиотечный код (реализующий модель акторов, например) компилится JIT-ом так, что по скорости на 150% (а не на 1500% как руби и прочие пхп) отстает от кода на С. Если учесть, что само переключение задач и вся инфраструктура шедуллера съедают не больше 1% времени, то нет смысла гоняться за проебанными долями процента. Что мы получаем взамен - весь код открыт + можно переписать что-угодно под себя (!)
>>341286
>их будет ровно столько, сколько ядер на машине + 1 под IO.
Если все действительно так, тогда непонятно зачем создавать несколько процессов ОС. Насколько я знаю, так поступают только PostgreSQL и старые версии MySQL для совместимости с какими-то редкими *никами у которых проблемы с потоками в нормальном понимании.
Еще тогда "перекидывание" треда (эрланговского процесса) между инстанцами (из одного адресного пространства в другое) - задача не быстрая.
>они не похожи на треды VM в обычном понимании.
ORLY?
>они вытесняют друг друга и имеют приоритеты.
Как и все потоки в большинстве современных ОС.
>у каждого свой хип
Это достигается средствами вм. На jvm и .net все также
>Они не разделяют данных
Или разделяют иммутабильные дынные
>>341288
>И за щедулинг отвечает не ОС, а только VM.
Че, правда? Это еще каким образом?
>Там встроенный балансировщик, следящий за тем, чтобы ядра были нагружены равномерно.
Ну начались охуительные истории. Тут байтоебов обсирают в соседнем треде, вот он, пример того, как сильно можно размечтаться, если не знать элементарные принципы работы ОС.
Повторяю еще раз: Все что может сделать любая программа, работающая в юзерспейсе - это работать с потоками ОС, создавать/удалять/менять_приоритеты (приоритеты номинальны, их соблюдение полностью зависит от ОС). Также можно шедуллить собственные "задачи" между этими потоками. А еще можно помолиться Балмеру/Торвалдсу, чтобы шедуллер ОС дал этим потокам каждому по ядру CPU.
>>341292
Erlang использует частные топологии кучи. Каждый поток имеет свою собственную крошечную кучу, которая содержит все данные, используемые потоком и его стек. Все данные потока находятся в его локальной куче. Она резервируется, когда создается поток. Когда поток уничтожается, вся куча просто возвращаются в пул свободной памяти. Кучи являются закрытыми.
>>340693
То, что Скала - говно для джавапитухов я и так знаю, меня интересует именно паттерн. Актор - объект, к которому прикручена очередь сообщений, в ответ на сообщения о меняет своё состояние, посылает сообщения, создаёт другие акторы - т.е. делает что угодно. Но это и есть ООП в первозданном виде с его питушинной семантикой. И еще вокруг акторов много всякого гуманитарного хайпа. Я ничего не упустил?
>>340722
Поясни по хардкору, что там такого? Вот та же STM в хачкеле по сути оптимистическая блокировка с ретраями, плюс она вся такая композабельная (благо сайдэффекты изолированы и ретраи жопаболей не доставляют, но никакого рокетсаенса, чтобы целые книги писать, там нет). Суть акторов?
>>341298
> Суть акторов?
Чтобы не жрать говно и не разделять данные.
у скаладебила горит пердак.
erlang > clojure > моча > говно > дно > хохол > scala
>>341298
>Поясни по хардкору, что там такого?
Здесь заканчиваются потоки управления, и отсюда начинаются потоки данных + Большие профиты в плане производительности: Нет синхронизации, нет блокировок, невозможно крайне сложно написать деадлок + есть минимальная защита от говнокода.
>И еще вокруг акторов много всякого гуманитарного хайпа.
Ни без этого. Акторы - первая ступенька из императивного мира к функциональному, на этой ступеньки многие гуманитарии ломают себе ноги, весь шум вокруг - просто их писк.
>в ответ на сообщения о меняет своё состояние
Это из быдлопедии что ли цитата? На Scalaz например, актор вообще расширяет функцию, а значит иммутабелен по природе.
>плюс она вся такая коммуникабельная
Еще одно открытие для тебя - акторы Scalaz - таки композабельны (за сайдэффекты, конечно, ты сам отвечаешь), прикинь да.
>но никакого рокетсаенса, чтобы целые книги писать, там нет
Потому что в stm не приходят сотни вчерашних джаваобезъян, это на несколько порядков выше их уровня.
>>341304
Моча > быдло < горит > пердак < дебил
ОЛОЛОЯВСЕХВАСЗОТРОЛЕЛ
О, кто к нам пожаловал... Ежедневный обход всех тредов перед сном? Что за ритуал такой?
>>341257
Когда на жвм делают асинхронщину, то заводят пул потоков и используют форк-джойн, т.е. чтобы не создавать постоянно новые трэды передают таски на те трэды, которые свою таску завершили. Теоретически, между работающими трэдами ресурсы CPU делить ОС. Но вполне возможен отсос, когда все трэды из пула зохватили таски с бесконечными циклами, и новые таски не выполняются. А ДАЛЬШЕ ПЕРЕПОЛНЯЮТСЯ БУФЕРА IO КРОВЬ-КИШКИ-РАСПИДОРАСИЛО РЕСТАРТУЕМ СЕРВЕР ВСЕ ЛОМЯТСЯ ТУДА ОН ОПЯТЬ ПАДАЕТ ПЕРЕПОЛНЯЮТСЯ БУФЕРА НА КЛИЕНТАХ ВСЁ НАХУЙ РЕСТАРТУЕТ ИЗВИНИТЕ ЗА ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ НАС АТАКОВАЛИ ЗЛЫЕ ХАКЕРЫ
8470
[EMIR][COM][CR] Master Aggreement Name/Date reporting should only be performed for Commodities trades - implement
rumosws200701
>>341300
Подробнее. Любая парадигма нужна чтобы не жрать говно.
>>341306
>Нет синхронизации, нет блокировок
Но это пиздёжь ведь полный, там везде внутри LOCK XCHG [хуй], пизда. Дедлок там делается так же как и везде - актор "а" ожидает сообщение "x" от актора "б" (все остальные сообщения признаются в данном состоянии некорректными либо игнорируются, не в курсе деталей семантики), актор "б" ожидает сообщения "y" от актора "а". Т.е. там где блокировок не будет в императивной парадигме там их и на акторах не будет, а там, где они подразумеваются by desing, никакие акторы от них избавиться не помогут. Ну или приведи пример, в котором на обычной парадигме будет кровь-кишки-распидорасило, а акторы как-то решат проблему.
>>341335
Когда на джаве делают асинронщину, используют эту хуйню - http://en.wikipedia.org/wiki/Reactor_pattern. Единственное отличие от async-монад в эрзацах функциональных языков программирования (в настоящих функциональных языках программирования IO и так монадический, поэтому никаких специальных Asnync монад городить не надо) - это то, что в случае Reactor_pattern-а на императивном говне код превращается в нечитаемую лапшу.
>>341380
Блядь, какая-то хуйня из банка в канаде скопипастилась. Модератор, удали тред, а то меня комплаенс трахн
>>341380
> Когда на джаве делают асинронщину, используют эту хуйню - http://en.wikipedia.org/wiki/Reactor_pattern.
Я имел в виду асинхронное IO. Внутри процессов нормальные люди просто используют BlockingQueue, лапша из листенеров для быдла.
>>341381
>трахн
Обязательно, я уже настучал куда надо.
Готовь туза, манька.
>>341558
Неужели здесь кто-то кроме меня форсить Кложу? Приятно удивлён.
>>341595
нахуй иди чмо, удивлён он блять, посцал на тебя.
>>341382
>Внутри процессов нормальные люди просто используют BlockingQueue
В смысле? Обмен сообщениями через очереди вместо прямых вызовов? Но в этом же и заключается модель акторов. На самом деле, таких "нормальных людей" в вджава мире можно по пальцам пересчитать.
>>341380
>Дедлок там делается так же как и везде - актор "а" ожидает сообщение "x" от актора "б" (все остальные сообщения признаются в данном состоянии некорректными либо игнорируются, не в курсе деталей семантики), актор "б" ожидает сообщения "y" от актора "а".
Гайдлайны осуждают написания акторов, ожидающих конкретного сообщения (имеющих состоянии из которого может вывести только одно сообщение), актор в каждом своем цикле должен реагировать на любые (валидные) сообщения из очереди. Конечно, никто не может помешать обезъяне написать логику с взаимными ожиданиями, но
>Ну или приведи пример, в котором на обычной парадигме будет кровь-кишки-распидорасило, а акторы как-то решат проблему.
Классика жанра: два взаимоожидающих потока упираются в синхроблок и виснут. Акторы продолжают работать, реагируют на другие сообщения. Задача, вызвавшая взаимную зависимость, конечно, остается не решенной, но потоки не блокируются, обработка сообщений продолжается и внешний супервизор может даже разрешить взаимную блокировку путем посылки спец.сообщения, выводящего акторы из состояния ожидания.
>>341380
>там везде внутри LOCK XCHG [хуй], пизда
Это происходит конкретно в Atom в ConcurrentLinkedQueue, знаем, знаем.
Блокировки шины на один такт - это же самый правильныйЪ метод межпотокового взаимодействия, никаких циклов, никаких ожиданий. Теперь сравни это с ожиданиями на мьютексах в синхроблоках.
Ты наверно знаешь пример реализации межпотокового взаимодействия без блокировок вообще (даже шины)? Поделись же с нами, как это работает?
>>341335
>Когда на жвм делают асинхронщину, то заводят пул потоков и используют форк-джойн
Совсем не обязательно через ForkJoin. Есть еще старый добрый ThreadPoolExecutor. Хотя, по сути, это те же яйца, вид сбоку.>>341335
>Но вполне возможен отсос, когда все трэды из пула зохватили таски с бесконечными циклами, и новые таски не выполняются.
Тут есть два варианта:
1. Зависло конечное число потоков и новые зависающие не порождаются.
- Тут пул (например, такой Executors.newCachedThreadPool()) может выдержать. Если планировщик, выполняемый в отдельном потоке, заметит эту ситуацию (таймера никто не отменял) он точно так же может засуспендить или поубивать зависшие потоки и пересоздать соответствующие задачи.
2. Зависающие задачи продолжают порождаться бесконечно.
- Тут не спасет ни какая реализация планировщика и никакая вытесняющая многозадачность. Через несколько секунд неизбежно переполнение стека или зависание.
>Ты наверно знаешь пример реализации межпотокового взаимодействия без блокировок вообще (даже шины)? Поделись же с нами, как это работает?
В Танненбауме есть алгоритм для двух потоков. Я это как-то обдумывал. В голове есть схема, которая даже должна работать, но в ней придется если не шину блокировать, так пихать кучу volatile, а это "иди нахрен, кэш".
>>341807
>Гайдлайны осуждают
пиздец. А еще гайдлайны осуждают выделение памяти без её освобождения да и вообще написание быдлокода.
>Классика жанра: два взаимоожидающих потока упираются в синхроблок и виснут. Акторы продолжают работать
Да я уже понял, что никаких конкретных примеров не понял, только гуманитарная хуита и маркетинговый булшит. Расходимся, поцоны.
>>341847
fix >никаких конкретных примеров не будет
>Теперь сравни это с ожиданиями на мьютексах в синхроблоках.
А нечего сравнивать, лол.
>>341849
>А нечего сравнивать, лол.
Или ты не понимаешь во сколько раз synchronized { }[/coode][/b] медленнее, чем [b][code]AtomicInteger.getAndSet()[/code][/b] или тебе просто нечего сказать?
>>341837
1. Где конкретно у Таненбаума ? Или сам алгоритм приведи.
2. Ванга говорит, что в точке синхронизации там должен быть цикл в котором он "ждет" (у него может быть другой смысл, но сам цикл должен быть) другой поток.
3. Если Ванга права, то это фэйл. Потому что в ConcurrentLinkedQueue нет циклов (даже на уровне машинного кода) ни при записи ни при чтении из очереди.
>1. Где конкретно у Таненбаума ? Или сам алгоритм приведи.
Пожалуйста. Это бы даже имело смысл, если бы прямо на процессоре была пара мегабайт адресуемой памяти. А так, нужно к interested и turn обращаться напрямую через оперативку. Выгода, если она была, теряется.
>2. Ванга говорит, что в точке синхронизации там должен быть цикл в котором он "ждет" (у него может быть другой смысл, но сам цикл должен быть) другой поток.
В моей суперсхеме у каждой критической секции ровно по два владельца, а всё, что они должны сделать - это записать значение указателя. Можно пережить, тем более гонка не будет возникать постоянно.
>3. Если Ванга права, то это фэйл. Потому что в ConcurrentLinkedQueue нет циклов (даже на уровне машинного кода) ни при записи ни при чтении из очереди.
А вот и есть. Цитата из статьи.
dequeue(Q: pointer to queue t, pvalue: pointer to data type): boolean
D1:loop # Keep trying until Dequeue is done
>>341807
> >Внутри процессов нормальные люди просто используют BlockingQueue
> В смысле? Обмен сообщениями через очереди вместо прямых вызовов? Но в этом же и заключается модель акторов.
Разница в том, что в случае с очередями вся логика остаётся линейной и сосредоточенной в одном месте, в отличие от акторов, где логику нужно дробить на кусочки и разбрасывать по ивент-хэндлерам. А когда логика ещё и недокументирована, то обратно её собирать из кусочков заёбывает.
> На самом деле, таких "нормальных людей" в вджава мире можно по пальцам пересчитать.
Увы, ты совершенно прав. Говнокодеры евривэа.
>>341914
> вся логика остаётся линейной и сосредоточенной в одном месте
Вообще-то дробление монолита на минимальные объекты с единой ответственностью - это правильно, и лежит в рамках любой нормальной парадигмы.
>разбрасывать по ивент-хэндлерам
Код по прежнему остается линейным.
Это тебе не ивент-дривен ноджеесо-подобная колбек-дрисня.
Ивент-дривн акторы, пиздец какой-то, только поверх уебищной jvm такую хуйню можно было написать.
И последнее, в тру-модели акторов - нет разделения данных. Любое конкурентная модель основанная на разделении данных - ад и погибель, написание и поддержка таких систем имеет куда больше общего с долбежкой в сракотан армированным дилдо, чем с программированием. Исключение составляют ЯП которые гарантируют иммутабельность и изоляцию сайд-эффектов. В остальном модель акторов >> control frow.
>>341857
>Или ты не понимаешь во сколько раз synchronized { }[/coode][/b] медленнее
Да, понимаю: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=chameneosredux&lang=all&id=1&data=u64q - задача на конкурентность - Erlang в 81 раз медленнее, Scala - Failed.
>>341863
>в ConcurrentLinkedQueue нет циклов
http://fuseyism.com/classpath/doc/java/util/concurrent/ConcurrentLinkedQueue-source.html
на 190 строке что, хуесос ты эдакий?
>>341934
>Scala - Failed.
Ты в глаза ебешся?
>22 Scala #2 41.02 13.56 57,564 1171 77% 82% 74% 74%
Скала = x 22 Почти в 4 раза быстрее ерланга.
И где теперь твой бог?
>>341934
Который раз убеждаюсь, что бенчмарки для языкосрачей пишут полные уебки не могущие не в один из языков. Вот и пример: код на скала http://benchmarksgame.alioth.debian.org/u64q/program.php?test=chameneosredux&lang=scala&id=2 - это же машинный перевод дешевый рерайт джава-кода! И что теперь показывает этот бенчмарк? Угол кривизны пальцев индуса? Или жлобство манагера, который решил сэкономить на кодерах?
Вообще нахуя ты это сюда притащил? Вопрос был не о фаллометрии между языками, а о том, что передача сообщения через ConcurrentLinkedQueue, в несколько (десятков?) раз быстрее, чем вход в synchronized-блок.
>>341946
Внимательнее на него посмотри. Этот цикл имеет номинальное значение. Это не обход очереди/списка. Практически он должен выйти по return на первой же итерации. Уход на вторую итерацию возможен только в ситуации конкуренции потоков за значения head tail внутри функций poll и offer. Это означает, что вероятность ухода на вторую итерацию равна Tвнутри / Tобщее; где Tвнутри - время проведенное внутри функций poll и offer, Tобщее - полное время работы всей программы. Т.е. на практике это может быть около 1/1000000.
>>342065
Стандартная либа скалы написана в таком же императивном стиле. Пруф https://raw.github.com/scala/scala/master/src/library/scala/collection/immutable/List.scala
>>342086
Мутабильные локальные переменные - ты об этом что ли? Так это не говнокод, а низкоуровневая оптимизация, которая применяется только в самых тонких (по быстродействию) местах. Совсем другое дело - мутабильные публичные свойства классов - в культурном обществе за такое пиздят ссаными тряпками.
>>342055
Только там нихуя не акторы, а старый добрый synchronized, про который местный говноиксперт пиздел, что он якобы медленнее.
>>342065
>это же машинный перевод дешевый рерайт джава-кода!
конечно, ведь попытки писать на джаве в функциональном стиле выльются в тормоза и переполнение стека.
>>342083
>цикл имеет номинальное значение.
гуманитарии совсем охуели
>benchmarksgame
Блять, любая ссылка на это говно должна наказываться тугой струи мочи прямо в лицо долба использующего её для подкрепления какого либо утверждения.
>>342243
КО-КО-КОНЕЧНО, как обычно - толсто, зелоно, голословно и без пруфов. Через пару постов ты объявишь, что всех затролил. Все кто не согласны - скам и быдло.
>>342245
Гуманитарий начинает кукарекать раньше, чем попытается разобраться в сути вопроса.
>>342256
Ну, отчасти этот толстяк прав, benchmarksgame - очень сомнительная контора РогаИКопыта™.
Кто-нибудь хотя бы читал этот высер http://benchmarksgame.alioth.debian.org/u64q/program.php?test=chameneosredux&lang=scala&id=2 ? Жалкло, на govnokod.ru нет раздела для скалы, там бы он занял достойное место.
>final case class Pair
Мы тут только что изобрели свой кортеж без блэкждэка, без шлюх и вообще без методов, т.е. просо голая идея Pair, о существовании которого автор не слышал.
>val Numbers = Array[String]("zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine")
>def getNumber(n: Int) = String.valueOf(n).toList.map { ch => Numbers(Character.getNumericValue(ch)) } .mkString(" ")
Догадайся что он этим хотел сказать. Я вот долго ржал, когда разгадал смысл этого куска говна.
>object Colours extends Enumeration {
Про sealed trait автор не слышал. Вот отсюда сразу идет ОХУИТЕЛЬНАЯ производительность и соответствующие результаты теста.
Дальше какие-то var-поля классов (вместо локальных переменных). Везде кошмарный джаваблядский стиль, местами встречаются неуместные map'ы и другие функциональные выебоны, которые ту все равно выглядят как гавно. Такое ощущение, что автор не осилил книжку Одерси даже до середины.
Итог: Тест очевидно заказной. Код явно был заказан группе школьников (один не осилит же), чтобы обосрать скалу (может и другие языки) и протолкнуть вверх какого-то своего кандидата.
>>342268
>толсто, зелоно, голословно и без пруфов
Анонимному хуесосу дали ссылку на бенчмарк, который по очевидным причинам был написан на джаве, анонимный хуесос сказал, что бенчмарк - говно. Анонимному хуесосу дали ссылку на стандратную либу, анонимный хуесос сказал, что стандартная либа не показатель. Анонимному хуесосу сказали что он хуесос - анонимный хуесос сказал, что толсто, зелоно, голословно и без пруфов. Разумеется у самого анонимного хуесоса полно прувов, но только мы их не увидим, ведь одно авторитета анонимного хуесоса уже достаточно, чтобы опровергнуть любые доказательства в виде бенчмарков и рельного кода.
>Гуманитарий начинает кукарекать раньше, чем попытается разобраться в сути вопроса.
Вот я вижу, что ты, питух, кукарекаешь, не понимая, как работают неблокирующие алгоритмы.
>benchmarksgame - очень сомнительная контора РогаИКопыт
Конечно, куда менее сомнительно пиздеть на двачах, не приведя ни строчки кода и не сделав ни одного замера.
>>342275
Напиши лучше, мы посмотрим, чей будет работать быстрее. Что, обосрамс? Ну да, скалоблядки соснули, опять.
>>342281
>Конечно, куда менее сомнительно пиздеть на двачах, не приведя ни строчки кода и не сделав ни одного замера.
Ой, кот бы говорил! Сам то много строчек своего кода сюда запостил?
Есть дела поважнее. Почему я это должен, это ты должен. Ко-ко-ко.
>>342283
Но как мы заставим их принять наш вариант, повторить весь тест на том же железе и софте, с теми же параметрами и включить результат в таблицу? Я бы не пожалел своего времени ради достижения справедливости.
Если я проведу тест сам у себя дома, то как доказать всем полученный результат?
>>342291
>Есть дела поважнее.
Пиздеть на дваче?
>Почему я это должен
Потому что ты тут много пиздел, хотя такие как ты за слова не отвечают, пиздёжь скалоёба легче перьев из жопы синицы.
> это ты должен
Я привёл ссылки, ты утверждаешь, что они говно и код там плохой, от того тормозной. Показывай свой, быстрый.
>>342292
Просто выложи код, чтобы каждый мог взять его, запустить дома (заодно осознать все прелести развёртывания джаваговна), и убедиться, что скала тормозит (максимум, что выжали уже на shootout-е), писать на ней в функциональном стиле нельзя (ибо jvm для этого не предназначена), и акторы никак не могут быть быстрее обычных блокировок.
>>342275
Var переменные класса конечно полный пиздец. А вот
>val Numbers = Array[String]("zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine")
>def getNumber(n: Int) = String.valueOf(n).toList.map { ch => Numbers(Character.getNumericValue(ch)) } .mkString(" ")
Как было бы лучше написать?
Я плохо знаю скалу, мне любопытно. Можно сократить до
>5123.toString.map(_.asDigit).mkString(" ")
это конечно короче но алгоритм почти тот же.
>>342292
Кроме того, если ты пришлёшь им свой вариант, и он окажется быстрее, они его выложат на сайте.
>>342299
> 5123.toString.map { c => Numbers(c.asDigit) }.mkString(" ")
fix
>>342295
>Аутист не чувствует inb4
>Сам себе отвечал => cам себя обосрал
>>342299
>Как было бы лучше написать?
Конечно длиннее одной строки. Зато производительность, здесь это не пустое слово.
def getNumber(n: Int) = {
val digStr = Array("zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine")
def div10(n: Int): Stream[Int] = n #:: div10(n / 10)
def digits(n: Int) = div10(n) takeWhile(_ > 0) map(_ % 10)
digits(n).reverse map(digStr) mkString(" ")
}
>>342283
При близком рассмотрение практически бессмысленная задача оказалась по условию не предназначена для реализации на акторах и фактически принудительно заставляет использовать блокируемые потоки (Скорость чего мы тогда меряем?).
>Programs may use pre-emptive kernel threads or pre-emptive lightweight threads; but programs that use non pre-emptive threads (coroutines, cooperative threads) and any programs that use custom schedulers, will be listed as interesting alternative implementations. Briefly say what concurrency technique is used in the program header comment.
А жалко, хотелось показать преимущества неблокируемых потоков, но для этого нужна другая задача.
object Wakaba { def truba_shatal[NeTak](tipa: NeTak) = Console println (tipa toString) }
class Thread { def post[Tak](kak_to: Tak) = Wakaba truba_shatal kak_to }
object OP { new Thread post "bump" }
Полон тред пидорасов.
Почему так?
>>342679
Потому что вас тут только двое - ты и твой семен.
Не надо проецировать на остальных свои сексуальные фантазии.
ракуем, сегодня мы с тобой ракуем
эх, сажа отклеилась
>>342316
>А жалко, хотелось показать преимущества неблокируемых потоков
Ну так покажи хоть на чем-нибудь, а то пока мы только слышали голословные утверждения и не видели нистрочки кода.
>>342806
Нужна задача с вычислительной нагрузкой (типа распределенных (локально) вычислений) и межпотоковым взаимодействием. Возможно подойдет какая-нибудь задача на map/reduce (только такие задачи решаются слишком просто через параллельные коллекции, там за нас уже почти все уже написали). Самое главное - должно иметься эталонное решение ( можно на джава) с классической синхронизацией потоков и блокировками. Без него будет не с чем сравнивать. А сам я (месить говно) писать такое не собираюсь.
>>342845
Нужно конкретно сформулированное условие. Задача должна быть не слишком тяжелой, чтобы писалась за хотя бы пол дня. Ну и готовое решение с блокирующими(ся) потоками для сравнения.
trait test {
def number: Int
}
val n = new test { val number = 5}
>>342950
Охуенно полезный ответ, спасибо, теперь все стало понятно.
>>342952
что ты хотел увидеть? простой и логичный ответ? это не к жвм-опущенным.
>>342970
Это же трейт, его нельзя инстанцировать вроде как. Я, конечно, вижу, что тут не просто создание экземпляра класса, но нигде не нашел про этот синтаксис трейтов.
>>342945
Это простой override. Когда val перекрывает def 'это ключевое слово слово не требуется.
>>342971
Инстанциируется не сам трэйт, а анонимный класс, неявно описанный в точке, в которой он же инстанциируется. Класс наследует интерфейс трэйта (обязательное наличие метода/поля), но переопределяет его реализацию. Любой субкласс может переопределять любую родительскую реализацию, если только она не final.
>>342824
>Нужна
Ну так приведи пример такой задачи. Ты же собрался доказывать, что акторы - не очередной псевдонаучный высер вроде ООП, а что-то имеющее реальную практическую ценность.
>>342979
>кто-то должен доказать
Пойми же, тебе тут никто ничего не должен. Ты демагог дохуя, сидишь тут такой троллишь всех, собственные отсосы не замечаешь, сам ни одной строчки собственного кода не выложил. Теперь тебе кто-то должен что-то доказывать? А хуйца не соснешь, жирдяй?
>>342988
Т.е. вбросил и тут же слился? Типично для скалкошкольников.
http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/
Почему Мне НЕ нравится AKKA Акторы (4 марта 2013)
Мы недавно переписали бэкэнд в Майна. Архитектура резко изменилась, стала быстрее и легче расширяема. Одним из значительных архитектурных изменений было удаление всех акторов Акка. После значительного использования их в первой версии серверной части, я перешел к другим методам управления параллелизмом. Поскольку акторы Акка занимают столь видное место в рамках сообщества Scala, я думаю, что это [статья] может представлять интерес для объяснения причин, сделанных нами изменений.
http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/
1. Акторы - грубые абстракции.
Акторы представляются как универсальный примитив для параллелизма. В соответствии с ортодоксальным взглядом, они [акторы] - это все, что нужно для любой параллельной программы. Этот подход привлекает своей принципиальной простотой, тех, кто ищет убер-абстракцию. На подобие унификации примитивных и объектных типов Scala, или того, как в Python все значения представляются как изменяемые (mutable) словари, что как правило считается позитивными моментами в соответствующих языковых сообществах.
Проблемы возникают, когда в поисках простоты скрываются важные различия. В языках программирования это обычно сказывается на производительности. Различие между примитивными и объектами типов на самом деле имеют значение, если вы заботитесь о скорости [использования]. Скала решает это по большей части путем умной компиляции в обоих компилятором Scala и Hotspot, но в написании высоко-производительного кода все еще есть что-то вроде черной магии (dark art).
Параллельное программирование включает в себя по крайней мере три различных концепта: параллелизм (concurrency), взаимное исключение (mutual exclusion) и синхронизацию. С акторами первые два - всегда даются сразу, и вам остается реализовать только собственную синхронизацию с помощью пользовательских протоколов сообщений. Это - неприятное обстоятельство, если вы хотите сделать что-то простое, как разделение контроля параллелизма и взаимного исключения. Это не эзотерический требование - это именно то, что ConcurrentHashMap предоставляет, например. Если вы действительно ищете производительности, то вы, вероятно, хотите использовать неблокирующие алгоритмы. Опять же, это не вписывается в модель акторов. В основном модель акторов вынуждает нас отказаться от многих инструментов, чтобы мы могли вписываться в жесткие концепции ее параллельной программы.
http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/
2. Акторы не пригодны для композиции (compose).
Композиция является желательным свойством абстракции. Функциональная композиция. Если я пишу некоторые функции (например, плюс и минус) можно написать еще одну функцию (скажем умножение), которая использует эти функции. В частности, я не могу предвидеть наперед то, как вы будите использовать эти функции.
Акторы не пригодны для композиции. По умолчанию в актор жестко закодирован (hard-coded) приемник (receiver) сообщений, отправленных им. Если я создаю актор А, который отправляет сообщение актору B, и вы хотите изменить принимающий актор на C, то вам не повезло. Если вам повезет я ожидал это заранее и предусмотрел соответствующую настройку, но более вероятно, что вам придется переписывать исходник. Отсутствие возможности композиции затрудняет создание больших систем из мелких.
http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/
3. Акторы Aкка неудобно типизированы.
Акторы Aкка дают вам статическую типизацию в пределах одного актора, но коммуникация между акторами - сложная вещь, которая как раз и может пойти не так. Именно она не типизирована ни в какой полезной форме. Я мог бы пережить две вышеупомянутые проблемы, но эта (3) действительно напрягает меня (gets me).
Система типов является той причиной, по которой мы используем Scala. Типы позволяют нам гарантировать определенные свойства наших программ. Если вы никогда не использовали современный статически типизированный язык программирования вы можете быть удивлены тем, как далеко вы можете в этом [в статической типизации] продвинуться. Мы стараемся продвинуться как можно дальше в этом, именно поэтому мы можем гарантировать, что, например, наше Myna API генерирует полезные сообщения об ошибках (это важно , потому что API является интерфейсом для многих пользователей). Мы платим за эту могучую (awesome) силу некоторой дополнительной сложностью по сравнению с динамически типизированными языками.
Акка поддерживает ряд функций, таких как "become" и прозрачным распределение (transparent distribution), которые затрудняют статическое типизированные сообщений. У нас еще остаются наши неудобства по сравнению с динамически типизированными языками, при этом мы теряем преимущества статической типизации. Это неприемлемый компромисс для меня.
Другие языки, такие как Concurrent ML и Haskell, продемонстрировали возможность иметь абстракции отличного параллелизма и распределенного программирования (distributed programming) в статически типизированном языке. Я ожидаю то же самое в Scala.
>>343966
В брось перевод на хабр. Там у некоторых должно хорошо бомбануть.
>>343964
> Этот подход привлекает своей принципиальной простотой, тех, кто ищет убер-абстракцию
Соответствующие языковые сообщества как правило заняты разработкой гораздо более легковесного программного обеспечения, в котором, действительно, универсальные структуры данных имеют право на жизнь, а вот затраты на размышления о выборе между хеш-табличкой и бинарным деревом - не имеют.
>>344082
Ищешь таблетку от всех болезней - обратись в герблайф.
>гораздо более легковесного программного обеспечения
Для начала - определение "тяжести" ПО - в студию.
>универсальные структуры данных имеют право на жизнь
А где они не имеют такого права? И при чем тут структуры данных, когда речь о парадигмах параллелизма.
>выборе между хеш-табличкой и бинарным деревом - не имеет значения
У меня от этого АЛГОРИТМИЧЕСКАЯ СЛОЖНОСТЬ.
>>344160
Если уж мы о таблеточках, то ты хотя бы глицинчику выпил, перед тем как. А то чувствуется зимний авитаминоз.
> Для начала - определение "тяжести" ПО - в студию.
Зависит от следующего: 1) тиража 2) срока жизни, и следующей из этого, необходимости/отсутствия необходимости в его поддержке 3) Требованиями по производительности/гарантиям/допускам.
> А где они не имеют такого права? И при чем тут структуры данных, когда речь о парадигмах параллелизма.
Внимательно прочитай свои сообщения еще раз.
> У меня от этого
см. пик.
>>344175
>"тяжесть" ПО зависит от
>1) тиража
Выбрасываем на свалку все, чем пользуются больше, чем 3.5 анонимуса + обмазываемся НЕХ + ощущаем свою элитарность + прокачиваем ЧСВ + кушаем борщи + слушаем инди + обсираем попсу = ПРОФИТ (кому только?)
>2) срока жизни, и следующей из этого, необходимости/отсутствия необходимости в его поддержке
Легкого ПО = Коротко живущее (?)
>3) Требованиями по производительности/гарантиям/допускам.
Скорость/гарантии(качество)/приятная_цена - выбирай 2 из 3
Вообще не плохо бы с примеров каких-то начать.
У тебя к легким что относится? Эрланг А к тяжелым?
>>344505
> Выбрасываем на свалку все, чем пользуются больше, чем 3.5 анонимуса + обмазываемся НЕХ + ощущаем свою элитарность + прокачиваем ЧСВ + кушаем борщи + слушаем инди + обсираем попсу = ПРОФИТ
м?
> Легкого ПО = Коротко живущее (?)
м?
> Скорость/гарантии(качество)/приятная_цена - выбирай 2 из 3
м?
> Вообще не плохо бы с примеров каких-то начать.
Что ты собрался "начать"?
>>344539
>м?
>м?
>м?
Переведите кто-нибудь это мычание на человеческий язык.
>>344570
>Ко-ко-ко! Кукареку! Кудкудах!
Перевёл на язык, понятный тебе.
>>344572
>Ко-ко-ко! Кукареку! Кудкудах!
Одно быдло мычало, второе закукарекало.
/pr, /pr never change.
http://benchmarksgame.alioth.debian.org/u32q/which-programs-are-fastest.php
Кто тут у нас в первом столбце идет? Ба! Неужели?
>>346306
Сколько можно обсасывать этот парашаметр?
Забыли сколько неугодных бенчей байтоебанутый автор выбросил из рассмотрения?
Так что ничего кроме фантазий прыщебляди на этих картиночках вы не увидите.
>>346340
На самом деле, на этой картиночке действительно хуй-пойми-что, но посмотреть на конкретные ЯП-ЯП сравнения смысл есть.
>>346306
>Кто тут у нас в первом столбце идет?
Верхняя таблица для инвалидов, в нижней на первом месте сишечка, что ожидаемо.
>>346340
> неугодных бенчей байтоебанутый автор выбросил из рассмотрения
Подробнее.
>>346485
автор пидорнул одну лиспоблядь за попытку читерства, а на дваче это превратилось в "сколько неугодных бенчей"
>>346508
>за попытку читерства
А ты сам то читал условия этих задач. Там не считить намного ложнее, чем решить саму задачу. Например http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=chameneosredux#about тут требуется чтобы каждый "зверь" (простой объект с внутренним состоянием, асинхронно взаимодействующий с себе-подобными) жил в отдельном потоке ОС. Абсолютно идиотское требование, отсекающее самые красивые решения на неблокирующих очередях и убивающие смысл всего соревнования. Результат зависит на 90% от реализации планировщика задач ОС и на 10% от самого кода.
>>346683
>Абсолютно идиотское требование
Совершенно правильное требование
>самые красивые решения на неблокирующих очередях
Это все НЕНУЖНО
Быдломрази должны страдать потому что пишут не на Хаскель.
Стасик
>>346686
Быдломрази должны страдать потому что употребляют мое имя всуе.
Хаскель
>>346686
>НИНУЖНО
С каких пор ты начал писать это слово через Е?
>>346769
>Хуй соси, Стасик
http://www.lingvotech.com/znaki_prepinaniya_pri_obrashchenii
>3. Если обращение стоит в конце предложения, перед обращением ставится запятая, а после него — тот знак, который нужен по смыслу предложения.
Итак, господа. На данный момент есть четыре парадигмы для конкурентного программирования.
Shared memory with locking, STM, futures, message passing.
Какая же лучшая из них? Давайте по порядку, от самой олдовой, к самой современной.
SHARED MEMORY WITH LOCKING
Самая уебищная и популярная по сей день. GOTO нашего времени. Парадигма позволяющая прострелить себе ногу в любой позе даже хлопушкой, породившая миф, что конкурентное программирование это тааак сложна. В этой парадигме несколько процессов могут обрабатывать одновременно одни и те же ячейки памяти; чтобы добиться атомарности - нужны блокировки. Есть высокоуровневые решения типа семафоров, мониторов, мьютексов и они решают часть проблем, но они остаются.
1. Блокировки накладывают оверхед даже тогда, когда шанс коллизий очень мал.
2. Они вносят противоречивости в систему памяти.
3. Они дополнительно связывают все процессы.
4. Вылетевший процесс может оставить лок в закрытом состоянии.
5. Момент между тем как процесс получил доступ к памяти и тем как он завершает работу с ней - критическая секция, если в этот момент процесс что-то делает не так как задумано - пизда рулю.
6. Отлаживать системы на блокировках - ад.
Локи хорошо подходят для синхронизации 2-3 процессов, когда же их число растет - ситуация выходит из под контроля, и вскоре вы будете ебаться с целым комплексом дедлоков неделями напролет.
Такая форма синхронизации может быть оправдана для низкоуровневого программирования, в большинстве же случаев - нет.
SOFTWARE TRANSACTIONAL MEMORY (STM)
Первый нетрадиционный метод решения проблемы. Используется в Haskell и Clojure. Такой подход больше напоминает работу с памятью, как с базой данный на транзакциях. Такая реализация как бы избегает блокировок работая на оптимистичный манер: последовательность чтения и записи рассматриваются как одна операция, и если два процесса пытаются получить доступ к общему региону в одно время, каждый в своей собственной транзакции, только один из выполнит операцию, остальные процессы сфейлятся и должны будут ретраиться.
Главный проеб, собственно, - необходимость ретраить транзакцию (и конечно они могут фейлиться много раз подряд).
Понятно, что все это накладывает нихуевый оверхед, но к тому же, теперь системе нужна дополнительная память, где она будет хранить хуиту, которую нужно записать, пока решается кто именно будет писать. Необходима поддержка STM на уровне железа, как поддержка виртуальной памяти.
STM, конечно, намного лучше предыдущего варианта, и он в общем-то хорош, до тех пор, пока транзакции не ретраятся слишком часто.
В любом случае это те же блокировки, только на более изящный манер, и это не решение, а только обезболивающее. Нужно двигаться дальше.
FUTURES/PROMISES
Ещё один модный концепт с несколькими вариантами. Есть в E, MultiLisp, есть жабалиба. Похожее на I-vars и M-vars в Id и Glasgow Haskell, те же конкурентные логические переменные из конкурентного пролога и датафлоу переменные в Oz.
Основная идея, что future - результат вычисления, которое было поручено другому процессу. Future может передаваться как полноценный объект, если кто-то хочет прочитать из него значение, а оно ещё не вычислено, - будет ждать.
И хотя это все выглядит концептуально просто, и позволяет легко передавать данные в конкурентных системах, подобный подход делает программу хрупкой в случае падения процесса или сети между ними: код который пытается получить доступ к promise, может не подозревать, что данных все ещё нет, а соединение сдохло.
Удобно, но ненадежно.
MESSAGE PASSING
Это значит, что процесс получает отдельную копию данных и закрывает их у себя. Ни процесс отправитель, никто другой с этими данными не работает и не может наблюдать за их изменением. Единственный способ ответить отправителю, послать ему новое сообщение. Так же важно, что посылка сообщения возможна независимо от того, находится ли процесс получатель в этом же инстансе или вообще на другой машине. Много много блэкбосков обмениваются сообщениями и не разделяют данных. Полная изоляция. Посылка сообщений может быть двух видов, синхронная и асинхронная. Синхронная, когда отправитель не может ничего делать, пока не получит ответ, в случае же с асинхронностью он переходит к следующему действию незамедлительно. Язык, который реализовал такую модель в полной мере - Erlang. Правда, в нем все message-примитивы асинхронные, потому как очень легко реализовать синхронную форму, когда надо, просто заставив получателя моментально отвечать отправителю то, что тот ждет. В основном же, отправителю просто похуй, что будет дальше, ведь не известно, что будет делать получатель, может он умрет нахуй через долю секунды, send-and-pray.
Конечно при таком подходе с постоянным копированием, тоже оверхед, но он заметен лишь у криворуких пхпшников/рубистов/js-овцев, пришедших на зов хайпа. В идиоматическом эрланге копируются очень маленькие объемы (<100 байт на сообщение), и как известно, современные машины делают это очень быстро.
Как насчет больших объемов? В Erlang бинари >64K идут в отдельную кучу и передается только указатель на этот бинарник. Бинарники не могут содержать указатели и более того, они тоже иммутабельны. Так как нет указателей, можно не париться, что бинарник указывает на какие-то там данные, он всегда leaf node. Это и иммутабельность позволяет VM переиспользовать один и тот же бинарник в множественных процессах. Более того, это позволяет VM выделять sub-binary ссылающиеся на один кусок. Выполняя binary:split/3,
чтобы порезать бинарник на куски, получаешь только sub-binary ссылки на оригинальный бинарник. Другие языки обеспечивают примерно подобные примитивы. Срезы в golang действует подобным образом, но они позволяют менять содержание. В Erlang такая хуйня не пройдет, так как ВСЕ иммутабельно. Слайсы в SML куда более похожи на эрланговские sub-binary. Это позволяет переиспользовать read-only память.
Короче message passing это наше все.
>>346966
С смого начала поста было такое ощущение, что автор - телепетушок. Так и вышло.
>>346966
Ну вот и дождались, адекватный Программист заглянул ИТТ (а то надоело уже гонять ссаными тряпками всяких стасиков) В целом вполне хардкорное пояснение. Ну под конец не смог удержаться от пиара своего ершланга, в результате перепутал две верхние ступеньки пирамиды. Акторы, конечно, ссут сверху вниз на все прочие concurrent поделия (на счет stm - спорно; оно как бы для другого применения в основном, но если использовать его как панацею от всего, то выйдет решение не намного лучше классических блокировок). Только ты совсем упустил, что
futures/promises - это такой проапгрэйженный вариант акторов, в котором пофисины все их хронические болезни и запилена ключевая фитча - композиция. И так сравним:
Любой небыдлокодер понимает, что возврат значения (или void) из функции должен осуществляться в одной точке. Любые варианты break - тот же goto по сути, запутывание потока данных, запутывание логики, ерись, гроб, гроб, кладбище. Поэтому все современные ЯВУ принуждают функции возвращать ровно одно значения заданного типа (пусть даже void), а не выходить во множестве точек с любыми значениями (быдлокодеры конечно и тут придумали себе break и return). Аналогом функций из однопоточного мира, в многопоточном мире является асинхронный блок (future или актор). Теперь видно, что future - прямой аналог функции с одной точкой входа и одной точкой выхода. Актор похож на кусок ассемблерного кода, который не имеет точки выхода, а совершает прямые прыжки в другие куски кода, все адреса переходов жестко закодированы и не могут быть выяснены/изменены снаружи функции этого куска, предсказать куда перейдет управление после выполнения этого куска не возможно. Получаем старую знакомую goto-парашу, абсолютно не_функциональный подход, в этом вся суть акторов, выходит они и есть "GOTO нашего времени". В противовес им, future - истинная функция, объект первого класса (эта мелочь решает все, для тех, кто в теме), на этом основаны все их свойства, включая композицию (См. >>343965), которая дает магическую силу ФП.
>>347105
Ты не понимаешь суть акторов.
Их суть не только посылка сообщений, но и самое главное - изоляция. Актор живет в своем черном ящике, со своим клочком данных и все что он умеет, обрабатывать только этот кусочек данных и посылать сообщения.
Почему тот же erlang не чисто функциональный? Это не потому что авторам похуй, они не рассматривали такой вариант или не осилили. Те же Joe и SPJ часто общаются, пересматривают различные варианты и идеи. Эрлангу не нужна чистота, потому что каждый процесс сам по себе чист. Единственный побочный эффект - сообщения, все. Это чистая модель акторов.
По композабельности, в OTP есть готовые механизмы заключения акторов в иерархии и установления цепочек связей между ними. Так же есть способы обернуть посылку/примем сообщения в функцию.
Но главное, - отправитель чаще всего ничего не ждет в ответ, гарантии чего либо не нужны. Как он может знать, что там будет дальше, получатель то, - черный ящик, у них с ним ничего общего. В этом и проблема promise/future, они слишком друг на друга рассчитывают, слишком связаны и трабл описанный мной выше до сих пор не решен, тогда как в эрланге, как-то похуй что какой-то там процесс где-то проебался и что-то не доделал.
>>347138
Дополню себя.
Актор не является функцией и не должен ей быть. Актор ничего не возвращает, у него нет return etc. Это бредовое мышление. Именно люди с таким мышлением проебали замечательную смолтолковую идею, заменив message passing на вызов метода в погоне за желанием специфицировать объекты.
Единственный способ воздействия на актора - посылка сообщения и все, это совершенно не тоже самое что вызов функции. Актор пославший сообщение никак не может отслеживать его состояние, прохождение и так далее, для актора вообще нихуя не существует, кроме его черной коробки. Получение ответа,- другое сообщение, совершенно новое событие. Именно такая схема позволяет строить системы, где смерть одного нейрона не приводит к парализации всего мозга.
>>346966
Несмотря на пафосный пердеж по параллельность и конкурентность, эрланг где-то в 6 раз медленней джавы на многоядерных процессорах http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=hipe&lang2=java&data=u64q
>>347337
>benchmarksgame
Дальше не читал. За любую ссылку на эту хуйню надо бить с разбега в ебальник.
>>347341
Лол, типичный религиозный фанатик - живёт в воображаемом мирке, отрицает неугодные его религии факты, зашорен, агрессивен.
>>347360
Привел ссылку на сомнительный ресурс, был по-делом обоссан, что-то продолжает кудахтать в ответ. Вся суть явадебилов.
Вот тебе тоже бенчмарк, раз ты так на них дрочишь.
http://eric.themoritzfamily.com/websocket-demo-results-v2.html
Можно ещё наковырять в сети как openfire всасывает у ejabberd, а Cassandra и HBase у Couchdb и Riak, да только хули на тебя дебила время тратить.
>>347360
В догонку поясни, почему кресто-яваблядксий AMQP QPID так всасывает на средних и крупных сообщениях у RabbitMQ?
http://x-aeon.com/wp/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
>>347369
>Привел ссылку на сомнительный ресурс
Сомнителен о тем, что там эрланг всасывает? Я же говорю, что религиозным фанатикам и прочим креационистам свойственно отрицать неугодные им факты.
>Вот тебе тоже бенчмарк, раз ты так на них дрочишь.
И что показывает этот бенчмарк, что именно там сравнивается?
>В догонку поясни, почему кресто-яваблядксий AMQP QPID так всасывает на средних и крупных сообщениях у RabbitMQ?
Перед тем как копаться в дебрях AMQP QPID и всего того, что там намерил у себя в блоге неизвестный товарищь, давай разберёмся, почему таки Эрлан соснул в минимум в 6 раз на всех задачах публичного бенчмарка? Заметь, я ведь не говрю, что AMQP быстрее, чем RabbitMQ, я просто говрю, что Эрланг в 6 раз медленней джавы, и никто с этим ничего сделать не может.
>>347410
>публичного бенчмарка
Где я могу посмотреть исходники кода участвующего в сравнениях?
Ява-хуява на шутауте с отключенным GC всегда такая охуенная, только вот в продакшне - тормозное говно, потому что JVM - параша.
Сравнивать ЯП по синтетическим бенчмаркам, это же вообще пиздец.
Во-вторых, чтобы код работал параллельно и конкуретно, он должен быть так написан, в том бэнче вангую однотредовый эрланговский код, ещё и запущенный с smp.
На однотредовых приложениях, говно вопрос, эрланг медленнее jvm, в условиях же агрессивной многопоточности jvm уже на 1000 тредах смотрит в сторону свопа, а на 10000 зарывается от прохода GC. Если добавить сюда задачи распределенности, то яваговно неспособно линейно отмасштабироваться даже на два узла.
>>347417
Более того, R1304, это 2010 год, если не ошибаюсь, ERTS и сама VM с тех пор столько изменений претерпели; все старее R15 вообще рассматривать сейчас глупо.
Прочитал тред, в треде заметил петушков для которых конкурентность = параллельность, в эрланге джо именно так и пояснял, конечно же это не верно.
>>347425
>>347421
Весь фокус в подмене понятия "тред". Давай назовем "тредами" ForkJoinTask (которые, между прочим, лежат под капотом у Акка), напишем синтетический тест измеряющий скорость их порождения/завершения (в качестве полезной нагрузки - пустая заглушка). Бедный эрланг уползет под стол при виде таких бэнчей. Остается только один вопрос - каков физический смысл таких "тредов" и что мы на в действительности только что измерили?
>>347486
Тред в эрланге - гринтред внутри VM, но со своим стеком и своим хипом и приоритетом. Скедулер организует их вытеснение внутри каждой VM, а ERTS их миграцию между VM.
Создается ~3 мкс, весит на начальной стадии 500 байт.
Теперь давай расскажи, есть ли подобное в JVM, где все говно лежит в одном хипе, а объекты внутри инстанса передаются только по ссылке.
Акка - inspired by Erlang костыль для уебищной JVM.
>>347496
Хипсторы - удивительные люди. Если ты не в курсе, зеленые потоки в жабе впервые и появились. Только делались они исключительно чтобы потоки работали на платформах, которые не поддерживают нативные. А потом пришли всякие эрлангобляди и гобляди, усмотрели в этом великую конспирацию ("не могли они сделать зеленые потоки для совместимости! наверное, они быстрее!") и стали выдавать костыль как килер-фичу. Поразительно. Хотя особенно смешно, когда эти же люди кукарекают про GIL в гвидоне, как будто их парашные недопотоки ОС по ядрам может раскидать.
>>347593
>> треды внутри VM
> недопотоки ОС
>> вытесняющая многозадачность
> кооперативная питонохуйня.
Ясно, ты ибецил.
>>347601
Для тупых эрлангоблядей, не знающих русский язык, разбил вторую часть последнего предложения на словосочетания.
их недопотоки
недопотоки парашные
ос может раскидать
раскидать по ядрам
раскидать недопотоки
>кооперативная питонохуйня
Эрлангоблядь блистает своими знаниями видов многозадачности. Покажи мне в гвидоне функции для управления гилом, ущербный.
>>347606
>раскидать по ядрам
>ос
На каждом ядре по VM, и ERTS организует распределение и миграцию тредов между ними. На каждом ядре скедулер организует равномерное распределение выделенного процессорного времени между тредами.
Иди лучше уроки делай, долбоеб обсосанный.
Скрипя сердцем, обсосал я долбоёба.
>>347593
>ОС
>по ядрам может раскидать
Для ОС эрланговские треды и не существуют, блять, что она будет раскидывать, ебан штоле?
Треды живут только внутри инста. Как процесс ОС висят только процессы VM'ов, и их по одному на ядро.
>>347496
>Скедулер организует их вытеснение внутри каждой VM, а ERTS их миграцию между VM.
Это пиздец просто. Ты понимаешь, насколько твоя программная многозадачность медленнее аппаратной?
Я, хоть и адепт максимальной абстрактности, но это уже через край.
Эрланговкие лёгкие и быстрые потоки наверняка медленнее родных системных.
>>347669
>наверняка
Петухан диванович экспертов во всей красе.
Переключение контекста, юзермод, кернелмод - ВЕДЬ ВСЕ ЭТО ЗНАТЬ НИНУЖНО ВСЕ ЭТО НИВАЖНО.
Стасики, стасики never change.
>>347138
>каждый процесс сам по себе чист. Единственный побочный эффект - сообщения
/0
>По композабельности, в OTP есть готовые механизмы заключения акторов в иерархии и установления цепочек связей между ними. Так же есть способы обернуть посылку/примем сообщения в функцию.
В этом случае актор принуждаестя к возврату сообщения отправителю?
Да = Та же модель futures/promises, те же яйца, вид сбоку.
Нет = Что происходит с отправителем, которому не ответили? Он зависает? Зачем тогда вообще нужны такие "функции"?
>Но главное, - отправитель чаще всего ничего не ждет в ответ, гарантии чего либо не нужны.
Как что-то хорошее.
>В этом и проблема promise/future, они слишком друг на друга рассчитывают
Так и должно быть, они же части одного алгоритма (или элементы одной бизнес логики). Проверка в рантайме многих (все проверить не возможно) нештатных ситуаций - лишний код + возможность упустить какой-то вариант, сложность локализации ошибок, большой оверхер рантайма. Короче - все "прелести" динамических языков (См. >>343966). В статически-строго-типизированных языках все проверки выполняет компилятор, все что может произойти в рантайме должно быть учтено в коде, иначе код просто не скомпилируется.
>>347138
>описанный мной выше до сих пор не решен, тогда как в эрланге, как-то похуй что какой-то там процесс где-то проебался и что-то не доделал.
Что в сущности может произойти с функцией (читай future)? Тут только три варианта: 1)возврат значения; 2)выброс исключения; 3)зависание. Для future (не будем говорить об (1)), не пойманные исключения (в норме все они должны ловиться) вылезут в точке future.get, это и есть ожидаемое поведение. Если актор упадет из-за исключения, то следующие за ним блоки алгоритма так и останутся висеть в ожидании сообщения, которое уже никогда не придет, попробуй отлови и отладь такой баг в достаточно сложной системе. Остается вариант (3) зависание функции/актора - это тот случай, когда не поможет ничего кроме ручной отладки. На какие бы хитрости не пошла виртуальная машина, она не сможет разрулить эту ситуацию в полностью автоматическом режиме без того, чтобы кодер предусмотрел эту конкретную ситуацию заранее. Причина проста - (фундаментальное свойство машины Тьюритга) Не существует способа выяснить завершится ли данная программа за конечное время (т.е. "подвисла" или нет). Если задумается над этим, то становится понятно, что никакие таймауты и автоматические перезапуски не могут решить эту проблему без участия человека.
>>347674
>В этом случае актор принуждаестя к возврату сообщения отправителю?
Есть обертка посылки/приема сообщения в обычную функцию, это синхронный вызов, и актор отправитель замораживается до получения ответа. Асинхронная же обертка, - просто сахар, плюс можно написать спеку для анализатора типов, чтоб удостоверься, что актор посылает то, что должен. Тащемта, синхронные вызовы считаются моветоном, так как, ещё раз, посылка сообщения =/= вызов функции, и идея сделать из первого второе, - выход за рамки тру модели акторов, где все действия однонаправлены, посылка ответа, это новое сообщение, новое событие.
Но в 3% случаев такое может понадобиться, поэтому в стандартной поставке есть.
>все проверки выполняет компилятор
Это конечно круто, я согласен. Но есть так же такие вещи как: выключение света, падение бокса в датацентре, внезапные разрывы связи вследствие кривости сети/железа/ОС/драйверов, свитер в панике перезагрузил что-то, какая-то хуйня забрала управление портом, короче житейские быдлопроблемы.
А ещё есть логические ошибки программиста и проебы архитектуры.
>выброс исключения
Иксепшены в эрланге хоть и есть, причем в довольно красивой форме, с патерн матчингом и всякими свистоперделками, defendency programming - считается жутко дурным тоном, и первое чему учат вчерашнего жаваиндуса, перестать кодить так, как будто ты не доверяешь тому что пишешь. Это тоже избавляет от лишнего кода.
Вылет процесса на каждый чих, на любой бэдматч - вполне в духе эрланга, ты пишешь только так, как оно должно работать, без учета вариантов того, что может там ещё случиться.
Это просто другой путь: иммутабельность + изоляция + ссылочная прозрачность + мониторы чекающие смерть актора + прилинковки, позволяющие по смерти актора захуярить целую цепочку других акторов + супервизоры рестартящие процесс + построение деревьев из них - все это дает возможность не волноваться об ошибках. Потом лениво почитывая лог можешь понять что, ага вот тут трабл. Более того, та же изоляция актора позволяет очень легко отлаживать ошибку. Это конечно не так изящно, как мощная система типов с тайп чекером, где ты увлеченно доказываешь себе и компилятору, что ты все сделал правильно. Но это тоже работает и это спасает не только от ошибок типов, но и от многих других.
>/0
Но ведь серьезно. Где может быть проблема сайдэфектов? В изменении глобального стейта, например. Но актор не видит внешней памяти, все что он может - менять свой изолированный от всего мира, доступный только ему стэйт и посылать сообщения. По получению сообщения, если оно матчится, другой актор так же меняет свой изолированный стэйт. Только он это может сделать, нет никаких внешних воздействий на его состояние. Итого, если каждый актор по конкретным сообщениям меняет свой стэйт корректно, то вся программа работает корректно.
Тут среди нас сидит один хабрапидор и анальный раб Тайпсэйфа, который дрочит на реактивное программирование и молиться на Акку. Он уперт, религиозен, фанатичен, не имеет собственного мнения и только повторяет заученную пропаганду Тайпсэйфа. А сейчас мы посмотрим, как этот педрила будет отмазываться, когда его ткнут ебалом в такой факт, что без типизации сообщений вся эта Акка - просто одна большая динамическая параша. Жалкие отмазки аффтора http://stackoverflow.com/questions/5547947/why-are-messages-to-akka-actors-untyped - какой-то лепет младенца. Не было ни одной серьезной причины убивать статическую типизацию. Вместо этого они наворотили типизированные акторы, уродливую надстройка поверх типизированных. По сути это убогий костыль, сам аффтор признает это и называет их "bridging between actor systems and non-actor code" а еще "sort of RPC". Еще типизированные акторы строятся в рантайме через JDK Proxies и потому адово тормозят (котыль же хуле). Акка от корней - петушиная динамическая система (получение акторов в рантайме по имени(!) + отправка любых сообщений без контроля типов). Самое хуевое, что они измазали своим динамическим говном стандартную библиотеку в 2.10, убили старую (относительно годную) реализацию акторов из 2.8, убили винрарную реализацию promise/future на fork-join, заменили ее своей петушиной реализацией поверх динамических (блядь!) акторов. Короче, зашкварили и опустили весь язык. Гореть вам за это в аду, пидарасы ебаные!1111