>>... I've performed the timing test on two identical HW platforms which have dual Xeon X5680 3.33GHz CPUs.

Could you post your data, please? What about a test-case? Thanks in advance.

There should be some differences between those two OSs , because of different architecture implementation.

I would be great if we had a test case, as Sergey mentioned. It will help debugging if there are any issues.

>>... I've just finished running some loop timings on the Lanczos resizer I mentioned earlier, and for Windows the loop runs in
>>3 minutes 36 seconds, and under Linux it's 4 minutes 2 seconds. This seems like a big difference to me...

I wouldn't expect absolutely identical numbers and some difference in times could be contributed by:

- different C/C++ compilers
- different optimization options selected for C/C++ compilers
- significant differences in OSs ( as Iliya mentioned )
- different workload of OSs ( services, network support, etc )

So, there are many things that affect performance on both platforms.

What compilers did you use?

I have lots of test cases and tests compiled with MS or Intel C/C++ compilers for Windows almost always outperform tests compiled with MinGW C/C++ compiler for Windows. Many tests compiled with a legacy Borland C/C++ compiler ( 15+ year-old technology ) outperform all modern C/C++ compilers (!) mentioned above.

In your case a test on Linux is ~10% slower than a test on Windows and in overall it matches to my numbers.

>>>How much of a difference would you expect. I've just finished running some loop timings on the Lanczos resizer I mentioned earlier, >>>
It is hard to say exactly how much of a difference you can excpect.Such a difference could be described as function of many variables which are tightly coupled to Linux internal architecture.

>>...I would not expect the compiler to affect the speed much since a majority of the work is being performed within the IPP calls which
>>should resolve to hand coded asm (correct?).

Yes, that is correct. Here are a couple of more comments:

- Try to boost a priority of your application to 'High' or 'Real-Time' on both platforms in order to preempt as many as possible processes and threads existing / working at the same time. I always do this when measuring performance of some piece(s) of codes.

- Try to set ( force ) a process / thread affinity mask to one CPU

Note: For these two cases I could provide two small examples for Windows but for Linux you'll need to understand how to do the same

- Try to use the same -O2 optimization option with Visual Studio 2010

By the way, do you have the same BIOS settings on both computers? The most important settings are as follows:

- Intel Hyper-Threading Technology
- Intel TurboBoost Technology
- Intel SpeedStep Technology

>>> Try to boost a priority of your application to 'High' or 'Real-Time' on both platforms in order to preempt as many as possible processes and threads existing / working at the same time. I always do this when measuring performance of some piece(s) of codes.>>>

Exact implementation of scheduler and dispatcher on Linux platform could differ from Windows OS.Moreover kernel code activity(mostly interrupt)driven drivers could also affect fine grain time measurement on Linux platform.
So I think that you can not directly compare those two OSs.Even a few dozens of different asm instruction(directly compiled from the kernel source)which are not used on Win OS components and those instructions could pollute the results of such a comparision.

Here you can see the exact comparision between thos two OSs :http://widefox.pbworks.com/w/page/8042290/Architecture
For example please look at scheduler latency results you can see that Linux scheduler has much lower latency that its Windows counterpart.

Here are my notes:

>>...Linux scheduler has much lower latency that its Windows counterpart...

A scheduling engine for family of Windows NT based OSs was designed by one of the best expert in multi-processing from VAX in 1990th. That design was initially introduced in first versions of Windows NT ( 1.x, 2.x, 3.x, or so ).

Take a look at:
http://widefox.pbworks.com/w/page/8042322/Scheduler

>>Kernel Comparison: Linux (2.6.28) versus Windows (Vista SP1)
>>...
>>...
>>Timeslice - Multiprocessor
>>Scheduler - Multiprocessor (timeslice) Linux Windows
>>timeslice - range 10ms-200ms' 15ms-180ms (Client)
>>180ms (Server')
>>...
>>...
>>timeslice - default 100ms' 30ms, 60ms, 90ms (Client)
>>180ms (Server)'
>>...
>>...
>>Performance
>>Scheduler (performance) Linux Windows
>>scheduling latency (average) 0.009mS' 2mS10'
>>scheduling latency (worse) 0.3mS' 16mS10'
>>...

- The report favours Linux by default but I don't defend Windows

- The report compares latest version of kernel for Linux with some older release(s) of Windows:

...
Compared Version: Linux Q1 2009 vs Windows Q1 2008
Initial Release: Q4 2008 vs Windows Q1 2007
Latest Release: Q3 2011 vs Windows Q1 2011
...

- Latencies could NOT be deterministic.

One of IDZ users tested my test-case on his computer with a latest Intel CPU and reported that a switch from thread A to thread B was completed in 38 nanoseconds.

Personally, I wouldn't worry about performance differences on different OSs if numbers for some test(s) differ by less than ~10%.

>>...One of IDZ users tested my test-case on his computer with a latest Intel CPU and reported that a switch from thread A to thread B
>>was completed in 38 nanoseconds

Forum topic: Synchronizing Time Stamp Counter
Web-link: http://software.intel.com/en-us/forums/topic/332570

>>>A scheduling engine for family of Windows NT based OSs was designed by one of the best expert in multi-processing from VAX in 1990th.>>>
Was it Dave Cutler?

>>>- The report compares latest version of kernel for Linux with some older release(s) of Windows:>>>
You are right I have forgotten to mention it in my post.

Another thing you can do is wrap timer calls around just the IPP code to narrow it down in both the Linux and Windows cases.

>>>A scheduling engine for family of Windows NT based OSs was designed by one of the best expert in multi-processing
>>from VAX in 1990th.
>>
>>Was it Dave Cutler?

That is possible. I don't remember his name but I remember that I read it in a book about history of Microsoft ( possibly written by Bill Gates or somebody else from Microsoft ).

>>...Windows vs. Linux...

By the way, in the middle of 1990th everybody was comparing Windows vs. OS/2 Wrap. Does anybody remember it? Unfortunately, OS/2 Wrap has not survived.

PS: Some time in June 1995, two months before a release of Windows 95, I had a very exciting dialog about Windows and OS/2 OSs with a very experienced system software developer and I will reproduce our conversation later...

>>...One thing I've noticed (at least under Windows), is that if you have a lot of other things happening in between the IPP call,
>>you can get some IPP slowdown...

That is why I recommended to boost a priority of a test process during tests. But, be carefull when an IPP function uses OpenMP threads because they are executed at 'Normal' priorities. If you boost a priority of your main thread to 'High' or 'Real-Time' then IPP OpenMP threads will be preempted and your test will work slower. So, you need to disable OpenMP threads for IPP functions.

Here is an example of boosting a priority of a thread for a Windows platform:
...
::SetThreadPriority( ::GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL );

uiTicksStart = SysGetTickCount();
//...
// Some processing
//...
uiTicksEnd = SysGetTickCount();

::SetThreadPriority( ::GetCurrentThread(), THREAD_PRIORITY_NORMAL );
...