[pypy-svn] r42852 - pypy/extradoc/talk/dyla2007
arigo at codespeak.net
arigo at codespeak.net
Tue May 8 14:31:03 CEST 2007
Author: arigo
Date: Tue May 8 14:31:01 2007
New Revision: 42852
Added:
pypy/extradoc/talk/dyla2007/ (props changed)
pypy/extradoc/talk/dyla2007/draft.txt (contents, props changed)
Log:
A possible outline for a dyla2007 position paper.
Added: pypy/extradoc/talk/dyla2007/draft.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/talk/dyla2007/draft.txt Tue May 8 14:31:01 2007
@@ -0,0 +1,112 @@
+~~~~~
+Draft
+~~~~~
+
+
+Introduction
+============
+
+- Some kind of intro about dynamic language implementations
+
+- In the context of academic or Open Source communities:
+ limited resources
+
+- What is the best way to implement dynamic languages?
+ Current situation:
+ * interpreters only
+ * for C (Posix, Windows), as custom VMs
+ * for Java (common in academia)
+ * for .NET (recent)
+ Trend:
+ * more support from OO VMs, better integration
+ * standardizing on one OO VM to increase interoperability
+ and reduce redundancy and out-of-sync implementations of the dyn language
+
+- Our view on the issue:
+ * high-level VMs come with limitations
+ * a single OO VM for everybody is not a good idea
+ * this is really a metaprogramming issue, not a standardization issue
+ * implementations should be generated - don't write VMs by hand any more
+
+
+The OO VM Arguments
+===================
+
+- Writing dynamic language implementations in an OO VM gives advantages
+ over writing custom VMs in C. Supposedly we get:
+ * more interoperability than the C level
+ * better tools
+ * better implementation of low-level issues like GC
+ * better performance
+ * ease of implementation
+ * a single base, which makes alternate implementations
+ unnecessary
+ (expand each topic with concrete supporting data...)
+
+- Some of these are only partially true:
+ * there is no single best base VM and unclear if there will ever be:
+ so far, all major dynamic languages have multiple implementations
+ (Perl has only a C/Posix impl) and it's probably a good thing
+ * "better performance": so far it's the other way around, and the
+ VM's JIT compilers don't help much the very dynamic languages (expand...)
+ * "better GCs" is unclear - obvious in theory, but OO VMs tend to
+ have quite large memory overheads to start with (ref...)
+ * "ease of implementation" disputable: it's really a trade-off:
+ it gives a higher-level language but also an imposed model in
+ which concepts must be mapped, which may be anywhere from easy
+ to mostly impossible depending on the language we want to implement
+ (ref... e.g. bad functional languages support for .NET?)
+
+- Not all arguments are bogus: we get better tools and GCs in theory,
+ and interoperability with the rest of the VM
+
+
+Metaprogramming Is Good
+=======================
+
+- Introduction to the generation of VMs from high-level interpreters
+ * PyPy proof of concept: can target many environments
+ * single source => multiple VMs
+
+- (Describe some of the PyPy architecture, ref...)
+
+- Makes interpreters easy to write, update, and generally experiment with
+ * expand...
+ * the requirement "write an interpreter for your language" is much
+ less strong than "fit it into the OO VM's model" [e.g. Pyrolog on .NET]
+ * transformations [Stackless]
+
+- We can get similarly good GCs and tools
+ * no easier or harder than what needs to be put in an OO VM
+ * existing GCs can also be reused
+ * a metaprogramming translation toolchain requires a lot of work,
+ but it is highly reusable
+
+- We can get better performance
+ * good baseline speed (e.g. pypy-c quite faster than Jython)
+ * JIT generation framework
+ * expand...
+
+- No need for VM standardization
+ * we reduce the need for alternative implementations by making
+ one source code enough for many environments
+ * even the translation framework need not be standardized, as
+ we could cross-translate high-level source code written for one
+ with another [e.g. steal the Jikes GC]
+ * might open the door to better solutions for interoperability
+ (high-level bridges instead of low-level ones, cross-translation...)
+
+
+Conclusion
+==========
+
+- Don't write dynamic language implementations "by hand"
+ * writing them more abstractly at a high level has mostly only advantages
+
+- Don't write VMs by hand any more
+ * certainly not language-specific VMs
+ * but even general-purpose OO VMs have trade-offs
+
+- Let's write more metaprogramming translation toolchains
+ * diversity is good
+ * ultimately a better investment of efforts than writing general-purpose VMs
More information about the Pypy-commit
mailing list