Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: harder case for optimization |
| Date | 2014-11-28 16:25 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <m5a455$tf3$1@dont-email.me> (permalink) |
| References | (3 earlier) <kLPdw.23649$bC1.20797@fx34.am4> <m5947m$i1k$1@dont-email.me> <2VYdw.15675$zz2.11112@fx06.am4> <m59rgr$rkh$1@dont-email.me> <22%dw.11896$He3.4668@fx15.am4> |
On 28/11/14 14:46, BartC wrote:
> "David Brown" <david.brown@hesbynett.no> wrote in message
> news:m59rgr$rkh$1@dont-email.me...
>> On 28/11/14 12:21, BartC wrote:
>
>>> because you've got no idea what gcc -O3 will get up to.
>>
>> Of course you know what gcc -O3 is up to - it asks the compiler to
>> put a lot of effort into making the code as fast as possible, even
>> if it makes it significantly bigger (although because of caches,
>> branch prediction, and other cpu features, -O2 code or even -Os
>> code can be faster - tweaking flags can lead to measurable
>> changes).
>>
>> If you have code that can be eliminated or simplified, you want
>> the compiler to eliminate it or simplify it. That is part of the
>> job of an optimising compiler - it lets you write code that is
>> clear, flexible and maintainable, and the compiler handles most of
>> the micro-optimisations.
>
> No, gcc -O3 is the equivalent of viewing code through rose-tinted
> specs. For example, I've had code generators producing
> atrocious-looking C code with far too many unnecessary temporary
> assignments, gotos everywhere, a right mess. Yet when compiled with
> gcc -O3 it was just as fast as perfectly written C!
>
> Compiled with no optimisation, there would likely have been a
> performance penalty which would have required those issues to be
> addressed.
I really don't understand your problem here. It doesn't matter how
"optimal" the source code is, if the generated result is the same thanks
to the compiler's optimiser. I want to write my source code in the
clearest way I can, and let the optimiser turn it into the best object
code. If I were writing a code generator, I would want to generate the
most convenient code using the simplest algorithms and let the C
compiler turn it into great object code - what is the point in spending
time and effort writing (and testing and debugging) a complex code
generator to produce neat or elegant C code, when I could rely on the
tried and tested optimisation from gcc?
>
> You're arguing that it doesn't matter how bad the code is, or how
> unnecessary or long-winded it is, provided the compiler can somehow
> sort out the essence of what it's trying to do. Maybe in some cases
> it can do that; in others it can't. Or the code initially compiles
> fine, until it's extended then it doesn't work as well because no-one
> ever bothered to attend to the original code properly as it seemed to
> run fine.
Yes, I am arguing that from the performance viewpoint, it doesn't matter
how bad the code is if the compiler can generate good results from it.
That means you can concentrate on other aspects of the code rather than
micro-optimising it - you can write code that is clear, flexible, and
maintainable. Or if it is from a code generator, you can make your code
generator as clear as possible without worrying about the speed of the
generated C code.
To take a very simple example, suppose I want a function that divides an
integer by 13 - and I want that code to run as fast as possible. The
simple, clear way is this:
int foo(int x) { return x / 13; }
Maybe I would want to allow for some future flexibility:
static const int fooDiv = 13;
int foo(int x) { return x / fooDiv; }
Compiled (by gcc 4.9 on 64-bit Linux) with -O0 gives:
11 foo:
12 .LFB0:
13 .cfi_startproc
14 0000 55 pushq %rbp
15 .cfi_def_cfa_offset 16
16 .cfi_offset 6, -16
17 0001 4889E5 movq %rsp, %rbp
18 .cfi_def_cfa_register 6
19 0004 897DFC movl %edi, -4(%rbp)
20 0007 B90D0000 movl $13, %ecx
20 00
21 000c 8B45FC movl -4(%rbp), %eax
22 000f 99 cltd
23 0010 F7F9 idivl %ecx
24 0012 5D popq %rbp
25 .cfi_def_cfa 7, 8
26 0013 C3 ret
The work is done by the slow "idivl" instruction.
Compiled with -O1 or above gives:
5 foo:
6 .LFB16:
7 .cfi_startproc
8 0000 BA4FECC4 movl $1321528399, %edx
8 4E
9 0005 89F8 movl %edi, %eax
10 0007 F7EA imull %edx
11 0009 C1FA02 sarl $2, %edx
12 000c C1FF1F sarl $31, %edi
13 000f 89D0 movl %edx, %eax
14 0011 29F8 subl %edi, %eax
15 0013 C3 ret
The division is now handled by much faster instructions (a multiply and
some shifts).
It is completely and utterly pointless to spend time and effort trying
to figure out the right C code to replace "x / 13" with a multiplication
and shifts. It would be time consuming, error-prone, and need
re-written if "fooDiv" were ever changed to a different value than 13.
So rather than "hand optimising" the C code so that it uses faster
instructions with -O0, I let the compiler do its job and enable the
optimiser.
I am in no way claiming that gcc's optimisers are perfect, or can turn
any old source code into fast object code. But they are pretty good,
and you should let them do their job so that you can put your effort
into the rest of the code.
>
> (For a real example, see the OP's first post in the 'how to optymize
> this' thread, 16-Nov-2014. That dimColor() had a lot of potential to
> be simplified, but because gcc -O3 cut right through all that code
> and gave good results anyway, that opportunity would have been passed
> over.)
Compilers are unlikely to be able to transform floating point code into
scaled integer code, since it is extremely difficult to guarantee
identical results - but "-O2 --fast-math" certainly improves the
generated code significantly over "-O0". (With --fast-math, gcc can
re-arrange floating point expressions and thus bring out the common
factor of "f * 0.3 + 0.7".)
And if the result (with -O2 or -O3) is good enough, then it is far
/better/ to have the source code written in a way that makes sense to
the programmer (using floating point or whatever) than to write
something that is hard to understand just to get faster results at -O0.
There is still scope for macro optimisations, such as algorithmic
changes (in this case, converting to scaled integers rather than
floats). But let the compiler handle the details of the micro
optimisations.
>
>> But dropping down to -O0 just mixes a wide range of different
>> pessimatisations into the problem. You have no idea whether the
>> speed changes you see are due to real code changes, or just poor
>> code generation when optimisations are disabled. And you have no
>> idea whether all your work is of any use - or if you would have got
>> the same effect through a simple -O2 switch rather than hours of
>> deep thought.
>
> You wouldn't spend hours, that's the point of quickly testing
> different fragments of code, often in a simple loop, a process which
> gcc -O3 renders next to impossible.
>
> In the past I've spent a lot of time comparing how my fast the code
> is from my code generator, to that produced by gcc -O3. But because
> gcc likes to optimise by eliminating code, I simply end up comparing
> how long my code takes to do something, with how long gcc takes *not*
> to do it! I considered that 'cheating'.
If your code does nothing, then gcc is right in generating nothing.
>
> (Actually now when I need to benchmark something, I often do that by
> running it on my own compiler. That only has a simple optimiser but
> which can usually be relied on to execute the code it's told to
> execute (and which might be what I'm trying to measure!). Something
> you can't rely on with gcc -O3 which tends to throw out the baby with
> the bathwater. While using gcc -O0 might generate poor code which is
> not typical of what is going to be in the production code which will
> use -O2 or -O3.)
>
Baring bugs in the compiler, gcc (and any other compiler) will always
generate code that does what it is told. But with higher optimisation
levels, you have to be more careful that your C code really says what
you think it says. If the code has different results under different
optimisation levels (other than speed and size differences), then your
code is wrong.
Benchmarking code that is not realistic for the final results, is
pointless. Benchmarking code that is intentionally poor, is pointless.
Massaging your source code in order to improve only non-optimised code
generation is pointless.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 00:42 -0800
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-27 11:34 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-27 13:29 +0100
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-27 05:58 -0800
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-27 06:36 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 12:26 -0800
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-27 22:07 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 14:49 -0800
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 00:05 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 00:46 +0100
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 00:55 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 07:20 +0100
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 00:41 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 01:54 -0800
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 02:19 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 04:05 -0800
Closed captioning (Was: harder case for something or other) gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 12:15 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 06:11 -0800
Re: harder case for optimization gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 12:18 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 04:42 -0800
Re: harder case for optimization gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 16:37 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 08:48 -0800
Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-28 16:51 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 10:38 -0800
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 11:34 +0100
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 11:21 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 04:23 -0800
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 13:58 +0100
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 13:46 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 16:25 +0100
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 08:18 -0800
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:17 +0100
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 08:54 -0800
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:22 +0100
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 11:29 -0800
Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-28 19:51 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:58 +0100
Re: harder case for optimization Melzzzzz <mel@zzzzz.com> - 2014-11-28 21:03 +0100
Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-28 20:11 +0000
Re: harder case for optimization Melzzzzz <mel@zzzzz.com> - 2014-11-28 21:31 +0100
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 20:06 +0000
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 17:14 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 20:54 +0100
Re: harder case for optimization "BartC" <bc@freeuk.com> - 2014-11-28 20:16 +0000
Re: harder case for optimization David Brown <david.brown@hesbynett.no> - 2014-11-28 21:56 +0100
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 23:37 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-27 23:54 -0800
Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-28 11:01 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-28 23:52 -0800
Re: harder case for optimization Morris Dovey <mrdovey@iedu.com> - 2014-11-29 02:03 -0600
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 00:38 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 03:12 -0800
Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 12:09 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 04:18 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 05:22 -0800
Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 16:58 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 09:35 -0800
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 10:55 -0800
Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 21:00 +0000
Re: harder case for optimization Ian Collins <ian-news@hotmail.com> - 2014-11-30 11:25 +1300
Re: harder case for optimization BartC <bc@freeuk.com> - 2014-11-29 22:56 +0000
Re: harder case for optimization Ian Collins <ian-news@hotmail.com> - 2014-11-30 12:00 +1300
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 16:01 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 16:21 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 16:52 -0800
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-11-29 17:14 -0800
Re: harder case for optimization glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-11-30 00:20 +0000
Re: harder case for optimization Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 16:43 -0800
Re: harder case for optimization Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 17:29 +0000
Re: harder case for optimization fir <profesor.fir@gmail.com> - 2014-12-05 02:12 -0800
csiph-web