Hi,
> On 7 Nov 2014, at 07:52, Anand Avati <av...@gluster.org> wrote:
> On Thu, Nov 6, 2014 at 8:22 PM, Anton Altaparmakov <ai...@cam.ac.uk> wrote:
> > On 7 Nov 2014, at 01:46, Jeff Moyer <jmo...@redhat.com> wrote:
> > Minor nit, but I'd rather read something that looks like this:
> >
> > if (type == READ && (flags & RWF_NONBLOCK))
> > return -EAGAIN;
> > else if (type == WRITE && (flags & RWF_DSYNC))
> > return -EINVAL;
>
> But your version is less logically efficient for the case where "type ==
> READ" is true and "flags & RWF_NONBLOCK" is false because your version then
> has to do the "if (type == WRITE" check before discovering it does not need
> to take that branch either, whilst the original version does not have to do
> such a test at all.
>
> Seriously?
Of course seriously.
> Just focus on the code readability/maintainability which makes the code most
> easily understood/obvious to a new pair of eyes, and leave such
> micro-optimizations to the compiler..
The original version is more readable (IMO) and this is not a
micro-optimization. It is people like you who are responsible for the fact
that we need faster and faster computers to cope with the inefficient/poor code
being written more and more...
And I really wouldn't hedge my bets on gcc optimizing something like that. The
amount of crap assembly produced from gcc that I have seen over the years
suggests that it is quite likely it will make a hash of it instead...
Best regards,
Anton
> Thanks
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
University of Cambridge Information Services, Roger Needham Building
7 JJ Thomson Avenue, Cambridge, CB3 0RB, UK
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
