All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaime Arrocha <jarr@innercoder.com>
To: David Laight <David.Laight@ACULAB.COM>,
	"'Austin S Hemmelgarn'" <ahferroin7@gmail.com>,
	Steve Calfee <stevecalfee@gmail.com>,
	Eric Curtin <ericcurtin17@gmail.com>
Cc: Valentina Manea <valentina.manea.m@gmail.com>,
	"shuah.kh@samsung.com" <shuah.kh@samsung.com>,
	USB list <linux-usb@vger.kernel.org>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: First kernel patch (optimization)
Date: Wed, 16 Sep 2015 20:49:42 -0500	[thread overview]
Message-ID: <55FA1C36.7060007@innercoder.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CB97D13@AcuExch.aculab.com>


On 09/16/2015 07:56 AM, David Laight wrote:
> From: Austin S Hemmelgarn
>> Sent: 16 September 2015 12:46
>> On 2015-09-15 20:09, Steve Calfee wrote:
>>> On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin <ericcurtin17@gmail.com> wrote:
>>>> Signed-off-by: Eric Curtin <ericcurtin17@gmail.com>
>>>>
>>>> diff --git a/tools/usb/usbip/src/usbip_detach.c b/tools/usb/usbip/src/usbip_detach.c
>>>> index 05c6d15..9db9d21 100644
>>>> --- a/tools/usb/usbip/src/usbip_detach.c
>>>> +++ b/tools/usb/usbip/src/usbip_detach.c
>>>> @@ -47,7 +47,9 @@ static int detach_port(char *port)
>>>>           uint8_t portnum;
>>>>           char path[PATH_MAX+1];
>>>>
>>>> -
>>>> +       unsigned int port_len = strlen(port);
>>>> +
>>>> +       for (unsigned int i = 0; i < port_len; i++)
>>>>                   if (!isdigit(port[i])) {
>>>>                           err("invalid port %s", port);
>>>>                           return -1;
>>>>
>>>> --
>>> Hi Eric,
>>>
>>> This is fine, but what kind of wimpy compiler optimizer will not move
>>> the constant initializer out of the loop? I bet if you compare binary
>>> sizes/code it will be exactly the same, and you added some characters
>>> of code. Reorganizing code for readability is fine, but for compiler
>>> (in)efficiency seems like a bad idea.
>> While I agree with your argument, I would like to point out that it is a
>> well established fact that GCC's optimizers are kind of brain-dead at
>> times and need their hands held.
>>
>> I'd be willing to bet that the code will be marginally larger (because
>> of adding another variable), but might run slightly faster too (because
>> in my experience, GCC doesn't always catch things like this), and should
>> compile a little faster (because the optimizers don't have to do as much
>> work).
> The compiler probably can't optimise the strlen().
> If isdigit() is a real function (the locale specific one probably is)
> then the compile cannot assume that port[n] isn't changed by the call
> to isdigit.
>
> A simpler change would be:
> 	for (unsigned int i = 0; port[i] != 0; i++)
>
> Much better would be to use strtoul() instead of atoi().
>
> 	David
>
I actually took some time to verify this. GCC makes this optimization 
with -O2 at least on gcc 4.7.2.
One interesting observation I found was that in O0 and O2, it does make 
a call to strlen while in O1 it calculates
the length of the string using:

repnz scas    %es:(%rdi),%al
not                %rcx
sub               $0x2,%rcx

Why does it do that? Is the code above faster? If yes, why not do it in 
O2 too?
Is this still a topic for this forum?


gcc version 4.7.2 (Debian 4.7.2-5)
code

void conv_input(char *port)
{
     int portnum;

     for(int i = 0; i <strlen(port); i++)
         if(!isdigit(port[i])) {
             printf("invalid port %s", port);
             exit (1);
         }

     portnum = atoi(port);
     printf("Port number: %d\n", portnum);
}

Optimization done?
              O0    O1    O2
x86        No    No    Yes
amd64   No   No    Yes


  reply	other threads:[~2015-09-17  2:05 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15 19:53 First kernel patch (optimization) Eric Curtin
2015-09-15 20:11 ` Felipe Balbi
2015-09-16  0:09 ` Steve Calfee
2015-09-16 11:45   ` Austin S Hemmelgarn
2015-09-16 12:56     ` David Laight
2015-09-17  1:49       ` Jaime Arrocha [this message]
2015-09-17  8:45         ` David Laight
2015-09-16 13:24     ` Greg KH
2015-09-16 16:03       ` Eric Curtin
2015-09-16 16:40         ` Theodore Ts'o
2015-09-16 17:24           ` Raymond Jennings
2015-09-16 17:26           ` Josh Boyer
2015-09-18  3:12             ` Theodore Ts'o
2015-09-18  7:42               ` Greg KH
2015-09-18  9:31                 ` Raymond Jennings
2015-09-18 19:08                   ` Austin S Hemmelgarn
2015-09-19  2:26                 ` Theodore Ts'o
2015-09-19  4:22                   ` Sudip Mukherjee
2015-09-19  5:18                   ` Greg KH
2015-09-19 12:20                     ` Theodore Ts'o
2015-09-19 12:52                     ` Alexander Holler
2015-09-19 14:14                       ` Alexander Holler
2015-09-19 14:22                       ` Theodore Ts'o
2015-09-19 17:47                         ` Alexander Holler
2015-09-20  2:21                           ` Theodore Ts'o
2015-09-20 10:41                             ` Alexander Holler
2015-09-21 15:47                               ` Austin S Hemmelgarn
2015-09-21 17:20                                 ` Alexander Holler
2015-09-21 18:41                                 ` Alexander Holler
2015-09-23  8:59                               ` Alexander Holler
2015-09-28  6:54                     ` Thiago Farina
2015-09-28 14:20                       ` Greg KH
2015-09-16 20:02         ` Greg KH
2015-09-16 20:21           ` Eric Curtin
2015-09-16 22:38             ` Greg KH
2015-09-22 17:38 ` Linus Torvalds
2015-09-22 18:18   ` Eric Curtin
2015-09-25 22:06     ` Dmitry Torokhov
2015-09-26 13:28       ` Eric Curtin
2015-09-29 13:51         ` Austin S Hemmelgarn
2015-09-29 14:47           ` Eric Curtin
  -- strict thread matches above, loose matches on Subject: below --
2015-09-15 19:52 Eric Curtin
2015-09-15 21:57 ` Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55FA1C36.7060007@innercoder.com \
    --to=jarr@innercoder.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=ahferroin7@gmail.com \
    --cc=ericcurtin17@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=shuah.kh@samsung.com \
    --cc=stevecalfee@gmail.com \
    --cc=valentina.manea.m@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.