Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129216 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2018-04-15 10:38 +0200 |
| Last post | 2018-04-15 23:20 +0200 |
| Articles | 20 on this page of 165 — 15 participants |
Back to article view | Back to comp.lang.c
stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-15 10:38 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 02:31 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 13:42 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 18:00 +0100
Re: stdcbench benchmark Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-15 18:11 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 19:30 +0100
Re: stdcbench benchmark Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-15 18:52 +0000
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 20:15 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 20:42 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-15 22:31 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 23:29 +0100
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-16 07:48 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 23:22 -0700
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-16 11:52 +0200
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-16 09:56 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-16 01:58 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 10:08 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 11:37 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-16 22:42 +1200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 12:54 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 13:02 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 14:39 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 14:53 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 16:32 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 14:41 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 15:56 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 17:21 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 15:43 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 17:00 +0100
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 16:09 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 17:22 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 09:35 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 11:42 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:14 +0200
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-17 15:49 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 18:45 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 23:00 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 21:18 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 23:20 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 09:27 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 11:30 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 03:43 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-18 22:58 +1200
Re: stdcbench benchmark mark.bluemel@gmail.com - 2018-04-18 04:01 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 12:39 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 06:52 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 13:59 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 06:14 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-19 07:39 +1200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 06:14 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 16:31 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 08:00 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 17:26 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 08:37 -0700
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-18 16:12 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 18:15 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 04:01 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 13:01 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 04:15 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 13:41 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 05:35 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 12:26 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 13:58 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 22:29 +0100
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-18 10:34 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 22:34 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 22:35 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-19 20:05 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-20 08:07 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-19 23:34 +0100
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-19 16:05 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 00:18 +0100
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-25 23:12 +0000
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-20 16:15 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 11:39 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-20 23:46 +1200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 05:04 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 13:27 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 06:06 -0700
Re: stdcbench benchmark supercat@casperkitty.com - 2018-04-20 13:05 -0700
Re: stdcbench benchmark mark.bluemel@gmail.com - 2018-04-20 01:23 -0700
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 01:40 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 12:04 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-20 04:16 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 13:48 +0100
Re: stdcbench benchmark Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:53 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-23 20:33 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 01:00 -0700
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-20 09:17 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 19:25 +0100
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-20 11:58 -0700
Re: stdcbench benchmark supercat@casperkitty.com - 2018-04-20 12:30 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 21:03 +0100
Re: stdcbench benchmark Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-20 22:16 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 23:09 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 14:42 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 09:30 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 07:24 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 20:43 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 07:59 +1200
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 08:01 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 21:18 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 09:17 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 23:15 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 02:14 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 09:54 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 01:21 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 11:40 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-18 11:26 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 01:48 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 09:58 +0200
Re: stdcbench benchmark Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-16 16:45 +0000
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 17:31 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 18:53 +0100
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 17:55 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 19:01 +0100
Re: stdcbench benchmark Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-16 20:28 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 21:57 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 09:45 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 12:24 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:31 +0200
Re: stdcbench benchmark Robert Wessel <robertwessel2@yahoo.com> - 2018-04-16 16:59 -0500
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 01:02 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 09:47 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 13:16 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:38 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 13:18 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 14:37 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 06:44 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 15:58 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 15:43 +0000
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 08:47 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-17 08:04 +1200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 20:30 +0000
Re: stdcbench benchmark Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-16 16:31 +0000
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-20 14:22 -0700
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 00:42 -0700
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-16 07:00 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 16:35 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-16 09:28 -0700
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 17:42 +0000
Re: stdcbench benchmark Robert Wessel <robertwessel2@yahoo.com> - 2018-04-16 17:07 -0500
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 02:50 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 12:42 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 11:58 +0100
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-17 14:01 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 13:40 +0100
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-17 15:41 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:46 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 06:09 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 16:07 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:43 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 15:26 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 07:42 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 16:51 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 08:07 -0700
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 08:16 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 23:17 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 17:12 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 23:26 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 23:38 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 05:52 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 16:10 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 10:02 +0200
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-15 23:20 +0200
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-21 08:01 +1200 |
| Message-ID | <fjuv7sFlnnqU8@mid.individual.net> |
| In reply to | #129530 |
On 04/21/2018 07:59 AM, Ian Collins wrote: > On 04/21/2018 07:43 AM, bartc wrote: >> On 20/04/2018 20:24, Ian Collins wrote: >>> On 04/21/2018 01:42 AM, bartc wrote: >>>> On 20/04/2018 09:23, mark.bluemel@gmail.com wrote: >>>> >>>>> I admit that that approach risks letting new entrants to the group >>>>> view your unchallenged opinions as facts, >>>> >>>> BTW what the you think new entrants would make of the claim that a >>>> simple optimisation option made a C (?) program up to 40 times faster? >>> >>> You are distorting the facts. Nowhere did Scott use the term "a simple >>> optimisation option", he said "compiler optimzations". If you spent >>> less time misinterpreting what people say, others might be less inclined >>> to call you out. >> >> And everyone is still at it. >> >> Please stop. > > Sot pulling you up for distorting the facts? No chance. > >> Somebody makes some over-the-top, unsubstantiated claim (in order to >> help win some argument), and it's ME distorting the facts? >> >> I actually asked: >> >> "How much difference would it make if you left all that in place, but >> switched off compiler optimisations?" >> >> How many optimisations are there? Are you saying that when I switch from >> -O0 to -O3, the compiler doesn't give me everything it's got? It's >> withholding something that might give me a 3000% speed-up instead of 30%? >> >> It was perfectly obvious what I meant. > > No it wasn't. As I explained elsewhere, there are many non-trivial > optimisations. Many are enabled by "umbrella" flags such as -Ox, while > other are not. Getting a fully optimised build for a specific target > process is not a simple task. I shouldn't post so early in the morning... "specific target processor". -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-20 21:18 +0100 |
| Message-ID | <dWrCC.1203312$Ly1.434769@fx13.am4> |
| In reply to | #129530 |
On 20/04/2018 20:59, Ian Collins wrote: > On 04/21/2018 07:43 AM, bartc wrote: >> On 20/04/2018 20:24, Ian Collins wrote: >>> On 04/21/2018 01:42 AM, bartc wrote: >>>> On 20/04/2018 09:23, mark.bluemel@gmail.com wrote: >>>> >>>>> I admit that that approach risks letting new entrants to the group >>>>> view your unchallenged opinions as facts, >>>> >>>> BTW what the you think new entrants would make of the claim that a >>>> simple optimisation option made a C (?) program up to 40 times faster? >>> >>> You are distorting the facts. Nowhere did Scott use the term "a simple >>> optimisation option", he said "compiler optimzations". If you spent >>> less time misinterpreting what people say, others might be less inclined >>> to call you out. >> >> And everyone is still at it. >> >> Please stop. > > Sot pulling you up for distorting the facts? No chance. We are talking about optimisations which in my experience of gcc has rarely offered anything beyond 2x or 3x let alone double figures, and somebody claims 40x improvement. And /I/ am distorting the facts? Give me a link to one open source C project I can build that will show anything like that much difference between optimised/unoptimised. >> It was perfectly obvious what I meant. > > No it wasn't. As I explained elsewhere, there are many non-trivial > optimisations. Many are enabled by "umbrella" flags such as -Ox, while > other are not. Getting a fully optimised build for a specific target > process is not a simple task. No. Then perhaps what I used to do for years, which was just to use inline assembly for some critical piece of code, was also a reasonable approach. It's not simple and it's not portable, but then it sounds like what you have to do isn't either. But what /I/ call compiler optimisation is to take EXACTLY the same source code, and automatically generate code from it to make it run faster. It should not depend on extra annotations within the source code.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-21 09:17 +1200 |
| Message-ID | <fjv3o7FlnnqU9@mid.individual.net> |
| In reply to | #129535 |
On 04/21/2018 08:18 AM, bartc wrote: > On 20/04/2018 20:59, Ian Collins wrote: >> On 04/21/2018 07:43 AM, bartc wrote: >>> On 20/04/2018 20:24, Ian Collins wrote: >>>> On 04/21/2018 01:42 AM, bartc wrote: >>>>> On 20/04/2018 09:23, mark.bluemel@gmail.com wrote: >>>>> >>>>>> I admit that that approach risks letting new entrants to the group >>>>>> view your unchallenged opinions as facts, >>>>> >>>>> BTW what the you think new entrants would make of the claim that a >>>>> simple optimisation option made a C (?) program up to 40 times faster? >>>> >>>> You are distorting the facts. Nowhere did Scott use the term "a simple >>>> optimisation option", he said "compiler optimzations". If you spent >>>> less time misinterpreting what people say, others might be less inclined >>>> to call you out. >>> >>> And everyone is still at it. >>> >>> Please stop. >> >> Sot pulling you up for distorting the facts? No chance. > > We are talking about optimisations which in my experience of gcc has > rarely offered anything beyond 2x or 3x let alone double figures, and > somebody claims 40x improvement. Hang on and back up a minute, I was calling you out for saying Scott said he used "a simple optimisation option" to make his code faster. He made no such claim. > And /I/ am distorting the facts? Undoubtedly. >>> It was perfectly obvious what I meant. >> >> No it wasn't. As I explained elsewhere, there are many non-trivial >> optimisations. Many are enabled by "umbrella" flags such as -Ox, while >> other are not. Getting a fully optimised build for a specific target >> process is not a simple task. > > No. Then perhaps what I used to do for years, which was just to use > inline assembly for some critical piece of code, was also a reasonable > approach. > > It's not simple and it's not portable, but then it sounds like what you > have to do isn't either. > > But what /I/ call compiler optimisation is to take EXACTLY the same > source code, and automatically generate code from it to make it run > faster. It should not depend on extra annotations within the source code. What you call compiler optimisation is largely irrelevant. What developers who tune applications for their execution environment is more pertinent here, even though the two are the same in this case. Architecture optimisations do not require extra annotations within the source code. Where did you conjure that up from? You have a penchant for twisting a thread with things no one has mentioned and throwing a tantrum when we call you out. For some idea what options are available, see https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/x86-Options.html#x86-Options -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-20 23:15 +0100 |
| Message-ID | <XDtCC.470678$qo7.421130@fx04.am4> |
| In reply to | #129544 |
On 20/04/2018 22:17, Ian Collins wrote: > On 04/21/2018 08:18 AM, bartc wrote: > Hang on and back up a minute, I was calling you out for saying Scott > said he used "a simple optimisation option" to make his code faster. He > made no such claim. He didn't say he was using C++ either, but people are assuming that. > Architecture optimisations do not require extra annotations within the > source code. I didn't bring up architectural optimisations. I'm talking about things like 'inline' and '__attribute__(always inline)'. If you're ONLY talking about command line options, then I would class those as simple. After all you are only telling it what machine you have, right?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-18 02:14 +0100 |
| Message-ID | <FZwBC.491453$f35.438921@fx23.am4> |
| In reply to | #129363 |
On 17/04/2018 22:00, David Brown wrote: > On 17/04/18 19:45, bartc wrote: > Of course it is simple in cases like this - and like most decent > compilers, gcc has an builtin function for byte swap. This is merely an > example - you can't make builtins, intrinsics, operators or extensions > for every function people think of. You can for the common ones. > See how easy this stuff can be to make an unnecessary mess and cause > pointless incompatibilities? It sounds like it's already a mess. But it's interesting to have a good example of how C works. Use the macro processor instead of fixing the language. Put the onus on advanced compilers to recognise idioms instead of fixing the language. In both cases, you have to implement the feature yourself, with everyone doing it differently. >> I don't see inlining as something that need only be part of optimiser. >> That can also be an intrinsic of the language, rather than left to the >> whim of the implementation. > > If you learned about what "inline" means in C, then you would > understand. But you'd rather take your half-baked knowledge of outdated > C, augment it with a bit of trial and error, and then imagine everything > else. > > You can decide the meaning of "inline", and make operators "bswap" and > "max" in your own language. But not C. Don't tell me that if you were designing C from scratch, you'd have it work exactly the same way, and have basic things like 'max' as DIY add-ons for everyone to create their own way. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-18 09:54 +0200 |
| Message-ID | <pb6tke$2kp$1@dont-email.me> |
| In reply to | #129373 |
On 18/04/18 03:14, bartc wrote: > On 17/04/2018 22:00, David Brown wrote: >> On 17/04/18 19:45, bartc wrote: > >> Of course it is simple in cases like this - and like most decent >> compilers, gcc has an builtin function for byte swap. This is merely >> an example - you can't make builtins, intrinsics, operators or >> extensions for every function people think of. > > You can for the common ones. You can indeed. > >> See how easy this stuff can be to make an unnecessary mess and cause >> pointless incompatibilities? > > It sounds like it's already a mess. It is, in fact, extremely simple to avoid. If you had read the C standards before trying to make your compiler, or looked at other tools, you would already know how to do it. In gcc, the function is called "__builtin_bswap16". In other compilers, it might be called "__bswap", or it might be declared as part of a <intrinsics.h> header. There are several ways to handle this properly. So in /your/ compiler, you might have made extra incompatibilities with the language. It's your tool - you can do that if you want. Other compilers that are interested in being /C/ compilers with at least a modicum of standards compatibility put effort into thinking about these things. Sure, it is more fun to dash in and implement the builtin and less fun to try to avoid breaking existing code or thinking about the bigger picture, but that is what real compilers have to do. > > But it's interesting to have a good example of how C works. Use the > macro processor instead of fixing the language. Put the onus on advanced > compilers to recognise idioms instead of fixing the language. In both > cases, you have to implement the feature yourself, with everyone doing > it differently. The language is what the language is. Do you think every C compiler should implement the language in a different and incompatible way? Do you think a programmer who wants to swap two halves of a byte should write a proposal for a change to the language, wait some 5 years for the next version of the language standard and then another 3 years for a new version of the compiler that supports it? Even for a single-vendor language like C# or Python it can take years to make a change to the core language. When you have your own little language designed by one person, used by one person, with tools written by one person and used by one person - /then/ you can add a "bswap" or "max" operator if you want, do so quickly, and know that you are not causing compatibility problems. You don't even need to spend time documenting the feature. That is advantage of a personal language. But C is not such a language. So yes, it is /much/ better to have C compilers that can recognise code like this. There are lots of compilers that do so. And compilers that don't generate optimal object code for a function like this "bswap" will still generate /correct/ code for it - the function is portable to any C compiler. And people who use good tools will get good results even if they express the same code in different ways. > >>> I don't see inlining as something that need only be part of >>> optimiser. That can also be an intrinsic of the language, rather than >>> left to the whim of the implementation. >> >> If you learned about what "inline" means in C, then you would >> understand. But you'd rather take your half-baked knowledge of >> outdated C, augment it with a bit of trial and error, and then imagine >> everything else. >> >> You can decide the meaning of "inline", and make operators "bswap" and >> "max" in your own language. But not C. > > Don't tell me that if you were designing C from scratch, you'd have it > work exactly the same way, and have basic things like 'max' as DIY > add-ons for everyone to create their own way. > Yes, I would. I don't see any advantage in having these as part of the language. But I would make it easier to define such things in the language - make it easier to write a "max" function with a variable number of arguments, for example. And I would probably put these (and many others) in the standard library - but definitely /not/ in the core language. If I were designing a language from scratch, I'd look more to how C++ is now, plus some of the suggested new features (like concepts and metaclasses), but with a somewhat different syntax in places because backwards compatibility would not be important. In particular, the core language should be minimal. (With C++ metaclasses, things like "enum", "struct" and "class" could be implemented as library code, not core language.) Of course it would support proper modules that can be pre-compiled, so that library code would not need to be parsed for every compile.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-18 01:21 -0700 |
| Message-ID | <e90a3dcf-6e04-4d0d-aa7b-156fb5af9ec7@googlegroups.com> |
| In reply to | #129381 |
On Wednesday, April 18, 2018 at 12:55:07 AM UTC-7, David Brown wrote: > On 18/04/18 03:14, bartc wrote: > > On 17/04/2018 22:00, David Brown wrote: > >> On 17/04/18 19:45, bartc wrote: > > > >> Of course it is simple in cases like this - and like most decent > >> compilers, gcc has an builtin function for byte swap. This is merely > >> an example - you can't make builtins, intrinsics, operators or > >> extensions for every function people think of. > > > > You can for the common ones. > > You can indeed. > > > > >> See how easy this stuff can be to make an unnecessary mess and cause > >> pointless incompatibilities? > > > > It sounds like it's already a mess. > > It is, in fact, extremely simple to avoid. If you had read the C > standards before trying to make your compiler, or looked at other tools, > you would already know how to do it. > > In gcc, the function is called "__builtin_bswap16". In other compilers, > it might be called "__bswap", or it might be declared as part of a > <intrinsics.h> header. There are several ways to handle this properly. > > So in /your/ compiler, you might have made extra incompatibilities with > the language. It's your tool - you can do that if you want. Other > compilers that are interested in being /C/ compilers with at least a > modicum of standards compatibility put effort into thinking about these > things. Sure, it is more fun to dash in and implement the builtin and > less fun to try to avoid breaking existing code or thinking about the > bigger picture, but that is what real compilers have to do. > > > > > But it's interesting to have a good example of how C works. Use the > > macro processor instead of fixing the language. Put the onus on advanced > > compilers to recognise idioms instead of fixing the language. In both > > cases, you have to implement the feature yourself, with everyone doing > > it differently. > > The language is what the language is. Do you think every C compiler > should implement the language in a different and incompatible way? Do > you think a programmer who wants to swap two halves of a byte should > write a proposal for a change to the language, wait some 5 years for the > next version of the language standard and then another 3 years for a new > version of the compiler that supports it? Even for a single-vendor > language like C# or Python it can take years to make a change to the > core language. > > When you have your own little language designed by one person, used by > one person, with tools written by one person and used by one person - > /then/ you can add a "bswap" or "max" operator if you want, do so > quickly, and know that you are not causing compatibility problems. You > don't even need to spend time documenting the feature. That is > advantage of a personal language. But C is not such a language. > > So yes, it is /much/ better to have C compilers that can recognise code > like this. There are lots of compilers that do so. And compilers that > don't generate optimal object code for a function like this "bswap" will > still generate /correct/ code for it - the function is portable to any C > compiler. And people who use good tools will get good results even if > they express the same code in different ways. > > > > >>> I don't see inlining as something that need only be part of > >>> optimiser. That can also be an intrinsic of the language, rather than > >>> left to the whim of the implementation. > >> > >> If you learned about what "inline" means in C, then you would > >> understand. But you'd rather take your half-baked knowledge of > >> outdated C, augment it with a bit of trial and error, and then imagine > >> everything else. > >> > >> You can decide the meaning of "inline", and make operators "bswap" and > >> "max" in your own language. But not C. > > > > Don't tell me that if you were designing C from scratch, you'd have it > > work exactly the same way, and have basic things like 'max' as DIY > > add-ons for everyone to create their own way. > > > > Yes, I would. I don't see any advantage in having these as part of the > language. But I would make it easier to define such things in the > language - make it easier to write a "max" function with a variable > number of arguments, for example. And I would probably put these (and > many others) in the standard library - but definitely /not/ in the core > language. > > If I were designing a language from scratch, I'd look more to how C++ is > now, plus some of the suggested new features (like concepts and > metaclasses), but with a somewhat different syntax in places because > backwards compatibility would not be important. In particular, the core > language should be minimal. (With C++ metaclasses, things like "enum", > "struct" and "class" could be implemented as library code, not core > language.) Of course it would support proper modules that can be > pre-compiled, so that library code would not need to be parsed for every > compile. And in retaliation you have nothing but an attempt to start a circus. I guess this is what comes about when seriously poor self esteem takes over Aragorn's psyche. At times, fantasy is more valuable than facts. What did Aragorn have to say about this miraculous, years long string of oddities? Most of the time he would try to lead the reader to trust they're long time lurkers who just happened to have not enough brains to see through his lies. Makes no sense. That lame duck update system failed over and over again. You are seconds away from being in my kill file. Windows Mobile, runs on the SC kernel. So yeah, SC is mobile. SC is a super computer. SC is a server. SC is a desktop. SC is growing in market share. -- Live on Kickstarter! https://youtu.be/5OfWsoPAg7o Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-18 11:40 +0100 |
| Message-ID | <IgFBC.383084$Il7.258606@fx46.am4> |
| In reply to | #129381 |
On 18/04/2018 08:54, David Brown wrote: > On 18/04/18 03:14, bartc wrote: >> On 17/04/2018 22:00, David Brown wrote: >>> On 17/04/18 19:45, bartc wrote: >> >>> Of course it is simple in cases like this - and like most decent >>> compilers, gcc has an builtin function for byte swap. This is merely >>> an example - you can't make builtins, intrinsics, operators or >>> extensions for every function people think of. >> >> You can for the common ones. > > You can indeed. > >> >>> See how easy this stuff can be to make an unnecessary mess and cause >>> pointless incompatibilities? >> >> It sounds like it's already a mess. > > It is, in fact, extremely simple to avoid. If you had read the C > standards before trying to make your compiler, or looked at other tools, > you would already know how to do it. > > In gcc, the function is called "__builtin_bswap16". In other compilers, > it might be called "__bswap", or it might be declared as part of a > <intrinsics.h> header. There are several ways to handle this properly. > > So in /your/ compiler, you might have made extra incompatibilities with > the language. I added the bswap operator to my language, not C. Not a full treatment, just so I could measure performance of my unoptimised but intrinsic feature, against optimised C working with your function. And, yes, I got just as good results. Which reinforces my point that some of the advantages of optimisation can be achieved by adjustment of the language. With the extra advantage that the feature is already there; it's not necessary for everyone to devise their own version.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-18 11:26 +1200 |
| Message-ID | <fjne4oFu2ghU1@mid.individual.net> |
| In reply to | #129322 |
On 04/18/2018 12:14 AM, David Brown wrote:
>
> Since I almost never compile without optimisations, and certainly don't
> bother timing code without optimising, I don't know.
>
> For the kind of code I usually work with, I would guess at about 4 or 5
> times difference. The cpus I use have plenty of registers - holding
> local data on the stack instead of the registers is immensely costly.
>
> Some functions could easily hit 40 times improvement, but these are in
> the minority. An example is this function:
>
> static uint16_t bswap(uint16_t x) {
> uint16_t lo = x & 0xff;
> uint16_t hi = (x >> 8);
> return (lo << 8) | hi;
> }
>
> Compiled with -O2, this function takes three instructions on the ARM
> Cortex-M4. However, function inlining means that if it is called on
> data read from memory (as it usually is) the compiler can replace the
> 16-bit load, call, shift+mask, or, return instructions (plus register
> manipulation instructions, plus any lost register information over the
> function call interface) with a single "16-bit load with reversed
> endian" instruction. That could quickly be 8-10 times faster from inlining.
>
> And compiled with -O0, not only is inlining disabled but the function is
> some 20-odd instructions long.
Another simple but common example would be this form our code base:
memcpy( SocketCANFrame.data, CANFrame.UData.m_Data, 8 );
Cumbersome setup and function call without optimisation, two
instructions (on ARM Cortex-a8).
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-18 01:48 +0100 |
| Message-ID | <2BwBC.582377$_J4.94826@fx28.am4> |
| In reply to | #129371 |
On 18/04/2018 00:26, Ian Collins wrote:
> On 04/18/2018 12:14 AM, David Brown wrote:
> Another simple but common example would be this form our code base:
>
> memcpy( SocketCANFrame.data, CANFrame.UData.m_Data, 8 );
>
> Cumbersome setup and function call without optimisation, two
> instructions (on ARM Cortex-a8).
Presumably there's some reason why you can't just do a normal
assignment; maybe those are both arrays?
Anyway, gcc-O0 will code that as a 64-bit load and store. Although not
all compilers will do that.
In that case, a language that allows value-arrays could just do an
assignment:
[8]byte a, b
a := b
also generates a 64-bit load and store (these arrays are 8-byte
aligned), but you can express it directly.
What was it that someone was saying about being able to write code more
clearly? Just a good optimiser is not quite enough.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-18 09:58 +0200 |
| Message-ID | <pb6trb$3lr$1@dont-email.me> |
| In reply to | #129372 |
On 18/04/18 02:48, bartc wrote: > On 18/04/2018 00:26, Ian Collins wrote: >> On 04/18/2018 12:14 AM, David Brown wrote: > >> Another simple but common example would be this form our code base: >> >> memcpy( SocketCANFrame.data, CANFrame.UData.m_Data, 8 ); >> >> Cumbersome setup and function call without optimisation, two >> instructions (on ARM Cortex-a8). > > Presumably there's some reason why you can't just do a normal > assignment; maybe those are both arrays? > > Anyway, gcc-O0 will code that as a 64-bit load and store. Although not > all compilers will do that. > > In that case, a language that allows value-arrays could just do an > assignment: > > [8]byte a, b > a := b > > also generates a 64-bit load and store (these arrays are 8-byte > aligned), but you can express it directly. > > What was it that someone was saying about being able to write code more > clearly? Just a good optimiser is not quite enough. > What makes you think these things in Ian's code are uint8_t[8] arrays? What makes you even think they are the same type? In my CAN code, the equivalent structures are usually unions of structs of various sorts in the application-level code, and an array of volatile bytes in the hardware registers. These are not the same thing in a typed programming language.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-04-16 16:45 +0000 |
| Message-ID | <slrnpd9kq6.31ka.grahn+nntp@frailea.sa.invalid> |
| In reply to | #129269 |
On Mon, 2018-04-16, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: >>On 16/04/2018 16:43, Scott Lurndal wrote: >>> bartc <bc@freeuk.com> writes: >>>> On 16/04/2018 15:41, Scott Lurndal wrote: >> >>>>> Indeed. The application I'm currently working on has between 6 >>>>> and 96 threads running flat-out, 100%. No I/O. Might block >>>>> infrequently waiting for a mutex, very infrequently, the threads >>>>> are pretty much independent. Every cycle matters, so >>>>> work goes into looking at L1/L2 cache behavior, data layout wrt >>>>> cache-lines, compiler optimzations, and inline micro-optimizations >>>>> (e.g. avoiding blocking operations like mutexes when possible by using >>>>> atomics instead) >>>>> >>>> >>>> How much difference would it make if you left all that in place, but >>>> switched off compiler optimisations? >>> >>> It runs 20 to 40 times slower. >>> >> >>Really? It has the same effect as switching to an interpreted language? >> >>Then your programs must be highly atypical. > > I wouldn't say that at all. Say instead that the optimizer is pretty > good. Note also that disabling optimization with gcc will prevent > function in-lining, which I suspect makes a large part of the > difference in performance. When you trust the optimizer, you tend to split things into more separate functions, use more temporaries, and so on -- write for maintainability, rather than for a hypothetical naive compiler. That's also something you learn when using C++; the standard library is designed that way. 20--40 times slower sounds high to me, but not implausible. I don't have any figures myself; I never build anything without at least -O2. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-16 17:31 +0000 |
| Message-ID | <i65BC.51544$KZ2.47329@fx39.iad> |
| In reply to | #129276 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >On Mon, 2018-04-16, Scott Lurndal wrote: >> bartc <bc@freeuk.com> writes: >>>On 16/04/2018 16:43, Scott Lurndal wrote: >>>> bartc <bc@freeuk.com> writes: >>>>> On 16/04/2018 15:41, Scott Lurndal wrote: >>> >>>>>> Indeed. The application I'm currently working on has between 6 >>>>>> and 96 threads running flat-out, 100%. No I/O. Might block >>>>>> infrequently waiting for a mutex, very infrequently, the threads >>>>>> are pretty much independent. Every cycle matters, so >>>>>> work goes into looking at L1/L2 cache behavior, data layout wrt >>>>>> cache-lines, compiler optimzations, and inline micro-optimizations >>>>>> (e.g. avoiding blocking operations like mutexes when possible by using >>>>>> atomics instead) >>>>>> >>>>> >>>>> How much difference would it make if you left all that in place, but >>>>> switched off compiler optimisations? >>>> >>>> It runs 20 to 40 times slower. >>>> >>> >>>Really? It has the same effect as switching to an interpreted language? >>> >>>Then your programs must be highly atypical. >> >> I wouldn't say that at all. Say instead that the optimizer is pretty >> good. Note also that disabling optimization with gcc will prevent >> function in-lining, which I suspect makes a large part of the >> difference in performance. > >When you trust the optimizer, you tend to split things into more >separate functions, use more temporaries, and so on -- write for >maintainability, rather than for a hypothetical naive compiler. Yep. In our case, we use many small inline functions. > >That's also something you learn when using C++; the standard library >is designed that way. > >20--40 times slower sounds high to me, but not implausible. I don't >have any figures myself; I never build anything without at least -O2. The application simulates an SoC. With optimization, can boot 6-core linux to busybox in 24 seconds. Without optimization, it's over 600 seconds. Call it 25x slower. It is when we overcommit host processor resources that the high-end of the slowdown occurs (e.g. simulate more SoC cores than available host cores).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-16 18:53 +0100 |
| Message-ID | <hq5BC.489525$f35.402984@fx23.am4> |
| In reply to | #129278 |
On 16/04/2018 18:31, Scott Lurndal wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> 20--40 times slower sounds high to me, but not implausible. I don't
>> have any figures myself; I never build anything without at least -O2.
>
> The application simulates an SoC. With optimization, can boot 6-core
> linux to busybox in 24 seconds. Without optimization, it's over 600
> seconds. Call it 25x slower.
>
> It is when we overcommit host processor resources that the high-end
> of the slowdown occurs (e.g. simulate more SoC cores than available
> host cores).
It sounds like the slowdown is not purely due to the poorer unoptimised
code but it might trigger extraneous factors which can make a bigger
difference (maybe the poorer code uses extra memory).
(For example, when we used to directly read sectors off a spinning disk,
a slightly slower program might mean missing the next sector so having
to wait for the next revolution. Then the apparent slowdown is much
bigger than just the program code.)
It might also of course be possible, as I suggested, that some
inefficient code has been written which runs fine optimised, but the
inefficiency shows when it's unoptimised. For example:
int main(void) {
char *s=malloc(1000001);
int i,sum=0;
for (i=0; i<1000000; ++i) s[i]='A';
s[1000000]=0;
for (i=0; i<strlen(s); ++i) sum+=s[i]; // ** HERE **
printf("Sum %d\n",sum); // 65 million
}
This executes instantly (say 0.05 seconds) with gcc-O3. But with gcc-O0,
It takes 120 seconds - 2500 times slower.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-16 17:55 +0000 |
| Message-ID | <9s5BC.73770$6_2.29370@fx41.iad> |
| In reply to | #129281 |
bartc <bc@freeuk.com> writes: >On 16/04/2018 18:31, Scott Lurndal wrote: >(For example, when we used to directly read sectors off a spinning disk, >a slightly slower program might mean missing the next sector so having >to wait for the next revolution. Then the apparent slowdown is much >bigger than just the program code.) That hasn't been a problem for forty years.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-16 19:01 +0100 |
| Message-ID | <my5BC.489526$f35.363193@fx23.am4> |
| In reply to | #129282 |
On 16/04/2018 18:55, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: >> On 16/04/2018 18:31, Scott Lurndal wrote: > >> (For example, when we used to directly read sectors off a spinning disk, >> a slightly slower program might mean missing the next sector so having >> to wait for the next revolution. Then the apparent slowdown is much >> bigger than just the program code.) > > That hasn't been a problem for forty years. Not quite that long (as I had that problem in the 80s working with FDCs). But it was just an example. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-04-16 20:28 +0000 |
| Message-ID | <slrnpda1qn.31ka.grahn+nntp@frailea.sa.invalid> |
| In reply to | #129281 |
On Mon, 2018-04-16, bartc wrote: ... > It might also of course be possible, as I suggested, that some > inefficient code has been written which runs fine optimised, but the > inefficiency shows when it's unoptimised. "Inefficient code which runs fine optimised" is an oxymoron; these days (1990s and onwards) you can -- and should -- expect an optimizing C compiler. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-16 21:57 +0100 |
| Message-ID | <z68BC.617636$TS3.160376@fx18.am4> |
| In reply to | #129286 |
On 16/04/2018 21:28, Jorgen Grahn wrote: > On Mon, 2018-04-16, bartc wrote: > ... >> It might also of course be possible, as I suggested, that some >> inefficient code has been written which runs fine optimised, but the >> inefficiency shows when it's unoptimised. > > "Inefficient code which runs fine optimised" is an oxymoron; these > days (1990s and onwards) you can -- and should -- expect an optimizing > C compiler. That's sounds like another sloppy attitude to me. So, it's fine to stick with a crude, student-joke of a language with its multiple of problems because everyone now uses highlighting editors, linters, analysers, shedloads of compiler options and other advanced tools to get around them. (So much easier than fixing the language!) Now you're saying it's not worth writing proper code because 'a decent compiler should optimise out any bad code'. Well, it might do, or it might not. Or it does, until you change something, but you won't know. Not unless it creates a key bottleneck. This is where coding using naive compilers - or ones with optimisation disabled - is an advantage in my opinion. If it runs fast enough, then the optimised version is a bonus. There's a lot of talk about C being 'close to the metal'. But it seems no one is that interested in being close to their own code. Rather, it's better when the compiler transforms it as much as possible! Difficult to be close to the metal when you have no idea what code you are actually executing. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-17 09:45 +0200 |
| Message-ID | <pb48mn$np7$1@dont-email.me> |
| In reply to | #129288 |
On 16/04/18 22:57, bartc wrote: > On 16/04/2018 21:28, Jorgen Grahn wrote: >> On Mon, 2018-04-16, bartc wrote: >> ... >>> It might also of course be possible, as I suggested, that some >>> inefficient code has been written which runs fine optimised, but the >>> inefficiency shows when it's unoptimised. >> >> "Inefficient code which runs fine optimised" is an oxymoron; these >> days (1990s and onwards) you can -- and should -- expect an optimizing >> C compiler. > > That's sounds like another sloppy attitude to me. > > So, it's fine to stick with a crude, student-joke of a language with its > multiple of problems because everyone now uses highlighting editors, > linters, analysers, shedloads of compiler options and other advanced > tools to get around them. (So much easier than fixing the language!) > > Now you're saying it's not worth writing proper code because 'a decent > compiler should optimise out any bad code'. Well, it might do, or it > might not. Or it does, until you change something, but you won't know. > Not unless it creates a key bottleneck. Did you here the "whoosh" ? That was the sound of the point passing way over your head. When you know you have a decent compiler, you can write better, clearer, safer, more maintainable code. When you know you have a crap compiler, or have decided to hobble it by not using optimisation, you have to write crap quality code if you want decent performance. With a good compiler, you know you can generalise your functions, you can freely use variables, you can split up sub-functions, you can use complex types - you can write the code in the clearest way possible. When you need to get efficient results from a poor compiler, you are forced to write "hand optimised" C code. You have to write a "while" loop counting down, even though a "for" loop counting up might be more natural. You have to write "(x << 4) + x" when you mean "x * 5". You have to use pointers when you want to use array accesses. You have to use "goto" instead of flag booleans. You have to use function-like macros instead of small functions. I've done more than my fair share of C coding for non-optimising compilers. Writing for proper compilers lets you write /far/ better source code - and get more efficient object code. > > This is where coding using naive compilers - or ones with optimisation > disabled - is an advantage in my opinion. If it runs fast enough, then > the optimised version is a bonus. > > There's a lot of talk about C being 'close to the metal'. But it seems > no one is that interested in being close to their own code. Rather, it's > better when the compiler transforms it as much as possible! Difficult to > be close to the metal when you have no idea what code you are actually > executing. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-17 12:24 +0100 |
| Message-ID | <tPkBC.1605251$jx2.111478@fx03.am4> |
| In reply to | #129308 |
On 17/04/2018 08:45, David Brown wrote:
> On 16/04/18 22:57, bartc wrote:
>> Now you're saying it's not worth writing proper code because 'a decent
>> compiler should optimise out any bad code'.
> When you know you have a decent compiler, you can write better, clearer,
> safer, more maintainable code. When you know you have a crap compiler,
> or have decided to hobble it by not using optimisation, you have to
> write crap quality code if you want decent performance.
My comments were about becoming lazy and writing inefficient, untidy
code because you know the compiler will clean up the mess.
Such as my example of:
for (i=0; i<strlen(s); ++s)
Yes, optimising might hoist the strlen call out of the loop [just
noticed that typo, but will leave it in as another example of the
problems with bloody C for loops]. But you make a mod, and the compiler
can no longer be certain that s is not altered within the loop.
> With a good compiler, you know you can generalise your functions, you
> can freely use variables, you can split up sub-functions, you can use
> complex types - you can write the code in the clearest way possible.
>
> When you need to get efficient results from a poor compiler, you are
> forced to write "hand optimised" C code. You have to write a "while"
> loop counting down, even though a "for" loop counting up might be more
> natural.
The language should offer several dedicated loop forms. Then it can
directly generate the most apt code without needing elaborate analysis
of the loop - harder in C because it is completely unstructured and
there is no concept of a loop variable.
In other words, language features can reduce the need for an optimiser.
> You have to write "(x << 4) + x" when you mean "x * 5".
This is peep-hole optimisation; even gcc-O0 will do this. I can do some
of this too.
You
> have to use pointers when you want to use array accesses. You have to
> use "goto" instead of flag booleans.
The language could allow things like nested breaks to avoid goto.
You have to use function-like
> macros instead of small functions.
And the language can provide built-ins like min and max to reduce the
need for such macros. Or special inline functions (not just an 'inline'
attribute that can be applied even to 1000-line functions, but ones
intended to be used inline). A bit like the one-line functions in Basic
and Fortran IIRC.
Then the inlining can be done as normal code generation, nothing to do
with running an optimiser.
> I've done more than my fair share of C coding for non-optimising
> compilers. Writing for proper compilers lets you write /far/ better
> source code
And far worse. I've generated dreadful-looking three-address-code
expressed in linear C, with dozens of temporaries and only if/goto for
control flow.
And gcc-O3 cleaned it all up. Which is admirable: if I was generating
that now, I'd want to to use gcc-O3 on it. But I'm not.
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web