Чисто технические причины НЕ любить Rust [holywar mode activated]

Твое «ололо неасилил», похоже, реально мешает тебе читать и понимать прочитанное. Отдохни и возвращайся в тред позже

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

Твое «ололо неасилил», похоже, реально мешает тебе читать и понимать прочитанное

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

На самом деле веская причина. Куда более разумна, чем считать гугловсцев идиотами, а себя дартаньянами. Скорее всего всё в итоге получится ровно наоборот.

Мамку свою залогинь, пес

It's a far better green thread implementation than Rust will ever have, because the language is designed around them

Я слегка не понял логики здесь. Erlang тоже весь написан вокруг тредов, и там с ними, вроде бы, никаких проблем нет. В Haskell (GHC) тоже весьма годная реализация зеленых тредов и шедулинга.

А зачем вообще нужны green threads?

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

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

Go более-менее активно используется в продакшене, в том числе самим Google, так что вполне нормально считать его за хороший образец реализации зеленых потоков. На счет «никаких проблем нет», найди вот здесь http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=p... Go, Haskell и Erlang и подумай, есть проблемы или нет.

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

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

У зеленых потоков как раз начинаются проблемы при многоядерности, они оптимизированы на однопоточность и для хайлоада не подходят. Полноценные потоки + AIO гораздо лучше масштабируются, сравни http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=pla... (8 ядер) и http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=p... (40 ядер с NUMA).

Meanwhile, Go's JSON serialization performance on Peak is only 1.6x that of i7. Even more interesting: Go's database performance is slightly lower on Peak than i7. (Yes, the Go tests use all CPU cores.)

Такой вот хайлоад на зеленых потоках.

То есть потоки эти нужны для того, чтобы писать асинхронный код в синхронном стиле с «блокирующими» вызовами и т.п?

Да.

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

Кмк Erlang был отличным примером почему это сообщение выдает желаемое за действительное.

Ну тогда не жалко)

Чтобы исбежать оверхеда от переключения контекстов процессора, достаточно использовать асинхронный ввод-вывод: select из POSIX-а из 80-х годов или более современные альтернативы. Зелёные потоки для этого не нужны.

Чтобы исбежать оверхеда от переключения контекстов процессора, достаточно использовать асинхронный ввод-вывод: select из POSIX-а из 80-х годов или более современные альтернативы. Зелёные потоки для этого не нужны.

Разве кто-то говорил что-то о вводе-выводе?

А в какой задаче тогда зелёные потоки дадут преимущество перед обычными потоками, если речь не идёт о вводе-выводе?

Я выше написал.

Это скорее один из способов выжать максимальную производительность при правильном применении.

Правильном применении в какой предметной области? Тут Legioner уже правильно сказал про задачи, связанные с IO. И если не IO, то что, числодробилки?

Тут пример. Я затрудняюсь сказать, насколько тут зелёные потоки оправданы. С одной стороны вроде верно. С другой стороны есть lock-free структуры данных; можно просто алгоритм переписать так, чтобы там не было последовательно выполняющихся потоков, иначе зачем они вообще нужны?

На Go можно некоторые алгоритмы очень красиво записывать с помощью горутин. Например обход дерева — одна горутина обходит дерево и выплёвывает вершины в канал, вторая горутина их читает и обрабатывает. Это итератор такой. Реализовывать его «ручками» будет куда больше кода. Но в общем то ручная реализация всё равно будет быстрей.

Мне тоже несколько непонятно, если это не IO, то завершения чего еще можно ждать в потоке?

Пусть сначала перебенчмаркируют с новым IO-менеджером из GHC 7.8.

Правильном применении в какой предметной области? Тут Legioner уже правильно сказал про задачи, связанные с IO. И если не IO, то что, числодробилки?

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

https://github.com/snoyberg/posa-chapter/blob/master/warp.md#performance-of-warp

Вот сравнение производительности mighty (сервер на основе warp, написан на haskell и использует зеленые треды) и nginx (зеленых тредов нет по понятным причинам).

одна горутина обходит дерево и выплёвывает вершины в канал, вторая горутина их читает и обрабатывает

По моему это очень красивый костыль :)

