Recommendation against Python?

[kgn]

Thomas, Jeffrey, or Collin,

I'm told that Google employees are being discouraged from using Python
for new projects, which seems silly given how much Python code and
Python support comes out of Google.

I've hunted for more information but haven't found any. Do you know
any details, or is this just a rumor?

Thanks -- K

[Collin Winter]

Hi,

Well, simple common sense is going to limit Python's applicability
when operating at Google's scale: it's not as fast as Java or C++,
threading sucks, memory usage is higher, etc. One of the design
constraints we face when designing any new system is, "what happens
when the load goes up by 10x or 100x? What happens if the whole planet
thinks your new service is awesome?" Any technology that makes
satisfying that constraint harder -- and I think Python falls into
this category -- *should* be discouraged if it doesn't have a very
strong case made in its favor on other merits. You have to balance
Python's strengths with its weaknesses: your engineers may be more
productive using Python, but if they have to work around more
platform-level performance/scaling limitations as volume increases, do
you come out ahead? etc.

Thanks,
Collin Winter

[Luis Gonzalez]

...but Unladen Swallow will change that. Right?
At this moment, what are the leassons learned (I know you wrote
something about it, but it was some time ago...), how has your
expectations changed, and when do you think Unladen Swallow will
deliver on its promises? (what does your heart tell you?)??

Luis

On 6 nov, 18:49, Collin Winter <collinwin...@google.com> wrote:
> Hi,
>

[Collin Winter]

Hi Luis,

On Sat, Nov 7, 2009 at 7:24 AM, Luis Gonzalez <lui...@gmail.com> wrote:
> ...but Unladen Swallow will change that. Right?
> At this moment, what are the leassons learned (I know you wrote
> something about it, but it was some time ago...), how has your
> expectations changed, and when do you think Unladen Swallow will
> deliver on its promises? (what does your heart tell you?)??

Unladen Swallow aims to shift the balancing points in that tradeoff to
make it possible to use Python in more places where it would currently
be unsuitable, but it's not going to be a panacea. Python will still
be slower than C and Java, use more memory and have inferior threading
until someone decides to invest resources into Python comparable to
what, say, Sun has invested in their JVM. I hope a focus on Python
performance by the developers will start a snowballing effect: more
companies are interested, more resources can be devoted, more grad
students will work on Python (and actually commit their work), etc.

Thanks,
Collin Winter

[Luis Gonzalez]

Hi Collin,

Thank you very much for your reply!
It is clear that python will still be slower than c or java, but I
wonder how python (in this case, unladen swallow) will perform
compared to the v8 javascript engine, for example.
Do you think it can get close? Or will it take a complete rewrite from
scratch to be competitive with this engine?

Luis

[Collin Winter]

Hey Luis,

I don't think it's possible to make an implementation like CPython as
fast as an engine like V8 or SquirrelFish Extreme that was designed to
be fast above all else. We've come up with some optimizations already
that would simply be too difficult to implement in CPython, and so we
had to discard them. Being a volunteer-run open-source project,
CPython requires somewhat different priorities than V8: CPython places
a heavy emphasis on simplicity, the idea being that a simple, slower
core will be easier for people to maintain in their free time than a
more complicated, faster core.

I have high hopes for one of the other Python implementations to
provide a longer-term performance solution designed without the
shackles of C-level backwards compatibility. We're thinking "what can
we accomplish in the short term to make things better *now*?", while a
project like PyPy is approach performance from the perspective of
"what can we accomplish if we spend a decade really getting it right?"

Thanks,
Collin Winter

[Reid Kleckner]

On Mon, Nov 9, 2009 at 8:12 PM, Collin Winter <collin...@google.com> wrote:
> I don't think it's possible to make an implementation like CPython as
> fast as an engine like V8 or SquirrelFish Extreme that was designed to
> be fast above all else. We've come up with some optimizations already
> that would simply be too difficult to implement in CPython, and so we
> had to discard them. Being a volunteer-run open-source project,
> CPython requires somewhat different priorities than V8: CPython places
> a heavy emphasis on simplicity, the idea being that a simple, slower
> core will be easier for people to maintain in their free time than a
> more complicated, faster core.

