<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>perhaps this would show it:<br><br>Again, what I'm saying is that you can use a WinNT system thread without losing M3 semantics as long as is implemented as it is in the consistent Model Architecture of the system:<br>http://research.microsoft.com/en-us/um/people/qadeer/talks/microsoft-dec00.ppt<br><br>Recently a guy from Intel (Rick Hudson) explained and out his thoughts on that (but I find the same problem I can't understand the problem his is talking about that much). Rialto NT OS was implemented along the lines for embedded devices (nice!):<br>http://www.youtube.com/watch?v=WUfvvFD5tAA<br><br>DEC-SRC and MS worked together on this, in acting like so there was an Alpha "beta" Win2000, but it didn't happen, as the piranha project :(<br><br>See this new architectures don't scale for that much they say (sorry HW guys, but show me a good proof
I'm writing this from nothing related to it)<br><br>Thanks in advance<br><br><br><br>--- El <b>jue, 7/6/12, Coleburn, Randy <i><rcolebur@SCIRES.COM></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Coleburn, Randy <rcolebur@SCIRES.COM><br>Asunto: Re: [M3devel] [M3commit] CVS Update: cm3<br>Para: "m3devel@elegosoft.com" <m3devel@elegosoft.com><br>Fecha: jueves, 7 de junio, 2012 16:44<br><br><div id="yiv938033429"><style><!--
#yiv938033429
_filtered #yiv938033429 {font-family:"Cambria Math";panose-1:2 4 5 3 5 4 6 3 2 4;}
_filtered #yiv938033429 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}
_filtered #yiv938033429 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
#yiv938033429
#yiv938033429 p.yiv938033429MsoNormal, #yiv938033429 li.yiv938033429MsoNormal, #yiv938033429 div.yiv938033429MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"serif";}
#yiv938033429 a:link, #yiv938033429 span.yiv938033429MsoHyperlink
{color:blue;text-decoration:underline;}
#yiv938033429 a:visited, #yiv938033429 span.yiv938033429MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
#yiv938033429 span.yiv938033429EmailStyle17
{font-family:"sans-serif";color:#1F497D;}
#yiv938033429 .yiv938033429MsoChpDefault
{}
_filtered #yiv938033429 {margin:1.0in 1.0in 1.0in 1.0in;}
#yiv938033429 div.yiv938033429WordSection1
{}
--></style><div><div class="yiv938033429WordSection1"><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Daniel:</span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">I’m impressed by your ability to provide so many different research links in your posts.</span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">But, after looking at the link you gave in response to my post, I don’t see the immediate relevance to my question regarding
Modula-3 threading on Windows.</span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">Also, I’m sorry, but I have a very difficult time trying to understand what you are saying in your posts. I suppose it must have something to do with the translation between our different languages. Forgive me, but I don’t understand your reply.</span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);"> </span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family: "sans-serif"; color: rgb(31, 73, 125);">--Randy Coleburn</span></p><p class="yiv938033429MsoNormal"><span style="font-size: 11pt; font-family:
"sans-serif"; color: rgb(31, 73, 125);"> </span></p><div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;"><p class="yiv938033429MsoNormal" style="margin-left: 0.5in;"><b><span style="font-size: 10pt; font-family: "sans-serif";">From:</span></b><span style="font-size: 10pt; font-family: "sans-serif";"> Daniel Alejandro Benavides D. [mailto:dabenavidesd@yahoo.es] <br><b>Sent:</b> Thursday, June 07, 2012 3:43 PM<br><b>To:</b> m3devel@elegosoft.com; Coleburn, Randy<br><b>Subject:</b> Re: [M3devel] [M3commit] CVS Update: cm3</span></p></div><p class="yiv938033429MsoNormal" style="margin-left: 0.5in;"> </p><table class="yiv938033429MsoNormalTable" style="width: 6.5in; margin-left: 0.5in;" border="0" cellpadding="0" cellspacing="0" width="624"><tbody><tr><td style="padding: 0in;" valign="top"><p
class="yiv938033429MsoNormal">Hi all:<br>Yes, it is, but the same conditioning over System Pthreads, is that you can't always link the threads against themselves, so you need re-implement it correctly.<br>Good style DEC-SRC threads might be along the verification project for the Alpha with Vector extensions:<br><a rel="nofollow" target="_blank" href="http://barroso.org/publications/piranha_asilomar.pdf">http://barroso.org/publications/piranha_asilomar.pdf</a><br><br>Thanks in advance<br><br><br>--- El <b>jue, 7/6/12, Coleburn, Randy <i><<a rel="nofollow" ymailto="mailto:rcolebur@SCIRES.COM" target="_blank" href="/mc/compose?to=rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a>></i></b> escribió:</p><p class="yiv938033429MsoNormal" style="margin-bottom: 12pt;"><br>De: Coleburn, Randy <<a rel="nofollow" ymailto="mailto:rcolebur@SCIRES.COM" target="_blank" href="/mc/compose?to=rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a>><br>Asunto: Re: [M3devel]
[M3commit] CVS Update: cm3<br>Para: "<a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>" <<a rel="nofollow" ymailto="mailto:m3devel@elegosoft.com" target="_blank" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a>><br>Fecha: jueves, 7 de junio, 2012 11:52</p><div><p class="yiv938033429MsoNormal">Mika:<br><br>I concur with what you are saying about needing a way to retain the good ideas in CM3 without sacrificing so much on performance.<br><br>As far as the thread test program goes, it still shows the implementation is broken somehow on Windows (2000, XP, & 7). <br><br>What can I do to help debug and solve this problem?<br><br>Am I correct that on Windows, Modula-3 threads are supposed to map to OS (Windows) threads?<br><br>Regards,<br>Randy Coleburn<br><br>-----Original Message-----<br>From: Mika Nystrom [mailto:<a
rel="nofollow">mika@async.caltech.edu</a>] <br>Sent: Thursday, June 07, 2012 12:37 PM<br>To: Jay K<br>Cc: <a rel="nofollow">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br><br>Hi Jay,<br><br>TYPECASE is limited to "reference" types, which effectively means heap-allocated. Unless you can get alloca in there, I suppose... what I mean is that in Green Book Modula-3 the only way to get a reference type is either through a heap allocation or an UNSAFE operation.<br><br>TYPECASE is sometimes the only way to do things. In the Green Book there are examples of using subtyping to have multiple generations of objects in the same pickles, for example. In my program, it was inside an interpreter that's figuring things out without any prior type information, using ISTYPE or TYPECASE.<br><br>The issue with TYPECASE that I brought up is actually that the implementation of TYPECASE and ISTYPE is far slower in the CM3
m3core than in PM3's (= SRC M3 as far as I know). The reason (which you allude to) is that Critical Mass did a lot of work on supporting dynamic loading of Modula-3 code (loading in types not known at compile time) and as with many of the other projects they carried out, the code quality was so-so. Because of the restrictions of SRC and P M3, types are statically allocated at compile time and all their subtyping relationships are known at that time. There is simply a static array of the types. CM3, on the other hand, has some more complicated dynamic data structure that makes all the TYPECASE and ISTYPE operations much more cumbersome. It's all in RT0 somewhere. In short, CM3 does "more" than SRC M3 did but at a heavy performance cost. And of course no one uses the "more" bit now.<br>Kind of like what they did to TEXTs... good ideas for some users, but somewhat half-baked implementation. Given that dynamic
loading is used so little, if at all, and it in any case only happens infrequently itself, it seems there ought to be a way to achieve what the CM3 guys were trying to do while retaining the performance of the older implementation, but not if your code is a "rush job". I think it would have been sensible to vet Critical Mass's code a bit better before switching from PM3 to<br>CM3 for the "official" distribution of Modula-3.<br><br>I still use PM3 quite a bit. I can no longer blame the TEXTs, nor can I blame the pthreads implementation's being broken since I use CM3 with user threads. Now it's mainly because m3gdb works great on FreeBSD-5.5 with PM3-generated code. I've tried so many times to get things working on other machines with CM3 and newer m3gdb and there's always something annoyingly wrong. Life's too short...<br><br> Mika<br><br>P.S. how are the pthreads coming along? I saw some
checkins (Dragisa), does the thread tester run without hanging or crashing now? I'd love to use pthreads but it's not been high on my list to debug as long as I can live with user threads...<br><br>Jay K writes:<br>><br>>Daniel=2C I can't find the email now=2C as usual=2C you are probably wrong.<br>><br>><br>>We don't have an older runtime=2C we have a newer one=2C I think.<br>>With more allowance for dynamic loading.<br>><br>><br>>Mika=2C<br>>Maybe a TYPECASE-intense design is generally poor?<br>>dynamic_cast is slow in some C++ implementations.<br>>And I've never seen it used much. Some=2C but not much.<br>>The "type matching" that C++ exception handling has to do isn't <br>>particularly fast=2C though there are other costs there.<br>>Other than the stack walk=2C there is "finding the base of the <br>>object"=2C and strcmp to do the actual type match -- <br>>name-based-type-equality and all
that=2C with a hope that it suffices <br>>and no runtime checking of type hashes like Modula-3 does..<br>><br>><br>>Maybe you should switch on your own type tag?<br>>=A0 But I guess Modula-3 doesn't have unions.<br>>Or use OBJECT and method calls?<br>><br>><br>>Which reminds me...it bothers me that OBJECT requires heap allocation <br>>and garbage collection. It shouldn't require either.<br>>I know we have function pointers available to simulate it=2C without <br>>heap allocation=2C but what I don't know=2C is if the "implicit dow= <br>>ncast"<br>>in a virtual function/method call is doable in safe code or not.<br>>I'll have to look into it..but I'm busy now..<br>><br>><br>>Maybe there is an optimization whereby the compiler can figure out that <br>>there is a small set of likely types that it could check first?<br>><br>><br>>Or maybe the full feature could be implemented more
efficiently?<br>><br>><br>>Maybe it can be optimized based on the fact that the types known to the <br>>system are read-mostly=2C rarely written/appended?<br>><br>><br>>I don't know.<br>>I'd really have to look into what the language supports and how it is <br>>implemented. I'm not certain of either.<br>><br>><br>>In C++=2C typeid() is fast=2C and requires there be virtual functions <br>>(OBJECT). Is TYPECASE limited to OBJECTs?<br>>Or heap allocated data?<br>><br>><br>>Later..<br>>=A0- Jay<br>><br>><br>><br>><br>><br>><br>>----------------------------------------<br>>> To: <a rel="nofollow">jay.krell@cornell.edu</a><br>>> CC: <a rel="nofollow">m3devel@elegosoft.com</a><br>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>>> Date: Wed=2C 6 Jun 2012 09:18:08 -0700<br>>> From: <a rel="nofollow">mika@async.caltech.edu</a><br>>><br>>>
Jay K writes:<br>>> ><br>>> ...<br>>> >7) Do folks out there really use the Modula-3/gcc optimizer=3D2C and <br>>> >not=<br>>ice i=3D<br>>> >t produces code that runs much faster?<br>>><br>>> If we are talking about turning on optimizations in the m3makefile=2C <br>>> the=<br>>n the<br>>> answer is:<br>>><br>>> Yes! At least with CM3 it makes a huge difference in runtime. Without <br>>> the optimizer CM3-produced code runs far slower than PM3-produced <br>>> code (I've seen 3X I think.) With it=2C CM3 can sometimes keep up. <br>>> Unless you use a lot of TYPECASE or other constructs that have a much <br>>> less efficient implementation in the CM3 libraries than in the PM3 libraries.<br>>><br>>> Mika<br>>
=</p></div></td></tr></tbody></table><p class="yiv938033429MsoNormal" style="margin-left: 0.5in;"><span style="font-size: 10pt; font-family: "sans-serif";"> </span></p></div></div></div></blockquote></td></tr></table>