Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167776 > 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 119 — 31 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??? Single Stage to Orbit <alex.buell@munted.eu> - 2022-09-22 09:42 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 11:16 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 16:48 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-22 23:12 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-23 01:40 +0100
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 deprecated??? The Real Non Homosexual <cdalten@gmail.com> - 2022-10-10 19:12 -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??? 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” Ben Collver <bencollver@tilde.pink> - 2022-09-22 15:19 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-22 15:23 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-22 12:13 -0700
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Andrea Biscuola <a@abiscuola.com> - 2022-09-22 20:32 +0200
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” scott@slp53.sl.home (Scott Lurndal) - 2022-09-22 19:01 +0000
Re: “Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated” Richard Harnden <richard.nospam@gmail.com> - 2022-09-22 17:36 +0100
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??? Paavo Helde <eesnimi@osa.pri.ee> - 2022-09-27 22:32 +0300
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-27 23:52 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 19:57 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 00:03 +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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:18 +0000
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-09-28 15:26 +0000
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-29 20:45 +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??? Michael S <already5chosen@yahoo.com> - 2022-10-01 11:40 -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??? 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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 14:17 +0000
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??? scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 18:48 +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??? Bart <bc@freeuk.com> - 2022-09-27 12:41 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-27 15:22 +0100
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 18:13 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? David Brown <david.brown@hesbynett.no> - 2022-09-27 16:50 +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??? David Brown <david.brown@hesbynett.no> - 2022-09-26 08:55 +0200
Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? BGB <cr88192@gmail.com> - 2022-10-01 16:07 -0500
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 | Ralf Goertz <me@myprovider.invalid> |
|---|---|
| Date | 2022-09-23 13:44 +0200 |
| Subject | g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgk67p$2gt74$1@dont-email.me> |
| In reply to | #167806 |
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":
~/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?
#include <iostream>
#include <algorithm>
#include <array>
#include <numeric>
//from oeis.org
int results[]={0, 0, 1, 2, 4, 7, 10, 16, 22, 30, 38, 51, 65, 80, 101,
113, 139, 159, 191, 221};
using namespace std; // I know…
const int n=12;
int flip(array<int, n> t) {
int res=0;
do {
++res;
int top=t[0];
reverse(t.begin(),t.begin()+top);
} while (t[0]!=1);
return res;
}
int main() {
array<int, n> a;
iota(a.begin(),a.end(),1);
if (n>1) swap(a[0],a[1]); // don't need the perms with 1 at the beginning
int m=0; //max
do {
int i=flip(a);
if (i>m) m=i;
} while (next_permutation(a.begin(),a.end()));
cout<<"fannkuch("<<n<<")="<<m<<" equals "<<results[n]<<" from oeis"<<endl;
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-23 13:53 +0100 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgka85$1fqh$1@gioia.aioe.org> |
| In reply to | #167824 |
On 23/09/2022 12: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": I didn't know it went up to -O6, I thought that -O3 was the highest level. My own tests shows -O3 was a bit slower than -O2, but -O4 and up were about the same as -O3. Apparently there's no upper limit to optimisation level, as -O1000000 also works (with the same result as -O3), as does -O1000000000000. So the real mystery is what the deal is with those silly optimisation numbers. > I just implemented the benchmark myself (it should really be called (Actually the reason for all those different (p)fannkuch versions was to use it as the basis of a bigger benchmark for comparing compilation speeds for large input files: https://github.com/sal55/langs/blob/master/Compilertest3.md)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-23 15:31 +0200 |
| Subject | Re: g++ with -O6 slower than with -O2 [was Re: "Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated"] |
| Message-ID | <tgkcfd$2hio7$1@dont-email.me> |
| In reply to | #167825 |
On 23/09/2022 14:53, Bart wrote: > On 23/09/2022 12: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": > > I didn't know it went up to -O6, I thought that -O3 was the highest level. > It is. But gcc (in common with many compilers) accepts higher numbers and treats it all as highest level. > My own tests shows -O3 was a bit slower than -O2, but -O4 and up were > about the same as -O3. > > Apparently there's no upper limit to optimisation level, as -O1000000 > also works (with the same result as -O3), as does -O1000000000000. > > So the real mystery is what the deal is with those silly optimisation > numbers. > At a guess, someone (long, long ago) thought it was a convenient compatibility with some other compiler that differentiated higher numbers - thus people could move from "some_other_compiler -O6" to "gcc -O6" without changing command line options. (Many command line options in gcc are compatible with other *nix style compilers, new and old.) > > I just implemented the benchmark myself (it should really be called > > (Actually the reason for all those different (p)fannkuch versions was to > use it as the basis of a bigger benchmark for comparing compilation > speeds for large input files: > > https://github.com/sal55/langs/blob/master/Compilertest3.md)
[toc] | [prev] | [next] | [standalone]
| 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 | #167824 |
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 | #167827 |
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 | #167828 |
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 | #167836 |
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 | #167840 |
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 | #167803 |
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 | #167803 |
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 | #167815 |
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 | #167817 |
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 | 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 | #167819 |
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 | #167821 |
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 | #167819 |
[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 | #167815 |
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]
| From | red floyd <no.spam.here@its.invalid> |
|---|---|
| Date | 2022-09-23 14:43 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgl99c$2mfba$1@redfloyd.dont-email.me> |
| In reply to | #167815 |
On 9/23/2022 12:45 AM, Juha Nieminen wrote: > > In general, the more condensed or the more sparse the code, the less > readable it is. The perfect middle should be the goal. Or, as Einstein once put it, "Things should be as simple as possible, but no simpler".
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-23 07:26 +0000 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <tgjn3l$14e6$1@gioia.aioe.org> |
| In reply to | #167797 |
In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: > Rust is supposed to be /better/ than C. It is supposed to look at how C > has evolved over the decades, and pick a better starting point. So > saying C is as bad, or worse, is not an excuse for poor design choices > in Rust. That's exactly what I meant. C is something like 45 years old, Rust is something like 10 years old, and supposed to be a more modern and better designed language taking advantage of 50+ years of experience on how a good programming language should be like. Answering the criticism "this 10yo language has this design problem" with "oh yeah? Well, this 45yo language also has the same problem!" makes no sense. Newer "better" language are not supposed to copy the mistakes of the past. It's supposed to fix/improve on them. I'm not saying that eg. C++ is significantly better. The "brevity-over-clarity" mentality can oftentimes be seen throughout the standard library. For example, there's literally no reason why it should be called 'shared_ptr' instead of 'shared_pointer'. I can't think of any advantage in shortening "pointer" like that. But not to be bested, Rust makes it better: 'Rc'. Because why not.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-23 11:15 +0100 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <87tu4ywg5t.fsf@bsb.me.uk> |
| In reply to | #167814 |
Juha Nieminen <nospam@thanks.invalid> writes: > In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote: >> Rust is supposed to be /better/ than C. It is supposed to look at how C >> has evolved over the decades, and pick a better starting point. So >> saying C is as bad, or worse, is not an excuse for poor design choices >> in Rust. > > That's exactly what I meant. C is something like 45 years old, Rust is > something like 10 years old, and supposed to be a more modern and better > designed language taking advantage of 50+ years of experience on how a > good programming language should be like. > > Answering the criticism "this 10yo language has this design problem" with > "oh yeah? Well, this 45yo language also has the same problem!" makes > no sense. Newer "better" language are not supposed to copy the mistakes > of the past. It's supposed to fix/improve on them. I took too much from the context. The context was Rust suggested as a replacement for C (any maybe C++, I don't recall) but your remarks seemed to all about thing things you thought bad about Rust that C also had. So in that context, all you seemed to be saying is that Rust is no worse than C. Maybe everyone, even the Rust champions, agree but they will then point to the things that /are/ better in Rust. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-23 12:35 -0700 |
| Subject | Re: ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? |
| Message-ID | <875yhdevec.fsf@nosuchdomain.example.com> |
| In reply to | #167814 |
Juha Nieminen <nospam@thanks.invalid> writes:
> In comp.lang.c++ David Brown <david.brown@hesbynett.no> wrote:
>> Rust is supposed to be /better/ than C. It is supposed to look at how C
>> has evolved over the decades, and pick a better starting point. So
>> saying C is as bad, or worse, is not an excuse for poor design choices
>> in Rust.
>
> That's exactly what I meant. C is something like 45 years old, Rust is
> something like 10 years old, and supposed to be a more modern and better
> designed language taking advantage of 50+ years of experience on how a
> good programming language should be like.
>
> Answering the criticism "this 10yo language has this design problem" with
> "oh yeah? Well, this 45yo language also has the same problem!" makes
> no sense. Newer "better" language are not supposed to copy the mistakes
> of the past. It's supposed to fix/improve on them.
>
> I'm not saying that eg. C++ is significantly better. The
> "brevity-over-clarity" mentality can oftentimes be seen throughout
> the standard library.
>
> For example, there's literally no reason why it should be called
> 'shared_ptr' instead of 'shared_pointer'. I can't think of any advantage
> in shortening "pointer" like that.
>
> But not to be bested, Rust makes it better: 'Rc'.
>
> Because why not.
"Rc" stands for "Reference Counted Smart Pointer". It's not just a
random 2-letter sequence.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[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