Yeah, I was thinking about this, and it's interesting to note that
there are very few CPython developers who are paid to work on CPython.
They're all volunteers. As such, performance really isn't a priority
the way it is for the JVM. The Ruby folks are getting funding (from
EngineYard and others) to work on their VMs because people have
realized that MRI is too darn slow to serve web applications and they
want to fix it.

Reid

[Ad]

What about Jython?

[Alex Gaynor]

On Tue, Nov 10, 2009 at 3:29 AM, Ad <ada...@gmail.com> wrote:
> What about Jython?
>

What about Jython? Collin has indicated the primary issue is resource
(CPU and RAM) at Google's scale, Jython has no significant advantage
in either of these departments.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Reid Kleckner]

On Tue, Nov 10, 2009 at 11:15 AM, Alex Gaynor <alex....@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 3:29 AM, Ad <ada...@gmail.com> wrote:
>> What about Jython?
>>
>
> What about Jython?  Collin has indicated the primary issue is resource
> (CPU and RAM) at Google's scale, Jython has no significant advantage
> in either of these departments.

Another one of unladen-swallow's major goals is to maintain
source-level compatibility with C extension modules, which Google uses
a lot of. Using Jython would require moving that infrastructure from
SWIG to JNI, which would be a huge pain in the butt.

Reid

[Collin Winter]

On Tue, Nov 10, 2009 at 8:15 AM, Alex Gaynor <alex....@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 3:29 AM, Ad <ada...@gmail.com> wrote:
>> What about Jython?
>>
>
> What about Jython?  Collin has indicated the primary issue is resource
> (CPU and RAM) at Google's scale, Jython has no significant advantage
> in either of these departments.

Jython has a similarly-small number of paid full-time developers (and
Frank W just left Sun, as you may have seen). To date, IronPython and
Jython have had to dedicate a significant portion of their engineering
resources to achieving compatibility with CPython, with relatively
little time left over for performance optimization. It remains to be
seen how these factors will be balanced as Jython, IronPython, PyPy,
etc move to support Python 3.

Collin Winter

[Collin Winter]

Reid is correct: moving large applications from SWIG-wrapped
infrastructure (e.g., Bigtable) to their Java equivalents would be a
tremendous pain in the ass and would almost certainly introduce
exceedingly-subtle bugs due to differences in handling rare edge/error
cases. This is the primary reason why we did not choose Jython as a
baseline.

Collin Winter

[Tom Machinski]

What about Cython?

http://cython.org/

-- Tom

[Collin Winter]

Since this has come up off-list, let me be more specific about this point:

One area where I believe Python (and other dynamic languages) do
particularly well is projects with lots of developers working on lots
of little subsystems, all contributing to the same codebase or the
same released binary. In a language like C or C++, the more developers
you add, the more fragile your binary becomes: it only takes one
segfault to kill a running binary (and hence lose those pending
requests), and the probability of introducing that segfault goes up
with the number of developers/subsystems/integration points/etc.
Dynamic languages, on the other hand, are much easier to sandbox in
this regard. If you want to isolate failures in one particular
component in your Python system, you can just throw a try/except
around it and you're basically good to go. That kind of agility and
flexibility is an important advantage, and it's one of the "other
merits" I was alluding to above.

Python may not be a good fit for millisecond-critical systems, but it
does have advantages; we wouldn't use it if it didn't.

Collin Winter

[Tom Machinski]

Just to clarify my question about Cython:

It seems to satisfy both requirements that Collin mentioned above, namely:
 1. It is a technology that is usable right now.
 2. It offers very significant efficiency gains.

So even for a company like Google, wouldn't it make sense to write a prototype with Python, then gradually convert performance critical parts to Cython, which still offers most of the benefits of pure Python, paired with C-like efficiency and optimization potential?

 -- Tom

[Sebastian]

