Сохранен F 281
https://2ch.hk/pr/res/340248.html
Был обновлён парсер тредов Двача, просим анонов обращать внимание и сообщать об аномалиях с содержанием сохраняемых тредов.
Аноним Чтв 05 Дек 2013 23:20:26  #1 №340248 

Тут среди нас сидит один хабрапидор и анальный раб Тайпсэйфа, который дрочит на реактивное программирование и молиться на Акку. Он уперт, религиозен, фанатичен, не имеет собственного мнения и только повторяет заученную пропаганду Тайпсэйфа. А сейчас мы посмотрим, как этот педрила будет отмазываться, когда его ткнут ебалом в такой факт, что без типизации сообщений вся эта Акка - просто одна большая динамическая параша. Жалкие отмазки аффтора 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

Loading...
Аноним Чтв 05 Дек 2013 23:31:17  #2 №340254 

Что почитать по типизации сообщений?

Аноним Чтв 05 Дек 2013 23:38:11  #3 №340256 

>>340248
> http://stackoverflow.com/questions/5547947/why-are-messages-to-akka-actors-untyped
>asked Apr 5 '11
яснопонятно

дальше твой высер не читал.



Аноним Чтв 05 Дек 2013 23:45:07  #4 №340259 

>>340256
А что изменилось с тех пор? То что мало кому известный (тогда) проект стал частью стандартной библиотеки? И только? Положительных изменений в плане архитектуры нет и теперь уже не будет.

sageАноним Чтв 05 Дек 2013 23:45:14  #5 №340260 

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

Аноним Чтв 05 Дек 2013 23:52:10  #6 №340264 

>>340254
Есть же много реализаций акторов на Скала, большинство поддерживает типизацию естественным образом. Но так называемые "typed-actors" в Акка - это жуткие костыли. См. - http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.html


Аноним Чтв 05 Дек 2013 23:57:49  #7 №340265 

>>340259
Можно исользовать тайпед чэнел' но там тоже есть проблемы.

Остальные твои претензии глупы.

Аноним Чтв 05 Дек 2013 23:58:01  #8 №340266 

>>340260
>в моем динамически типизированном интернете
Завязывал бы ты с травой в своем гипертекстовом фидонете.

Аноним Птн 06 Дек 2013 00:01:39  #9 №340267 

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

Аноним Птн 06 Дек 2013 00:03:05  #10 №340269 

>>340267
Ммм, ты пришел пояснить за статическое говно или просто так кукарекаешь от скуки?

Аноним Птн 06 Дек 2013 00:06:33  #11 №340271 

http://stackoverflow.com/a/5997668/1203558

Аноним Птн 06 Дек 2013 00:14:16  #12 №340275 

>>340269
>статическое говно
WOT?
>ты пришел пояснить
Если тебе приятнее долбиться в сраку с динамическим любрикантом, то мне нечего тебе пояснять.

Аноним Птн 06 Дек 2013 00:18:55  #13 №340276 


>>340275
Не думаю что ты смог пояснить' за все твои посты я не услышал ни слова, о том почему динамическая типизация плохо. Но перед этим дай определение дин. Тип. И найди те признаки в акке.

Аноним Птн 06 Дек 2013 00:27:54  #14 №340281 

>>340271
Очень хорошее сравнение.
Остается вопрос: Почему они засунули в стандартную библиотеку 2.10 самое днище?
>Akka Actors: Actor[Any]

Аноним Птн 06 Дек 2013 00:48:12  #15 №340292 

>>340276
Актор (как Promise[T] ) должен быть параметризован типом сообщений, которые он принимает. Это же очевидное решение. Разные сообщения могут наследовать один trait, который указывает на принадлежность сообщения к актору. Если сообщение - внешний класс, то его можно заворачивать в Either. В крайнем случае можно сделать Actor[Any]. Но в Акка же выбрали самый уебанский вариант в стиле бэйсика, короче слепили все как проще: "Нахуя нам параметризация, если и без нее все работает?" Если бы так же рассуждали авторы самой скалы, то у них бы вышел бы какой-то groovy.

Аноним Птн 06 Дек 2013 01:10:14  #16 №340296 

Скаланы, поясните, где лучше всего использовать скалу? Например, написать масштабируем сервер мморпг - подходящая задача или лучше подыскать что-нибудь другое из языков?

Аноним Птн 06 Дек 2013 02:04:54  #17 №340316 

Посоны, вам не кажется, что скала и джава это как с++ и с? Там и там наворотили прибамбасов, что черт ногу сломит и что со всем этим делать - не ясно.

ниасилятор

Аноним Птн 06 Дек 2013 03:03:57  #18 №340322 

>>340296
>Скаланы, поясните, где лучше всего использовать скалу?
Почти везде, где используют джаву + кое-где, где джава сосет: т.е. почти все от андроида до серверов и кластеров.
>Например, написать масштабируем сервер мморпг
>мморпг
В геймдеве я плохо разбираюсь, но вот
>масштабируемый
Так скала рождена для для этого.

Аноним Птн 06 Дек 2013 03:19:46  #19 №340323 

>>340316
Скала изначально разрабатывалась не как Джава 2.0 с блэкджэком и шлюхами. А как реализация идей ФП на платформе JVM. Чистого функционального языка не получилось. Дальше уже совместимость с джава продиктована необходимостью использовать рантайм от jvm.
>что со всем этим делать - не ясно
Тебя притягивает красота и лаконичность самого языка? Если нет, значит это просто не твое, возвращайся на родную жабу или попробуй еще раз через пару лет (когда тебя реально стошнит от жабы).

P.S. Кстати С и С++ так похожи только с виду из далека.

Аноним Птн 06 Дек 2013 08:36:00  #20 №340335 

>>340292
>>340292
Напиши что ты хочешь сделать на скале

Аноним Птн 06 Дек 2013 08:37:12  #21 №340336 

>>340296
Уебывай на свой лор припиженый

Аноним Птн 06 Дек 2013 10:34:32  #22 №340345 

>>340323
Ты меня совсем не понял.
>С и С++ так похожи только с виду из далека
>Скала изначально разрабатывалась не как Джава
именно об этом я и говорю.
>Тебя притягивает красота и лаконичность самого языка?
Единственный язык, подходящий под это определение - Лисп.Меня же отталкивает невероятное количество свистелок и перделок что в С++ что в Скала.

Аноним Птн 06 Дек 2013 10:56:43  #23 №340347 

На С нельзя писать то, что пишут на С++. Первый подходит только для программирования сливных бачков, в то время как на втором пишут сложные и, одновременно с этим, очень требовательные системы: графические/физические движочки, операционные системы, рантаймы языков программирования, и так далее. Понятно, что не у нас, и не нашего ума это дело - нам, в лучшем случае, сливные бачки доверят. Вот с Java и Scala ситуация похожая, но оные находятся в альтернативной вселенной софта - где веб и корпоративное говно, и где вместо примитивных и сложных систем бывают сложные и очень сложные, а требования (к эффективности) гораздо ниже.

Аноним Птн 06 Дек 2013 11:00:53  #24 №340348 

>>340347
>Первый подходит только для программирования сливных бачков
Апач
Все операционки
Квейки

Аноним Птн 06 Дек 2013 11:07:51  #25 №340351 

>>340348
Это не значит, что С для этого подходит. Вот если ты с нуля напишешь на С, с нуля напишешь на С++, при этом используя на полную катушку возможности каждого языка, и сравнишь - и вдруг окажется что на ассемблере не гораздо хуже - тогда да. Но этого никто до сих пор не делал.

sageАноним Птн 06 Дек 2013 11:17:35  #26 №340352 

>>340347
> сложные системы
> С++
Вадим, может хватит?

Аноним Птн 06 Дек 2013 11:28:05  #27 №340354 

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

Аноним Птн 06 Дек 2013 11:32:35  #28 №340356 

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

sageАноним Птн 06 Дек 2013 11:36:50  #29 №340358 

>>340248
Поясняю:
1. Данные идущие по проводам нетипизрованы по своей сути. Все попытки натянуть на них типы приводят к фейлам, т.к. привязывают систему к конкретному языку и технологиям, усложняют любые изменения и рост системы. CORBA, DCOM, Java RMI - это кошмары 90х, забытые как страшный сон и заменённые на protobuf, thrift, avro, json и т.д.
2. Одна из "киллер-фич" акторов - одинаковая семантика для внутрипроцессного, межпроцессного и даже сетевого взаимодействия, т. е. отправка сообщений.
Из 1 и 2 следует, что если не хочешь стрелять себе в ногу, нужно делать сообщения динамически типизоравнными.
Также, после этого становится очевидным, насколько глупым является пункт 2 - для сохранения иллюзии одинаковой семантики мы делаем взаимодейсвия внутри процесса жутко неудобным: нет статической проверки типов, любой локальный запрос памяти мы вынуждены делать как отправку сообщения и приём ответа, даже если данные иммутабельны.

Аноним Птн 06 Дек 2013 11:44:23  #30 №340361 

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

Аноним Птн 06 Дек 2013 11:53:35  #31 №340362 

>>340361
Что плохого во втором типе. Иногда проще выбросить говно, чем копаться в нём.
тред не читал

Аноним Птн 06 Дек 2013 11:55:36  #32 №340363 

>>340292
А если нужно в рантайме сменить тип сообщений принимаемый актором?

Аноним Птн 06 Дек 2013 11:56:41  #33 №340364 

>>340348
>Апач
Говно же.

Аноним Птн 06 Дек 2013 11:57:57  #34 №340365 

>>340363
>принимаемых

fix

Аноним Птн 06 Дек 2013 11:58:31  #35 №340366 

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

Аноним Птн 06 Дек 2013 11:59:35  #36 №340367 

>>340361
Второй тип - суровые практики. Если что-то требует слишком много времени для изучения и нет оснований считать, что оно принесет какой-то профит - ну его нахуй.

Аноним Птн 06 Дек 2013 12:06:45  #37 №340368 

Правильные выводы из критики Scala таковы:
- если вы хотите разобраться в таких вещах просто из интереса, лучше уж выбирайте хаскель в качестве игрушки на досуге
- если хотите писать промышленно на чём-то лучше, чем остальное, и не являетесь джавистом - на Scala вам писать не удастся, а раз так, см. пункт 1
- если хотите писать промышленно на чём-то лучше, чем остальное, и являетесь джавистом, тогда Scala - ваш выбор

Аноним Птн 06 Дек 2013 12:20:41  #38 №340371 

>>340368
двочую

sageАноним Птн 06 Дек 2013 12:25:27  #39 №340372 

>>340371
семенчует он

Аноним Птн 06 Дек 2013 13:04:15  #40 №340377 

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

sageАноним Птн 06 Дек 2013 13:10:58  #41 №340381 

>>340377
> тайпкастами
Не пиши так больше, а то дети с тайпклассами перепутают.

sageАноним Птн 06 Дек 2013 14:38:18  #42 №340399 

>>340366
умри, сука
будь добрее, сука
не оскорбляй людей, сука

Аноним Птн 06 Дек 2013 14:51:19  #43 №340406 

>>340372
а вот и нет, чини детектор.

Аноним Птн 06 Дек 2013 15:41:38  #44 №340421 

>>340336
Чего, какой лор?

Аноним Птн 06 Дек 2013 15:53:48  #45 №340425 

>>340399
Ладно.

Аноним Птн 06 Дек 2013 18:04:22  #46 №340444 

>>340377
>тайпкастами как нормой жизни
Тайпкасты - не хуя не норма для скалы.
>такими-то нулами
Имеешь в виду Nothing ? Отчасти ты прав, это издержки jvm. Но все таки он не так опасен, как null в джаве (за счет того, что представляет собой отдельный тип).
>признать одной большой динамической парашей языки с сабтайпингом
>сабтайпинг
>динамическая параша
ВУУУУТ??? А ну-ка быстро пояснил за базар!11

Аноним Птн 06 Дек 2013 18:06:12  #47 №340445 

>>340368
>если хотите писать промышленно на чём-то лучше, чем остальное, и не являетесь джавистом - на Scala вам писать не удастся
Обоснуй.

Аноним Птн 06 Дек 2013 18:32:00  #48 №340458 

>>340361
Согласен с тобой в целом. Есть неасиляторы, которые критикуют Акку потому, что просто не могут в красоту акторов. Я же знаком с пятью разными реализациями акторов. Раньше использовал акторы из 2.9 в одном своем проекте, нарекания к ним есть, но такого отвращения они не вызывают. Еще раньше на джаве писал свой аналогичный велосипед (я тогда даже слова "актор" еще не знал). Короче мне есть с чем сравнивать и я ответственно заявляю, что реализация Акка - самая конченая из всех широко распространенных (я не считаю всякие малоизвестные). Поэтому я так жидко обосрался когда узнал, что именно это говно они влепили в стандартную библиотеку в 2.10, да еще винрарный Promise/Future на нее перетащили.

Аноним Птн 06 Дек 2013 18:48:38  #49 №340459 

глядите, раки:
http://ru-scala.livejournal.com/47591.html#

Аноним Птн 06 Дек 2013 18:55:08  #50 №340462 

