>
>
> Processor affinity is a tweak. A micro-optimization, if you like. It is
> a technique that is meant for reducing the overhead just a little more,
> to squeeze a bit more performance out of a program. That has nothing to
> do with the problem at hand.
>
> Our problem is this. We have X mips at our disposal, but instead of
> having all X at our disposal, we have X/n mips at our disposal which we
> can parallelize up to a parallel level of n. The question is, how do we
> create an algorithm that can take advantage of this.
Hmm interesting thanks for the eye opener...not such a rare problem for
single/dual threaded apps it seems:
http://en.wikipedia.org/wiki/Intel_Core_2#Kentsfield if the article is
anything to go by.
If n is greater than 2, we have one CPU encrypting full steam, another one
> that uses some of its time for compressing, and the rest of the CPUs are
> not utilized by rsyncrypto.
I assume you meant vice versa (one cpu with gzip compressing full steam, the
other with rsyncrypto hovering at around 15%)... or at least that's whats
happening on my pc.
PS I mistakenly used autofd.h instead of win32/autofd.h in the previous
"patch" file. Obviously this problem does not exist on linux, but the
insertion remains the same.
Cheers
Julian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rsyncrypto-devel mailing list
Rsyncrypto-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsyncrypto-devel