I always had the impression that java is much faster than python, but
sucks up a rather big amount of memory, so this isn't true in your
experience?
My impression more or less came from
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=javaxint&lang2=python&box=1
as i didn't test that myself.

sebastian

[Leon Sit]

I believe that Cython has good performance increase in numerical code
and not so much on other application. Moreover, Cython relies on C
compiler which most Windows systems do not have. To get major speedup
in Cython, you would need to add type information which involves
syntax outside of standard Python. I do not see the reason why Cython
is what Google is looking for.

Leon

[Tom Machinski]

On Tue, Nov 10, 2009 at 2:46 PM, Leon Sit <wing11...@gmail.com> wrote:

I believe that Cython has good performance increase in numerical code and not so much on other application.

Is this belief based on factual data?  I have working examples demonstrating >100x performance gains for common, non-"numerical" operations such as looping, iteration, object construction, etc.
 

Moreover, Cython relies on C compiler which most Windows systems do not have.

How is that relevant for the many server-side users of Python, such as Google?
 

To get major speedup in Cython, you would need to add type information which involves syntax outside of standard Python.

Yes. Still far less work than rewriting the entire prototype in C, or writing it in C from scratch.

 -- Tom

[Brian Harring]

On Tue, Nov 10, 2009 at 02:54:27PM -0800, Tom Machinski wrote:
> On Tue, Nov 10, 2009 at 2:46 PM, Leon Sit <[1]wing11...@gmail.com>

> wrote:
>
> I believe that Cython has good performance increase in numerical
> code and not so much on other application.
>
> Is this belief based on factual data? I have working examples
> demonstrating >100x performance gains for common, non-"numerical"
> operations such as looping, iteration, object construction, etc.

Fundamentally cython is the wrong approach for this in my opinion.
It's syntactic glue to translate pseudo python into c code- much like
pyrex. This isn't a bad thing mind you. It's just not applicable to
speeding up the core processing of the language.

To use cython, they'd have to go converting large chunks of stdlib to
cython. Yes those components would be faster, but when I write

def f(*args):
some_cython_func(args[0])
... do other things

This still invokes the mainline cpython vm, meaning you still get
.5us hit for just generating the function frame itself. This is
ignoring the FFI cost there also- for passing bits into the extension,
it has to convert it into tuples/keywords (hence *args, **kwargs,
although METH_O/METH_NONE are modifications to this).

All of these things take time, and are not something cython can
address unless you're proposing shifting the actual vm implementation
itself to cython... which isn't really possible.

> Moreover, Cython relies on C compiler which most Windows systems do
> not have.
>
> How is that relevant for the many server-side users of Python, such as
> Google?

Rebasing the implementation upon llvm, they don't have to care if it's
windows or unix (or client or server)- they just need to either
compile llvm into the resultant binary, or ensure the library is
there.

This is *far* more simple then trying to ensure cython machinery still
works and avoids excluding platforms.

> To get major speedup in Cython, you would need to add type
> information which involves syntax outside of standard Python.
>
> Yes. Still far less work than rewriting the entire prototype in C, or
> writing it in C from scratch.

The gains from cython aren't comparable to llvm gains on a grand
scale. Speeding up chunks of code is nice (a faster os.path.join for
example), but that's hot spot optimization. The potential gains from
it aren't comparable to the intended goal of a 5x increase in
raw/normal python code (this is the target of u-s).

Or that's the theory at least. Either way I'd suggest you dig into
what u-s is targeting, and what cython is targeting- they're two
rather orthogonally different things. The one nifty thing is that via
u-s trying to maintain transparent cpy extension, you probably will be
able to use cython generated modules w/ u-s. That's the current
theory at least...

Hope that clarifies things.
~harring

[Tom Machinski]

On Tue, Nov 10, 2009 at 5:28 PM, Brian Harring <ferr...@gmail.com> wrote:
>
> The gains from cython aren't comparable to llvm gains on a grand
> scale.  Speeding up chunks of code is nice (a faster os.path.join for
> example), but that's hot spot optimization.  The potential gains from
> it aren't comparable to the intended goal of a 5x increase in
> raw/normal python code (this is the target of u-s).

