Здравствуйте, netch80, Вы писали:
N>То есть, если новых не поступит, время отработки пропорционально квадрату количества поступивших (точнее, каждый может подсчитать, чему равно N*(N-1)+(N-1)*(N-2)+(N-2)*(N-3)+..., но мне облом — асимпотически это равно N*N/2).
У тебя в формуле по сути сумма последовательности квадратов, что соответствует кубической сложности.
А должна быть сумма арифметической прогрессии (N + (N-1) + (N-2) + ...) — которая как раз квадратична.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
N>>То есть, если новых не поступит, время отработки пропорционально квадрату количества поступивших (точнее, каждый может подсчитать, чему равно N*(N-1)+(N-1)*(N-2)+(N-2)*(N-3)+..., но мне облом — асимпотически это равно N*N/2).
EP>У тебя в формуле по сути сумма последовательности квадратов, что соответствует кубической сложности. EP>А должна быть сумма арифметической прогрессии (N + (N-1) + (N-2) + ...) — которая как раз квадратична.
Посмотрел. Да, похоже, именно случай TCP это бы вылечило — за счёт залезания в недокументированные потроха реализации (что prim_inet, что port command это такие потроха). Это само по себе обидно, но, если бы у нас была фатальная необходимость досидеть на Erlang, наверняка так бы и сделали (и очень осторожно меняли базовый релиз).
_>Да, неприятно, но на первый взгляд лечится и довольно тривиально. Но может и у этих решений есть какая-то проблема — я не знаю, я на практике с неконтролируемой отправкой не сталкивался.
Я тоже не в курсе. Но если Rabbit работает — значит, этот путь пока что работает...
N>>И подобные ситуации не только с TCP, а с любым случаем, где владелец длинной очереди синхронно с кем-то общается (то есть, дожидаясь ответа). N>>(Да, оптимизации R14 про watermark на эту очередь не вспоминать — они тут не помогают.)
_>С портами не помогают, но почему не помогают "с любым случаем, где владелец длинной очереди синхронно с кем-то общается"? И почему — для этого любого другого случая — не вспоминать про watermark?
Потому что оптимизация с watermark жёстко рассчитана на вызов make_ref для одного запроса и получения ответа определённой структуры с этим ref. OK, не с любым, но в общем случае.
Здравствуйте, netch80, Вы писали:
N>Хотя бы вот. Так вот, кодогенерация там очень слабая, если сравнивать с аналогами, где на заточку под процессоры с их возможностями ушло много человеко-лет. Но сделать выхлоп, например, в LLVM IR они не хотят — "у нас всё должно быть на Go".
Есть же gccgo, который не самый живой, но поддерживается и развивается.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Компилятор го вставляет вызовы runtime.Gosched перед некоторыми конструкциями, чтобы шедулер получал управление и мог прервать выполнение кода. В BEAM вытесняющая многозадачность, а в Go — кооперативная, со всеми вытекающими проблемами.
И какие же проблемы от этого вытекают? В Го можно послать тяжёлые графы объектов между потоками без всякого оверхеда, в отличие от Эрланга.
Да, насильная остановка потока — это фундаментально неправильная операция.
Здравствуйте, Cyberax, Вы писали:
N>>Хотя бы вот. Так вот, кодогенерация там очень слабая, если сравнивать с аналогами, где на заточку под процессоры с их возможностями ушло много человеко-лет. Но сделать выхлоп, например, в LLVM IR они не хотят — "у нас всё должно быть на Go". C>Есть же gccgo, который не самый живой, но поддерживается и развивается.
Здравствуйте, chaotic-kotik, Вы писали:
DD>>Почему Lisp? Вроде автор писал, что вдохновлялся Ruby в основном...
CK>А получился полноценный Lisp!
Закономерно получился :
Любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp
Здравствуйте, Sharov, Вы писали:
S> С другой стороны в выше процитированной док-ии сказано, что выч. на канале идут в порядке следования их case'ов.
Вычисления. Но не пробы каналов. Подозреваю, что тут есть существенная разница.
S> И как бэ неявно приоритет будет отдаваться первому, наверное.
Есть исходники, я читаю по ним (по 1.7.5).
Файл go/work/src/runtime/select.go, функция selectGoImpl(). В массиве pollorder генерируется перестановка, на каждый запуск select{} своя. По ней сортируется массив lockorder (код сортировки, как это у них принято, повторен и вшит прямо на месте в функцию). Дальше в порядке этого lockorder они двигаются по кейсам.
Никакого предпочтения первому — нет.
S> В целом было логично, что если первый case готов -- управление ему, иначе рандомный выбор.
Не логично. Логично или строго по порядку, или по явно прописанным приоритетам (я бы предпочёл схему, как в DNS SRV записях — есть priority и есть weight).
И ещё обязательно должна быть возможность таймаута. Её сейчас тоже нет.
Здравствуйте, netch80, Вы писали:
C>>Есть же gccgo, который не самый живой, но поддерживается и развивается. N>_Пока_ есть.
По словам гугловодов, поддержка gccgo для них принципиальна. Ближайшие годы он будет развиваться, хотя у него циклы выпусков сильно длиннее, чем у Go.
Здравствуйте, netch80, Вы писали:
N>Хотя бы вот. Так вот, кодогенерация там очень слабая, если сравнивать с аналогами, где на заточку под процессоры с их возможностями ушло много человеко-лет. Но сделать выхлоп, например, в LLVM IR они не хотят — "у нас всё должно быть на Go".
Есть проект по реализации Go над LLVM. Насколько я понимаю, он пока очень сырой.
Кроме того, есть gccgo. Он тоже, насколько я понимаю, сыроват.
Здравствуйте, Sharov, Вы писали:
S>Тут согласен. Я думаю они все прекрасно понимали, и рассчитывали что вне циклов использовать select смысла нет, поэтому приоритетное событие никуда не убежит. Имело ли смысли усложнять язык ради метки приоритета -- . Они посчитали, что нет. С другой стороны в выше процитированной док-ии сказано, что выч. на канале идут в порядке следования их case'ов. И как бэ неявно приоритет будет отдаваться первому, наверное. В целом было логично, что если первый case готов -- управление ему, иначе рандомный выбор.
Нет, в спецификации сказано, что если в селекте готово несколько вариантов, то тот, который сработает, будет выбран с помощью генератора случайных чисел с равномерным распределением.
Здравствуйте, netch80, Вы писали:
N>Не логично. Логично или строго по порядку, или по явно прописанным приоритетам (я бы предпочёл схему, как в DNS SRV записях — есть priority и есть weight).
Я бы предпочел схему, в которой рантайм выберет первый попавшийся удобный ему case, потому что это дешевле всего. Только народ прочухает, в каком порядке рантайм выбирает варианты, и начнет использовать это для приоритезации. И если потом в рантайме алгоритм выбора варианта изменится, куча кода сломается. Поэтому они, назло всем, сделали случайный выбор.
N>И ещё обязательно должна быть возможность таймаута. Её сейчас тоже нет.
Просто добавляем в select case, в который таймер тикает. Это ничем не хуже какого-то отдельного механизма для таймаута.
Здравствуйте, Cyberax, Вы писали:
C>>>Есть же gccgo, который не самый живой, но поддерживается и развивается. N>>_Пока_ есть. C>По словам гугловодов, поддержка gccgo для них принципиальна. Ближайшие годы он будет развиваться, хотя у него циклы выпусков сильно длиннее, чем у Go.
Я думаю, для них принципиально, чтобы было больше одной реализации языка. Если llvm обгонит gccgo, они могут его и забросить.
Здравствуйте, Pzz, Вы писали:
N>>Не логично. Логично или строго по порядку, или по явно прописанным приоритетам (я бы предпочёл схему, как в DNS SRV записях — есть priority и есть weight).
Pzz>Я бы предпочел схему, в которой рантайм выберет первый попавшийся удобный ему case, потому что это дешевле всего. Только народ прочухает, в каком порядке рантайм выбирает варианты, и начнет использовать это для приоритезации.
FYI, правильно — "приоритизация"
Pzz>И если потом в рантайме алгоритм выбора варианта изменится, куча кода сломается. Поэтому они, назло всем, сделали случайный выбор.
Вот именно, что "назло всем" никогда не должно быть подходом проектирования языка. А в Go, похоже, такое любят — см. те же ошибки вместо предупреждений на неиспользованные импорты, или форсированная статическая сборка.
N>>И ещё обязательно должна быть возможность таймаута. Её сейчас тоже нет. Pzz>Просто добавляем в select case, в который таймер тикает. Это ничем не хуже какого-то отдельного механизма для таймаута.
Хуже. Делать отдельную горутину для таймера... я понимаю, что они дешёвые, но это всё равно костыль.
Заметь, в Erlang таймеры — отдельные процессы, но receive всё равно имеет вариант after.
Здравствуйте, netch80, Вы писали:
N>>>И ещё обязательно должна быть возможность таймаута. Её сейчас тоже нет. Pzz>>Просто добавляем в select case, в который таймер тикает. Это ничем не хуже какого-то отдельного механизма для таймаута.
N>Хуже. Делать отдельную горутину для таймера... я понимаю, что они дешёвые, но это всё равно костыль. N>Заметь, в Erlang таймеры — отдельные процессы, но receive всё равно имеет вариант after.
Зачем отдельную гороутину? Таймер из стандартной библиотеки обходится одной гороутиной на всех.
I think conservative is the best description of Go's design. It doesn't bring anything new to the table
and ignores basically all advancements in programming language design from the last few decades.
Just look at their type system, which is basically worse than OCaml's in every way. OCaml supports
essentially the same sort of structural sub-typing, but without sacrificing type inference (what
Go has is too limited to honestly call "type inference") and with well-supported and well-implemented
generics. And don't get me started on how variants actually make sense for error handling unlike Go's approach!
Moreover, all this technology (like how to implement those generics safely and efficiently) is
well-understood and well-documented in academic papers which I suspect the Go designers largely
ignored. Instead, they couldn't figure out how to implement generics efficiently and so decided
to sacrifice both expressiveness and safety to the altar of compiler simplicity. Much better
to have every end-user pay a small amount than to pay a larger cost once, in the compiler!
All this and OCaml still manages fast compile times and good performance. But obviously,
unlike Go, it's not a practical language, so they couldn't have considered it.
The Go creators liked C--about as far from functional as possible--so they wrote a C 2.0.
Except with garbage collection. Because C is obviously a perfect programming language except for being too low-level.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Может кто-нибудь объяснить, почему люди считают что Go подходит для concurrency и сервисов, хотя там нет нормального планировщика (любая горутина может неотдавать управление неограничено долго), общая память и глобальный GC, невозможно нормально остановить горутину, нет нормальной обработки ошибок?
По сравнению со своим логическим конкурентом (Java) у него действительно более развиты врождённые средства многопоточности. При этом сам язык ещё более упрощён (хотя казалось бы куда уж больше).
CK>Самое главное, есть же нормальная алтернатива — Erlang/Elixir + OTP.
Эрланг немного из другой области — динамических языков. )
> Чтобы перебрать всю очередь и перейти в ожидание, ему нужно прошерстить N-1 сообщение
Вариант номер раз: перед чтением первого сообщения, вычитываешь все в локальный кеш и затем работаешь с кешем. Кстати, так ты сможешь и приоритеты реализовать.
Вариант номер два: делаешь отправку в отдельной корутине, туда же придет и ответ по tcp, и там не будет такой очереди.
Я это к тому, что решения этой задачи существуют, другой вопрос, насколько это решение тебе подойдет.
Здравствуйте, Masterspline, Вы писали:
>> Чтобы перебрать всю очередь и перейти в ожидание, ему нужно прошерстить N-1 сообщение
M>Вариант номер раз: перед чтением первого сообщения, вычитываешь все в локальный кеш и затем работаешь с кешем. Кстати, так ты сможешь и приоритеты реализовать.
Если за это время навалят ещё сообщений — не сработает. На практике именно так и происходило.
M>Вариант номер два: делаешь отправку в отдельной корутине, туда же придет и ответ по tcp, и там не будет такой очереди.
Проходили. Не работает. Сам догадаешься, почему?
M>Я это к тому, что решения этой задачи существуют, другой вопрос, насколько это решение тебе подойдет.
Вариант по ссылкам от meadow_meal, скорее всего, сработает, да. Если наплевать на идеологическую правильность влезания в недокументированные потроха. Что мне, собственно, в нём и не нравится (и не только мне). Сработает потому, что в нём вообще исключён просмотр вперёд за синхронным ответом.
Твои варианты — нет и никак.
: 
. Они посчитали, что нет. С другой стороны в выше процитированной док-ии сказано, что выч. на канале идут в порядке следования их case'ов. И как бэ неявно приоритет будет отдаваться первому, наверное. В целом было логично, что если первый case готов -- управление ему, иначе рандомный выбор.
