Hello Lucas,
I hope you do not mind some comments and asking for some clarifications:
On Tue, 18 Sep 2007 10:57:57 +0200, Lucas S. Silva <
lssilva@...>
wrote:
> Well, If I get enough time, my goals are:
>
> 1 Learn how the ec works
Sure - it is not too difficult, once you have managed to climb some hills.
Feel free to ask on the list for specific details.
> 2 Split the static analysis from the compilation. I want to be able to
> compile without the static analysis
I do not get this point. The whole compiler frontend is static analysis.
What is it exactly that you want to avoid?
> 3 Update the naming system, I think that the current encoder will
> generate the feature name based on their ids which depends on the number
> of
> features/types, hence in the inheritance analysis.
Which naming system? At some time during the compilation, names are
dropped and replaced by IDs. Multiple IDs for a single feature are needed
because of multiple subtyping (merging of different features). It does not
need to be ID sets, there are other possible techniques, but in the end it
boils down to the same.
> 4 Have the feature loading / binding done dynamically
Do you mean "loading" as in "class loading"?
> I think that the Eiffel Compiler does a excellent job, I would like to
> have
> a simpler compiler
> which is easier to experiment.
There exists the GOBO Eiffel compiler, which is work-in-progress, but
definitely using a more simplistic approach to compilation. You might want
to have a look at it, though some of Eric's "magic" is difficult to grasp.
Not that I want to push you away from EC (it is a good compiler), just
want to mention alternatives. You should avoid SmartEiffel, because that
is not an Eiffel compiler.
> class loading of precompiled Eiffel modules", you should be aware that
>> there is probably a major problem: as far as I know the following three
>> things cannot be joined:
>>
>> - Efficient class loading
>> - Constant dynamic binding
>> - Multiple subtyping
>
>
> I think we could cross the Efficient out from Class loading, that would
> do
> it.
OK. You have to globally recompute the feature table every time you add a
new class that implements the feature. Smart updating mechansism can help
there.
> Eiffel is so fast, because it can generate a global feature table for
>> constant feature lookup in dynamic binding. This is not possible any
>> more if you introduce incremental compilation and dynamic class loading.
>
> It is one reason why people in C++ are so picky about "virtual" and Java
>> is so slow (because it needs a search routine for dynamic binding).
>
>
> I believe that Eiffel's efficient is not only attributed to the constant
> feature look-up, and
> as I said my goal is not to replace the Eiffel Compiler.
It is one of the reasons. But surely not the only one, you are right.
> Even with dynamic
> loading/binding
> some people will say that Java is no longer so slow, in fact they will
> claim
> that it is faster than
> C/C++ in some areas[1][2].
Java has non-constant lookup when you are making use of 'invokeinterface',
which requires non-constant lookup because of multiple subtyping. This is
nearly never the case in the benchmarks you mention, but happens really
often in complex data-models as they are present in the industry.
An other source of speed problems is the use of "functional programming
style" of coding, because Java does not propagate Command/Query
separation. As an effect, this creates very many short-lives objects (for
intermediate results). Object creation is expensive, making Java slow.
This is another property of Java that is not tested in benchmarks, but has
a strong impact on performance of large scale applications.
> The only solution would be to recompute the global feature table when
>> loading a new class, making class loading rather inefficient. YMMV
>
> I think that if the naming is not dependent on the entire feature
> history,
> we might
> not have to recompute the whole feature table but just the new ones
True, as said it is only necessary to recompute the feature tables of all
features of the dynamically loaded class, and there is quite some room
"algorithmic smartness", though it will not change the "worst case"
behavior.
Bernd
_______________________________________________
Es-devel mailing list
Es-devel@...
http://rock.inf.ethz.ch/cgi-bin/mailman/listinfo/es-devel
