Re: [Qemu-devel] [PATCH v4 5/5] 9p: Use variable length suffixes for inode remapping

[Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>]

On Freitag, 28. Juni 2019 16:56:15 CEST Christian Schoenebeck via Qemu-devel 
> > > + */
> > > +#define EXP_GOLOMB_K    0
> > > +
> > > +# if !EXP_GOLOMB_K
> > > +
> > > +/** @brief Exponential Golomb algorithm limited to the case k=0.
> > > + *
> > 
> > This doesn't really help to have a special implementation for k=0. The
> > resulting function is nearly identical to the general case. It is likely
> > that the compiler can optimize it and generate the same code.
> 
> I don't think the compiler's optimizer would really drop all the
> instructions automatically of the generalized variant of that particular
> function. Does it matter in practice? No, I actually just provided that
> optimized variant for the special case k=0 because I think k=0 will be the
> default value for that parameter and because you were already picky about a
> simple
> 
> 	if (pdu->s->dev_id == 0)
> 
> to be optimized. In practice users won't feel the runtime difference either
> one of the two optimization scenarios.

I just checked my assmption made here with a simple C test unit:

	// Use manually optimized function for case k=0.
	VariLenAffix implK0(uint64_t n) {
	    return expGolombEncodeK0(n);
	}

	// Rely on compiler to optimize generalized function for k=0
	VariLenAffix implGenK(uint64_t n) {
	    return expGolombEncode(n, 0);
	}

And :   gcc -S -O3 -ffast-math k.c

Like expected the generated 2 functions are almost identical, except that the 
manually optimized variant saves the following 3 instructions:

	movl	$0, %eax
	...
	testl	%edx, %edx
	cmovns	%edx, %eax

But like I said, it is a tiny difference of course. Not really relevant in 
practice.

Best regards,
Christian Schoenebeck