On 10/17/2016 11:00 AM, SF Markus Elfring wrote:
>>> Calling the function "seq_putc" will be more efficient than "seq_printf"
>>> in this case because of the following reasons.
>>> 1. How does the distribution look like for supported processor architectures
>>> where the data transfer for bytes (as a function call parameter)
>>> is faster than for (string) pointers?
>> How would I know?
> How many processor architecture characteristics do you know already?
x86, s390x, ppc/ppc64.
> * Is a string pointer often longer than a byte?
(Which up to now I thought was basic programming knowledge...)
> * I imagine that it can become also interesting to check byte level data
> under constraints of machine word sizes and alignment.
So, another test for you to do.
>> I would assume that _you_ did some measurements here;
> How much would you trust in any concrete numbers I could present
> for this use case?
> Do you give more trust to a reference testing platform?
At the moment _any_ test would do.
With every response from your side you just keep on asking further
questions. But so far you haven't delivered any answers nor measurements.
>> I could easily claim that seq_printf() is more efficient than
>> seq_putc(), and won't apply your patch.
> This is also possible in principle.
No, this is what's going to happen if you don't show any measurements.
>> So _you_ have to prove that your patch is more efficient.
> How many results would we like to clarify from various hardware
> and software combinations?
See above. At the moment _any_ test result from your side would do.
>>> 2. Did anybody measure already how many the execution times can vary
>>> for these functions?
>> Probably not.
> Thanks for this information.
> How important are the mentioned functions for you within the Linux
> programming interface so far?
Not very. The interface is only used in a slow path, and the execution
time doesn't affect I/O performance in any way.
>> Unless _you_ prove that _your_ patch is more efficient it won't get applied.
> Which data would you accept as a "prove" in this case?
Again: You want something from us. We don't have to prove anything, you
need to convince us. And it is really hard to convince anyone by asking
>>> Where do you get doubts about its efficiency for the data processing
>>> of a single character?
>> Because it's being called at the end of a function calling seq_printf()
> Interesting view …
>> So exchanging a single call is probably not helping anything,
>> as the compiler will optimize it anyway.
> How common is the discussed software transformation between implementations
> for optimising compilers?
>> Case in point: with your patch the x86_64 compiler generates nearly
>> identical code for driver/md/raid1.c, but with one instruction _more_
>> after your patch has been applied.
> Which software versions and command parameters did you try out
> for this information (from an unspecified run time environment)?
# gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
git tree from git.kernel.org/mkp/u/4.10/scsi-queue
_I_ did some measurements.
I'm still waiting from results from your side.
Dr. Hannes Reinecke Teamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)