So if your CPU-bound program spends a conservative 90% of its
execution time running a small set of tight loops, and Cython can
speed those loops up by 100x or more, it's not comparable to an
expected 5x gain that U-S will hopefully deliver to the entire
application?

And you realize that most CPU-bound programs are like this, spending
most of their execution time - probably more than 90% - in very
specific hot spots, so dismissing "hot spot optimization" is
inappropriate in this context?

> To use cython, they'd have to go converting large chunks of stdlib to
> cython.

They don't have be Cython, just C extension modeuls, which many
performance-intensive parts of the stdlib already are.

> Yes those components would be faster, but when I write
>
> def f(*args):
>    some_cython_func(args[0])
>    ... do other things
>
> This still invokes the mainline cpython vm, meaning you still get
> .5us hit for just generating the function frame itself.

Correct. The sensible design here is that if f() is being invoked
enough times to matter - i.e. it is itself inside a tight loop - then
optimizing it entails translating f() itself and its containing loop
to Cython.

Don't get me wrong: I'm excited by U-S and hope it meets its
beneficial goals. Unfortunately, I also agree with Collin when he says
that even if all the project goals are met, Python on U-S would still
not be a match for Java or C++.

Cython exists right now, and offers efficiency gains that bring it
close to compiled code of these two languages. So if Google, or any
other company, is entirely ruling out Python for performance intensive
tasks, it's interesting to ask whether they considered it, and on what
grounds (if any) was it ruled out.

-- Tom

[Craig Citro]

I think what you're saying could be a very good plan for *new* Python
code being developed at Google. It's exactly how we develop code for
the Sage library, in fact -- write it and get it working correctly in
Python, write some tests, then move the mission-critical sections into
Cython for speed. However, I think that the comments Collin makes
above are all in the context of making Google's *existing* Python code
run faster, without having to do anything to the source at all. In
particular, they also want something they can do without having to
worry about the prospect of introducing subtle bugs in corner cases
(like, say, the difference between C and Python semantics for
arithmetic).

That said, this will also be a much more interesting question a little
further down the line. In particular, the goal is for Cython to
support all of the Python language in the near future, and there are
things like Robert Bradshaw's recent start of a type inferencer ...
once Cython can actually compile all the code one might run into in
the wild, it'll be interesting to see how competitive it is.

Even still, though, Cython and Unladen Swallow really are orthogonal
in several ways -- in particular, with LLVM in the mix, Unladen
Swallow has the prospect of introducing lots of interesting *runtime*
optimization and specialization that Cython could never do ...

-cc

[Reid Kleckner]

> Even still, though, Cython and Unladen Swallow really are orthogonal
> in several ways -- in particular, with LLVM in the mix, Unladen
> Swallow has the prospect of introducing lots of interesting *runtime*
> optimization and specialization that Cython could never do ...

This is actually a really important point. The HotSpot JVM can beat
g++ on some benchmarks because it can devirtualize method calls with
type feedback where the C++ compiler doesn't have enough information
to generate the fastest code. This suggests to me that it shouldn't
be too hard to beat a *naive* static compilation of pure Python code
with Cython.

Cython is great if you have a specific application for which you
really care about performance, and you're willing to profile it, find
the hot loops, and turn objects into native C data types. If you
aren't willing to dig in and force your pure Python code into Cython,
a JIT compiler like u-s can do a much better job optimizing the pure
Python code. It has so much more information than a static compiler.
That's the theory, anyway. :)

Here's another anecdote for why Cython may not be the right answer for
all Python performance problems. I wrote an optimizing Decaf compiler
for a class in Python, and I could not get Cython to speed it up. I
only spent one afternoon working on it, but I was surprised that
everything I tried (in particular, turning the IR classes into Cython
classes) resulted in slowdowns, not speedups. There were none of the
mythical "doubly-nested for loops" that I could just provide type
annotations for to make my code fast.

So, in summary, Cython is great for bridging that performance gap for
projects that are concerned about performance, and u-s is targeted
more towards everyone else who will take what performance they can
get.

