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

[Michael_K_4]

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

[SergeyKostrov]

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

[RafSchietekat]

Original posting confirmed (on Linux, for tbb41_20120718oss_src.tgz and tbb41_20121003oss_src.tgz to be explicit).

[SergeyKostrov]

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.

[SergeyKostrov]

>>...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

[SergeyKostrov]

>>...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

[SergeyKostrov]

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.

[SergeyKostrov]

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.

[Michael_K_4]

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.

[SergeyKostrov]

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.

[SergeyKostrov]

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?

[Michael_K_4]

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.

[SergeyKostrov]

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?

[Michael_K_4]

> 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.

[SergeyKostrov]

>>...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.

[Abhishek81]

@ Sergev can you put an insight what does TBB does? I am very new to it...Thanks

[SergeyKostrov]

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

[SergeyKostrov]

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.

[Michael_K_4]

> TBB: INTERFACE VERSION 6101 Yes, that's exactly the version where the bug occurs. Thanks for taking care of this.

[RafSchietekat]

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?

[SergeyKostrov]

Hi everybody, >>Any progress, Sergey? I'll be able to look on Monday and I'll keep you informed.