Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25896 > unrolled thread
| Started by | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| First post | 2017-03-05 16:03 -0700 |
| Last post | 2017-03-11 14:21 -0700 |
| Articles | 20 on this page of 202 — 22 participants |
Back to article view | Back to comp.arch.embedded
Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-05 16:03 -0700
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-06 08:04 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 10:31 -0700
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-07 23:29 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 02:49 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 13:18 +0100
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-08 16:58 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 10:35 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 22:07 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-06 08:40 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-06 10:31 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 08:47 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-06 21:33 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:44 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-07 12:24 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 09:34 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 10:14 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 10:37 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 22:09 +0100
Re: Language feature selection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-06 22:50 +0200
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-07 12:31 +0100
Re: Language feature selection rickman <gnuarm@gmail.com> - 2017-03-07 14:45 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-06 08:39 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 08:39 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-06 17:27 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:30 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-06 11:11 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:38 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-07 12:18 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 10:28 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-06 13:33 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 13:36 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-06 22:15 -0500
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-06 22:22 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 00:27 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-08 12:20 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 11:23 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-10 13:43 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 16:49 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 04:17 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 12:33 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-12 18:08 -0400
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 17:25 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-15 21:05 -0400
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-16 17:23 -0700
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-17 23:59 -0400
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-17 23:25 -0700
Re: Language feature selection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-18 12:05 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-18 04:04 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-18 04:39 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-18 03:55 -0700
Re: Language feature selection upsidedown@downunder.com - 2017-03-18 16:00 +0200
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-11 16:35 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 15:39 -0700
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-06 18:59 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-06 12:36 -0700
Re: Language feature selection Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-07 19:02 +0000
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-07 19:18 +0000
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-07 19:19 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 12:38 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-07 22:10 -0600
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-07 20:35 -0800
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-08 20:43 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-07 23:48 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-08 20:48 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-08 21:15 -0700
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-09 01:33 -0800
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-09 14:47 +0000
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 16:40 +0100
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-09 16:15 +0000
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 22:04 +0100
Re: Language feature selection John Devereux <john@devereux.me.uk> - 2017-03-10 07:46 +0000
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-10 13:21 +0100
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-09 17:57 -0600
Re: Language feature selection Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-03-10 11:16 +0200
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-10 20:39 +0100
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 13:32 -0800
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-11 14:58 +0200
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-13 13:02 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-08 10:46 +0100
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-08 20:33 -0600
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 11:08 +0100
Re: Language feature selection Britt <britt.snodgrass@gmail.com> - 2017-03-09 07:04 -0800
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 16:36 +0100
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-09 16:11 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-09 12:06 -0600
Re: Language feature selection Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-09 19:26 +0100
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-09 22:08 +0100
Re: Language feature selection Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-09 19:04 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-09 15:34 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-09 15:40 -0700
Re: Language feature selection Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-10 14:19 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 11:10 -0700
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 11:49 -0700
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-09 18:00 -0600
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-09 17:54 -0600
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-09 18:54 -0600
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-10 04:07 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 08:07 -0600
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-10 13:59 +0100
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-10 08:17 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 11:24 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-10 19:09 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 12:33 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-10 23:25 +0000
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-10 20:22 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 01:32 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 18:16 -0800
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 09:59 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-11 02:23 -0800
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 11:13 +0000
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 14:28 -0500
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 17:20 -0500
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-12 16:26 -0400
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-12 21:46 +0100
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-12 23:15 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-13 14:14 -0400
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-13 18:48 +0000
Re: Language feature selection "Brian G. Lucas" <bagel99@gmail.com> - 2017-03-13 15:17 -0500
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-13 23:17 +0200
Re: Language feature selection "Brian G. Lucas" <bagel99@gmail.com> - 2017-03-13 17:27 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 17:10 -0700
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-14 10:11 +0200
Re: Language feature selection "Brian G. Lucas" <bagel99@gmail.com> - 2017-03-14 12:23 -0500
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-14 13:27 +0100
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-14 13:30 -0400
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-14 22:03 +0100
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-14 17:24 -0400
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-11 07:19 -0600
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 19:43 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-12 09:28 -0600
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-12 15:15 -0400
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-12 19:38 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 18:08 -0800
Re: Language feature selection George Neuner <gneuner2@comcast.net> - 2017-03-11 04:22 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 10:02 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-11 02:22 -0800
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 11:07 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 14:30 -0600
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 13:37 -0800
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 16:30 -0600
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-10 18:14 -0800
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-11 07:46 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 12:53 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-12 09:45 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 11:56 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-12 21:05 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 14:40 -0700
Re: Language feature selection Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-13 00:36 +0200
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-12 17:00 -0700
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 16:50 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 17:08 -0700
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 20:51 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 20:31 -0700
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-14 21:45 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-14 21:16 -0700
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-11 16:40 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 15:10 -0700
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 16:42 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 17:02 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 00:46 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 13:05 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 21:58 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 15:19 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-11 23:27 +0000
Re: Language feature selection Walter Banks <walter@bytecraft.com> - 2017-03-10 20:14 -0600
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 12:16 -0700
Re: Language feature selection Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-10 20:40 +0100
Re: Language feature selection Wouter van Ooijen <wouter@voti.nl> - 2017-03-10 22:28 +0100
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-10 20:03 +0100
Re: Language feature selection Grant Edwards <invalid@invalid.invalid> - 2017-03-10 19:48 +0000
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-13 21:25 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-10 13:03 -0700
Re: Language feature selection Jacob Sparre Andersen <jacob@jacob-sparre.dk> - 2017-03-13 21:40 +0100
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-13 14:35 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-14 01:06 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-13 19:23 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-14 08:48 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-14 02:14 -0700
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-14 09:33 +0000
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-14 09:21 -0700
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-17 06:01 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 11:39 +0000
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-17 07:16 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 13:49 +0000
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-17 11:03 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-17 19:21 +0100
Re: Language feature selection Paul Rubin <no.email@nospam.invalid> - 2017-03-17 11:34 -0700
Re: Language feature selection David Brown <david.brown@hesbynett.no> - 2017-03-17 20:26 +0100
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 20:07 +0000
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-17 20:29 +0000
Re: Language feature selection Les Cargill <lcargill99@comcast.com> - 2017-03-17 19:19 -0500
Re: Language feature selection Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-18 08:18 +0000
Re: Language feature selection Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-14 21:20 +0100
Re: Language feature selection jim.brakefield@ieee.org - 2017-03-10 18:46 -0800
Re: Language feature selection Niklas Holsti <niklas.holsti@tidorum.invalid> - 2017-03-11 15:41 +0200
Re: Language feature selection jim.brakefield@ieee.org - 2017-03-11 14:20 -0800
Re: Language feature selection upsidedown@downunder.com - 2017-03-12 00:54 +0200
Re: Language feature selection jim.brakefield@ieee.org - 2017-03-12 18:08 -0700
Re: Language feature selection upsidedown@downunder.com - 2017-03-13 23:36 +0200
Re: Language feature selection Robert Wessel <robertwessel2@yahoo.com> - 2017-03-13 17:03 -0500
Re: Language feature selection Don Y <blockedofcourse@foo.invalid> - 2017-03-11 14:21 -0700
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 00:46 +0000 |
| Message-ID | <tNHwA.52667$15.51804@fx07.am4> |
| In reply to | #25994 |
On 11/03/17 00:02, Don Y wrote: > On 3/10/2017 3:42 PM, Walter Banks wrote: >> Most of my time now is working on both tools and ISA's. There has been >> some really significant changes in both approaches to compiling for >> heterogeneous parallel environments and execution environments that have >> hundreds to thousands of processors in them. > > But they are (largely) *static* environments (?). The toolchain doesn't > have to decide when to bring another processor on-line... or, when it can > retire a running processor and migrate its workload to some OTHER > processor, etc. Or, which aspects of an application should be bound > to specific processors (nearness of related I/Os) and which aspects > should AVOID particular processors (as they were in insecure locations). The more advanced toolchains are doing similar things. They instrument themselves, determine what the code+data is *actually* doing at runtime, and optimise the **** out of that. That's as opposed to what the compiler can guess they are doing and where a compiler has to make pessimising assumptions. And such techniques also work with C. For 18 year old (gulp) results, google for "hplb dynamo". And don't forget that some related techniques are implemented in processor's hardware microarchitecture. > [Simulations of my first workload scheduler immediately brought every > processor online and kept them there! D'uh!] > > I've found it "trying" to come up with even a suitable set of criteria > by which to constrain these choices. E.g., "performance" can be evaluated > in a variety of ways: throughput, response time, power consumption, > redundancy, etc. Just coming up with *a* set of criteria is a challenge. > And, if the user can bias this at run-time, it becomes even more > challenging! (perhaps userX might be willing to suffer slower response > times for reduced power consumption?) > > [As I get older, I am encountering more applications where The Right Answer > is really elusive and often not available "at compile time". *Or*, even > DESIGN TIME! (I'm still at a loss to forumulate a test suite to score > the performance of the different speech synthesizer implelmentations I've > created -- let alone their "costs"! sqrt(3) = 1.732 is a "better" answer > than sqrt(3) = 1.7; but, how do you decide which pronunciation of which > utterance is "better" -- and, how to weight the performances of the > limitless number of POSSIBLE uterances to come up with a composite score??)] You are correct in presuming that you can't do an optimal job at compile time, since the information isn't there - and can't be there. The bonus of avoiding getting toolchains to make premature optimisations, is that the same runtime optimisation techniques also work with different processors. There are disadvantages, of course. TANSTAFFL. >> We are likely sooner than later to see some major shifts in tool sets. >> I am currently working on a reference design for one of these that has >> several hundred execution units. > > I'd be interested in seeing what directions you took when you have something > to share! And, the assumptions you made along the way. > > Time for my evening jaunt... cripes, still 90 degrees -- this won't be fun. > :<
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-11 13:05 -0700 |
| Message-ID | <oa1l4e$g8l$1@dont-email.me> |
| In reply to | #25995 |
On 3/10/2017 5:46 PM, Tom Gardner wrote:
> On 11/03/17 00:02, Don Y wrote:
>> On 3/10/2017 3:42 PM, Walter Banks wrote:
>>> Most of my time now is working on both tools and ISA's. There has been
>>> some really significant changes in both approaches to compiling for
>>> heterogeneous parallel environments and execution environments that have
>>> hundreds to thousands of processors in them.
>>
>> But they are (largely) *static* environments (?). The toolchain doesn't
>> have to decide when to bring another processor on-line... or, when it can
>> retire a running processor and migrate its workload to some OTHER
>> processor, etc. Or, which aspects of an application should be bound
>> to specific processors (nearness of related I/Os) and which aspects
>> should AVOID particular processors (as they were in insecure locations).
>
> The more advanced toolchains are doing similar things.
> They instrument themselves, determine what the code+data
> is *actually* doing at runtime, and optimise the **** out
> of that.
I don't see how that can happen -- unless you can force all possible
uses of the code to occur while that analysis is being undertaken.
E.g., if it never sees you hit the brake pedal in your vehicle,
it's likely to spend a lot of effort optimizing ignition timing,
thinking "brakes" are never/seldom used! :>
> That's as opposed to what the compiler can guess they
> are doing and where a compiler has to make pessimising
> assumptions.
>
> And such techniques also work with C. For 18 year old
> (gulp) results, google for "hplb dynamo".
>
> And don't forget that some related techniques are implemented
> in processor's hardware microarchitecture.
>
>> [Simulations of my first workload scheduler immediately brought every
>> processor online and kept them there! D'uh!]
>>
>> I've found it "trying" to come up with even a suitable set of criteria
>> by which to constrain these choices. E.g., "performance" can be evaluated
>> in a variety of ways: throughput, response time, power consumption,
>> redundancy, etc. Just coming up with *a* set of criteria is a challenge.
>> And, if the user can bias this at run-time, it becomes even more
>> challenging! (perhaps userX might be willing to suffer slower response
>> times for reduced power consumption?)
>>
>> [As I get older, I am encountering more applications where The Right Answer
>> is really elusive and often not available "at compile time". *Or*, even
>> DESIGN TIME! (I'm still at a loss to forumulate a test suite to score
>> the performance of the different speech synthesizer implelmentations I've
>> created -- let alone their "costs"! sqrt(3) = 1.732 is a "better" answer
>> than sqrt(3) = 1.7; but, how do you decide which pronunciation of which
>> utterance is "better" -- and, how to weight the performances of the
>> limitless number of POSSIBLE uterances to come up with a composite score??)]
>
> You are correct in presuming that you can't do an
> optimal job at compile time, since the information
> isn't there - and can't be there.
I contend that there are huge classes of "programs" (this is c.a.E, right?)
that would fail miserably with such an approach. You're not processing
payroll where you can tweek umpteen gazillion iterations of the same loop.
Rather, you are at the mercy of the events that transpire in the environment
AND some externally sourced notion of relative "values" (neglecting timeliness
for the moment).
> The bonus of avoiding getting toolchains to make
> premature optimisations, is that the same runtime
> optimisation techniques also work with different
> processors.
That would depend on the nature of those optimizations and their potential
consequences. Replacing an ADD with a SHIFT (assuming the SHIFT was more
economical) isn't going to "color" the result, significantly.
And, an application ("program") can behave differently in different
execution environments -- optimizations intended to exploit cache
would be wasted on a system without cache; applications hosted in
a paged memory management environment will benefit from different
optimizations than the same application running in a flat/unpaged
environment; etc.
> There are disadvantages, of course. TANSTAFFL.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 21:58 +0000 |
| Message-ID | <Tp_wA.249954$qK5.74888@fx45.am4> |
| In reply to | #26020 |
On 11/03/17 20:05, Don Y wrote:
> On 3/10/2017 5:46 PM, Tom Gardner wrote:
>> On 11/03/17 00:02, Don Y wrote:
>>> On 3/10/2017 3:42 PM, Walter Banks wrote:
>>>> Most of my time now is working on both tools and ISA's. There has been
>>>> some really significant changes in both approaches to compiling for
>>>> heterogeneous parallel environments and execution environments that have
>>>> hundreds to thousands of processors in them.
>>>
>>> But they are (largely) *static* environments (?). The toolchain doesn't
>>> have to decide when to bring another processor on-line... or, when it can
>>> retire a running processor and migrate its workload to some OTHER
>>> processor, etc. Or, which aspects of an application should be bound
>>> to specific processors (nearness of related I/Os) and which aspects
>>> should AVOID particular processors (as they were in insecure locations).
>>
>> The more advanced toolchains are doing similar things.
>> They instrument themselves, determine what the code+data
>> is *actually* doing at runtime, and optimise the **** out
>> of that.
>
> I don't see how that can happen -- unless you can force all possible
> uses of the code to occur while that analysis is being undertaken.
That would be counterproductive, since you want to
optimise the common case. (Just like hardware and
software caches do).
For a surprising example of where an experimental lab
investigation became vaguely practical, see
http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html
> E.g., if it never sees you hit the brake pedal in your vehicle,
> it's likely to spend a lot of effort optimizing ignition timing,
> thinking "brakes" are never/seldom used! :>
>
>> That's as opposed to what the compiler can guess they
>> are doing and where a compiler has to make pessimising
>> assumptions.
>>
>> And such techniques also work with C. For 18 year old
>> (gulp) results, google for "hplb dynamo".
>>
>> And don't forget that some related techniques are implemented
>> in processor's hardware microarchitecture.
>>
>>> [Simulations of my first workload scheduler immediately brought every
>>> processor online and kept them there! D'uh!]
>>>
>>> I've found it "trying" to come up with even a suitable set of criteria
>>> by which to constrain these choices. E.g., "performance" can be evaluated
>>> in a variety of ways: throughput, response time, power consumption,
>>> redundancy, etc. Just coming up with *a* set of criteria is a challenge.
>>> And, if the user can bias this at run-time, it becomes even more
>>> challenging! (perhaps userX might be willing to suffer slower response
>>> times for reduced power consumption?)
>>>
>>> [As I get older, I am encountering more applications where The Right Answer
>>> is really elusive and often not available "at compile time". *Or*, even
>>> DESIGN TIME! (I'm still at a loss to forumulate a test suite to score
>>> the performance of the different speech synthesizer implelmentations I've
>>> created -- let alone their "costs"! sqrt(3) = 1.732 is a "better" answer
>>> than sqrt(3) = 1.7; but, how do you decide which pronunciation of which
>>> utterance is "better" -- and, how to weight the performances of the
>>> limitless number of POSSIBLE uterances to come up with a composite score??)]
>>
>> You are correct in presuming that you can't do an
>> optimal job at compile time, since the information
>> isn't there - and can't be there.
>
> I contend that there are huge classes of "programs" (this is c.a.E, right?)
> that would fail miserably with such an approach. You're not processing
> payroll where you can tweek umpteen gazillion iterations of the same loop.
> Rather, you are at the mercy of the events that transpire in the environment
> AND some externally sourced notion of relative "values" (neglecting timeliness
> for the moment).
If by "embedded" you mean "tiny", then I agree these
techniques are not currently very useful.
OTOH I have used them successfully in HA soft realtime
telecom call processing systems. Those can reasonably
be regarded as "large" embedded systems.
>> The bonus of avoiding getting toolchains to make
>> premature optimisations, is that the same runtime
>> optimisation techniques also work with different
>> processors.
>
> That would depend on the nature of those optimizations and their potential
> consequences. Replacing an ADD with a SHIFT (assuming the SHIFT was more
> economical) isn't going to "color" the result, significantly.
>
> And, an application ("program") can behave differently in different
> execution environments -- optimizations intended to exploit cache
> would be wasted on a system without cache; applications hosted in
> a paged memory management environment will benefit from different
> optimizations than the same application running in a flat/unpaged
> environment; etc.
If you have hard realtime embedded systems, all caches
are problematic since they are by definition statistical
in nature.
IIRC the i960 processor had a crude mechanism for freezing
its caches, to avoid such issues.
>> There are disadvantages, of course. TANSTAFFL.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-11 15:19 -0700 |
| Message-ID | <oa1t0n$s21$1@dont-email.me> |
| In reply to | #26022 |
On 3/11/2017 2:58 PM, Tom Gardner wrote:
> On 11/03/17 20:05, Don Y wrote:
>> On 3/10/2017 5:46 PM, Tom Gardner wrote:
>>> On 11/03/17 00:02, Don Y wrote:
>>>> On 3/10/2017 3:42 PM, Walter Banks wrote:
>>>>> Most of my time now is working on both tools and ISA's. There has been
>>>>> some really significant changes in both approaches to compiling for
>>>>> heterogeneous parallel environments and execution environments that have
>>>>> hundreds to thousands of processors in them.
>>>>
>>>> But they are (largely) *static* environments (?). The toolchain doesn't
>>>> have to decide when to bring another processor on-line... or, when it can
>>>> retire a running processor and migrate its workload to some OTHER
>>>> processor, etc. Or, which aspects of an application should be bound
>>>> to specific processors (nearness of related I/Os) and which aspects
>>>> should AVOID particular processors (as they were in insecure locations).
>>>
>>> The more advanced toolchains are doing similar things.
>>> They instrument themselves, determine what the code+data
>>> is *actually* doing at runtime, and optimise the **** out
>>> of that.
>>
>> I don't see how that can happen -- unless you can force all possible
>> uses of the code to occur while that analysis is being undertaken.
>
> That would be counterproductive, since you want to
> optimise the common case. (Just like hardware and
> software caches do).
But "common" may have little *value*. E.g., I can tolerate my
ECU producing a slightly richer burn but can't tolerate my
brakes failing to respond in a timely fashion.
How many pixels in a multimegapixel image can you afford to
corrupt, slightly, before the picture becomes unrecognizable as
such? OTOH, if you fail to snap the shutter when commanded...
> For a surprising example of where an experimental lab
> investigation became vaguely practical, see
> http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
> http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html
>
>> E.g., if it never sees you hit the brake pedal in your vehicle,
>> it's likely to spend a lot of effort optimizing ignition timing,
>> thinking "brakes" are never/seldom used! :>
>>
>>> That's as opposed to what the compiler can guess they
>>> are doing and where a compiler has to make pessimising
>>> assumptions.
>>>
>>> And such techniques also work with C. For 18 year old
>>> (gulp) results, google for "hplb dynamo".
>>>
>>> And don't forget that some related techniques are implemented
>>> in processor's hardware microarchitecture.
>>>
>>>> [Simulations of my first workload scheduler immediately brought every
>>>> processor online and kept them there! D'uh!]
>>>>
>>>> I've found it "trying" to come up with even a suitable set of criteria
>>>> by which to constrain these choices. E.g., "performance" can be evaluated
>>>> in a variety of ways: throughput, response time, power consumption,
>>>> redundancy, etc. Just coming up with *a* set of criteria is a challenge.
>>>> And, if the user can bias this at run-time, it becomes even more
>>>> challenging! (perhaps userX might be willing to suffer slower response
>>>> times for reduced power consumption?)
>>>>
>>>> [As I get older, I am encountering more applications where The Right Answer
>>>> is really elusive and often not available "at compile time". *Or*, even
>>>> DESIGN TIME! (I'm still at a loss to forumulate a test suite to score
>>>> the performance of the different speech synthesizer implelmentations I've
>>>> created -- let alone their "costs"! sqrt(3) = 1.732 is a "better" answer
>>>> than sqrt(3) = 1.7; but, how do you decide which pronunciation of which
>>>> utterance is "better" -- and, how to weight the performances of the
>>>> limitless number of POSSIBLE uterances to come up with a composite score??)]
>>>
>>> You are correct in presuming that you can't do an
>>> optimal job at compile time, since the information
>>> isn't there - and can't be there.
>>
>> I contend that there are huge classes of "programs" (this is c.a.E, right?)
>> that would fail miserably with such an approach. You're not processing
>> payroll where you can tweek umpteen gazillion iterations of the same loop.
>> Rather, you are at the mercy of the events that transpire in the environment
>> AND some externally sourced notion of relative "values" (neglecting timeliness
>> for the moment).
>
> If by "embedded" you mean "tiny", then I agree these
> techniques are not currently very useful.
No. Embedded means nothing of the sort. Rather, it signifies applications
that tend to be driven by events sensed in the environment. Where do I specify
the average interarrival time of a particular event? Or, combinations and
interactions of events? How do I indicate that this is "typical" behavior
vs. worst case? How do you know that the "optimizations" it has chosen
make sense in any but THAT case?
How do I tune my current system without knowing what one particular set of
users will consider "normal use" -- which may differ dramatically from what the
next set of users will consider normal? What if their usage patterns change
over the course of the product's lifetime? Or, over the course of a single
*day*? Should I optimize the video channel? Audio? Speech recognition?
Synthesis?
The needs of presenting OTA video to a user differ considerably from those
of *storing* OTA video for later playback! How do I balance the resources
devoted to these tasks -- when either, neither or *both* may be required
at any given instant? How does the tool know what resources are available
*now* to meet the present workload?
> OTOH I have used them successfully in HA soft realtime
> telecom call processing systems. Those can reasonably
> be regarded as "large" embedded systems.
That's akin to a payroll system. Reasonably constant, consistent
traffic. How often does it have to manage the fire suppression
equipment protecting the switch? Or, deal with folks entering the
building via the front doorway?
A control system on a warship operates in hugely different conditions
based on whether it is sailing "at peace", "on alert" or actively
engaged in a firefight. Does the code get rewritten as the warship
transitions between these states? Which is the "common case"?
Is it defined by number of instructions executed in that state?
Or, total elapsed time, there? Or, the *value* of its performance
in that state?
"We're really efficient at sailing on the open seas but our
maneuvering while under fire is really shitty!"
>>> The bonus of avoiding getting toolchains to make
>>> premature optimisations, is that the same runtime
>>> optimisation techniques also work with different
>>> processors.
>>
>> That would depend on the nature of those optimizations and their potential
>> consequences. Replacing an ADD with a SHIFT (assuming the SHIFT was more
>> economical) isn't going to "color" the result, significantly.
>>
>> And, an application ("program") can behave differently in different
>> execution environments -- optimizations intended to exploit cache
>> would be wasted on a system without cache; applications hosted in
>> a paged memory management environment will benefit from different
>> optimizations than the same application running in a flat/unpaged
>> environment; etc.
>
> If you have hard realtime embedded systems, all caches
> are problematic since they are by definition statistical
> in nature.
Doesn't matter if HRT, SRT or NON real-time. The point is the
behavior changes. Same source code.
> IIRC the i960 processor had a crude mechanism for freezing
> its caches, to avoid such issues.
>
>>> There are disadvantages, of course. TANSTAFFL.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-11 23:27 +0000 |
| Message-ID | <XJ%wA.241649$3B6.117070@fx40.am4> |
| In reply to | #26023 |
On 11/03/17 22:19, Don Y wrote:
> On 3/11/2017 2:58 PM, Tom Gardner wrote:
>> On 11/03/17 20:05, Don Y wrote:
>>> On 3/10/2017 5:46 PM, Tom Gardner wrote:
>>>> On 11/03/17 00:02, Don Y wrote:
>>>>> On 3/10/2017 3:42 PM, Walter Banks wrote:
>>>>>> Most of my time now is working on both tools and ISA's. There has been
>>>>>> some really significant changes in both approaches to compiling for
>>>>>> heterogeneous parallel environments and execution environments that have
>>>>>> hundreds to thousands of processors in them.
>>>>>
>>>>> But they are (largely) *static* environments (?). The toolchain doesn't
>>>>> have to decide when to bring another processor on-line... or, when it can
>>>>> retire a running processor and migrate its workload to some OTHER
>>>>> processor, etc. Or, which aspects of an application should be bound
>>>>> to specific processors (nearness of related I/Os) and which aspects
>>>>> should AVOID particular processors (as they were in insecure locations).
>>>>
>>>> The more advanced toolchains are doing similar things.
>>>> They instrument themselves, determine what the code+data
>>>> is *actually* doing at runtime, and optimise the **** out
>>>> of that.
>>>
>>> I don't see how that can happen -- unless you can force all possible
>>> uses of the code to occur while that analysis is being undertaken.
>>
>> That would be counterproductive, since you want to
>> optimise the common case. (Just like hardware and
>> software caches do).
>
> But "common" may have little *value*. E.g., I can tolerate my
> ECU producing a slightly richer burn but can't tolerate my
> brakes failing to respond in a timely fashion.
Caches have exactly the same properties.
So how do you ensure your systems have absolutely no
caches, neither hardware nor software?
If you have caches, you have statistical timings,
and hence your brakes could fail to respond in a
timely fashion.
> How many pixels in a multimegapixel image can you afford to
> corrupt, slightly, before the picture becomes unrecognizable as
> such? OTOH, if you fail to snap the shutter when commanded...
>
>> For a surprising example of where an experimental lab
>> investigation became vaguely practical, see
>> http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
>> http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html
>>
>>> E.g., if it never sees you hit the brake pedal in your vehicle,
>>> it's likely to spend a lot of effort optimizing ignition timing,
>>> thinking "brakes" are never/seldom used! :>
>>>
>>>> That's as opposed to what the compiler can guess they
>>>> are doing and where a compiler has to make pessimising
>>>> assumptions.
>>>>
>>>> And such techniques also work with C. For 18 year old
>>>> (gulp) results, google for "hplb dynamo".
>>>>
>>>> And don't forget that some related techniques are implemented
>>>> in processor's hardware microarchitecture.
>>>>
>>>>> [Simulations of my first workload scheduler immediately brought every
>>>>> processor online and kept them there! D'uh!]
>>>>>
>>>>> I've found it "trying" to come up with even a suitable set of criteria
>>>>> by which to constrain these choices. E.g., "performance" can be evaluated
>>>>> in a variety of ways: throughput, response time, power consumption,
>>>>> redundancy, etc. Just coming up with *a* set of criteria is a challenge.
>>>>> And, if the user can bias this at run-time, it becomes even more
>>>>> challenging! (perhaps userX might be willing to suffer slower response
>>>>> times for reduced power consumption?)
>>>>>
>>>>> [As I get older, I am encountering more applications where The Right Answer
>>>>> is really elusive and often not available "at compile time". *Or*, even
>>>>> DESIGN TIME! (I'm still at a loss to forumulate a test suite to score
>>>>> the performance of the different speech synthesizer implelmentations I've
>>>>> created -- let alone their "costs"! sqrt(3) = 1.732 is a "better" answer
>>>>> than sqrt(3) = 1.7; but, how do you decide which pronunciation of which
>>>>> utterance is "better" -- and, how to weight the performances of the
>>>>> limitless number of POSSIBLE uterances to come up with a composite score??)]
>>>>
>>>> You are correct in presuming that you can't do an
>>>> optimal job at compile time, since the information
>>>> isn't there - and can't be there.
>>>
>>> I contend that there are huge classes of "programs" (this is c.a.E, right?)
>>> that would fail miserably with such an approach. You're not processing
>>> payroll where you can tweek umpteen gazillion iterations of the same loop.
>>> Rather, you are at the mercy of the events that transpire in the environment
>>> AND some externally sourced notion of relative "values" (neglecting timeliness
>>> for the moment).
>>
>> If by "embedded" you mean "tiny", then I agree these
>> techniques are not currently very useful.
>
> No. Embedded means nothing of the sort. Rather, it signifies applications
> that tend to be driven by events sensed in the environment. Where do I specify
> the average interarrival time of a particular event? Or, combinations and
> interactions of events? How do I indicate that this is "typical" behavior
> vs. worst case? How do you know that the "optimizations" it has chosen
> make sense in any but THAT case?
Telecom call control systems have all those characteristics,
therefore telecom call control systems can be considered
to be embedded systems.
I've embedded timing measurements in my systems (over
some objections I might note). They were subsequently
used to prove that my system was fast and another
manufacturer's system was too slow culprit. There were
no objections to my PDF/CDF histograms after that :)
> How do I tune my current system without knowing what one particular set of
> users will consider "normal use" -- which may differ dramatically from what the
> next set of users will consider normal? What if their usage patterns change
> over the course of the product's lifetime? Or, over the course of a single
> *day*? Should I optimize the video channel? Audio? Speech recognition?
> Synthesis?
You don't; in practice you couldn't do such
micro-optimisations. The system measures
itself and optimises itself depending on what
it finds.
It keeps monitoring itself and keeps re-optimising
its performance as conditions change.
The first versions of such optimisations appeared in
1986, in a Smalltalk implementation. Vastly improved
techniques were developed in the late 90s, and they
have been standard in deployed systems for over a
decade.
> The needs of presenting OTA video to a user differ considerably from those
> of *storing* OTA video for later playback! How do I balance the resources
> devoted to these tasks -- when either, neither or *both* may be required
> at any given instant? How does the tool know what resources are available
> *now* to meet the present workload?
>
>> OTOH I have used them successfully in HA soft realtime
>> telecom call processing systems. Those can reasonably
>> be regarded as "large" embedded systems.
>
> That's akin to a payroll system. Reasonably constant, consistent
> traffic. How often does it have to manage the fire suppression
> equipment protecting the switch? Or, deal with folks entering the
> building via the front doorway?
No, it is not.
There are soft realtime performance obligations; if
the call is not placed within a defined time the
subscribers get annoyed and the network operators
start throwing chairs around meeting rooms.
Ditto if a subscriber runs out of credit and all parts
of the multimedia the call are not terminated at the
right time.
"HA" is high availability, so it has to cope with bits
of the system disappearing and reappearing without
warning. In a payroll system the transactions can be
(and sometimes are) re-run from the event logs; that's
conceptually impossible in telecom call-control systems,
for obvious reasons.
> A control system on a warship operates in hugely different conditions
> based on whether it is sailing "at peace", "on alert" or actively
> engaged in a firefight. Does the code get rewritten as the warship
> transitions between these states? Which is the "common case"?
> Is it defined by number of instructions executed in that state?
> Or, total elapsed time, there? Or, the *value* of its performance
> in that state?
> "We're really efficient at sailing on the open seas but our
> maneuvering while under fire is really shitty!"
>
>>>> The bonus of avoiding getting toolchains to make
>>>> premature optimisations, is that the same runtime
>>>> optimisation techniques also work with different
>>>> processors.
>>>
>>> That would depend on the nature of those optimizations and their potential
>>> consequences. Replacing an ADD with a SHIFT (assuming the SHIFT was more
>>> economical) isn't going to "color" the result, significantly.
>>>
>>> And, an application ("program") can behave differently in different
>>> execution environments -- optimizations intended to exploit cache
>>> would be wasted on a system without cache; applications hosted in
>>> a paged memory management environment will benefit from different
>>> optimizations than the same application running in a flat/unpaged
>>> environment; etc.
>>
>> If you have hard realtime embedded systems, all caches
>> are problematic since they are by definition statistical
>> in nature.
>
> Doesn't matter if HRT, SRT or NON real-time. The point is the
> behavior changes. Same source code.
I don't understand your point.
>> IIRC the i960 processor had a crude mechanism for freezing
>> its caches, to avoid such issues.
>>
>>>> There are disadvantages, of course. TANSTAFFL.
>
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2017-03-10 20:14 -0600 |
| Message-ID | <o9vmh8$hmg$1@gioia.aioe.org> |
| In reply to | #25994 |
On 2017-03-10 6:02 PM, Don Y wrote: > On 3/10/2017 3:42 PM, Walter Banks wrote: >> On 2017-03-10 4:10 PM, Don Y wrote: >>>> What's wrong with a single set of sources that defines an >>>> application, no command line options or linker scripts just an >>>> application including the definition of the target, files and >>>> libraries it needs. Compilation is both faster by many factors >>>> and there is a simple self contained project that can be >>>> easily re-created after a decade or more. >>> >>> That would depend on the size and complexity of the project, >>> right? I have 192 processors (each with multiple cores) in my >>> current design. It would be *delightful* if <something> could >>> sort out how best to allocate resources at run-time instead of my >>> crude metrics. >>> >>> But, those tools don't exist and aren't likely to any time soon. >> >> Most of my time now is working on both tools and ISA's. There has >> been some really significant changes in both approaches to >> compiling for heterogeneous parallel environments and execution >> environments that have hundreds to thousands of processors in >> them. > > But they are (largely) *static* environments (?). The toolchain > doesn't have to decide when to bring another processor on-line... or, > when it can retire a running processor and migrate its workload to > some OTHER processor, etc. Or, which aspects of an application > should be bound to specific processors (nearness of related I/Os) and > which aspects should AVOID particular processors (as they were in > insecure locations). It is not a static environment. The compiler DOES allocate which processor (the compiler has heterogeneous processor support) is suitable for some particular part of the application. Most of the application distribution IS determined at compile time. The compiler tool work is an evolution of the named address space work we did in Japan in the early 90's (ISO/IEC18037) to named processor space to compiler allocated named processor space. w..
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-11 12:16 -0700 |
| Message-ID | <oa1i92$kb4$1@dont-email.me> |
| In reply to | #25999 |
On 3/10/2017 7:14 PM, Walter Banks wrote:
> On 2017-03-10 6:02 PM, Don Y wrote:
>> On 3/10/2017 3:42 PM, Walter Banks wrote:
>>> On 2017-03-10 4:10 PM, Don Y wrote:
>>>>> What's wrong with a single set of sources that defines an
>>>>> application, no command line options or linker scripts just an
>>>>> application including the definition of the target, files and
>>>>> libraries it needs. Compilation is both faster by many factors
>>>>> and there is a simple self contained project that can be
>>>>> easily re-created after a decade or more.
>>>>
>>>> That would depend on the size and complexity of the project,
>>>> right? I have 192 processors (each with multiple cores) in my
>>>> current design. It would be *delightful* if <something> could
>>>> sort out how best to allocate resources at run-time instead of my
>>>> crude metrics.
>>>>
>>>> But, those tools don't exist and aren't likely to any time soon.
>>>
>>> Most of my time now is working on both tools and ISA's. There has
>>> been some really significant changes in both approaches to
>>> compiling for heterogeneous parallel environments and execution
>>> environments that have hundreds to thousands of processors in
>>> them.
>>
>> But they are (largely) *static* environments (?). The toolchain
>> doesn't have to decide when to bring another processor on-line... or,
>> when it can retire a running processor and migrate its workload to
>> some OTHER processor, etc. Or, which aspects of an application
>> should be bound to specific processors (nearness of related I/Os) and
>> which aspects should AVOID particular processors (as they were in
>> insecure locations).
>
> It is not a static environment. The compiler DOES allocate which
> processor (the compiler has heterogeneous processor support) is suitable
> for some particular part of the application. Most of the application
> distribution IS determined at compile time.
>
> The compiler tool work is an evolution of the named address space work
> we did in Japan in the early 90's (ISO/IEC18037) to named processor
> space to compiler allocated named processor space.
I don't see how that can be applied to anything but a generic environment.
E.g., I track resources associated with each node (especially "unique"
I/O's). Then, based on the *events* encountered in the environment,
decide which of those resources NEED to be brought on-line and how
resources can then be redistributed to meet the current workload.
(and, conversely, when I can "shed" resources -- to conserve *power*
and/or improve communication overhead)
So, for example, if it's "daytime", the node that supports the video camera
that monitors folks approaching the front door is powered up -- because I
want to notice "visitors" in order to ANNOUNCE them (I don't accept visitors
"after hours"). In this case, there is a NEED for that particular set
of I/O's (i.e., the cameras facing the back yard are not capable of watching
the front door approach!) along with a need for some additional compute
resources (real-time image analysis). There is a COST associated with this:
the power required to run that node and those hardware resources.
*Where* the code that analyzes the imagery executes is determined by
the locations of the resources (CPU+memory) required to perform that
task along with the communication costs to/from that application's
physical location and the I/O's that it requires along with the clients
with which it interacts.
If/when a visitor is "detected", then a means of informing the occupants
of its identity is required. The most obvious solution being to power
up another node proximate to an occupant and dispatch a live video feed
to the *display* served by that node. An occupant can elect to interact
with the visitor ("intercom") *or* direct the system to interact with
them on their behalf (i.e., so they don't have to disclose their presence
to the visitor: "Who are you? Whaddya want?"). Of course, this means
tasks dedicated to synthesizing the required prompts need to be brought
on-line and a channel opened by which that audio can be fed to the
visitor and the visitor's reply captured and relayed to the occupant.
If the house is unoccupied, that video feed might, instead, be spooled to
a media tank. Or, pushed over an internet/phone connection to the occupant(s)
at a remote location. The audio prompts can be triggered from a
"house_unoccupied()" script and responses similarly captured/dispatched.
When the visitor departs, all of this mechanism can be taken down to
conserve power.
Later that night, that idle (cold!) node might be deliberately powered up,
its camera left OFF and the CPU+memory assigned to "off-line/batch" processing
of commercial detection in some OTA video broadcast captured earlier in the
day. Or, the resources used to refine the speech recognizer's training
set for UserA based on the stored audio for the voice commands issued
during that day.
It's not possible to come up with an "ideal" resource (re)allocation
strategy -- even having detailed knowledge of the *current* workload.
I don't see how a tool can know these usage patterns or even possibilities
at compile/build time!
[How does it know the cost of migrating taskA to node4 to accommodate taskM's
MORE EFFICIENT use of node4's hardware resources (I/O's) in order to factor
that into its decision as to whether node27 should, instead, be powered up
and taskM spawned there, instead (incurring higher communication costs to
PROXY stubs on node4 to twiddle those I/O's)? How does it know the
communication costs for taskM's interactions with those proxies? etc.]
[[I do this with a combination of crude metrics and heuristics "learned"
over time -- by the system observing itself and how well it meets its
performance requirements and deadlines with particular (task,node)
bindings. And, I never know if I've got the *ideal* configuration
for any set of nodes and tasks...]]
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2017-03-10 20:40 +0100 |
| Message-ID | <eigdp0Ff47gU1@mid.dfncis.de> |
| In reply to | #25968 |
Am 10.03.2017 um 09:17 schrieb Tom Gardner: > This is a philosophical difference. > > If something is important to the correct operation of > the program, then I like it to be visible in the source > code. That's just it: it is hardly essential for the operation of such code _where_ exactly that register is; what really matters is that the variable describing it is a) properly structured and named, and b) ultimately correctly located. So how is it better to have that address hard-coded into the driver source code, as opposed to getting to decide it at link-time? Among other things, this allows using the same, pre-compiled driver code to be used for different micros, even if they mapped the same peripheral IP module to different addresses. Practically speaking, the @ extension has caused my employer a good deal more grief than equivalent methods in other toolchains we use. That happened primarily because it _is_ an extension that quite a number of our other tools that read C source don't fully recognize. The worst aspect of it is that no amount of preprocessor work gets the @ syntax reliably hidden from those tools' view. > A useful benefit is that the information is easily > found and analysed by the IDEs and/or other source code > manipulation tools around. An IDE that cannot find text in linker/locator scripts or make files isn't worth being in use. > In the same vein, in C I dislike having correct code > operation being dependent on combinations of command > line compiler arguments. Well, most code whose behaviour is changed by compiler flags is anything but correct --- its authors usually fail to see that, though. OTOH, using language extensions like this '@' makes your code dependent not just on a compiler option that might toggle it on/off, but even on the compiler _having_ such support in the first place, for that option to enable. > I cannot think of a reason why you would need to nail down addresses > in portable code. For platforms like ARM that have multiple compiler toolchains available, it's highly preferrable to allow a single code base to work on all of them. That's one kind of portability the '@' extension breaks almost immediately, first by not being supported on all compilers, second by hard-coding addresses that aren't necessarily the same on all implementations of the CPU platform.
[toc] | [prev] | [next] | [standalone]
| From | Wouter van Ooijen <wouter@voti.nl> |
|---|---|
| Date | 2017-03-10 22:28 +0100 |
| Message-ID | <58c31a97$0$1830$e4fe514c@newszilla.xs4all.nl> |
| In reply to | #25982 |
Op 10-Mar-17 om 20:40 schreef Hans-Bernhard Bröker: > Am 10.03.2017 um 09:17 schrieb Tom Gardner: >> This is a philosophical difference. >> >> If something is important to the correct operation of >> the program, then I like it to be visible in the source >> code. > > That's just it: it is hardly essential for the operation of such code > _where_ exactly that register is; what really matters is that the > variable describing it is a) properly structured and named, and b) > ultimately correctly located. > > So how is it better to have that address hard-coded into the driver > source code, as opposed to getting to decide it at link-time? Because it might enable the code generator to generate better (smaller and faster) code. Wouter "Objects? No Thanks!" van Ooijen
[toc] | [prev] | [next] | [standalone]
| From | Jacob Sparre Andersen <jacob@jacob-sparre.dk> |
|---|---|
| Date | 2017-03-10 20:03 +0100 |
| Message-ID | <87d1dprm2l.fsf@adaheads.consafe1.org> |
| In reply to | #25896 |
Don Y <blockedofcourse@foo.invalid> writes: > What *single* (non-traditional) language feature do you find most > valuable in developing code? (and, applicable language if unique > to *a* language or class of languages) In my daily work I would say strong typing (as done in Ada and SPARK). When I'm doing embedded systems, being able to declare representations for a type (especially for enumerations) is very valuable. What really made me say "wow" to a programming language feature was when I first read about having tasking built into a language (and not as an add-on library) in a book about Ada 83. Greetings, Jacob -- "We will be restoring normality as soon as we are sure what is normal anyway."
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-03-10 19:48 +0000 |
| Message-ID | <o9uvv2$ag6$2@reader1.panix.com> |
| In reply to | #25978 |
On 2017-03-10, Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:
> Don Y <blockedofcourse@foo.invalid> writes:
>
>> What *single* (non-traditional) language feature do you find most
>> valuable in developing code? (and, applicable language if unique
>> to *a* language or class of languages)
>
> In my daily work I would say strong typing (as done in Ada and SPARK).
When you say "strong typing" you are also assuming "static typing"?
--
Grant Edwards grant.b.edwards Yow! I love ROCK 'N ROLL!
at I memorized the all WORDS
gmail.com to "WIPE-OUT" in 1965!!
[toc] | [prev] | [next] | [standalone]
| From | Jacob Sparre Andersen <jacob@jacob-sparre.dk> |
|---|---|
| Date | 2017-03-13 21:25 +0100 |
| Message-ID | <874lywsz3c.fsf@adaheads.consafe1.org> |
| In reply to | #25983 |
Grant Edwards <invalid@invalid.invalid> writes: > On 2017-03-10, Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote: >> Don Y <blockedofcourse@foo.invalid> writes: >>> What *single* (non-traditional) language feature do you find most >>> valuable in developing code? (and, applicable language if unique to >>> *a* language or class of languages) >> >> In my daily work I would say strong typing (as done in Ada and >> SPARK). > > When you say "strong typing" you are also assuming "static typing"? Yes. Strong, static typing. Jacob -- "Good enough for physics" -- Ridcully
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-10 13:03 -0700 |
| Message-ID | <o9v0le$gc7$1@dont-email.me> |
| In reply to | #25978 |
On 3/10/2017 12:03 PM, Jacob Sparre Andersen wrote:
> Don Y <blockedofcourse@foo.invalid> writes:
>
>> What *single* (non-traditional) language feature do you find most
>> valuable in developing code? (and, applicable language if unique
>> to *a* language or class of languages)
>
> In my daily work I would say strong typing (as done in Ada and SPARK).
>
> When I'm doing embedded systems, being able to declare representations
> for a type (especially for enumerations) is very valuable.
Yes. Though I want a mechanism by which I can "override" the type of
the object in this reference (even if that has to be done by invoking
a user-defined "cast operator").
And, the ability to apply operations to each of these types in a
somewhat orthogonal manner.
(why can't I reference the N'th element of a CONST list? or,
ALTER an element of a non-const list? I.e., why make lists
less capable than arrays?)
I think it takes a bit of "experience" (time in the trenches) to
truly appreciate strong typing. Early in your career, you are likely
to view it as a nuisance (hail, Pascal!).
There are also often significant conflicts trying to make "general
purpose" languages that can address application development AND
operating system/driver development; the concepts that make sense in
one domain don't always directly translate to the other.
> What really made me say "wow" to a programming language feature was when
> I first read about having tasking built into a language (and not as an
> add-on library) in a book about Ada 83.
The flip side of this is that it requires more of the run-time; a
greater set of constraints on the environment in which the code
can execute.
E.g., a language supporting tasking can "arrange" for atomic references
by simply not allowing the scheduler (that *it* controls) to be invoked
within such regions. It can elect to do this without the developer's
awareness -- which can have unexpected (though "correct") outcomes
if the developer isn't aware of those behind-the-scenes activities.
foo: array[HUGE_NUMBER] of rational
...
bar := foo
The same is true of integrating IPC/RPC, GC, etc. in the language.
Each constrains how the application can be deployed -- and requires
more intimate knowledge of the contract that the compiler is willing
to make with the support platform.
Increasingly, languages seem to want to bring their own sandbox to
the party -- in the guise of "helping" the developer. If you can't
use things "as is", then you're faced with a BIGGER problem as the
language designer may not have planned for the sandbox to be
dissociated from the code generator.
[I.e., often, its better to piece together smaller capabilities
than it is to try to extract those capabilities from a gestalt
for reimplementation]
[toc] | [prev] | [next] | [standalone]
| From | Jacob Sparre Andersen <jacob@jacob-sparre.dk> |
|---|---|
| Date | 2017-03-13 21:40 +0100 |
| Message-ID | <87zigorjtx.fsf@adaheads.consafe1.org> |
| In reply to | #25984 |
Don Y <blockedofcourse@foo.invalid> writes: > On 3/10/2017 12:03 PM, Jacob Sparre Andersen wrote: >> Don Y <blockedofcourse@foo.invalid> writes: >>> What *single* (non-traditional) language feature do you find most >>> valuable in developing code? (and, applicable language if unique to >>> *a* language or class of languages) >> >> In my daily work I would say strong typing (as done in Ada and >> SPARK). >> >> When I'm doing embedded systems, being able to declare >> representations for a type (especially for enumerations) is very >> valuable. > > Yes. Though I want a mechanism by which I can "override" the type of > the object in this reference (even if that has to be done by invoking > a user-defined "cast operator"). Luckily that is a part of Ada (but not SPARK). > I think it takes a bit of "experience" (time in the trenches) to truly > appreciate strong typing. That is probably true. > There are also often significant conflicts trying to make "general > purpose" languages that can address application development AND > operating system/driver development; the concepts that make sense in > one domain don't always directly translate to the other. Yes. In Ada this is in part handled by "profiles", where a run-time can be designed only to support a specific subset of the language. This means that you can target even rather small 8-bit MCUs with an Ada compiler, if you don't need the full language. As an example, one of my colleagues recently built a controller for a toy lighthouse. The executable is around 500 bytes in total (without playing around with compiler options). His estimate is that he probably could do the same in 200-300 bytes of assembler, so there is a cost to using a high-level language. The good part is that there are also benefits. >> What really made me say "wow" to a programming language feature was >> when I first read about having tasking built into a language (and not >> as an add-on library) in a book about Ada 83. > > The flip side of this is that it requires more of the run-time; a > greater set of constraints on the environment in which the code can > execute. Yes. > Increasingly, languages seem to want to bring their own sandbox to the > party -- in the guise of "helping" the developer. If you can't use > things "as is", then you're faced with a BIGGER problem as the > language designer may not have planned for the sandbox to be > dissociated from the code generator. Yes. But since Ada is intended for systems programming there are limits to how closed the sandbox can be, even if you can see the run-time as a kind of sandbox. The big challenge with using limited run-times (all the way down to zero-footprint) is that it also limits which libraries you can reuse. Jacob -- "Even god needs a bus to get there."
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-03-13 14:35 -0700 |
| Message-ID | <oa735c$24g$1@dont-email.me> |
| In reply to | #26056 |
On 3/13/2017 1:40 PM, Jacob Sparre Andersen wrote:
>> I think it takes a bit of "experience" (time in the trenches) to truly
>> appreciate strong typing.
>
> That is probably true.
I suspect it is true of many aspects of "programming" that aren't
apparent until you've been exposed to a fair bit of code (esp stuff
authored by OTHERS!)
In school ("university" for right-ponders), many of the issues that
were brought up as "worthy goals" in language design seemed somewhat
arbitrary (at that time). Over time, I've been chagrined at how
many of those comments/lessons have gained new voice!
"Ahhh.... *that's* what they meant!"
It is also significant to consider the nature of the "coder" in the
calculus. How high do you want to raise the bar -- and to what gain?
>> There are also often significant conflicts trying to make "general
>> purpose" languages that can address application development AND
>> operating system/driver development; the concepts that make sense in
>> one domain don't always directly translate to the other.
>
> Yes. In Ada this is in part handled by "profiles", where a run-time can
> be designed only to support a specific subset of the language. This
> means that you can target even rather small 8-bit MCUs with an Ada
> compiler, if you don't need the full language.
But, isn't this effectively not-including certain "modules"? Or,
will the parser then note that you've attempted to use something that
is not supported?
> As an example, one of my colleagues recently built a controller for a
> toy lighthouse. The executable is around 500 bytes in total (without
> playing around with compiler options). His estimate is that he probably
> could do the same in 200-300 bytes of assembler, so there is a cost to
> using a high-level language. The good part is that there are also
> benefits.
>
>>> What really made me say "wow" to a programming language feature was
>>> when I first read about having tasking built into a language (and not
>>> as an add-on library) in a book about Ada 83.
>>
>> The flip side of this is that it requires more of the run-time; a
>> greater set of constraints on the environment in which the code can
>> execute.
>
> Yes.
>
>> Increasingly, languages seem to want to bring their own sandbox to the
>> party -- in the guise of "helping" the developer. If you can't use
>> things "as is", then you're faced with a BIGGER problem as the
>> language designer may not have planned for the sandbox to be
>> dissociated from the code generator.
>
> Yes. But since Ada is intended for systems programming there are limits
> to how closed the sandbox can be, even if you can see the run-time as a
> kind of sandbox.
>
> The big challenge with using limited run-times (all the way down to
> zero-footprint) is that it also limits which libraries you can reuse.
Correct -- unless you can impose a discipline on the library designers.
I prefer leaner languages because they give me more flexibility in how
I address certain aspects (problems?) brought about by the language's
model without dictating how things *must* be done.
E.g., it was easy to make reentrant "standard libraries" (without
changing the calling semantics) for C decades ago because there
was no significant runtime "integration" of those libraries with
the "execution environment".
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-14 01:06 +0000 |
| Message-ID | <1mHxA.183734$0k4.78445@fx37.am4> |
| In reply to | #26058 |
On 13/03/17 21:35, Don Y wrote:
> In school ("university" for right-ponders), many of the issues that
> were brought up as "worthy goals" in language design seemed somewhat
> arbitrary (at that time). Over time, I've been chagrined at how
> many of those comments/lessons have gained new voice!
> "Ahhh.... *that's* what they meant!"
"When I was 14 I thought my father was an idiot. When
I became 21 I was amazed at how much he had learned
in the past 7 years"
Oft repeated to my daughter ;}
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-13 19:23 -0700 |
| Message-ID | <87o9x41tr5.fsf@nightsong.com> |
| In reply to | #26066 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > "When I was 14 I thought my father was an idiot. When I became 21 I > was amazed at how much he had learned in the past 7 years" One of the profs at my old school said at his retirement dinner "I've been teaching these kids freshman calculus for FORTY YEARS and they still don't get it!".
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-14 08:48 +0000 |
| Message-ID | <p7OxA.184699$0k4.2094@fx37.am4> |
| In reply to | #26068 |
On 14/03/17 02:23, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> "When I was 14 I thought my father was an idiot. When I became 21 I >> was amazed at how much he had learned in the past 7 years" > > One of the profs at my old school said at his retirement dinner "I've > been teaching these kids freshman calculus for FORTY YEARS and they > still don't get it!". :) We learned integration and differentials of polynomials except 1/x for exams at 15. I can still visualise the teacher taking a double period (80 mins) for each, deriving the concepts from first principles. OK, he was a good teacher (but not a good mathematician, he knew his limits!), but even so I've never understood why people think calculus is inherently difficult.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-14 02:14 -0700 |
| Message-ID | <87k27s1apu.fsf@nightsong.com> |
| In reply to | #26071 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > OK, he was a good teacher (but not a good mathematician, he knew his > limits!), but even so I've never understood why people think calculus > is inherently difficult. Don't know if that was a pun, but yes, the usual stumbling block is understanding limits (for every epsilon there is a delta etc). It's often the first encounter students have with that type of treatment.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2017-03-14 09:33 +0000 |
| Message-ID | <ONOxA.104277$Iy2.30127@fx28.am4> |
| In reply to | #26072 |
On 14/03/17 09:14, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> OK, he was a good teacher (but not a good mathematician, he knew his >> limits!), but even so I've never understood why people think calculus >> is inherently difficult. > > Don't know if that was a pun, but yes, the usual stumbling block is > understanding limits (for every epsilon there is a delta etc). It's > often the first encounter students have with that type of treatment. It wasn't /intended/ to be a pun; too early in the morning :) That teacher realised while doing maths at university that he was never going to be a professional mathematician. OTOH the teacher who had invented a new way of generating Pythagorean triads was a seriously cryptic teacher.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web