Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1429
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: language design models, was Writing A Plain English Compiler |
| Date | 2014-11-09 14:30 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <14-11-021@comp.compilers> (permalink) |
| References | <14-11-004@comp.compilers> <14-11-005@comp.compilers> <14-11-012@comp.compilers> <14-11-018@comp.compilers> |
On Sat, 08 Nov 2014 10:48:09 -0600, Joshua Cranmer ? <Pidgeot18@verizon.invalid> wrote: >On 11/7/2014 3:23 PM, George Neuner wrote: >I think actor models (which is basically CSP?) appear to be winning out, >but, as you say, they're not completely sufficient. If I had to make a >bet, it would be on an actor-based model with some support for >cross-thread shared data collections. But I would be hesitant to wager >very much even on that. Yes, actors are a form of CSP. And I agree that CSP in whatever form currently is the best option available. The major difficulty with it is handling complex coordination patterns. Special purpose coordination languages are better able to handle complex communication patterns, but they rely on temporal decoupling - i.e. they have no sense of real world time - and, so far, none has proven to scalable beyond a few thousands of actors [which is not a lot for a complex system]. >You've failed to mentioned transactional memory. My MS degree is in database technology. I can see potential for transactional memory, but currently HTM is non-scalable, confined to shared-memory systems, and hard to use effectively due to limitations on the size of managed memory, the number of concurrent transactions supported and the less-than-friendly isolation model that is implemented. On chip HTM essentially works through an extension of the cache coherence protocol to fail on X-access to a line owned by another core rather than to arbitrate access to it. TM needs to track a great deal of meta information - minimally the entire set of written lines on a per transaction basis - which severely limits the size of memory that can be managed. Existing HTM implementations provide only a handful of kilobytes. Implementations vary as to whether they also fail on read of a dirty line owned by a concurrent transaction. Most don't and thus (in database terms) provide only uncommitted-read isolation. Uncommitted-read is the most basic isolation level and the most difficult to work with ... essentially every TM hosted value has to be considered (C) volatile. STM layered on top of HTM can provide more programmer friendly isolation and also can address the HTM size issues. But the STM layer creates additional register and/or cache pressure on transactions that can't tolerate the limitations of the underlying HTM [which in most uses is likely to be most transactions.] Pure STM can (at least theoretically) support clusters as well as shared memory, but STM is slow even in shared memory: performance similar to that of an in-memory DBMS, a bit faster because STM does not also have to address data persistence. Again, TM has value but is not a scalable solution. >There are also things like Concurrent Collections which I'm >hard-pressed to place, particular since I'm vague on the details >(maybe dataflow?). CC is just a thread safe collection. >> Most natural languages are a hindrance to logic because they are >> inherently ambiguous. There is some anecdotal evidence that Sumerian >> might have been sufficiently unambiguous to program with, but the >> issue is moot because no one today speaks it. > >There's an issue not strictly related to ambiguity that I realized >when reading Gerry's examples. English (and presumably other natural >languages, but I'm not enough of a linguist to say with any >confidence) allows you to reliably refer to one, sometimes two, things >without naming them. At the same time, it makes it cumbersome to name >a temporary object. Exactly. English in particular has slippery pronouns: the "royal" "we" is singular; "you", "they" and "it" all may be singular or plural depending on context. [The plural use of "it" is rare in polite conversation, but is relatively common in exasperation and vulgarity: e.g., "Screw it!" may be a multiple reference.] >I prefer Brainfuck as the go-to "unprogrammable" language. :-) A neat simulation of a Turing tape machine. IIRC, there are several compilers that target it as a bytecoded interpreter. Very small, but still very powerful. George
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-04 15:50 -0600
Re: Writing A Plain English Compiler Joshua Cranmer 🐧 <Pidgeot18@verizon.net> - 2014-11-05 00:54 -0600
Re: Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-06 18:52 -0600
Re: Writing A Plain English Compiler Joshua Cranmer 🐧 <Pidgeot18@verizon.net> - 2014-11-07 22:54 -0600
Re: Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-08 02:41 -0600
Re: Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-08 03:46 -0600
Re: Writing A Plain English Compiler "BartC" <bc@freeuk.com> - 2014-11-09 01:16 +0000
Re: Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-10 14:37 -0600
Re: self-hosting, was Writing A Plain English Compiler Richard Hable <portempa@aon.at> - 2014-11-11 19:50 +0100
Re: self-hosting, was Writing A Plain English Compiler "BartC" <bc@freeuk.com> - 2014-11-11 23:33 +0000
Re: self-hosting, was Writing A Plain English Compiler anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-12 08:46 +0000
Re: self-hosting, was Writing A Plain English Compiler "BartC" <bc@freeuk.com> - 2014-11-12 11:15 +0000
Re: self-hosting, was Writing A Plain English Compiler anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-11-12 08:40 +0000
Re: Writing A Plain English Compiler "BartC" <bcas@freeuk.com> - 2014-11-07 11:36 +0000
Re: Writing A Plain English Compiler George Neuner <gneuner2@comcast.net> - 2014-11-07 16:23 -0500
Re: Writing A Plain English Compiler Richard Hable <portempa@aon.at> - 2014-11-08 17:22 +0100
Re: Writing A Plain English Compiler Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-11-08 10:48 -0600
Re: language design models, was Writing A Plain English Compiler George Neuner <gneuner2@comcast.net> - 2014-11-09 14:30 -0500
Re: language design models, was Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-10 03:29 -0600
Re: Writing A Plain English Compiler Tomasz Kowaltowski <tk@ic.unicamp.br> - 2014-11-10 09:13 -0200
Re: Writing A Plain English Compiler "Gerry Rzeppa" <gerry.rzeppa@pobox.com> - 2014-11-10 17:19 -0600
Re: matching tasks to languages, was Writing A Plain English Compiler Gene Wirchenko <genew@telus.net> - 2014-11-10 15:37 -0800
Re: Writing A Plain English Compiler Martin Ward <martin@gkc.org.uk> - 2014-11-10 22:56 +0000
Re: Writing A Plain English Compiler "BartC" <bcas@freeuk.com> - 2014-11-07 11:39 +0000
Re: Writing A Plain English Compiler "BartC" <bc@freeuk.com> - 2014-11-08 00:35 +0000
Fundamentals for a Compiler and Language (was: Writing A Plain English Compiler) federation2005@netzero.com - 2014-12-29 13:30 -0800
csiph-web