Собственно, пример с короутинами из доки к Boost.Coroutine показывает аналогичное — SAX-парсер на короутинах позволяет сделать запись алгоритма более короткой (хотя разобраться что к чему и почему может быть не так-то и просто). Но здесь речь идет о выигрыше на уровне компактности и выразительности кода. А не о производительности.

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

Повылазили! Я только только начал неспешно изучать синтаксис Rust и решать задачки. А тут на тебе - опять эксперты гонят на новый ЯП.

И таких тредов большинство. Буду в тетради программировать на русском языке - сочинение писать.

Кушайте дальше свои печеньки!

У меня в голове есть такой список касательно си, там десятки причин. А все равно и си, и сишники неистребимы :)

Список или GTFO.

http-сервера тоже подходят.

Не знал, что http-сервера, это уже не IO-задачи.

1: «одобряемс» со стороны таилганнер

это +500 к ненужности сразу.

Не знал, что http-сервера, это уже не IO-задачи.

Там выигрыш не в IO коде получился (вернее, не только в IO).

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

Зачем для этого держать больше потоков, чем число доступных ядер?

http-сервера тоже подходят

Http-сервер, по-твоему, не io-bound?

Вот сравнение производительности

Из статьи 2х летней давности от хаскелистов для хаскелистов. Вот более репрезентативное сравнение: http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=p... , и там есть Haskell:

snap 72,217 1.1%

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

Только если задача плохо параллелится.

Зависит от железа

Там выигрыш не в IO коде получился (вернее, не только в IO).

Да там же английским по белому написано, для чего и как они используют user-threads:

When a user thread performs a logically blocking I/O operation, such as receiving or sending data on a socket, a non-blocking call is actually attempted. If it succeeds, the thread continues immediately without involving the IO manager or the thread scheduler. If the call would block, the thread instead registers interest for the relevant event with the runtime system's IO manager component and then indicates to the scheduler that it is waiting. Independently, an IO manager thread monitors events and notifies threads when their events occur, causing them to be re-scheduled for execution.

Т.е. на контексте user-thread делается попытка выполнить IO опереацию. В неблокирующем режиме. Если это не удается, то текущая user-thread регистрируется в IO-менеджере. А самой IO-операцией затем занимается IO-менеджер, который разбудит нужную user-thread по итогам операции. Сам же IO-менеджер работает на нативной нити.

При этом они еще и вынуждены были свой parallel IO manager реализовать.

Так что судя по описанию, типичная IO-задача. И мотивация к использованию user-threads была в том, чтобы не заставлять пользователя писать асинхронный event-driven код.

Ичо? Как тормоза snap доказывают ненужность green threads?

О том, что нет у ТС никакого списка, уже писали?

Только если задача плохо параллелится.

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

Так в этом и проблема, что зеленые потоки, как минимум в Go реализации, не масштабируются, а значит для хайлоада не подходят.

Господа, на самом деле фишка легковенсых процессов не в оверхеде на переключение контекста. Идея в том, что у тебя 10к tcp-соденинений и полностью асинхронный IO. Ты запускаешь по одному легковесному процессу на пользователя, и он его запросы обрабатывает. Разница между легковесными процессами в Go/Haskell/Erlang и футурами в Scala/Rust уловно говоря в том, что первые намного проще и удобнее, а вторые реализованы средствами самого языка и потому могут развиваться независимо, иметь несколько реализаций и прочее. Но во втором случае нужно уметь с ними работать, есть масса нюаснов. Порог вхождения при втором подходе выше.

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

Мы все еще ждем списка.

PHP тоже активно используется в продакшене, но хорошим образцом вообще чего-либо его считать - плохая идея

А вот продакшен думает, что хорошая и рубит тонны бабла на этом. И где теперь твой rust бог?

Тут как бы все это понимают, ну разве что кроме hateyoufeel

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

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

Идея в том, что у тебя 10к tcp-соденинений и полностью асинхронный IO. Ты запускаешь по одному легковесному процессу на пользователя, и он его запросы обрабатывает.

Но зачем запускать по процессу на пользователя, если у тебя асинхронный IO?

Это просто удобная абстракция, позволяющая написать условно:

while(1) {
  req = getRequestFromUser
  res = processRequest(req)
  sendResponseToUser(res)
}