Reid

[Thomas_H]

On Nov 10, 4:22 pm, Reid Kleckner <r...@mit.edu> wrote:

> Yeah, I was thinking about this, and it's interesting to note that
> there are very few CPython developers who are paid to work on CPython.
>  They're all volunteers.  As such, performance really isn't a priority
> the way it is for the JVM.  The Ruby folks are getting funding (from
> EngineYard and others) to work on their VMs because people have
> realized that MRI is too darn slow to serve web applications and they
> want to fix it.

This comes as kind of a surprise, knowing that GvR is working for
Google, and obviously you U-S guys are getting funded. Wouldn't it be
only too logical that Google throws a couple of FTE at CPython?!

T.

[Luis Gonzalez]

Collin,

We know that U-S is an effort to speed up cpython *right now*, as an
incremental step to the current implementation (as opposed to Pypy,
for example, which is what can be done in a decade...).

But I wonder if, considering the importance of Python for Google, and
seeing that V8 is a Google project...
Is there any slim chance that, one day, Google will do for Python the
same they are doing for Javascript?

After all, Python is not very different than Javascript. They are both
dynamic languages.
And the knowledge and brains are there.
Do you imagine working with Lars Bak & Co.? Or perhaps, applying the
same strategy and techniques for implementing python?

I know it sounds easier than it is, but wouldn't it be great if you
guys could leverage all this knowledge and experience for Python?
If not Google, which is already doing it for Javascript, who else?

Luis


On 10 nov, 19:26, Collin Winter <collinwin...@google.com> wrote:

> On Fri, Nov 6, 2009 at 1:49 PM, Collin Winter <collinwin...@google.com> wrote:
> > Hi,
>

[Collin Winter]

Hey Tom,

On Tue, Nov 10, 2009 at 7:25 PM, Tom Machinski <tom.ma...@gmail.com> wrote:
[snip]

> Don't get me wrong: I'm excited by U-S and hope it meets its
> beneficial goals. Unfortunately, I also agree with Collin when he says
> that even if all the project goals are met, Python on U-S would still
> not be a match for Java or C++.
>
> Cython exists right now, and offers efficiency gains that bring it
> close to compiled code of these two languages. So if Google, or any
> other company, is entirely ruling out Python for performance intensive
> tasks, it's interesting to ask whether they considered it, and on what
> grounds (if any) was it ruled out.

Right, the obvious hotspots are the easy part: you code them by hand
in C, use a tool like Cython, bring in Psyco, etc. We're seeking to
speed up the entire application from end to end without the need for
special tools, to have that performance be more adaptive to code
changes, and to make the existing Python language faster without
language extensions. We feel that such extensions and exceptions
increase the barrier to adoption, increase possibly-problematic edge
cases, and increase the training needed for engineers to produce
Python applications.

Thanks,
Collin Winter

[Collin Winter]

Hi Luis,

On Wed, Nov 11, 2009 at 8:42 AM, Luis Gonzalez <lui...@gmail.com> wrote:
[snip]

> But I wonder if, considering the importance of Python for Google, and
> seeing that V8 is a Google project...
> Is there any slim chance that, one day, Google will do for Python the
> same they are doing for Javascript?
>
> After all, Python is not very different than Javascript. They are both
> dynamic languages.
> And the knowledge and brains are there.
> Do you imagine working with Lars Bak & Co.? Or perhaps, applying the
> same strategy and techniques for implementing python?
>
> I know it sounds easier than it is, but wouldn't it be great if you
> guys could leverage all this knowledge and experience for Python?
> If not Google, which is already doing it for Javascript, who else?

Our work is animated by the same theories and papers that inform V8,
HotSpot, Rubinius, etc. We are familiar with the work being done on
V8, TraceMonkey, SquirrelFish Extreme, and try to reuse as much
knowledge and practical experience as we can. That said, JavaScript is
a far more important optimization target than a language like Python:
JavaScript has far, far more installations worldwide, sits on the
critical path of many more applications, has historically suffered
from inattention, etc. This is why multiple companies -- Apple,
Mozilla and Google among them -- have sunk important resources into
optimizing their JavaScript engines. I would argue that producing a
generation of faster JavaScript engines is far more significant to the
Internet as a whole, and brings greater benefit to the network and the
planet.

