does a Qt application run faster on a windows 64 bit machine?

[pkohut]

In the code you have these macros defined

#define Drc     Data[r][c]
#define DrcOutlet     Data[r_outlet][c_outlet]
#define MV(r,c) IS_MV_REAL4(&Mask->Data[r][c])
#define FOR_ROW_COL_MV for (int r = 0; r < nrRows; r++)\
		for (int c = 0; c < nrCols; c++)\
		if(!IS_MV_REAL4(&Mask->Data[r][c]))
 
#define FOR_ROW_COL_MV_CH for (int  r = 0; r < nrRows; r++)\
		for (int  c = 0; c < nrCols; c++)\
		if(!IS_MV_REAL4(& ChannelMask->Data[r][c]))

#define Drc     Data[r][c]
#define DrcOutlet     Data[r_outlet][c_outlet]
#define MV(r,c) IS_MV_REAL4(&Mask->Data[r][c])
#define FOR_ROW_COL_MV for (int r = 0; r < nrRows; r++)\
		for (int c = 0; c < nrCols; c++)\
		if(!IS_MV_REAL4(&Mask->Data[r][c]))

#define FOR_ROW_COL_MV_CH for (int  r = 0; r < nrRows; r++)\
		for (int  c = 0; c < nrCols; c++)\
		if(!IS_MV_REAL4(& ChannelMask->Data[r][c]))

To copy to clipboard, switch view to plain text mode 

Normally, not a big fan of macros, but in this circumstance they work well.

With the exception of any code that relies on variables r and c directly (looked like only a few), the macros can be changed and loops simplified (flattened). How much of a speed up is unknown. I'd change a few functions and benchmark to see if the effort is worth it.

// return the row and col index, computed from input idx and nCols
void RowColFromIndex(int & row, int & col, int idx, int nCols)
{
    row = idx / nCols;
    col = idx % nCols;
}
 
// return the flat index computed from inputs row, col, nCols
int IndexFromRowCol(int row, int col, int nCols)
{
    return row * nCols + col;
}
 
#define DrcIdx     Data[rIdx][cIdx]
#define FOR_ROW_COL_MV for (int idx = 0; idx < nrRows * nrCols; ++idx)\
		int rIdx, cIdx; \
		RowColFromIndex(rIdx, cIdx, idx, nrCols); \
		if(!IS_MV_REAL4(&Mask->Data[rIdx][cIdx]))
 
#define FOR_ROW_COL_MV_CH for (int  idx = 0; idx < nrRows * nrCols; ++idx)\
		int rIdx, cIdx; \
		RowColFromIndex(rIdx, cIdx, idx, nrCols); \
		if(!IS_MV_REAL4(& ChannelMask->Data[rIdx][cIdx]))

// return the row and col index, computed from input idx and nCols
void RowColFromIndex(int & row, int & col, int idx, int nCols)
{
    row = idx / nCols;
    col = idx % nCols;
}

// return the flat index computed from inputs row, col, nCols
int IndexFromRowCol(int row, int col, int nCols)
{
    return row * nCols + col;
}

#define DrcIdx     Data[rIdx][cIdx]
#define FOR_ROW_COL_MV for (int idx = 0; idx < nrRows * nrCols; ++idx)\
		int rIdx, cIdx; \
		RowColFromIndex(rIdx, cIdx, idx, nrCols); \
		if(!IS_MV_REAL4(&Mask->Data[rIdx][cIdx]))

#define FOR_ROW_COL_MV_CH for (int  idx = 0; idx < nrRows * nrCols; ++idx)\
		int rIdx, cIdx; \
		RowColFromIndex(rIdx, cIdx, idx, nrCols); \
		if(!IS_MV_REAL4(& ChannelMask->Data[rIdx][cIdx]))

To copy to clipboard, switch view to plain text mode 

So, basically anywhere variable r and c are used need to be changed to rIdx and cIdx (using rIdx and cIdx helps find errors while porting).

[wysota]

All those loops can be easy paralellized. These that don't depend on the order of calculations can be done with QtConcurrent or with a simple OpenCL kernel. Those that depend on the order of execution are a bit more tricky but I'm sure they can be sped up as well. If you use OpenCL you can get a speed-up in the magnitude of 10-50x. With QtConcurrent the speed-up depends on the number of cpu cores (so it's probably around 2-4x max). There is also a possibility to use SIMD optimizations available in your CPU such as SSE.

[pkohut]

All those loops can be easy paralellized. These that don't depend on the order of calculations can be done with QtConcurrent or with a simple OpenCL kernel. Those that depend on the order of execution are a bit more tricky but I'm sure they can be sped up as well. If you use OpenCL you can get a speed-up in the magnitude of 10-50x. With QtConcurrent the speed-up depends on the number of cpu cores (so it's probably around 2-4x max). There is also a possibility to use SIMD optimizations available in your CPU such as SSE.

While technically true, there is no free lunch. "easy paralellized" "simple OpenCl kernel", again are dependent an the OP's capabilities and understanding of parallel programming issues.

[wysota]

While technically true, there is no free lunch. "easy paralellized" "simple OpenCl kernel", again are dependent an the OP's capabilities and understanding of parallel programming issues.

It's not that bad. If you have a for loop such as the following:

for(int r = 0; r < rows; ++r) {
    for(int c = 0; c < cols; ++c) {
        doSomething(r,c);
    }
}

for(int r = 0; r < rows; ++r) {
    for(int c = 0; c < cols; ++c) {
        doSomething(r,c);
    }
}

To copy to clipboard, switch view to plain text mode 

Can be rewritten as

QFutureSynchronizer<void> waiter;
for(int r = 0; r < rows; ++r) {
    for(int c = 0; c < cols; ++c) {
        waiter.addFuture(QtConcurrent::run(doSomething, r, c));
    }
}
waiter.waitForFinished(); // or do something else in the meantime

QFutureSynchronizer<void> waiter;
for(int r = 0; r < rows; ++r) {
    for(int c = 0; c < cols; ++c) {
        waiter.addFuture(QtConcurrent::run(doSomething, r, c));
    }
}
waiter.waitForFinished(); // or do something else in the meantime

To copy to clipboard, switch view to plain text mode 

This doesn't require any skills and provided that doSomething() does more than just add two ints together, you will get a decent speed improvement on a multicore system. Of course there is a good chance the loop can be substituted with a flat call to QtConcurrent::mappedReduced(). OpenCL is more tricky although I see the OP's calculations are mostly simple vector operations (additions and multiplications) so the code doesn't need many changes.

[qt_gotcha]

thanks for the help and suggestions guys, I really apreciate it.