[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Perl Objects with C APIs, Stackless Python, Misc
> Isn't anybody going to rage, rage against the
> dying of the lightweight language list?
I hereby warn this list that if I don't see some intelligent discussion
about getting innovative language features into the hands of working
programmers, I'm going to [... consequences too horrible to contemplate ...:]
> as a relative newbie coming into computer science through python, i'd like
> to know what the C translators are about and what people think about the
> idea. will they (or one of them) speed up python considerably, and if so,
> at what cost?
There are a lot of theories about this. Today's C translators are quite
far from improving the performance of Python much. Optimization is
tricky in general and quite difficult in a language as dynamic as
Python. I'm beginning to wonder if JIT and optimization-at-rutnime
techniques will preempt the C translators.
Perhaps a complementary approach is to have interacting objects
"conspire to compile". Interacting Perl/Python/Ruby objects gossip,
and on finding a mutual capability to provide auxiliary C
implementations or apis, switch to dealing with each other "under the
table". Either via collections of C function pointers, or by dumping
their mingled guts to a file for gcc optimization and dynamic linking.
The upside is one can do principled engineering of "cost free"
abstractions, and can get truly wizzy speed (often better than
maintainable hand-tuned C). Downsides include rather increased
complexity, having to engineer twice+ as many apis, dealing blended
multilingual programming, and suffering the artifacts of a very
immature infrastructure (multi-second pauses, file turds, etc).
I've a quick, dirty, and grossly incomplete note at "An Illustration
of Perl Objects with C APIs"
In other news, Stackless Python is apparently mutating from an
extensively hacked version of CPython, to a clean combination of
CPython and a C stack-swapping scheme for light-weight threads.
He is apparently looking to Limbo for the thread api. Anyone with
insight might weigh in. http://www.stackless.com/
It seems the Goo manual is still not available in HTML? :(
Trying to view the pdf version online always reminds me of Tufte's
comments on maximizing the portion of ink devoted to data... :-/
(looking for a job... really...)