[M3devel] [M3commit] CVS Update: cm3

Fri Jun 8 04:05:11 CEST 2012

1. Yes, Daniel generally doesn't make sense to me either.  2.  > Am I correct that on Windows, Modula-3 threads are supposed to map to OS (Windows) threads?
Yes.Note though that "LOCK" doesn't map directly to EnterCriticalSection and more significantly, m3core provides essentially condition variables, which don't map directly to Win32, prior to Vista. (LOCK at least does a delay-heap-allocation-and-initialize before EnterCriticalSection, but also interacts with the condition variables I recall.)  I did a bunch of "research" and our condition variable substitution is pretty good now, equivalent to what Java implementations do.Definitely better than others e.g. Boost.  At some point maybe we could use the condition variables that Vista introduces, but 1) I'm reluctant to drop 2000/XP/etc. support and 2) if we implemented something that chose one implementation or the other at runtime, we'd lose coverage of the pre-Vista code. (I'm really disappointed in this area in Win32, that NT 3.1 and Windows 95 didn't have small locks, zero-or-at-least-statically-initializable locks, read/write locks, "once", and condition variables. Vista, finally, has all that. (SRWLOCK are the first three all in one -- small, zero-initialized, read/write...and given them, I'm not sure you really need "once".)  Also note that historically we maintained a thread pool, so /creating/ a Modula-3 thread did not necessarily create a Win32 thread. I removed that though, so the implementation is more direct now, albeit probably slower.   I didn't realize or forgot we had a problem here. I can try to look into it. The Win32 and pthreads implementation is similar enough, that it might easily be the same problem.   - Jay
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 7 Jun 2012 17:44:56 -0400
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Daniel: I’m impressed by your ability to provide so many different research links in your posts. 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. 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. --Randy Coleburn From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] 
Sent: Thursday, June 07, 2012 3:43 PM
To: m3devel at elegosoft.com; Coleburn, Randy
Subject: Re: [M3devel] [M3commit] CVS Update: cm3 Hi all:
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.
Good style DEC-SRC threads might be along the verification project for the Alpha with Vector extensions:
http://barroso.org/publications/piranha_asilomar.pdf

Thanks in advance

--- El jue, 7/6/12, Coleburn, Randy <rcolebur at SCIRES.COM> escribió:
De: Coleburn, Randy <rcolebur at SCIRES.COM>
Asunto: Re: [M3devel] [M3commit] CVS Update: cm3
Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
Fecha: jueves, 7 de junio, 2012 11:52Mika:

I concur with what you are saying about needing a way to retain the good ideas in CM3 without sacrificing so much on performance.

As far as the thread test program goes, it still shows the implementation is broken somehow on Windows (2000, XP, & 7).  

What can I do to help debug and solve this problem?

Am I correct that on Windows, Modula-3 threads are supposed to map to OS (Windows) threads?

Regards,
Randy Coleburn

-----Original Message-----
From: Mika Nystrom [mailto:mika at async.caltech.edu] 
Sent: Thursday, June 07, 2012 12:37 PM
To: Jay K
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Hi Jay,

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.

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.

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.
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
CM3 for the "official" distribution of Modula-3.

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...

     Mika

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...

Jay K writes:
>
>Daniel=2C I can't find the email now=2C as usual=2C you are probably wrong.
>
>
>We don't have an older runtime=2C we have a newer one=2C I think.
>With more allowance for dynamic loading.
>
>
>Mika=2C
>Maybe a TYPECASE-intense design is generally poor?
>dynamic_cast is slow in some C++ implementations.
>And I've never seen it used much. Some=2C but not much.
>The "type matching" that C++ exception handling has to do isn't 
>particularly fast=2C though there are other costs there.
>Other than the stack walk=2C there is "finding the base of the 
>object"=2C and strcmp to do the actual type match -- 
>name-based-type-equality and all that=2C with a hope that it suffices 
>and no runtime checking of type hashes like Modula-3 does..
>
>
>Maybe you should switch on your own type tag?
>=A0 But I guess Modula-3 doesn't have unions.
>Or use OBJECT and method calls?
>
>
>Which reminds me...it bothers me that OBJECT requires heap allocation 
>and garbage collection. It shouldn't require either.
>I know we have function pointers available to simulate it=2C without 
>heap allocation=2C but what I don't know=2C is if the "implicit dow= 
>ncast"
>in a virtual function/method call is doable in safe code or not.
>I'll have to look into it..but I'm busy now..
>
>
>Maybe there is an optimization whereby the compiler can figure out that 
>there is a small set of likely types that it could check first?
>
>
>Or maybe the full feature could be implemented more efficiently?
>
>
>Maybe it can be optimized based on the fact that the types known to the 
>system are read-mostly=2C rarely written/appended?
>
>
>I don't know.
>I'd really have to look into what the language supports and how it is 
>implemented. I'm not certain of either.
>
>
>In C++=2C typeid() is fast=2C and requires there be virtual functions 
>(OBJECT). Is TYPECASE limited to OBJECTs?
>Or heap allocated data?
>
>
>Later..
>=A0- Jay
>
>
>
>
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>> Date: Wed=2C 6 Jun 2012 09:18:08 -0700
>> From: mika at async.caltech.edu
>>
>> Jay K writes:
>> >
>> ...
>> >7) Do folks out there really use the Modula-3/gcc optimizer=3D2C and 
>> >not=
>ice i=3D
>> >t produces code that runs much faster?
>>
>> If we are talking about turning on optimizations in the m3makefile=2C 
>> the=
>n the
>> answer is:
>>
>> Yes! At least with CM3 it makes a huge difference in runtime. Without 
>> the optimizer CM3-produced code runs far slower than PM3-produced 
>> code (I've seen 3X I think.) With it=2C CM3 can sometimes keep up. 
>> Unless you use a lot of TYPECASE or other constructs that have a much 
>> less efficient implementation in the CM3 libraries than in the PM3 libraries.
>>
>> Mika
>                           =  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120608/537368cc/attachment-0002.html>