From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933146AbcFGQnG (ORCPT ); Tue, 7 Jun 2016 12:43:06 -0400 Received: from ns.sciencehorizons.net ([71.41.210.147]:49925 "HELO ns.sciencehorizons.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752637AbcFGQnE (ORCPT ); Tue, 7 Jun 2016 12:43:04 -0400 Date: 7 Jun 2016 12:43:02 -0400 Message-ID: <20160607164302.27585.qmail@ns.sciencehorizons.net> From: "George Spelvin" To: andriy.shevchenko@linux.intel.com, linux@sciencehorizons.net Subject: Re: [PATCH v2 3/2] lib/uuid.c: Silence an unchecked return value warning Cc: bjorn@mork.no, linux-kernel@vger.kernel.org, matt@codeblueprint.co.uk, rv@rasmusvillemoes.dk In-Reply-To: <1465201496.1767.91.camel@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Shevchenko wrote: > ^^^^ Something wrong with mail configuration? Oops, sorry, I forgot to delete the header. > On Sun, 2016-06-05 at 15:25 -0400, George Spelvin wrote: >> It's also faster, as hex_to_bin() *is* inlined within hex2bin() >> (if you compile with -O). > To be sure it faster we need the measurements. Sometimes it's not > obvious. You're right that sometimes measurements show surprising results. But do you want to bet on it? :-) If speed were a primary goal, I'd want to be sure. But as you pointed out, this is not hot-path code and speed is *not* a primary goal. Being off the hot path also makes benchmarking more annoying, as it's hard to define realistic test conditions. (Code resident in L2 but not in L1?) So I think it's reasonable in this case to estimate rather than waste effort striving for certainty. Performing the same basic operations in the same order, but with shorter code and fewer jumps, it's hard not to be faster. It might be measurably faster, or it might be an insignificant change that's not measurable, but barring some bizarre alignment or cache aliasing effect, the chance of it being *slower* is negligible. Speaking pedantically, you're right. But as a practical matter, it's very unlikely, and what makes it truly insignificant is that it's not really a problem even if I'm wrong and the code *is* slower. As you said, size is more important than speed, and I did, at your request, benchmark that. I'm just trying to make the sort of changes that improve *both*. If you have a realistic concern that the patches degrade speed, I can put in a few hours of work to put the different versions into a test harness and measure it accurately. But if this is just a pro forma observation that estimates aren't perfectly reliable, it's not worth the effort.