а не кусками уже сплитнутыми? :)

Foreign Function Interface - это некоторый интерфейс вызова функций одного языка из другого. Некоторый набор соглашений и реализаций.

Это использование FFI.

Не понял, что этот вопрос делает на канале про компиляторы. Но да: сначала форкаем, чтобы у других потоков тоже появилась возможность поработать, потом делаем своё. Штатно на параллельном пути тупо всё форкнуть и тупо всё джойнуть, а там уж FJP пусть сам на одном из join'ов дойдёт до последовательного вычисления. Иначе толку от такой параллелизации нет. Или я просто не понял вопроса.

то есть, смотри, я крестовик если что, вот пусть у нас есть задача посчитать сумму 80 чисел, тогда в методе экзекат у задачи мы создаем 8 подзадач размерностью по 10 чисел в каждой. И считаем сумму там, а затем дождавшись все 8 подзадач, делаем сумму их результатов. Но, вот эти 8 подзадач будут доступны на исполнение, только после того как мы сделаем полное разбитие? Или мы можем сначала получить одну подзадачу и сразу начать ее выполнять другим потоком, который ее украдет и т. д?

Понимаешь о чем я :)?

Никто не будет ждать полного разбиения, да и непонятно, как его дождаться (кто пулу скажет-то "разбиение закончено, вперёд"?). Как только задача fork()-нулась, она доступна для исполнения любым потоком.

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

чем связать уже k работающих подзадач этим же колбеком.

ведь, в последнем случае, надо делать проверку на то, не выполнилась ли задача, до того как мы поставили колбек

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

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

я вот про эту самую нарезку на k подзадач на каждом уровне. Она эта нарезка всегда последовательная в fjp?

если бы там было k*

Ну она же написана в теле execute(), который исполняется как обычный код -- последовательно! В том-то и состоит проблема: дешевле отдать жирную половину другому потоку, и вы дальше *вдвоём* будете дробить каждый свою половину, чем ждать, пока один поток последовательно отфоркает k подзадач.

но как только форкаем первую из k(остаток все еще не сплитнут) подзадач, она доступна на выполнение?

да, конечно. fork() делает задачу доступной для исполнения другим потокам

тогда, все понял :) А производительность мерял, кстати? Ну там, например с tbb intel?

так понимаю, в основе там лок фри дек.

у вас, ну или тебя. Как угодно.