Интересуют перспективы разработки многопоточного/многопроцессерного ПО на ближайшие 10 лет.
Сейчас в тренде многоядерность. Общедоступны процессоры которые имеют много относительно слабых ядер. Я думаю года через 2-3 для разных Raspberi Pi и аналогов нормой будет 16-32 ядер.
Соответственно какой поток к реализации многозадачности будет самый эффективный? На каждое физическое ядро процессора по процессу от ядра ОС? Будет ли тогда смысл в процессах потоки создавать? На сколько разные green thread (и их аналоги в Go) будут целесообразны?
Скажем в Go нормой является запуск и по 5000 зеленых потоков в рядовом веб-сервисе. Если речь идет о ТЫСЯЧАХ потоков (а то даже о десятках и сотнях тысяч), то какая разница сколько у вас при этом физических ядер - 4 или 32?
Я ответил на ваш вопрос?
На сколько го-рутины эффективны на многопроцессорных конфигурациях? Переключение контекста на каждом ядре будет независимым? Т.е. к примеру можно ли на каждом ядре запустить по отдельной задаче и будет ли эта задача выполняться сама по себе автономно т.е. не ведая что делают другие ядра?
beduin01:
> Т.е. к примеру можно ли на каждом ядре запустить по отдельной задаче и будет ли эта задача выполняться сама по себе автономно т.е. не ведая что делают другие ядра?
У привязки потоков к ядрам есть проблемы, из-за которых полная привязка все равно невозможна, например, как тогда по вашему будет работать общая хип-память?
Именно поэтому ряд высоконагруженных проектов предпочитают иметь дело с одним физическим потоком, например, Tarantool, авторы которого утверждают, что тем самым сэкономили на блокировках. А если вам нужно утилизировать все ядра, то вы просто запускаете несколько экземпляров Тарантула.
beduin01:
> Все ли го-рутины будут работать в рамках одного процесса?
Если вы используете общеупотребимую терминологию, то один процесс соответствует одной программе (внутри которой может быть несколько физических thread).
Разумеется ВСЕ go-routine будут работать в рамах одного процесса, если мы говорим об ОДНОЙ ПРОГРАММЕ.
beduin01:
> Как вообще определить эффективное количество зеленых потоков на ядро? Т.е. 5000 норм, а 6000? Или к примеру 4000?
Если нам неизвестно - а что там может их блокировать в каждом конкретном случае, используются ли какие-либо процедуры ввода-вывода или другие блокирующие операции - то о какой оценке можно говорить вот так вот с бухты-барахты?
beduin01:
> А в случае веб-сервисов в какой момент эта общая память может потребоваться?
В любой момент.
Общая память - это т.н. хип (куча).
Любой обработчик запросов может создавать множество объектов.
Непредсказуемо.
Общая память нужна всегда.
Если вы хотите обойтись без нее, то тут же исчезает гибкость.
Вы заранее распределяете все структуры (при запуске приложения) - тогда общая память и не нужна.
Нужно ли объяснять - что это два диаметрально разных подхода?
Когда все заранее известно и заранее распределено и, напротив, когда все динамично.
Простой
Средний
