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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-01-20 14:18 +0100 |
| Message-ID | <20150120141823.4077a84e@maxa-pc> |
| In reply to | #56517 |
On Tue, 20 Jan 2015 05:16:26 -0800 (PST) asetofsymbols@gmail.com wrote: > Fir wrote: > >not so sure thing - each core cost > >watts, if you have 4 cores 16 cores > > would cost 4 times more watts, > >thus it may be for example the most > >pewople could get in next rest of > >your life(if not less) > > In future the calculus power will increase as > exponential [is it the Moore law?] but not > because it increasing the clock time... > > I imagines one future where in the place of a single > cpu will be 100 cpu etc so the limit will be > parallelize algorithms and success languages will be > the ones can parallelise better algo... > But possibly nobody will search the speed in > execution code or possible, programmers not longer > exist because machine will program they self... > or anyone will program in some HIPERTHRADBASIC > program language as someone said, that does all > better than a nowadays programmer There is no algorithm for making algorithms....
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-01-20 15:29 -0600 |
| Message-ID | <dthtbad5int4kf5nerdeo82pp1bdngpn8u@4ax.com> |
| In reply to | #56518 |
On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote: >On Tue, 20 Jan 2015 05:16:26 -0800 (PST) >asetofsymbols@gmail.com wrote: > >> Fir wrote: >> >not so sure thing - each core cost >> >watts, if you have 4 cores 16 cores >> > would cost 4 times more watts, >> >thus it may be for example the most >> >pewople could get in next rest of >> >your life(if not less) >> >> In future the calculus power will increase as >> exponential [is it the Moore law?] but not >> because it increasing the clock time... >> >> I imagines one future where in the place of a single >> cpu will be 100 cpu etc so the limit will be >> parallelize algorithms and success languages will be >> the ones can parallelise better algo... >> But possibly nobody will search the speed in >> execution code or possible, programmers not longer >> exist because machine will program they self... >> or anyone will program in some HIPERTHRADBASIC >> program language as someone said, that does all >> better than a nowadays programmer > >There is no algorithm for making algorithms.... Perhaps no efficient algorithms... If you can write a formal specification, and create a decent set of test cases, just try all the possible programs (a finite number, after all), that will fit on your machine, and use a verifier to see if that program actually meets the spec. For any that do, benchmark them, and then pick the fastest. And there are certainly optimizations we can apply to that process, not that it's anywhere near practical yet.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-01-20 21:53 +0000 |
| Message-ID | <d7Avw.209008$ls6.15242@fx16.am4> |
| In reply to | #56529 |
Robert Wessel wrote: > On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote: > <snip> >> >>There is no algorithm for making algorithms.... > > > Perhaps no efficient algorithms... > > If you can write a formal specification, and create a decent set of > test cases, just try all the possible programs (a finite number, after > all), that will fit on your machine, and use a verifier to see if that > program actually meets the spec. For example, if your computer only has 32 octets of RAM (no, not GB, not MB, not KB, just 32 octets, or 256 bits) say, a ZX-81 after a rather serious lobotomy), you only have to test 115792 million million million million million million million million million million million million programs. If you can verify them at the rate of a million million million million per second, it will only take an average of 1834614945960976047347881096925747012657331113 years to find the solution (if a solution exists), or twice that to demonstrate that there is no solution in the available RAM. If you have 257 bits, double the above numbers. If you have 258, double them again. And so on. > For any that do, benchmark them, and > then pick the fastest. Oh, good point - there might be more than one solution, in which case the average case calc above is a little simplistic. Nevertheless, I think we can safely assume that the heat death of the universe will precede a valid solution by many orders of magnitude. > And there are certainly optimizations we can > apply to that process, not that it's anywhere near practical yet. Assuming we can automatically verify one solution candidate per nanosecond, and assuming we're prepared to wait no longer than one year, we're limited to solutions that are no longer than 54 bits. You can do a surprising amount in 54 bits if you're clever. Even so, I don't think this technique is going to fly any time soon. :-) -- 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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-01-20 17:37 -0600 |
| Message-ID | <t9otba5uj8incgj6db79pvfdvd2rn69fla@4ax.com> |
| In reply to | #56531 |
On Tue, 20 Jan 2015 21:53:12 +0000, Richard Heathfield <invalid@see.sig.invalid> wrote: >Robert Wessel wrote: > >> On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote: >> ><snip> >>> >>>There is no algorithm for making algorithms.... >> >> >> Perhaps no efficient algorithms... >> >> If you can write a formal specification, and create a decent set of >> test cases, just try all the possible programs (a finite number, after >> all), that will fit on your machine, and use a verifier to see if that >> program actually meets the spec. > >For example, if your computer only has 32 octets of RAM (no, not GB, not MB, >not KB, just 32 octets, or 256 bits) say, a ZX-81 after a rather serious >lobotomy), you only have to test 115792 million million million million >million million million million million million million million programs. If >you can verify them at the rate of a million million million million per >second, it will only take an average of >1834614945960976047347881096925747012657331113 years to find the solution >(if a solution exists), or twice that to demonstrate that there is no >solution in the available RAM. If you have 257 bits, double the above >numbers. If you have 258, double them again. And so on. > >> For any that do, benchmark them, and >> then pick the fastest. > >Oh, good point - there might be more than one solution, in which case the >average case calc above is a little simplistic. Nevertheless, I think we can >safely assume that the heat death of the universe will precede a valid >solution by many orders of magnitude. > >> And there are certainly optimizations we can >> apply to that process, not that it's anywhere near practical yet. > >Assuming we can automatically verify one solution candidate per nanosecond, >and assuming we're prepared to wait no longer than one year, we're limited >to solutions that are no longer than 54 bits. > >You can do a surprising amount in 54 bits if you're clever. Even so, I don't >think this technique is going to fly any time soon. :-) Sure, although I though the bit about this being utterly *impractical* was obvious. Melzzzz' statement was that there were *no* algorithms, not a lack of practical ones. As an analogy, there are no algorithms for cracking a properly implement one-time-pad, and never will be. Such a thing provable does not exist. OTOH, cracking AES-256 with a brute force attack is conceptually trivial. Heck the actual program to do so is pretty simple too. It just won't finish while this universe still has meaningful existence. But there *is* a known algorithm. And further, we don't know that that's actually the best algorithm for cracking AES, and all sort of things might be discovered in the future. In fact many such possible improvements for the program finder *are* obvious. For example, if we're generating x86 code as programs, not all bit patterns are sensible, even over short sections. We have everything from illegal instructions, to non-sensical instruction combinations (mov ax,bx / mov ax,cx), and so on, which as a rough guess reduce the possible entropy of an x86 program to no more than about .5 bits/bit. Writing a generator for that, that would short circuit expansions including the bad combinations, would not be hard either. And if we were limiting ourselves to programs with 2MB of program text, that reduces the numbers of cases we have to consider from 2**16777216 to a "mere" 2**8388608. I'd say that reducing the work by some 2.5 million orders of magnitude in a few minutes at least hints that further substantial reductions are possible. Exercise left to the reader. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-01-21 00:05 +0000 |
| Message-ID | <g3Cvw.223891$xe1.149299@fx47.am4> |
| In reply to | #56532 |
Robert Wessel wrote:
> On Tue, 20 Jan 2015 21:53:12 +0000, Richard Heathfield
> <invalid@see.sig.invalid> wrote:
>
>>Robert Wessel wrote:
>>
>>> On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote:
>>>
>><snip>
>>>>
>>>>There is no algorithm for making algorithms....
>>>
>>>
>>> Perhaps no efficient algorithms...
>>>
>>> If you can write a formal specification, and create a decent set of
>>> test cases, just try all the possible programs (a finite number, after
>>> all), that will fit on your machine, and use a verifier to see if that
>>> program actually meets the spec.
>>
>>For example, if your computer only has 32 octets of RAM (no, not GB, not
>>MB, not KB, just 32 octets, or 256 bits) say, a ZX-81 after a rather
>>serious lobotomy), you only have to test 115792 million million million
>>million million million million million million million million million
>>programs. If you can verify them at the rate of a million million million
>>million per second, it will only take an average of
>>1834614945960976047347881096925747012657331113 years to find the solution
>>(if a solution exists), or twice that to demonstrate that there is no
>>solution in the available RAM. If you have 257 bits, double the above
>>numbers. If you have 258, double them again. And so on.
>>
>>> For any that do, benchmark them, and
>>> then pick the fastest.
>>
>>Oh, good point - there might be more than one solution, in which case the
>>average case calc above is a little simplistic. Nevertheless, I think we
>>can safely assume that the heat death of the universe will precede a valid
>>solution by many orders of magnitude.
>>
>>> And there are certainly optimizations we can
>>> apply to that process, not that it's anywhere near practical yet.
>>
>>Assuming we can automatically verify one solution candidate per
>>nanosecond, and assuming we're prepared to wait no longer than one year,
>>we're limited to solutions that are no longer than 54 bits.
>>
>>You can do a surprising amount in 54 bits if you're clever. Even so, I
>>don't think this technique is going to fly any time soon. :-)
>
>
> Sure, although I though the bit about this being utterly *impractical*
> was obvious.
Well, I knew *you* knew that, but I'm not completely convinced that your
entire readership knew that.
> Melzzzz' statement was that there were *no* algorithms, not a lack of
> practical ones.
Your algorithm *is* practical (admittedly only on very, very, very small
computers).
> As an analogy, there are no algorithms for cracking a properly
> implement one-time-pad, and never will be. Such a thing provable does
> not exist.
I'm not sure that Tom Clancy would have agreed with you.
<snip>
> And if we were limiting ourselves to programs with 2MB of program
> text, that reduces the numbers of cases we have to consider from
> 2**16777216 to a "mere" 2**8388608. I'd say that reducing the work by
> some 2.5 million orders of magnitude in a few minutes at least hints
> that further substantial reductions are possible.
>
> Exercise left to the reader. ;-)
I'll get right onto that, just as soon as my previous test program runs to
completion. Here it is:
#include <stdio.h>
int main(void)
{
for(;;);
puts("Test complete.");
return 0;
}
So far, it's been running for about fifteen years, possibly because I forgot
to use gcc's -O3 switch.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-01-21 01:38 -0600 |
| Message-ID | <lglubapqvgbmlff4hiegsdtmd24u8ufhjb@4ax.com> |
| In reply to | #56533 |
On Wed, 21 Jan 2015 00:05:31 +0000, Richard Heathfield <invalid@see.sig.invalid> wrote: >Robert Wessel wrote: > >> On Tue, 20 Jan 2015 21:53:12 +0000, Richard Heathfield >> <invalid@see.sig.invalid> wrote: >> >>>Robert Wessel wrote: >>> >>>> On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote: >>>> >>><snip> >>>>> >>>>>There is no algorithm for making algorithms.... >>>> >>>> >>>> Perhaps no efficient algorithms... >>>> >>>> If you can write a formal specification, and create a decent set of >>>> test cases, just try all the possible programs (a finite number, after >>>> all), that will fit on your machine, and use a verifier to see if that >>>> program actually meets the spec. >>> >>>For example, if your computer only has 32 octets of RAM (no, not GB, not >>>MB, not KB, just 32 octets, or 256 bits) say, a ZX-81 after a rather >>>serious lobotomy), you only have to test 115792 million million million >>>million million million million million million million million million >>>programs. If you can verify them at the rate of a million million million >>>million per second, it will only take an average of >>>1834614945960976047347881096925747012657331113 years to find the solution >>>(if a solution exists), or twice that to demonstrate that there is no >>>solution in the available RAM. If you have 257 bits, double the above >>>numbers. If you have 258, double them again. And so on. >>> >>>> For any that do, benchmark them, and >>>> then pick the fastest. >>> >>>Oh, good point - there might be more than one solution, in which case the >>>average case calc above is a little simplistic. Nevertheless, I think we >>>can safely assume that the heat death of the universe will precede a valid >>>solution by many orders of magnitude. >>> >>>> And there are certainly optimizations we can >>>> apply to that process, not that it's anywhere near practical yet. >>> >>>Assuming we can automatically verify one solution candidate per >>>nanosecond, and assuming we're prepared to wait no longer than one year, >>>we're limited to solutions that are no longer than 54 bits. >>> >>>You can do a surprising amount in 54 bits if you're clever. Even so, I >>>don't think this technique is going to fly any time soon. :-) >> >> >> Sure, although I though the bit about this being utterly *impractical* >> was obvious. > >Well, I knew *you* knew that, but I'm not completely convinced that your >entire readership knew that. > >> Melzzzz' statement was that there were *no* algorithms, not a lack of >> practical ones. > >Your algorithm *is* practical (admittedly only on very, very, very small >computers). And people have actually done just that for very short segments of code. "Peephole superoptimization".
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-01-21 07:46 +0000 |
| Message-ID | <NPIvw.390991$BB2.65913@fx35.am4> |
| In reply to | #56541 |
Robert Wessel wrote: > On Wed, 21 Jan 2015 00:05:31 +0000, Richard Heathfield > <invalid@see.sig.invalid> wrote: > >>Robert Wessel wrote: <snip> >>> Melzzzz' statement was that there were *no* algorithms, not a lack of >>> practical ones. >> >>Your algorithm *is* practical (admittedly only on very, very, very small >>computers). > > > And people have actually done just that for very short segments of > code. "Peephole superoptimization". We have also found ways to improve on brute force. Normally these techniques are applied to data, but what is a program if not data? One obvious example is the Genetic Algorithm. (Instead of trying everything, try stuff that seems to work, and try to make it work better by combining it with some other stuff that also seems to work.) -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-01-21 03:23 -0800 |
| Message-ID | <74f50106-5515-4010-bf2f-807a70bd5efa@googlegroups.com> |
| In reply to | #56542 |
On Wednesday, January 21, 2015 at 7:47:02 AM UTC, Richard Heathfield wrote: > > One obvious example is the Genetic Algorithm. (Instead of trying everything, > try stuff that seems to work, and try to make it work better by combining it > with some other stuff that also seems to work.) > That's the answer. You need to be able to represent your solution so that approximately correct answers can be recognised and scored, and such that changes can be made which have a small effect on the result, and so that all or at least a wide selection of possible states are accessible via incremental small changes. All of those are difficult.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-01-21 13:52 +0000 |
| Message-ID | <zaOvw.390998$BB2.262964@fx35.am4> |
| In reply to | #56543 |
Malcolm McLean wrote: > On Wednesday, January 21, 2015 at 7:47:02 AM UTC, Richard Heathfield > wrote: >> >> One obvious example is the Genetic Algorithm. (Instead of trying >> everything, try stuff that seems to work, and try to make it work better >> by combining it with some other stuff that also seems to work.) >> > That's the answer. > You need to be able to represent your solution Yes, but that's easy in this case - a straight bitmap will do fine, and the fitness function can mark down illegal bitmaps. > so that approximately > correct answers can be recognised and scored, and such that changes can be > made which have a small effect on the result, and so that all or at least > a wide selection of possible states are accessible via incremental small > changes. Actually, no. It doesn't have to be the case that small changes have small effects. You do have to be able to rank the answers, though, and /that/ is hard in the current instance. > All of those are difficult. Yes, but perhaps not impossible. -- 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 | Morris Dovey <mrdovey@iedu.com> |
|---|---|
| Date | 2015-01-21 08:53 -0600 |
| Message-ID | <m9oehi$dvl$1@speranza.aioe.org> |
| In reply to | #56543 |
On 1/21/15 5:23 AM, Malcolm McLean wrote: > On Wednesday, January 21, 2015 at 7:47:02 AM UTC, Richard Heathfield > wrote: >> >> One obvious example is the Genetic Algorithm. (Instead of trying >> everything, try stuff that seems to work, and try to make it work >> better by combining it with some other stuff that also seems to >> work.) >> > That's the answer. You need to be able to represent your solution so > that approximately correct answers can be recognised and scored, and > such that changes can be made which have a small effect on the > result, and so that all or at least a wide selection of possible > states are accessible via incremental small changes. > > All of those are difficult. Yes, but let's note that "difficulty" is subjective. I would like to suggest that the process you describe becomes easier with practice. -- Morris Dovey http://www.iedu.com/Solar/
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-01-21 01:18 +0100 |
| Message-ID | <20150121011859.44704d46@maxa-pc> |
| In reply to | #56529 |
On Tue, 20 Jan 2015 15:29:58 -0600 Robert Wessel <robertwessel2@yahoo.com> wrote: > On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote: > > >On Tue, 20 Jan 2015 05:16:26 -0800 (PST) > >asetofsymbols@gmail.com wrote: > > > >> Fir wrote: > >> >not so sure thing - each core cost > >> >watts, if you have 4 cores 16 cores > >> > would cost 4 times more watts, > >> >thus it may be for example the most > >> >pewople could get in next rest of > >> >your life(if not less) > >> > >> In future the calculus power will increase as > >> exponential [is it the Moore law?] but not > >> because it increasing the clock time... > >> > >> I imagines one future where in the place of a single > >> cpu will be 100 cpu etc so the limit will be > >> parallelize algorithms and success languages will be > >> the ones can parallelise better algo... > >> But possibly nobody will search the speed in > >> execution code or possible, programmers not longer > >> exist because machine will program they self... > >> or anyone will program in some HIPERTHRADBASIC > >> program language as someone said, that does all > >> better than a nowadays programmer > > > >There is no algorithm for making algorithms.... > > > Perhaps no efficient algorithms... > > If you can write a formal specification, and create a decent set of > test cases, just try all the possible programs (a finite number, after > all), that will fit on your machine, and use a verifier to see if that > program actually meets the spec. For any that do, benchmark them, and > then pick the fastest. And there are certainly optimizations we can > apply to that process, not that it's anywhere near practical yet. > It never will be. All you can do is that, like chess engine. Thought is not algorithm, but it can make algorithm. I learned that in 1987 by my mathematics professor ;)
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2015-01-20 16:41 -0800 |
| Message-ID | <35cb4bfb-a530-458d-afba-f16f6892e4fe@googlegroups.com> |
| In reply to | #56534 |
On Wednesday, January 21, 2015 at 1:19:08 AM UTC+1, Melzzzzz wrote: > On Tue, 20 Jan 2015 15:29:58 -0600 > Robert Wessel <robertwessel2@yahoo.com> wrote: > > > On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> wrote: > > > > >On Tue, 20 Jan 2015 05:16:26 -0800 (PST) > > >asetofsymbols@gmail.com wrote: > > > > > >> Fir wrote: > > >> >not so sure thing - each core cost > > >> >watts, if you have 4 cores 16 cores > > >> > would cost 4 times more watts, > > >> >thus it may be for example the most > > >> >pewople could get in next rest of > > >> >your life(if not less) > > >> > > >> In future the calculus power will increase as > > >> exponential [is it the Moore law?] but not > > >> because it increasing the clock time... > > >> > > >> I imagines one future where in the place of a single > > >> cpu will be 100 cpu etc so the limit will be > > >> parallelize algorithms and success languages will be > > >> the ones can parallelise better algo... > > >> But possibly nobody will search the speed in > > >> execution code or possible, programmers not longer > > >> exist because machine will program they self... > > >> or anyone will program in some HIPERTHRADBASIC > > >> program language as someone said, that does all > > >> better than a nowadays programmer > > > > > >There is no algorithm for making algorithms.... > > > > > > Perhaps no efficient algorithms... > > > > If you can write a formal specification, and create a decent set of > > test cases, just try all the possible programs (a finite number, after > > all), that will fit on your machine, and use a verifier to see if that > > program actually meets the spec. For any that do, benchmark them, and > > then pick the fastest. And there are certainly optimizations we can > > apply to that process, not that it's anywhere near practical yet. > > > > It never will be. All you can do is that, like chess engine. > Thought is not algorithm, but it can make algorithm. > I learned that in 1987 by my mathematics professor ;) > It also depends on how you compare two different algorithms. If it's just the sequence of certain steps, or the number of states, or the number of instructions, then any compiler (with a decent level of optimizations) creates an brand-new algorithm each time based on the specifications given in a human-friendly language. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-01-21 01:58 +0100 |
| Message-ID | <20150121015815.4b3d8b15@maxa-pc> |
| In reply to | #56536 |
On Tue, 20 Jan 2015 16:41:01 -0800 (PST) fmassei@gmail.com wrote: > On Wednesday, January 21, 2015 at 1:19:08 AM UTC+1, Melzzzzz wrote: > > On Tue, 20 Jan 2015 15:29:58 -0600 > > Robert Wessel <robertwessel2@yahoo.com> wrote: > > > > > On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> > > > wrote: > > > > > > >On Tue, 20 Jan 2015 05:16:26 -0800 (PST) > > > >asetofsymbols@gmail.com wrote: > > > > > > > >> Fir wrote: > > > >> >not so sure thing - each core cost > > > >> >watts, if you have 4 cores 16 cores > > > >> > would cost 4 times more watts, > > > >> >thus it may be for example the most > > > >> >pewople could get in next rest of > > > >> >your life(if not less) > > > >> > > > >> In future the calculus power will increase as > > > >> exponential [is it the Moore law?] but not > > > >> because it increasing the clock time... > > > >> > > > >> I imagines one future where in the place of a single > > > >> cpu will be 100 cpu etc so the limit will be > > > >> parallelize algorithms and success languages will be > > > >> the ones can parallelise better algo... > > > >> But possibly nobody will search the speed in > > > >> execution code or possible, programmers not longer > > > >> exist because machine will program they self... > > > >> or anyone will program in some HIPERTHRADBASIC > > > >> program language as someone said, that does all > > > >> better than a nowadays programmer > > > > > > > >There is no algorithm for making algorithms.... > > > > > > > > > Perhaps no efficient algorithms... > > > > > > If you can write a formal specification, and create a decent set > > > of test cases, just try all the possible programs (a finite > > > number, after all), that will fit on your machine, and use a > > > verifier to see if that program actually meets the spec. For any > > > that do, benchmark them, and then pick the fastest. And there > > > are certainly optimizations we can apply to that process, not > > > that it's anywhere near practical yet. > > > > > > > It never will be. All you can do is that, like chess engine. > > Thought is not algorithm, but it can make algorithm. > > I learned that in 1987 by my mathematics professor ;) > > > > It also depends on how you compare two different algorithms. > If it's just the sequence of certain steps, or the number of states, > or the number of instructions, then any compiler (with a decent level > of optimizations) creates an brand-new algorithm each time based on > the specifications given in a human-friendly language. > > Ciao! Well, I don't think so. If you feed it with bubble sort it would not come up with quick sort ;)
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2015-01-20 17:11 -0800 |
| Message-ID | <2c016c12-bebc-47dc-b840-df8b123a7efc@googlegroups.com> |
| In reply to | #56537 |
On Wednesday, January 21, 2015 at 1:58:25 AM UTC+1, Melzzzzz wrote: > On Tue, 20 Jan 2015 16:41:01 -0800 (PST) > fmassei@gmail.com wrote: > > > On Wednesday, January 21, 2015 at 1:19:08 AM UTC+1, Melzzzzz wrote: > > > On Tue, 20 Jan 2015 15:29:58 -0600 > > > Robert Wessel <robertwessel2@yahoo.com> wrote: > > > > > > > On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> > > > > wrote: > > > > > > > > >On Tue, 20 Jan 2015 05:16:26 -0800 (PST) > > > > >asetofsymbols@gmail.com wrote: > > > > > > > > > >> Fir wrote: > > > > >> >not so sure thing - each core cost > > > > >> >watts, if you have 4 cores 16 cores > > > > >> > would cost 4 times more watts, > > > > >> >thus it may be for example the most > > > > >> >pewople could get in next rest of > > > > >> >your life(if not less) > > > > >> > > > > >> In future the calculus power will increase as > > > > >> exponential [is it the Moore law?] but not > > > > >> because it increasing the clock time... > > > > >> > > > > >> I imagines one future where in the place of a single > > > > >> cpu will be 100 cpu etc so the limit will be > > > > >> parallelize algorithms and success languages will be > > > > >> the ones can parallelise better algo... > > > > >> But possibly nobody will search the speed in > > > > >> execution code or possible, programmers not longer > > > > >> exist because machine will program they self... > > > > >> or anyone will program in some HIPERTHRADBASIC > > > > >> program language as someone said, that does all > > > > >> better than a nowadays programmer > > > > > > > > > >There is no algorithm for making algorithms.... > > > > > > > > > > > > Perhaps no efficient algorithms... > > > > > > > > If you can write a formal specification, and create a decent set > > > > of test cases, just try all the possible programs (a finite > > > > number, after all), that will fit on your machine, and use a > > > > verifier to see if that program actually meets the spec. For any > > > > that do, benchmark them, and then pick the fastest. And there > > > > are certainly optimizations we can apply to that process, not > > > > that it's anywhere near practical yet. > > > > > > > > > > It never will be. All you can do is that, like chess engine. > > > Thought is not algorithm, but it can make algorithm. > > > I learned that in 1987 by my mathematics professor ;) > > > > > > > It also depends on how you compare two different algorithms. > > If it's just the sequence of certain steps, or the number of states, > > or the number of instructions, then any compiler (with a decent level > > of optimizations) creates an brand-new algorithm each time based on > > the specifications given in a human-friendly language. > > > > Ciao! > > Well, I don't think so. If you feed it with bubble sort it would > not come up with quick sort ;) If you call qsort() in C, it "could" be that you will run a qsort - maybe not; it depends on what the compiler chooses (in fact, on little arrays, probably it will not). Even if you write "a=b;" the compiler could choose to look at the whole code and decide to write "b=a;" in the executable because it will be better. So: what makes an algorithm unique? Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-01-21 02:18 +0100 |
| Message-ID | <20150121021845.703ad476@maxa-pc> |
| In reply to | #56538 |
On Tue, 20 Jan 2015 17:11:27 -0800 (PST) fmassei@gmail.com wrote: > On Wednesday, January 21, 2015 at 1:58:25 AM UTC+1, Melzzzzz wrote: > > On Tue, 20 Jan 2015 16:41:01 -0800 (PST) > > fmassei@gmail.com wrote: > > > > > On Wednesday, January 21, 2015 at 1:19:08 AM UTC+1, Melzzzzz > > > wrote: > > > > On Tue, 20 Jan 2015 15:29:58 -0600 > > > > Robert Wessel <robertwessel2@yahoo.com> wrote: > > > > > > > > > On Tue, 20 Jan 2015 14:18:23 +0100, Melzzzzz <mel@zzzzz.com> > > > > > wrote: > > > > > > > > > > >On Tue, 20 Jan 2015 05:16:26 -0800 (PST) > > > > > >asetofsymbols@gmail.com wrote: > > > > > > > > > > > >> Fir wrote: > > > > > >> >not so sure thing - each core cost > > > > > >> >watts, if you have 4 cores 16 cores > > > > > >> > would cost 4 times more watts, > > > > > >> >thus it may be for example the most > > > > > >> >pewople could get in next rest of > > > > > >> >your life(if not less) > > > > > >> > > > > > >> In future the calculus power will increase as > > > > > >> exponential [is it the Moore law?] but not > > > > > >> because it increasing the clock time... > > > > > >> > > > > > >> I imagines one future where in the place of a single > > > > > >> cpu will be 100 cpu etc so the limit will be > > > > > >> parallelize algorithms and success languages will be > > > > > >> the ones can parallelise better algo... > > > > > >> But possibly nobody will search the speed in > > > > > >> execution code or possible, programmers not longer > > > > > >> exist because machine will program they self... > > > > > >> or anyone will program in some HIPERTHRADBASIC > > > > > >> program language as someone said, that does all > > > > > >> better than a nowadays programmer > > > > > > > > > > > >There is no algorithm for making algorithms.... > > > > > > > > > > > > > > > Perhaps no efficient algorithms... > > > > > > > > > > If you can write a formal specification, and create a decent > > > > > set of test cases, just try all the possible programs (a > > > > > finite number, after all), that will fit on your machine, and > > > > > use a verifier to see if that program actually meets the > > > > > spec. For any that do, benchmark them, and then pick the > > > > > fastest. And there are certainly optimizations we can apply > > > > > to that process, not that it's anywhere near practical yet. > > > > > > > > > > > > > It never will be. All you can do is that, like chess engine. > > > > Thought is not algorithm, but it can make algorithm. > > > > I learned that in 1987 by my mathematics professor ;) > > > > > > > > > > It also depends on how you compare two different algorithms. > > > If it's just the sequence of certain steps, or the number of > > > states, or the number of instructions, then any compiler (with a > > > decent level of optimizations) creates an brand-new algorithm > > > each time based on the specifications given in a human-friendly > > > language. > > > > > > Ciao! > > > > Well, I don't think so. If you feed it with bubble sort it would > > not come up with quick sort ;) > > If you call qsort() in C, it "could" be that you will run a qsort - > maybe not; it depends on what the compiler chooses (in fact, on > little arrays, probably it will not). qsort is library function. Compiler translate it as any other code... > Even if you write "a=b;" the compiler could choose to look at the > whole code and decide to write "b=a;" in the executable because it > will be better. > > So: what makes an algorithm unique? Im giving up... > > Ciao!
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2015-01-20 17:38 -0800 |
| Message-ID | <50a340f6-b298-4ef3-aa98-7bb8739c3ba1@googlegroups.com> |
| In reply to | #56539 |
On Wednesday, January 21, 2015 at 2:18:53 AM UTC+1, Melzzzzz wrote: > On Tue, 20 Jan 2015 17:11:27 -0800 (PST) > fmassei@gmail.com wrote: > > So: what makes an algorithm unique? > > Im giving up... > I don't know the answer either :) I've just a bunch of personal opinions that are far away from the formalism needed for the discussion. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-01-21 08:48 -0800 |
| Message-ID | <lnbnlsoz9n.fsf@nuthaus.mib.org> |
| In reply to | #56539 |
Melzzzzz <mel@zzzzz.com> writes:
[...]
>> If you call qsort() in C, it "could" be that you will run a qsort -
>> maybe not; it depends on what the compiler chooses (in fact, on
>> little arrays, probably it will not).
>
> qsort is library function. Compiler translate it as any other code...
qsort is a *standard* library function. Its behavior is defined by the
C standard, and a compiler may take advantage of that definition.
For example, a call like
printf("%d\n", 42);
might be compiled to code equivalent to
puts("42");
Optimization of a call to qsort would be more difficult, but in
principle it's perfectly possible.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-01-20 15:24 -0600 |
| Message-ID | <k5gtbalm5h8i84197n2hscv4g4826udsh2@4ax.com> |
| In reply to | #56514 |
On Tue, 20 Jan 2015 02:11:59 -0800 (PST), fmassei@gmail.com wrote: >On Tuesday, January 20, 2015 at 7:05:24 AM UTC+1, robert...@yahoo.com wrote: >> On Mon, 19 Jan 2015 03:58:26 -0800 (PST), fmassei@gmail.com wrote: >> > >> >I've used them recently in a high level framework: Unity. >> >As I understood it, the Unity developers had the problem that the rendering >> >steps have to be executed in a single thread, but they still had to give the >> >users some kind of event-driven framework. >> > >> >In general, I don't find coroutines so useful: it's just the lazy (or poor) >> >man alternative to pure multithreading. >> >> >> Nah, threads are a lazy (or poor) man's alterative to coroutines for >> most uses of threads. >> > >Well, they are two different paradigms, but given that "modern" languages >and systems give threads out of the box and coroutines are not easily >found at system-level, while multithreading in some cases could sound like >an overkill, the final result would be more clean and flexible for sure. It's really a shame. There are so many things that fit naturally into the producer/consumer* model that coroutines make trivial. Simulating coroutines with threads is easy enough, but the 'yields' then have considerable latency, which make it difficult to use for small units of work. Done properly, a coroutine yield is only slightly more expensive than a subroutine call and return, so passing very small units of work is a non-issue. Indirectly asking the OS for a task-switch to a different thread is going to be at least a couple of orders of magnitude worse. Nor are coroutines a new technique, or hard to implement. Heck, setjmp/longjmp have half the required mechanism already for C. *Not, of course, that coroutines are limited to that.
[toc] | [prev] | [next] | [standalone]
| From | fmassei@gmail.com |
|---|---|
| Date | 2015-01-20 13:38 -0800 |
| Message-ID | <348cfbb5-0aff-42a2-8538-5c7fb0d0ec46@googlegroups.com> |
| In reply to | #56528 |
On Tuesday, January 20, 2015 at 10:24:47 PM UTC+1, robert...@yahoo.com wrote: > On Tue, 20 Jan 2015 02:11:59 -0800 (PST), fmassei@gmail.com wrote: > > >On Tuesday, January 20, 2015 at 7:05:24 AM UTC+1, robert...@yahoo.com wrote: > >> On Mon, 19 Jan 2015 03:58:26 -0800 (PST), fmassei@gmail.com wrote: > >> >In general, I don't find coroutines so useful: it's just the lazy (or > >> >poor) man alternative to pure multithreading. > >> > >> > >> Nah, threads are a lazy (or poor) man's alterative to coroutines for > >> most uses of threads. > >> > > > >Well, they are two different paradigms, but given that "modern" languages > >and systems give threads out of the box and coroutines are not easily > >found at system-level, while multithreading in some cases could sound like > >an overkill, the final result would be more clean and flexible for sure. > > It's really a shame. There are so many things that fit naturally into > the producer/consumer* model that coroutines make trivial. Simulating > coroutines with threads is easy enough, but the 'yields' then have > considerable latency, which make it difficult to use for small units > of work. Done properly, a coroutine yield is only slightly more > expensive than a subroutine call and return, so passing very small > units of work is a non-issue. Indirectly asking the OS for a > task-switch to a different thread is going to be at least a couple of > orders of magnitude worse. > I agree, but still.. - coroutines are pretty limited when compared to threads: supporting both of them when one suffices and covers most of the user cases is probably not worthy.. - I still think that, even for threads, splitting algorithms on multiple cores is one of the things that compilers/interpreters could do better than humans. C is not the case but, for example, a good Haskell code could reach a great degree of parallelization with no programmers' efforts. And for a machine the complexity of the underlaying system is not an actual problem.. > Nor are coroutines a new technique, or hard to implement. Heck, > setjmp/longjmp have half the required mechanism already for C. > In fact, it should be easy to have a coroutine functionality in C too. If few people (or better, almost nobody) does that, it is surely not because he doesn't know about their existence: he has other standard ways for each given problem which could be solved (maybe more elegantly) by them. Ciao!
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-01-21 16:43 +0000 |
| Message-ID | <rGQvw.1483517$yK.1012292@fx14.iad> |
| In reply to | #56530 |
On 2015-01-20, fmassei@gmail.com <fmassei@gmail.com> wrote:
> On Tuesday, January 20, 2015 at 10:24:47 PM UTC+1, robert...@yahoo.com wrote:
>> On Tue, 20 Jan 2015 02:11:59 -0800 (PST), fmassei@gmail.com wrote:
>>
>> of work. Done properly, a coroutine yield is only slightly more
>> expensive than a subroutine call and return, so passing very small
>> units of work is a non-issue. Indirectly asking the OS for a
>> task-switch to a different thread is going to be at least a couple of
>> orders of magnitude worse.
>>
>
> I agree, but still..
> - coroutines are pretty limited when compared to threads: supporting both
> of them when one suffices and covers most of the user cases is probably
> not worthy..
> - I still think that, even for threads, splitting algorithms on multiple
> cores is one of the things that compilers/interpreters could do better than
> humans. C is not the case but, for example, a good Haskell code could reach
> a great degree of parallelization with no programmers' efforts. And for a
> machine the complexity of the underlaying system is not an actual problem..
>
>> Nor are coroutines a new technique, or hard to implement. Heck,
>> setjmp/longjmp have half the required mechanism already for C.
>>
>
> In fact, it should be easy to have a coroutine functionality in C too. If
> few people (or better, almost nobody) does that, it is surely not because he
> doesn't know about their existence: he has other standard ways for each
> given problem which could be solved (maybe more elegantly) by them.
>
OpenMP seems intersting. It has a simple syntax to allow a implementing
compiler to parallelize code. I've just started looking at it so I don't
imagine this to be anything like correct but here's a simple
producer/consumer example.
#include <stdio.h>
#define ENOUGH 100
int incr (int* n) {
if (*n == ENOUGH) {
return 0;
}
(*n)++;
return 1;
}
int use_n (int n) {
printf ("%d\n", n);
return n != ENOUGH;
}
int main () {
int n = 0;
int flag = 0;
#pragma omp parallel sections
{
#pragma omp section
{
int ok = 1;
while (ok) {
while (flag) {
#pragma omp flush(flag)
}
ok = incr (&n);
#pragma omp flush
flag = 1;
#pragma omp flush(flag)
}
}
#pragma omp section
{
int ok = 1;
while (ok) {
while (!flag) {
#pragma omp flush(flag)
}
#pragma omp flush
ok = use_n (n);
flag = 0;
}
}
}
return 0;
}
--
http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web