Your SlideShare is downloading.
×

×

Saving this for later?
Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.

Text the download link to your phone

Standard text messaging rates apply

Like this presentation? Why not share!

- Counting Triangles and the Curse of... by vsergei 1700 views
- Membase Introduction by Membase 6267 views
- The Alpha Version of a Wundering Mo... by Bernard Goldbach 611 views
- Digital Learning Futures by Steve Wheeler 64862 views
- The Relationship of Cross-Cultural ... by Russ Merz, Ph.D. 1353 views
- Bits of Evidence by Greg Wilson 66450 views

3,516

Published on

In 1936, Alan Turing published a famous model of computation. However, it is in need of revision in part because Moore's Law for computation now takes the following form: …

In 1936, Alan Turing published a famous model of computation. However, it is in need of revision in part because Moore's Law for computation now takes the following form:

* Clock frequency is no longer increasing exponentially.

* Instead, the number of cores is increasing exponentially.

This talk explains why Turing's model is becoming obsolete (both in theory and practice) and how to program the many cores.

In turn, programming the many cores provides technology for inconsistency robustness: information system performance in the face of continually pervasive inconsistencies---a shift from the previously dominant paradigms of inconsistency denial and inconsistency elimination attempting to sweep them under the rug.

Further reading:

"ActorScript(TM) extension of C#(TM), Java(TM), Objective C(TM), and JavaScript(TM)” ArXiv 1008.2748

"Actor Model for Discretionary Adaptive Concurrency" ArXiv. 1008.1459

"Incompleteness Theorems: The Logical Necessity of Inconsistency" Google Knol

No Downloads

Total Views

3,516

On Slideshare

0

From Embeds

0

Number of Embeds

0

Shares

0

Downloads

0

Comments

0

Likes

3

No embeds

No notes for slide

