|
Hello,
On Mon, 5 Aug 2013, Simon Kirby wrote:
> > 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)
>
> Did you mean here "(__s64) loh * (__s32) atomic_read(&dest->sweight)"?
>
> If not, the results for me on GCC 4.7.2 were what I posted at
> http://0x.ca/sim/ref/3.9-ipvs/.
Reading your reply I see that the key issue you are
missing here is that the type of loh/doh matters, it should
match the type of atomic_read (and its signedness).
As atomic_t is int we prefer loh and doh to be int.
The __u64/__s64 cast before loh/doh does not matter at all.
If both operands are not from same signedness the
32*32 optimization is not applied.
> > 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.
>
> I found that u64*u32 was faster than u64*s32, but I didn't check s64*s32.
It is faster because your loh/doh are u32 and single mul is
generated while for u64*s32 we have u64=u32*s32 which obviously
is not implemented with single imul/mul. Our goal is single imul.
> I checked now and found that u64*u32 and s64*s32 have the same number of
> output instructions on i386, with just the different signedness tests.
> Both actually use imul since it's the comparison after which it cares
> about for signedness.
IIRC, (u64) u32 * u32 uses mul if you compile
with optimizations (-O).
> But what actually makes sense? Do negative weights ever make sense?
__u64/__s64 cast does not matter because both
operands are positive values. As result, this solution
looks better:
int loh, doh;
(__s64) loh * atomic_read(&dest->weight)
because:
- both operands are 'int' => no extra casts before atomic_read
- 'int', not 'unsigned int' because imul is better than mul
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
|