Thanks,
Collin Winter

[Collin Winter]

Hi Thomas,

Well, that's what Unladen Swallow *is*: two full-time engineers
working on a branch of CPython, which we intend to merge back into
mainline with the community's blessing. We two engineers, however, are
not the primary workforce maintaining or releasing mainline CPython;
CPython is a volunteer, open-source effort, which individual companies
have seen fit to fund as their own needs and priorities suggest or
require. Google is not the first company to fund optimization work on
CPython; EWT and CCP Games co-sponsored the Need for Speed sprint in
2006, for example.

Thanks,
Collin Winter

[Tom Machinski]

Thanks for the reply Collin.

On Fri, Nov 13, 2009 at 2:25 PM, Collin Winter <collin...@google.com> wrote:
> We're seeking to
> speed up the entire application from end to end without the need for
> special tools, to have that performance be more adaptive to code
> changes, and to make the existing Python language faster without
> language extensions.

This is indeed a laudable cause, and we'd all be happy to write
idiomatic Python and have it run as efficiently as V8 is currently
running idiomatic Javascript, with no additional work or effort on our
part.

My comment on this thread was strictly regarding the topic: I was
wondering why Google was apparently not making greater use of Cython
and similar technologies.

Specifically, if an engineer wishes to pursue a performance-intensive
project in Python, why not tell him to use Cython (or Python with some
C extensions) rather than force him to a completely different language
like Java or C++.

An engineer who picks Python as his first choice is probably familiar
enough with the language to utilize Cython / C-extension effectively,
and would probably rather do that than use any of those completely
different languages. As a bonus, Google gets a tool that's probably
easier to maintain than your common C++ codebase.

Cheers,
-- Tom

[Leon Sit]

IMHO, Cython requires a lots of time to fine tune and the performance
gain is not obvious. In my limited python/cython experience, once I
tried Cython on a couple thousand lines of numerical code after adding
type information to every places and adjusting operations to the
suggested form, and there was no performance gain at all. Can you
afford your programmers to code things in pure Python, and spend 50%
more time to tune their code and hope to experience performance gain?
I personally cannot. It is not cost and time efficient to educate 1000
python programmers to learn how to fine tuning their Cython code than
few full-time engineer to improve the interpreter.

The piece of code in question is at
http://github.com/wingsit/KF/blob/master/kalman_filter/clibregression.pyx

Dont get me wrong. I love every Python projects on earth but people
just build what is best for themselves.

Leon

[kgn]

Hi Leon,

On Nov 14, 9:16 am, Leon Sit <wing1127ai...@gmail.com> wrote:
> IMHO, Cython requires a lots of time to fine tune and the performance
> gain is not obvious. In my limited python/cython experience, once I
> tried Cython on a couple thousand lines of numerical code after adding
> type information to every places and adjusting operations to the
> suggested form, and there was no performance gain at all. Can you
> afford your programmers to code things in pure Python, and spend 50%
> more time to tune their code and hope to experience performance gain?
> I personally cannot. It is not cost and time efficient to educate 1000
> python programmers to learn how to fine tuning their Cython code than
> few full-time engineer to improve the interpreter.
>

> The piece of code in question is at http://github.com/wingsit/KF/blob/master/kalman_filter/clibregression...

This code frequently crosses into NumPy and back. If the Python
interpreter mediates these round trips, how much time is then spent in
the interpreter?

Cython works well as a simple binding layer. To migrate classes from
Python to C++, I like to re-implement the classes wholly in C++ in
order do as much work as possible in a single round trip across the
binding layer.

-- kgn

[Collin Winter]

