public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox