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