On Sat, Nov 14, 2009 at 10:18 AM, kgn <kaben....@gmail.com> wrote:
> Hi Leon,
>
> On Nov 14, 9:16 am, Leon Sit <wing1127ai...@gmail.com> wrote:
>> IMHO, Cython requires a lots of time to fine tune and the performance
>> gain is not obvious. In my limited python/cython experience, once I
>> tried Cython on a couple thousand lines of numerical code after adding
>> type information to every places and adjusting operations to the
>> suggested form, and there was no performance gain at all. Can you
>> afford your programmers to code things in pure Python, and spend 50%
>> more time to tune their code and hope to experience performance gain?
>> I personally cannot. It is not cost and time efficient to educate 1000
>> python programmers to learn how to fine tuning their Cython code than
>> few full-time engineer to improve the interpreter.
>>
>> The piece of code in question is at http://github.com/wingsit/KF/blob/master/kalman_filter/clibregression...
>
> This code frequently crosses into NumPy and back. If the Python
> interpreter mediates these round trips, how much time is then spent in
> the interpreter?

FYI, reducing the overhead of calling between Python and C is
something we're working on. See the recent commits related to
METH_FIXED and its successor, METH_ARG_RANGE. I'm going to start
working on speeding up C->Python calls, too.

Thanks,
Collin Winter

[Leon Sit]

Hi Collin,

Do you see the possibility that u-s can achieve highly optimised
numerical code like Cython in the future? Or additional type
information must be needed for this purpose?

Sincerely,

Leon

[Alex Gaynor]

Unladen Swallow has huge potential for improvements, as these patches
demonstrate: http://bitbucket.org/ebo/unladen-swallow-mergequeue/
however Python will never patch C (I don't buy into the Java will
ultimately be faster than C++ argument either FWIW).

[Leon Sit]

Sorry, I meant to compare the performance of numerical code between
Cython and U-S.

[Collin Winter]

Hi Leon,

On Mon, Nov 16, 2009 at 5:16 PM, Leon Sit <wing11...@gmail.com> wrote:
> Hi Collin,
>
> Do you see the possibility that u-s can achieve highly optimised
> numerical code like Cython in the future? Or additional type
> information must be needed for this purpose?

In the future, yes, but don't ask me about a time horizon :) PyPy has
invested in good numeric performance and has achieved significant
speedups there. It's less important for Unladen, simply because the
applications we're targeting are webapps, and they don't do much math
(ergo, it's a lower priority). There's massive opportunity there,
though; it just needs someone to do the work.

Thanks,
Collin Winter

[Reid Kleckner]

I doubt it. No matter what we do, we're still going to be emitting
guards and boxing and unboxing into and out of data structures.
Cython and NumPy can help you eliminate that via the code annotation
mechanism and changing your data representation to use proper arrays
of structs, but we can't.

We can certainly do better than CPython currently does, though.

Reid

[Jeffrey Yasskin]

On Mon, Nov 16, 2009 at 5:51 PM, Reid Kleckner <r...@mit.edu> wrote:
> I doubt it.  No matter what we do, we're still going to be emitting
> guards and boxing and unboxing into and out of data structures.

That's not quite true. It'll be hard, and it's a long way off, but in
theory we can unbox arbitrary objects onto the C stack and only
reconstitute them onto the heap when they escape or when an exception
is thrown.

[Reid Kleckner]

On Tue, Nov 17, 2009 at 10:55 AM, Jeffrey Yasskin <jyas...@google.com> wrote:
> On Mon, Nov 16, 2009 at 5:51 PM, Reid Kleckner <r...@mit.edu> wrote:
>> I doubt it.  No matter what we do, we're still going to be emitting
>> guards and boxing and unboxing into and out of data structures.
>
> That's not quite true. It'll be hard, and it's a long way off, but in
> theory we can unbox arbitrary objects onto the C stack and only
> reconstitute them onto the heap when they escape or when an exception
> is thrown.

True, but I was thinking about cramming floats and ints and small
structs into arrays instead of having pointers to objects across the
heap. NumPy will let you do this, but I doubt we will ever be able
to.

Reid

[Jeffrey Yasskin]

Ah, for the savings in escaped objects. Yeah, doing that automatically
would be much harder.