Alex
Alex

Reputation: 5247

C# program works faster on slower PC and vice versa

I have an OCR program, written with C# (WinForms app). So it's main purpose is to crop, modify, compare, ocr images.. no more or less. When I run this program on slower machine - I'm getting better results!

My main machine (stationary PC):

notebook's config (benq joybook P52)

Can you guess what's faster?

So the question is - how will you explain this abnormal performance? Is it possible to increase performace on my main PC?

P.S.: I know it's hard to say without looking at the code.. sorry about that

Upvotes: 1

Views: 936

Answers (4)

Arne
Arne

Reputation: 3074

Is your application multi-threaded? I read this a little while ago, maybe it doesn't apply for your situation, but very interesting nonetheless.

Basically, the processor type combined with amount of cores and the memory model of your application can have a lot to say.

http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/

Excerpt:

On some processors, not only must the compiler avoid certain optimizations on volatile reads and writes, it also has to use special instructions. On a multi-core machine, different cores have different caches. The processors may not bother to keep those caches coherent by default, and special instructions may be needed to flush and refresh the caches.

The mainstream x86 and x64 processors implement a strong memory model where memory access is effectively volatile. So, a volatile field forces the compiler to avoid some high-level optimizations like hoisting a read out of a loop, but otherwise results in the same assembly code as a non-volatile read.

The Itanium processor implements a weaker memory model. To target Itanium, the JIT compiler has to use special instructions for volatile memory accesses: LD.ACQ and ST.REL, instead of LD and ST. Instruction LD.ACQ effectively says, “refresh my cache and then read a value” and ST.REL says, “write a value to my cache and then flush the cache to main memory”. LD and ST on the other hand may just access the processor’s cache, which is not visible to other processors.

Upvotes: 0

Daniel Armstrong
Daniel Armstrong

Reputation: 849

I would say profile both (I use jetbrains) and you may find a hotspot on the faster machine that you were not expecting.

Also I would say OS is a big difference, perhaps get a hold of a usb bootable mini XP, 200-300mb download. And run the code on the good machine in that.

Also the same could be tested with 2 VM's just create one VM with XP and one with windows 7 and see if there is a difference on the same hardware.

Upvotes: 0

Cronan
Cronan

Reputation: 193

Without more information it's hard to say, but IF you're running code compiled for x64 on your stationary PC, you could be seeing a problem I've had on a client site. 64-bit code uses larger numbers, so may fill up the processor cache quicker, meaning your code runs slower. Here is a previously answered question that deals with the same issue: How can compiling my application for 64-bit make it faster or better?

Upvotes: 0

RQDQ
RQDQ

Reputation: 15579

OCR is non-trivial code. The most logical first step is to measure! Profile the performance against the exact same test data in both environments. That should give you an idea of which pieces of code are taking the longest on the "faster" machine.

Upvotes: 4

Related Questions