Showing posts with label pypy. Show all posts
Showing posts with label pypy. Show all posts

2012-11-17

walk and chew gum #Python

8.22: news.adda/python/co/walk and chew gum:
summary:
Google discourages Python for new projects?
[they encourage go.lang;
Python is said to need more resources?
I'm sure the problem is backwards compatibility .
. in the paper where they talked about Unladen Swallow
they mentioned wanting to remove the GIL
(the global interpreter lock for thread safety)
and this really surprised me coming from google staff,
because Python's project lead (another google staff)
has argued convincingly
that due to the language itself, [11.17:
ie, by being designed for interfacing C
(Jython and IronPython have no GIL)]
removing the GIL from CPython was impractical .
[11.17: at PyCon 2012, he adds:
Threading is for parallel IO.
Multiprocessing is for parallel computation.
The GIL does not hinder any of that.
... just because process creation in Windows
used to be slow as a dog, ...]
. Python has that old-style OOP,
which doesn't do much for encapsulation,
and therefore doesn't do much for thread safety
except to single-thread the interpreter .
. if you want something much like python
that also has good concurrency,
then google has given it to us in go.lang;
but, perhaps what he meant to say
is that it's like Intel's CISC architecture:
that was fundamentally slower than RISC;
but they virtualized it:
the machine instructions are converted
to RISC microcode .
. that's what big money could do for Python:
automatically find the inherent concurrency
and translate it to a threaded virtual machine .[11.17:
... but still interface flawlessly with
all C code on all platforms?
I'm no longer confident about that .]

[11.17: web:
. to overcome GIL limitation,
the parallel python SMP module;
runs python code in parallel
on both multicores and multiprocessors .
Doug Hellmann 2007 reviews it:
. you need install your code only once:
the code and data are both auto'distributed
from the central server to the worker nodes .
Jobs are started asynchronously,
and run in parallel on an available node.
The callable object that is
returned when the job is submitted
blocks until the response is ready,
so response sets can be computed
asynchronously, then merged synchronously.
Load distribution is transparent,
making it excellent for clustered environments.
Whereas Parallel Python is designed around
a “push” style distribution model,
the Processing package is set up to
create producer/consumer-style systems
where worker processes pull jobs from a queue .
Since the Processing package is almost a
drop-in replacement for the
standard library’s threading module,
many of your existing multi-threaded applications
can be converted to use processes
simply by changing a few import statements .
. see wiki.python.org/moin/Concurrency/
for the latest on Pythonic concurrency .]

8.22: news:

2011-07-30

Ousterhout's dichotomy

7.1: news.adda/Ousterhout's dichotomy:
. John Ousterhout, designer of Tcl,
noticed that high-level programming languages
tend to fall into two groups,
"system programming languages"
and "scripting languages".
[ie you can't have a language that is
optimal for both .
. in defence of that claim,
pypy tried to have a system language Rpython
that was as much as possible like
Python, the scripting lang;
because they wanted
a self-hosting python compiler
ie, one written in python instead of c .
[7.30: like adda,
Rpython is designed to translate into c
for the purpose of avoiding c:
system programmers can use Rpython
yet still take advantage of c compilers .]
. the closest Rpython could get to python
is a subset of it that added static typing;
because, some features that support
coder productivity
are antithetical to features that support
algorithm efficiency .
. Ousterhout was likely pointing out that
scripting lang efficiency was not so important;
because, scripts are glue for
subprograms of sufficient size,
such that most of the run time
is spent in the parts defined by the system lang .
7.30: web:
D. Ancona, M. Ancona, A Cuni, and N. Matsakis.
RPython: a Step Towards Reconciling
Dynamically and Statically Typed OO Languages.
In OOPSLA 2007 Proceedings and Companion, DLS'07:
Proceedings of the 2007 Symposium on
Dynamic Languages, pages 53-64. ACM, 2007(pdf)
. an approach that attempts to preserve
the flexibility of Python,
while still allowing for efficient execution
is limiting the use of
the more dynamic features of Python
to an initial, bootstrapping phase.
This phase is used to construct
a final RPython (Restricted Python) program
that is actually executed.
RPython is a proper subset of Python,
is statically typed,
and does not allow dynamic modification
of class or method definitions;
however, it can still take advantage of
Python features such as mixins and
first-class methods and classes.
This paper presents an overview of RPython,
including its design and its translation to
both CLI and JVM bytecode.
We show how the bootstrapping phase can be
used to implement advanced features,
like extensible classes and generative programming.
   

2010-03-31

portable translation the pypy way

3.26: bk.adda/Self-Sustaining Systems:
Self-Sustaining Systems: First Workshop, S3 2008 By Robert Hirschfeld, Kim Rose
. pypy offers a model-driven approach
to language implementation:
unlike jython, which diverges from cpython,
pypy is providing a pil (pythonic intermediate lang')
which can then have a backend to every other lang;
ie, the compiler is translating as if
that lang were a cpu intstruction set .
. pypy doesn't try be the intermed'lang for all back ends .
. it has versions for
high level (oop'ish) langs -- eg, {cli, jvm, js} --
and low level langs: eg, {llvm, c} .
. by coding your translator in pypy (Rpython)
you can debug it on the batteries-included cPython system
and then have all these back ends it will run on
-- including c .
. great, now if I could only love python!
3.31:
. this presentation assumes jython diverges
simply because it's rendered in a
different code base;
but jython differs for a deliberate reason:
it didn't want to just be another python
that happened to be runnable on a jvm,
it wanted a lang customized to complement the jvm;
whereas, cpython wants a lang that is
basically customized to complement ms`windows .