Hi,
TBB features aggregator feature. I've posted some thoughts on aggregators here:
http://software.intel.com/en-us/blogs/2013/02/22/combineraggregator-synchronization-primitive
perhaps you may find them interesting. I think some ideas can be applied to TBB, e.g. better aggregation or prefetching.
Dear all
We want to running the nake running program on specific interl cpu core on which there isn't linux operation system. Alternatively, we should running the specific Linux application program on specific core.
Please tell me how to realize this requirement.
Thank you very much.
Hi, all,
I've been working on a paper design for a flow graph and am having difficulties getting something clean, but have an idea of how a hopefully simple TBB addition would make my problem easier.
Basically, I have a graph where a serial multifunction node M is feeding a function node F (which may be serial as well). Node M may generate between 1 and 3 inputs to F for every input it receives.
... -> M -> F -> ...
I am trying to use tbb::parallel_for on a machine with 160 parallel threads (8 Intel E7-8870) and 0.5 TBytes of memory. It is a current Ubuntu system with kernel 3.2.0-35-generic #55-Ubuntu SMP. TBB is from the current download package release 4.1.
Even with a very simple task, I tend to run out of resources, either "bad_alloc" or "thread_monitor Resource temporarily unavailable". I boiled it down to this very simple test, which I attached as test.cpp.
Typical output is
Continued from "Conditional parallelization".
(Original thread for "parallel_sort" that couldn't seem to decide whether to show up or not.)
On a current Intel x86-64 Apple Macintosh (my first use of TBB with OS X on this configuration), with TBB 4.1 update 2 (unpack source distribution, make examples), example graphics were conspicuously absent. The remedy is to disable/remove tbb41_20130116oss/examples/Makefile:113-119 ("# GUI for examples does not support 64-bit platforms" etc.): graphics will now be visible, but upside down.
Is opposite vertical orientation the only reason for deliberately disabling graphics support? That seems a bit harsh...
Had a project on Visual Studio 2010, with TBB tbb40_233oss, on Windows 7. Everything worked well, for long time, through many modifications.
Copied same project to Windows 8, opened with Visual Studio 2012, the project is 'updated' successfully. As usual added TBBROOT env.variable to windows, added all appropriate TBB include and lib references to the project. When compiling - getting error:
error C1004: unexpected end-of-file found ...\tbb41_20130116oss\include\tbb\internal\_tbb_windef.h Line: 37
TBB 4.1 Update 2 stable release is available for download on our site
Changes (w.r.t. TBB 4.1 Update 1):
- Objects up to 128 MB are now cached by the tbbmalloc. Previously
the threshold was 8MB. Objects larger than 128 MB are still
processed by direct OS calls.
- concurrent_unordered_multiset and concurrent_unordered_multimap
have been added, based on Microsoft* PPL prototype.
- Ability to value-initialize a tbb::atomic<T> variable on construction
in C++11, with const expressions properly supported.
Hi
I am doing some measurement with TBB. I noticed that the first call to tbb::parallel_for is slow. I thought, this might come from the task scheduler initialization that is executed the first time a tbb algorithm is called. And yes it had an influence but I don't realy understand the behaviour.
Inserting
task_scheduler_init();
before the first call to tbb::parallel_for is made reduces the time needed for the first call to tbb::parallel_for.
However when I insert:
