Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #56134 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2015-01-10 13:11 -0800 |
| Last post | 2015-01-20 00:12 -0800 |
| Articles | 20 on this page of 205 — 34 participants |
Back to article view | Back to comp.lang.c
faster than c fir <profesor.fir@gmail.com> - 2015-01-10 13:11 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-10 14:26 -0800
Re: faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:43 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:39 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-11 09:23 +0000
Re: faster than c asetofsymbols@gmail.com - 2015-01-11 02:17 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-11 06:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 06:46 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 15:01 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 13:44 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 16:59 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 15:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 04:56 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-12 23:26 +0000
Re: faster than c jt@toerring.de (Jens Thoms Toerring) - 2015-01-13 01:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 05:16 -0800
faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:42 -0800
Re: faster than c Cooler_x0a <c00f3r@gmail.com> - 2015-01-10 15:51 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-11 00:21 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-11 02:27 -0800
Re: faster than c gamo <gamo@telecable.es> - 2015-01-11 12:17 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:02 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 03:44 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 05:08 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 06:03 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:06 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 06:57 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-22 07:27 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:45 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 22:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:16 +0100
Re: faster than c Tim Prince <tprince@computer.org> - 2015-01-11 15:42 -0500
Re: faster than c Michael Angelo Ravera <maravera@prodigy.net> - 2015-01-14 12:25 -0800
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 13:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:32 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 14:42 +0100
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 19:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:55 -0800
Re: faster than c "Osmium" <r124c4u102@comcast.net> - 2015-01-17 08:00 -0600
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 10:15 -0800
Re: faster than c wssimms@gmail.com - 2015-01-17 10:31 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:21 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:13 -0800
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-17 12:32 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:01 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 08:24 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 22:52 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:04 -0600
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 10:12 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 23:05 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 16:23 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:32 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-24 19:08 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 12:31 -0700
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:45 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 12:58 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-25 21:22 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:30 -0700
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:50 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:20 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 00:55 +0100
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 01:06 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 11:34 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 20:29 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:34 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-26 13:53 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 15:08 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:28 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 12:42 -0700
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-30 20:06 +0000
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:37 +1300
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 05:13 +0000
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:33 +1300
Re: faster than c Philip Lantz <prl@canterey.us> - 2015-03-31 00:14 -0700
Re: faster than c wssimms@gmail.com - 2015-01-17 10:33 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-17 20:03 +0000
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:07 +0100
Re: faster than c wpihughes@gmail.com - 2015-01-26 13:30 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:36 +1300
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:02 +0000
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 19:14 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:41 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 12:06 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 20:36 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:01 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 21:18 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:36 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:17 +0100
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 10:40 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:29 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:41 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 12:45 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:31 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:48 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 15:23 +0100
Re: faster than c mark.bluemel@gmail.com - 2015-01-19 07:25 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-19 08:56 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 17:01 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:08 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:19 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 17:46 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 10:19 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-19 10:56 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 11:30 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 14:22 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-20 00:45 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 01:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 08:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 00:57 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 03:58 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:05 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 02:11 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 02:18 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 02:30 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 05:16 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-20 14:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:29 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-20 21:53 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 17:37 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 00:05 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 01:38 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 07:46 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-21 03:23 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:52 +0000
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-21 08:53 -0600
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 16:41 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:58 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:11 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 02:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:38 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-21 08:48 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:24 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 13:38 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-21 16:43 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 10:09 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-24 01:15 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 23:59 -0600
Re: faster than c fmassei@gmail.com - 2015-01-22 01:17 -0800
Re: faster than c wssimms@gmail.com - 2015-01-22 05:16 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:27 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-22 05:36 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:54 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 05:55 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-23 00:53 -0600
Re: faster than c fmassei@gmail.com - 2015-01-23 00:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:09 -0800
Re: faster than c fmassei@gmail.com - 2015-01-23 01:33 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:55 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-23 22:44 +1300
Re: faster than c fmassei@gmail.com - 2015-01-23 01:56 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:11 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 06:21 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 16:46 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 07:58 -0800
Re: faster than c Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-01-22 12:29 -0500
Re: faster than c fmassei@gmail.com - 2015-01-22 10:09 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-22 14:07 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-24 00:40 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-24 12:53 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-22 15:09 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 01:59 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:46 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-25 02:15 -0500
Re: faster than c asetofsymbols@gmail.com - 2015-03-25 02:45 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 11:30 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-26 00:42 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 11:35 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-17 14:42 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 22:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 15:13 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 22:02 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 16:21 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 01:27 +0000
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-18 01:41 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 00:11 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 11:23 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 20:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 13:12 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 15:49 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 16:06 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 01:03 +0000
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 08:13 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 01:39 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 13:52 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:36 +0000
Re: faster than c Walter Banks <walter@bytecraft.com> - 2015-01-20 14:01 -0500
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 11:18 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 22:30 +0100
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:49 +1300
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 14:30 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 07:32 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 15:56 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 08:33 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 02:26 -0800
faster than c asetofsymbols@gmail.com - 2015-01-20 00:12 -0800
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 11:55 -0800 |
| Message-ID | <e41e1546-303f-4d56-a14a-05210ed70093@googlegroups.com> |
| In reply to | #56388 |
W dniu sobota, 17 stycznia 2015 20:29:10 UTC+1 użytkownik Jorgen Grahn napisał: > On Sat, 2015-01-17, Melzzzzz wrote: > > On 17 Jan 2015 13:29:52 GMT > > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > > > >> On Sat, 2015-01-10, fir wrote: > >> > >> > there are some languages that are low level like c [...] I mean some > >> > languages that could teoretically compete with c in efficiency.. do > >> > maybe some of such language some solution that make the outcome > >> > program to be faster (or equally speed but with different solution) > >> > comparing to c? > >> > >> I have a hard time parsing your question, but C++ tends to be faster > >> than C. > > > > How so? Speed should be same and C++ has additional bloat. Lot of > > bloat... > > By all means, keep telling yourself that. > > >> Plenty of other languages are faster, in specialized cases. > >> > > > > Talk about *implementations* please. This implementation of > > language X is faster than that implementation of language Y > > in this benchmark, particular case. > > Fortran for numerics has already been mentioned. Surely this is > common knowledge, that Fortran allows the compiler author to do things > a C compiler author cannot easily do? But yes of course a poor > implementation of Fortran will be beaten by a good C compiler. > comparing language to language in the simpletonic plane: a language is faster than b language is hard; I am getting angry if someone even brings such confusion it is better to talk over advantages of some partial mechanisms not "comparing whole languages", discussing advantages is other thing than comparing
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-01-17 08:00 -0600 |
| Message-ID | <chv878Fh9nrU1@mid.individual.net> |
| In reply to | #56368 |
"Jorgen Grahn" wrote: > On Sat, 2015-01-10, fir wrote: > >> there are some languages that are low level like c [...] I mean some >> languages that could teoretically compete with c in efficiency.. do >> maybe some of such language some solution that make the outcome >> program to be faster (or equally speed but with different solution) >> comparing to c? > > I have a hard time parsing your question, but C++ tends to be faster > than C. > > Plenty of other languages are faster, in specialized cases. Don't tease us! Tell us what those languages are and what fields they are used in. They have to be faster in some interesting way; a language that can open a file 100 times faster than C++ does not count. Things having to do with matrices, for example, are interesting.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-01-17 10:15 -0800 |
| Message-ID | <42a7365b-a1a2-4287-a17a-270c2f168097@googlegroups.com> |
| In reply to | #56368 |
On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: > > I have a hard time parsing your question, but C++ tends to be faster > than C. > I find that hard to believe. If performance is overwhelming important, then of course it's hard to be extremely optimised C. If there has to be a trade-off between performance and ease of coding, C++ templates can be faster than the C equivalent of passing void *s about. The main advantage of C++, as far as I can see, is that it makes it easier to use a balanced binary search tree (called a set for some reason). However C++ makes it more tempting to use inefficient data representations, and do unnecessary copying and dynamic memory allocation, also run unnecessary bounds checking. It much harder to keep track of how many cycles you are using, because C++ does more work without being explicitly told.
[toc] | [prev] | [next] | [standalone]
| From | wssimms@gmail.com |
|---|---|
| Date | 2015-01-17 10:31 -0800 |
| Message-ID | <66abefe5-b011-4784-8753-618db4c51326@googlegroups.com> |
| In reply to | #56380 |
Am Samstag, 17. Januar 2015 13:15:09 UTC-5 schrieb Malcolm McLean: > On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: > > > > I have a hard time parsing your question, but C++ tends to be faster > > than C. > > > I find that hard to believe. > If performance is overwhelming important, then of course it's hard to > be extremely optimised C. If there has to be a trade-off between > performance and ease of coding, C++ templates can be faster than > the C equivalent of passing void *s about. The main advantage of C++, > as far as I can see, is that it makes it easier to use a balanced > binary search tree (called a set for some reason). > > However C++ makes it more tempting to use inefficient data representations, > and do unnecessary copying and dynamic memory allocation, also run > unnecessary bounds checking. It much harder to keep track of how > many cycles you are using, because C++ does more work without being > explicitly told. There isn't anything inherent in C++ that would make it faster than C, at least as far as the base language goes. But C++ has a very large and useful standard library that can be highly optimized for each platform, and C++ strongly encourages the use of this library. Unless you are talking about embedded systems programming (and even then with modern "big" embedded systems, it may well be faster to use C++'s built in libraries than to roll your own in C. Sure you can license third party libraries in C to cover some of the gap, and of course everybody probably has their own personal libraries, but neither of these are likely to be as optimized, both algorithmically and in a machine- dependent sense, as the standard libraries in a good C++ implementation.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-01-17 19:10 +0000 |
| Message-ID | <m9ec3g$3e6$1@speranza.aioe.org> |
| In reply to | #56381 |
wssimms@gmail.com wrote: (snip regarding C++ being faster than C) >> However C++ makes it more tempting to use inefficient data >> representations, >> and do unnecessary copying and dynamic memory allocation, also run >> unnecessary bounds checking. It much harder to keep track of how >> many cycles you are using, because C++ does more work without being >> explicitly told. > There isn't anything inherent in C++ that would make it faster than > C, at least as far as the base language goes. But C++ has a very large > and useful standard library that can be highly optimized for each > platform, and C++ strongly encourages the use of this library. And if you are lucky that your program exactly matches one of those libraries, then yes. > Unless you are talking about embedded systems programming (and > even then with modern "big" embedded systems, it may well be faster > to use C++'s built in libraries than to roll your own in C. Well, even for non-embedded systems, the libraries you indicate have to allow for a more general case than one usually needs. That adds extra overhead relative to the more specific case. But well optimized code might make up for some more specific, but less optimized code. > Sure you can > license third party libraries in C to cover some of the gap, and of course > everybody probably has their own personal libraries, but neither of these > are likely to be as optimized, both algorithmically and in a machine- > dependent sense, as the standard libraries in a good C++ implementation. The personal library might be better matched to the problem, though, as the person will have written it for the problems in need. One then has to balance the extra cost (time) for the optimal routine against the faster (in people time) of the more general choice. -- glen
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 11:21 -0800 |
| Message-ID | <6a24944e-8aaf-49de-86f7-eed06060c039@googlegroups.com> |
| In reply to | #56384 |
W dniu sobota, 17 stycznia 2015 20:10:57 UTC+1 użytkownik glen herrmannsfeldt napisał: > wssimms@gmail.com wrote: > > (snip regarding C++ being faster than C) > > >> However C++ makes it more tempting to use inefficient data > >> representations, > >> and do unnecessary copying and dynamic memory allocation, also run > >> unnecessary bounds checking. It much harder to keep track of how > >> many cycles you are using, because C++ does more work without being > >> explicitly told. > > > There isn't anything inherent in C++ that would make it faster than > > C, at least as far as the base language goes. But C++ has a very large > > and useful standard library that can be highly optimized for each > > platform, and C++ strongly encourages the use of this library. > > And if you are lucky that your program exactly matches one of those > libraries, then yes. > > > Unless you are talking about embedded systems programming (and > > even then with modern "big" embedded systems, it may well be faster > > to use C++'s built in libraries than to roll your own in C. > > Well, even for non-embedded systems, the libraries you indicate have > to allow for a more general case than one usually needs. That adds > extra overhead relative to the more specific case. But well optimized > code might make up for some more specific, but less optimized code. > > > Sure you can > > license third party libraries in C to cover some of the gap, and of course > > everybody probably has their own personal libraries, but neither of these > > are likely to be as optimized, both algorithmically and in a machine- > > dependent sense, as the standard libraries in a good C++ implementation. > > The personal library might be better matched to the problem, though, > as the person will have written it for the problems in need. > > One then has to balance the extra cost (time) for the optimal routine > against the faster (in people time) of the more general choice. > > -- glen the poster you answer to probably does not want what he is talkin about; maybe wssimms should give specyfic example (othervise i very dislike this kind of posting the false matters)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 11:13 -0800 |
| Message-ID | <472bded4-778b-453d-b8d9-9e643909ba09@googlegroups.com> |
| In reply to | #56381 |
W dniu sobota, 17 stycznia 2015 19:31:20 UTC+1 użytkownik wss...@gmail.com napisał: > Am Samstag, 17. Januar 2015 13:15:09 UTC-5 schrieb Malcolm McLean: > > On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: > > > > > > I have a hard time parsing your question, but C++ tends to be faster > > > than C. > > > > > I find that hard to believe. > > If performance is overwhelming important, then of course it's hard to > > be extremely optimised C. If there has to be a trade-off between > > performance and ease of coding, C++ templates can be faster than > > the C equivalent of passing void *s about. The main advantage of C++, > > as far as I can see, is that it makes it easier to use a balanced > > binary search tree (called a set for some reason). > > > > However C++ makes it more tempting to use inefficient data representations, > > and do unnecessary copying and dynamic memory allocation, also run > > unnecessary bounds checking. It much harder to keep track of how > > many cycles you are using, because C++ does more work without being > > explicitly told. > > There isn't anything inherent in C++ that would make it faster than > C, at least as far as the base language goes. But C++ has a very large > and useful standard library that can be highly optimized for each > platform, and C++ strongly encourages the use of this library. > > Unless you are talking about embedded systems programming (and > even then with modern "big" embedded systems, it may well be faster > to use C++'s built in libraries than to roll your own in C. Sure you can > license third party libraries in C to cover some of the gap, and of course > everybody probably has their own personal libraries, but neither of these > are likely to be as optimized, both algorithmically and in a machine- > dependent sense, as the standard libraries in a good C++ implementation. blam, that was weak , so shamefully banal so weak, I even forgot that some could make such posts prove that those are not raindamaging (to truth) coverof foggy belifs and wishes - what could be so optymised in c++ generalised vector over crafted array craft? can you provide an example? or are you maybe compare some c++ code to some exceptionnaly weak c code - in this case you could spare words to express such strange comparison damn how awfully weak this was
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-01-17 12:32 -0800 |
| Message-ID | <4397205f-c6de-45b4-899b-21aa24e1d2d8@googlegroups.com> |
| In reply to | #56381 |
On Saturday, 17 January 2015 20:31:20 UTC+2, wss...@gmail.com wrote: > Am Samstag, 17. Januar 2015 13:15:09 UTC-5 schrieb Malcolm McLean: > > On Saturday, January 17, 2015 at 1:30:06 PM UTC, Jorgen Grahn wrote: > > > > > > I have a hard time parsing your question, but C++ tends to be faster > > > than C. > > > > > I find that hard to believe. > > If performance is overwhelming important, then of course it's hard to > > be extremely optimised C. If there has to be a trade-off between > > performance and ease of coding, C++ templates can be faster than > > the C equivalent of passing void *s about. The main advantage of C++, > > as far as I can see, is that it makes it easier to use a balanced > > binary search tree (called a set for some reason). > > > > However C++ makes it more tempting to use inefficient data representations, > > and do unnecessary copying and dynamic memory allocation, also run > > unnecessary bounds checking. It much harder to keep track of how > > many cycles you are using, because C++ does more work without being > > explicitly told. > > There isn't anything inherent in C++ that would make it faster than > C, at least as far as the base language goes. But C++ has a very large > and useful standard library that can be highly optimized for each > platform, and C++ strongly encourages the use of this library. There are no inherent benefit in C++ or some defect in C. Only that C++ has almost all the features of C and lot of features on the top of that. So code written in C++ is sometimes hard to translate into C. C++ is large and complex language. Learning to write efficient C++ takes more years but once learned it tends to be faster. > Unless you are talking about embedded systems programming (and > even then with modern "big" embedded systems, it may well be faster > to use C++'s built in libraries than to roll your own in C. Sure you can > license third party libraries in C to cover some of the gap, and of course > everybody probably has their own personal libraries, but neither of these > are likely to be as optimized, both algorithmically and in a machine- > dependent sense, as the standard libraries in a good C++ implementation. Most C++ libraries are template libraries. Templates let compiler's to do as lot of work compile time as is possible and so generate more optimal binaries. With C function calls it is more difficult for compiler to apply such optimizations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 11:01 +0100 |
| Message-ID | <m9ikl0$fv7$1@dont-email.me> |
| In reply to | #56395 |
On 17/01/15 21:32, Öö Tiib wrote: > Most C++ libraries are template libraries. Templates let compiler's to do > as lot of work compile time as is possible and so generate more optimal > binaries. With C function calls it is more difficult for compiler to apply > such optimizations. > And that is a reason why C++ code can sometimes be faster than roughly equivalent C code. Given that almost all well-written C code is also valid C++ code, and that you are usually using the same compiler for C and C++, any C code can also be used as C++ at the same speed. (The one feature of C++ that can sometimes adversely affect optimisation is exceptions - you may want to turn them off in compiler options if that's the case.) So while you certainly /could/ write slower C++ code than a given C program, you don't have to - you can write C++ code that is at least as fast as the C code. The question then is if you can write C++ code that is /faster/ than C code. C++ has metaprogramming features such as templates that can generate multiple optimised versions of code as a replacement for more generic code (taking a "void*" and "size_t" parameter) - such optimised functions will almost always be faster than C-style generic functions. A template-based linked list or search algorithm will beat a generic void* one. To get the same performance with C, you need to write individual functions for each type you are going to use, or write ugly macros. C++ also has the "constexpr" keyword to help pre-calculate function results - trading compile time for faster run-time (and opening the possibility of more constant propagation optimisations). Again, with C this could be done with macros, or external programs. As has been noted before, C++ has some highly optimised standard libraries - but you could write C code with the same algorithms instead of using the libraries. I therefore think it would be rare for it to be impossible to write C code that runs as fast or faster than any given C++ code. However, I think it is perfectly reasonable to say that for some types of C++ code, it is impossible to write /good/, /clean/, /maintainable/, /flexible/ C code that does the same job just as quickly - and certainly impossible to do so in a similar timeframe.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-01-19 08:24 -0800 |
| Message-ID | <lnoapupwkt.fsf@nuthaus.mib.org> |
| In reply to | #56459 |
David Brown <david.brown@hesbynett.no> writes:
> On 17/01/15 21:32, Öö Tiib wrote:
>> Most C++ libraries are template libraries. Templates let compiler's to do
>> as lot of work compile time as is possible and so generate more optimal
>> binaries. With C function calls it is more difficult for compiler to apply
>> such optimizations.
>
> And that is a reason why C++ code can sometimes be faster than roughly
> equivalent C code.
>
> Given that almost all well-written C code is also valid C++ code, and
True if you count "almost all" by lines of code. Any C program that
calls malloc() and does not cast the result is not a valid C++ program
(assuming it assigns the result to a non-void pointer object). That
doesn't affect your point, though.
> that you are usually using the same compiler for C and C++,
Not exactly. C and C++ compilers at least have different front ends. I
suppose you could have a compiler front end that parses based on a
combined grammar that recognizes both C and C++, and that interprets the
meaning of the code (or rejects it) based on the current language, but I
don't think that's the usual approach. A C and C++ compiler can share
optimization and code generation phases (as they do in gcc, for
example), and does tend to imply similar generated code for similar
constructs.
any C code
> can also be used as C++ at the same speed. (The one feature of C++ that
> can sometimes adversely affect optimisation is exceptions - you may want
> to turn them off in compiler options if that's the case.)
>
> So while you certainly /could/ write slower C++ code than a given C
> program, you don't have to - you can write C++ code that is at least as
> fast as the C code.
>
> The question then is if you can write C++ code that is /faster/ than C
> code. C++ has metaprogramming features such as templates that can
> generate multiple optimised versions of code as a replacement for more
> generic code (taking a "void*" and "size_t" parameter) - such optimised
> functions will almost always be faster than C-style generic functions.
> A template-based linked list or search algorithm will beat a generic
> void* one. To get the same performance with C, you need to write
> individual functions for each type you are going to use, or write ugly
> macros.
C's qsort() is a good example. (It's also C++'s qsort(), but it's
probably not used much in C++.) C's lack of type-generic programming
means that the comparison function has to be called via a function
pointer. A C++ template can expand to code that calls the comparison
function directly, which presumably can lead to substantially faster
code if the comparison is simple.
It would be interesting to take a C library qsort() implementation and
rewrite it as a very large macro, and compare the performance.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 22:52 +0100 |
| Message-ID | <m9juao$1ks$1@dont-email.me> |
| In reply to | #56473 |
On 19/01/15 17:24, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/01/15 21:32, Öö Tiib wrote:
>>> Most C++ libraries are template libraries. Templates let compiler's to do
>>> as lot of work compile time as is possible and so generate more optimal
>>> binaries. With C function calls it is more difficult for compiler to apply
>>> such optimizations.
>>
>> And that is a reason why C++ code can sometimes be faster than roughly
>> equivalent C code.
>>
>> Given that almost all well-written C code is also valid C++ code, and
>
> True if you count "almost all" by lines of code. Any C program that
> calls malloc() and does not cast the result is not a valid C++ program
> (assuming it assigns the result to a non-void pointer object). That
> doesn't affect your point, though.
Fair enough - people's idea of good style (for C, C++ or anything else)
varies. Let's just say that almost all well-written C can be trivially
modified to be valid C and C++ (and have the same function in both
languages).
>
>> that you are usually using the same compiler for C and C++,
>
> Not exactly. C and C++ compilers at least have different front ends. I
> suppose you could have a compiler front end that parses based on a
> combined grammar that recognizes both C and C++, and that interprets the
> meaning of the code (or rejects it) based on the current language, but I
> don't think that's the usual approach. A C and C++ compiler can share
> optimization and code generation phases (as they do in gcc, for
> example), and does tend to imply similar generated code for similar
> constructs.
I'll accept that too. But any differences in generated results are
going to be very minor (baring obvious things like the mangled names,
and tables for handling exceptions).
>
> any C code
>> can also be used as C++ at the same speed. (The one feature of C++ that
>> can sometimes adversely affect optimisation is exceptions - you may want
>> to turn them off in compiler options if that's the case.)
>>
>> So while you certainly /could/ write slower C++ code than a given C
>> program, you don't have to - you can write C++ code that is at least as
>> fast as the C code.
>>
>> The question then is if you can write C++ code that is /faster/ than C
>> code. C++ has metaprogramming features such as templates that can
>> generate multiple optimised versions of code as a replacement for more
>> generic code (taking a "void*" and "size_t" parameter) - such optimised
>> functions will almost always be faster than C-style generic functions.
>> A template-based linked list or search algorithm will beat a generic
>> void* one. To get the same performance with C, you need to write
>> individual functions for each type you are going to use, or write ugly
>> macros.
>
> C's qsort() is a good example. (It's also C++'s qsort(), but it's
> probably not used much in C++.) C's lack of type-generic programming
> means that the comparison function has to be called via a function
> pointer. A C++ template can expand to code that calls the comparison
> function directly, which presumably can lead to substantially faster
> code if the comparison is simple.
>
> It would be interesting to take a C library qsort() implementation and
> rewrite it as a very large macro, and compare the performance.
>
In theory, the macro approach should give basically the same results.
But while people (justifiably) consider template code to be a bit more
difficult to understand, write and debug than "normal" functions,
templates are much nicer than large macro functions.
A better choice for something like this in plain C would be something
like this:
// qsort_template.h
void qsort_##TYPENAME(TYPENAME* base, size_t num) {
// code to sort TYPENAME's using function COMP
}
// test.c
#define TYPENAME int
static int comp_int(a, b) { return (a - b); }
#define COMP comp_int
#include "qsort_template.h"
#undef TYPENAME
#undef COMP
// test code calling qsort_int
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-01-20 00:04 -0600 |
| Message-ID | <blorbatl9h162oqhc7o8jmv885rt36gv8n@4ax.com> |
| In reply to | #56473 |
On Mon, 19 Jan 2015 08:24:50 -0800, Keith Thompson <kst-u@mib.org>
wrote:
>David Brown <david.brown@hesbynett.no> writes:
>
>True if you count "almost all" by lines of code. Any C program that
>calls malloc() and does not cast the result is not a valid C++ program
>(assuming it assigns the result to a non-void pointer object). That
>doesn't affect your point, though.
>
>> that you are usually using the same compiler for C and C++,
>
>Not exactly. C and C++ compilers at least have different front ends. I
>suppose you could have a compiler front end that parses based on a
>combined grammar that recognizes both C and C++, and that interprets the
>meaning of the code (or rejects it) based on the current language, but I
>don't think that's the usual approach. A C and C++ compiler can share
>optimization and code generation phases (as they do in gcc, for
>example), and does tend to imply similar generated code for similar
>constructs.
"Separate" is relative. GCC has vast amounts of common code for the
two.
>> The question then is if you can write C++ code that is /faster/ than C
>> code. C++ has metaprogramming features such as templates that can
>> generate multiple optimised versions of code as a replacement for more
>> generic code (taking a "void*" and "size_t" parameter) - such optimised
>> functions will almost always be faster than C-style generic functions.
>> A template-based linked list or search algorithm will beat a generic
>> void* one. To get the same performance with C, you need to write
>> individual functions for each type you are going to use, or write ugly
>> macros.
>
>C's qsort() is a good example. (It's also C++'s qsort(), but it's
>probably not used much in C++.) C's lack of type-generic programming
>means that the comparison function has to be called via a function
>pointer. A C++ template can expand to code that calls the comparison
>function directly, which presumably can lead to substantially faster
>code if the comparison is simple.
>
>It would be interesting to take a C library qsort() implementation and
>rewrite it as a very large macro, and compare the performance.
This should mainly be a distribution issue. Most compilers should be
able to inline an ordinary definition of qsort (assuming they saw it
in the header, perhaps making it "static inline"), and then inline the
compare function (assuming it's fixed).
With LTCG, it should even be possible to do that if qsort's code is
not in a header, but it then requires the correct intermediate form to
be available at code generation (aka link) time.
Out of curiosity, I compiled the following with a recent MSVC:
#define inline __forceinline // MS silliness
#include <stddef.h>
static inline void inssort(void* base, size_t num, size_t size,
int (*compar)(const void*,const void*))
{
int i, j, k;
char *b = base;
char *p;
for (i=1; i<num; i++)
for (j=i-1; j>=0; j--)
{
p = b+(j*size);
if (compar(p, p+size) > 0)
{
// swap
for (k=0; k<size; k++)
{
char t;
t = *(p+k);
*(p+k) = *(p+k+size);
*(p+k+size) = t;
}
}
else
break;
}
}
static inline int compint(const void* p1, const void* p2)
{
const int *pi1 = p1;
const int *pi2 = p2;
if (*pi1 > *pi2)
return 1;
if (*pi1 < *pi2)
return -1;
return 0;
}
void f(int *array, int num)
{
inssort(array, num, sizeof(int), compint);
}
With -Ox, it generated for f():
PUBLIC _f
; Function compile flags: /Ogtpy
_TEXT SEGMENT
_array$ = 8 ; size = 4
tv819 = 12 ; size = 4
_num$ = 12 ; size = 4
_f PROC
; Line 48
mov eax, DWORD PTR _num$[esp-4]
cmp eax, 1
jbe SHORT $LN11@f
push ebx
push ebp
mov ebp, DWORD PTR _array$[esp+4]
push esi
push edi
xor edi, edi
add ebp, 4
dec eax
mov DWORD PTR tv819[esp+12], eax
npad 5
$LL33@f:
mov esi, edi
test edi, edi
js SHORT $LN12@f
mov eax, ebp
$LL32@f:
mov edx, DWORD PTR [eax-4]
lea ecx, DWORD PTR [eax-4]
cmp edx, DWORD PTR [eax]
jle SHORT $LN12@f
mov bl, BYTE PTR [eax]
mov BYTE PTR [eax], dl
movzx edx, BYTE PTR [eax+1]
mov BYTE PTR [ecx], bl
mov cl, BYTE PTR [eax-3]
mov BYTE PTR [eax-3], dl
movzx edx, BYTE PTR [eax+2]
mov BYTE PTR [eax+1], cl
mov cl, BYTE PTR [eax-2]
mov BYTE PTR [eax-2], dl
movzx edx, BYTE PTR [eax+3]
mov BYTE PTR [eax+2], cl
mov cl, BYTE PTR [eax-1]
mov BYTE PTR [eax-1], dl
mov BYTE PTR [eax+3], cl
sub eax, 4
dec esi
jns SHORT $LL32@f
$LN12@f:
inc edi
add ebp, 4
dec DWORD PTR tv819[esp+12]
jne SHORT $LL33@f
pop edi
pop esi
pop ebp
pop ebx
$LN11@f:
; Line 49
ret 0
_f ENDP
_TEXT ENDS
It completely inlined the sort and the call to the comparison program
(the three lines after $LL32@f).
Caveats: No testing. I did an insertion sort because it was less work
than a Quicksort, although I used what are pretty canonical signatures
for the sort and comparison functions. The generated swap code is
atrocious (although it did unroll it nicely), the compiler should have
detected that no aliasing is possible in that loop. If you compiled
that as a C++ program, a number of casts are necessary.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-01-19 10:12 -0800 |
| Message-ID | <3fb730a4-7776-474e-8ed3-3f79b6d48f12@googlegroups.com> |
| In reply to | #56459 |
On Monday, 19 January 2015 12:01:42 UTC+2, David Brown wrote: > On 17/01/15 21:32, 嘱 Tiib wrote: > > > Most C++ libraries are template libraries. Templates let compiler's to do > > as lot of work compile time as is possible and so generate more optimal > > binaries. With C function calls it is more difficult for compiler to apply > > such optimizations. > > And that is a reason why C++ code can sometimes be faster than roughly > equivalent C code. > > Given that almost all well-written C code is also valid C++ code, and > that you are usually using the same compiler for C and C++, any C code > can also be used as C++ at the same speed. (The one feature of C++ that > can sometimes adversely affect optimisation is exceptions - you may want > to turn them off in compiler options if that's the case.) My tests show that this is myth on majority of platforms. If the situation handled with exception is exceptional (like with probability < 1:50000) then exception seems most efficient way of handling it. Doing same manually with setjmp/longjmp is painful and usually less efficient. Only a code that does not handle the situation at all (crashes or aborts instead) is marginally (usually <1%) faster with always flawless input. The 'try' is made very cheap on case when exceptions don't fly. Similar myth seems to be about virtual functions. I need those rarely but when I do then they get rid of some switch-cases, if-else chains or lookup tables on some "kind" or "type" struct member that tend to be less efficient than the hidden vtable pointer member. Both features can be used (and are used by novices) for wrong things and that is the source of the myths of their crippling inefficiency. > So while you certainly /could/ write slower C++ code than a given C > program, you don't have to - you can write C++ code that is at least as > fast as the C code. > > The question then is if you can write C++ code that is /faster/ than C > code. C++ has metaprogramming features such as templates that can > generate multiple optimised versions of code as a replacement for more > generic code (taking a "void*" and "size_t" parameter) - such optimised > functions will almost always be faster than C-style generic functions. The 'void*' erases context to extreme. Even array (or string constant) to (non-void) pointer decay loses the dimension of array (that may be useful for optimisations). > A template-based linked list or search algorithm will beat a generic > void* one. To get the same performance with C, you need to write > individual functions for each type you are going to use, or write ugly > macros. > > C++ also has the "constexpr" keyword to help pre-calculate function > results - trading compile time for faster run-time (and opening the > possibility of more constant propagation optimisations). Again, with C > this could be done with macros, or external programs. > > As has been noted before, C++ has some highly optimised standard > libraries - but you could write C code with the same algorithms instead > of using the libraries. Yes, also that means testing and profiling of such hand-written or macro- generated or other code-generator generated sources per platform targeted. It is worth doing with C++ library as well but it has been of very decent quality lately. It was more than 10 years ago when bad surprises were more frequent. > I therefore think it would be rare for it to be impossible to write C > code that runs as fast or faster than any given C++ code. However, I > think it is perfectly reasonable to say that for some types of C++ code, > it is impossible to write /good/, /clean/, /maintainable/, /flexible/ C > code that does the same job just as quickly - and certainly impossible > to do so in a similar timeframe. The major advantage is indeed flexibility. The stress conditions may be are unknown or misunderstood at early stages of project. Replacing the containers/algorithms later is lot cheaper with C++. The problem is that good specialist of C++ himself takes years more to train first.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 23:05 +0100 |
| Message-ID | <m9jv2v$4om$1@dont-email.me> |
| In reply to | #56480 |
On 19/01/15 19:12, Öö Tiib wrote: > On Monday, 19 January 2015 12:01:42 UTC+2, David Brown wrote: >> On 17/01/15 21:32, 嘱 Tiib wrote: >> >>> Most C++ libraries are template libraries. Templates let compiler's to do >>> as lot of work compile time as is possible and so generate more optimal >>> binaries. With C function calls it is more difficult for compiler to apply >>> such optimizations. >> >> And that is a reason why C++ code can sometimes be faster than roughly >> equivalent C code. >> >> Given that almost all well-written C code is also valid C++ code, and >> that you are usually using the same compiler for C and C++, any C code >> can also be used as C++ at the same speed. (The one feature of C++ that >> can sometimes adversely affect optimisation is exceptions - you may want >> to turn them off in compiler options if that's the case.) > > My tests show that this is myth on majority of platforms. If the situation > handled with exception is exceptional (like with probability < 1:50000) > then exception seems most efficient way of handling it. Doing same > manually with setjmp/longjmp is painful and usually less efficient. Only > a code that does not handle the situation at all (crashes or aborts instead) > is marginally (usually <1%) faster with always flawless input. The 'try' is > made very cheap on case when exceptions don't fly. I would not want to use setjmp/longjmp as alternatives to exceptions - I would never want to use them at all. Certainly exceptions can be implemented quite efficiently (at least on sufficiently powerful platforms). But the use of exceptions, and the possibility that a called function may introduce an exception, can limit the compiler's freedoms in moving code around, or it can force data to be placed on the stack (where it can be found during stack unwinding in the event of an exception being thrown). So I don't mean that the exception handling itself is inefficient, but that it can (at least in theory) affect the optimisation of the rest of the code. So I agree that what you /think/ I said is a myth (at least on the majority of platforms, as you said). But that wasn't what I said - or at least what I meant, and have now explained in a little more detail. Of course, it is possible that my believe that exceptions can hinder optimisation is /also/ a myth. If so, I will be happy to hear about it. > > Similar myth seems to be about virtual functions. I need those rarely > but when I do then they get rid of some switch-cases, if-else > chains or lookup tables on some "kind" or "type" struct member that tend > to be less efficient than the hidden vtable pointer member. I agree that the "cost" of virtual functions is mostly a myth. They cost more than non-virtual functions if you don't actually need the functionality - but not much more, as compilers are pretty good at de-virtualising calls when possible. But when the virtual nature of the function is used, they are typically cheaper than any alternatives. > > Both features can be used (and are used by novices) for wrong things and > that is the source of the myths of their crippling inefficiency. Agreed. > >> So while you certainly /could/ write slower C++ code than a given C >> program, you don't have to - you can write C++ code that is at least as >> fast as the C code. >> >> The question then is if you can write C++ code that is /faster/ than C >> code. C++ has metaprogramming features such as templates that can >> generate multiple optimised versions of code as a replacement for more >> generic code (taking a "void*" and "size_t" parameter) - such optimised >> functions will almost always be faster than C-style generic functions. > > The 'void*' erases context to extreme. Even array (or string constant) to > (non-void) pointer decay loses the dimension of array (that may be > useful for optimisations). Yes. > >> A template-based linked list or search algorithm will beat a generic >> void* one. To get the same performance with C, you need to write >> individual functions for each type you are going to use, or write ugly >> macros. >> >> C++ also has the "constexpr" keyword to help pre-calculate function >> results - trading compile time for faster run-time (and opening the >> possibility of more constant propagation optimisations). Again, with C >> this could be done with macros, or external programs. >> >> As has been noted before, C++ has some highly optimised standard >> libraries - but you could write C code with the same algorithms instead >> of using the libraries. > > Yes, also that means testing and profiling of such hand-written or macro- > generated or other code-generator generated sources per platform > targeted. It is worth doing with C++ library as well but it has been of > very decent quality lately. It was more than 10 years ago when bad > surprises were more frequent. With the proviso that not all C++ libraries are of equal quality, I agree - and this is why C++ code can be faster than /practical/ C code. (Similarly, /practical/ C code is going to be faster than /practical/ assembly code for entire programs - even though particular snippets might be faster in specialised assembly. And in some cases, a language like Python will outperform C++ if you can quickly make use of highly optimised algorithms that would take too long to write, test and debug in C.) > >> I therefore think it would be rare for it to be impossible to write C >> code that runs as fast or faster than any given C++ code. However, I >> think it is perfectly reasonable to say that for some types of C++ code, >> it is impossible to write /good/, /clean/, /maintainable/, /flexible/ C >> code that does the same job just as quickly - and certainly impossible >> to do so in a similar timeframe. > > The major advantage is indeed flexibility. The stress conditions may be > are unknown or misunderstood at early stages of project. Replacing the > containers/algorithms later is lot cheaper with C++. The problem is that > good specialist of C++ himself takes years more to train first. >
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-01-19 16:23 -0800 |
| Message-ID | <3dfc826d-8a07-4c94-8fb9-6c846fe2041c@googlegroups.com> |
| In reply to | #56495 |
On Tuesday, 20 January 2015 00:05:57 UTC+2, David Brown wrote: > On 19/01/15 19:12, Öö Tiib wrote: > > On Monday, 19 January 2015 12:01:42 UTC+2, David Brown wrote: > >> On 17/01/15 21:32, Öö Tiib wrote: > >> > >>> Most C++ libraries are template libraries. Templates let compiler's to do > >>> as lot of work compile time as is possible and so generate more optimal > >>> binaries. With C function calls it is more difficult for compiler to apply > >>> such optimizations. > >> > >> And that is a reason why C++ code can sometimes be faster than roughly > >> equivalent C code. > >> > >> Given that almost all well-written C code is also valid C++ code, and > >> that you are usually using the same compiler for C and C++, any C code > >> can also be used as C++ at the same speed. (The one feature of C++ that > >> can sometimes adversely affect optimisation is exceptions - you may want > >> to turn them off in compiler options if that's the case.) > > > > My tests show that this is myth on majority of platforms. If the situation > > handled with exception is exceptional (like with probability < 1:50000) > > then exception seems most efficient way of handling it. Doing same > > manually with setjmp/longjmp is painful and usually less efficient. Only > > a code that does not handle the situation at all (crashes or aborts instead) > > is marginally (usually <1%) faster with always flawless input. The 'try' is > > made very cheap on case when exceptions don't fly. > > I would not want to use setjmp/longjmp as alternatives to exceptions - I > would never want to use them at all. I neither. If some library uses those then I am deeply worried. > Certainly exceptions can be implemented quite efficiently (at least on > sufficiently powerful platforms). But the use of exceptions, and the > possibility that a called function may introduce an exception, can limit > the compiler's freedoms in moving code around, or it can force data to > be placed on the stack (where it can be found during stack unwinding in > the event of an exception being thrown). So I don't mean that the > exception handling itself is inefficient, but that it can (at least in > theory) affect the optimisation of the rest of the code. You are correct. When exceptions can not be possibly thrown from function then it can be specified with 'noexcept' or 'throw()' to let compiler to know that such optimisations are safe. > So I agree that what you /think/ I said is a myth (at least on the > majority of platforms, as you said). But that wasn't what I said - or > at least what I meant, and have now explained in a little more detail. > > Of course, it is possible that my believe that exceptions can hinder > optimisation is /also/ a myth. If so, I will be happy to hear about it. No, I misunderstood your point. The problem with exceptions in tool-set is not efficiency. If a function has to signal about low probability show-stopper problems then the exceptions seem to be the most efficient way to do it in my tests. The actual problem is to teach the developers to use exceptions correctly and to write code only by exception-safe coding practices. RAII is simple to teach but there are other constraints too. Fortunately quite lot of languages have exceptions so people tend to be familiar. If there is some existing code that was not written exception-safe (because exceptions were turned off) then it may still be too lot of work for too little gain.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-24 09:32 -0700 |
| Message-ID | <kfna8z2icer.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #56459 |
David Brown <david.brown@hesbynett.no> writes: > Given that almost all well-written C code is also valid C++ code, > [snip] Twenty years ago I would have agreed with that, but somewhere between now and then that situation has changed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-24 19:08 +0100 |
| Message-ID | <mes95t$eml$1@dont-email.me> |
| In reply to | #58847 |
On 24/03/15 17:32, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> Given that almost all well-written C code is also valid C++ code, >> [snip] > > Twenty years ago I would have agreed with that, but > somewhere between now and then that situation has > changed. > This thread is over two months old, but since you have brought it up again, I'll bite. What constructs do you consider "well-written" in C that are not valid C++ code (with the same functionality)? So far, we've had assignment of malloc() returns (i.e., void*) to pointers without using a cast, which is fair enough. I know that there are more examples - "class" would be a perfectly good identifier in C but not in C++. And designated initialisers and VLA's are not (yet) valid in C++. Certainly these are used in C programming - but I don't think they constitute a large proportion of C code. People sometimes change large code bases from C to C++ - gcc managed it on their compiler without much problem.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-25 12:31 -0700 |
| Message-ID | <kfnd23wc1r7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #58858 |
David Brown <david.brown@hesbynett.no> writes: > On 24/03/15 17:32, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> Given that almost all well-written C code is also valid C++ >>> code, [snip] >> >> Twenty years ago I would have agreed with that, but >> somewhere between now and then that situation has >> changed. > > This thread is over two months old, but since you have brought it > up again, I'll bite. I'm sorry for the long delay. It has been a very busy time. > What constructs do you consider "well-written" in C that are not > valid C++ code (with the same functionality)? So far, we've had > assignment of malloc() returns (i.e., void*) to pointers without > using a cast, which is fair enough. The biggest problem is I don't know! It used to be the case that I could identify all the differences, or at least all the not-completely-weird ones, between C and the C subset of C++. Now I can't. I remember seeing some months ago a new item on this list and thinking, "oh, there's another C/C++ difference." IIRC it was a construct that has somewhat different semantics in the two languages. But the main thing is the gap seems to be getting wider, not narrower. > I know that there are more examples - "class" would be a perfectly > good identifier in C but not in C++. And designated initialisers > and VLA's are not (yet) valid in C++. Certainly these are used in > C programming - but I don't think they constitute a large > proportion of C code. But the percentage of programs in which they are used is going up, not down. My measure is not how many lines of code (in C) are the same in C++, but what fraction of C programs are the same if compiled as C++. And that fraction is becoming non-trivial. By the way, I'll give you another item for your list, which is compound literals. I find compound literals extremely useful, and would not want to give them up. (Disclaimer: I believe that C++ does not support compound literals, but I haven't really followed what's going on with C++ features, especially lately.) > People sometimes change large code bases from C to C++ - gcc > managed it on their compiler without much problem. The people who develop/maintain C++ are intimately familiar with both languages; they may not have had much difficulty, but they are not representative of developers in general. In any case the key word in that sentence is "change" - that the code has to be changed says that it isn't the same in the two languages. Note that my complaint is primarily about "almost all", which IMO is a significant overstatement. If you has said "A lot of C code is also valid C++", or perhaps even "a majority of C code is also valid C++", I might have agreed with you. But not "almost all". (BTW I think the "well-written" qualifier is just weaseling, since you could arbitrarily limit "well-written" code to be only that code that is also legal C++. To give the statement any meaning there must be an independent definition of what "well-written" means, or better yet choose another qualifier that can be measured objectively.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-25 12:45 -0700 |
| Message-ID | <e80eed4c-56f5-4f57-a533-629a1aaa3a93@googlegroups.com> |
| In reply to | #58950 |
On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote: > > (BTW I think the "well-written" qualifier is just weaseling, > since you could arbitrarily limit "well-written" code to be only > that code that is also legal C++. To give the statement any > meaning there must be an independent definition of what > "well-written" means, or better yet choose another qualifier that > can be measured objectively.) > Stuff like implict int, functions without prototypes, functions called with arguments of a different type to that declared in the argument list, ignoring of const qualifiers, assignment of pointer variables to ints and back, all examples of things C supports for backwards compatibility.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-25 12:58 -0700 |
| Message-ID | <87lhikq27c.fsf@kst-u.example.com> |
| In reply to | #58952 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, March 25, 2015 at 7:31:59 PM UTC, Tim Rentsch wrote:
>> (BTW I think the "well-written" qualifier is just weaseling,
>> since you could arbitrarily limit "well-written" code to be only
>> that code that is also legal C++. To give the statement any
>> meaning there must be an independent definition of what
>> "well-written" means, or better yet choose another qualifier that
>> can be measured objectively.)
>>
> Stuff like implict int, functions without prototypes, functions
> called with arguments of a different type to that declared in
> the argument list, ignoring of const qualifiers, assignment of
> pointer variables to ints and back, all examples of things C
> supports for backwards compatibility.
Implicit int and functions without prototypes: Yes.
Calling functions with incorrect argument types: Yes, but only if
the visible declaration is not a prototype.
So far, these are easily addressed by using prototypes consistently.
I do not consider C code with non-prototype function declarations
to be "well-written", for reasons unrelated to C++ compatibility.
(I make no claim that an objective definition of "well-written"
is possible.)
C does *not* permit ignoring const qualifiers, assigning pointers
to integers, or assigning integers to pointers (with the exception
of 0, which is a null pointer constant). Code that does any of
these things violates one or more *constraints*, meaning that a
conforming compiler is required to issue a diagnostic.
It is unfortunate, IMHO, that the diagnostic is often a non-fatal
warning. I would prefer all constraint violations to be treated
as fatal errors by default. Yes, I know there are command-line
options that enable the behavior I prefer. The trouble is that
these options are not always used, resulting in bad code being
inflicted on me and other programmers.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web