Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

flow graph: limiter_node in v4.1 update1 doesn't work as in previous versions

Michael_K_4
Beginner
1,495 Views

Hi there!

In the transition from TBB "4.1" to "4.1 Update 1" something seems to have gone wrong.

Attached is a simple test case (inspired by http://software.intel.com/en-us/blogs/2011/09/14/how-to-make-a-pipeline-with-an-intel-threading-building-blocks-flow-graph).

The program is supposed to generate 100 numbers, let them be squared, and then print the square. The limiter node is set to an arbitrary limit of 7, to limit the number of numbers that are processed in parallel.

I use Visual Studio 2012 to compile this. With TBB V4.1 (20120718) and earlier versions, everything works fine: 100 numbers and their squares are printed. With TBB V4.1 Update 1 (20121003) the program stops after 8 numbers or so. It just terminates. This can be influenced by adjusting the limiter_node limit (7 in the example).

I have traced the problem back to the include file tbb/flow_graph.h: I can use both versions of the TBB DLL, but only the 20120718 version of tbb/flow_graph.h will produce the desired result.

For me, this is a showstopper. I have no idea how to work around this. Hope I've provided enough info! Thanks for any help or input on this - maybe I've just misunderstood the whole concept of a limiter_node :-)

Michael

0 Kudos
40 Replies
SergeyKostrov
Valued Contributor II
913 Views
Hi Michael, >>...tbb20121003-flow-graph-bug.cpp Thanks for the test-case and I wish everybody does the same. I'll take a look at a little bit older TBB version 4.0 Update 3 ( Commercial-Aligned Release ) in order to see how it executes your test-case. I hope that it will be done in a right way. Best regards, Sergey
0 Kudos
RafSchietekat
Valued Contributor III
913 Views
Original posting confirmed (on Linux, for tbb41_20120718oss_src.tgz and tbb41_20121003oss_src.tgz to be explicit).
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
This is a quick follow up... Hi Michael, >>>>...tbb20121003-flow-graph-bug.cpp >> >>Thanks for the test-case and I wish everybody does the same. I'll take a look at a little bit older TBB version 4.0 Update 3 >>( Commercial-Aligned Release ) in order to see how it executes your test-case. I hope that it will be done in a right way. It works in a right way ( ! ) and also it works in a wrong way ( ! ). Here are correct results: [ This is an example of correct output ] ... ** Manually Ordered ( Edited ) output ** ( Passed ) Sending number : 0.0 -> Received number: 0.0 Sending number : 1.0 -> Received number: 1.0 Sending number : 2.0 -> Received number: 4.0 Sending number : 3.0 -> Received number: 9.0 Sending number : 4.0 -> Received number: 16.0 Sending number : 5.0 -> Received number: 25.0 Sending number : 6.0 -> Received number: 36.0 Sending number : 7.0 -> Received number: 49.0 Sending number : 8.0 -> Received number: 64.0 Sending number : 9.0 -> Received number: 81.0 Sending number : 10.0 -> Received number: 100.0 Sending number : 11.0 -> Received number: 121.0 Sending number : 12.0 -> Received number: 144.0 Sending number : 13.0 -> Received number: 169.0 ... I'll continue some time later and technical details will be provided.
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
>>...It works in a right way ( ! )... [ Test-Case 1 - 'printf' was used instead of 'std::cout << ... << std::endl' ] ** Unordered output ** ( Passed ) Sending number : 0.0 Sending number : 1.0 Sending number : 2.0 Received number: 0.0 Sending number : 3.0 Received number: 1.0 Sending number : 4.0 Received number: 4.0 Received number: 9.0 Sending number : 5.0 Received number: 16.0 Sending number : 6.0 Received number: 25.0 Sending number : 7.0 Received number: 36.0 Sending number : 8.0 Received number: 49.0 Sending number : 9.0 Received number: 64.0 Sending number : 10.0 Received number: 81.0 Sending number : 11.0 Received number: 100.0 Sending number : 12.0 Sending number : 13.0 Received number: 121.0 Received number: 144.0 Received number: 169.0 ** Manually Ordered output ** ( Passed ) Sending number : 0.0 -> Received number: 0.0 Sending number : 1.0 -> Received number: 1.0 Sending number : 2.0 -> Received number: 4.0 Sending number : 3.0 -> Received number: 9.0 Sending number : 4.0 -> Received number: 16.0 Sending number : 5.0 -> Received number: 25.0 Sending number : 6.0 -> Received number: 36.0 Sending number : 7.0 -> Received number: 49.0 Sending number : 8.0 -> Received number: 64.0 Sending number : 9.0 -> Received number: 81.0 Sending number : 10.0 -> Received number: 100.0 Sending number : 11.0 -> Received number: 121.0 Sending number : 12.0 -> Received number: 144.0 Sending number : 13.0 -> Received number: 169.0
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
>>...also it works in a wrong way ( ! )... [ Test-Case 2 - 'std::cout << ... << std::endl' was used ] ** Unordered output ** ( Output is broken ) Sending number : 0 Sending number : Received number: 01 Sending number : Received number: 2 Sending number : 1 Received number: 3 Sending number : 4 Received number: 4 Sending number : 9 Received number: 5 Sending number : 16 Received number: 6 Sending number : 25 Received number: 7 Sending number : 36 Received number: 8 Sending number : 49 Received number: 9 Sending number : 64 Received number: 10 Sending number : 81 Received number: 11 Sending number : 100 Received number: 12 Sending number : 121 Received number: 13 144 Received number: 169 ** Manually Ordered output ** ( Output is broken / Sending and Received numbers are flipped ) Sending number : 0 Sending number : 1 Sending number : 1 Sending number : 4 Sending number : 9 Sending number : 16 Sending number : 25 Sending number : 36 Sending number : 49 Sending number : 64 Sending number : 81 Sending number : 100 Sending number : 121 Sending number : 144 Received number: 0 Received number: 2 Received number: 3 Received number: 4 Received number: 5 Received number: 6 Received number: 7 Received number: 8 Received number: 9 Received number: 10 Received number: 11 Received number: 12 Received number: 13 Received number: 169
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Can you see that the output is broken? >>... >>Sending number : 0 >>Sending number : Received number: 01 >>Sending number : >>Received number: 2 >>... It is clearly a problem with 'std::cout << ... << std::endl' and it looks like it doesn't have a critical section that controls access to a CONSOLE device. So, if you save your data in an array everything should be correct. Do you need modified sources? Best regards, Sergey Note: As I already mentioned all tests are done with older TBB version 4.0 Update 3 ( Commercial-Aligned Release ) and Visual Studio 2005 in Debug and Release configurations.
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Just one more note... >>...So, if you save your data in an array everything should be correct. Please take into account that you will need a synchronization object in order to control access to that 'magic'-array of calculated values.
0 Kudos
Michael_K_4
Beginner
913 Views
Hi Sergey, thanks a lot for taking the time to check the test case so far. I am aware that the actual output would need proper synchronizing / ordering in a real application. However, that was not the issue I wanted to report. (I deliberately kept the output statements in the test case in this simple way.) The actual problem is that TBB stops execution of the flow graph prematurely, but this happens only in V4.1 Update 1. The version you were using (4.0 Update 3, commerical-aligned release) works fine in that respect.
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Hi Michael, >>The actual problem is that TBB stops execution of the flow graph prematurely, but this happens only in V4.1 Update 1... I won't be able to investigate your test-case with TBB v4.1 Update 1 but I would suggest you to compare differences in source files for the Flow Graph functionality with Microsoft's Windiff utility. I think this is the simpliest way to detect what was changed. As soon as you see these differences you can try to debug in order to see how the new version of Flow Graph works and why it stops execution.
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Hi Michael, >>...In the transition from TBB "4.1" to "4.1 Update 1"... Could you post an example of the output ( possibly partial... ) when calculating squares for 14 or 28 numbers, please?
0 Kudos
Michael_K_4
Beginner
913 Views
Hi Sergey, > Could you post an example of the output ( possibly partial... ) when calculating squares for 14 or 28 numbers, please? Sure. I'm attaching an updated test case where the output is done with printf(), and the number of numbers is configurable through the NUMNUMBERS #define. (edit: I also changed the squaring-node concurrency from unlimited to serial, but that doesn't affect the issue). Attached is the output of the program for the two cases NUMNUMBERS=14 and NUMNUMBERS=28, respectively, for the "good" TBB V4.1 (20120718). Also attached is the output of the program for the two cases NUMNUMBERS=14 and NUMNUMBERS=28, respectively, for the "bad" TBB V4.1 Update 1 (20121003). You can clearly see that the flow-graph execution terminates prematurely, independent of the actual setting of NUMNUMBERS.
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Thank you. >>... >>Attached is the output of the program for the two cases NUMNUMBERS=14 and NUMNUMBERS=28, respectively, for the "good" >>TBB V4.1 (20120718). >> >>Also attached is the output of the program for the two cases NUMNUMBERS=14 and NUMNUMBERS=28, respectively, for the "bad" >>TBB V4.1 Update 1 (20121003). You can clearly see that the flow-graph execution terminates prematurely... I can see it and It is interesting that only 9 numbers are sent for both "bad" cases. Did you try to compare the flow graph sources?
0 Kudos
Michael_K_4
Beginner
913 Views
> Did you try to compare the flow graph sources? Yes, I did. The difference is not a simple one-liner, however - I don't see how to quickly fix it myself. I don't fully understand the flow-graph internals yet.
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
>>...The difference is not a simple one-liner, however - I don't see how to quickly fix it myself. I don't fully understand the flow-graph >>internals yet... I hope to hear from TBB software developers regarding the problem with TBB v4.1 Update 1. I'm currently investigating another issue related to memory leaks in the latest version of TBB. It looks like the the update created a set of fresh issues / problems.
0 Kudos
Abhishek81
Novice
913 Views
@ Sergev can you put an insight what does TBB does? I am very new to it...Thanks
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Hi, >>...can you put an insight what does TBB does? I am very new to it... A very short answer: It is a highly portable library of C++ template classes that allows to parallelize some processing. Please take a look at: http://www.threadingbuildingblocks.org and http://en.wikipedia.org/wiki/Intel_Threading_Building_Blocks If you really interested in parallel programming I recommend you to download some latest version of TBB, for example, version 4.1. The library has many test examples which demonstrate application of different techniques to parallelize some processing. Best regards, Sergey
0 Kudos
SergeyKostrov
Valued Contributor II
913 Views
Hi Michael, >>>>Did you try to compare the flow graph sources? >> >>Yes, I did. The difference is not a simple one-liner, however - I don't see how to quickly fix it myself. I don't fully understand >>the flow-graph internals yet. As I already mentioned I'm still using TBB 4.0 Update 3 ( Commercial-Aligned Release ) but I will be to test your test-case with: TBB: VERSION 4.1 TBB: INTERFACE VERSION 6101 TBB: BUILD_DATE Wed, 3 Oct 2012 13:45:05 UTC TBB: BUILD_HOST FXEOWIN16 TBB: BUILD_OS I'll post results of my investigation later.
0 Kudos
Michael_K_4
Beginner
913 Views
> TBB: INTERFACE VERSION 6101 Yes, that's exactly the version where the bug occurs. Thanks for taking care of this.
0 Kudos
RafSchietekat
Valued Contributor III
913 Views
Any progress, Sergey? I had already tried to pinpoint the problem, myself, but, because of the substantial changes (not mentioned in CHANGES!), I almost immediately concluded (not unlike Michael) that I would prefer to first have Intel's TBB team have another look, instead. Any progress, TBB team?
0 Kudos
SergeyKostrov
Valued Contributor II
836 Views
Hi everybody, >>Any progress, Sergey? I'll be able to look on Monday and I'll keep you informed.
0 Kudos
Reply