Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86469 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2022-09-21 14:04 -0500 |
| Last post | 2022-09-26 02:08 -0400 |
| Articles | 20 on this page of 109 — 28 participants |
Back to article view | Back to comp.lang.c++
“Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-21 14:04 -0500
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-21 12:28 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:16 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 09:45 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:07 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:42 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 15:24 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:00 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be Muttley@dastardlyhq.com - 2022-09-26 16:11 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-09-26 09:22 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 09:41 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:46 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 16:15 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 20:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 20:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 22:56 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-22 23:15 +0100
g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 13:44 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Bart <bc@freeuk.com> - 2022-09-23 13:53 +0100
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:31 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-23 15:53 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] Ralf Goertz <me@myprovider.invalid> - 2022-09-23 16:21 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] David Brown <david.brown@hesbynett.no> - 2022-09-24 17:05 +0200
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] red floyd <no.spam.here@its.invalid> - 2022-09-24 12:33 -0700
Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Muttley@dastardlyhq.com - 2022-09-25 08:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 00:08 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-23 12:13 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 10:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-09-23 03:14 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:57 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-02 13:53 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-07 16:00 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Michael S <already5chosen@yahoo.com> - 2022-10-08 10:57 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-09 08:33 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:58 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:01 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:03 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? red floyd <no.spam.here@its.invalid> - 2022-09-23 14:43 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 11:15 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-23 12:35 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-23 12:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:09 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 13:25 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:13 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-26 10:44 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2022-09-27 09:56 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-27 10:50 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 01:57 -0400
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-09-22 14:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-23 03:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-23 07:50 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-23 13:37 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:19 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-26 13:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 14:31 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bart <bc@freeuk.com> - 2022-09-26 16:05 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 06:36 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:21 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Juha Nieminen <nospam@thanks.invalid> - 2022-09-27 13:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-27 16:53 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 10:32 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 18:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 01:30 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 08:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 10:43 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-09-28 13:15 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 23:38 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:46 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-29 17:58 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-30 09:17 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 16:39 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-01 12:47 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-30 17:20 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-30 20:59 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:31 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 13:38 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-02 13:00 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-02 16:20 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-10-02 22:05 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-10-03 11:58 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 07:24 -0700
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 09:40 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 07:56 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 15:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:21 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 16:17 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 16:56 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Bo Persson <bo@bo-persson.se> - 2022-09-28 20:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? doctor@doctor.nl2k.ab.ca (The Doctor) - 2022-09-28 21:45 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-29 11:50 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Richard Damon <Richard@Damon-Family.org> - 2022-09-28 19:33 -0400
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-26 09:04 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 11:27 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 08:11 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:10 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? rbowman <bowman@montana.com> - 2022-09-27 17:30 -0600
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:26 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-28 11:00 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-28 13:33 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Manfred <noname@add.invalid> - 2022-09-25 19:31 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-26 04:53 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-10-02 12:59 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Opus <ifonly@youknew.org> - 2022-09-23 18:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2022-09-26 02:08 -0400
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-23 15:53 +0200 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgkdp0$2hm22$1@dont-email.me> |
| In reply to | #86528 |
On 23/09/2022 13:44, Ralf Goertz wrote: > Am Thu, 22 Sep 2022 23:15:44 +0100 > schrieb Bart <bc@freeuk.com>: > >> I've done a bit more than you then in porting a 70-line benchmark to >> it: >> >> https://github.com/sal55/langs/blob/master/fannkuch.txt > > I just implemented the benchmark myself (it should really be called > „Pfannkuchen“) quite straightforwardly (see below). There is a 1995 > article about the the benchmark where the authors listed execution times > of (among others) C-versions compiled with "gcc -O2" and just "gcc". The > latter needed almost 4 times as long as the former. I wondered how "-O6" > would compare. So I compiled my program with that (using n=12 instead of > 10 as in the article). To my big surprise "-O6": > Anything higher than -O3 is the same as -O3 in gcc. > ~/c> time ./fannkuch > fannkuch(12)=65 equals 65 from oeis > > real 0m36.325s > user 0m36.242s > sys 0m0.045s > > was significantly slower than "-O2): > > ~/c> time ./fannkuch > fannkuch(12)=65 equals 65 from oeis > > real 0m30.976s > user 0m30.913s > sys 0m0.021s > > What's the reason for that? > gcc -O3 uses a lot effort trying to get the last few fractions of a percent out of the code - it is rarely used, as it is rarely worth the effort. And sometimes it backfires. Typically, this is caused by enthusiastic loop unrolling or inlining that gives code that is /sometimes/ faster, but also sometimes slower due to more misses for instruction caches, return address buffers, branch prediction tables, etc. Trying to squeeze the last drops of speed out of a compiler is an art - you should expect to work hard at benchmarking, profiling, and testing different compiler options in different parts of the code. Compilers are not omniscient, and don't know everything about your code and how it is used, your processor, or what else might be running on the same system. So generally, gcc -O2 is the normal choice until you are ready to work hard. There are, however, a few flags that can make a very significant difference, depending on source code. "-march" tells the compiler details of the processor you are using, rather than picking the lowest common denominator for the processor family. "-march=native" tells it that the target is the same as the compiler is running on. The "-march" flag gives the compiler access to more SIMD and advanced instructions, as well as a more accurate model for scheduling, pipelining, and other processor-specific fine tuning options. "-fast-math" enables a lot of floating point optimisations that are not allowed by strict IEEE rules, but are often fine for real-world floating point code. If your source has a lot of floating point calculations and you are okay with the kinds of re-arrangements enabled by this flag, it can speed up the floating point code significantly.
[toc] | [prev] | [next] | [standalone]
| From | Ralf Goertz <me@myprovider.invalid> |
|---|---|
| Date | 2022-09-23 16:21 +0200 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgkfdl$2gt74$2@dont-email.me> |
| In reply to | #86533 |
Am Fri, 23 Sep 2022 15:53:36 +0200 schrieb David Brown <david.brown@hesbynett.no>: > On 23/09/2022 13:44, Ralf Goertz wrote: > > Am Thu, 22 Sep 2022 23:15:44 +0100 > > schrieb Bart <bc@freeuk.com>: > > > >> I've done a bit more than you then in porting a 70-line benchmark > >> to it: > >> > >> https://github.com/sal55/langs/blob/master/fannkuch.txt > > > > I just implemented the benchmark myself (it should really be called > > „Pfannkuchen“) quite straightforwardly (see below). There is a 1995 > > article about the the benchmark where the authors listed execution > > times of (among others) C-versions compiled with "gcc -O2" and just > > "gcc". The latter needed almost 4 times as long as the former. I > > wondered how "-O6" would compare. So I compiled my program with > > that (using n=12 instead of 10 as in the article). To my big > > surprise "-O6": > > Anything higher than -O3 is the same as -O3 in gcc. Oh okay. I don't know where I got the idea that 6 was the maximum. > > ~/c> time ./fannkuch > > fannkuch(12)=65 equals 65 from oeis > > > > real 0m36.325s > > user 0m36.242s > > sys 0m0.045s > > > > was significantly slower than "-O2): > > > > ~/c> time ./fannkuch > > fannkuch(12)=65 equals 65 from oeis > > > > real 0m30.976s > > user 0m30.913s > > sys 0m0.021s > > > > What's the reason for that? > > > > gcc -O3 uses a lot effort trying to get the last few fractions of a > percent out of the code - it is rarely used, as it is rarely worth the > effort. And sometimes it backfires. As it obviously does with my program. Then again it still surprises me. It's 17% slower! I guess the 99% consists of swapping elements in a std::array<int, 12>. At least the part I have written but also next_permutation() if I remember the algorithm in TAOCP correctly. > Typically, this is caused by enthusiastic loop unrolling or inlining > that gives code that is /sometimes/ faster, but also sometimes slower > due to more misses for instruction caches, return address buffers, > branch prediction tables, etc. Trying to squeeze the last drops of > speed out of a compiler is an art - you should expect to work hard at > benchmarking, profiling, and testing different compiler options in > different parts of the code. Compilers are not omniscient, and don't > know everything about your code and how it is used, your processor, or > what else might be running on the same system. > So generally, gcc -O2 is the normal choice until you are ready to work > hard. > > There are, however, a few flags that can make a very significant > difference, depending on source code. > > "-march" tells the compiler details of the processor you are using, > rather than picking the lowest common denominator for the processor > family. "-march=native" tells it that the target is the same as the > compiler is running on. The "-march" flag gives the compiler access > to more SIMD and advanced instructions, as well as a more accurate > model for scheduling, pipelining, and other processor-specific fine > tuning options. -march=native makes "-O2" a little bit slower and "-O3" a little bit faster but the former is still 11% faster. Thanks for your explanations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-24 17:05 +0200 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgn6ba$30itj$1@dont-email.me> |
| In reply to | #86535 |
On 23/09/2022 16:21, Ralf Goertz wrote: > Am Fri, 23 Sep 2022 15:53:36 +0200 > schrieb David Brown <david.brown@hesbynett.no>: > >> On 23/09/2022 13:44, Ralf Goertz wrote: >>> Am Thu, 22 Sep 2022 23:15:44 +0100 >>> schrieb Bart <bc@freeuk.com>: >>> >>>> I've done a bit more than you then in porting a 70-line benchmark >>>> to it: >>>> >>>> https://github.com/sal55/langs/blob/master/fannkuch.txt >>> >>> I just implemented the benchmark myself (it should really be called >>> „Pfannkuchen“) quite straightforwardly (see below). There is a 1995 >>> article about the the benchmark where the authors listed execution >>> times of (among others) C-versions compiled with "gcc -O2" and just >>> "gcc". The latter needed almost 4 times as long as the former. I >>> wondered how "-O6" would compare. So I compiled my program with >>> that (using n=12 instead of 10 as in the article). To my big >>> surprise "-O6": >> >> Anything higher than -O3 is the same as -O3 in gcc. > > Oh okay. I don't know where I got the idea that 6 was the maximum. I've seen other compilers that go up to -O6. gcc has taken the path of having explicit control flags for different optimisations, for those that want more control, rather than having many levels. After all, as you have seen, a higher numerical level does not always relate well to higher speeds. > >>> ~/c> time ./fannkuch >>> fannkuch(12)=65 equals 65 from oeis >>> >>> real 0m36.325s >>> user 0m36.242s >>> sys 0m0.045s >>> >>> was significantly slower than "-O2): >>> >>> ~/c> time ./fannkuch >>> fannkuch(12)=65 equals 65 from oeis >>> >>> real 0m30.976s >>> user 0m30.913s >>> sys 0m0.021s >>> >>> What's the reason for that? >>> >> >> gcc -O3 uses a lot effort trying to get the last few fractions of a >> percent out of the code - it is rarely used, as it is rarely worth the >> effort. And sometimes it backfires. > > As it obviously does with my program. Then again it still surprises me. > It's 17% slower! I guess the 99% consists of swapping elements in a > std::array<int, 12>. At least the part I have written but also > next_permutation() if I remember the algorithm in TAOCP correctly. > >> Typically, this is caused by enthusiastic loop unrolling or inlining >> that gives code that is /sometimes/ faster, but also sometimes slower >> due to more misses for instruction caches, return address buffers, >> branch prediction tables, etc. Trying to squeeze the last drops of >> speed out of a compiler is an art - you should expect to work hard at >> benchmarking, profiling, and testing different compiler options in >> different parts of the code. Compilers are not omniscient, and don't >> know everything about your code and how it is used, your processor, or >> what else might be running on the same system. > >> So generally, gcc -O2 is the normal choice until you are ready to work >> hard. >> >> There are, however, a few flags that can make a very significant >> difference, depending on source code. >> >> "-march" tells the compiler details of the processor you are using, >> rather than picking the lowest common denominator for the processor >> family. "-march=native" tells it that the target is the same as the >> compiler is running on. The "-march" flag gives the compiler access >> to more SIMD and advanced instructions, as well as a more accurate >> model for scheduling, pipelining, and other processor-specific fine >> tuning options. > > -march=native makes "-O2" a little bit slower and "-O3" a little bit > faster but the former is still 11% faster. > Interesting. "-march=native" usually makes things faster (or smaller) - rarely slower. Maybe your processor is newer than your compiler, so it doesn't really know about the details. Or maybe you were just unlucky. If you see particular slowdown effects and poor code, and it is the same even with relatively current gcc versions, you can always report it. Missed or poor optimisation issues are not often the highest prioritised issues for gcc development (unlike incorrect code bugs), but the developers like to have them in the bugzilla list. It makes it easier to see when an issue is affecting many people. (If you want to look at the generated code with different gcc versions and different compiler options, <https://godbolt.org> is your website of choice.) > Thanks for your explanations. > No problem.
[toc] | [prev] | [next] | [standalone]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-09-24 12:33 -0700 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgnm1f$321vn$1@redfloyd.dont-email.me> |
| In reply to | #86559 |
On 9/24/2022 8:05 AM, David Brown wrote: > > I've seen other compilers that go up to -O6. gcc has taken the path of > having explicit control flags for different optimisations, for those > that want more control, rather than having many levels. After all, as > you have seen, a higher numerical level does not always relate well to > higher speeds. > I understand that the Spinal Tap compiler, written by Nigel Tufnel, goes up to 11.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-25 08:45 +0000 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO |
| Message-ID | <tgp4ej$oll$1@gioia.aioe.org> |
| In reply to | #86571 |
On Sat, 24 Sep 2022 12:33:03 -0700 red floyd <no.spam.here@its.invalid> wrote: >On 9/24/2022 8:05 AM, David Brown wrote: > >> >> I've seen other compilers that go up to -O6. gcc has taken the path of >> having explicit control flags for different optimisations, for those >> that want more control, rather than having many levels. After all, as >> you have seen, a higher numerical level does not always relate well to >> higher speeds. >> > >I understand that the Spinal Tap compiler, written by Nigel Tufnel, goes >up to 11. +1 Though I doubt many on here will get it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-23 00:08 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87czbnxb14.fsf@bsb.me.uk> |
| In reply to | #86507 |
David Brown <david.brown@hesbynett.no> writes: > On 22/09/2022 21:15, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: <cut> >>> Whataboutism is not an acceptable defence, >> >> Sure. I was not defending Rust's choice. >> >>> nor is it double standards >>> to use a different language that is worse. >> >> Nor was I suggesting the double standard came from making such a >> multi-faceted choice as which language to use. I was remarking on >> never having seen this objection raised about C or C++. > > I interpreted your comment as a more direct response to Juha - > accusing him personally of double standards. But it looks like I was > reading too much into a general comment. Kind of. I was not specifically accusing Juha but saying that his remarks were part of a larger double standard. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-23 07:45 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgjo7e$1ivg$1@gioia.aioe.org> |
| In reply to | #86507 |
In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: > It's very much a subjective thing. Unless someone can show real, > relevant statistical evidence that one style of keyword length is better > than the other in terms of fewer mistakes in code, then it will always > be a matter of personal preference and familiarity. It's not so much about making mistakes, but about readability and understandability of the code (from the perspective of others than the author). In general, programmers are blind to the illegibility of their own code. After all, they are thinking what to write, and writing it, so rather obviously they understand perfectly what the code is doing. However, someone else reading the code doesn't know in advance what the code is doing and thus has to decipher that from reading the source code. The problem with many programmers is that they get some kind of fuzzy feeling when they create code that does a lot with as little code as possible. Some programming language (such as Haskell) advocates even sometimes boast how their pet language can do so much with a one-liner! Things that require a dozen lines in other languages can be done with a one-liner in their language! As if brevity were somehow a desirable goal. Of course the other extreme isn't good either: Excessive verbosity can also make the code less readable and understandable. In general, the more condensed or the more sparse the code, the less readable it is. The perfect middle should be the goal. This is where even the length of keywords steps in: The shorter the keywords, the more condensed the code becomes. The more conceptual units are packed into a small space, the more effort it requires the reader to dig out the meaning. This isn't exactly helped if the code does not consist of full English words, but some obscure abbreviations. Imagine if this post consisted of nothing but very short abbreviations of every word. It would become illegible.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2022-09-23 12:13 +0300 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgjtci$2g8qe$1@dont-email.me> |
| In reply to | #86518 |
23.09.2022 10:45 Juha Nieminen kirjutas: > > Imagine if this post consisted of nothing but very short abbreviations > of every word. It would become illegible. In general, the length of the word ought to be reversely correlated with the frequency of its use. Imagine what would English look like if the words "is", "it", "me", "you", etc. were all 12 letter long.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-23 10:01 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgk06a$vit$1@gioia.aioe.org> |
| In reply to | #86520 |
In comp.lang.c++ Paavo Helde <eesnimi@osa.pri.ee> wrote: > 23.09.2022 10:45 Juha Nieminen kirjutas: >> >> Imagine if this post consisted of nothing but very short abbreviations >> of every word. It would become illegible. > > In general, the length of the word ought to be reversely correlated with > the frequency of its use. Imagine what would English look like if the > words "is", "it", "me", "you", etc. were all 12 letter long. I think it's more important that names are entire words, not contracted (with very few exceptions). Secondly, the names should express as clearly as possible what the thing is representing. Using an entire English word is not good enough if it still doesn't express clearly what the thing is representing. In general one shouldn't be afraid of creating even quite long names that express clearly what the thing is. This especially if you can't give a rational argument why the shorter version has some concrete benefit from it (other than "it makes code lines shorter"). For example, I think it's quite hard to argue why "ret" is a better variable name than "returnValue" (or "return_value", depending on your coding style/guideline). If you can't give a rational argument for using the shorter name, just use the longer one. As another example: "convert(...)" might feel more convenient to write than something like "convert_to_utf8_from_utf16(...)", but you have to think about the code from the perspective of someone who is reading it and doesn't already know what it's doing. The latter may be significantly longer but it expresses infinitely more clearly what it's doing (even without seeing what the parameters are). Someone seeing just "convert(...)" in the code can't have any idea what it's doing.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-09-23 03:14 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <d08944a8-69d6-4e00-b6ee-7b4399449d4dn@googlegroups.com> |
| In reply to | #86521 |
On Friday, September 23, 2022 at 1:02:17 PM UTC+3, Juha Nieminen wrote: > > As another example: "convert(...)" might feel more convenient to > write than something like "convert_to_utf8_from_utf16(...)", but > you have to think about the code from the perspective of someone > who is reading it and doesn't already know what it's doing. > The latter may be significantly longer but it expresses infinitely > more clearly what it's doing (even without seeing what the parameters > are). Someone seeing just "convert(...)" in the code can't have any > idea what it's doing. It sounds like an argument against C++-style static polymorphism. Personally, I was against static polymorphism since I started to think independently about that sort of matters (which didn't happen until I was 35+). But I was not expecting to hear it from aficionado of "moderm C++". Maturing?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 08:01 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrm84$1k0d$1@gioia.aioe.org> |
| In reply to | #86522 |
Michael S <already5chosen@yahoo.com> wrote: >> As another example: "convert(...)" might feel more convenient to >> write than something like "convert_to_utf8_from_utf16(...)", but >> you have to think about the code from the perspective of someone >> who is reading it and doesn't already know what it's doing. >> The latter may be significantly longer but it expresses infinitely >> more clearly what it's doing (even without seeing what the parameters >> are). Someone seeing just "convert(...)" in the code can't have any >> idea what it's doing. > > It sounds like an argument against C++-style static polymorphism. Polymorphism has its uses (especially in templates), but also its abuses. Every good feature can be abused to make it a bad feature. And in situations where the shorter and more generic name is needed because of polymorphism (eg. in templates), my answer is almost always the same: "Implement convert_to_utf8_from_utf16() anyway, and make the equivalent convert() function call it. Use the former when you don't need the polymorphism, restrict the use of the latter only to those situations where it's actually needed."
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-10-02 12:57 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <868rlyj8xd.fsf@linuxsc.com> |
| In reply to | #86522 |
Michael S <already5chosen@yahoo.com> writes: > On Friday, September 23, 2022 at 1:02:17 PM UTC+3, Juha Nieminen wrote: > >> As another example: "convert(...)" might feel more convenient to >> write than something like "convert_to_utf8_from_utf16(...)", but >> you have to think about the code from the perspective of someone >> who is reading it and doesn't already know what it's doing. >> The latter may be significantly longer but it expresses infinitely >> more clearly what it's doing (even without seeing what the parameters >> are). Someone seeing just "convert(...)" in the code can't have any >> idea what it's doing. > > It sounds like an argument against C++-style static polymorphism. Do you mean ad hoc polymorphism, aka function overloading? Or do you mean something else, e.g., template-related?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-10-02 13:53 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <7e3900e7-358f-440b-9afe-57d42b095a03n@googlegroups.com> |
| In reply to | #86767 |
On Sunday, October 2, 2022 at 10:57:21 PM UTC+3, Tim Rentsch wrote: > Michael S <already...@yahoo.com> writes: > > > On Friday, September 23, 2022 at 1:02:17 PM UTC+3, Juha Nieminen wrote: > > > >> As another example: "convert(...)" might feel more convenient to > >> write than something like "convert_to_utf8_from_utf16(...)", but > >> you have to think about the code from the perspective of someone > >> who is reading it and doesn't already know what it's doing. > >> The latter may be significantly longer but it expresses infinitely > >> more clearly what it's doing (even without seeing what the parameters > >> are). Someone seeing just "convert(...)" in the code can't have any > >> idea what it's doing. > > > > It sounds like an argument against C++-style static polymorphism. > > Do you mean ad hoc polymorphism, aka function overloading? Or do > you mean something else, e.g., template-related? Mostly the former, but I'd rather do without the later as well. With very few exceptions. The only static polymorphism I wholeheartedly approve is polymorphism of arithmetic operators for built-in types.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-10-07 16:00 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <86lepri6hs.fsf@linuxsc.com> |
| In reply to | #86771 |
Michael S <already5chosen@yahoo.com> writes: > On Sunday, October 2, 2022 at 10:57:21 PM UTC+3, Tim Rentsch wrote: > >> Michael S <already...@yahoo.com> writes: >> >>> On Friday, September 23, 2022 at 1:02:17 PM UTC+3, Juha Nieminen wrote: >>> >>>> As another example: "convert(...)" might feel more convenient to >>>> write than something like "convert_to_utf8_from_utf16(...)", but >>>> you have to think about the code from the perspective of someone >>>> who is reading it and doesn't already know what it's doing. >>>> The latter may be significantly longer but it expresses infinitely >>>> more clearly what it's doing (even without seeing what the parameters >>>> are). Someone seeing just "convert(...)" in the code can't have any >>>> idea what it's doing. >>> >>> It sounds like an argument against C++-style static polymorphism. >> >> Do you mean ad hoc polymorphism, aka function overloading? Or do >> you mean something else, e.g., template-related? > > Mostly the former, but I'd rather do without the later as well. > With very few exceptions. > The only static polymorphism I wholeheartedly approve is > polymorphism of arithmetic operators for built-in types. Not that I disagree necessarily, but can you say what it is about function overloading you don't like? (For the time being let's ignore the larger topic of polymorphism with templates.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-10-08 10:57 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87a2ad16-df85-4b29-bdbd-0fa774c1a980n@googlegroups.com> |
| In reply to | #86833 |
On Saturday, October 8, 2022 at 2:01:05 AM UTC+3, Tim Rentsch wrote: > Michael S <already...@yahoo.com> writes: > > > On Sunday, October 2, 2022 at 10:57:21 PM UTC+3, Tim Rentsch wrote: > > > >> Michael S <already...@yahoo.com> writes: > >> > >>> On Friday, September 23, 2022 at 1:02:17 PM UTC+3, Juha Nieminen wrote: > >>> > >>>> As another example: "convert(...)" might feel more convenient to > >>>> write than something like "convert_to_utf8_from_utf16(...)", but > >>>> you have to think about the code from the perspective of someone > >>>> who is reading it and doesn't already know what it's doing. > >>>> The latter may be significantly longer but it expresses infinitely > >>>> more clearly what it's doing (even without seeing what the parameters > >>>> are). Someone seeing just "convert(...)" in the code can't have any > >>>> idea what it's doing. > >>> > >>> It sounds like an argument against C++-style static polymorphism. > >> > >> Do you mean ad hoc polymorphism, aka function overloading? Or do > >> you mean something else, e.g., template-related? > > > > Mostly the former, but I'd rather do without the later as well. > > With very few exceptions. > > The only static polymorphism I wholeheartedly approve is > > polymorphism of arithmetic operators for built-in types. > Not that I disagree necessarily, but can you say what it is about > function overloading you don't like? (For the time being let's > ignore the larger topic of polymorphism with templates.) Difficulty (for human reader) to find out which of name-sakes is called at given place. 15 years ago I would add another reason - this sort of polymorphism interacts badly with default function parameters, which I considered really useful. But today I am less sure that I still consider default function parameters particularly useful. [O.T.] I probably would consider them very useful in the language that has option for calling functions with designated (rather than positional) syntax of parameters passing. But neither C nor C++ are likely to ever provide such syntax. More so C++. For C, there exists slight hope. [/O.T.]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2022-10-09 08:33 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <86h70dhv0f.fsf@linuxsc.com> |
| In reply to | #86836 |
Michael S <already5chosen@yahoo.com> writes:
> On Saturday, October 8, 2022 at 2:01:05 AM UTC+3, Tim Rentsch wrote:
[...]
>> Not that I disagree necessarily, but can you say what it is about
>> function overloading you don't like? (For the time being let's
>> ignore the larger topic of polymorphism with templates.)
>
> Difficulty (for human reader) to find out which of name-sakes is
> called at given place. [...]
If the different overloadings all provide what is conceptually
the same operation, is it important to know which one is called?
For example, if we have
size_t read_bytes_into( void *out, size_t n, FILE *file );
size_t read_bytes_into( void *out, size_t n, int fd );
should a caller care which of the two functions is called? At
some level that seems to be a violation of the principle of
information hiding.
Of course, if the different overloadings do not all provide the
same conceptual operation, that is a problem in program design.
Is your objection only for cases in this second category?
(A problem with file descriptors being of 'int' type is that any
old arithmetic expression can be used, and the argument value may
not be a suitable file descriptor. But that problem is inherent
is using 'int' file descriptors, regardless of whether there is
function overloading.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-23 11:58 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87leqawe5z.fsf@bsb.me.uk> |
| In reply to | #86521 |
Juha Nieminen <nospam@thanks.invalid> writes: > As another example: "convert(...)" might feel more convenient to > write than something like "convert_to_utf8_from_utf16(...)", but > you have to think about the code from the perspective of someone > who is reading it and doesn't already know what it's doing. Is convert(...) a Rust function that converts strings or are you just giving an example of someone who chose a bad name in a particular program? (I know about std::convert in Rust, but that does not seem to be what you are talking about.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 08:01 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrm9h$1k0d$2@gioia.aioe.org> |
| In reply to | #86524 |
In comp.lang.c++ Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: > >> As another example: "convert(...)" might feel more convenient to >> write than something like "convert_to_utf8_from_utf16(...)", but >> you have to think about the code from the perspective of someone >> who is reading it and doesn't already know what it's doing. > > Is convert(...) a Rust function that converts strings or are you just > giving an example of someone who chose a bad name in a particular > program? (I know about std::convert in Rust, but that does not seem to > be what you are talking about.) It's just a hypothetical example (which is actually based on real production code).
[toc] | [prev] | [next] | [standalone]
| From | Blue-Maned_Hawk <bluemanedhawk@gmail.com> |
|---|---|
| Date | 2022-09-26 02:03 -0400 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgrfb9$3m0g3$2@dont-email.me> |
| In reply to | #86521 |
[Multipart message — attachments visible in raw view] — view raw
On 9/23/22 06:01, Juha Nieminen wrote: > [snip] > As another example: "convert(...)" might feel more convenient to > write than something like "convert_to_utf8_from_utf16(...)", but > you have to think about the code from the perspective of someone > who is reading it and doesn't already know what it's doing. > The latter may be significantly longer but it expresses infinitely > more clearly what it's doing (even without seeing what the parameters > are). Someone seeing just "convert(...)" in the code can't have any > idea what it's doing. While there's some truth here, i think it's important to remember that names don't exist in a vacuum. If, for example, you're working in the text-handling part of the codebase, and you see `convert32to16()`, you can pretty reasonably infer that that's talking about converting UTF-32 to UTF-16, and not something like small icon downscaling. (Also, to contribute to the rest of the discussion on short names in general…i personally just think they look prettier.) -- /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr. bluemanedhawk.github.io I think my Usenet provider stores their passwords in plain text. If i'm acting suspiciously, chances are that that backfired on them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-23 13:32 +0200 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgk5fn$2gvlo$1@dont-email.me> |
| In reply to | #86518 |
On 23/09/2022 09:45, Juha Nieminen wrote: > In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >> It's very much a subjective thing. Unless someone can show real, >> relevant statistical evidence that one style of keyword length is better >> than the other in terms of fewer mistakes in code, then it will always >> be a matter of personal preference and familiarity. > > It's not so much about making mistakes, but about readability and > understandability of the code (from the perspective of others than the > author). The prime purpose of making code readable is to avoid mistakes. Either you see the mistakes in your own code, or someone else sees them. (Readable code is also easier to use and re-use, and less effort to read - but I think the avoidance of errors is key in this discussion. Certainly it is foremost in the minds of almost everyone who promotes Rust - every pro-Rust article starts by saying how many memory-related errors in C could have been prevented by using Rust.) > > In general, programmers are blind to the illegibility of their own code. > After all, they are thinking what to write, and writing it, so rather > obviously they understand perfectly what the code is doing. However, > someone else reading the code doesn't know in advance what the code is > doing and thus has to decipher that from reading the source code. > > The problem with many programmers is that they get some kind of fuzzy > feeling when they create code that does a lot with as little code as > possible. Some programming language (such as Haskell) advocates even > sometimes boast how their pet language can do so much with a one-liner! > Things that require a dozen lines in other languages can be done with > a one-liner in their language! > > As if brevity were somehow a desirable goal. > > Of course the other extreme isn't good either: Excessive verbosity can > also make the code less readable and understandable. > > In general, the more condensed or the more sparse the code, the less > readable it is. The perfect middle should be the goal. > You should aim to be like a successful psychic - a happy medium :-) > This is where even the length of keywords steps in: The shorter the > keywords, the more condensed the code becomes. The more conceptual units > are packed into a small space, the more effort it requires the reader to > dig out the meaning. This isn't exactly helped if the code does not > consist of full English words, but some obscure abbreviations. > > Imagine if this post consisted of nothing but very short abbreviations > of every word. It would become illegible. I agree that there is a balance to be struck. But I think the "ideal" balance has a lot of variation, and thus is always going to be somewhat subjective.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web