>>340358
>1. Данные идущие по проводам ... CORBA, DCOM, Java RMI ... protobuf, thrift, avro, json и т.д.
Причем тут все это? Речь идет о конкретном языке, о конкретной технологии (акторы) и о выборе годной ее реализации.
>2. Одна из "киллер-фич" акторов - одинаковая семантика для внутрипроцессного, межпроцессного и даже сетевого взаимодействия, т. е. отправка сообщений.
Акроты изначально - это просто технология параллелизма (наряду с promise/future и др.) без синхронизации, блокировок и ожиданий, разрабатывалась как средство от кошмара java concurrency. До сих пор используется на 95% в этом качестве. Все остальные фичи, как отказоустойчивость, сетевая транспарентность и др. - просто плюшки, которые выдаются бесплатно в одних реализациях и требуют дополнительных телодвижений в других. Тем более физическое расположение sender и destination в разных процессах/машинах никак не мешает статической проверке типов при компиляции.
>если не хочешь стрелять себе в ногу, нужно делать сообщения динамически типизоравнными.
Ну бред же полный. Динамическая типизация как раз дает возможность прострелить ногу.

Аноним Птн 06 Дек 2013 19:03:39  #51 №340464 

>>340445
Дело в том, что Scala используют только в компаниях, где всё давно на JVM, и все вакансии, что мне встречались ранее, предполагали, что соискатель - как минимум Senior Java. Вот это - >>340459 - первое исключение, которое мне встретилось. Хотя раньше я в рашке не смотрел, может у вас там нередко такое бывает.

Аноним Птн 06 Дек 2013 19:04:55  #52 №340466 

>>340458
А где акторы лучше?

Аноним Птн 06 Дек 2013 19:05:22  #53 №340467 

>>340335
Я в работе акторы постоянно использую. В основном, Reactor[T] из 2.9 (не блеск, конечно, сыроватые какие-то, то с типизацией проблем нет). Вот когда они стали deprecated в 2.10, а вместо них всунули это днище, тут мой анус реально воспламенился.

Аноним Птн 06 Дек 2013 19:21:49  #54 №340468 

>>340466
По юзабильности: Scala Actors из 2.9 - вполне годные.
По красоте: Scalaz Actors - вне конкуренции. Иммутабильность + лаконичность. Сама концепция у них мощная: "актор - это просто функция" (параллельное выполнение не отменяется). Но на практике я ими почти не пользовался, так как Scalaz - жирная либа, зависимостей куча (не хотеть подключать) + мутная она довольно, мозг под нее придется сильно перепиливать + мало документации + лень моя. Может теперь на 2.10 придется на нее перелезать.

Аноним Птн 06 Дек 2013 21:40:06  #55 №340515 

бамп1

Аноним Птн 06 Дек 2013 22:11:26  #56 №340527 


