Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67978 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2019-08-28 16:11 -0500 |
| Last post | 2019-09-09 01:09 -0700 |
| Articles | 20 on this page of 165 — 31 participants |
Back to article view | Back to comp.lang.c++
"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-28 16:11 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-29 02:36 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 11:02 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 22:21 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 13:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 23:35 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 20:00 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 13:29 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 23:11 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 10:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 07:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:54 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:07 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 05:14 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-29 06:08 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:00 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:26 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 06:30 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:59 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 07:42 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:44 +0000
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:07 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-03 17:13 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:53 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" gazelle@shell.xmission.com (Kenny McCormack) - 2019-08-29 13:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 15:38 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:09 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-04 08:31 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 13:28 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-06 02:36 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:38 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 11:41 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 11:56 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 13:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@invalid.add> - 2019-08-31 18:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 18:21 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 05:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-01 03:21 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 12:25 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 12:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-01 04:13 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-01 23:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 14:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 07:20 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 18:22 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-01 15:23 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 22:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 06:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 11:12 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 17:52 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-02 18:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 13:05 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 19:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 06:49 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 08:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 08:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 09:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 09:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 10:30 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-03 07:11 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 13:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 15:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-03 17:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 17:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 18:51 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:42 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:56 +0000
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 11:07 -0700
Re: Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-05 19:23 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-06 08:25 +0200
Re: Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-18 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-06 07:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-06 17:16 +1200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:33 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:38 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" antispam@math.uni.wroc.pl - 2019-09-03 22:08 +0000
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:41 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:50 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 22:43 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-09-03 11:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-03 12:16 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:35 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-03 22:49 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-04 00:20 -0700
Re: Comments on third parties Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-07 06:59 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 17:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 09:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 20:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 14:40 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-06 10:05 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 22:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Clifford Heath <no.spam@please.net> - 2019-09-04 10:47 +1000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-04 16:56 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-09-05 22:02 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-31 13:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:45 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 14:08 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 13:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 15:18 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 14:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:23 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:40 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:57 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 19:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Anton Shepelev <anton.txt@gmail.com> - 2019-08-31 03:05 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 12:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 11:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-31 17:17 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 16:28 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 00:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-01 15:49 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:12 +0200
Error handling strategies (was: Rust is the future of systems programming C is the new Assembly) legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-08 20:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:42 +0200
Re: "???Rust is the future of systems programming, C is the new Assembly???: Intel principal engineer, Josh Triplett" Juha Nieminen <nospam@thanks.invalid> - 2019-08-30 21:03 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 09:42 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 23:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 06:24 -0500
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 13:51 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 22:03 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@hotmail.com> - 2019-09-07 10:57 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-08 12:40 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-09 08:59 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-09 16:35 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-09-07 18:09 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-07 15:32 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-31 04:50 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 18:39 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-09-04 01:07 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" William Ahern <william@25thandClement.com> - 2019-09-03 20:04 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-04 04:48 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson " <chris.m.thomasson.1@gmail.com> - 2019-09-09 01:09 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 10:31 +0200 |
| Message-ID | <almarsoft.9013647030560314716@news.albasani.net> |
| In reply to | #68021 |
On Fri, 30 Aug 2019 10:18:02 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> And exceptions are more performant for the performance-relevant case > >> that no exception is thrown with table-driven excepion-handling. The > >> code-path that is processed when no exception is thrown is almost as > >> efficient as if there isn't any exception-handling (nearly > > zero-over- > >> head). > > Exceptions take space or time, there is no escape, and they are non > > deterministic... > Computers are always deterministic. ;-) > But trowing exceptions is slow. But the case when we have a resouce- > or I/O-collapse isn't performance-relevant, i.e. it doesn't matter > if throwsing an exception lasts 10 or 1.000 clock-cycles. I am not talking when you throw. -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 10:39 +0200 |
| Message-ID | <qkanbn$3u7$1@news.albasani.net> |
| In reply to | #68023 |
>> Computers are always deterministic. ;-) >> But trowing exceptions is slow. But the case when we have a resouce- >> or I/O-collapse isn't performance-relevant, i.e. it doesn't matter >> if throwsing an exception lasts 10 or 1.000 clock-cycles. > I am not talking when you throw. The non-throw-case takes almost no or no performance. Evaluating return-codes is simply a magnitude slower.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 10:43 +0200 |
| Message-ID | <almarsoft.188316418275962884@news.albasani.net> |
| In reply to | #68025 |
On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Computers are always deterministic. ;-) > >> But trowing exceptions is slow. But the case when we have a resouce- > >> or I/O-collapse isn't performance-relevant, i.e. it doesn't matter > >> if throwsing an exception lasts 10 or 1.000 clock-cycles. > > I am not talking when you throw. > The non-throw-case takes almost no or no performance. That's no true. You have to install handlers evrry time or prepare tbla for each function at program start... > Evaluating return-codes is simply a magnitude slower. This is especially not true. -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 10:47 +0200 |
| Message-ID | <qkanqg$2lv$1@news.albasani.net> |
| In reply to | #68026 |
>> Evaluating return-codes is simply a magnitude slower. > This is especially not true. No, this is true. You don't simply unterstand the implications of table-driven exception handling or table-driven exception-handling at all.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-30 11:41 +0200 |
| Message-ID | <qkar0o$qke$1@dont-email.me> |
| In reply to | #68027 |
On 30/08/2019 10:47, Bonita Montero wrote: >>> Evaluating return-codes is simply a magnitude slower. > >> This is especially not true. > > No, this is true. I take it you have measured this yourself? You have sample code, measurements, statistics to back up this very specific claim? Or is it just based on "something you read somewhere", repeated in the hope that people will believe you more the second time? > You don't simply unterstand the implications of table-driven > exception handling or table-driven exception-handling at all. I expect Mel does understand it. I am less convinced /you/ do. Different error handling techniques have their pros and cons. Anyone claiming one method is faster, safer, clearer, easier than other methods is guaranteed to be /wrong/. They will have different balances, and there is no solution that is the "best" in all situations, or the best in all ways. Table-driven exception handling tends to be efficient at run-time when exceptions are not thrown, when you are running on larger processors (like x86), and when you have no issues with code space. That makes it a good choice (from the efficiency viewpoint) on PC programming. But you can also find that the possibility of exceptions passing through functions can affect their efficiency, even if they don't throw or catching anything directly - it can affect ordering and optimisation of the code by the compiler. It can affect the re-use of stack slots as the compiler has to track all possible exception points and be able to unwind correctly. On resource-constrainted systems, this kind of thing can lead to unwind tables that are bigger than the actual code size - a horrible level of inefficiency that is unacceptable in many cases. And while table-driven exception handling does not need extra instruction codes (just data tables) for functions that pass on exceptions without handling them, you need plenty of extra code - and run-time - when throwing the exception, or when catching it. Error handling via return codes, on the other hand, uses minimal extra code space in functions that raise or handle the errors - usually less overhead than for throwing or catching exceptions. It is certainly going to be much faster when errors do occur. But you have to have some way of passing on errors in functions between the "thrower" and the "catcher". That means more explicit source code, but more efficient object code. Each technique has, as I said, its pros and cons. And there are lots of reasons why one might pick one method over the other beyond efficiency - do you want your error handling clear and explicit, or automatic and hidden? Which is easier to get right, and which is harder to get wrong? But one thing we can be sure of - Sutter would not have started the process of getting "Zero-overhead deterministic exceptions" into C++ if current C++ exceptions were as ideal as suggested. And while Sutter's ideas here may come to naught, and he can be as wrong as anyone else, I am more inclined to listen to his thoughts than those of Bonita.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 11:56 +0200 |
| Message-ID | <qkarss$qsd$1@news.albasani.net> |
| In reply to | #68028 |
> I expect Mel does understand it. I am less convinced /you/ do.
Disassemble the code that calls a fuction that might throw an exceptions
with an without enabled EH. The difference is only, that the optimiza-
tions around that call might be slightly weakened; that's all. But that
usually doesn't outweigh the overhead against manually evaluating
return-codes.
> Different error handling techniques have their pros and cons. Anyone
> claiming one method is faster, safer, clearer, easier than other methods
> is guaranteed to be /wrong/.
1. Table-driven EH is usually faster.
2. I didn't say that it is safer or clearer,
but it is much more convenient.
3. When you come to the excepion-handling mechanism like in Java
with checked and unchecked exceptions, you get the best solution.
But for compatibility-reasons with C this isn't possible in C++.
> Table-driven exception handling tends to be efficient at run-time when
> exceptions are not thrown, when you are running on larger processors
> (like x86), and when you have no issues with code space. That makes it
> a good choice (from the efficiency viewpoint) on PC programming.
Almost right, but it doesn't depend on the performance of the CPU.
Even on small CPUs the performance of processing a resurce- or I/O
-collapse doesn't count.
> But you can also find that the possibility of exceptions passing through
> functions can affect their efficiency, even if they don't throw or
> catching anything directly - it can affect ordering and optimisation of
> the code by the compiler. It can affect the re-use of stack slots as
> the compiler has to track all possible exception points and be able to
> unwind correctly.
The loss of optimization-opportunities with table-driven exception
-handling is very slight. And the cost is of course not so high as
handling return-codes manually.
> On resource-constrainted systems, this kind of thing can lead to unwind
> tables that are bigger than the actual code size - a horrible level of
> inefficiency that is unacceptable in many cases.
That's true, but then you wouldn't use C++.
> Error handling via return codes, on the other hand, uses minimal extra
> code space in functions that raise or handle the errors - usually less
> overhead than for throwing or catching exceptions.
1. This case isn't performance relevant.
2. Yo cannot say that this is always true. The thing is simply that
there might be a number of return-codes evaluated at each call-level
which might result in a higher total CPU-time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-30 13:08 +0200 |
| Message-ID | <qkb03o$o43$1@dont-email.me> |
| In reply to | #68029 |
On 30/08/2019 11:56, Bonita Montero wrote: >> I expect Mel does understand it. I am less convinced /you/ do. > > Disassemble the code that calls a fuction that might throw an exceptions > with an without enabled EH. The difference is only, that the optimiza- > tions around that call might be slightly weakened; that's all. But that > usually doesn't outweigh the overhead against manually evaluating > return-codes. There is no doubt that exceptions are aimed at having minimal run-time cost when they are not thrown. But it is important to realise that /minimal/ is not /zero/. > >> Different error handling techniques have their pros and cons. Anyone >> claiming one method is faster, safer, clearer, easier than other methods >> is guaranteed to be /wrong/. > > 1. Table-driven EH is usually faster. Usually it is faster when exceptions are not thrown, but a lot slower when they /are/ thrown. But "usually" is not "always". And for some situations, it is the worst case performance - the speed when there is a problem - that is critical. I'm happy with a claim "Table driven exceptions are generally faster, when there are no errors, than other handling techniques for typical code on PC's". What I am /not/ happy with is "Exception handling is faster than other error return techniques". > 2. I didn't say that it is safer or clearer, > but it is much more convenient. Fair enough - though convenience is also a subjective matter. > 3. When you come to the excepion-handling mechanism like in Java > with checked and unchecked exceptions, you get the best solution. > But for compatibility-reasons with C this isn't possible in C++. Checked exceptions - where the type of exceptions that a function may throw or pass on is part of the signature - are safer, clearer and more efficient. (Compilers can use tables or code branches, whichever is most convenient). But they involve more explicit information, which some people like and others dislike. And they can't pass through functions compiled without knowledge of the exceptions - such as C functions compiled by a C compiler. > >> Table-driven exception handling tends to be efficient at run-time when >> exceptions are not thrown, when you are running on larger processors >> (like x86), and when you have no issues with code space. That makes it >> a good choice (from the efficiency viewpoint) on PC programming. > > Almost right, but it doesn't depend on the performance of the CPU. > Even on small CPUs the performance of processing a resurce- or I/O > -collapse doesn't count. Incorrect. Performance under the worst case is often a critical feature of high reliability systems. It is precisely because the performance exception handling is difficult to predict or measure that exceptions are banned in most such systems. > >> But you can also find that the possibility of exceptions passing through >> functions can affect their efficiency, even if they don't throw or >> catching anything directly - it can affect ordering and optimisation of >> the code by the compiler. It can affect the re-use of stack slots as >> the compiler has to track all possible exception points and be able to >> unwind correctly. > > The loss of optimization-opportunities with table-driven exception > -handling is very slight. And the cost is of course not so high as > handling return-codes manually. > That may often be the case, but I would be very wary of generalising too much. >> On resource-constrainted systems, this kind of thing can lead to unwind >> tables that are bigger than the actual code size - a horrible level of >> inefficiency that is unacceptable in many cases. > > That's true, but then you wouldn't use C++. > Nonsense. There are many good reasons to use C++, and many features that can be used, without leading to any inefficiency or bloat. >> Error handling via return codes, on the other hand, uses minimal extra >> code space in functions that raise or handle the errors - usually less >> overhead than for throwing or catching exceptions. > > 1. This case isn't performance relevant. Often not - but you are wrong to generalise like that. And you can equally well argue that since exception handling is often used in cases where you are dealing with I/O, the performance cost of manual return code checks is negligible and therefore irrelevant with such code. > 2. Yo cannot say that this is always true. The thing is simply that > there might be a number of return-codes evaluated at each call-level > which might result in a higher total CPU-time. > Yes, I have already mentioned that return code checking usually involves some handling at functions along the chain between the "thrower" and the "catcher".
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 13:47 +0200 |
| Message-ID | <qkb2d8$fou$1@news.albasani.net> |
| In reply to | #68030 |
> Usually it is faster when exceptions are not thrown, but a lot slower > when they /are/ thrown. But "usually" is not "always". And for some > situations, it is the worst case performance - the speed when there is a > problem - that is critical. The case when an exception is thrown isn't performance-relevant as this occurs when there's an resource- or I/O-collapse. > Fair enough - though convenience is also a subjective matter. That's rather not subjective here because evaluating return-codes on every call-level is a lot of work. >> 3. When you come to the excepion-handling mechanism like in Java >> with checked and unchecked exceptions, you get the best solution. >> But for compatibility-reasons with C this isn't possible in C++. > Checked exceptions - where the type of exceptions that a function may > throw or pass on is part of the signature - are safer, clearer and more > efficient. (Compilers can use tables or code branches, whichever is > most convenient). But they involve more explicit information, which > some people like and others dislike. And they can't pass through > functions compiled without knowledge of the exceptions - such as C > functions compiled by a C compiler. Can you read what I told above? >> Almost right, but it doesn't depend on the performance of the CPU. >> Even on small CPUs the performance of processing a resurce- or I/O >> -collapse doesn't count. > Incorrect. No, correct. > Performance under the worst case is often a critical feature of high > reliability systems. When you have a resource or I/O-collapse, you don't have reliability anyway. >> That's true, but then you wouldn't use C++. > Nonsense. There are many good reasons to use C++, and many features > that can be used, without leading to any inefficiency or bloat. Almost the whole standard-libary uses an allocaor which might throw bad_alloc; not to use the standard-library isn't really C++.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2019-08-31 18:03 +0200 |
| Message-ID | <qke5nr$fc1$1@gioia.aioe.org> |
| In reply to | #68033 |
On 8/30/19 1:47 PM, Bonita Montero wrote: [...] > >>> Almost right, but it doesn't depend on the performance of the CPU. >>> Even on small CPUs the performance of processing a resurce- or I/O >>> -collapse doesn't count. > >> Incorrect. > > No, correct. No, incorrect. > >> Performance under the worst case is often a critical feature of high >> reliability systems. > > When you have a resource or I/O-collapse, you don't have reliability > anyway. > Correctness of behavior (which includes controlled performance) under stress conditions (including resource exhaustion) is a critical requirement of high reliability systems - that's what they are made for. It appears you don't have much experience with such systems. > >>> That's true, but then you wouldn't use C++. > >> Nonsense. There are many good reasons to use C++, and many features >> that can be used, without leading to any inefficiency or bloat. > > Almost the whole standard-libary uses an allocaor which might > throw bad_alloc; not to use the standard-library isn't really C++. Incorrect as well. As a first one can replace the allocator in all standard library facilities, and more generally one can use many features of C++ (e.g. templates, generic programming, metaprogramming, constexpr (aka compile-time processing), ...) with no need for any runtime-hungry technology.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-31 18:21 +0200 |
| Message-ID | <qke6ql$d94$1@news.albasani.net> |
| In reply to | #68057 |
>> When you have a resource or I/O-collapse, you don't have reliability >> anyway. > Correctness of behavior (which includes controlled performance) under > stress conditions (including resource exhaustion) is a critical > requirement of high reliability systems - that's what they are made for. > It appears you don't have much experience with such systems. The correctnes is also guaranteed with exceptions. But they might have higher runtime-overhead when being thrown. But this absolutely doesn't matter because the resouce- or I/O-collapse case isn't performance -relevant. So I'm not incorrect. And consider what you would do with return-codes: you would evaluate them at every call-level and convert them into a special return-code appropriate for the function-level. This is also likely to be very inperformant. >> Almost the whole standard-libary uses an allocaor which might >> throw bad_alloc; not to use the standard-library isn't really C++. > Incorrect as well. N, true. > As a first one can replace the allocator in all standard library > facilities, ... Doing this without throwing an exception like bad_alloc from an allo- cator doesn't work. This is because there is no way to signal a memory -collapse differently than through throwing an exception on the usual container-operations. Dropping the facilities that might throw excep- tions isn't really C++
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-31 23:39 +0200 |
| Message-ID | <qkepfg$5u7$1@dont-email.me> |
| In reply to | #68033 |
On 30/08/2019 13:47, Bonita Montero wrote: >> Usually it is faster when exceptions are not thrown, but a lot slower >> when they /are/ thrown. But "usually" is not "always". And for some >> situations, it is the worst case performance - the speed when there is a >> problem - that is critical. > > The case when an exception is thrown isn't performance-relevant > as this occurs when there's an resource- or I/O-collapse. As seems to be the case depressingly often, you are over-generalising from certain types of software. For some software, exceptions are ruled out as a technique because they take too long, and in particular, their timing is very hard to predict. For real-time programming, it doesn't matter how fast the usual situation runs. It matters that even in the worst case, you know how long the code will take. It is a world outside your experience and understanding, apparently, but it is a vital part of the modern world. > >> Fair enough - though convenience is also a subjective matter. > > That's rather not subjective here because evaluating return-codes on > every call-level is a lot of work. > Again, you don't see the big picture and think that your ideas cover everything. Dealing with return codes on every call level is only a lot of work if you have lots of call levels between identifying a problem and dealing with it. And using exceptions is a /huge/ amount of work for some kinds of analysis of code and possible code flows. By being explicit and clearly limited, return code error handling is far simpler to examine and understand, and it is far easier to test functions fully when you don't have to take into account the possibility of an unknown number of unknown exceptions passing through. As I have said, different ways of handling errors have their pros and cons, and there is no one way that is best for all cases. > >>> 3. When you come to the excepion-handling mechanism like in Java >>> with checked and unchecked exceptions, you get the best solution. >>> But for compatibility-reasons with C this isn't possible in C++. > >> Checked exceptions - where the type of exceptions that a function may >> throw or pass on is part of the signature - are safer, clearer and more >> efficient. (Compilers can use tables or code branches, whichever is >> most convenient). But they involve more explicit information, which >> some people like and others dislike. And they can't pass through >> functions compiled without knowledge of the exceptions - such as C >> functions compiled by a C compiler. > > Can you read what I told above? I elaborated on what you wrote. > >>> Almost right, but it doesn't depend on the performance of the CPU. >>> Even on small CPUs the performance of processing a resurce- or I/O >>> -collapse doesn't count. > >> Incorrect. > > No, correct. I'm sorry, but you are making bald statements with apparently no knowledge or experience in the area. > >> Performance under the worst case is often a critical feature of high >> reliability systems. > > When you have a resource or I/O-collapse, you don't have reliability > anyway. > You do understand that people use exceptions for a variety of reasons, don't you? You do realise that people sometimes write safe and reliable software that is designed to deal with problems in a reasonable fashion? If "throw an exception" simply means "there's been a disaster - give up on reliability, accept that the world has ended and it doesn't matter how slowly we act as the program is falling apart" then why have an exception system in the first place? Just call "abort()" and be done with it. > >>> That's true, but then you wouldn't use C++. > >> Nonsense. There are many good reasons to use C++, and many features >> that can be used, without leading to any inefficiency or bloat. > > Almost the whole standard-libary uses an allocaor which might > throw bad_alloc; not to use the standard-library isn't really C++. That's bollocks on so many levels, it's not worth trying to explain them to you.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-01 05:16 +0200 |
| Message-ID | <qkfd6h$b1b$1@news.albasani.net> |
| In reply to | #68059 |
> For some software, exceptions are ruled out as a technique because they > take too long, and in particular, their timing is very hard to predict. Another time: the performance of resource- or I/O-collapse-handling is never relevant. >> That's rather not subjective here because evaluating return-codes on >> every call-level is a lot of work. > Again, you don't see the big picture and think that your ideas cover > everything. I see "the big picture" - you are not. > Dealing with return codes on every call level is only a lot of work if > you have lots of call levels between identifying a problem and dealing > with it. And using exceptions is a /huge/ amount of work for some kinds > of analysis of code and possible code flows. Wrong; you catch them in a central point and that's all. >> When you have a resource or I/O-collapse, you don't have reliability >> anyway. > You do understand that people use exceptions for a variety of reasons, > don't you? They are used for resource- or I/O-collapse - and nothing more. > f "throw an exception" simply means "there's been a disaster - give > up on reliability, accept that the world has ended and it doesn't matter > how slowly we act as the program is falling apart" then why have an > exception system in the first place? Just call "abort()" and be done > with it. You don't have any reliability any more at this point because the operation simply failed. The timing isn't relevant any more a this point.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-09-01 03:21 -0700 |
| Message-ID | <f580f1cf-8a0e-48c4-832e-bdbc61b8f813@googlegroups.com> |
| In reply to | #68063 |
On Sunday, 1 September 2019 06:16:45 UTC+3, Bonita Montero wrote: > On Sunday, 1 September 2019 00:40:08 UTC+3, David Brown wrote: > > For some software, exceptions are ruled out as a technique because they > > take too long, and in particular, their timing is very hard to predict. > > Another time: the performance of resource- or I/O-collapse-handling > is never relevant. Where it is written that exceptions are only for handling resource or I/O collapse? Exceptions are typically thrown in situation when a function (such as operator or constructor) can't fulfill its post-conditions. Running out of resources or failures of I/O are just easy examples why it may happen. > >> That's rather not subjective here because evaluating return-codes on > >> every call-level is a lot of work. > > > Again, you don't see the big picture and think that your ideas cover > > everything. > > I see "the big picture" - you are not. Yet the current exceptions can’t be used for some hard-real time projects exactly because of bad performance on failure case. See http://stroustrup.com/JSF-AV-rules.pdf Basically they have to extend their post-conditions of all functions that may fail with failure state and to check it. And you don't seem to understand why it is so.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-01 12:25 +0200 |
| Message-ID | <qkg6ar$o83$1@news.albasani.net> |
| In reply to | #68064 |
> Running out of resources or failures of I/O are just easy examples > why it may happen. Tell me more where exceptions might be used!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-01 12:35 +0200 |
| Message-ID | <qkg6ss$msv$1@news.albasani.net> |
| In reply to | #68065 |
>> Running out of resources or failures of I/O >> are just easy examples why it may happen. > Tell me more where exceptions might be used! Or better: mention a class-library that uses exceptions for something different than what I told!
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-09-01 04:13 -0700 |
| Message-ID | <0618fb23-abb7-4435-9d2f-2b6bd1d5036f@googlegroups.com> |
| In reply to | #68066 |
On Sunday, 1 September 2019 13:35:17 UTC+3, Bonita Montero wrote: > >> Running out of resources or failures of I/O > >> are just easy examples why it may happen. > > > Tell me more where exceptions might be used! > > Or better: mention a class-library that uses exceptions > for something different than what I told! Huh? C++ standard library and <https://www.boost.org/> contain piles of throws for numerous other reasons. Rather elementary things like Boost.Lexical_Cast may fail and throw.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-09-01 23:18 +1200 |
| Message-ID | <gt1no8FmknoU3@mid.individual.net> |
| In reply to | #68069 |
On 01/09/2019 23:13, Öö Tiib wrote: > On Sunday, 1 September 2019 13:35:17 UTC+3, Bonita Montero wrote: >>>> Running out of resources or failures of I/O >>>> are just easy examples why it may happen. >> >>> Tell me more where exceptions might be used! >> >> Or better: mention a class-library that uses exceptions >> for something different than what I told! > > Huh? C++ standard library and <https://www.boost.org/> contain piles > of throws for numerous other reasons. Rather elementary things > like Boost.Lexical_Cast may fail and throw. Even more basic, std::vector::at(). -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-01 14:04 +0200 |
| Message-ID | <qkgc4u$fdn$1@news.albasani.net> |
| In reply to | #68071 |
>> Huh? C++ standard library and <https://www.boost.org/> contain
>> piles of throws for numerous other reasons. Rather elementary
>> things like Boost.Lexical_Cast may fail and throw.
> Even more basic, std::vector::at().
OK, you're right. But the first exception isn't thrown in a per
-formance-relevant case. .at is, but this might make it useless
in many cases as eceptions are slow.
I just measured the performance of trowing an int and catching
an int & with VC++ and it is about 3 million clock-cycles:
// main translation-unit
#include <windows.h>
#include <iostream>
#include <intrin.h>
void Thrower();
using namespace std;
int main()
{
// to get always the same TSC
SetThreadAffinityMask( GetCurrentThread(), 1 );
typedef long long LL;
unsigned const REP = 1'000;
LL start, end;
start = (LL)__rdtsc();
for( unsigned i = REP; i; --i )
try
{
Thrower();
}
catch( int & )
{
}
end = (LL)__rdtsc();
cout << (double)(end - start) / REP << endl;
}
// throwing translation-unit
void Thrower()
{
throw int( 123 );
}
Maybe anyone could adapt this for other compilrs / platforms;
I'm curious about the results. Compile it without interprocedural
optimizations to prevent the compiler from optimizing away the
whole throw-try-catch-issue.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-02 07:20 +0200 |
| Message-ID | <qki8ra$62n$1@news.albasani.net> |
| In reply to | #68072 |
Sorry, I had a background task that was encoding a video through x265. I thought that it is simply sufficient to put it on idle -priority. But the issue I hadn't in mind was that this task is stealing "cycles" on the the other thread of a core. Without any competing cycles on that core the time to throw and catch an exception is only about 8.600 cycles on my Ryzen 7 1800X. But I'm still curious about the performance of other implementa- tions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-01 16:03 +0200 |
| Message-ID | <qkgj3r$pr9$1@dont-email.me> |
| In reply to | #68063 |
On 01/09/2019 05:16, Bonita Montero wrote: >> For some software, exceptions are ruled out as a technique because >> they take too long, and in particular, their timing is very hard to >> predict. > > Another time: the performance of resource- or I/O-collapse-handling > is never relevant. > All I can say is that I am glad I don't have to rely on your software. It's one thing to be ignorant - but your blind, stubborn, wilful and insistent ignorance is fortunately exceptional.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web