Intel Software Network - feed

idea for improveming the performance

Mon, 23 Nov 2009 21:56:09 -0800

the SW architecture like this:

TASK1(Gbps packets input)---TASK2(pre-processed)-TASK3A,TASK3B,TASK3C....(all of them are processing engine)--TASK4(output)

my questions:

1.the packet are coming in continually,so I don't thind it is necessary to keep the cache HOT?(and I don't know how to do that,all packets are alloced in TASK1,and each TASK runs on different CPU,it is not like the TBB:pipeline mode)

2.input packet will be copied to a buf(alloced from a memory pool with malloc),necessary to use cache_aligned_llocator<> to replace the malloc?(again,the content of buf changed quickly and frequently)

Tuning Advice given by Intel VTune for tbb.dll and tbbmalloc.dll

Mon, 23 Nov 2009 05:44:32 -0800

I sampled my application with Intel VTune profiler and the following is about the results it gave.

My application comprises of an application.dll and a Test.exe both of which extensively use tbb.dll and tbbmalloc.dll. I use task interface, concurrent_queue, concurrent_hash_map from tbb.dll and cache_aligned_allocator from tbbmalloc.dll.Iam using the tbb22_20090809oss version.

Here are the results which the Intel Tuning assistant gave
Process/Module Summary (Process: test.exe, Module: msvcr80.dll, RVA: 0x23ed-0x504a7)
CPU_CLK_UNHALTED.CORE: 18,501,600,000

Time Statistics
CPU_CLK_UNHALTED.CORE: 18,501,600,000 events
Processor Time: 7.73 sec
Accounts for 44.48% (workload)

Process/Module Summary (Process: test.exe, Module: test.exe, RVA: 0x10b0-0x7f06)
CPU_CLK_UNHALTED.CORE: 18,400,800,000

Time Statistics
CPU_CLK_UNHALTED.CORE: 18,400,800,000 events
Processor Time: 7.69 sec
Accounts for 44.24% (workload)

Process/Module Summary (Process: test.exe, Module: application.dll, RVA: 0x1017-0x488a)
CPU_CLK_UNHALTED.CORE: 225,600,000

Time Statistics
CPU_CLK_UNHALTED.CORE: 225,600,000 events
Processor Time: 0.094 sec
Processor Time: 0.094 sec
Accounts for 0.54% (workload)

Other Possible Problems
CPI (Cycles Per retired Instruction) is poor: 1.92 clockticks per instructions retired

Process/Module Summary (Process: test.exe, Module: tbb.dll, RVA: 0x91d0-0x1de61)
CPU_CLK_UNHALTED.CORE: 1,156,800,000

Time Statistics
CPU_CLK_UNHALTED.CORE: 1,156,800,000 events
Processor Time: 0.48 sec
Processor Time: 0.48 sec
Accounts for 2.78% (workload)

Other Possible Problems
CPI (Cycles Per retired Instruction) is poor: 2.8 clockticks per instructions retired

Process/Module Summary (Process: test.exe, Module: tbbmalloc.dll, RVA: 0x1904-0x4139)
CPU_CLK_UNHALTED.CORE: 206,400,000

Time Statistics
CPU_CLK_UNHALTED.CORE: 206,400,000 events

Processor Time: 0.086 sec
Accounts for 0.5% (workload)

Other Possible Problems
Branch mispredictions impact performance: 15.29 % cycles spent in branch misprediction recovery

Advice:
Use the precise events to focus on instructions of interest.
Eliminate branches
Use constants rather than variables or parameters
Improve branch predictability.
Compile with the Interprocedural Optimizations (IPO) switch
Compile with the Profile-guided Basic-block Optimization.
Consider assembly-level branch-prediction tuning.
Measure events required to compute advanced event ratios.

CPI (Cycles Per retired Instruction) is poor: 3.07 clockticks per instructions retired
Advice:
Measure events required to compute advanced event ratios.

Many L2 cache demand misses: 0.0081 L2 cache demand misses per instruction retired
Advice:
Use the precise events to focus on instructions of interest.
Improve data locality, if possible.
Consume data in chunks that fit in the L2 cache.
Better exploit the hardware prefetchers.
Use software prefetching.

Many L2 data cache misses: 0.022 L2 cache misses per instruction retired
Advice:
Use the precise events to focus on instructions of interest.
Improve data locality, if possible.
Consume data in chunks that fit in the L2 cache.
Better exploit the hardware prefetchers.

