Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, vdimas, Вы писали:

I>>>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.

V>>Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это.

I>Наоборот, потоков вообще не нужно для этого. Смотри на видеокарту — винде не надо создавать по 3 тысячи потоков если в видеокарте 3 тысячи ядер

Это зависит от вида алгоритма. В видеокарте, считай, все тыщщи ядер выполняют один и тот же алгоритм, просто над разными участками данных.
Кароч, это спор о видах пареллелизма.
Я имел виду "независимый" параллелизм, т.е. паралеллизм независимых потоков, где каждый поток выполняет уникальный алгоритм.


V>>Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.

I>Смешное утверждение. Файберы могут работать с дотнетом. Принципиальной разницы нет.

Да, но корутины буста дешевле, чем файберы windows, поэтому и разрабатываются.

Дотнету НЕОБХОДИМО разметить стек на фреймы, чтобы GC мог в нём работать. Если же корутина была создана не ср-вами дотнета, то дотнет в таком стеке сможет работать только с самым последним кадром стека, который создаётся, например, вы вызове из нейтива unmanaged poiner to function, которую можно получить из дотнетного делегата.


I>Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.

GC сканирует не весь стек, а только список связанный фреймов в нём. Оборвешь связь — и нет никакого сканирования.


I>Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.

Облом спорить. Но, таки, ожидание IO — это де-факто больное место ВСЕХ библиотек statefull-корутин. Могу рекомендовать посмотреть на PPL, как там с этим борются.

Здравствуйте, Ikemefula, Вы писали:

V>>Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это.
I>Наоборот, потоков вообще не нужно для этого. Смотри на видеокарту — винде не надо создавать по 3 тысячи потоков если в видеокарте 3 тысячи ядер

Это зависит от вида алгоритма. В видеокарте, считай, все тыщщи ядер выполняют один и тот же алгоритм, просто над разными участками данных.
Кароч, это спор о видах пареллелизма.
Я имел виду "независимый" параллелизм, т.е. паралеллизм независимых потоков, где каждый поток выполняет уникальный алгоритм.


V>>Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.

I>Смешное утверждение. Файберы могут работать с дотнетом. Принципиальной разницы нет.

Да, но корутины буста дешевле, чем файберы windows, поэтому и разрабатываются.

Дотнету НЕОБХОДИМО разметить стек на фреймы, чтобы GC мог в нём работать. Если же корутина была создана не ср-вами дотнета, то дотнет в таком стеке сможет работать только с самым последним кадром стека, который создаётся, например, вы вызове из нейтива unmanaged poiner to function, которую можно получить из дотнетного делегата.


I>Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.

GC сканирует не весь стек, а только список связанный фреймов в нём. Оборвешь связь — и нет никакого сканирования.


I>Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.

Облом спорить. Но, таки, ожидание IO — это де-факто больное место ВСЕХ библиотек statefull-корутин. Могу рекомендовать посмотреть на PPL, как там с этим борются.