|
Hello,
On Fri, 24 May 2013, Julian Anastasov wrote:
> On Thu, 23 May 2013, Simon Kirby wrote:
> > Hmm, I was comparing atomic_t being s32 versus u32, not u64 being u64. :)
> > Anyway, the .s results are much easier to read, and (closer to) reality!
> > I did a comparison with (__u64)loh * atomic_read(dest->weight) versus
> > (__u64)loh * (__u32)atomic_read(dest->weight) on both arches and uploaded
> > them to http://0x.ca/sim/ref/3.9-ipvs/. It's not a huge difference, but I
> > prefer the shorter/faster version. ;)
>
> I now see why your patch shows difference compared
> to my tests month ago. This change is the culprit:
>
> - int loh, doh;
> + unsigned int loh, doh;
>
> It effectively changes the operation from:
>
> (__u64/__s64) int * int
>
> into
>
> (__u64) unsigned int * int
>
> that is why you fix it by using __u32:
>
> (__u64) unsigned int * unsigned int
>
> so that both operands are from same 4-byte signedness.
>
> I think, we should keep loh and doh to be int, may be
> the following both solutions should generate 32x32 multiply:
>
> 1. same as my first email:
>
> int loh, doh;
>
> (__u64/__s64) loh * atomic_read(&dest->weight)
>
> In this case I see only one difference between
> __u64 and __s64:
>
> - jb .L41 #,
> - ja .L79 #,
> + jl .L41 #,
> + jg .L79 #,
>
> 2. Your patch:
>
> unsigned int loh, doh;
>
> (__u64) loh * (__u32) atomic_read(&dest->weight)
> or
> (__s64) loh * (__u32) atomic_read(&dest->weight)
>
> Both solutions generate code that differs only
> in imul vs. mul. In internet I see that imul is
> preferred/faster than mul. That is why I prefer solution 1,
> it has less casts.
>
> So, I think you can change your patch as follows:
>
> 1. Use int for loh, doh. Note that some schedulers
> use 'unsigned int' and should be patched for this
> definition: NQ, SED, WLC
>
> 2. Use (__u64) prefix only, no (__u32) before atomic_read:
> LBLC, LBLCR, NQ, SED, WLC
>
> (__u64) loh * atomic_read(&dest->weight) ...
> (__u64) doh * ...
>
> 3. Explain in commit message that we find the
> result64=int32*int32 faster than result64=uint32*uint32
> and far better than using 64*64 multiply which is
> a bit slower on older CPUs.
Simon, any progress on this change? I can
continue and finish it if you prefer so?
Regards
--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