- 1. How to Program the Many CoresforInconsistency Robustness<br />Carl Hewitt<br />©2011<br />All rights reserved except<br />Stanford has the right to distribute video & slides<br />Slides updated June 5, 2011<br />
- 2. Turing’s Model of Computation<br />Turing [1936] stated:<br />the behavior of the computer at any moment is determined by the symbols which he [the computer] is observing, and his ‘state of mind’ at that moment<br />there is a bound B to the number of symbols or squares which the computer can observe at one moment. If he wishes to observe more, he must use successive observations.<br />
- 3. Triumph of Turing’s Model<br />Turing [1948]:<br />LCMs[logical computing machines: Turing's expression for Turing machines] can do anything that could be described as … "purely mechanical"…This is sufficiently well established that it is now agreed amongst logicians that "calculable by means of an LCM" is the correct accurate rendering [of phrases like “purely mechanical”]<br />
- 4. Impossibility ofUnbounded Nondeterminism<br />Now the set of initial segments of execution sequences of a given nondeterministic program P, starting from a given state, will form a tree. <br />The branching points will correspond to the choice points in the program. <br />Since there are always only finitely many alternatives at each choice point, the branching factor of the tree is always finite.<br />Now König's lemma says that if every branch of a finitary tree is finite, then so is the tree itself. <br />In the present case this means that if every execution sequence of Pterminates, then there are only finitely many execution sequences. <br />So if an output set of Pis infinite, it must contain a nonterminating computation.<br />---Plotkin [1976]<br />
- 5. Bounded Nondeterminism in CSP<br />[X :: Z!stop( )<br /> ||<br /> Y :: guard:boolean; guard:=true;<br /> *[guard Z!go( ); Z?guard]<br /> ||<br /> Z :: n:integer;n:=0;<br /> continue:boolean; continue:=true;<br /> *[X?stop( ) continue:=false; Y!continue;<br /> []<br /> Y?go( )n:=n+1; Y!continue]<br />]<br />
- 6. Abstraction<br />Any problem in computer science can be solved by adding another level of abstraction.<br /> --paraphrase of Alan Perlis<br />
- 7. Actors [IJCAI’73]<br />Organization: The local storage of an Actor can include addresses only<br />that were provided when it was created<br />that have been received in messages<br />Operation:In response to a message received, an Actor can<br />create more Actors<br />send messages to addresses in:<br />the message it has just received<br />its local storage<br />
- 8. Acknowledgement<br />Important contributions to the semantics of Actors have been made by: Gul Agha, Beppe Attardi, Henry Baker, Will Clinger, Irene Greif, Carl Manning, Ian Mason, Ugo Montanari, Maria Simi, Scott Smith, Carolyn Talcott, Prasanna Thati, and Aki Yonezawa. <br />Important contributions to the implementation of Actors have been made by: Bill Athas, Russ Atkinson, Beppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Nanette Boden, Jean-Pierre Briot, Bill Dally, Blaine Garst, Peter de Jong, Jessie Dedecker, Ken Kahn, Henry Lieberman, Carl Manning, Mark S. Miller, Tom Reinhardt, Chuck Seitz, Richard Steiger, Dan Theriault, Mario Tokoro, Darrell Woelk, and Carlos Varela.<br />
- 9. Actor Misunderstandings<br />Question:Isn't procedure calling faster than message passing?<br />Answer: No, they are equivalent.<br />Question:Doesn't every Actor have a X (where X is thread, mailbox, queue, etc.)?<br />Answer: Is X an Actor?<br />Question:What is an Actor?<br />Answer: Anything that obeys the axioms!<br />
- 10. Let head scratching begin!<br />Quantum Actors<br />metaCompilation (reducing friction)<br />I think I can safely say that nobody understands quantum mechanics.<br />-- Richard Feynman<br />
- 11. Actor Unbounded Nondeterminism<br />Unbounded ~~<br /> behavior{<br /> start -> let(c = create Counter(count =0, continue = true) )<br /> {c.go , c.stop }}<br />Counter ~~<br /> behavior has (count↦Integer , continue↦Boolean ) {<br /> stop -> count alsoBecome (continue = false)} ||| <br /> go -> continue ?? {true -> exit go alsoBecome(count =count+1) else void}}<br /> <br />
- 12. Computational Representation Theorem<br />The denotation DenoteS of a closed system Srepresents all the possible behaviors of S as <br />DenoteS = ⊔iNProgressionSi(⊥S)<br />where ProgressionSis an approximation function that takes a set of partial behaviors to their next stage and ⊥S is the initial behavior of S.<br />
- 13. Devil in Details<br />SimpleGCDqueue ~~<br />behavior queues(q) {<br />dispatch_sync(theBlock)-><br />passThru(q)<br />hole theBlock( ) <br />thenvoidalsoDequeueq |||<br />this.dispatch_async(theBlock)-><br /> this ↞passThru (q)<br />hole theBlock( ) <br />then void alsoDequeue q}<br />
- 14. Domain Specific Computation<br />Implementing postponed execution:<br /><<<postponeExpression::expr>>> ~~<br />eval(e) -><br />let (v=expr.eval(e))<br /> Type(v)::.m ↣<br />v↢malsoBecomeForwardTo(v)<br />ForwardTo(v) ~~ <br /> Type(v)::.m ↣v↢m<br />
- 15. Interoperation with Legacy<br />
- 16. Concurrency Crisis<br />Clock frequency is not going up!<br />Number of cores is growing exponentially!<br />
- 17. No More Free Lunch<br />Frequency: past sins haunt us (e.g. JavaScript)<br />Many-core computation: unforgiving (e.g.bottlenecks, throttling, testing, etc.)<br />
- 18. Hope<br />...and you will find someday that, after all, it isn’t as horrible as it looks.<br /> --Richard Feynman<br />
- 19. How toProgram the Many Cores<br />Physically:<br />Actors<br />Practically:<br />Organizational Programming <br />
- 20. Organizational Programming<br />Authority<br />Accountability<br />Collaboration<br />
- 21. Organizational Scalability<br />Executive<br />info<br />info<br />info<br />Sales<br />info<br />info<br />Engineering<br />Accounting<br />info<br />Hierarchical parallelism<br />Heterarchical concurrency<br />
- 22. Inconsistency by Design<br />Executive<br />info<br />info<br />info<br />Sales<br />info<br />info<br />Engineering<br />Accounting<br />info<br />Where you sit<br /> is<br />where you stand!<br />
- 23. Economics<br />Strategic inconsistency:<br />Classical microeconomics<br />individual economic transactions (i.e. “propensity to barter, truck and exchange one thing for another” [Adam Smith]) lead to generally desirable outcomes<br />Keynesian macroeconomics<br />fraud, externalities, and monetary instabilities require government regulation<br />
- 24. Addiction<br />Step 1 in Twelve Step programs for recovery is that addicts admit that they are powerless over their addictions.<br />
- 25. Mathematical Logic<br />Wittgenstein: Indeed, even at this stage, I predict a time when there will be mathematical investigations of calculi containing contradictions, and people will actually be proud of having emancipated themselves from consistency.<br />Turing: The real harm will not come in unless there is an application, in which a bridge may fall down or something of that sort…. You cannot be confident about applying your calculus until you know that there are no hidden contradictions in it.<br />Wittgenstein: There seems to me an enormous mistake there. ... Suppose I convince [someone] of the paradox of the Liar, and he says, 'I lie, therefore I do not lie, therefore I lie and I do not lie, therefore we have a contradiction, therefore 2x2 = 369.' Well, we should not call this 'multiplication,' that is all...<br />
- 26. Direct LogicTM<br />Minimal fix to Classical Mathematical Logic*<br />DirectInference (no contrapositive bug for inference)<br />DirectArgumentation (inference directly expressed)<br />Inconsistency Robustness<br />Two-way Deduction Theorem for natural deduction<br />Boolean Equivalences hold<br />Self-refutation<br />Incompleteness self-provable<br />*Published in arXiv:0812.4852<br />
- 27. Language Games<br />This sentence P cannot be inferred<br />P ⇔ ⊬RussellP <br />
- 28. Proof of Incompleteness<br />Suppose⊢RussellP<br />⊢Russell⊬RussellPfrom the hypothesis<br />becauseP ⇔⊬RussellP <br />⊢Russell⊢RussellP from the hypothesis<br />by Adequacy<br />But 1.and 2.are a contradiction in Russell . <br />Consequently, ⊢Russell⊬RussellP follows from proof by contradiction in Russell .<br />
- 29. WittgensteinIncompleteness means Inconsistency<br />Let us suppose I prove the unprovability (in Russell’s system[Russell )] ) of P [⊢Russell⊬RussellPwhereP⇔⊬RussellP];then by this proof I have proved P[⊢RussellP].<br />Now if this proof were one in Russell’s system[⊢Russell⊢RussellP]—I should in this case have proved at once that it belonged [⊢RussellP] and did not belong [⊢RussellPbecauseP⇔⊢Russell P]to Russell’s system.—That is what comes of making up such sentences.<br />But there is a contradiction here!—Well, then there is a contradiction here[in Russell]. Does it do any harm here?<br />
- 30. Demonization of Wittgenstein<br />It’s amazing that Turing could get anything out of discussions with somebody like Wittgenstein.<br />…<br />Wittgenstein did “not” understand it [1st incompleteness theorem] (or pretended not to understand it). He interpreted it as a kind of logical paradox, while in fact is just the opposite…<br />…<br />He [Wittgenstein] has to take a position when he has no business to do so. For example, “you can’t derive everything from a contradiction.” He should try to develop a system of logic in which that is true<br />----Kurt Gödel <br />
- 31. In the Argumentation lies the Power<br />A╟Tmeans that Ais an argument for in T<br />Example:<br />Redfield╟Biochemistry (NASA⊮Biochemistry SupportsLife[Arsenic])<br /> <br />Felisa Wolfe-Simon, et. al. A bacterium that can grow by using arsenic instead of phosphorus Science. Dec. 2, 2010.<br />Rosemary Redfield. Arsenic-associated bacteria (NASA's claims) RR Research blog. Dec. 6, 2010.<br />Semantics of Direct Logic<br />
- 32. Openness to Further Argumentation<br />A good scientist is never 'certain'. <br />Lack of certainty is precisely what makes conclusions more reliable than the conclusions of those who are certain: because the good scientist will be ready to shift to a different point of view if better elements of evidence, or novel arguments emerge. <br />Therefore certainty is not only something of no use, but is in fact damaging, if we value reliability.<br /> --Carlo Rovelli<br />
- 33. Inconsistency RobustReasoning<br />Large-scale information systems are chock full of inconsistencies<br />Can’t get rid of them<br />Relational Data Base*<br />*replacement in the works<br />
- 34. Inconsistency Euphemisms<br />Anomaly<br />Bug<br />Feature (ironic)<br />Glitch<br />Outlier<br />Paradox<br />
- 35. Relational Physics<br />Relational physics discards the notions of absolute state of a system, absolute value of its physical quantities, or absolute event.<br />State and physical quantities refer always to the interaction, or the relation, among multiple systems. <br />Nevertheless, relational physics is a complete description of reality.<br />
- 36. What is reality?<br />Quantum mechanics is a theory about the physical description of physical systems relative to other systems, and this is a complete description of the world.<br />---Carlo Rovelli<br />
- 37. Interaction creates Reality<br />Do not keep saying to yourself, if you can possibly avoid it, "But how can it be like that?" because you will go "down the drain," into a blind alley from which nobody has yet escaped.<br />---Richard Feynman<br />
- 38. Inconsistency Robustness 2011<br />Inconsistency robustnessis information system performance in the face of continually pervasive inconsistencies---a shift from the previously dominant paradigms of inconsistency denialand inconsistency eliminationattempting to sweep them under the rug.<br />Inconsistency robustness is both an observed phenomenon and a desired feature:<br />It is an observed phenomenon because large information systems are required to operate in an environment of pervasive inconsistency. How are they doing?<br />It is a desired feature because we need to improve the performance of large information systems.<br />
- 39. Inconsistency Robustness 2011Program Committee (½)<br />Fei Xia, Washington Linguistics<br />Mary-Anne Williams, Sydney Innovation and Enterprise Research Lab<br />Mario Tokoro, Sony CSL<br />Jamie Taylor, Google<br />Markus Strohmaier, Graz CS<br />Tom Stace, Queensland Physics<br />Yuval Shachar, Ben-Gurion Information Systems Engineering<br />Erik Sandewall, Linköping Computer and Information Science<br />Neil Rubens, Electro-Communications Information Systems<br />Carlo Rovelli, Marseille Centre de Physique Theorique de Luminy<br />Greg Restall, Melbourne Philosophy<br />Kay Prüfer, Max-Planck Institute for Evolutionary Anthropology<br />Stanley Peters, Stanford CSLI<br />Peter Neumann, SRI <br />Fanya S. Montalvo, independent consultant<br />
- 40. Inconsistency Robustness 2011Program Committee (½)<br />Subhasish Mitra, Stanford CS and EE<br />Joao Marcos, Rio Grande de Norte Informatics and Applied Mathematics<br />Ben Kuipers, Michigan CS<br />Andrei Khrennikov, Linnaeus Applied Mathematics<br />Mike Huhns, South Carolina Electrical & Computer Engineering<br />Chuck House, Stanford Media X<br />Robert Hoehndorf, Cambridge Genetics<br />Carl Hewitt (chair), emeritus MIT EECS, visiting Stanford CS<br />Ted Goldstein, UCSC Bioinformatics and Biomolecular Engineering<br />Elihu M. Gerson, Tremont Research Institute<br />Mike Genesereth, Stanford CS<br />Giacomo Mauro D'Ariano, Pavia Quantum Information, Mechanics, & Optics<br />Rainer Brendle, SAP<br />Francesco Berto, Aberdeen Philosophy<br />Gil Alterovitz, MIT EECS and Harvard Medical School<br />
- 41. Inconsistency Robustness 2011<br />Important dates<br />February 15, 2011: Due date of extended abstracts for position statements, overviews, panel proposals, and technical papers (consisting of approximately 2000 words in PDF format ). Rather than have authors try to pigeon hole their work by key word ahead of time, we plan to distribute submissions to referees on the basis of the extended abstract.<br />March 31, 2011: Due date of full technical papers, revised panel proposals and position statements. A hard limit on size will not be imposed because the proceedings will be produced electronically. So anything up to about 25K words would be possible. Of course, the length must be suitable to the subject matter.<br />May 30, 2011: Notification of acceptance, conditional acceptance, or non-acceptance<br />August 16-18, 2011: Symposium at Stanford<br />August 19, 2011: Invited workshop for active researchers, practitioners, and sponsors<br />Submissions should be made via the EasyChair website at:<br />http://submit.robust11.org<br />

Be the first to comment