Leonid Kudryavtsev,

волшебство в восстановлении значений локальных переменных, без явного привлечения концепции static.
Оговорка о "хранении состояния в возвращаемом значении" может намекать, например, на некий struct
с разной видимостью внутри и снаружи.
Но как на самом деле, я не знаю.

Leonid Kudryavtsev,

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

mayton,

полистал про Эльбрусы.
Впечатление вынес вот какое -
Имхо, пока в самой слабой позиции, из всех вообще связанных с ними историй, выглядит их жесткое и непокобелимое
желание никого не допускать до кодогенерации.
Что-то даже мило-оправдательное в свой адрес на эту тему произносят.

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

предположим, что смысл вашего вопроса заключается в выяснении вопроса о том,
"как модельно стоит кооперативная многозадачность против физической многопоточности".

Тогда ответ будет такой:
It depends.
Причем, депендс катастрофически, в зависимости от длины очереди физических потоков, ожидающих своего времени выполнения на процессоре. И особенно быстро катастрофически, когда работа таких взаимодействующих потоков связана блокировками, регулирующими доступ к совместно используемым ресурсам.

Поток, содержащий в себе "кооперативную многозадачность" нельзя заставить работать быстрее, чем может то процессорное ядро, которое его выполняет.
Но его нельзя и заморозить, остановить, если это ядро непрерывно доступно для исполняемого потока, то есть - в предположении, что поток не вытесняется.
Программа просто работает со скоростью выполняющего ее ядра.
У вас есть принципиальная возможность заняться умеренно надежными предсказаниями, через какое время она завершит свое вычисление.

В случае физических потоков, пусть пока без взаимодействия, вы назначаете потоки ядрам и, в отсутствии взаимодействия,
все выглядит прилично, пока число физических потоков не превышает числа вычислительных ядер.
Что нужно делать точно в такой ситуации, когда очередь ожидающих потоков становится "слишком длинной"?
Правильно, добавлять вычислительные ядра. Так выглядит картинка на Земле, при разглядывании ее примерно с Марса.

По мере приближения к Земле выяснится, что у вас есть физические пределы скорости распределения потоков освобождающимся ядрам, или скорости приостановки текущего выполняемого физического потока для выделения кванта времени ожидающему.
И понятие "фигня вопрос - я сейчас сюда физических ядер досыплю и все опять станет зашибись" - упирается в стенку таких
пределов.
Достаточно быстро становится бессмысленно добавлять вычислительные ядра, они все равно окажутся простаивающими,
не выполняющими "полезную работу", в конце концов, почти 100% времени.

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

Статистически это зависит не от точного устройства взаимодействия, а от факта его наличия и "нагрузки" системы в виде общего числа ожидающих выполнения потоков. В конце концов, независимо от числа процессоров система содержательно встает.
В ней не происходит полезной работы. Только непрерывно молотит планировщик задач, но это совсем не то,
что ожидается в качестве "полезной работы".

Проводившиеся лет, наверно в районе 10, может и чуть уже больше назад, модельные имитации показывали,
что нет смысла на современной моменту исследования технологии строить системы больше, чем о 132 (по памяти) примерно процессорах.
Добавление следующих не приводит к увеличению общей производительности в модели с захватами блокировок.
И, в любом случае, по мере увеличения нагрузки в виде очереди ожидающих потоков система "встает" на сопоставимых длинах очередей. Общая производительность в смысле полезной работы составляет малую долю полезного времени работы единственного ядра, что эквивалентно просто "закупорке" системы.

С тех пор в технологиях ничего не произошло, что могло бы сдвинуть оценку осмысленного максимума процессорных ядер
со 128-132 к 265 или 514.

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

Смысл всего этого заключается в том, что если вам не повезет, и вы неудачно разложите свою систему на кооперативную многозадачность и многопоточное выполнение, то выиграете всего полтора-два порядка на стопорящем краю, получив вместо 0.1 полезно работающего процессора в единицу времени 1.5 - 2.
При удачном раскладе, число порядков выигрыша могут оказаться и три и все четыре.

Ну барин, я без помощника меньше, чем за неделю точные ссылки не найду, это года 3 назад было, как я кино с упоминанием смотрел.
На 100% не уверен, что это несомненно и безоговорочно оно, но здесь об очень похожих вещах речь идет, и по крайней мере один автор, по моей памяти, совпадает.
Здесь тема изложена в терминах анализа нагрузки OLTP-систем на 1000 ядрах.
Сейчас полистал, прямо помянутых слов не нашел, но картинка, в целом, схожего типа.
вот:
https://www.vldb.org/pvldb/vol8/p209-yu.pdf



Думаю, что напрямую нет. Эту шведскую историю из функционального программирования как-то выводить надо, вероятно.

Aklin,

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

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

Потому же, почему в C++ норвежский ООП
здесь автор - швед :))