[M3devel] [M3commit] CVS Update: cm3
Jay K
jay.krell at cornell.edu
Thu Jun 7 06:45:38 CEST 2012
Daniel, I can't find the email now, as usual, you are probably wrong.
We don't have an older runtime, we have a newer one, I think.
With more allowance for dynamic loading.
Mika,
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, but not much.
The "type matching" that C++ exception handling has to do
isn't particularly fast, though there are other costs there.
Other than the stack walk, there is "finding the base of the object",
and strcmp to do the actual type match -- name-based-type-equality
and all that, 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?
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,
without heap allocation, but what I don't know, is if the "implicit downcast"
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, 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++, typeid() is fast, and requires there be virtual
functions (OBJECT). Is TYPECASE limited to OBJECTs?
Or heap allocated data?
Later..
- Jay
----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> Date: Wed, 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=2C and notice i=
> >t produces code that runs much faster?
>
> If we are talking about turning on optimizations in the m3makefile, then 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, 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
More information about the M3devel
mailing list