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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-18 05:35 -0700 |
| Message-ID | <82bc18f8-210e-489c-ac96-b4c296745b06@googlegroups.com> |
| In reply to | #129394 |
On Wednesday, April 18, 2018 at 12:41:33 PM UTC+1, David Brown wrote: > On 18/04/18 13:15, Malcolm McLean wrote: > > On Wednesday, April 18, 2018 at 12:01:52 PM UTC+1, David Brown wrote: > >> On 18/04/18 12:30, bartc wrote: > >>> On 18/04/2018 08:27, David Brown wrote: > >>>> On 18/04/18 00:20, bartc wrote: > >>>>> On 17/04/2018 22:00, David Brown wrote: > >>>>>> On 17/04/18 19:45, bartc wrote: > >>>>> > >>>>>> What, you think all programs should run in a few seconds? Some > >>>>>> programs have a lot of work to do. > >>>>> > >>>>> The same program normally taking 25 seconds, takes 9 1/2 extra minutes, > >>>>> and you just shrug that off? > >>>>> > >>>> > >>>> Who is shrugging things off? Scott already knows the main cause of the > >>>> difference, and has already told us. > >>>> > >>>> As I said before, I think (but have not had conformation of this) that > >>>> Scott's code is actually modern C++ rather than C. > >>> > >>> So the code isn't even C that we're talking about? > >> > >> As I say, that's my guess - but I am not sure. > >> > >>> > >>> In that case all bets are off. > >> > >> No, they are not. It's the same compiler, the same settings, the same > >> optimisations, and the same key reason for a difference in the generated > >> code. It is merely that in modern C++ styles you are likely to have > >> more small functions than in C programming. > >> > >>> > >>> And another mark against C++ if the language and the way it's used is so > >>> impossibly complicated that it DOES rely on hyper-optimisation to avoid > >>> it running as slow as an interpreted scripting language. > >> > >> You really do like to complain about /everything/, don't you? This is > >> not a "mark against C++" - it is a mark against numpties who think they > >> can use a language but have no idea what the tools are for or how to use > >> them. > >> > > I'm currently using a C interpreter to embed C into a new programming > > language of my own devising. The C interpreter was written by one person, > > and it's small enough that it's also a one man job to modify it so > > that it works with my system. > > A C++ interpreter would not be so tractable. It's not a one man job > > to write one, and it would run too slowly. It would also likely be > > too complex to be easily modifiable. The project itself can embed > > any serial language, it's a parallel protocol at heart. C++ would > > actually be a better fit than C, were it not for the problem of obtaining > > an embeddable implementation. > > > > Embedding a C interpreter in another language is a bad idea unless you > have a desperate need for compatibility. There are many embeddable > scripting languages available that are a better plan in most cases - Lua > is a prime example. Adding Lua to a C (or C++) system as an embedded > interpreted language is done in a couple of days. > > Making a C++ interpreter is far worse - it would be completely crazy. > > For a big enough system, where you need the power and speed of C or C++, > you use clang/llvm as libraries. > > > Size of tools matters. That's something Bart understands but you don't, > > because you don't have the right sort of programming experience. > > > > I fully understand that size can matter. But I also understand when it > /doesn't/ matter (which is almost all of the time), and I understand > picking appropriate tools for the job. > > So when I have needed an embedded scripting language in small C systems, > I have used Lua. If I were working on a big application and needed a > big embedded scripting language, I would probably still choose Lua. If > Lua is not enough, I'd embed Python. (TCL is another popular choice.) > Writing a C interpreter would be combining all the worst aspects of C > with all the worst aspects of an interpreted language, and wrapping the > whole thing in a big waste of developer time. > The version with the C interpreter is a proof of concept. It's then intended to replace with a compiler after the new language has matured. You could also use Lua, that's not necessarily a bad idea.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-18 12:26 +0100 |
| Message-ID | <8XFBC.1464447$oG7.692613@fx14.am4> |
| In reply to | #129390 |
On 18/04/2018 12:01, David Brown wrote: > On 18/04/18 12:30, bartc wrote: >> And another mark against C++ if the language and the way it's used is so >> impossibly complicated that it DOES rely on hyper-optimisation to avoid >> it running as slow as an interpreted scripting language. >> That is the astonishing fact that you are brushing off. > Apparently, some people are easily astonished. So, let me get this straight. Someone claims that using -O2 or -O3 instead of O0, gives the same degree of speed-up as switching from Python to C, and you just take that at face value, while decrying anyone who dares to question it. OK, thanks. Now at least I know that you are just winding me up. > <snip due to the pointlessness of this thread> It sounds like you don't want to admit that, most of the time, optimisation applied to an /application/ gives worthwhile but not overly dramatic results. My own apps might show up to 50% improvement. Compiling the Lua intepreter, gcc-O3 made it double the speed compared to using my own compiler. But that is still within my 1x to 2x figure. (And my code generator can do with some work so it could be better.) Malcolm gave an example of 200% improvement but in a rather narrow application. (But I also ran his BBX program which, being interactive, made it somewhat irrelevant as to whether it was optimised or not.) The question is, can a C program compiled without optimisation, ever produce programs that can be usefully run? To me the answer is a resounding Yes. To you presumably any such program would be so slow as to be unusable. Even interactive ones. It does sound very much as though if I were so say that something was black (because it is), you would claim it was white. I think you and me are done here. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-18 13:58 +0200 |
| Message-ID | <pb7bth$ovt$1@dont-email.me> |
| In reply to | #129392 |
On 18/04/18 13:26, bartc wrote: > On 18/04/2018 12:01, David Brown wrote: >> On 18/04/18 12:30, bartc wrote: > >>> And another mark against C++ if the language and the way it's used is so >>> impossibly complicated that it DOES rely on hyper-optimisation to avoid >>> it running as slow as an interpreted scripting language. > >>> That is the astonishing fact that you are brushing off. > >> Apparently, some people are easily astonished. > > So, let me get this straight. Someone claims that using -O2 or -O3 > instead of O0, gives the same degree of speed-up as switching from > Python to C, and you just take that at face value, while decrying anyone > who dares to question it. I decry anyone who thinks Scott is lying here, and anyone who fails to understand how such differences can occur after it has been carefully and repeatedly explained to them. Oh, and the difference between Python and C can range from perhaps 3 to 3000 times slower, depending on the type of code. If you want justification for that, you can look elsewhere. > > OK, thanks. Now at least I know that you are just winding me up. > >> <snip due to the pointlessness of this thread> > > It sounds like you don't want to admit that, most of the time, > optimisation applied to an /application/ gives worthwhile but not overly > dramatic results. I am quite happy to agree that on many code bases, the difference between gcc -O0 to -O2 or -O3 is going to be somewhere between 1.5 and 3 times. I am also quite happy to agree that this difference is often not significant. No where have I disagreed with any of that. But Scott's application has a far bigger difference. Other types of code too will show a huge difference. My own code can, in some places, show huge differences from optimisation - though mostly it is much more modest. A key reason for seeing more dramatic optimisation improvements is the way the code is organised and divided - especially the degree of inlining achieved. My own experience has included programs that were too big or slow for the task when optimisation was disabled. And I consider optimisation and a good optimising compiler as essential tools for a serious programmer. OK? Do you understand? Once you have removed all your straw man arguments and misrepresentations, are there any parts of that paragraph that you disagree with? > > The question is, can a C program compiled without optimisation, ever > produce programs that can be usefully run? > > To me the answer is a resounding Yes. > Sure - I have never disagreed with that. Is there any point in running an optimising compiler with optimisation disabled? Yes, but rarely - there are advantages for some uses (like debugging) but disadvantages too (like needlessly big and slow code, and poorer static analysis). Is there any point in running /gcc/ (as distinct from any other compiler) with -O0 rather than -O1? Very, very rarely, IMHO. There are times during development when -O1 is a better choice than -O2 or -O3, and there are a lot of programs for which -O2 or -O3 really doesn't make a real, useful difference. > To you presumably any such program would be so slow as to be unusable. Where /do/ you get your ideas? Feel free to show quotations to justify that presumption. > Even interactive ones. It does sound very much as though if I were so > say that something was black (because it is), you would claim it was white. > > I think you and me are done here. > >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-18 22:29 +0100 |
| Message-ID | <PMOBC.931190$B71.241590@fx15.am4> |
| In reply to | #129395 |
On 18/04/2018 12:58, David Brown wrote: > On 18/04/18 13:26, bartc wrote: >> It sounds like you don't want to admit that, most of the time, >> optimisation applied to an /application/ gives worthwhile but not overly >> dramatic results. > > I am quite happy to agree that on many code bases, the difference > between gcc -O0 to -O2 or -O3 is going to be somewhere between 1.5 and 3 > times. I am also quite happy to agree that this difference is often not > significant. No where have I disagreed with any of that. Thank you. Just change that 1.5 to 1.0 (since on some kinds of apps, it makes little difference) and we're in general agreement. Except that from my own experience of /applications/, I tend to see figures up to 2.0 (with small benchmarks, it could be up to 10x when the optimised code is still doing the work, and infinity when it finds a way of not doing it). This is why I think a compiler producing reasonably sensible code but without any serious optimising passes, or none at all, can be a viable proposition. Especially as my current project (not for C) will offer ways of doing language-assisted speed-ups. It is, for example, a whole project compiler. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-18 10:34 -0700 |
| Message-ID | <lna7u0l8po.fsf@kst-u.example.com> |
| In reply to | #129392 |
bartc <bc@freeuk.com> writes:
> On 18/04/2018 12:01, David Brown wrote:
[snip]
> I think you and me are done here.
David, he's giving you a way out. Take it.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-18 22:34 +0200 |
| Message-ID | <pb8a4k$l5r$1@dont-email.me> |
| In reply to | #129417 |
On 18/04/18 19:34, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 18/04/2018 12:01, David Brown wrote: > [snip] >> I think you and me are done here. > > David, he's giving you a way out. Take it. > I'm trying :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-18 22:35 +0200 |
| Message-ID | <pb8a6s$l5r$2@dont-email.me> |
| In reply to | #129432 |
On 18/04/18 22:34, David Brown wrote: > On 18/04/18 19:34, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 18/04/2018 12:01, David Brown wrote: >> [snip] >>> I think you and me are done here. >> >> David, he's giving you a way out. Take it. >> > > I'm trying :-) > And I'm off on holiday for a couple of weeks on Friday - so that will definitely mean a break in this thread!
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-19 20:05 +0100 |
| Message-ID | <NL5CC.658974$Oy5.533339@fx11.am4> |
| In reply to | #129390 |
On 18/04/2018 12:01, David Brown wrote: > On 18/04/18 12:30, bartc wrote: >> And another mark against C++ if the language and the way it's used is so >> impossibly complicated that it DOES rely on hyper-optimisation to avoid >> it running as slow as an interpreted scripting language. > > You really do like to complain about /everything/, don't you? This is > not a "mark against C++" - it is a mark against numpties who think they > can use a language but have no idea what the tools are for or how to use > them. David is on holiday so perhaps someone else can pitch in. I said the way C++ is used is complicated - true or not? I said that it relies on optimisation - true or not? I said that it otherwise runs as slow as an interpreted language - true or not? And if all those do apply, then it does appear to be a mark against C++ - true or not? Since it seems that, in the case being discussed at least, C++ /was/ used in a such a way that a 20-40 times slowdown resulted unless it was optimised (and any other possible causes were dismissed), and 20-40 times /is/ typically how much slower an interpreted language can be, then I can't see those statements being anything other than true. I suspect David is being a trifle over-defensive of his favourite language and any upstart who dares to criticise it is an idiotic 'numpty' who knows nothing. (Such grown-up debate here.) >> that I wouldn't know if a such a claim was out of field? >> > > Apparently, yes. Since he later admitted more typical speed-ups due to optimisation might be of the order of 1.5 to 3, that suggests that the claim of '20-40 times' /would/ be 'out of field'. So I wasn't wrong then either. > Apparently, some people are easily astonished. Here David is saying that a 20:1 or 40:1 factor in optimised:unoptimised speeds is such an unremarkable figure that no one should be astonished. (I wonder what figure then is necessary for anyone to show astonishment? And who gets to decide the astonishment threshold? Him?) >> They both do the same job. > > I'm glad I wasn't drinking coffee when I read /that/ remark! I take it that he thinks that his C compiler turning a .c file into an executable is doing such a superior job that the idea of anything of mine performing the same translation is laughable. I'm not really interested in this particular debate any more - I'm more fascinated by the now apparent bullying. It seems David Brown hates me and hates my work so much that he's prepared to ignore both facts and common sense. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-20 08:07 +1200 |
| Message-ID | <fjsbc0Fcse1U1@mid.individual.net> |
| In reply to | #129462 |
On 04/20/2018 07:05 AM, bartc wrote: > On 18/04/2018 12:01, David Brown wrote: >> On 18/04/18 12:30, bartc wrote: > >>> And another mark against C++ if the language and the way it's used is so >>> impossibly complicated that it DOES rely on hyper-optimisation to avoid >>> it running as slow as an interpreted scripting language. >> >> You really do like to complain about /everything/, don't you? This is >> not a "mark against C++" - it is a mark against numpties who think they >> can use a language but have no idea what the tools are for or how to use >> them. > > David is on holiday so perhaps someone else can pitch in. > > I said the way C++ is used is complicated - true or not? That applies to any language and depends on the user, doesn't at? > I said that it relies on optimisation - true or not? C++ was designed to use inline functions, they are part of the language that C++ compilers have always supported. They have gone on to be part of C and saved us from all those ghastly function like macro which some people still use. > I said that it otherwise runs as slow as an interpreted language - true > or not? Not. It is no different from C with small functions. > And if all those do apply, then it does appear to be a mark against C++ > - true or not? Not. That argument is like saying light bulbs are a poor design because they rely on electricity, or Netflix is slow over dial-up.... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-19 23:34 +0100 |
| Message-ID | <9Q8CC.663606$%a5.321093@fx21.am4> |
| In reply to | #129467 |
On 19/04/2018 21:07, Ian Collins wrote: > On 04/20/2018 07:05 AM, bartc wrote: >> I said the way C++ is used is complicated - true or not? > > That applies to any language and depends on the user, doesn't at? This is in the context of the the example application that slows down dramatically when not optimised. Apparently there were no other explanations. >> I said that it relies on optimisation - true or not? > C++ was designed to use inline functions, they are part of the language > that C++ compilers have always supported. They have gone on to be part > of C and saved us from all those ghastly function like macro which some > people still use. > >> I said that it otherwise runs as slow as an interpreted language - true >> or not? > > Not. It is no different from C with small functions. That example reportedly ran 1.5 magnitudes slower with optimisation turned off. That kind of difference IS what you see with interpreted code. What, are taking over from David now in glossing over the facts while he's away? Or has this stuff about that MASSIVE difference being due purely to C++ and its penchant for small functions just been made up for my benefit? >> And if all those do apply, then it does appear to be a mark against C++ >> - true or not? > > Not. That argument is like saying light bulbs are a poor design because > they rely on electricity, or Netflix is slow over dial-up.... I said I wasn't interested in arguing this (I don't care about C++) but you seem to be in denial. Is C++ with its many complex layers and all the other stuff that has been piled onto it, more demanding of its compiler or not? (For example, the difference between O0/O3 being greater than it is with C code.) If the answer is Yes, then that's the mark I'm talking about. What I suspect however, is that there are other reasons for those reported figures of 20-40, but this could not be admitted because that would reinforce my assertion that on real programs, optimisation plays a much smaller part. Since the speed of the resulting code is the only real difference between gcc and my compiler, it was important to pretend otherwise. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-19 16:05 -0700 |
| Message-ID | <lnsh7qkda9.fsf@kst-u.example.com> |
| In reply to | #129476 |
bartc <bc@freeuk.com> writes:
> On 19/04/2018 21:07, Ian Collins wrote:
>> On 04/20/2018 07:05 AM, bartc wrote:
>>> I said the way C++ is used is complicated - true or not?
>>
>> That applies to any language and depends on the user, doesn't at?
>
> This is in the context of the the example application that slows down
> dramatically when not optimised. Apparently there were no other
> explanations.
Let's restore some context to this discussion. The following text is
quoted from articles earlier in this thread.
David Brown:
For some real C code - yes, that is exactly what happens.
And the efficiency of the generated code matters little in
such cases. For other real C code, it is a different situation.
Scott Lurndal:
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)
bartc:
How much difference would it make if you left all that in place,
but switched off compiler optimisations?
Scott Lurndal:
It runs 20 to 40 times slower.
Then, several followups later, David Brown:
Good software design will involve a lot of functions - often
small ones. If Scott's code is C++ rather than C, that will
likely be even more true. Inlining is disabled in gcc at -O0,
even for functions marked "inline" (since the C/C++ keyword
"inline" does not force function inlining). This can easily
make a massive difference, especially as inlining opens up new
possibilities for other optimisations (constant propagation,
strength reduction, dead code elimination, etc.). gcc does a
lot of that kind of thing.
Scott has not posted in this thread since then.
So this entire argument about C++ (which, I'll point out, is not
the topic of this newsgroup) was based on David Brown's speculation
that Scott's application *might* be C++.
The fact that an application runs 20 to 40 times slower without
optimization is somewhat interesting. I see no reason to doubt
Scott's word on the matter, or to speculate further on the reasons
behind it without more information from Scott (who is, of course,
under no obligation to provide it).
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-20 00:18 +0100 |
| Message-ID | <kt9CC.971677$BA6.389507@fx29.am4> |
| In reply to | #129477 |
On 20/04/2018 00:05, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > Let's restore some context to this discussion. The following text is > quoted from articles earlier in this thread. <snip> > Scott has not posted in this thread since then. > > So this entire argument about C++ (which, I'll point out, is not > the topic of this newsgroup) was based on David Brown's speculation > that Scott's application *might* be C++. > > The fact that an application runs 20 to 40 times slower without > optimization is somewhat interesting. I see no reason to doubt > Scott's word on the matter, or to speculate further on the reasons > behind it without more information from Scott (who is, of course, > under no obligation to provide it). That's a good summary, and in those circumstances I remain sceptical about those figures. (I'm sure those guys didn't deliberately use unsubstantiated facts to try and make optimisation appear more vital than it really is, for C anyway.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-04-25 23:12 +0000 |
| Message-ID | <UX7EC.22948$mD.4497@fx31.iad> |
| In reply to | #129477 |
Keith Thompson <kst-u@mib.org> writes: >bartc <bc@freeuk.com> writes: >> On 19/04/2018 21:07, Ian Collins wrote: >>> On 04/20/2018 07:05 AM, bartc wrote: >>>> I said the way C++ is used is complicated - true or not? >>> >>> That applies to any language and depends on the user, doesn't at? >> >> This is in the context of the the example application that slows down >> dramatically when not optimised. Apparently there were no other >> explanations. > >Let's restore some context to this discussion. The following text is >quoted from articles earlier in this thread. > >David Brown: > For some real C code - yes, that is exactly what happens. > And the efficiency of the generated code matters little in > such cases. For other real C code, it is a different situation. > >Scott Lurndal: > 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) > >bartc: > How much difference would it make if you left all that in place, > but switched off compiler optimisations? > >Scott Lurndal: > It runs 20 to 40 times slower. > >Then, several followups later, David Brown: > Good software design will involve a lot of functions - often > small ones. If Scott's code is C++ rather than C, that will > likely be even more true. Inlining is disabled in gcc at -O0, > even for functions marked "inline" (since the C/C++ keyword > "inline" does not force function inlining). This can easily > make a massive difference, especially as inlining opens up new > possibilities for other optimisations (constant propagation, > strength reduction, dead code elimination, etc.). gcc does a > lot of that kind of thing. > Nice summary Keith. >Scott has not posted in this thread since then. Indeed. I will point out that I also posted at one point that the 40x end of the slowdown was a result of heavily overcommitting the host processors with the unoptimized binaries. A bit extreme, I will grant. > >So this entire argument about C++ (which, I'll point out, is not >the topic of this newsgroup) was based on David Brown's speculation >that Scott's application *might* be C++. David was, as usual, spot on. Tens of thousands of inline functions in the application, many of them quite small.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-20 16:15 +1200 |
| Message-ID | <fjt7q5Fcse1U2@mid.individual.net> |
| In reply to | #129476 |
On 04/20/2018 10:34 AM, bartc wrote: > On 19/04/2018 21:07, Ian Collins wrote: >> On 04/20/2018 07:05 AM, bartc wrote: > >>> I said the way C++ is used is complicated - true or not? >> >> That applies to any language and depends on the user, doesn't at? > > This is in the context of the the example application that slows down > dramatically when not optimised. Apparently there were no other > explanations. There were several, including a couple from me. Scott says their application is tuned to the hardware, one tool being optimisations. If you take those away, you detune the whole thing. There are a whole heap of hardware related optimisations in most decent compilers. These compilers often support some form of profile based optimisation to help developers tune their application. While my stuff isn't as performance critical as Scott's, I have used profile based optimisation to to get the best out of similar but subtly different hardware. You say you haven't gone down the optimisation route with your compiler, if you do I'm sure you will find building a good optimising compiler is many times more work than building a simple C to ASM translator. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-20 11:39 +0100 |
| Message-ID | <7rjCC.659979$rA1.190049@fx34.am4> |
| In reply to | #129484 |
On 20/04/2018 05:15, Ian Collins wrote: > You say you haven't gone down the optimisation route with your compiler, (I did try once with the non-C compiler. And it worked well - for benchmarks. For real programs it didn't make enough difference to justify the extra complexity.) > if you do I'm sure you will find building a good optimising compiler is > many times more work than building a simple C to ASM translator. Yes, because it's so open-ended - you can spend years on it and never finish the task. And the somewhat unstructured (and also rather open-ended) nature of C makes it harder. (My own non-C compiler is mainly used for two types of programs: an interpreter where I found that a simple HLL->ASM translator combined with an ASM layer was /twice as fast/ as running gcc-O3 on 100% C. And compilers and such which are already written to be very fast. While gcc-O3 on the generated C might give a welcome boost (a 4Mlps assembler instead of a mere 3Mlps), typical run-times are so small that you can't tell the difference. I agree it might be more important for a C compiler that needs to run arbitrary kinds of programs. I am currently building a new kind of (whole project) compiler, not for C, which might more easily make possible some kinds optimisations. But it's never going to match gcc-O3 or equivalent of other compilers.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-20 23:46 +1200 |
| Message-ID | <fju28tFlnnqU1@mid.individual.net> |
| In reply to | #129495 |
On 04/20/2018 10:39 PM, bartc wrote: > On 20/04/2018 05:15, Ian Collins wrote: > >> You say you haven't gone down the optimisation route with your compiler, > > (I did try once with the non-C compiler. And it worked well - for > benchmarks. For real programs it didn't make enough difference to > justify the extra complexity.) > >> if you do I'm sure you will find building a good optimising compiler is >> many times more work than building a simple C to ASM translator. > > Yes, because it's so open-ended - you can spend years on it and never > finish the task. And the somewhat unstructured (and also rather > open-ended) nature of C makes it harder. The nature of C has very little to do with the open-ended nature of the task, it is well understood by compiler writers and rarely changes. The real complexity lies in the ever evolving nature of processors. When I was building applications for Solaris I could never use the highest level of optimisation because it implied arch=native so highly optimised x86 code built on latest generation hardware would not run on older (or AMD) machines. This is also why Intel's compiler will always give the best performance on their hardware and, when it was my main tool, Sun's compiler always had the edge on SPARC. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-20 05:04 -0700 |
| Message-ID | <dc53ed9f-b183-4076-b5e7-ba9aacb575e4@googlegroups.com> |
| In reply to | #129503 |
On Friday, April 20, 2018 at 4:46:46 AM UTC-7, Ian Collins wrote: > On 04/20/2018 10:39 PM, bartc wrote: > > On 20/04/2018 05:15, Ian Collins wrote: > > > >> You say you haven't gone down the optimisation route with your compiler, > > > > (I did try once with the non-C compiler. And it worked well - for > > benchmarks. For real programs it didn't make enough difference to > > justify the extra complexity.) > > > >> if you do I'm sure you will find building a good optimising compiler is > >> many times more work than building a simple C to ASM translator. > > > > Yes, because it's so open-ended - you can spend years on it and never > > finish the task. And the somewhat unstructured (and also rather > > open-ended) nature of C makes it harder. > > The nature of C has very little to do with the open-ended nature of the > task, it is well understood by compiler writers and rarely changes. > > The real complexity lies in the ever evolving nature of processors. > When I was building applications for Solaris I could never use the > highest level of optimisation because it implied arch=native so highly > optimised x86 code built on latest generation hardware would not run on > older (or AMD) machines. This is also why Intel's compiler will always > give the best performance on their hardware and, when it was my main > tool, Sun's compiler always had the edge on SPARC. > > -- > Ian. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <328ae2c8-12e1-4830-b455-53187a4bc309@googlegroups.com>, Steve Carroll wrote: > > Sandman: > > <http://usenet.sandman.net/misc/snit_flood> It doesn't show what > > interval the script is run at, but how he has used it, at least in > > the beginning. I stopped logging it this way back in may :) > > From what I've personally looked at, it looks like it's all over the > map. Yes, with obvious scripted sessions. Not saying some of it isn't manual. > > Sandman: > > Maybe I'll update it :) > > What would it take to do that? For "later" to occur! <http://usenet.sandman.net/misc/postingtimes/Snit/Flooding> That's a running tally of Snit's non-sock posts and his flooding during the last month. It'll update automatically and always show the last two months. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJZyKjaAAoJECFEwfBaA+jR4QEIAIWE3GfOGnnxynLfUhRnWv+l OkvAvQ8GofGI1JjIOn7NnlyfGRV/JPiIzJmzoCrdV6uY9E9qaYOXScF4M5Vas4bv 2WqBlNIh7se9g6Zkj330L12RkuZckS5l0nJ++OTbmztOzLtAlrWKHADTiJ9u8JnR BCjcAhMrjQ0Jwut34hJr57pzj7p88oYCPP46IcrEMbWnd03n43BGUVLGr9i9pYU+ 7F6867hOzaFJ4DdRE52zv15yIYVUIHx7HFNNtV7ZfPRBRQQuyA403S8PM1RC/nQ/ RKau+ma21bzltpxlqTO+XAXMMLLZiGXy8hbv4Ib/tPlc5cKI3P6UDZ4exbbCmnE= =1Dqa -----END PGP SIGNATURE----- -- What Every Entrepreneur Must Know http://www.5z8.info/horse-slaughter_w8c4en_launchexe https://youtu.be/iztSc_msHuo http://www.5z8.info/--INITIATE-CREDIT-CARD-XFER--_k7s1jt_inject_worm Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-20 13:27 +0100 |
| Message-ID | <C0lCC.917543$yk2.327169@fx40.am4> |
| In reply to | #129503 |
On 20/04/2018 12:46, Ian Collins wrote:
> On 04/20/2018 10:39 PM, bartc wrote:
>> On 20/04/2018 05:15, Ian Collins wrote:
>>
>>> You say you haven't gone down the optimisation route with your compiler,
>>
>> (I did try once with the non-C compiler. And it worked well - for
>> benchmarks. For real programs it didn't make enough difference to
>> justify the extra complexity.)
>>
>>> if you do I'm sure you will find building a good optimising compiler is
>>> many times more work than building a simple C to ASM translator.
>>
>> Yes, because it's so open-ended - you can spend years on it and never
>> finish the task. And the somewhat unstructured (and also rather
>> open-ended) nature of C makes it harder.
>
> The nature of C has very little to do with the open-ended nature of the
> task, it is well understood by compiler writers and rarely changes.
It makes it harder. It's like trying to apply optimisation to an ASM
program; it doesn't contain enough obvious information as to what the
intentions are; they have to be deduced from analysing the code.
An example in C might be this:
for (i=0; i<N; ++i) {<code that doesn't read, write or modify i>}
An optimiser needs to infer that this is a repeat-N-times loop, from the
infinite number of possibilities within C's 'flexible' for(...)
construct, and from analysing the loop body, taking account of goto
into, out of, and back into the body. And if 'i' is a global, by
analysing the functions called from within the execution path during
each iteration.
Or the language may have a statement like this:
to N do ... end
which requires no analysis, inference or deductions at all.
It's much easier.
> The real complexity lies in the ever evolving nature of processors. When
> I was building applications for Solaris I could never use the highest
> level of optimisation because it implied arch=native so highly optimised
> x86 code built on latest generation hardware would not run on older (or
> AMD) machines. This is also why Intel's compiler will always give the
> best performance on their hardware and, when it was my main tool, Sun's
> compiler always had the edge on SPARC.
That's another kind of optimisation. I'm more familiar with that which
is independent of the exact processor type, which works on a more
generic model.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-20 06:06 -0700 |
| Message-ID | <3d456559-2967-4081-a0f1-f3af5658adee@googlegroups.com> |
| In reply to | #129505 |
On Friday, April 20, 2018 at 5:27:24 AM UTC-7, Bart wrote:
> On 20/04/2018 12:46, Ian Collins wrote:
> > On 04/20/2018 10:39 PM, bartc wrote:
> >> On 20/04/2018 05:15, Ian Collins wrote:
> >>
> >>> You say you haven't gone down the optimisation route with your compiler,
> >>
> >> (I did try once with the non-C compiler. And it worked well - for
> >> benchmarks. For real programs it didn't make enough difference to
> >> justify the extra complexity.)
> >>
> >>> if you do I'm sure you will find building a good optimising compiler is
> >>> many times more work than building a simple C to ASM translator.
> >>
> >> Yes, because it's so open-ended - you can spend years on it and never
> >> finish the task. And the somewhat unstructured (and also rather
> >> open-ended) nature of C makes it harder.
> >
> > The nature of C has very little to do with the open-ended nature of the
> > task, it is well understood by compiler writers and rarely changes.
>
> It makes it harder. It's like trying to apply optimisation to an ASM
> program; it doesn't contain enough obvious information as to what the
> intentions are; they have to be deduced from analysing the code.
>
> An example in C might be this:
>
> for (i=0; i<N; ++i) {<code that doesn't read, write or modify i>}
>
> An optimiser needs to infer that this is a repeat-N-times loop, from the
> infinite number of possibilities within C's 'flexible' for(...)
> construct, and from analysing the loop body, taking account of goto
> into, out of, and back into the body. And if 'i' is a global, by
> analysing the functions called from within the execution path during
> each iteration.
>
> Or the language may have a statement like this:
>
> to N do ... end
>
> which requires no analysis, inference or deductions at all.
>
> It's much easier.
>
> > The real complexity lies in the ever evolving nature of processors. When
> > I was building applications for Solaris I could never use the highest
> > level of optimisation because it implied arch=native so highly optimised
> > x86 code built on latest generation hardware would not run on older (or
> > AMD) machines. This is also why Intel's compiler will always give the
> > best performance on their hardware and, when it was my main tool, Sun's
> > compiler always had the edge on SPARC.
>
> That's another kind of optimisation. I'm more familiar with that which
> is independent of the exact processor type, which works on a more
> generic model.
>
> --
> bartc
My uptime is almost forty-three weeks and I will now be called a liar by Aragorn.
Aragorn should know everyone knows he is just lying. Having to suffer the use of Mint would just confuse the general user. Are you being idiotic on purpose? How is Blender on Linux doing anything above the lowest common denominator?
Well... like I said, I have a number of reasons for believing the flooder is Aragorn, who is a self professed Swift programmer but I don't know if it could be used to flood so much. How is wasting a universal consciousness tied to flatlining brain waves in any way going to lead to meaningful newsgroup conversation?
--
Eight things to never feed your dog
https://youtu.be/D_so1dvjeyI
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-20 13:05 -0700 |
| Message-ID | <060f47ce-0c12-442f-a728-ac28706f32ef@googlegroups.com> |
| In reply to | #129495 |
On Friday, April 20, 2018 at 5:39:08 AM UTC-5, Bart wrote: > > if you do I'm sure you will find building a good optimising compiler is > > many times more work than building a simple C to ASM translator. > > Yes, because it's so open-ended - you can spend years on it and never > finish the task. And the somewhat unstructured (and also rather > open-ended) nature of C makes it harder. Starting with a "dumb translator", some rather straightforward optimizations will produce dramatic performance improvements. Even a single-pass compiler which randomly selects registers for recycling could benefit be keeping track of what values happen to be held in registers, and skip reloading anything whose value is already in a register, so long as it flushes the register cache of any lvalue of a type which is used to derive another lvalue. On a machine with a decent register set like the ARM, such an approach might provide 25% of the performance benefits of a really good optimizing compiler, but at a tiny fraction of the cost.
[toc] | [prev] | [next] | [standalone]
Page 4 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