Many TLB misses: 7.31 % cycles spent on TLB misses
Advice: Measure events required to understand the type of TLB misses.

As seen in the results the Intel Vtune profiler doesnt have much to advice on my application.dll and Test.exe. But it gives lot of advices on tbbmalloc.dll and tbb.dll. Does this have anything to do with the way of usage of tbb?

What is CPI(cycles per retired instruction)? what value of it is not poor?

why does it show a huge Branch mispredictions impact performance in tbbmalloc.dll? And are the values of L2 cache demand misses, L2 data cache misses, TLB misses acceptable? Also is L2 cache demand miss and L2 data cache miss related to each other?

Race Condition in ParallelMerge?

Fri, 20 Nov 2009 10:19:17 -0800

Attached is a parallel merge sort that is substantially faster than TBB's parallel_sort - it uses parallel_reduce. The speed up comes from using Intel's IPP to do the sort. ParallelMerge (provided with TBB) merges the sorted data from each thread using parallel_reduce.

The sort works all the time with range size = height / (# of processors) and this is probably the most efficient setting for the tile size. However, in testing the smaller range sizes, the stack is corrupted in ParallelMerge. Parallel Studio reports that there is a race condition at the location of the crash. (Parallel Studio has been patched with Update 2 - the latest.)

To reproduce the problem, set TileSize = 1 in the attached code. It is failing on my 8-way Core i7 so TileSize = Height / 8 will work fine. This problem will not fail if TBB is initialized with only 1 thread (single-threaded mode.) The problem may also be circumvented by setting ParallelMerge's Is_Divisible method to always return false (but this leaves a lot of the speed up on the table.)

If anyone could help resolve this problem, it will probably benefit TBB or ParallelMerge. I don't believe the problem is in my code but I am willing to be test any suggestions.

parallel_reduce problem

Thu, 19 Nov 2009 05:21:00 -0800

I know I must be doing something really dumb, but I have not been able to figure out what. I'm basically just doing the simple reduction example in the TBB book, but using the IPP sum routine (sum of all pixels in a Ipp16u plane). Sounds simple enough, but it looks like join() is not being called enough times. Do I ever need to explicitly call join() or does the system always call it?

class Sum
{
public:  // Methods
    Sum(Img *img) : m_img(img), m_sum(0) {}
    void operator () (const tbb::blocked_range &range)
    {
        IppiSize sz;
        Ipp16u *pSrc = (Ipp16u*)m_img->getPixel(0, range.begin(), 0);
        I32 step = m_img->getStep(0);
        sz.width = m_img->getWidth(0);
        sz.height = range.size();

        if (ippStsNoErr != ippiSum_16u_C1R(pSrc, step, sz, &m_sum))
            throw std::runtime_error("ippiSum_16u_C1R failed!\n");
        printf("Sum for %d %d = %0.1f\n", range.begin(), range.end(), m_sum);
    }
    Sum(Sum &x, tbb::split) : m_img(x.m_img), m_sum(0) {}
    void join(const Sum &y) { printf("%0.1f = %0.1f + %0.1f\n", m_sum + y.m_sum, m_sum, y.m_sum); m_sum += y.m_sum; }
    F64 getSum() { return m_sum; }

private: // Attributes
    Img *m_img;
    F64 m_sum;
};

If I call operator() directly it works fine. As soon as I put it inside a parallel_reduce() I get the wrong (smaller) answer. Looking at the diagnostic prints in my code it looks like all sub-regions are computed correctly, but not all of them end up in join() calls.

Peter

Help with writing a parallel application for solving a three dimensional parabolic heat equation

Wed, 18 Nov 2009 19:41:03 -0800

I am working on my final year research..I am supposed to write a parallel system for finding solution to to parabolic partial differential equations. the three dimensional heat equations is my main focus. i need to do this using OpenMP....i want to do everything in Intel Parallel Studio can anyone give me the serial version of this problem at least by providing me with the necessary loops and then advice on where to parallelize

Thanks (Mathew)

performance of tbb for data parallel applications

Wed, 18 Nov 2009 18:03:05 -0800

hi everyone,
iam a novice programer to tbb an trying to evaluate the tbb on an intel 64 architecture. i have few questions on tbb.
1. actually i would like to know whether tbb only achieves better performance(linear speedup) for divide and conquer type problems or is it also possible for data parallel applications as well ?. iam asking this is because i achieved poor performance for data parallel applications and i used only parallel_for() to parallelize the application.
2. one more observation is that the one node execution times of tbb applications very less than others but atlast the speedup achieved on 8-nodes not linear.
3. Also i would like to know whether there is an implicit synchronization barriers in the parallel_for() tasks for the threads or is it the responsibility of the programmer to synchronize.

TBB on linux segfaulting

Wed, 18 Nov 2009 09:10:54 -0800

I have a cross platform program I've written that uses either TBB or OpenMP (not at the same time!). The code is in every respect cross platform, but I initially developed it in Visual Studio.

The program is a framework for developing n-body models.

On Windows it works perfectly, compiling with no errors or warnings, and runs as expected. On Linux (Ubuntu 64 bit) it compiles well, just one warning that wouldn't effect the TBB code, but when I run it, as soon as it tries to begin the first parallel_for class, it segfaults.
I tried using openMP, and the code ran perfectly. Note that the OpenMP and TBB code do not interfere with each other, using them at the same time isn't possible.

Since the parallel code is in my Runge Kutta 4th Order Integrator, I decided to comment out the first Parallel_for block and see if that had a bug in it (replacing it with equivilent serial code), but instead it just segfaults on running the next one it encounters. I deduce from this, and the fact that the same code runs perfectly on Windows, that it is the act of using TBB which is causing the segfault, not the code itself.

On Linux I've compiled it using GCC, with the project managed by Code::Blocks. I've linked tbb, and initialised tbb with a call to
tbb::task_scheduler_init init;

Have I missed something about using TBB on Linux?

I haven't posted lots of code because I rather think the issue is one of setting up TBB, rather than a problem in my code. I can do though, but the project is rather large, so it would be a fair bit to go through.

TBB on Visual studio 2008

Tue, 17 Nov 2009 08:47:26 -0800

I get the following error message upon trying to build the examples attached with TBB

"1>Copying DLLs and PDBs
1>$C:\Program Files\tbb22\ia32\vc9\bin\tbb.dll
1>The filename, directory name, or volume label syntax is incorrect.",

C:\Program Files\tbb22 is my installation directory,

I have included the path C:\Program Files\tbb22\ia32\vc9\lib in library files, and tbb.lib in liker>>additional properties.

Could someone please point out the problem to me or include a link on how to install TBB on VS 2008 ( I have followed the guide in the release notes (or as instructed in this link:

http://software.intel.com/en-us/blogs/2008/07/07/get-tbb-going-by-a-single-click/

, but as pointed out by other users there's no "use Intel TBB option in the project sub menu)

thanks

TBB and Arrandale

Mon, 16 Nov 2009 03:03:13 -0800

Intel has announced the roadmap for the Arrandale chip combining CPU and GPU. Will TBB enable us to utilize this new chip in the future ?

pipeline scheduling tasks

Mon, 16 Nov 2009 00:01:20 -0800

Hi,

a have a problem with pipeline:
say i have a 4 threads, 4 tasks, and 3 pipeline stages:
emit(serial), worker(not serial), and join(serial)

but if i run a code - a got following output:

processing with 4 files (4 threads)
emit __cdb_tbench-0
emit __cdb_tbench-1
worker: __cdb_tbench-0
emit __cdb_tbench-2
emit __cdb_tbench-3
worker: __cdb_tbench-0 done
joining : __cdb_tbench-0
worker: __cdb_tbench-1
joining : __cdb_tbench-0 done: 10000000
worker: __cdb_tbench-1 done
joining : __cdb_tbench-1
worker: __cdb_tbench-2
joining : __cdb_tbench-1 done: 10000000
worker: __cdb_tbench-2 done
joining : __cdb_tbench-2
worker: __cdb_tbench-3
joining : __cdb_tbench-2 done: 10000000
worker: __cdb_tbench-3 done
joining : __cdb_tbench-3
joining : __cdb_tbench-3 done: 10000000
Done.

worker stage is nearly to 1 sec, join is faster.

looks like stages are interleaved, but worker() never called in parallel,
can you advise why ?

code looks like:

template
struct Stage : public tbb::filter {
T& ticket;
Stage(T& ticketIn) : tbb::filter(serial), ticket(ticketIn) {}
virtual ~Stage() throw() {}
virtual void* operator()(void* item)
{
return ((&ticket)->*callback)(item);
}
....
tbb::pipeline pl;
internal::Stage s1(ticket);
internal::Stage s2(ticket);
internal::Stage s3(ticket);

pl.add_filter(s1);
pl.add_filter(s2);
pl.add_filter(s3);
pl.run(data.size());