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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 11:07 +0100 |
| Message-ID | <m9ikv6$h00$1@dont-email.me> |
| In reply to | #56391 |
On 17/01/15 21:03, Greg Martin wrote: > On 2015-01-17, wssimms@gmail.com <wssimms@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 much harder to keep track of how >>> many cycles you are using. >> >> Another thing. If you are doing the type of programming where you care >> how many cycles are being used, then yeah, C++ is probably not for your >> projects. But for most programming projects you don't care how many >> cycles are used. > > The number of cysles usedd is directly porportional to the efficiency of > the code - which was the question - so in this case the number of cycles > does matter. > There are many types of "cycles" - processor clock cycles, instructions executed per second, memory bus cycles, single-core speed, multi-core speed, ticks on the wall clock. And there are many types of efficiency - run-time speed, power, processor saturation, wall-clock time, etc. Sometimes code that uses more processor cycles but less memory cycles will be much faster than one that uses more memory to save processor cycles. If you are trying to count cycles on a modern "big" processor, you have almost certainly misunderstood the problem. As others have said, real-world profiling with real-world data on real-world targets is the only way to get proper information.
[toc] | [prev] | [next] | [standalone]
| From | wpihughes@gmail.com |
|---|---|
| Date | 2015-01-26 13:30 -0800 |
| Message-ID | <9f399a99-cc28-4ea4-bc84-43ed8b6fc9e6@googlegroups.com> |
| In reply to | #56391 |
On Saturday, January 17, 2015 at 4:03:21 PM UTC-4, Greg Martin wrote: > used. > > The number of cysles usedd is directly porportional to the efficiency of > the code Neither in theory nor practice. If the bottleneck is memory access it might be worth a *LOT* of cycles to speed up memory access (e.g. by doing few overall accesses or by improving locality) -William Hughes
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-01-18 16:36 +1300 |
| Message-ID | <ci0o2dFgs9mU1@mid.individual.net> |
| In reply to | #56380 |
Malcolm McLean wrote: > 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. You can't fool a profiler! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-01-17 19:02 +0000 |
| Message-ID | <m9ebji$22b$1@speranza.aioe.org> |
| In reply to | #56368 |
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. Why would that be? > Plenty of other languages are faster, in specialized cases. If you use the fancier features of any language, usually that allow for less work by the programmer, they often have more run-time overhead. A simpler language requires more work by the programmer, and often runs faster as a result. -- glen
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-17 19:14 +0000 |
| Message-ID | <Nwyuw.171066$NM4.69280@fx15.am4> |
| In reply to | #56383 |
On 17/01/2015 19:02, glen herrmannsfeldt wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >> On Sat, 2015-01-10, fir wrote: >> Plenty of other languages are faster, in specialized cases. > > If you use the fancier features of any language, usually that allow > for less work by the programmer, they often have more run-time > overhead. A simpler language requires more work by the programmer, > and often runs faster as a result. Maybe. Or maybe it can be faster by using those advanced features. Example: a = b*c; Not much to optimise here, unless a, b and c are large matrices perhaps. Then the compiler can make use of an existing, dedicated and highly optimised set of routines for matrix multiplication. Without such a feature, the work would need to be implemented in C code, as a set complicated nested loops, and the C compiler would need to analyse that to try and recognise any pattern that could conceivably be accelerated. Some compilers might manage it to some extent, others won't. By having such features built-in, there is less dependence on super-optimising capabilities of compilers. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 11:41 -0800 |
| Message-ID | <f22d76bf-2708-4f00-a3a6-75de2cc582d1@googlegroups.com> |
| In reply to | #56386 |
W dniu sobota, 17 stycznia 2015 20:15:02 UTC+1 użytkownik Bart napisał: > On 17/01/2015 19:02, glen herrmannsfeldt wrote: > > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > >> On Sat, 2015-01-10, fir wrote: > > >> Plenty of other languages are faster, in specialized cases. > > > > If you use the fancier features of any language, usually that allow > > for less work by the programmer, they often have more run-time > > overhead. A simpler language requires more work by the programmer, > > and often runs faster as a result. > > Maybe. Or maybe it can be faster by using those advanced features. Example: > > a = b*c; > > Not much to optimise here, unless a, b and c are large matrices perhaps. > Then the compiler can make use of an existing, dedicated and highly > optimised set of routines for matrix multiplication. > > Without such a feature, the work would need to be implemented in C code, > as a set complicated nested loops, and the C compiler would need to > analyse that to try and recognise any pattern that could conceivably be > accelerated. > > Some compilers might manage it to some extent, others won't. > > By having such features built-in, there is less dependence on > super-optimising capabilities of compilers. > I do not take it if we compare some implementations we compare libraries and it make no sense imo you could compare language mechanisms, should stay away on comparing libraries besides even if c++ would provide some more hints to optymisers, this is mariginall change imp (still removable by optymizing library) personaly i was not asking about virtual cases but real and measurable ones, some that can be showed and measured
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 12:06 -0800 |
| Message-ID | <30a2cfce-3441-465e-85d9-bd7346b3eada@googlegroups.com> |
| In reply to | #56389 |
> > you could compare language mechanisms, > should stay away on comparing libraries > i wanted to say 'discuss language mechanisms' not damn compare
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-17 20:36 +0000 |
| Message-ID | <tJzuw.194092$Um.128550@fx22.am4> |
| In reply to | #56392 |
On 17/01/2015 20:06, fir wrote: >> >> you could compare language mechanisms, >> should stay away on comparing libraries >> > i wanted to say 'discuss language mechanisms' not damn compare > OK. Language mechanisms for doing what? And what was wrong with my example? Would you reject a language that was faster than C, because the exact feature you wanted to be fast, was built-in to it and therefore makes it possible to be streamlined? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 13:01 -0800 |
| Message-ID | <ed203f2a-e9ef-4aab-a3db-2d4e9a9a6d0e@googlegroups.com> |
| In reply to | #56396 |
W dniu sobota, 17 stycznia 2015 21:36:50 UTC+1 użytkownik Bart napisał: > On 17/01/2015 20:06, fir wrote: > >> > >> you could compare language mechanisms, > >> should stay away on comparing libraries > >> > > i wanted to say 'discuss language mechanisms' not damn compare > > > > OK. Language mechanisms for doing what? > > And what was wrong with my example? > > Would you reject a language that was faster than C, because the exact > feature you wanted to be fast, was built-in to it and therefore makes it > possible to be streamlined? > as a mechanism hints to potymisers are some advantage - i was angry on putting this in the context of (a bit dumbish) language comparisons, and a time waste that is related to that I like to talk some subject matter not read posts that are endless presentations of (a bit dumbish) belifs In this topic i ask about some interesting informations about some solutions maybe better than c ones, God save me form belifs expressors
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-17 21:18 +0000 |
| Message-ID | <9lAuw.205227$I4.134647@fx34.am4> |
| In reply to | #56397 |
On 17/01/2015 21:01, fir wrote: > W dniu sobota, 17 stycznia 2015 21:36:50 UTC+1 użytkownik Bart napisał: >> On 17/01/2015 20:06, fir wrote: >>>> >>>> you could compare language mechanisms, >>>> should stay away on comparing libraries >>>> >>> i wanted to say 'discuss language mechanisms' not damn compare >>> >> >> OK. Language mechanisms for doing what? >> >> And what was wrong with my example? >> >> Would you reject a language that was faster than C, because the exact >> feature you wanted to be fast, was built-in to it and therefore makes it >> possible to be streamlined? >> > as a mechanism hints to potymisers are some advantage - i was angry on putting this in the context of (a bit dumbish) language comparisons, and a time waste that is related to that > I like to talk some subject matter not > read posts that are endless presentations of (a bit dumbish) > belifs > > In this topic i ask about some interesting informations about some solutions maybe better than c ones, > God save me form belifs expressors > Solutions to what? Give us a concrete problem, not some vague, open-ended ones that in the end you say are of no interest to you, then maybe someone can give you a concrete solution too! (Which you will then proceed to shoot down.) Are you interested in an existing language, or you creating your own? (If the latter, then good luck with that.) With existing HLL languages, you're not going to get anything significantly faster than C, because C compiler optimisers do such a good job. But if someone tries to discuss the situations where a different language might be faster, then you shoot /them/ down! And are you interested in existing libraries, or not? If not, why not? Or are you just after some magic combination of gcc optimiser flags? It's very difficult to figure what you're after. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 13:36 -0800 |
| Message-ID | <bdf06552-7f7d-4242-b9f4-21f99d4531ef@googlegroups.com> |
| In reply to | #56398 |
W dniu sobota, 17 stycznia 2015 22:19:10 UTC+1 użytkownik Bart napisał: > On 17/01/2015 21:01, fir wrote: > > W dniu sobota, 17 stycznia 2015 21:36:50 UTC+1 użytkownik Bart napisał: > >> On 17/01/2015 20:06, fir wrote: > >>>> > >>>> you could compare language mechanisms, > >>>> should stay away on comparing libraries > >>>> > >>> i wanted to say 'discuss language mechanisms' not damn compare > >>> > >> > >> OK. Language mechanisms for doing what? > >> > >> And what was wrong with my example? > >> > >> Would you reject a language that was faster than C, because the exact > >> feature you wanted to be fast, was built-in to it and therefore makes it > >> possible to be streamlined? > >> > > as a mechanism hints to potymisers are some advantage - i was angry on putting this in the context of (a bit dumbish) language comparisons, and a time waste that is related to that > > I like to talk some subject matter not > > read posts that are endless presentations of (a bit dumbish) > > belifs > > > > In this topic i ask about some interesting informations about some solutions maybe better than c ones, > > God save me form belifs expressors > > > > Solutions to what? Give us a concrete problem, not some vague, > open-ended ones that in the end you say are of no interest to you, then > maybe someone can give you a concrete solution too! (Which you will then > proceed to shoot down.) > > Are you interested in an existing language, or you creating your own? > (If the latter, then good luck with that.) > > With existing HLL languages, you're not going to get anything > significantly faster than C, because C compiler optimisers do such a > good job. But if someone tries to discuss the situations where a > different language might be faster, then you shoot /them/ down! > > And are you interested in existing libraries, or not? If not, why not? > > Or are you just after some magic combination of gcc optimiser flags? > > It's very difficult to figure what you're after. > you seem to understand usage of usenet other then i (do not want to write to much on this as i feel i wasted to much time today) in general i state some topic not primary to 'help me' but as a some subject to exchange opinions, informations etc; My post text is more to specify what i got on my mind (sometimes it is maybe to much narrow,'sometimes it may be to open) this tim ei was curious if someone heard about some language elements that make some techniques that are possibly maybe bit faster (in runtime) than those in c - maybe some oryginal contepts i was not heard of nobady knows, alright, you can skip this thread (as i probably do and move to another, i got no so much time and many topics to work on)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 11:17 +0100 |
| Message-ID | <m9iljj$j74$1@dont-email.me> |
| In reply to | #56401 |
On 17/01/15 22:36, fir wrote: > W dniu sobota, 17 stycznia 2015 22:19:10 UTC+1 użytkownik Bart > napisał: >> On 17/01/2015 21:01, fir wrote: >>> W dniu sobota, 17 stycznia 2015 21:36:50 UTC+1 użytkownik Bart >>> napisał: >>>> On 17/01/2015 20:06, fir wrote: >>>>>> >>>>>> you could compare language mechanisms, should stay away on >>>>>> comparing libraries >>>>>> >>>>> i wanted to say 'discuss language mechanisms' not damn >>>>> compare >>>>> >>>> >>>> OK. Language mechanisms for doing what? >>>> >>>> And what was wrong with my example? >>>> >>>> Would you reject a language that was faster than C, because the >>>> exact feature you wanted to be fast, was built-in to it and >>>> therefore makes it possible to be streamlined? >>>> >>> as a mechanism hints to potymisers are some advantage - i was >>> angry on putting this in the context of (a bit dumbish) language >>> comparisons, and a time waste that is related to that I like to >>> talk some subject matter not read posts that are endless >>> presentations of (a bit dumbish) belifs >>> >>> In this topic i ask about some interesting informations about >>> some solutions maybe better than c ones, God save me form belifs >>> expressors >>> >> >> Solutions to what? Give us a concrete problem, not some vague, >> open-ended ones that in the end you say are of no interest to you, >> then maybe someone can give you a concrete solution too! (Which you >> will then proceed to shoot down.) >> >> Are you interested in an existing language, or you creating your >> own? (If the latter, then good luck with that.) >> >> With existing HLL languages, you're not going to get anything >> significantly faster than C, because C compiler optimisers do such >> a good job. But if someone tries to discuss the situations where a >> different language might be faster, then you shoot /them/ down! >> >> And are you interested in existing libraries, or not? If not, why >> not? >> >> Or are you just after some magic combination of gcc optimiser >> flags? >> >> It's very difficult to figure what you're after. >> > you seem to understand usage of usenet other then i (do not want to > write to much on this as i feel i wasted to much time today) > > in general i state some topic not primary to 'help me' but as a some > subject to exchange opinions, informations etc; My post text is more > to specify what i got on my mind (sometimes it is maybe to much > narrow,'sometimes it may be to open) You asked a very open question, phrased in a language that was gibberish even by /your/ impressive standards, and then you get "angry" because people are having a discussion based on that question? I think Bart is not alone in having a different understanding of Usenet from you. > > this tim ei was curious if someone heard about some language elements > that make some techniques that are possibly maybe bit faster (in > runtime) than those in c - maybe some oryginal contepts i was not > heard of > I can think of one concept that is not supported by C or by many other low-level languages - coroutines. I have not used them myself, so I can't tell you what sort of tasks would be more efficient with coroutines, but certainly some tasks are more elegantly implemented using them.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-01-19 10:40 +0000 |
| Message-ID | <Da5vw.162959$re.156223@fx40.am4> |
| In reply to | #56461 |
David Brown wrote: > On 17/01/15 22:36, fir wrote: <snip> >> you seem to understand usage of usenet other then i (do not want to >> write to much on this as i feel i wasted to much time today) >> >> in general i state some topic not primary to 'help me' but as a some >> subject to exchange opinions, informations etc; My post text is more >> to specify what i got on my mind (sometimes it is maybe to much >> narrow,'sometimes it may be to open) > > You asked a very open question, phrased in a language that was gibberish > even by /your/ impressive standards, and then you get "angry" because > people are having a discussion based on that question? I think Bart is > not alone in having a different understanding of Usenet from you. By calling into question his ability to use Usenet effectively, you reveal yourself to be ignorant, unintelligent, offensive, insulting, and a waster of his time. (Join the club.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-19 03:29 -0800 |
| Message-ID | <e077e698-0e8a-44af-b195-0f5c9ae5598e@googlegroups.com> |
| In reply to | #56463 |
W dniu poniedziałek, 19 stycznia 2015 11:40:45 UTC+1 użytkownik Richard Heathfield napisał: > David Brown wrote: > > > On 17/01/15 22:36, fir wrote: > > <snip> > >> you seem to understand usage of usenet other then i (do not want to > >> write to much on this as i feel i wasted to much time today) > >> > >> in general i state some topic not primary to 'help me' but as a some > >> subject to exchange opinions, informations etc; My post text is more > >> to specify what i got on my mind (sometimes it is maybe to much > >> narrow,'sometimes it may be to open) > > > > You asked a very open question, phrased in a language that was gibberish > > even by /your/ impressive standards, and then you get "angry" because > > people are having a discussion based on that question? I think Bart is > > not alone in having a different understanding of Usenet from you. > > By calling into question his ability to use Usenet effectively, you reveal > yourself to be ignorant, unintelligent, offensive, insulting, and a waster > of his time. > > (Join the club.) > yea the club of "boring and weak fiction" writers, (yawn) your skills of holding truth in "statement chains" is a bit damaged ps im not such bored to go further in "the works of ritchard heathfield" though it remembers me some english tv emmision from glasworthy/forsythe saga, (nice memory but probably not much related ;/
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-19 03:41 -0800 |
| Message-ID | <4b9458ed-5d93-462a-9757-ee881192e378@googlegroups.com> |
| In reply to | #56461 |
W dniu poniedziałek, 19 stycznia 2015 11:18:01 UTC+1 użytkownik David Brown napisał:
> I can think of one concept that is not supported by C or by many other
> low-level languages - coroutines. I have not used them myself, so I
> can't tell you what sort of tasks would be more efficient with
> coroutines, but certainly some tasks are more elegantly implemented
> using them.
i was thinking about this recently,
on c level coroutines could probably look like
f(){ return; }
g() { ... f(); ... }
(to quote godek from pl.comp.lng.c who was recently talking about this)
where f return makes return from g
not sure as to efficiency-gain and usability of this
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 12:45 +0100 |
| Message-ID | <m9iqnv$6qg$1@dont-email.me> |
| In reply to | #56465 |
On 19/01/15 12:41, fir wrote:
> W dniu poniedziałek, 19 stycznia 2015 11:18:01 UTC+1 użytkownik David Brown napisał:
>
>> I can think of one concept that is not supported by C or by many other
>> low-level languages - coroutines. I have not used them myself, so I
>> can't tell you what sort of tasks would be more efficient with
>> coroutines, but certainly some tasks are more elegantly implemented
>> using them.
>
> i was thinking about this recently,
> on c level coroutines could probably look like
>
> f(){ return; }
> g() { ... f(); ... }
>
> (to quote godek from pl.comp.lng.c who was recently talking about this)
>
> where f return makes return from g
>
> not sure as to efficiency-gain and usability of this
>
That is how subroutines ("functions" in C) work, not coroutines.
Coroutines look like:
f() { ... yield to g ... }
g() { ... yield to f ... }
with the "yields" returning to the middle of the functions, rather than
the start.
Coroutines are more like a set of cooperative multi-tasking threads,
except that it is the coroutines (and not a scheduler) which control who
runs after a "yield", and they can pass data back and forth.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-19 04:00 -0800 |
| Message-ID | <b8cd8dd8-f697-4178-9586-4de98f6b612d@googlegroups.com> |
| In reply to | #56466 |
W dniu poniedziałek, 19 stycznia 2015 12:45:41 UTC+1 użytkownik David Brown napisał:
> On 19/01/15 12:41, fir wrote:
> > W dniu poniedziałek, 19 stycznia 2015 11:18:01 UTC+1 użytkownik David Brown napisał:
> >
> >> I can think of one concept that is not supported by C or by many other
> >> low-level languages - coroutines. I have not used them myself, so I
> >> can't tell you what sort of tasks would be more efficient with
> >> coroutines, but certainly some tasks are more elegantly implemented
> >> using them.
> >
> > i was thinking about this recently,
> > on c level coroutines could probably look like
> >
> > f(){ return; }
> > g() { ... f(); ... }
> >
> > (to quote godek from pl.comp.lng.c who was recently talking about this)
> >
> > where f return makes return from g
> >
> > not sure as to efficiency-gain and usability of this
> >
>
> That is how subroutines ("functions" in C) work, not coroutines.
> Coroutines look like:
>
> f() { ... yield to g ... }
> g() { ... yield to f ... }
>
> with the "yields" returning to the middle of the functions, rather than
> the start.
>
you mean like g() has some labels:
in various parts of code,
void g()
{
l1:
l2:
l3:
l4:
}
and some state variable that it updates with some label value on return , and makes goto/jump
on entry of another call?
void g()
{
static void* state = L1;
jump(state); // something like goto
L1:
state = L2;
return;
L2:
L3:
L4:
}
the idea of such kind of goto is fine imo (remember i was already talking here about possibly more support for goto in c back then)
> Coroutines are more like a set of cooperative multi-tasking threads,
> except that it is the coroutines (and not a scheduler) which control who
> runs after a "yield", and they can pass data back and forth.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-19 04:31 -0800 |
| Message-ID | <7da2434a-4783-487d-aff1-85a5c9cce8a9@googlegroups.com> |
| In reply to | #56468 |
W dniu poniedziałek, 19 stycznia 2015 13:00:46 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 19 stycznia 2015 12:45:41 UTC+1 użytkownik David Brown napisał:
> > On 19/01/15 12:41, fir wrote:
> > > W dniu poniedziałek, 19 stycznia 2015 11:18:01 UTC+1 użytkownik David Brown napisał:
> > >
> > >> I can think of one concept that is not supported by C or by many other
> > >> low-level languages - coroutines. I have not used them myself, so I
> > >> can't tell you what sort of tasks would be more efficient with
> > >> coroutines, but certainly some tasks are more elegantly implemented
> > >> using them.
> > >
> > > i was thinking about this recently,
> > > on c level coroutines could probably look like
> > >
> > > f(){ return; }
> > > g() { ... f(); ... }
> > >
> > > (to quote godek from pl.comp.lng.c who was recently talking about this)
> > >
> > > where f return makes return from g
> > >
> > > not sure as to efficiency-gain and usability of this
> > >
> >
> > That is how subroutines ("functions" in C) work, not coroutines.
> > Coroutines look like:
> >
> > f() { ... yield to g ... }
> > g() { ... yield to f ... }
> >
> > with the "yields" returning to the middle of the functions, rather than
> > the start.
> >
>
> you mean like g() has some labels:
> in various parts of code,
>
> void g()
> {
> l1:
>
> l2:
>
> l3:
>
> l4:
>
> }
>
> and some state variable that it updates with some label value on return , and makes goto/jump
> on entry of another call?
>
>
> void g()
> {
> static void* state = L1;
>
> jump(state); // something like goto
>
> L1:
> state = L2;
> return;
> L2:
>
> L3:
>
> L4:
>
> }
>
> the idea of such kind of goto is fine imo (remember i was already talking here about possibly more support for goto in c back then)
>
> > Coroutines are more like a set of cooperative multi-tasking threads,
> > except that it is the coroutines (and not a scheduler) which control who
> > runs after a "yield", and they can pass data back and forth.
some thought if it (such goto) could bring c efficiency gain:
probably in some cases this could allow for example the replacing of switch by jump table, switch could be optymised sometimes by values table or function pointers table but this may be a bit more convenient in some cases
- so indeed it seems that could possibly maybe give some gain (at all seem to be good idea imo)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-19 04:48 -0800 |
| Message-ID | <40f79fdb-18ce-4841-abd6-5a5c3c1ce115@googlegroups.com> |
| In reply to | #56469 |
W dniu poniedziałek, 19 stycznia 2015 13:31:39 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 19 stycznia 2015 13:00:46 UTC+1 użytkownik fir napisał:
> > W dniu poniedziałek, 19 stycznia 2015 12:45:41 UTC+1 użytkownik David Brown napisał:
> > > On 19/01/15 12:41, fir wrote:
> > > > W dniu poniedziałek, 19 stycznia 2015 11:18:01 UTC+1 użytkownik David Brown napisał:
> > > >
> > > >> I can think of one concept that is not supported by C or by many other
> > > >> low-level languages - coroutines. I have not used them myself, so I
> > > >> can't tell you what sort of tasks would be more efficient with
> > > >> coroutines, but certainly some tasks are more elegantly implemented
> > > >> using them.
> > > >
> > > > i was thinking about this recently,
> > > > on c level coroutines could probably look like
> > > >
> > > > f(){ return; }
> > > > g() { ... f(); ... }
> > > >
> > > > (to quote godek from pl.comp.lng.c who was recently talking about this)
> > > >
> > > > where f return makes return from g
> > > >
> > > > not sure as to efficiency-gain and usability of this
> > > >
> > >
> > > That is how subroutines ("functions" in C) work, not coroutines.
> > > Coroutines look like:
> > >
> > > f() { ... yield to g ... }
> > > g() { ... yield to f ... }
> > >
> > > with the "yields" returning to the middle of the functions, rather than
> > > the start.
> > >
> >
> > you mean like g() has some labels:
> > in various parts of code,
> >
> > void g()
> > {
> > l1:
> >
> > l2:
> >
> > l3:
> >
> > l4:
> >
> > }
> >
> > and some state variable that it updates with some label value on return , and makes goto/jump
> > on entry of another call?
> >
> >
> > void g()
> > {
> > static void* state = L1;
> >
> > jump(state); // something like goto
> >
> > L1:
> > state = L2;
> > return;
> > L2:
> >
> > L3:
> >
> > L4:
> >
> > }
> >
> > the idea of such kind of goto is fine imo (remember i was already talking here about possibly more support for goto in c back then)
> >
> > > Coroutines are more like a set of cooperative multi-tasking threads,
> > > except that it is the coroutines (and not a scheduler) which control who
> > > runs after a "yield", and they can pass data back and forth.
>
> some thought if it (such goto) could bring c efficiency gain:
>
> probably in some cases this could allow for example the replacing of switch by jump table, switch could be optymised sometimes by values table or function pointers table but this may be a bit more convenient in some cases
> - so indeed it seems that could possibly maybe give some gain (at all seem to be good idea imo)
on the other side i am not sure if static if switch is not able to help
branch predictor to take some optymisation routes on static jmp's
- maybe such intermediate jumps by pointers would tear this predictions, dowm?
(anyway as i said i consider this good idea at least for improved c code expressibility, improve c expressability is easier than improve c efficiency ;o though)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-01-19 15:23 +0100 |
| Message-ID | <m9j40k$9tt$1@dont-email.me> |
| In reply to | #56468 |
On 19/01/15 13:00, fir wrote:
> W dniu poniedziałek, 19 stycznia 2015 12:45:41 UTC+1 użytkownik David Brown napisał:
>> On 19/01/15 12:41, fir wrote:
<snip>
>> That is how subroutines ("functions" in C) work, not coroutines.
>> Coroutines look like:
>>
>> f() { ... yield to g ... }
>> g() { ... yield to f ... }
>>
>> with the "yields" returning to the middle of the functions, rather than
>> the start.
>>
>
> you mean like g() has some labels:
> in various parts of code,
>
Rather than making a series of random guesses, then posting increasingly
confused and misguided followups, why don't you read the Wikipedia
article on coroutines and start from there? When you have an idea of
what they are, you can think about how they might be used to improve
software design in a language that has full support for them.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web