Компромиссы программирования с такими фреймворками, как reactivex, kotlin-coroutines, akka-субъекты?

Все эти фреймворки создают новый уровень абстракции поверх потоков. Например, использование kotlin-сопрограмм, по-видимому, потребует больше циклов ЦП, чем чистые потоки из-за планирования. Для реактивного у нас такая же ситуация, дополнительный уровень - больше циклов процессора. Хотя про акка-актеров не знаю.

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

Может ли кто-нибудь подробно объяснить эти преимущества (или это компромисс?) С акцентом на аппаратное обеспечение и уровень ОС? Может быть, каковы ситуации, когда мы хотели бы использовать сопрограммы или реактивы, и когда мы не хотим их использовать из-за чего-то?


person A. L.    schedule 28.10.2020    source источник
comment
Модель памяти Java сложна и не интуитивно понятна. Непосредственное вмешательство в него чревато ошибками. Фреймворки позволяют этого избежать   -  person darw    schedule 28.10.2020


Ответы (1)


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

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

Абстракции пользовательского уровня всех видов, которые создаются поверх потоков уровня ОС, работают хорошо, когда у вас много параллельных операций и / или они потребляют очень мало ЦП от начала до конца или от одной точки возобновления до следующей приостановки, поскольку эти абстракции легкие, а их запуск, остановка и переключение между ними тоже очень дешевы.

person Roman Elizarov    schedule 29.10.2020