Да, вы правы в том, что первый метод имеет то преимущество, что он не ждет, пока все объекты данных начнут свою обработку. Тем не менее, он также имеет преимущество в том, что не ожидает завершения обработки всех объектов данных, переданных в parallel_for
. Это становится особенно заметным, если скорость обработки варьируется для каждого объекта данных и / или каждого объекта обработки.
Кроме того, кажется достаточным, чтобы за buffer_node
следовали (возможно, reserving
) join_node
вместо concurrent_queue
для сохранения обрабатываемых объектов для дальнейшего повторного использования. В этом случае function_node
вернет объект обработки обратно в buffer_node
, как только он завершит обработку объекта данных. Таким образом, график будет выглядеть следующим образом:
input_node -> input_port<0>(join_node);
buffer_node -> input_port<1>(join_node);
join_node -> function_node;
function_node -> buffer_node;
В этом случае параллелизм function_node
можно оставить равным unlimited
, поскольку за ним автоматически будет следовать число существующих объектов обработки ( доступные токены ) на графике.
Также обратите внимание, что генерация объектов данных из разных файлов также может выполняться параллельно. Если вы видите выгоду от этого, рассмотрите возможность использования function_node
вместо input_node
, так как последний всегда последовательный. Однако в этом случае используйте join_node
с queueing
политикой, поскольку function_node
не зарезервирован.
Также, пожалуйста, рассмотрите возможность использования tbb :: parallel_pipeline вместо этого, как кажется, у вас есть Классификационная схема обработки c. В частности, эта и эта ссылка может быть полезной.