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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-17 14:31 +0200 |
| Message-ID | <pb4pfq$eks$1@dont-email.me> |
| In reply to | #129319 |
On 17/04/18 13:24, bartc wrote: > 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. Or you can leave it as an example of not being able to write C code... As to being lazy, inefficient or untidy - that's a matter of opinion. And quite frankly, I don't place a lot of credit on your opinions of good style in C coding. Knowing that you have a good optimising compiler means that you /can/ write: for (sizeof_t i = 0; i < strlen(s); i++) ... if that's what you think makes the cleanest and clearest code. It certainly does not mean that you /have/ to write it that way - but you can choose based on criteria other than the details of the generated code. Using an optimised compiler means that you can concentrate more on things like maintainability, correctness, testability, readability - and don't need to be concerned about exactly how the code will run. > > > 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. Or it could offer a few flexible and general loop forms, and let compilers do the donkey work of analysing them and generating the best code. > > 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. I've used plenty of compilers that can't even manage that. It is merely a simple example of strength reduction - you can replace it with a more advanced one if you like: y = x / 3; instead of: y = ((long long int) x * 1431655766) >> 31; The compiler will, of course, generate the correct values here, and make sure it all works regardless of the sizes of the operands, their signedness, etc. > > 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. > It could - but it doesn't. Boolean flags and breaking functions into sub-functions is usually the way I handle it. > 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. Yes - for those two cases. They are common cases, but hardly the only use of function-like 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. Or even better, let the /compiler/ figure out where it makes sense to inline code. Compilers are much better at this than humans, and adapt easily to changes in the code without having to re-write stuff. > >> 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. People have always, and will always, write ugly and unpleasant code. Optimising compilers don't encourage that - they help, by letting people write /nice/ code and still get fast results. > I've generated dreadful-looking three-address-code > expressed in linear C, with dozens of temporaries and only if/goto for > control flow. That is, of course, exactly the sort of thing you usually want from generated C code. > > 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. >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-04-16 16:59 -0500 |
| Message-ID | <lp6add9eo4ne41ouacgp7j9h7atfh6n2ja@4ax.com> |
| In reply to | #129278 |
On Mon, 16 Apr 2018 17:31:58 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >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. And especially small(-ish) functions that are subject to considerable specialization when they get inlined. And absolutely, you write code with an eye towards clarity an maintainability, and assume the compiler will do a competent job optimizing.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-17 01:02 +0100 |
| Message-ID | <BQaBC.929758$B71.745883@fx15.am4> |
| In reply to | #129291 |
On 16/04/2018 22:59, Robert Wessel wrote: > On Mon, 16 Apr 2018 17:31:58 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote: >> Yep. In our case, we use many small inline functions. > > > And especially small(-ish) functions that are subject to considerable > specialization when they get inlined. > > And absolutely, you write code with an eye towards clarity an > maintainability, and assume the compiler will do a competent job > optimizing. That's ironic when talking about C. When I was writing more C a few years ago, I more or less waved goodbye to clarity and maintainability. And you all know why. (Clarity in a language with C's type syntax? Sure. Just finding out where a function starts is enough of a challenge!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-17 09:47 +0200 |
| Message-ID | <pb48qf$np7$2@dont-email.me> |
| In reply to | #129296 |
On 17/04/18 02:02, bartc wrote: > On 16/04/2018 22:59, Robert Wessel wrote: >> On Mon, 16 Apr 2018 17:31:58 GMT, scott@slp53.sl.home (Scott Lurndal) >> wrote: > >>> Yep. In our case, we use many small inline functions. >> >> >> And especially small(-ish) functions that are subject to considerable >> specialization when they get inlined. >> >> And absolutely, you write code with an eye towards clarity an >> maintainability, and assume the compiler will do a competent job >> optimizing. > > That's ironic when talking about C. > > When I was writing more C a few years ago, I more or less waved goodbye > to clarity and maintainability. And you all know why. Yes, we know why - there were two reasons. One is that you steadfastly refuse to learn anything and are determined to write bad C code - simply so that you can continue to claim that C is such a terrible language. The other is that you steadfastly refuse to use a decent compiler, and thus have to sacrifice some clarity and maintainability for performance. > > (Clarity in a language with C's type syntax? Sure. Just finding out > where a function starts is enough of a challenge!) >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-17 13:16 +0100 |
| Message-ID | <1AlBC.365110$By2.155760@fx30.am4> |
| In reply to | #129309 |
On 17/04/2018 08:47, David Brown wrote:
> On 17/04/18 02:02, bartc wrote:
>> On 16/04/2018 22:59, Robert Wessel wrote:
>>> On Mon, 16 Apr 2018 17:31:58 GMT, scott@slp53.sl.home (Scott Lurndal)
>>> wrote:
>>
>>>> Yep. In our case, we use many small inline functions.
>>>
>>>
>>> And especially small(-ish) functions that are subject to considerable
>>> specialization when they get inlined.
>>>
>>> And absolutely, you write code with an eye towards clarity an
>>> maintainability, and assume the compiler will do a competent job
>>> optimizing.
>>
>> That's ironic when talking about C.
>>
>> When I was writing more C a few years ago, I more or less waved goodbye
>> to clarity and maintainability. And you all know why.
>
> Yes, we know why - there were two reasons. One is that you steadfastly
> refuse to learn anything and are determined to write bad C code - simply
> so that you can continue to claim that C is such a terrible language.
You forget that I've seen plenty of examples of other people's code.
When I started /generating code/, then my C started to look like this:
global function i32 *do_push_m(void)
{
(*(--sptr))=(*(varrec (*))(*(pcptr+1)));
sptr->copy |= 1;
return (pcptr+2);
}
global function i32 *do_push_f(void)
{
(*(--sptr))=(*(varrec (*))(frameptr+(*(pcptr+1))));
sptr->copy |= 1;
return (pcptr+2);
}
Notice the 'global function' prefixes which most people here would think
are totally useless.
> The other is that you steadfastly refuse to use a decent compiler, and
> thus have to sacrifice some clarity and maintainability for performance.
I used gcc-O3. For my interpreter, the simplest and clearest dispatch
method was to use a small function with a simple loop calling function
pointers. But that wasn't the fastest.
Faster was to use a giant switch statement, but that was 250 lines extra
and less clear. But that wasn't the fastest either.
Faster was to use label pointers, with a table of 250 label addresses,
and a set of 250 labels followed by a function call on each. A lot less
clear. But even that wasn't /quite/ the fastest.
To get the best speed, I needed to add something like
__attribute__(always_inline) to certain functions. Even more obfuscation.
It's never as simple a matter of just using O2 or O3. Actually, O2 or O3
will just help obscure matters.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-17 14:38 +0200 |
| Message-ID | <pb4psr$mhv$1@dont-email.me> |
| In reply to | #129323 |
On 17/04/18 14:16, bartc wrote:
> On 17/04/2018 08:47, David Brown wrote:
>> On 17/04/18 02:02, bartc wrote:
>>> On 16/04/2018 22:59, Robert Wessel wrote:
>>>> On Mon, 16 Apr 2018 17:31:58 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>> wrote:
>>>
>>>>> Yep. In our case, we use many small inline functions.
>>>>
>>>>
>>>> And especially small(-ish) functions that are subject to considerable
>>>> specialization when they get inlined.
>>>>
>>>> And absolutely, you write code with an eye towards clarity an
>>>> maintainability, and assume the compiler will do a competent job
>>>> optimizing.
>>>
>>> That's ironic when talking about C.
>>>
>>> When I was writing more C a few years ago, I more or less waved goodbye
>>> to clarity and maintainability. And you all know why.
>>
>> Yes, we know why - there were two reasons. One is that you steadfastly
>> refuse to learn anything and are determined to write bad C code - simply
>> so that you can continue to claim that C is such a terrible language.
>
> You forget that I've seen plenty of examples of other people's code.
> When I started /generating code/, then my C started to look like this:
>
> global function i32 *do_push_m(void)
> {
> (*(--sptr))=(*(varrec (*))(*(pcptr+1)));
> sptr->copy |= 1;
> return (pcptr+2);
> }
>
> global function i32 *do_push_f(void)
> {
> (*(--sptr))=(*(varrec (*))(frameptr+(*(pcptr+1))));
> sptr->copy |= 1;
> return (pcptr+2);
> }
>
> Notice the 'global function' prefixes which most people here would think
> are totally useless.
If that is C, then I don't know what either "global" or "function" would
do here - presumably they are empty macros? If you like them because
you think it helps you keep your code legible, then fair enough. Other
people may disagree, but that's your choice.
However, making such small, commonly used functions "global" rather than
static may lose you a lot of optimisation opportunities (when you
compile with a good compiler, of course). And casting your pointers
like this is almost certainly breaking the aliasing rules of C.
>
>> The other is that you steadfastly refuse to use a decent compiler, and
>> thus have to sacrifice some clarity and maintainability for performance.
>
> I used gcc-O3. For my interpreter, the simplest and clearest dispatch
> method was to use a small function with a simple loop calling function
> pointers. But that wasn't the fastest.
>
> Faster was to use a giant switch statement, but that was 250 lines extra
> and less clear. But that wasn't the fastest either.
>
> Faster was to use label pointers, with a table of 250 label addresses,
> and a set of 250 labels followed by a function call on each. A lot less
> clear. But even that wasn't /quite/ the fastest.
>
> To get the best speed, I needed to add something like
> __attribute__(always_inline) to certain functions. Even more obfuscation.
>
> It's never as simple a matter of just using O2 or O3. Actually, O2 or O3
> will just help obscure matters.
>
No one ever claimed that getting the /fastest/ code was just a matter of
using "-O2". It takes work.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-17 13:18 +0000 |
| Message-ID | <CumBC.4544$PE5.1290@fx37.iad> |
| In reply to | #129309 |
David Brown <david.brown@hesbynett.no> writes: >Yes, we know why - there were two reasons. One is that you steadfastly >refuse to learn anything and are determined to write bad C code - simply >so that you can continue to claim that C is such a terrible language. >The other is that you steadfastly refuse to use a decent compiler, and >thus have to sacrifice some clarity and maintainability for performance. Actually, I've come to the conclusion that Bart is simply a troll, and it seems pointless to engage him further.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-17 14:37 +0100 |
| Message-ID | <MMmBC.556849$iy7.490494@fx09.am4> |
| In reply to | #129332 |
On 17/04/2018 14:18, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: > >> Yes, we know why - there were two reasons. One is that you steadfastly >> refuse to learn anything and are determined to write bad C code - simply >> so that you can continue to claim that C is such a terrible language. >> The other is that you steadfastly refuse to use a decent compiler, and >> thus have to sacrifice some clarity and maintainability for performance. > > Actually, I've come to the conclusion that Bart is simply a troll, and it > seems pointless to engage him further. You made an outrageous claim about what compiler optimisation can achieve, and haven't really explained how it is was possible. Nor even supplied an example of any program demonstrating such a speed-up. Who's the troll again? Bear in mind some newcomers here might really believe their C application might run 10, 20 or 40 times faster simply by using -O3 instead of -O0. I think it seems pointless to engage /you/ further.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-17 06:44 -0700 |
| Message-ID | <3246e417-1429-4911-80fb-3df4387e8665@googlegroups.com> |
| In reply to | #129333 |
On Tuesday, April 17, 2018 at 2:37:57 PM UTC+1, Bart wrote: > On 17/04/2018 14:18, Scott Lurndal wrote: > > David Brown <david.brown@hesbynett.no> writes: > > > >> Yes, we know why - there were two reasons. One is that you steadfastly > >> refuse to learn anything and are determined to write bad C code - simply > >> so that you can continue to claim that C is such a terrible language. > >> The other is that you steadfastly refuse to use a decent compiler, and > >> thus have to sacrifice some clarity and maintainability for performance. > > > > Actually, I've come to the conclusion that Bart is simply a troll, and it > > seems pointless to engage him further. > > You made an outrageous claim about what compiler optimisation can > achieve, and haven't really explained how it is was possible. Nor even > supplied an example of any program demonstrating such a speed-up. > > Who's the troll again? > > Bear in mind some newcomers here might really believe their C > application might run 10, 20 or 40 times faster simply by using -O3 > instead of -O0. > > I think it seems pointless to engage /you/ further. > You do come across as a bit too determined to see the faults in C. However you understand the domain of algorithmic C programming, where the challenge is to devise a method for doing something rather then to interact correctly with hardware or encode a set of "business rules". It's very important that components be kept lightweight or they generally fail to make the trip from the original environment to the new one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-17 15:58 +0200 |
| Message-ID | <pb4uho$k5u$1@dont-email.me> |
| In reply to | #129333 |
On 17/04/18 15:37, bartc wrote: > On 17/04/2018 14:18, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> Yes, we know why - there were two reasons. One is that you steadfastly >>> refuse to learn anything and are determined to write bad C code - simply >>> so that you can continue to claim that C is such a terrible language. >>> The other is that you steadfastly refuse to use a decent compiler, and >>> thus have to sacrifice some clarity and maintainability for performance. >> >> Actually, I've come to the conclusion that Bart is simply a troll, and it >> seems pointless to engage him further. > > You made an outrageous claim about what compiler optimisation can > achieve, and haven't really explained how it is was possible. Nor even > supplied an example of any program demonstrating such a speed-up. What outrageous claim? I wouldn't expect Scott to publish his code - nor would I publish my code. But just to please you I gave you an example. > > Who's the troll again? Would that be the one that is continually misrepresenting what other people write? > > Bear in mind some newcomers here might really believe their C > application might run 10, 20 or 40 times faster simply by using -O3 > instead of -O0. I tend to take the position that people can read and think, until proven otherwise. Nobody remotely suggested that you can take any C code and have it run that much faster with a compiler flag. What Scott claimed - and I believe him, based on my own experiences - is that if you have code that has lots of small functions you can often get an order of magnitude or so more efficient cpu code by using letting the compiler do good inlining. (If the code is C++, written in a modern style, then this will make a /huge/ difference.) And higher order optimisation can sometimes - depending on the code, and the target processor - also give very significant speedups though vectorisation and techniques such as function cloning and partial inlining. Optimisation makes the biggest difference for code that is written to take advantage of optimising compilers, and written to work well with optimising compilers. It makes much less of a difference to code that is either written in an unhelpful manner (such as missing "static"), or that is full of "hand optimisations". Nobody thinks that will help if the bottlenecks are elsewhere - such as memory use or file I/O. Nobody thinks it will gloss over a poor choice of algorithm. Nobody thinks it will be significant in all code - or even most code. > > I think it seems pointless to engage /you/ further. > > >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-17 15:43 +0000 |
| Message-ID | <YCoBC.239$7H4.164@fx12.iad> |
| In reply to | #129333 |
bartc <bc@freeuk.com> writes: >On 17/04/2018 14:18, Scott Lurndal wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> Yes, we know why - there were two reasons. One is that you steadfastly >>> refuse to learn anything and are determined to write bad C code - simply >>> so that you can continue to claim that C is such a terrible language. >>> The other is that you steadfastly refuse to use a decent compiler, and >>> thus have to sacrifice some clarity and maintainability for performance. >> >> Actually, I've come to the conclusion that Bart is simply a troll, and it >> seems pointless to engage him further. > >You made an outrageous claim about what compiler optimisation can >achieve, and haven't really explained how it is was possible. Actually, both David and I have explained how we think it is possible, not that either of us are required to explain anything to you. > Nor even >supplied an example of any program demonstrating such a speed-up. Actually, I did describe the program - and others commented on it. > >Who's the troll again? That would be you.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-17 08:47 -0700 |
| Message-ID | <4a375da3-3674-4c22-ba0c-fa5740165e66@googlegroups.com> |
| In reply to | #129349 |
On Tuesday, April 17, 2018 at 8:44:01 AM UTC-7, Scott Lurndal wrote: > bartc <bc@freeuk.com> writes: > >On 17/04/2018 14:18, Scott Lurndal wrote: > >> David Brown <david.brown@hesbynett.no> writes: > >> > >>> Yes, we know why - there were two reasons. One is that you steadfastly > >>> refuse to learn anything and are determined to write bad C code - simply > >>> so that you can continue to claim that C is such a terrible language. > >>> The other is that you steadfastly refuse to use a decent compiler, and > >>> thus have to sacrifice some clarity and maintainability for performance. > >> > >> Actually, I've come to the conclusion that Bart is simply a troll, and it > >> seems pointless to engage him further. > > > >You made an outrageous claim about what compiler optimisation can > >achieve, and haven't really explained how it is was possible. > > Actually, both David and I have explained how we think it is > possible, not that either of us are required to explain anything > to you. > > > Nor even > >supplied an example of any program demonstrating such a speed-up. > > Actually, I did describe the program - and others commented on it. > > > > >Who's the troll again? > > That would be you. If Daniel Lewis calls being busted using socks by dozens of people good 'trolling', then yeah... he is a fine troll. I don't subscribe to that view, I use another term. I call him a perfect fool. I bet he thinks your life was worse than Jessica Lane's. I am working on code which will blow what Linux has away. Right, Daniel Lewis is looking to produce a Unity variable, which Jessica Lane can get in 5 seconds. If he could stop being so screwed up he would figure out how stupid he sounds. Several of us reported Daniel Lewis years ago. As expected, it did squat to attenuate the imbecile. -- Top Six Ways Daniel Lewis Trolls!! https://redd.it/6sfkup Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-17 08:04 +1200 |
| Message-ID | <fjkdueFc8hgU1@mid.individual.net> |
| In reply to | #129269 |
On 04/17/2018 04:09 AM, 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. Yours is at the extreme end of the scale, probably because you have managed to keep caches full and cores running flat out. Most software wastes CPU cycles stalling or blocking, so optimisations don't play such a dominant role in the overall performance. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-16 20:30 +0000 |
| Message-ID | <TJ7BC.2$z83.0@fx19.iad> |
| In reply to | #129285 |
Ian Collins <ian-news@hotmail.com> writes: >On 04/17/2018 04:09 AM, 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. > >Yours is at the extreme end of the scale, probably because you have >managed to keep caches full and cores running flat out. Most software >wastes CPU cycles stalling or blocking, so optimisations don't play such >a dominant role in the overall performance. You just don't notice the issues because modern CPU's are too powerful :-)
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-04-16 16:31 +0000 |
| Message-ID | <9d4BC.1239495$lm7.807409@fx12.am4> |
| In reply to | #129268 |
On 2018-04-16, bartc <bc@freeuk.com> wrote: > 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 have a benchmark called NSIEVE that uses arrays large enough not to > fit in the cache. With gcc, the difference between -O0 and -O3 is about > 15%. I would have thought such a large-scale applications would have > used enough resources like that, that optimisations would be less > effective.) > Without cache, IPC is 0.x, rather then 2-3. -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-20 14:22 -0700 |
| Message-ID | <lnvacliner.fsf@kst-u.example.com> |
| In reply to | #129264 |
scott@slp53.sl.home (Scott Lurndal) writes:
> 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.
That's interesting. The application is in C, right?
Is there something unusual about your application that results in
such extreme speed improvement from optimization? (You mentioned
inlining.) Can you share the source? (I suspect the answer is no,
but I thought I'd ask.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-17 00:42 -0700 |
| Message-ID | <8a460650-be4a-4874-8763-fbd2458647d0@googlegroups.com> |
| In reply to | #129254 |
On Monday, April 16, 2018 at 5:40:01 AM UTC-7, David Brown wrote:
> On 16/04/18 14:02, bartc wrote:
> > On 16/04/2018 11:54, David Brown wrote:
> >> On 16/04/18 12:37, bartc wrote:
> >
> >>> Testing only immul(), my own compiler is faster than gcc-O0. So I don't
> >>> need to look at that code. But with isort() and compress(), overall
> >>> gcc-O0 is faster, so I might want to have a quick look at why.
> >>>
> >>
> >> gcc -O0 is basically useless, and no one who understands compilers uses
> >> it for anything serious.
> >
> > OK, let's see, I've created two versions of a program that is a
> > byte-code compiler, one with gcc-O3 and the other with gcc-O0:
> >
> > qcgcco0.exe
> > qcgcco3.exe
> >
> > I'm going to use it to compile a 24Kloc, 20-module program; how much
> > difference do you think the optimisation of gcc will make? These are two
> > actual consecutive runs:
> >
> > c:\mxold>timeit "\q\qcgcco3 mc"
> > Q Compiler 12.1
> > Compiling mc.q to mc.pc
> > \q\qcgcco3 mc 0.09
> >
> > c:\mxold>timeit "\q\qcgcco0 mc"
> > Q Compiler 12.1
> > Compiling mc.q to mc.pc
> > \q\qcgcco0 mc 0.09
> >
> > The elapsed time is the 0.09 figure, so both take 90msec. 'timeit' is a
> > C program that calls system() with the parameter, and measures clock()
> > before and after.
>
> You cannot possibly hope to get useful timings like that. You are
> measuring noise, for the most part.
>
> >
> > Actually there are small differences; sometimes o0 takes 0.11, and
> > sometimes o3 takes 0.08. And internal timing, which excludes process
> > overheads, gives 31msec for o3 and 47msec for o0, but the timer
> > resolution is 16msec; they can't get any closer without being identical.
> > (All runs make use of OS file cacheing.)
> >
> > But whatever the timing, it makes no practical difference to running
> > this program. Here's one more timing:
> >
> > c:\mxold>timeit "\q\qctcc mc"
> > Q Compiler 12.1
> > Compiling mc.q to mc.pc
> > \q\qctcc mc 0.12
> >
> > Tiny C takes 0.12 seconds (but sometimes 0.14). Internal time 63ms.
>
> Again, you can't make such timings and think you have something useful.
>
> >
> > For this application, the performance of the C code is almost
> > irrelevant. And it's not a trivial application either because it is
> > building my main non-C compiler from scratch.
>
> The actual run-time of the C code itself is negligible in this case.
> (That does not mean it is not doing something useful - just that it is
> not doing something that takes significant time.) Your measurements
> will be dominated by the program doing the measurements, the OS in
> starting and stopping the processes, the cache effects (including how
> many other programs are running in the background), the file I/O, etc.
>
> >
> >> About the only use of -O0 is for syntax checking - or
> >> for pretending that your own compiler generates better code than gcc.
> >
> > My own C compiler for this program also gives 0.09 (and sometimes 0.11).
> > All these programs use the same one-file C source which ought to give
> > gcc even more opportunity to optimise as it can see the whole program.
> >
> > So, do you still think that gcc-O0 is useless? If not then you also have
> > to admit that other C compilers which don't optimise as well as gcc have
> > their uses too.
> >
>
> I mean gcc -O0 is useless as an alternative to gcc -O1 or higher. I
> would have thought that was obvious.
>
> Other compilers may have their advantages compared to gcc - some will be
> faster to compile, some generate faster code, some will be easier to
> install for people who find gcc too complicated, some will have
> different additional features.
Was that meant to be to me? Takuya Saitoh is trying ("very, very" hard) to project their trolling crap onto Krystal Lynn. For as long as I can remember Takuya Saitoh has spurred the theory that Krystal Lynn needs 'documentation' to point out all his crap. The fact is that no one needs any proof to do that. So Takuya Saitoh pulls this nonsensical blaming baloney in a feeble attempt to 'boost' the idea that Krystal Lynn is like he is. All that Takuya Saitoh cares about is that Takuya Saitoh gets to dish out his prank call and then hang up and giggle about it. The fact that Krystal Lynn is a real person on the other end of the phone is what's funny.
--
Curious how these posts are made? Email: frelwizzen@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-16 07:00 -0700 |
| Message-ID | <44bf5b6a-c741-43b7-b10c-9fa46fab8d58@googlegroups.com> |
| In reply to | #129252 |
On Monday, April 16, 2018 at 11:54:33 AM UTC+1, David Brown wrote: > > And if you find that the good optimising compiler has thrashed another > tool because it has found shortcuts that you don't like, then the fault > lies with the benchmark, not the compiler. > Not really. A reasonable benchmark would be to calculate how fast it can take a square root. However just passing sqrt(2.0) would likely have too much noise. So a reasonable benchmark could take ten thousand square roots. Now if a clever optimiser optimises the loop to nothing on the grounds that the results are discarded, then the test becomes useless. That's irritating and a reasonable response is to turn that optimisation off, if it's possible. Eventually you'll have to sum the results and print out the answer to defeat the optimiser, of course.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-16 16:35 +0200 |
| Message-ID | <pb2cbv$9i2$1@dont-email.me> |
| In reply to | #129257 |
On 16/04/18 16:00, Malcolm McLean wrote: > On Monday, April 16, 2018 at 11:54:33 AM UTC+1, David Brown wrote: >> >> And if you find that the good optimising compiler has thrashed another >> tool because it has found shortcuts that you don't like, then the fault >> lies with the benchmark, not the compiler. >> > Not really. A reasonable benchmark would be to calculate how fast it > can take a square root. However just passing sqrt(2.0) would likely > have too much noise. So a reasonable benchmark could take ten thousand > square roots. > > Now if a clever optimiser optimises the loop to nothing on the grounds > that the results are discarded, then the test becomes useless. That's > irritating and a reasonable response is to turn that optimisation > off, if it's possible. No, a /stupid/ response is to turn off optimisation. A reasonable response is to tell the compiler that the result cannot be discarded (such as by storing it in a volatile). The fault lies with the benchmark - or the benchmark author, if you prefer. > > Eventually you'll have to sum the results and print out the answer to > defeat the optimiser, of course. > If you are trying to "defeat the optimiser", then you are wasting your effort looking at benchmarks, or even considering compiler speed.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-16 09:28 -0700 |
| Message-ID | <1a423d4a-45d6-4199-a597-11a20768d800@googlegroups.com> |
| In reply to | #129259 |
On Monday, April 16, 2018 at 3:35:53 PM UTC+1, David Brown wrote: > On 16/04/18 16:00, Malcolm McLean wrote: > > > > > Eventually you'll have to sum the results and print out the answer to > > defeat the optimiser, of course. > > > > If you are trying to "defeat the optimiser", then you are wasting your > effort looking at benchmarks, or even considering compiler speed. > An optimiser that eliminates large chunks of unused code isn't very valuable in most programming environments, where programmers simply don't write significant amounts of code that is unused. The exception is where code is written for profiling purposes. Yes, you can write to a volatile, but memory access is one of the most expensive operations, and that makes the profiling code harder to write and interpret. In reality if we are taking 10,000 square roots we'll be normalizing 10,000 lighting vectors for a 3D mesh. As part of our optimisation strategy, we might want to know how much time the processor spends in the square root function itself, so we might write a scratch program that submits 10000 square roots in a tight loop. But obviously you need to turn off any optimisations such as common expression elimination or unused value ignoring, if the result is going to be at all valuable.
[toc] | [prev] | [next] | [standalone]
Page 7 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