<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle29
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>How do Pharo’s and Squeak’s VMs differ? I thought OpenSmalltalkVM was the common VM. I also read something recently from Eliot that seemed to indicate a fork. </span><o:p></o:p></p><p style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I thought Pharo had the new tools, like GT, but I’m not sure. I don’t follow Squeak anymore. </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Pharo may, it is fast moving and they drop historical support as new tools come online. I don't follow Pharo anymore. There is a common VM but the builds are separate.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I mostly don’t follow Squeak, but do follow Pharo on and off, and may port as soon as the GUI formatting problems are fixed or are fixable by my own use of Spec2. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I tried Squeak 5.3 a few days ago for the first time in 16 years. It has a nicer induction/setup process, but menus were malfunctioning (rending spastically) before I finished getting reacquainted with the new surface. I don’t have time these days to finish playing with it. I may get back to it, but why do that if the Pharo GUI is more advanced? Besides avoiding Pharo framework bloat and confusion, what about Squeak compels you to use it instead of Pharo for VM dev?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><a href="https://ponylang.zulipchat.com/#narrow/search/lzip">https://ponylang.zulipchat.com/#narrow/search/lzip</a></span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Here was the thread reference I was unable to follow. That you provided it around a discussion of why the CogVM was "not acceptable". Say what? So we are adding a near real-time requirement? I would suggest that the CogVM meets near real-time requirements. The longest GC pause may be 100 ms let us say. That is still near real-time.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>5 to 10 ms is what I need. Even Pony’s GCing barely keeps up with this, but the effect is smoother because all actors are running all the time, except when each actor GCs its own little heap. The timing issue is more about smoothness and predictably small tail latencies at the <u>right end of a very steep and narrow latencies distribution</u>. <o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Read the thread above and watch the video to sharper your imagination and mental model, somewhat, for <u>how real object-oriented programs work <b>at run-time</b>.</u> The video details are fuzzy, but you can get a good feel for message flow. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Exactly the way Smalltalk operates at runtime. Smalltalk was made with the benefit that the core message passing paradigm is the exact model of interaction we see remotely: message passing. Squeak is a native message passing machine.<br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>This should have happened first in Smalltalk. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>It did.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>No, the <b>idea</b> of asynchronous messaging did, but not the implementation. We’re not discussing the same phenomenon.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Smalltalk does not in general have asynchronous messaging between all actors all the time. It doesn’t even have actors by default in the core language. You have to design them as an afterthought. That’s just wrong.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Smalltalk does not have true actors as a baseline implementation of the OO programming paradigm. You have to engineer it if you want it, and it doesn’t scale well with the green threads. Just non-blocking FFI doesn’t count; that is necessary and good, but not sufficient.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Async messaging: that was the original vision, and it still works best for state-machine construction, because no blocking and no read/write-barriers are needed. Here’s the gist, and you’ll find that Kay says the same in his talks, repeatedly (apparently no one listens and thinks about using it): <u>advance the state of the state-machine only by exchange of asynchronous messages between actors. </u> That’s the whole thing. Then you have the tooling on top of that to make the SM building systematic, reliable, and pleasant. That’s missing too, and must be done, as well, or the core idea is hard to use fully—which is largely why we program as we do today. Most programmers are old dogs coding in the same old wrong way, because the new way, which is very much better, is even harder to do without the right tools and guarantees, and we don’t have those yet. Functional programming (great for many domains) is a much better choice for general-purpose programming than the actor model <u>with the current actor-based tools.</u> <o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'>The performance of the GC in the CogVM is demonstrated with this profiling result running all Cryptography tests. Load Cryptography with this script, open the Test Runner select Cryptography tests and click 'Run Profiled':<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:1.0in'>Installer ss<br> project: 'Cryptography';<br> install: 'ProCrypto-1-1-1';<br> install: 'ProCryptoTests-1-1-1'.<o:p></o:p></p></blockquote><p style='margin-left:1.0in'>Here are the profiling results.<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:1.0in'> - 12467 tallies, 12696 msec.<br><br>**Leaves**<br>13.8% {1752ms} RGSixtyFourBitRegister64>>loadFrom:<br>8.7% {1099ms} RGSixtyFourBitRegister64>>bitXor:<br>7.2% {911ms} RGSixtyFourBitRegister64>>+=<br>6.0% {763ms} SHA256Inlined64>>processBuffer<br>5.9% {751ms} RGThirtyTwoBitRegister64>>loadFrom:<br>4.2% {535ms} RGThirtyTwoBitRegister64>>+=<br>3.9% {496ms} Random>>nextBytes:into:startingAt:<br>3.5% {450ms} RGThirtyTwoBitRegister64>>bitXor:<br>3.4% {429ms} LargePositiveInteger(Integer)>>bitShift:<br>3.3% {413ms} [] SystemProgressMorph(Morph)>>updateDropShadowCache<br>3.0% {382ms} RGSixtyFourBitRegister64>>leftRotateBy:<br>2.2% {280ms} RGThirtyTwoBitRegister64>>leftRotateBy:<br>1.6% {201ms} Random>>generateStates<br>1.5% {188ms} SHA512p256(SHA512)>>processBuffer<br>1.5% {184ms} SHA256Test(TestCase)>>timeout:after:<br>1.4% {179ms} SHA1Inlined64>>processBuffer<br>1.4% {173ms} RGSixtyFourBitRegister64>>bitAnd:<br><br>**Memory**<br> old -16,777,216 bytes<br> young +18,039,800 bytes<br> used +1,262,584 bytes<br> free -18,039,800 bytes<br><br>**GCs**<br> full 1 totalling 86 ms (0.68% uptime), avg 86 ms<br> incr 307 totalling 81 ms (0.6% uptime), avg 0.3 ms<br> tenures 7,249 (avg 0 GCs/tenure)<br> root table 0 overflows<o:p></o:p></p></blockquote><p class=MsoNormal style='margin-left:1.0in'>As shown, 1 full GC occurred in 86 ms<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Not acceptable. Too long.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>What is your near real-time requirement?<br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>5 to 10 ms pauses per actor, not globally whilst all actors wait. Think <i>smooth.<o:p></o:p></i></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:1.0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span>and 307 incremental GCs occurred for a total of 81 ms. All of this GC activity occurred within a profile run lasting 12.7 seconds. The total GC time is just 1.31% of the total time. Very fast.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Not acceptable. Too long. And, worse, it won’t scale.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>I am unaware of any scaling problems. In Networking, 1000s of concurrent connections are supported. In computations, 10,000s objects. What are your timing requirements? Each incremental took a fraction of a millisecond to compute: <b>264 microseconds.</b><br><br><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> The problem is not the percentage; it’s the <u>big delays amidst other domain-specific computation.</u> These times must be much smaller and spread out across many pauses during domain-specific computations.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>See the 307 incremental GCs? These are 264 microsecond delays spread out across <span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>domain-specific computations.</span> <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>We have to watch definitions and constraints carefully. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Where memory management is concerned, this thread tries to compare the merits of the two extremes: per-actor memory management, as in the Orca (Pony practically), and global stop-the-world (StW) collection as in a classical Smalltalk. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>You seem to be presenting something intermediate above, where there are segments that are GCed in turn. Are you stopping all domain threads/messaging during the incremental GCs, or just the ones for objects in a certain section of the heap? Or, are the heap partitions divided by more traditional criteria, like object size and lifespan? What is the spacing between the incremental GCs? <span style='color:#00B0F0'>Steady frequency of pauses, smallness of pauses, and <u>narrowness of distribution of longest pauses</u>, especially, are the most important criteria. <o:p></o:p></span></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> No serious real-time apps can be made in this case.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Of course they can. Model the domain as resilient & accepting of 100 ms pauses, for full GCs. It may be more could be done to the CogVM for near real-time, I am not very knowledgeable about the VM.<br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>We are discussing different app domains.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I can’t use 100 ms pauses in my real-time app. I need sub 10 ms pauses. Again even Pony needs better GCing, but the report I have from Rocco shows more or less acceptable pauses. He was kind enough to run the program again with the GC stats turned on. I’ll try to find the document and attach it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I suggest studying the Pony and Orca material, if the video and accompanying explanation don’t clarify Pony-Orca speed and scale. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Yeah, the video did not suggest anything other than using message passing. <o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>You can’t miss this detail; it’s almost everything that matters: <b><u>asynchronous</u></b><u> message passing between all actors, all the time, on the metal, not as an afterthought, with a guarantee of no data-races.</u><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>I could not find the thread discussing GC. Would you please post the specific URL to get to that resource, please? I do not want to guess any longer.<br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I don’t get it. It works for me in a newly opened tab. I don’t know what the problem is. Zulip should work for you as it does for me. Login to your Zulip and search on ‘Rocco’. You’ll see Rocco’s stuff, which is largely about the parsing app he has. Better, just ask for the info you want. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Why would the idea of ‘remote’ enter here? The execution scope is an OS process. Pony actors run on their respective threads in one OS process. Message passing is zero-copy; all “passing” is done by reference. No data is actually copied.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>In the SqueakELib Capabilities model, between Vats (in-process, inter-process & inter-machine-node) most references to Actors are remote and then we have zero-copy. Sometimes we need to pass numbers/strings/collections and those are pass-by-copy.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Yeah, the copying won’t work well. Just never do it, at least not in one OS process. 0-copy messaging is the rule in Pony. Even this may not matter much eventually. The MM is being reworked with the hope of eliminating all consensus-driven messaging, which can be expensive, even if only transiently, on highly mutable object sets. See the Verona project, which seems to be slowly converging with Pony: <a href="https://github.com/microsoft/verona/blob/master/docs/faq.md">https://github.com/microsoft/verona/blob/master/docs/faq.md</a>. The Orca memory management core-weakness is still the fact that all messaging must be traced so that the collector knows which actors still refer to a given object. This is true of all concurrent collectors. That problem—and it’s a big problem-- goes away completely if the Pony runtime becomes Verona-ized.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> The scheduler interleaves all threads needing to share a core if there are more actors than cores. Switching time for actor threads, in that case, is 5 to 15 ns. This was mentioned before. Opportunistic work stealing happens. That means that all the cores stay as busy as possible if there is any work at all left to do. All of this happens by design without intervention or thought from the programmer. You can read about this in the links given earlier. I suggest we copy the design for Smalltalk.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Which specific links? Could you send a summary email?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Not now, maybe later. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Some of this data comes from lectures by Clebsch, but you’ll find most of the meat in the Pony papers, for which links can be found on the community page: <a href="https://www.ponylang.io/community/">https://www.ponylang.io/community/</a> . <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I think the Pony runtime is still creating by default just one OS process per app and as many threads as needed, with each actor having only one thread of execution by definition of what an actor is (single-threaded, very simple, very small). A scheduler keeps all cores busy, running and interleaving all the current actor threads. Message tracing maintains ref counts. A cycle-detector keep things tidy. Do Squeak and Pharo have those abilities?</span><o:p></o:p></p></blockquote></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>In the case of remote capability references, there is reference counting. This occurs inside the Scope object, there are 6 tables: 2 for third party introduction (gift tables), 2 for outgoing references (#answers & #export) and 2 for incoming references (#questions & #imports). These tables manage all the remote reference counting. Once again between any two Vats (in-process, inter-process & inter-machine-node). There are 2 GC messages sent back from a remote node (GCAnswer & GCExport) for each of the outgoing references. Alice has a reference to a remote object in Bob, when the internal references to Alice's reference end and the RemoteERef is to be garbage collected a GC message is sent to the hosting Vat, Bob.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>In Squeak/Pharo do all actors stop for the GCs, even for the smaller incremental ones?<o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><p style='margin-left:.5in'>I have some experience with state-machine construction to implement security protocols. In Squeak, DoIt to this script to load Crypto and ParrotTalk & SSL (currently broken) and see some state-machines:<o:p></o:p></p><p style='mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'>Installer ss<br> project: 'Cryptography'; install: 'ProCrypto-1-1-1';<br> project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';<br> project: 'Cryptography'; install: 'CapabilitiesLocal';<br> project: 'Oceanside'; install: 'ston-config-map';<br> project: 'Cryptography'; install: 'SSLLoader;<br> project: 'Cryptography'; install: 'Raven'.<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Pony has Actors. It also has Classes. The actors have behaviours. Think of these as async methods. <u>Smalltalk would need new syntax for Actors, behaviours, and the ref-caps that type the objects.</u> Doing this last bit well is the task that concerns me most.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Which? "ref-caps that type the objects"? What does that mean?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>This is the best page on ref-caps: <a href="https://www.ponylang.io/learn/#reference-capabilities">https://www.ponylang.io/learn/#reference-capabilities</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The six ref caps define which objects can mutate which others at compile time. Ref-caps provide the guarantees. The ref caps connect the code of your language (Pony so far) to the MM runtime at compile time.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> With the CapabilitiesLocal I pointed you to, we have an Actor model with async message passing to behaviors of an Actor. Squeak has Actors supporting remote references (3-way introductions, through the gift tables is broken. Remote references from Alice to Bob is working. See the tests in ThunkHelloWorldTest: #testConnectAES, #testConnectAESBufferOrdering & #testConnectAESBuffered.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'>that exists for Smalltalk capabilities and Pony capabilities. In fact, instead of talking about actors, concurrency & parallel applications, I prefer to speak of a capabilities model, inherently on an event loop which is the foal point for safe concurrency.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I suggest a study of the Pony scheduler. There are actors, mailboxes, message queues, and the scheduler, mainly. You don’t need to be concerned about safety. It’s been handled for you by the runtime and ref-caps.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Same with Raven, plus remote. We have all of that. See the PriorityVat class.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Last time I checked, Squeak/Pharo didn’t have actors that run without interruption by the GC. Or can Smalltalk actors do that now? How hard to implement on OSVM would a per-actor memory architecture be? You need a concurrent collector algo to make it work. I don’t think you have that in the current VM. <o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I don’t have time for Pony programming these days--I can’t even read about these days. Go ahead if you wish.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Your time is better spent in other ways, though.</span><o:p></o:p></p></blockquote></blockquote><p style='margin-left:.5in'>I communicate with you about what could be, but I agree I must stay focused on my primary target, which is porting SSL to use my new ThunkStack framework for remote encrypted communications. End-to-end encryption is what I am about. Here is a visualization of what I aim for with TLS 1.3 and Signal as to be done projects, it is currently vaporware. I have ParrotTalk done and am working SSL, then I will move to SSH. The script I listed above will load all remote packages, except for SSH. I m attaching the flyer I created to broadcast Squeak's ProCrypto configuration.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><img border=0 width=611 height=543 id="_x0000_i1025" src="cid:image002.jpg@01D624B2.BF24FFE0"><o:p></o:p></p><p style='margin-left:.5in'><o:p> </o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The speed and scale advantages of Orca over the big-heap approach have been demonstrated. That was done some time ago. Read the paper by Clebsch and friends for details. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Regarding capabilities please read the ELib documentation on ERights website: <a href="http://erights.org/elib/index.html">http://erights.org/elib/index.html</a><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The material is not well organized, and is very hard to even want to read. Maybe you are the one to change that.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I’m looking for: 1) definitions of all terms that are new or nonstandard; 2) problem-constraint invariants (one can’t reason about anything without invariants); 3) problem-solution objectives expressed in<u> measurable terms, like data-rate or latency</u>. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Can I get those? This might be a good time and place to describe your proposed concurrency solution for Smalltalk in terse, measurable terms. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Have you measured a running actor-based app on one node? On two or more?<o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>You state that Pony is just to access Orca. <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The two are codesigned.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>What makes Orca so great?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The measurements. Read the end of the Orca paper if you can’t read the whole thing. Orca is the best concurrent MM protocol now. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Aside: I want to be rid of general purpose GC. I think the purely functional approach with persistent data structures can work better (think Haskell). You still need to maintain state in processing queues (think Clojure; not sure how Haskell handles this). You still need temporal-coherency control devices at the periphery for IO (atoms for example). <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> <o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>There are definitely more than one Actor per Vat. <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Why have another construct? It appears to be scoped to the node. Is that the reason for the vat’s existence? Does it control machine-node-specific messaging and resource management for the actors in it contains?<o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>1 per process. There will be a finite number of Capability actors in each event loop. <o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>But more than one and scale into thousands per Vat.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Is there a formal definition of <i>vat</i>? I found this:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal>“A vat is the part of the Neocosm implementation that has a unique network identity. We expect that normal circumstances, there will only be one vat running on a particular machine at one time. Neocom currently (28 May 1998) supports only one avatar per vat.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p style='margin-left:.5in'>Here is the state machine specification for ParrotTalk version 3.7, which is compiled by the ProtocolStateCompiler. This stateMap models states, triggers, transitions, default and callbacks and is simple to use.<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p style='margin-left:.5in'>ParrotTalkSessionOperations_V3_7 class>>#stateMap<o:p></o:p></p><p style='mso-margin-top-alt:5.0pt;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'> "(((ParrotTalkSessionOperations_v3_7 stateMap compile)))"<br><br> | desc |<br> desc := ProtocolStateCompiler initialState: #initial.<br> (desc newState: #initial -> (#processInvalidRequest: -> #dead))<br> add: #answer -> (nil -> #receivingExpectHello);<br> add: #call -> (nil -> #receivingExpectResponse).<br> (desc newState: #connected -> (#processInvalidRequest: -> #dead))<br> addInteger: 7 -> (#processBytes: -> #connected).<br> (desc newState: #dead -> (#processInvalidRequest: -> #dead)).<br><br> (desc newState: #receivingExpectHello -> (#processInvalidRequest: -> #dead))<br> addInteger: 16 -> (#processHello: -> #receivingExpectSignature).<br> (desc newState: #receivingExpectSignature -> (#processInvalidRequest: -> #dead))<br> addInteger: 18 -> (#processSignature: -> #connected);<br> addInteger: 14 -> (#processDuplicateConnection: -> #dead);<br> addInteger: 15 -> (#processNotMe: -> #dead).<br><br> (desc newState: #receivingExpectResponse -> (#processInvalidRequest: -> #dead))<br> addInteger: 17 -> (#processResponse: -> #connected);<br> addInteger: 14 -> (#processDuplicateConnection: -> #dead);<br> addInteger: 15 -> (#processNotMe: -> #dead).<br> ^desc.<o:p></o:p></p></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p></blockquote></blockquote><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:1.0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>--Because it will continue the current Smalltalk-concurrency lameness.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>The only identified difference is not the Actor model, it is the near real-time requirements on the Garbage Collector, yes? So what lameness do you reference?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The actor model is a problem too if you stop all actors with a StW GC. Fix the problem by letting each actor run until it finishes processing the last message. Then let it collect its own garbage. Then let it take the next message from the queue. All actors are single-threaded by definition. This maximizes processing rate and smoothness of GC-disruption of domain work. It also increases tracing overhead transiently when large numbers of mutable objects are used (21% peak CPU consumption ascribable to tracing when you throw the tree/ring exercise at Pony with as many mutable types as possible). We will be turning to functional programming strategies for at least some (if not eventually all) core (not peripheral IO) parallelization efforts, but I digress somewhat.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Two big problems impede parallelization of programs in Smalltalk: 1) the GC stops all actors, all of them or large chunks of them at once, depending on how the GC works. Neither situation is acceptable. That this pause is small is not as important as the work lost from all the actors during that period; 2) core Smalltalk doesn’t have a guaranteed concurrency-integrity model that automatically starts threads on different cores; it can only interleave them on one core (green threading). <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>These ideas should not be add-ons or frameworks. They should be core features. If we can do the above two in Squeak/Pharo, I’ll use Squeak/Pharo to work on a VM. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>Have you tried implementing SmallInteger class>>#tinyBenchmarks in Pony?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>No, sadly. I’ve yet to build Pony. I’m still reading about the techniques and background. I plan to parse large CSV files into objects, as in Rocco’s exercise. I have some files I can use for that purpose, and can get the same data over HTTP to test a connection too. That would be a nice first experiment. We need to be clinical about this. All the talk and hand-waving is an okay start, but at some point, we must measure and keep on doing that in a loop, as architecture is tweaked. I would like to compare a Pony parsing program to my VW parsing program as a start. But the Pony work has to wait.<o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Too slow/wasteful. Moving an actor isn’t needed if the each has its own heap.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>In ELib, why not allow an Actor to be mobile and move from Alice's Vat to Bob's Vat?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Are Vats for scoping actors to specific machine nodes? If so, then yes move the actors to another machine node if it is better suited to what the actor does and needs. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'> Then automated management apps can really truly rebalance Actors. Only on a rare moment, not for every call.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Yes, we must have run-time feedback to adjust resources, which are the actors and the machine nodes they are made to run on. A coordination actor would watch all other actors and clusters of them.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><br><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Once again the near real-time of the Orca Garbage Collector. I am not convinced, but reading some papers. <br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Runtime action with an Orca collector is definitely smoother. This we can know before the fact (before we measure) from the fine-grain MM. What is not clear without testing is overall speed. We need to test and measure.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>86 ms will not break the contract, I propose.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>It’s okay for a business app, certainly--not such much for machine-control or 3D graphics. It’s good enough for prototyping a 3D sim, but not for deployment. <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Yes, and a dedicated cycle-detecting actor watches for this in Pony-Orca. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>I don't watch for it, but it is a strong design consideration. Keep Actor behaviors short and sweet.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The cycles are about chaining of messages/dependencies between actors. When a programmer makes these actor clusters manually, messing up is easy. A higher-level tools is need to manage these constructions. The actor-cycles will exist and become problematic even if each actor is fast. The detector finds and exposes them to the programmer. <o:p></o:p></span></p><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'>E-right's event loops ensure no data races, as long as actor objects are not accessible from more than one event-loop.<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Speed hit.</span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>???<br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>This constraint is not needed to guarantee correct concurrency in Pony, which happens at compile time and takes no CPU cycles. The approach above sounds dynamic; there are some CPU cycles involved.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Yes; I didn’t claim otherwise. The networked version is coming. See above. My point is that the ‘remote’ characterization is not needed. It’s not helping us describe and understand. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>It does so for me, either we have inner-Vat message calling, immediate, adding to the stack. And we have inter-Vat message sending, asynchronous, adding to the queue.<br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I still don’t see a clear definition of <i>vat.</i><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>None of the above language is needed when the concurrency scheme is simpler and doesn’t use those ideas and devices. <o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:.5in'>Design wise, it makes much sense to treat inter-thread, inter-process and inter-machine concurrency as the same remote interface.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The design is already done, modulo the not-yet-present network extension. Interfacing between actors is always by async messaging. Messaging will work as transparently as possible in the networked version across machine nodes. </span><o:p></o:p></p></blockquote></blockquote><p class=MsoNormal style='margin-left:.5in'>Must remember, we are still vulnerable to network failure errors.<br><br><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Yes, they are keenly aware of that. It’s a big task and won’t happen for a while. But it will happen.<o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I don’t like the Pony language syntax. I don’t like anything that looks like Algo-60. Pony is a language, compiler and runtime implementing Orca. The other stuff is good. And I’ve not had much time to use it; I suspect I could like it more.</span><o:p></o:p></p></blockquote></blockquote><p style='margin-left:.5in'>No argument from me! Squeak is a language, a compiler and a profound image-based runtime. Is there another language with such an image-based runtime? I think not.<o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Yes, we all love Smalltalk. It’s still too slow. <o:p></o:p></span></p><p><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>We’re not talking about coding ergonomics and testing dynamic. We all agree that Smalltalk is a better that way to code and interact with the evolving program. But that’s not what the thread is about. This is all about speed and scale across cores, CPUs, and machine nodes. The solution must be implemented close to the metal (VM). It can’t be an add-on framework. We need an Actor class and syntax for making actors and their async behaviours. Then we need the VM to understand the new format and bytecodes associated with actors.<o:p></o:p></span></p><p><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Shaping</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>