/** 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 }))
Аноним Суб 07 Дек 2013 00:16:20  #57 №340550 

>>340527
>Почему
А чего ты ждал? Один Промис комплитят одновременно несколько Фьюч из разных потоков => он будет скомпличен многократно, это же очевидно.
Hint: Используй tryComplete

Аноним Суб 07 Дек 2013 00:19:36  #58 №340552 

>>340550
>tryComplete
Точно, забыл про него.

Аноним Суб 07 Дек 2013 00:19:43  #59 №340553 

>>340363
А если нужно в рантайме сменить тип переменной?
- Преходи на ПХП и меняй;
А если нужно нагнуться за мылом?
- Расслабь булки и нагибайся;

Аноним Суб 07 Дек 2013 00:27:36  #60 №340558 

Я тут вам покушать принес ПравильныхЪ акторов на Scalaz
http://files.meetup.com/1443989/Scalaz%20Actors.pdf
http://zvozin.github.io/blog/2013/05/12/non-blocking-pipelines-with-scalaz-actors/
Они проще пишутся и работают быстрее, чем в этой навороченной тормознутой Акке.

sageАноним Суб 07 Дек 2013 01:05:48  #61 №340566 

Что только не придумают лишь бы на эрланге не писать. Сажи долбоебам.

Аноним Суб 07 Дек 2013 01:26:17  #62 №340575 

>>340566
говноед по курсу

Аноним Суб 07 Дек 2013 02:13:28  #63 №340580 

>>340566
Вот ты и попался, эрлядок. Сейчас за весь эршланг перед нами отвечать будешь. Готов или зассал?
1. Чо я вот так прямо в рантайме могу получить нэндл (или как там у вас называется) любого актора по его имени (строке) ? Области видимости, энкапсуляция, все достижения ООП, нет не слышали?
2. Я вот так прямо на месте объявляю тип Huy и посылаю сообщение этого типа актору YourAnus, который нашел по имени, методом (1), и этот актор так спокойно примет это сообщение и будет обрабатывать?
3. Ты когда кодишь актор YourAnus, ты всегда предусматриваешь такую ситуацию (2) и пишешь для всех таких ситуаций обработчики? Или все сообщения типа Huy тихо пролетают в YourAnus и ты, разраб, даже не знаешь где и с каким актором это происходит прямо в этот момент?
4. Может входная очередь сообщений актора YourAnus уже забита сообщениями типа Huy, поток висит перемалывая миллиарды хуев (сообщений), память течет, а ты даже не знаешь обо всем этом, потому что ты не можешь к каждому анусу прописывать обработчики для всех хуев.

sageАноним Суб 07 Дек 2013 02:52:00  #64 №340582 

>>340580
Вау вау палехче, я всего лишь тролль.

Аноним Суб 07 Дек 2013 03:43:52  #65 №340585 

>>340582
Давай, давай, чеши отсюда и корешам своим передай, чтоб на нашем районе больше не светились.

Аноним Суб 07 Дек 2013 03:45:19  #66 №340586 

>>340580
>(строке)
Апофеоз зашкваренного говноеда, дальше не читал.

Аноним Суб 07 Дек 2013 05:40:17  #67 №340590 

Одному мне кажется, что акторы - это такая питушинна ООП-ешная хуйня, которая в нормальных языках не нужна?

Аноним Суб 07 Дек 2013 06:38:53  #68 №340596 

>>340590
Да.

Аноним Суб 07 Дек 2013 10:23:11  #69 №340604 

>>340248
Joe мне передал что тебя поймает после школы и отпиздят всем эрриксоном

Аноним Суб 07 Дек 2013 17:04:39  #70 №340680 

>>340604
Скаланы, что мне делать? Тут у подъезда машина стоит с номерами OTP-999. Я из дома выходить боюсь.

Аноним Суб 07 Дек 2013 17:35:34  #71 №340693 

>>340590
Вроде человек не глупый, а не видит разницы между самим языком и паттернами, на нем реализуемыми.

Аноним Суб 07 Дек 2013 17:38:02  #72 №340694 

>>340693
>человек не глупый
>Стасик

Аноним Суб 07 Дек 2013 17:51:40  #73 №340701 

>>340586
>дальше не читал.
У тебя какое-то РАННЕЕ ЗАЖИГАНИЕ. Сожми анус покрепче и дочитай до конца. Дальше там самая мякота идет. Настоящий ВЗРЫВ возможен на последних строчках.

Аноним Суб 07 Дек 2013 18:13:17  #74 №340717 

>>340580
1. Под атомом регистрируют только пару долгоживущих акторов, а так pid'ы запрашиваются у процесса-сервиса через API. Более того, модульность никто не отменял.
2. Будут обрабатываться только те сообщения, которые описаны в receive (паттерн-матчингом). Чтобы майлбокс не засырался сообщениями, не совпавшими ни с одним шаблоном, пишут финальную клаузу, игнорирующую сообщение, но при этом оно удаляется.
3, 4 - см. 2

Зато я могу прямо в рантайме заменить весь код актора, все его распознавание сообщений и их обработку. Одной командой.

Аноним Суб 07 Дек 2013 18:18:38  #75 №340722 

>>340590

Old-style imperative multithreading (synchronizing, locking, control flow) < Actors (data flow beginning here) < Promise/Future (composition beginning here) < Pure functional

Аноним Суб 07 Дек 2013 18:29:59  #76 №340730 

>>340722
Если это о том, на какой технологии написано меньше софта, тогда верно.

Аноним Суб 07 Дек 2013 18:34:05  #77 №340732 

>>340730
http://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D1%85_%D1%81%D0%B8%D0%BC%D0%B2%D0%BE%D0%BB%D0%BE%D0%B2
> x<y обозначает, что x строго меньше y.

Аноним Суб 07 Дек 2013 18:41:13  #78 №340735 

>>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 больше всего.

Аноним Суб 07 Дек 2013 18:47:55  #79 №340740 

>>340735
>софта
нинужно.

Аноним Суб 07 Дек 2013 18:58:59  #80 №340748 

>>340735
Лапша > Пельмени > Шашлык > Фуа-гра

Это - Соотношение объяемов производства продуктов питания. Качество этих продуктов имет обратное соотношение.

Аноним Суб 07 Дек 2013 19:02:36  #81 №340751 

>>340748
>Фуа-гра
>Качество
Ебать ты пидорашка.

Аноним Суб 07 Дек 2013 21:36:52  #82 №340808 

>>340717
>pid'ы запрашиваются у процесса-сервиса
Не по строке с именем ли?
>модульность никто не отменял
(В 2013 году) Ну спасибо, что хоть модульность то не отменили.
>Будут обрабатываться только те сообщения, которые описаны в receive
Значит остальные бутут тихо игнорироваться.
>Чтобы майлбокс не засырался сообщениями, не совпавшими ни с одним шаблоном, пишут финальную клаузу, игнорирующую сообщение
Игнорирование сообщений при обработке никак не спасет от засирания ими мэйлбокса.

В общем, пункты (2), (3) и (4) из >>340580 полностю подтверднись. Пункт (1) похоже тоже.

>Зато я могу прямо в рантайме заменить весь код актора, все его распознавание сообщений и их обработку. Одной командой.
Как что-то хорошее.

Аноним Суб 07 Дек 2013 23:02:47  #83 №340859 

>>340808
>подтвердились

слоуфикс

Аноним Вск 08 Дек 2013 00:42:04  #84 №340894 

>>340808
>Игнорирование сообщений при обработке никак не спасет от засирания ими мэйлбокса.

Ты в глаза ебешься? Я же написал
>>но при этом оно удаляется
Любое совпавшее с шаблоном сообщение по прочтению удаляется. У нас любое совпадает.

>>>Энкапсуляция
Под именем регистрируется только пару персистентных порождающих акторов, которые только лишь делегируют задачи.
То есть не:
{ok, Pid} = players:get_pid(Id),
Pid ! {self(), privateMessage, "Lol"}

а
players:private_message(Id, "Lol")
И видимость тоже ограничивается.

Аноним Вск 08 Дек 2013 05:40:52  #85 №340931 

>>340894
Бро, ты всё правильно пояснил этому выблядку, но что это у тебя за камелкейс в эрланге?

Аноним Вск 08 Дек 2013 07:45:12  #86 №340936 

Просто jvm-мирок зашкварен уже давно и основательно, и никакой Typesafe не спасёт. Прочитал ОП-пост и почему-то не удивился даже. Это ж джава, как всегда всё проебали.

Аноним Вск 08 Дек 2013 12:44:31  #87 №340980 

>>340931
Переменные в эрланге пишутся камелкейсом же.
Правда там я провтыкал и атом тоже камелкейсом написал

Аноним Вск 08 Дек 2013 13:51:58  #88 №340995 

>>340580
пиздец ты поехавший
>1. Чо я вот так прямо в рантайме могу получить нэндл (или как там у вас называется) любого актора по его имени (строке) ? Области видимости, энкапсуляция, все достижения ООП, нет не слышали?
могу, gproc
>4. Может входная очередь сообщений актора YourAnus уже забита сообщениями типа Huy, поток висит перемалывая миллиарды хуев (сообщений), память течет, а ты даже не знаешь обо всем этом, потому что ты не можешь к каждому анусу прописывать обработчики для всех хуев.
могу подключиться к ноде и посмотреть что внутри мэйлбокса процесса, а так же обоссать тебя прямо из консоли

Аноним Вск 08 Дек 2013 17:48:07  #89 №341084 

>>340995
>могу, gproc
Родина им области видимости дала, ООП им дало инкапсуляцию, ФП дало первоклассные функции, нет не хотим все это, хотим динамическое говно жрать, в рантайме все получать по строке без тайпчекинга, чтоб компилятор не мешал говнокод писать. Построили они свое ПХП с акторами и шлюхами.
>могу подключиться к ноде и посмотреть что внутри мэйлбокса процесса
Я говорю, что левое говно не должно попадать в мэйлбокс, а ты говоришь, что можешь открыть свой мэйлбокс и понюхать любое говно в нем.
>а так же обоссать тебя прямо из консоли
Вот она - привычка в рантайме свой говнокод вилкой чистить. В нормальных языках, где компилятор сам выполняет все проверки, НИНУЖНО ничего в рантайме чистить вилкой.
>пиздец ты поехавший
Поехавшие - те, кто считают динамическое говно сладким хлебом.

Аноним Вск 08 Дек 2013 18:05:43  #90 №341094 

>>340894
>Ты в глаза ебешься? Я же написал
>>но при этом оно удаляется
>Любое совпавшее с шаблоном сообщение по прочтению удаляется. У нас любое совпадает.
Совсем уже мозг потек на 100500 потоков/нитей (которые и не потоки не разу, а голимые функции последовательно в потоке исполняемые) ? Ты вообще не чувствуешь разницу между попаданием сообщений в мэйлбокс (реальная причина засирания) и их обработкой? Как, скажи, как, блядь, клоз в обработчике может помешать попаданию сообщения в мэйлбокс? По твоей логике: Часто стирать штаны == не срать под себя. Если ты так считаешь, то ты уже обосрался.

Аноним Вск 08 Дек 2013 18:15:38  #91 №341099 

>>340931
>всё правильно пояснил
Из 4 серьезных предъяв:
- Ответил за 0.5 (что область видимости актора даже может быть как-то ограничена (ну нихуя себе));
- Полностью признал остальные 3.5;
>всё правильно пояснил
И под шконку уполз.

Аноним Вск 08 Дек 2013 18:33:34  #92 №341102 

>>341094
Так ты же тупой как бревно.
Ещё раз объясняю, читай по слогам что ли.
Попавшее в майлбокс сообщение сопоставляется со всеми шаблонами из receive. Если оно совпадает хотя бы с одним, выполняется соответствующая инструкция и ЭТО СООБЩЕНИЕ СРАЗУ УДАЛЯЕТСЯ ИЗ МАЙЛБОКСА. Засирание майлбокса возможно только если актору приходит сообщение, которое он не знает как обрабатывать. Такие сообщения актор игнорирует и не удаляет. Чтобы этого избежать пишут:

receive
{huita, _, HuitaMessage} → huita(HuitaMessage);
{govno, Pid, GovnoMessage} → govno(Pid, GovnoMessage);
Unknown → log(self(), unknown, Unknown), ignore
end

Когда актор получает сообщение, он поочередно сверяем его со всеми шаблонами. Последний шаблон Unknown сработает в любом случае, что значит, что СООБЩЕНИЕ ГАРАНТИРОВАННО БУДЕТ УДАЛЕНО ИЗ МАЙЛБОКСА.

Аноним Вск 08 Дек 2013 18:55:15  #93 №341109 

>>341084
>В нормальных языках, где компилятор сам выполняет все проверки, НИНУЖНО ничего в рантайме чистить вилкой.

Есть статический анализатор, который по такому-то http://www.it.uu.se/research/group/hipe/papers/succ_types.pdf success typing'у так же все проверит до запуска.

Аноним Вск 08 Дек 2013 19:20:41  #94 №341120 

>>340936
[Фэйспалм.жпг] - с кем я говорю. Ты оказывается не можешь в самые основы акторов. Что такое по-твоему мэйлбокс? Ты никогда не слышал, что в нем хранится ОЧЕРЕДЬ сообщений? Или ты думаешь обработка сообщений происходит в момент его отправки (попадания в мэйлбокс)? Что такое засирание мэйлбокса? Это ни когда в нем лежит что-то, что актор не желает обрабатывать, а когда сообщения поступают в него быстрее, чем обрабатываются. Сечешь? А теперь скажи еще что ты не понимаешь какое отношение ко всему этому имеет быстрый вброс левых сообщений в мэйлбокс нагруженного (теперь ты понимаешь значение этого слова?) актора ? А как можно выдавить из очереди нагруженного актора любое ценное/значимое сообщение с помощью вбросал перед ним лкучи левого говна, ты тоже не понимаешь? Короче, RTFM, я тут не собираюсь лекции по теории акторов читать.

Аноним Вск 08 Дек 2013 19:27:11  #95 №341123 

>>341109
Интересно, почитаю, когда время будет. Ты сам то можешь вкратце пояснить суть? Например, как понимать это:
>It is important to point out that although Erlang is dynamically typed, it is type safe

Аноним Вск 08 Дек 2013 19:53:28  #96 №341130 

>>341123
>dynamically typed
>type safe
Строгая, динамическая типизация.
мимо

Аноним Вск 08 Дек 2013 20:00:07  #97 №341136 

>>341130
Неправда, ведь звучность строгой динамической типизации не сильно выше звучности слабой. Различие только в том, что слабая динамическая типизация старается помочь, спасая в некоторых случаях программу от краха и додумывая ее за программиста, а сильная сразу валит ее, отрицательно влияя на безотказность.

Аноним Вск 08 Дек 2013 20:44:05  #98 №341160 

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

Аноним Вск 08 Дек 2013 20:51:16  #99 №341167 

>>341160
> Программа должна падать при малейшем подозрении что что-то не так.
Это было бы абсолютно правильно при нулевой цене падения программы.
> Если некорректные действия программы опаснее её выключения, то лучше её выключить.
А если не опаснее? Ведь нету же статистички сравнения случаев "программа охуячилась и выдала неправильный результат - скоко $ потеряли" vs "программа охуячилась из-за ошибки тепезации - скоко $ потеряли из-за простоя". Или, может быть, ты меня обрадуешь, обвинишь в соснульстве, и в качестве четкого и дерзкого доказательства этому приведешь ссылку на такую статистичку?

Аноним Вск 08 Дек 2013 20:51:43  #100 №341168 

>>341160>>341136
Вы идиоты? Статическая и скомпилить не даст при ошибки с типами.

Аноним Вск 08 Дек 2013 20:57:26  #101 №341172 

>>341168
Но ведь дискурс идет в контексте динамической. Зачем ты сюда со своей статикопатокой влез?

Аноним Вск 08 Дек 2013 21:06:03  #102 №341176 

>>341167
Статистику такую трудно сделать, потому что она будет дорогой. Последствия останова программы очень легко просчитать. А вот последствия её дальшейшей некорректной работы - нет. Потому что работать она может как угодно и все варианты просчитать невозможно. Риск в случае останова просчитываем, а риск в случае неостанова становится неопределенным. В этой ситуации нормальные люди выбирают первый вариант.
Я играл на бирже и пришел к тому что программа должна останавливаться при малейшем чихе (торговый робот). Хотя раньше всегда был сторонником либерального отношения к ошибкам.
Моя стата простая - из-за неостанова программы проебал 5К рублей (повезло что так мало).
Из-за нескольких остановок сохранил возможно приличные деньги (точно узнать нельзя, т.к. неизвестно что бы сделала программа будучи неостановленной, но то что набрала бы позиций на чужие деньги - это 100%. Возможно они оказались бы прибыльными и я бы даже заработал, но если убыточными, то влетел бы прилично и потенциально выше собственных активов, проще говоря полное банкротство и с долгами впоследствии).
Видел примеры как один робот слил 2 ляма рублей на фортс в 2009 году за 10-15 минут, и 2-4 млн долларов где-то в 2011 за 2 минуты. Вот там роботы не останавливались. Если бы они остановились, то они бы просто ничего не заработали, но и не потеряли бы. На всякий случай скажу что деньги это всё довольно большие и за такое время не зарабатываются за какое они были проиграны, по крайней мере теми алгоритмами.
Простой (отсутствие активности) на бирже это вещь очень и очень неопасная (перестает генерироваться прибыль при сохранении волатильности, если простой очень долгий, то там волатильность может несколько возрасти потом), в сравнении с ошибочными действиями, убытки от которых могут быть колоссальны на самом деле. Но это касаемо биржи. Может в других областях иначе, но я таких областей не видел и буду рад если ты приведешь примеры, желательно из своего опыта.

Аноним Вск 08 Дек 2013 21:10:12  #103 №341184 

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

Аноним Вск 08 Дек 2013 21:14:36  #104 №341185 

>>341176
Это были ошибки типизации или ошибки алгоритмов?

Аноним Вск 08 Дек 2013 21:16:34  #105 №341187 

>>341176
> Статистику такую трудно сделать, потому что она будет дорогой. Последствия останова программы очень легко просчитать.
Тока больно уж печально получается, а в вот во втором случае можно еще надеяться на авось.
> А вот последствия её дальшейшей некорректной работы - нет. Потому что работать она может как угодно и все варианты просчитать невозможно. Риск в случае останова просчитываем, а риск в случае неостанова становится неопределенным.
Риск в обоих случаях снижаем как дешевыми методиками, вроде наделать еще немного всяких там проверок, так и дорогими вроде диверсификации.
> В этой ситуации нормальные люди выбирают первый вариант.
А аппликативные и нуждающиеся люди какой выбирают? (:

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

Аноним Вск 08 Дек 2013 21:18:50  #106 №341189 

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

Аноним Вск 08 Дек 2013 21:20:51  #107 №341190 

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

Аноним Вск 08 Дек 2013 21:24:26  #108 №341195 

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

Но если пофантазировать, то какова будет цена падения самолетного ПО в случае ошибки типизации (оно конечно по ватчдогу перзапустится, но будем считать что падение было обусловлено IO и после перезапуска оно снова падает и снова и снова). Против цены неправильного управления, когда у пилотов есть возможность заметить, что компьютер врет и перейти на ручное управление?
> Из-за нескольких остановок сохранил возможно приличные деньги
То есть у тебя типизировались математические расчеты? Какие формальные методы применял для верификации и валидации?

Аноним Вск 08 Дек 2013 21:26:41  #109 №341199 

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

Аноним Вск 08 Дек 2013 21:31:12  #110 №341200 

>>341187
>а в вот во втором случае можно еще надеяться на авось.
>Вот это и есть ошибка.

>>341185
В моем случае ошибки были в данных, которые поставлял терминал (я не знаю конкретно из-за чего, терминал писал не я, код закрыт) и ошибки брокера (человеческий фактор). Робот на C#, компилятор там отловил все ошибки типизации еще на компиляции. На языках с динамической типизацией пишут только веб-макаки и самоубийцы.

>>341195
>Но если пофантазировать, то какова будет цена падения самолетного ПО в случае ошибки типизации (оно конечно по ватчдогу перзапустится, но будем считать что падение было обусловлено IO и после перезапуска оно снова падает и снова и снова). Против цены неправильного управления, когда у пилотов есть возможность заметить, что компьютер врет и перейти на ручное управление?
В такой ситуации нужен останов однозначно. Автопилот подает сигнал что он выключился и перестает портить ситуацию. Если же он продолжит действовать то есть риск сваливания в штопор, из которого выйти практически невозможно на пассажиских лайнерах.

Аноним Вск 08 Дек 2013 21:37:17  #111 №341201 

>>341199
Ну ладно, уговорил, всё дело в невнимательности.

Аноним Вск 08 Дек 2013 21:38:06  #112 №341202 

>>341200
> В моем случае ошибки были в данных, которые поставлял терминал
Ясно.
> Автопилот
Система управления самолетом. Не существует пути управления кроме как через нее и она постоянно падает из-за ошибок типизации. Не во всех системах автоматизированного управления машинами и механизмами существует путь непосредственного управления, через веревочки.

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

Аноним Вск 08 Дек 2013 22:07:20  #113 №341212 

>>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, там действительно можно померятся пипками, а так, пиздуй отсюдова, мальчик.

Аноним Вск 08 Дек 2013 22:15:09  #114 №341215 

Рис № 42. "Сорта динамической типизации".
(сверху вниз, слева направо) 1.Строгая; 2.Нестрогая; 3.Полустрогая; 4.5.6...ect.

Аноним Вск 08 Дек 2013 22:36:17  #115 №341228 

>>341212
Блядь, ведь хотел же подробно твой пост разжевать, на все по порядку ответить. Но тут у меня БОМБАНУЛО.
>У скалы тред-акторы - жирные треды ОС, более пару тысяч не запустишь, ивент-дривен акторы - это вообще какая-то насмешка, выполняются последовательно, один лочит всю VM, пиздец.
НУ ЛОЖЬ ЖЕ, БДЯДЬ. НАГЛАЯ ЛОЖЬ!111111111111111
Вся как сказано >>340248
>анальный раб Тайпсэйфа, который дрочит на реактивное программирование и молиться на Акку. Он уперт, религиозен, фанатичен, не имеет собственного мнения и только повторяет заученную пропаганду Тайпсэйфа
Точнее не скажешь

Сейчас успокоюсь и попробую все подробно расписать.

Аноним Вск 08 Дек 2013 23:29:36  #116 №341241 

>>341212
>Скала отсосет у ерланга в сетевом I/O
Это тебе менеджер из эриксона таких охуительных историй нарасказывал?
>там вообще есть захват актором сокета
Что захуйню я читаю? Что такое по-твоему актор? Это что нода? - ХУЙОДА! АКТОР (для тех кто не в курсе) - это просто ФУНКЦИЯ не возвращавшая значения и выполняемая асинхронно (отсюда все фитчи) в цикле. Какой, блядь, захват сокета (теперь)?
>автоматическая ивент-обертка, передача управления
Что это? Еще один маркетинговый ход ериксона? Наверняка какой-то велосипед, который давно валяется в библиотеках многих языков и никто такой ерундой не хвастается.
>в хвостовой рекурсии (какие-то ограничения
Хвостовая рекурсия в скале ВСЕГДА компилируется в максимально быстрый код (где возможно через цикл, где невозможно через вызов на стеке). Все ограничения - просто ворнинги для байтоебов, которые хотят засунуть свой нос в сам механизм компиляции. Могу поспорить, в ерланге компилятор устроен так-же (все другие варианты - не оптимальны), только ты об этом даже не знаешь.
>У скалы тред-акторы - жирные треды ОС
Такую хуйню мог написать только человек, очень далекий от скалы или с полностью промытыми пропагандой мозгами. Мимо же люди проходят, ведь поверить же могут, лол. Поясняю еще раз: Актор - просто функция (НЕ НОДА, НЕ ПОТОК, еще раз это прочти), которую вызывает шедуллер и передает ей сообщение из очереди. Сам шедуллер может быть устроен как угодно, почти все реализации акторов (даже акка) позволяют внутри себя выбирать реализацию шедуллера (ерланг и тут соснул). Можно, например взять ExecutionService с пулом потоков, он нагружает все потоки пула по максимуму: Как только один актор отработал сообщение в это же потоке запускается другой активный актор, в очереди у которого есть сообщения. Это практически наиболее ОПТИМАЛЬНЫЙ из возможных вариантов распределения нагрузки между потоками ОС. Или давай придумай что-то лучше (если можешь в многопоточноть в ОС), только для начала выкинь из своей башки весь этот маркетинговый чес про СУПЕРБЫСТРЫЕ-ОЛОЛО-ПОТОКИ, забудь эти сказки. Там внутри OTP все реализовано точно так же, потому что иначе это реализовать невозможно. Разница только в том, что OPT закрыта и тебе приходится верить/не_верить сказкам маркетологов, а на скала ты можешь сам выбирать/настраивать/крутить-на-хую шедуллер или писать свой.
>Скала по конкуренси не может даже кложуру догнать
Одно история охуительнее другой. Даебали уже такие пиздобольские заявления без пруфов. Особенно от человека с промытыми мозгами ("Акторы = потоки ОС" - не перестаю лоллировать).

Аноним Вск 08 Дек 2013 23:30:49  #117 №341243 

>>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 кэп). В некоторых реализациях динамических яп тоже есть возможность проанализировать код до рантайма и поймать там ошибки типов. Что касается нежелательного краха и простоя программы - это не обязательно должно решаться смягчением типизации, гораздо лучше иметь возможность перезапустить процесс в случае ошибки и получить новый, корректно работающий вместо некорректно работающего старого.

Аноним Вск 08 Дек 2013 23:36:30  #118 №341244 

>>341241
То есть актов это простой калбак? Хуле вы тогда свою хуйню развели?

sageАноним Вск 08 Дек 2013 23:39:45  #119 №341246 

Смотрите, что думает о Скалке создатель Lift, после того, как он слегка познакомился с Clojure:
http://skillsmatter.com/podcast/java-jee/some-musings-on-scala-and-clojure-by-a-long-time-scala-dude

Аноним Пнд 09 Дек 2013 00:02:09  #120 №341250 

>>341228
Насколько я знаю, нормальный мультитаскинг реализован только в Эрланго-VM, в GHC и в Go. Подразумевается, что для этого нужна вытесняющая многозадачность, никакое кооперативное говно на такое претендовать даже не может.

GHC переключает процесс - когда нужна память, Go просто переключает контекст канала, так что затяжной луп может зойхавать ядро.
Только эрланг переключает процессы по исчерпыванию ими бюджета (~1ms) и только он дает чистый fair use.

В остальных моделях, в Ocaml, Node.js, Twisteded etc такого нет, у их щедулер не умеет двигать процессы, они не могут быть приоретезированы и т.д.

Аноним Пнд 09 Дек 2013 00:04:31  #121 №341251 

>>341244
Актор - это паттерн проектирования. См >>340722, т.е. вся concurrency может быть исполнена:
1. Старомодно на потоках, синхронизациях, блокировках;
2. На акторах (если смешать их с (1), то весь смысл теряется);
3. На Promise/Future;
4. Чисто (+лениво) функционально. Все проблемы concurrency тут снимаются, и шедуллер может сам запускать все ленивые вычисления как ему покайфу без последствий.
5. В принципе не исключены другие варианты, если они не сводятся к (1).

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

Аноним Пнд 09 Дек 2013 00:15:22  #122 №341254 

>>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

Аноним Пнд 09 Дек 2013 00:17:34  #123 №341255 

>>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).

Аноним Пнд 09 Дек 2013 00:28:14  #124 №341256 

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.

Аноним Пнд 09 Дек 2013 00:32:08  #125 №341257 

>>341256
А че шах и мат то? Ты так говоришь будто у нас на нативоговне байтобляди не городят преемптив планировщики. Неужели на нейтиврговне можно а на жвм нельзя?

Аноним Пнд 09 Дек 2013 00:32:46  #126 №341258 

>>341250
Давай поаккуратней с терминологией. Ты говоришь о threads (потоках/нитях/тредах), процессы ОС - это отдельные адресные пространства, виртуальная машина (ВМ) работает внутри процесса ОС и не может его переключать.
>вытесняющая многозадачность
Реализуется на уровне ОС. ВМ чаще всего не должна этим заниматься. Вычисления внутри ВМ обычно распараллельиваются так - ВМ сразу закупает несколько десятков потоков ОС (можно и несколько сотен, не таки они и тяжелые, как говорят) и распределяет свои мелкие задачи (акторы, например) между этими потоками. Нагруженные потоки ОС шедуллит между ядрами ЦП, заблокированные/ожидающие занимают только поток ОС, но ни как иначе не тормозят систему. Опасность тут только в том, что выделенных потоков ОС может тупо не хватить на все задачи (много мелких акторов) и их придется прикупать/продавать походу, а это накладные расходы и тормоза. Отсюда идея об Асинхронности. Смысл - закупать у ОС потоки по количеству ядер ЦП (или чуть больше), если задачи не будут блокировать потоки на время IO, то потоков должно хватить.
>Только эрланг переключает процессы по исчерпыванию ими бюджета (~1ms)
Такое поведение можно написать и для акторов на скала. Только нет особого смысла перекидывать легковесные "потоки" между потоками ОС, кроме как в моменты получения сообщения актором, все эти таймеры, пуски/остановки - это только дополнительный оверхед. Если большинство акторов отрабатывают за время в сотни наносекунд, то квант времени в миллисекунду - лишен всякого смысла. Возможно все это придумано, как лекарство от зависаний для ериксоновского железа на котором ОСи (что там кроме самой OPT?) не имеют собственного шедуллера вытесняющей многозадачности, а потом уже широко распеарено.

Аноним Пнд 09 Дек 2013 00:47:33  #127 №341264 

>>341254
Хуйню какую-то нагуглил и мне в глаза ее тычишь. Нахуй убери это отсюда. Хватит уже заученную хуйню твердить. Пора включать собственный мозг и начинать думать без посторонней помощи. Ты изучаешь языки по туториалам и сторонним обзорам, а я в первым делом вычитываю исходники библиотеки, прежде чем подключить ее к проекту. А я наподключал "scala.actors" во много проектов. И "scalaz.concurrent" я тоже не раз перечитал. Я знаю как они устроены до последнего винтика. Я бы свою библиотеку акторов на коленке написал бы с закрытыми глазами, вот только нахуй нужен еще один велосипед. Ты бы немного для начала ознакомился с тем, что в треде уже было >>340558 а потом бы попиздел про свои heavyweight-потоки.
>Дааа, на горелом заду адекватный пост не напишешь.
Но в этом ты прав, СУКА!!111

Аноним Пнд 09 Дек 2013 00:56:17  #128 №341266 

>>341256
>Checkmate. Game over. Hasta la vista:)
Показывает уровень того школьника. От того, что он англоговорящий, умнее он не станет.
>rebuilding your mind, your way of thinking
Ты и теперь тут не видишь высера маркетологов?
>Erlang teaches you and upgrades you.
Похоже на пиздежь менеджера продавана из Мвидео. "Вы еще кипятите (на скала) тогда мы (ерланг) идем к вам". Только дебилы могут на это вестись.

Аноним Пнд 09 Дек 2013 00:56:21  #129 №341267 

>>341256
На самом деле 2к редукций, но это настраивается, да.

-Erlang does copy-on-send
- Akka uses shared memory.
>shared memory
И на этом месте настоящая модель акторов заканчивается.

>>341258
В эрланге процессы - это треды VM, но они не совсем треды, так как у каждого - свой стек, свой хип, есть приоритет, и они вытесняют друг друга, прямо как процессы ОС, но живут внутри VM. Эрланг запускает на каждом ядре по инстансу, за счет прозрачности передачи данных, процессы общаются между ними, так, как будто они внутри одного инста. Каждый инст - контролирует переключение своих процессов, по исчерпанию бюджета, если процесс не доделал свою задачу, он бросается в конец очереди, таким образом все получают поровну, сборка мусора кстати тоже. Эрланговское IO живет в ОС процессах. Нить весит ~0.5 Кб, создается за 3-5 мкс. Такая дешевизна позволяет ебошить чуть ли не на каждую сущность по процессу. Если нужна оптимизация и контроль памяти - делается пул процессов, растаскивающая очередь.

Аноним Пнд 09 Дек 2013 01:05:07  #130 №341269 

>>341266
>Ты и теперь тут не видишь высера маркетологов?
Это просто какой-то хуй со стековерфлоу. Вангую что он фанатик, а это всегда хуево, но тут он прав же.

Что примечательно, почти в любом бложике, иксперт сравнивающий Scala и Erlang, говорит, что ирлонг лучше в плане конкурентности/распределености. Неужели эриксоновские маркетологи настолько вездесущи? А ну загляни под кровать.
Вон fb отписывались по поводу своего чата на эрланг, что он работает, как они и хотели. Разраб с ласт.фм, тоже писал, воу парни это охуенно один сервер свободно держит 1кк соединений, попробуйте. Они тоже куплены?

Аноним Пнд 09 Дек 2013 01:19:40  #131 №341274 

>>341256
Ладно, копнем по глубже этот маркетинговый высер.
>>341256
>In Erlang processes are guaranteed to be switched approximately each 1000 reductions.
Т.е. акторы работают по 1 миллисекунде в среднем. За это время можно перебрать несколько миллионов хэшей (это за один цикл работы актора, т.е. на убработка одного сообщения). Если ты реально пишешь такие тяжелые акторы, то ты точно наркоман. Нормальный актор в несколько (десятков) строк должен отрабатывать в несколько десятов/сотен наносекунд. Значит реальная скорость переключения между "задачами" (акторами) на два порядка быстрее (и на скале, и на эрланге и на хую моржевом), чем этот квант времени в 1 мс. Вопрос: Нахуй тогда нужно это ограничение в 1 мс, если реально оно не может быть достигнуто никогда или только по ошибке кодера, который проебал условие цикла?

Вопрос №2. Современные ОСи в реализации своей вытесняющей многозадачности используют квант времени >10мс. Т.е. не станут трогать полностью зависший поток как минимум 10 мс. Что мы имеем: проги виснут, это случается, но система при этом субъективно только "притормаживает", мы нигде не замечаем скачков и дерганий (кривые драйвера на видео в шиндос таки умеет это). Значит кванта времени в 10мс за глаза хватает для очень плавного распределения нагрузки. теперь вопрос: квант = 1 мс? Это мы перед кем решили повыебываться?

Аноним Пнд 09 Дек 2013 01:35:40  #132 №341281 

>>341264
Ладно, я согласен с тем, что не могу быть объективен, так как хорошо знаю только ирлонг, скалу знаю поверхностно. Но совершенно очевидно, что многое зависит от платформы. Если beam.smp заточена под акторов и конкуренси, то jvm - нет, что значит, что создание хорошей модели поверх неё - задача сложная и по своей сути - костыль. Делать на уровне языка/библиотеки, то, что должно быть выполнено на уровне платформы - это никак не хорошее решение. Учу сейчас скалу, мне нравится удобная система типов, наличие хуевой тучи либ, улучшенное еба ООП, гора синтаксического сахара для ФП.

>>341274
1. Актор ограничен только верхним пределом. Если он справляется быстрее 2к редукций, ок молодец, переключаемся на следующего. Бюджет в ~1 ms выделяется на все в рамках щедулера. Сборка мусора, отправка сообщения, выборка из таблицы, I/O в порт, посылка сообщения на другую ноду, абсолютно все. Ещё раз, только верхний предел.

2. Квант можно настроить. В некоторых системах провисание > 5мс - уже плохо. Но опять таки, это все настройки рантайма.

Аноним Пнд 09 Дек 2013 01:42:50  #133 №341283 

>>341267
>В эрланге процессы - это треды VM
Очень сомневаюсь в этом. Тысяча нитей под нагрузкой положат всю ОСь так, что курсор мыши не отрисуется. А акторы могут работать десятками тысяч (те самые хваленые "Легковесные" потки). В Скале также могут работать (а не просто болтаться в ожидании) десятки тысяч акторов, при этом они работают на пуле в 16 (например) потоков ОС.
>>341267
>Эрланг запускает на каждом ядре по инстансу
Лол. Так прям в руководстве написано? Ну начнем с того, что процесс в юзерспэйсе к ядрам ЦП доступа имеет нихуя. Все что он может, это создать несколько потоков ОС (по колличеству ядер или в два/четыре раза больше) и надеяться на то, что ОС-шедуллер разложит эти потоки по ядрам (в лучшем случае) когда на всей ОС нет других активных потоков.
>Нить весит ~0.5 Кб, создается за 3-5 мкс
Это подтверждает, что к потокам ОС эти потоки отношения не имеют.

Ну в общем все что ты описал соответствует (грубо) шедулленгу "задач" на ExecutionService (кстати прочитай про него), который используется в шедуллере акторов "scalaz.concurrent" и в акка. В "scala.actors" используется ForkJoin, который устроен чуть по-хитрее, но на том же принципе (быстрое переключение "задач" на пуле потоков ОС).

Аноним Пнд 09 Дек 2013 01:59:16  #134 №341285 

>>341269
>Неужели эриксоновские маркетологи настолько вездесущи?
Допускаю что большая часть проектов на ерланге более производительна, чем большая часть проектов на скала.
Этому могут быть разные причины.
1. Многие скалисты - бывшие джависты, привыкли пердолиться абстрактными фабриками абстрактных адаптеров во имя энтерпрайза.
2. Скала еще не полностью оторвалась от рантайма джавы. А большинство крупных (сегодня) проектов начинали писаться в те времена, когда скала еще плотно сидела на жаберном рантайме. Все эти переходники/адаптеры вносят значительный оверхед.
3. Скала - мультипарадигменный это охуительно низкая производительность в реальных проектах показывает, что это очень плохо, когда разрабов не принуждают к определенному стилю.
4. Ерланг - В чем-то препятствует написанию быдлокода. (Но вот динамическая сущность сообщений, наоборот способствует).
5. Возможны еще варианты.

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

Аноним Пнд 09 Дек 2013 02:09:46  #135 №341286 

>>341283
Так, ещё раз по-порядку.

Инстанс VM - процесс ОС.
Если ты запускаешь рантайм с no-smp их будет всего 2, один из них - под IO. Если запускаешь как обычно, с smp - их будет ровно столько, сколько ядер на машине + 1 под IO.
Больше процессов OС нет.

Эрланговские "процессы" - это треды внутри инстанса, с процессами ОС ничего общего не имеющие ВООБЩЕ.
Называются они процессами, по той причине, что они не похожи на треды VM в обычном понимании. Они не разделяют данных, у каждого свой хип, они вытесняют друг друга и имеют приоритеты.

Аноним Пнд 09 Дек 2013 02:20:47  #136 №341288 

>>341286
И за щедулинг отвечает не ОС, а только VM.

Более того, "процессы" мигрируют между инстансами.
Там встроенный балансировщик, следящий за тем, чтобы ядра были нагружены равномерно. Если тасков меньше, чем надо, он старается освободить ядро, перевести инстанс на нем в пауер сэйф моде. Так же щедулер может воровать таски у других инстансов, если ему нехуй делать.

Аноним Пнд 09 Дек 2013 02:22:39  #137 №341289 

>>341281
>Делать на уровне языка/библиотеки, то, что должно быть выполнено на уровне платформы - это никак не хорошее решение.
Если платформа как-то мешает этому, то да. Но jvm сама почти не в вмешивается в эти вопросы (кроме сборщика мусора). Нативный класс Thread - очень тонкая обертка вокруг потока ОС, а более низкого уровня не существует. Библиотечный код (реализующий модель акторов, например) компилится JIT-ом так, что по скорости на 150% (а не на 1500% как руби и прочие пхп) отстает от кода на С. Если учесть, что само переключение задач и вся инфраструктура шедуллера съедают не больше 1% времени, то нет смысла гоняться за проебанными долями процента. Что мы получаем взамен - весь код открыт + можно переписать что-угодно под себя (!)

Аноним Пнд 09 Дек 2013 02:39:01  #138 №341292 

>>341286
>их будет ровно столько, сколько ядер на машине + 1 под IO.
Если все действительно так, тогда непонятно зачем создавать несколько процессов ОС. Насколько я знаю, так поступают только PostgreSQL и старые версии MySQL для совместимости с какими-то редкими *никами у которых проблемы с потоками в нормальном понимании.
Еще тогда "перекидывание" треда (эрланговского процесса) между инстанцами (из одного адресного пространства в другое) - задача не быстрая.
>они не похожи на треды VM в обычном понимании.
ORLY?
>они вытесняют друг друга и имеют приоритеты.
Как и все потоки в большинстве современных ОС.
>у каждого свой хип
Это достигается средствами вм. На jvm и .net все также
>Они не разделяют данных
Или разделяют иммутабильные дынные

Аноним Пнд 09 Дек 2013 02:51:16  #139 №341294 

>>341288
>И за щедулинг отвечает не ОС, а только VM.
Че, правда? Это еще каким образом?
>Там встроенный балансировщик, следящий за тем, чтобы ядра были нагружены равномерно.
Ну начались охуительные истории. Тут байтоебов обсирают в соседнем треде, вот он, пример того, как сильно можно размечтаться, если не знать элементарные принципы работы ОС.
Повторяю еще раз: Все что может сделать любая программа, работающая в юзерспейсе - это работать с потоками ОС, создавать/удалять/менять_приоритеты (приоритеты номинальны, их соблюдение полностью зависит от ОС). Также можно шедуллить собственные "задачи" между этими потоками. А еще можно помолиться Балмеру/Торвалдсу, чтобы шедуллер ОС дал этим потокам каждому по ядру CPU.

Аноним Пнд 09 Дек 2013 03:05:52  #140 №341297 

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

Аноним Пнд 09 Дек 2013 03:09:26  #141 №341298 

>>340693
То, что Скала - говно для джавапитухов я и так знаю, меня интересует именно паттерн. Актор - объект, к которому прикручена очередь сообщений, в ответ на сообщения о меняет своё состояние, посылает сообщения, создаёт другие акторы - т.е. делает что угодно. Но это и есть ООП в первозданном виде с его питушинной семантикой. И еще вокруг акторов много всякого гуманитарного хайпа. Я ничего не упустил?
>>340722
Поясни по хардкору, что там такого? Вот та же STM в хачкеле по сути оптимистическая блокировка с ретраями, плюс она вся такая композабельная (благо сайдэффекты изолированы и ретраи жопаболей не доставляют, но никакого рокетсаенса, чтобы целые книги писать, там нет). Суть акторов?

Аноним Пнд 09 Дек 2013 03:15:38  #142 №341300 

>>341298
> Суть акторов?
Чтобы не жрать говно и не разделять данные.

Аноним Пнд 09 Дек 2013 04:03:49  #143 №341304 

у скаладебила горит пердак.
erlang > clojure > моча > говно > дно > хохол > scala

Аноним Пнд 09 Дек 2013 04:31:30  #144 №341306 

>>341298
>Поясни по хардкору, что там такого?
Здесь заканчиваются потоки управления, и отсюда начинаются потоки данных + Большие профиты в плане производительности: Нет синхронизации, нет блокировок, невозможно крайне сложно написать деадлок + есть минимальная защита от говнокода.
>И еще вокруг акторов много всякого гуманитарного хайпа.
Ни без этого. Акторы - первая ступенька из императивного мира к функциональному, на этой ступеньки многие гуманитарии ломают себе ноги, весь шум вокруг - просто их писк.
>в ответ на сообщения о меняет своё состояние
Это из быдлопедии что ли цитата? На Scalaz например, актор вообще расширяет функцию, а значит иммутабелен по природе.
>плюс она вся такая коммуникабельная
Еще одно открытие для тебя - акторы Scalaz - таки композабельны (за сайдэффекты, конечно, ты сам отвечаешь), прикинь да.
>но никакого рокетсаенса, чтобы целые книги писать, там нет
Потому что в stm не приходят сотни вчерашних джаваобезъян, это на несколько порядков выше их уровня.

Аноним Пнд 09 Дек 2013 04:54:26  #145 №341310 

>>341304
Моча > быдло < горит > пердак < дебил
ОЛОЛОЯВСЕХВАСЗОТРОЛЕЛ

О, кто к нам пожаловал... Ежедневный обход всех тредов перед сном? Что за ритуал такой?

Аноним Пнд 09 Дек 2013 05:32:42  #146 №341314 

>>341310

Аноним Пнд 09 Дек 2013 09:49:09  #147 №341335 

>>341257
Когда на жвм делают асинхронщину, то заводят пул потоков и используют форк-джойн, т.е. чтобы не создавать постоянно новые трэды передают таски на те трэды, которые свою таску завершили. Теоретически, между работающими трэдами ресурсы CPU делить ОС. Но вполне возможен отсос, когда все трэды из пула зохватили таски с бесконечными циклами, и новые таски не выполняются. А ДАЛЬШЕ ПЕРЕПОЛНЯЮТСЯ БУФЕРА IO КРОВЬ-КИШКИ-РАСПИДОРАСИЛО РЕСТАРТУЕМ СЕРВЕР ВСЕ ЛОМЯТСЯ ТУДА ОН ОПЯТЬ ПАДАЕТ ПЕРЕПОЛНЯЮТСЯ БУФЕРА НА КЛИЕНТАХ ВСЁ НАХУЙ РЕСТАРТУЕТ ИЗВИНИТЕ ЗА ТЕХНИЧЕСКИЕ ПРОБЛЕМЫ НАС АТАКОВАЛИ ЗЛЫЕ ХАКЕРЫ

Аноним Пнд 09 Дек 2013 14:12:46  #148 №341380 

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-а на императивном говне код превращается в нечитаемую лапшу.

sageАноним Пнд 09 Дек 2013 14:14:38  #149 №341381 

>>341380
Блядь, какая-то хуйня из банка в канаде скопипастилась. Модератор, удали тред, а то меня комплаенс трахн

Аноним Пнд 09 Дек 2013 14:21:18  #150 №341382 

>>341380
> Когда на джаве делают асинронщину, используют эту хуйню - http://en.wikipedia.org/wiki/Reactor_pattern.
Я имел в виду асинхронное IO. Внутри процессов нормальные люди просто используют BlockingQueue, лапша из листенеров для быдла.

Аноним Пнд 09 Дек 2013 14:23:51  #151 №341384 

>>341381
>трахн
Обязательно, я уже настучал куда надо.
Готовь туза, манька.

sageАноним Пнд 09 Дек 2013 16:17:21  #152 №341397 
Аноним Втр 10 Дек 2013 07:35:09  #153 №341558 

>>341382
а это всё потому что на clojure не пишут

Аноним Втр 10 Дек 2013 09:22:52  #154 №341563 

>>341558
На кложуре оно на руку не влезет...)

Аноним Втр 10 Дек 2013 13:24:07  #155 №341595 

>>341558
Неужели здесь кто-то кроме меня форсить Кложу? Приятно удивлён.

Аноним Втр 10 Дек 2013 13:29:59  #156 №341596 

>>341595
нахуй иди чмо, удивлён он блять, посцал на тебя.

Аноним Втр 10 Дек 2013 23:55:35  #157 №341807 

>>341382
>Внутри процессов нормальные люди просто используют BlockingQueue
В смысле? Обмен сообщениями через очереди вместо прямых вызовов? Но в этом же и заключается модель акторов. На самом деле, таких "нормальных людей" в вджава мире можно по пальцам пересчитать.
>>341380
>Дедлок там делается так же как и везде - актор "а" ожидает сообщение "x" от актора "б" (все остальные сообщения признаются в данном состоянии некорректными либо игнорируются, не в курсе деталей семантики), актор "б" ожидает сообщения "y" от актора "а".
Гайдлайны осуждают написания акторов, ожидающих конкретного сообщения (имеющих состоянии из которого может вывести только одно сообщение), актор в каждом своем цикле должен реагировать на любые (валидные) сообщения из очереди. Конечно, никто не может помешать обезъяне написать логику с взаимными ожиданиями, но
>Ну или приведи пример, в котором на обычной парадигме будет кровь-кишки-распидорасило, а акторы как-то решат проблему.
Классика жанра: два взаимоожидающих потока упираются в синхроблок и виснут. Акторы продолжают работать, реагируют на другие сообщения. Задача, вызвавшая взаимную зависимость, конечно, остается не решенной, но потоки не блокируются, обработка сообщений продолжается и внешний супервизор может даже разрешить взаимную блокировку путем посылки спец.сообщения, выводящего акторы из состояния ожидания.
>>341380
>там везде внутри LOCK XCHG [хуй], пизда
Это происходит конкретно в Atom в ConcurrentLinkedQueue, знаем, знаем.
Блокировки шины на один такт - это же самый правильныйЪ метод межпотокового взаимодействия, никаких циклов, никаких ожиданий. Теперь сравни это с ожиданиями на мьютексах в синхроблоках.

Ты наверно знаешь пример реализации межпотокового взаимодействия без блокировок вообще (даже шины)? Поделись же с нами, как это работает?

Аноним Срд 11 Дек 2013 00:16:00  #158 №341815 

>>341335
>Когда на жвм делают асинхронщину, то заводят пул потоков и используют форк-джойн
Совсем не обязательно через ForkJoin. Есть еще старый добрый ThreadPoolExecutor. Хотя, по сути, это те же яйца, вид сбоку.>>341335
>Но вполне возможен отсос, когда все трэды из пула зохватили таски с бесконечными циклами, и новые таски не выполняются.
Тут есть два варианта:
1. Зависло конечное число потоков и новые зависающие не порождаются.
- Тут пул (например, такой Executors.newCachedThreadPool()) может выдержать. Если планировщик, выполняемый в отдельном потоке, заметит эту ситуацию (таймера никто не отменял) он точно так же может засуспендить или поубивать зависшие потоки и пересоздать соответствующие задачи.
2. Зависающие задачи продолжают порождаться бесконечно.
- Тут не спасет ни какая реализация планировщика и никакая вытесняющая многозадачность. Через несколько секунд неизбежно переполнение стека или зависание.

Аноним Срд 11 Дек 2013 01:48:47  #159 №341837 

>Ты наверно знаешь пример реализации межпотокового взаимодействия без блокировок вообще (даже шины)? Поделись же с нами, как это работает?


В Танненбауме есть алгоритм для двух потоков. Я это как-то обдумывал. В голове есть схема, которая даже должна работать, но в ней придется если не шину блокировать, так пихать кучу volatile, а это "иди нахрен, кэш".

Аноним Срд 11 Дек 2013 03:03:33  #160 №341847 

>>341807
>Гайдлайны осуждают
пиздец. А еще гайдлайны осуждают выделение памяти без её освобождения да и вообще написание быдлокода.
>Классика жанра: два взаимоожидающих потока упираются в синхроблок и виснут. Акторы продолжают работать
Да я уже понял, что никаких конкретных примеров не понял, только гуманитарная хуита и маркетинговый булшит. Расходимся, поцоны.

Аноним Срд 11 Дек 2013 03:06:58  #161 №341849 

>>341847
fix >никаких конкретных примеров не будет
>Теперь сравни это с ожиданиями на мьютексах в синхроблоках.
А нечего сравнивать, лол.

Аноним Срд 11 Дек 2013 04:08:05  #162 №341857 

>>341849
>А нечего сравнивать, лол.
Или ты не понимаешь во сколько раз

synchronized { }[/coode][/b] медленнее, чем [b][code]AtomicInteger.getAndSet()[/code][/b] или тебе просто нечего сказать?

sageАноним Срд 11 Дек 2013 04:10:53  #163 №341858 

>>341857
Абу, ты хоть знаешь, что у тебя жопа вакабы ?

Аноним Срд 11 Дек 2013 04:34:09  #164 №341863 

>>341837
1. Где конкретно у Таненбаума ? Или сам алгоритм приведи.
2. Ванга говорит, что в точке синхронизации там должен быть цикл в котором он "ждет" (у него может быть другой смысл, но сам цикл должен быть) другой поток.
3. Если Ванга права, то это фэйл. Потому что в ConcurrentLinkedQueue нет циклов (даже на уровне машинного кода) ни при записи ни при чтении из очереди.

Аноним Срд 11 Дек 2013 10:17:30  #165 №341879 

>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

Аноним Срд 11 Дек 2013 11:59:17  #166 №341914 

>>341807
> >Внутри процессов нормальные люди просто используют BlockingQueue
> В смысле? Обмен сообщениями через очереди вместо прямых вызовов? Но в этом же и заключается модель акторов.
Разница в том, что в случае с очередями вся логика остаётся линейной и сосредоточенной в одном месте, в отличие от акторов, где логику нужно дробить на кусочки и разбрасывать по ивент-хэндлерам. А когда логика ещё и недокументирована, то обратно её собирать из кусочков заёбывает.
> На самом деле, таких "нормальных людей" в вджава мире можно по пальцам пересчитать.
Увы, ты совершенно прав. Говнокодеры евривэа.

Аноним Срд 11 Дек 2013 13:30:24  #167 №341933 

>>341914
> вся логика остаётся линейной и сосредоточенной в одном месте

Вообще-то дробление монолита на минимальные объекты с единой ответственностью - это правильно, и лежит в рамках любой нормальной парадигмы.

>разбрасывать по ивент-хэндлерам
Код по прежнему остается линейным.
Это тебе не ивент-дривен ноджеесо-подобная колбек-дрисня.
Ивент-дривн акторы, пиздец какой-то, только поверх уебищной jvm такую хуйню можно было написать.

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

Аноним Срд 11 Дек 2013 13:31:21  #168 №341934 

>>341857
>Или ты не понимаешь во сколько раз synchronized { }[/coode][/b] медленнее
Да, понимаю: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=chameneosredux&lang=all&id=1&data=u64q - задача на конкурентность - Erlang в 81 раз медленнее, Scala - Failed.

Аноним Срд 11 Дек 2013 14:31:06  #169 №341946 

>>341863
>в ConcurrentLinkedQueue нет циклов
http://fuseyism.com/classpath/doc/java/util/concurrent/ConcurrentLinkedQueue-source.html
на 190 строке что, хуесос ты эдакий?

Аноним Срд 11 Дек 2013 18:49:51  #170 №342055 

>>341934
>Scala - Failed.
Ты в глаза ебешся?
>

22	Scala #2 	41.02	13.56	57,564	1171	  77% 82% 74% 74%

Скала = x 22 Почти в 4 раза быстрее ерланга.
И где теперь твой бог?



Аноним Срд 11 Дек 2013 19:28:53  #171 №342065 

>>341934
Который раз убеждаюсь, что бенчмарки для языкосрачей пишут полные уебки не могущие не в один из языков. Вот и пример: код на скала http://benchmarksgame.alioth.debian.org/u64q/program.php?test=chameneosredux&lang=scala&id=2 - это же машинный перевод дешевый рерайт джава-кода! И что теперь показывает этот бенчмарк? Угол кривизны пальцев индуса? Или жлобство манагера, который решил сэкономить на кодерах?

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

Аноним Срд 11 Дек 2013 20:12:30  #172 №342083 

>>341946
Внимательнее на него посмотри. Этот цикл имеет номинальное значение. Это не обход очереди/списка. Практически он должен выйти по return на первой же итерации. Уход на вторую итерацию возможен только в ситуации конкуренции потоков за значения head tail внутри функций poll и offer. Это означает, что вероятность ухода на вторую итерацию равна Tвнутри / Tобщее; где Tвнутри - время проведенное внутри функций poll и offer, Tобщее - полное время работы всей программы. Т.е. на практике это может быть около 1/1000000.

Аноним Срд 11 Дек 2013 20:15:39  #173 №342086 

>>342065
Стандартная либа скалы написана в таком же императивном стиле. Пруф https://raw.github.com/scala/scala/master/src/library/scala/collection/immutable/List.scala

Аноним Срд 11 Дек 2013 20:38:09  #174 №342090 

>>342086
Мутабильные локальные переменные - ты об этом что ли? Так это не говнокод, а низкоуровневая оптимизация, которая применяется только в самых тонких (по быстродействию) местах. Совсем другое дело - мутабильные публичные свойства классов - в культурном обществе за такое пиздят ссаными тряпками.

Аноним Чтв 12 Дек 2013 00:47:16  #175 №342239 

>>342055
Только там нихуя не акторы, а старый добрый synchronized, про который местный говноиксперт пиздел, что он якобы медленнее.

Аноним Чтв 12 Дек 2013 00:50:53  #176 №342243 

>>342065
>это же машинный перевод дешевый рерайт джава-кода!
конечно, ведь попытки писать на джаве в функциональном стиле выльются в тормоза и переполнение стека.

Аноним Чтв 12 Дек 2013 00:53:56  #177 №342245 

>>342083
>цикл имеет номинальное значение.
гуманитарии совсем охуели

Аноним Чтв 12 Дек 2013 01:10:36  #178 №342252 

>benchmarksgame
Блять, любая ссылка на это говно должна наказываться тугой струи мочи прямо в лицо долба использующего её для подкрепления какого либо утверждения.

Аноним Чтв 12 Дек 2013 01:16:10  #179 №342256 

>>342252
Ололо, как у анонимных икспертов бомбануло-то!

Аноним Чтв 12 Дек 2013 02:02:03  #180 №342268 

>>342243
КО-КО-КОНЕЧНО, как обычно - толсто, зелоно, голословно и без пруфов. Через пару постов ты объявишь, что всех затролил. Все кто не согласны - скам и быдло.
>>342245
Гуманитарий начинает кукарекать раньше, чем попытается разобраться в сути вопроса.
>>342256
Ну, отчасти этот толстяк прав, benchmarksgame - очень сомнительная контора РогаИКопыта™.

Аноним Чтв 12 Дек 2013 02:46:24  #181 №342275 

Кто-нибудь хотя бы читал этот высер 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'ы и другие функциональные выебоны, которые ту все равно выглядят как гавно. Такое ощущение, что автор не осилил книжку Одерси даже до середины.
Итог: Тест очевидно заказной. Код явно был заказан группе школьников (один не осилит же), чтобы обосрать скалу (может и другие языки) и протолкнуть вверх какого-то своего кандидата.

Аноним Чтв 12 Дек 2013 03:16:36  #182 №342281 

>>342268
>толсто, зелоно, голословно и без пруфов
Анонимному хуесосу дали ссылку на бенчмарк, который по очевидным причинам был написан на джаве, анонимный хуесос сказал, что бенчмарк - говно. Анонимному хуесосу дали ссылку на стандратную либу, анонимный хуесос сказал, что стандартная либа не показатель. Анонимному хуесосу сказали что он хуесос - анонимный хуесос сказал, что толсто, зелоно, голословно и без пруфов. Разумеется у самого анонимного хуесоса полно прувов, но только мы их не увидим, ведь одно авторитета анонимного хуесоса уже достаточно, чтобы опровергнуть любые доказательства в виде бенчмарков и рельного кода.
>Гуманитарий начинает кукарекать раньше, чем попытается разобраться в сути вопроса.
Вот я вижу, что ты, питух, кукарекаешь, не понимая, как работают неблокирующие алгоритмы.
>benchmarksgame - очень сомнительная контора РогаИКопыт
Конечно, куда менее сомнительно пиздеть на двачах, не приведя ни строчки кода и не сделав ни одного замера.

Аноним Чтв 12 Дек 2013 03:21:26  #183 №342283 

>>342275
Напиши лучше, мы посмотрим, чей будет работать быстрее. Что, обосрамс? Ну да, скалоблядки соснули, опять.

Аноним Чтв 12 Дек 2013 03:44:46  #184 №342291 

>>342281
>Конечно, куда менее сомнительно пиздеть на двачах, не приведя ни строчки кода и не сделав ни одного замера.
Ой, кот бы говорил! Сам то много строчек своего кода сюда запостил?
Есть дела поважнее. Почему я это должен, это ты должен. Ко-ко-ко.

Аноним Чтв 12 Дек 2013 03:51:25  #185 №342292 

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

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

Аноним Чтв 12 Дек 2013 04:09:17  #186 №342295 

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

Аноним Чтв 12 Дек 2013 04:14:01  #187 №342298 

>>342292
Просто выложи код, чтобы каждый мог взять его, запустить дома (заодно осознать все прелести развёртывания джаваговна), и убедиться, что скала тормозит (максимум, что выжали уже на shootout-е), писать на ней в функциональном стиле нельзя (ибо jvm для этого не предназначена), и акторы никак не могут быть быстрее обычных блокировок.

Аноним Чтв 12 Дек 2013 04:14:11  #188 №342299 

>>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(" ")
это конечно короче но алгоритм почти тот же.

Аноним Чтв 12 Дек 2013 04:15:52  #189 №342301 

>>342292
Кроме того, если ты пришлёшь им свой вариант, и он окажется быстрее, они его выложат на сайте.

Аноним Чтв 12 Дек 2013 04:15:59  #190 №342302 

>>342299
> 5123.toString.map { c => Numbers(c.asDigit) }.mkString(" ")
fix

Аноним Чтв 12 Дек 2013 04:19:02  #191 №342303 

>>342295
>Аутист не чувствует inb4
>Сам себе отвечал => cам себя обосрал

Аноним Чтв 12 Дек 2013 04:35:07  #192 №342305 

>>342303
Засчитан.

Аноним Чтв 12 Дек 2013 08:39:33  #193 №342311 

>>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(" ")
}

Аноним Чтв 12 Дек 2013 10:06:22  #194 №342316 

>>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.
А жалко, хотелось показать преимущества неблокируемых потоков, но для этого нужна другая задача.

Аноним Птн 13 Дек 2013 00:00:13  #195 №342576 


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" }

Аноним Птн 13 Дек 2013 09:11:48  #196 №342679 

Полон тред пидорасов.
Почему так?

Аноним Птн 13 Дек 2013 12:11:01  #197 №342692 

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

Аноним Птн 13 Дек 2013 15:16:00  #198 №342717 

ракуем, сегодня мы с тобой ракуем

sageАноним Птн 13 Дек 2013 15:17:27  #199 №342718 

эх, сажа отклеилась

Аноним Птн 13 Дек 2013 18:24:11  #200 №342768 

>>342717
раковать, тебя хочу я раковать

Аноним Птн 13 Дек 2013 21:35:10  #201 №342806 

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

Аноним Птн 13 Дек 2013 22:49:10  #202 №342824 

>>342806
Нужна задача с вычислительной нагрузкой (типа распределенных (локально) вычислений) и межпотоковым взаимодействием. Возможно подойдет какая-нибудь задача на map/reduce (только такие задачи решаются слишком просто через параллельные коллекции, там за нас уже почти все уже написали). Самое главное - должно иметься эталонное решение ( можно на джава) с классической синхронизацией потоков и блокировками. Без него будет не с чем сравнивать. А сам я (месить говно) писать такое не собираюсь.

Аноним Суб 14 Дек 2013 00:36:12  #203 №342845 

>>342824
Глобальная оптимизация, как пример

Аноним Суб 14 Дек 2013 02:28:21  #204 №342855 

>>342845
Нужно конкретно сформулированное условие. Задача должна быть не слишком тяжелой, чтобы писалась за хотя бы пол дня. Ну и готовое решение с блокирующими(ся) потоками для сравнения.

почему так можно? Аноним Суб 14 Дек 2013 18:58:16  #205 №342945 


trait test {
def number: Int
}

val n = new test { val number = 5}


Аноним Суб 14 Дек 2013 19:11:16  #206 №342950 

>>342945
потому что джава головного мозга

Аноним Суб 14 Дек 2013 19:13:10  #207 №342952 

>>342950
Охуенно полезный ответ, спасибо, теперь все стало понятно.

Аноним Суб 14 Дек 2013 19:18:54  #208 №342954 

>>342952
что ты хотел увидеть? простой и логичный ответ? это не к жвм-опущенным.

Аноним Суб 14 Дек 2013 20:37:05  #209 №342970 

>>342945
А почему должно быть нельзя?

Аноним Суб 14 Дек 2013 20:42:01  #210 №342971 

>>342970
Это же трейт, его нельзя инстанцировать вроде как. Я, конечно, вижу, что тут не просто создание экземпляра класса, но нигде не нашел про этот синтаксис трейтов.

Аноним Суб 14 Дек 2013 21:16:56  #211 №342979 

>>342971
это создание анонимного класса

Аноним Суб 14 Дек 2013 21:21:56  #212 №342981 

>>342945
Это простой override. Когда val перекрывает def 'это ключевое слово слово не требуется.
>>342971
Инстанциируется не сам трэйт, а анонимный класс, неявно описанный в точке, в которой он же инстанциируется. Класс наследует интерфейс трэйта (обязательное наличие метода/поля), но переопределяет его реализацию. Любой субкласс может переопределять любую родительскую реализацию, если только она не final.

Аноним Суб 14 Дек 2013 21:23:54  #213 №342983 

>>342824
>Нужна
Ну так приведи пример такой задачи. Ты же собрался доказывать, что акторы - не очередной псевдонаучный высер вроде ООП, а что-то имеющее реальную практическую ценность.

Аноним Суб 14 Дек 2013 21:36:00  #214 №342988 

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

Аноним Суб 14 Дек 2013 21:37:59  #215 №342990 

>>342988
Т.е. вбросил и тут же слился? Типично для скалкошкольников.

Аноним Вск 15 Дек 2013 09:03:42  #216 №343089 
Аноним Вск 15 Дек 2013 18:33:13  #217 №343127 

>>343089
что за хуй на пике?

Аноним Вск 15 Дек 2013 18:40:16  #218 №343130 

>>343127
Дима Гамбургер.

Аноним Вск 15 Дек 2013 21:39:21  #219 №343156 

>>343127

Why I Don"t Like Akka Actors Аноним Чтв 19 Дек 2013 10:25:11  #220 №343963 

http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/

Почему Мне НЕ нравится AKKA Акторы (4 марта 2013)

Мы недавно переписали бэкэнд в Майна. Архитектура резко изменилась, стала быстрее и легче расширяема. Одним из значительных архитектурных изменений было удаление всех акторов Акка. После значительного использования их в первой версии серверной части, я перешел к другим методам управления параллелизмом. Поскольку акторы Акка занимают столь видное место в рамках сообщества Scala, я думаю, что это [статья] может представлять интерес для объяснения причин, сделанных нами изменений.

Why I Dont Like Akka Actors Аноним Чтв 19 Дек 2013 10:26:43  #221 №343964 

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 предоставляет, например. Если вы действительно ищете производительности, то вы, вероятно, хотите использовать неблокирующие алгоритмы. Опять же, это не вписывается в модель акторов. В основном модель акторов вынуждает нас отказаться от многих инструментов, чтобы мы могли вписываться в жесткие концепции ее параллельной программы.

Why I Dont Like Akka Actors Аноним Чтв 19 Дек 2013 10:27:53  #222 №343965 

http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/

2. Акторы не пригодны для композиции (compose).

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

Акторы не пригодны для композиции. По умолчанию в актор жестко закодирован (hard-coded) приемник (receiver) сообщений, отправленных им. Если я создаю актор А, который отправляет сообщение актору B, и вы хотите изменить принимающий актор на C, то вам не повезло. Если вам повезет я ожидал это заранее и предусмотрел соответствующую настройку, но более вероятно, что вам придется переписывать исходник. Отсутствие возможности композиции затрудняет создание больших систем из мелких.

Why I Dont Like Akka Actors Аноним Чтв 19 Дек 2013 10:29:40  #223 №343966 

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.

Аноним Чтв 19 Дек 2013 11:13:05  #224 №343975 

>>343966
В брось перевод на хабр. Там у некоторых должно хорошо бомбануть.

Аноним Чтв 19 Дек 2013 11:35:26  #225 №343976 

>>343975
>Вбрось

Аноним Чтв 19 Дек 2013 18:59:50  #226 №344038 

>>343975
>>343975
>должно хорошо бомбануть.
Ога. Бомбануть по твоей карме.
У этих хомячков сильней всего развит стадный инстинкт.

Аноним Чтв 19 Дек 2013 22:07:15  #227 №344082 

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

Аноним Птн 20 Дек 2013 03:37:51  #228 №344160 

>>344082
Ищешь таблетку от всех болезней - обратись в герблайф.
>гораздо более легковесного программного обеспечения
Для начала - определение "тяжести" ПО - в студию.
>универсальные структуры данных имеют право на жизнь
А где они не имеют такого права? И при чем тут структуры данных, когда речь о парадигмах параллелизма.
>выборе между хеш-табличкой и бинарным деревом - не имеет значения
У меня от этого АЛГОРИТМИЧЕСКАЯ СЛОЖНОСТЬ.

Аноним Птн 20 Дек 2013 06:35:44  #229 №344175 

>>344160
Если уж мы о таблеточках, то ты хотя бы глицинчику выпил, перед тем как. А то чувствуется зимний авитаминоз.
> Для начала - определение "тяжести" ПО - в студию.
Зависит от следующего: 1) тиража 2) срока жизни, и следующей из этого, необходимости/отсутствия необходимости в его поддержке 3) Требованиями по производительности/гарантиям/допускам.
> А где они не имеют такого права? И при чем тут структуры данных, когда речь о парадигмах параллелизма.
Внимательно прочитай свои сообщения еще раз.
> У меня от этого
см. пик.

Аноним Птн 20 Дек 2013 18:43:20  #230 №344405 

>>344175
Тиреч умер.

Аноним Суб 21 Дек 2013 01:34:22  #231 №344505 

>>344175
>"тяжесть" ПО зависит от
>1) тиража
Выбрасываем на свалку все, чем пользуются больше, чем 3.5 анонимуса + обмазываемся НЕХ + ощущаем свою элитарность + прокачиваем ЧСВ + кушаем борщи + слушаем инди + обсираем попсу = ПРОФИТ (кому только?)
>2) срока жизни, и следующей из этого, необходимости/отсутствия необходимости в его поддержке
Легкого ПО = Коротко живущее (?)
>3) Требованиями по производительности/гарантиям/допускам.
Скорость/гарантии(качество)/приятная_цена - выбирай 2 из 3

Вообще не плохо бы с примеров каких-то начать.
У тебя к легким что относится? Эрланг А к тяжелым?

sageАноним Суб 21 Дек 2013 04:24:45  #232 №344539 

>>344505
> Выбрасываем на свалку все, чем пользуются больше, чем 3.5 анонимуса + обмазываемся НЕХ + ощущаем свою элитарность + прокачиваем ЧСВ + кушаем борщи + слушаем инди + обсираем попсу = ПРОФИТ
м?
> Легкого ПО = Коротко живущее (?)
м?
> Скорость/гарантии(качество)/приятная_цена - выбирай 2 из 3
м?
> Вообще не плохо бы с примеров каких-то начать.
Что ты собрался "начать"?

Аноним Суб 21 Дек 2013 10:42:15  #233 №344570 

>>344539
>м?
>м?
>м?
Переведите кто-нибудь это мычание на человеческий язык.

Аноним Суб 21 Дек 2013 11:21:26  #234 №344572 

>>344570
>Ко-ко-ко! Кукареку! Кудкудах!
Перевёл на язык, понятный тебе.

Аноним Суб 21 Дек 2013 11:46:33  #235 №344577 

>>344572
>Ко-ко-ко! Кукареку! Кудкудах!
Одно быдло мычало, второе закукарекало.
/pr, /pr never change.

Аноним Чтв 26 Дек 2013 18:16:46  #236 №346306 

http://benchmarksgame.alioth.debian.org/u32q/which-programs-are-fastest.php

Кто тут у нас в первом столбце идет? Ба! Неужели?

Аноним Чтв 26 Дек 2013 20:22:44  #237 №346340 

>>346306
Сколько можно обсасывать этот парашаметр?
Забыли сколько неугодных бенчей байтоебанутый автор выбросил из рассмотрения?
Так что ничего кроме фантазий прыщебляди на этих картиночках вы не увидите.

Аноним Чтв 26 Дек 2013 20:35:01  #238 №346348 

>>346340
На самом деле, на этой картиночке действительно хуй-пойми-что, но посмотреть на конкретные ЯП-ЯП сравнения смысл есть.

Аноним Чтв 26 Дек 2013 23:18:34  #239 №346441 

>>346306
>Кто тут у нас в первом столбце идет?
Верхняя таблица для инвалидов, в нижней на первом месте сишечка, что ожидаемо.

Аноним Птн 27 Дек 2013 03:01:49  #240 №346485 

>>346340
> неугодных бенчей байтоебанутый автор выбросил из рассмотрения
Подробнее.

Аноним Птн 27 Дек 2013 05:06:01  #241 №346508 

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

Аноним Птн 27 Дек 2013 20:00:20  #242 №346683 

>>346508
>за попытку читерства
А ты сам то читал условия этих задач. Там не считить намного ложнее, чем решить саму задачу. Например http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=chameneosredux#about тут требуется чтобы каждый "зверь" (простой объект с внутренним состоянием, асинхронно взаимодействующий с себе-подобными) жил в отдельном потоке ОС. Абсолютно идиотское требование, отсекающее самые красивые решения на неблокирующих очередях и убивающие смысл всего соревнования. Результат зависит на 90% от реализации планировщика задач ОС и на 10% от самого кода.

Аноним Птн 27 Дек 2013 20:29:46  #243 №346686 

>>346683
>Абсолютно идиотское требование
Совершенно правильное требование
>самые красивые решения на неблокирующих очередях
Это все НЕНУЖНО
Быдломрази должны страдать потому что пишут не на Хаскель.
Стасик

Аноним Птн 27 Дек 2013 20:50:43  #244 №346688 

>>346686
Быдломрази должны страдать потому что употребляют мое имя всуе.
Хаскель

Аноним Птн 27 Дек 2013 21:05:33  #245 №346690 

>>346688
Иди нахуй, мразь.
Стасик

Аноним Птн 27 Дек 2013 22:08:31  #246 №346752 

>>346690
Но ведь мы созданы друг для друга.
Хаскель

Аноним Птн 27 Дек 2013 22:26:39  #247 №346767 

>>346686
>НИНУЖНО
С каких пор ты начал писать это слово через Е?

Аноним Птн 27 Дек 2013 22:29:23  #248 №346769 

>>346767
Хуй соси.
Стасик

Аноним Суб 28 Дек 2013 14:39:55  #249 №346929 

>>346769
>Хуй соси, Стасик

http://www.lingvotech.com/znaki_prepinaniya_pri_obrashchenii

>3. Если обращение стоит в конце предложения, перед обращением ставится запятая, а после него — тот знак, который нужен по смыслу предложения.

Аноним Суб 28 Дек 2013 18:08:03  #250 №346966 

Итак, господа. На данный момент есть четыре парадигмы для конкурентного программирования.
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 это наше все.

sageАноним Суб 28 Дек 2013 19:09:10  #251 №346986 

>>346966
С смого начала поста было такое ощущение, что автор - телепетушок. Так и вышло.

Аноним Вск 29 Дек 2013 01:30:33  #252 №347105 

>>346966
Ну вот и дождались, адекватный Программист заглянул ИТТ (а то надоело уже гонять ссаными тряпками всяких стасиков) В целом вполне хардкорное пояснение. Ну под конец не смог удержаться от пиара своего ершланга, в результате перепутал две верхние ступеньки пирамиды. Акторы, конечно, ссут сверху вниз на все прочие concurrent поделия (на счет stm - спорно; оно как бы для другого применения в основном, но если использовать его как панацею от всего, то выйдет решение не намного лучше классических блокировок). Только ты совсем упустил, что
futures/promises - это такой проапгрэйженный вариант акторов, в котором пофисины все их хронические болезни и запилена ключевая фитча - композиция. И так сравним:
Любой небыдлокодер понимает, что возврат значения (или void) из функции должен осуществляться в одной точке. Любые варианты break - тот же goto по сути, запутывание потока данных, запутывание логики, ерись, гроб, гроб, кладбище. Поэтому все современные ЯВУ принуждают функции возвращать ровно одно значения заданного типа (пусть даже void), а не выходить во множестве точек с любыми значениями (быдлокодеры конечно и тут придумали себе break и return). Аналогом функций из однопоточного мира, в многопоточном мире является асинхронный блок (future или актор). Теперь видно, что future - прямой аналог функции с одной точкой входа и одной точкой выхода. Актор похож на кусок ассемблерного кода, который не имеет точки выхода, а совершает прямые прыжки в другие куски кода, все адреса переходов жестко закодированы и не могут быть выяснены/изменены снаружи функции этого куска, предсказать куда перейдет управление после выполнения этого куска не возможно. Получаем старую знакомую goto-парашу, абсолютно не_функциональный подход, в этом вся суть акторов, выходит они и есть "GOTO нашего времени". В противовес им, future - истинная функция, объект первого класса (эта мелочь решает все, для тех, кто в теме), на этом основаны все их свойства, включая композицию (См. >>343965), которая дает магическую силу ФП.

Аноним Вск 29 Дек 2013 02:38:00  #253 №347138 

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

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

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

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

Аноним Вск 29 Дек 2013 12:24:48  #254 №347236 

>>347138
Дополню себя.
Актор не является функцией и не должен ей быть. Актор ничего не возвращает, у него нет return etc. Это бредовое мышление. Именно люди с таким мышлением проебали замечательную смолтолковую идею, заменив message passing на вызов метода в погоне за желанием специфицировать объекты.
Единственный способ воздействия на актора - посылка сообщения и все, это совершенно не тоже самое что вызов функции. Актор пославший сообщение никак не может отслеживать его состояние, прохождение и так далее, для актора вообще нихуя не существует, кроме его черной коробки. Получение ответа,- другое сообщение, совершенно новое событие. Именно такая схема позволяет строить системы, где смерть одного нейрона не приводит к парализации всего мозга.

Аноним Вск 29 Дек 2013 16:55:44  #255 №347337 

>>346966
Несмотря на пафосный пердеж по параллельность и конкурентность, эрланг где-то в 6 раз медленней джавы на многоядерных процессорах http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=hipe&lang2=java&data=u64q

Аноним Вск 29 Дек 2013 17:05:49  #256 №347341 

>>347337
>benchmarksgame
Дальше не читал. За любую ссылку на эту хуйню надо бить с разбега в ебальник.

Аноним Вск 29 Дек 2013 17:32:01  #257 №347360 

>>347341
Лол, типичный религиозный фанатик - живёт в воображаемом мирке, отрицает неугодные его религии факты, зашорен, агрессивен.

Аноним Вск 29 Дек 2013 17:44:55  #258 №347369 

>>347360
Привел ссылку на сомнительный ресурс, был по-делом обоссан, что-то продолжает кудахтать в ответ. Вся суть явадебилов.

Вот тебе тоже бенчмарк, раз ты так на них дрочишь.
http://eric.themoritzfamily.com/websocket-demo-results-v2.html

Можно ещё наковырять в сети как openfire всасывает у ejabberd, а Cassandra и HBase у Couchdb и Riak, да только хули на тебя дебила время тратить.

Аноним Вск 29 Дек 2013 18:04:27  #259 №347383 

>>347360
В догонку поясни, почему кресто-яваблядксий AMQP QPID так всасывает на средних и крупных сообщениях у RabbitMQ?

http://x-aeon.com/wp/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/

Аноним Вск 29 Дек 2013 18:49:10  #260 №347410 

>>347369
>Привел ссылку на сомнительный ресурс
Сомнителен о тем, что там эрланг всасывает? Я же говорю, что религиозным фанатикам и прочим креационистам свойственно отрицать неугодные им факты.
>Вот тебе тоже бенчмарк, раз ты так на них дрочишь.
И что показывает этот бенчмарк, что именно там сравнивается?
>В догонку поясни, почему кресто-яваблядксий AMQP QPID так всасывает на средних и крупных сообщениях у RabbitMQ?
Перед тем как копаться в дебрях AMQP QPID и всего того, что там намерил у себя в блоге неизвестный товарищь, давай разберёмся, почему таки Эрлан соснул в минимум в 6 раз на всех задачах публичного бенчмарка? Заметь, я ведь не говрю, что AMQP быстрее, чем RabbitMQ, я просто говрю, что Эрланг в 6 раз медленней джавы, и никто с этим ничего сделать не может.

Аноним Вск 29 Дек 2013 19:05:45  #261 №347417 
Аноним Вск 29 Дек 2013 19:11:46  #262 №347418 

>>347410
>публичного бенчмарка
Где я могу посмотреть исходники кода участвующего в сравнениях?

Ява-хуява на шутауте с отключенным GC всегда такая охуенная, только вот в продакшне - тормозное говно, потому что JVM - параша.

Сравнивать ЯП по синтетическим бенчмаркам, это же вообще пиздец.

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

На однотредовых приложениях, говно вопрос, эрланг медленнее jvm, в условиях же агрессивной многопоточности jvm уже на 1000 тредах смотрит в сторону свопа, а на 10000 зарывается от прохода GC. Если добавить сюда задачи распределенности, то яваговно неспособно линейно отмасштабироваться даже на два узла.

Аноним Вск 29 Дек 2013 19:16:54  #263 №347421 

>>347417
На однотредовых приложениях, разумеется.

Аноним Вск 29 Дек 2013 19:22:34  #264 №347423 

>>347421
>сравнивает нативные треды с грин тредами

Аноним Вск 29 Дек 2013 19:26:07  #265 №347425 

>>347417
Более того, R1304, это 2010 год, если не ошибаюсь, ERTS и сама VM с тех пор столько изменений претерпели; все старее R15 вообще рассматривать сейчас глупо.

Аноним Вск 29 Дек 2013 22:39:35  #266 №347483 

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

Аноним Вск 29 Дек 2013 22:54:29  #267 №347486 

>>347425
>>347421
Весь фокус в подмене понятия "тред". Давай назовем "тредами" ForkJoinTask (которые, между прочим, лежат под капотом у Акка), напишем синтетический тест измеряющий скорость их порождения/завершения (в качестве полезной нагрузки - пустая заглушка). Бедный эрланг уползет под стол при виде таких бэнчей. Остается только один вопрос - каков физический смысл таких "тредов" и что мы на в действительности только что измерили?

Аноним Пнд 30 Дек 2013 01:12:13  #268 №347496 

>>347486
Тред в эрланге - гринтред внутри VM, но со своим стеком и своим хипом и приоритетом. Скедулер организует их вытеснение внутри каждой VM, а ERTS их миграцию между VM.

Создается ~3 мкс, весит на начальной стадии 500 байт.

Теперь давай расскажи, есть ли подобное в JVM, где все говно лежит в одном хипе, а объекты внутри инстанса передаются только по ссылке.

Акка - inspired by Erlang костыль для уебищной JVM.

Аноним Пнд 30 Дек 2013 17:15:01  #269 №347588 

>>347496
>Создается ~3 мкс
охуительное достижение

Аноним Пнд 30 Дек 2013 17:33:00  #270 №347593 

>>347496
Хипсторы - удивительные люди. Если ты не в курсе, зеленые потоки в жабе впервые и появились. Только делались они исключительно чтобы потоки работали на платформах, которые не поддерживают нативные. А потом пришли всякие эрлангобляди и гобляди, усмотрели в этом великую конспирацию ("не могли они сделать зеленые потоки для совместимости! наверное, они быстрее!") и стали выдавать костыль как килер-фичу. Поразительно. Хотя особенно смешно, когда эти же люди кукарекают про GIL в гвидоне, как будто их парашные недопотоки ОС по ядрам может раскидать.

Аноним Пнд 30 Дек 2013 17:49:33  #271 №347601 

>>347593
>> треды внутри VM
> недопотоки ОС

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

Ясно, ты ибецил.

Аноним Пнд 30 Дек 2013 17:56:57  #272 №347606 

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

их недопотоки
недопотоки парашные
ос может раскидать
раскидать по ядрам
раскидать недопотоки

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

Аноним Пнд 30 Дек 2013 18:12:43  #273 №347612 

>>347606
>раскидать по ядрам
>ос

На каждом ядре по VM, и ERTS организует распределение и миграцию тредов между ними. На каждом ядре скедулер организует равномерное распределение выделенного процессорного времени между тредами.

Иди лучше уроки делай, долбоеб обсосанный.

Аноним Пнд 30 Дек 2013 18:23:21  #274 №347617 

Скрипя сердцем, обсосал я долбоёба.

Аноним Пнд 30 Дек 2013 18:31:21  #275 №347620 

>>347593
>ОС
>по ядрам может раскидать

Для ОС эрланговские треды и не существуют, блять, что она будет раскидывать, ебан штоле?

Треды живут только внутри инста. Как процесс ОС висят только процессы VM'ов, и их по одному на ядро.

Аноним Пнд 30 Дек 2013 19:59:00  #276 №347637 

>>347593
лил

Аноним Втр 31 Дек 2013 01:06:20  #277 №347669 

>>347496
>Скедулер организует их вытеснение внутри каждой VM, а ERTS их миграцию между VM.

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

Аноним Втр 31 Дек 2013 01:39:27  #278 №347673 

>>347669
>наверняка
Петухан диванович экспертов во всей красе.
Переключение контекста, юзермод, кернелмод - ВЕДЬ ВСЕ ЭТО ЗНАТЬ НИНУЖНО ВСЕ ЭТО НИВАЖНО.
Стасики, стасики never change.

Аноним Втр 31 Дек 2013 01:44:02  #279 №347674 

>>347138
>каждый процесс сам по себе чист. Единственный побочный эффект - сообщения
/0
>По композабельности, в OTP есть готовые механизмы заключения акторов в иерархии и установления цепочек связей между ними. Так же есть способы обернуть посылку/примем сообщения в функцию.
В этом случае актор принуждаестя к возврату сообщения отправителю?
Да = Та же модель futures/promises, те же яйца, вид сбоку.
Нет = Что происходит с отправителем, которому не ответили? Он зависает? Зачем тогда вообще нужны такие "функции"?
>Но главное, - отправитель чаще всего ничего не ждет в ответ, гарантии чего либо не нужны.
Как что-то хорошее.
>В этом и проблема promise/future, они слишком друг на друга рассчитывают
Так и должно быть, они же части одного алгоритма (или элементы одной бизнес логики). Проверка в рантайме многих (все проверить не возможно) нештатных ситуаций - лишний код + возможность упустить какой-то вариант, сложность локализации ошибок, большой оверхер рантайма. Короче - все "прелести" динамических языков (См. >>343966). В статически-строго-типизированных языках все проверки выполняет компилятор, все что может произойти в рантайме должно быть учтено в коде, иначе код просто не скомпилируется.
>>347138
>описанный мной выше до сих пор не решен, тогда как в эрланге, как-то похуй что какой-то там процесс где-то проебался и что-то не доделал.
Что в сущности может произойти с функцией (читай future)? Тут только три варианта: 1)возврат значения; 2)выброс исключения; 3)зависание. Для future (не будем говорить об (1)), не пойманные исключения (в норме все они должны ловиться) вылезут в точке future.get, это и есть ожидаемое поведение. Если актор упадет из-за исключения, то следующие за ним блоки алгоритма так и останутся висеть в ожидании сообщения, которое уже никогда не придет, попробуй отлови и отладь такой баг в достаточно сложной системе. Остается вариант (3) зависание функции/актора - это тот случай, когда не поможет ничего кроме ручной отладки. На какие бы хитрости не пошла виртуальная машина, она не сможет разрулить эту ситуацию в полностью автоматическом режиме без того, чтобы кодер предусмотрел эту конкретную ситуацию заранее. Причина проста - (фундаментальное свойство машины Тьюритга) Не существует способа выяснить завершится ли данная программа за конечное время (т.е. "подвисла" или нет). Если задумается над этим, то становится понятно, что никакие таймауты и автоматические перезапуски не могут решить эту проблему без участия человека.

Аноним Втр 31 Дек 2013 03:55:27  #280 №347695 

>>347674
>В этом случае актор принуждаестя к возврату сообщения отправителю?

Есть обертка посылки/приема сообщения в обычную функцию, это синхронный вызов, и актор отправитель замораживается до получения ответа. Асинхронная же обертка, - просто сахар, плюс можно написать спеку для анализатора типов, чтоб удостоверься, что актор посылает то, что должен. Тащемта, синхронные вызовы считаются моветоном, так как, ещё раз, посылка сообщения =/= вызов функции, и идея сделать из первого второе, - выход за рамки тру модели акторов, где все действия однонаправлены, посылка ответа, это новое сообщение, новое событие.
Но в 3% случаев такое может понадобиться, поэтому в стандартной поставке есть.

>все проверки выполняет компилятор
Это конечно круто, я согласен. Но есть так же такие вещи как: выключение света, падение бокса в датацентре, внезапные разрывы связи вследствие кривости сети/железа/ОС/драйверов, свитер в панике перезагрузил что-то, какая-то хуйня забрала управление портом, короче житейские быдлопроблемы.
А ещё есть логические ошибки программиста и проебы архитектуры.

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

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

>/0
Но ведь серьезно. Где может быть проблема сайдэфектов? В изменении глобального стейта, например. Но актор не видит внешней памяти, все что он может - менять свой изолированный от всего мира, доступный только ему стэйт и посылать сообщения. По получению сообщения, если оно матчится, другой актор так же меняет свой изолированный стэйт. Только он это может сделать, нет никаких внешних воздействий на его состояние. Итого, если каждый актор по конкретным сообщениям меняет свой стэйт корректно, то вся программа работает корректно.

Аноним Втр 31 Дек 2013 04:00:04  #281 №347696 

>>347669
>наверняка медленнее родных системных.
Ну да, ведь переключение контекста это так быстро.
Особенно когда процессов >1k.

comments powered by Disqus

Отзывы и предложения