Re: python simply not scaleable enough for google?

Discussion in 'Python' started by Terry Reedy, Nov 11, 2009.

  1. Terry Reedy

    Terry Reedy Guest

    Robert P. J. Day wrote:
    > http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1
    >
    > thoughts?


    Program_cost = human_writing&maintance_cost + running_cost*number_of_runs

    Nothing new here. The builtin types and many modules are written in C to
    reduce running cost for frequency used components. The first killer ap
    for Python was scientific computing with early numerical python, where
    people often run one-time combinations of inputs and constantly reused
    linear algebra functions.

    Google has an unusually high number of runs for many programs, making
    running_cost minimization important.

    At one time, C was not 'scaleable enough' for constantly rerun aps.
    Hotspots were hand rewritten in assembler. Apparently now, with
    processors more complex and compilers much improved, that is not longer
    much the case.

    I can imagine a day when code compiled from Python is routinely
    time-competitive with hand-written C.

    Terry Jan Reedy
     
    Terry Reedy, Nov 11, 2009
    #1
    1. Advertising

  2. Alain Ketterlin, Nov 11, 2009
    #2
    1. Advertising

  3. Terry Reedy

    Peter Chant Guest

    Terry Reedy wrote:

    > I can imagine a day when code compiled from Python is routinely
    > time-competitive with hand-written C.


    In my very limited experience it was very informative programming in C for
    PIC microcontrollers and inspecting the assembly code produced. If I just
    threw together loops and complex if statements the assembly produced was
    very long and impossible to follow whereas if I though carefully about what
    I was doing, tried to parallel what I would have done in assembly I found
    the assembly produced looked a lot like I imagined it would if I were
    programming in assembler directly. Except that the whole process was 10x
    faster and actually worked.

    Pete

    --
    http://www.petezilla.co.uk
     
    Peter Chant, Nov 12, 2009
    #3
  4. On 2009-11-11, at 14:31, Alain Ketterlin wrote:
    > Terry Reedy <> writes:
    >
    >> I can imagine a day when code compiled from Python is routinely
    >> time-competitive with hand-written C.

    >
    > Have a look at
    > http://code.google.com/p/unladen-swallow/downloads/detail?name=Unladen_Swallow_PyCon.pdf&can=2&q=
    >
    > Slide 6 is impressive. The bottom of slide/page 22 explains why python
    > is so slow: in most cases "the program is less dynamic than the
    > language".


    I'm having some trouble understanding this thread. My comments aren't directed at Terry's or Alain's comments, but at the thread overall.

    1. The statement `Python is slow' doesn't make any sense to me. Python is a programming language; it is implementations that have speed or lack thereof.

    2. A skilled programmer could build an implementation that compiled Python code into Common Lisp or Scheme code, and then used a high-performance Common Lisp compiler such as SBCL, or a high-performance Scheme compiler such as Chez Scheme, to produce quite fast code; Python's object model is such that this can be accomplished (and not using CLOS); a Smalltalk-80-style method cache can be used to get good method dispatch. This whole approach would be a bad idea, because the compile times would be dreadful, but I use this example as an existence proof that Python implementations can generate reasonably efficient executable programs.

    In the Lisp world, optional declarations and flow analysis are used to tell the compiler the types of various variables. Python 3's annotations could be used for this purpose as well. This doesn't impact the learner (or even the casual programmer) for who efficiency is not that important.

    Unladen Swallow's JIT approach is, IMHO, better than this; my point here is that we don't know what the speed limits of Python implementations might be, and therefore, again, we don't know the limits of performance scalability.

    3. It is certainly true that CPython doesn't scale up to environments where there are a significant number of processors with shared memory. It is also true that similar languages for highly parallel architectures have been produced (Connection Machine Lisp comes to mind). Whether the current work being done on the GIL will resolve this I don't know. Still, even if CPython had to be thrown away completely (something I don't believe is necessary), a high-performance multiprocessor/shared memory implementation could be built, if resources were available.

    4. As to the programming language Python, I've never seen any evidence one way or the other that Python is more or less scalable to large problems than Java. My former employers build huge programs in C++, and there's lots of evidence (most of which I'm NDA'd from repeating) that it's possible to build huge programs in C++, but that they will be horrible :)

    -- v
     
    Vincent Manis, Nov 12, 2009
    #4
  5. On Wed, 11 Nov 2009 16:38:50 -0800, Vincent Manis wrote:

    > I'm having some trouble understanding this thread. My comments aren't
    > directed at Terry's or Alain's comments, but at the thread overall.
    >
    > 1. The statement `Python is slow' doesn't make any sense to me. Python
    > is a programming language; it is implementations that have speed or lack
    > thereof.


    Of course you are right, but in common usage, "Python" refers to CPython,
    and in fact since all the common (and possibly uncommon) implementations
    of Python are as slow or slower than CPython, it's not an unreasonable
    short-hand.

    But of course "slow" is relative. And many applications are bound by I/O
    time, not CPU time.


    > 2. A skilled programmer could build an implementation that compiled
    > Python code into Common Lisp or Scheme code, and then used a
    > high-performance Common Lisp compiler such as SBCL, or a
    > high-performance Scheme compiler such as Chez Scheme, to produce quite
    > fast code;


    Unless you can demonstrate this, it's all theoretical. And probably not
    as straight-forward as you think:

    http://codespeak.net/pypy/dist/pypy/doc/faq.html#id29


    > Python's object model is such that this can be accomplished
    > (and not using CLOS); a Smalltalk-80-style method cache can be used to
    > get good method dispatch. This whole approach would be a bad idea,
    > because the compile times would be dreadful, but I use this example as
    > an existence proof that Python implementations can generate reasonably
    > efficient executable programs.


    I think a better existence proof is implementations that *actually*
    exist, not theoretical ones. There's good work happening with Psycho and
    PyPy, and you can write C extensions using almost-Python code with Cython
    and Pyrex.

    There's very little reason why Python *applications* have to be slow,
    unless the application itself is inherently slow.


    > In the Lisp world, optional declarations and flow analysis are used to
    > tell the compiler the types of various variables. Python 3's annotations
    > could be used for this purpose as well. This doesn't impact the learner
    > (or even the casual programmer) for who efficiency is not that
    > important.
    >
    > Unladen Swallow's JIT approach is, IMHO, better than this; my point here
    > is that we don't know what the speed limits of Python implementations
    > might be, and therefore, again, we don't know the limits of performance
    > scalability.


    Absolutely. It's early days for Python.



    --
    Steven
     
    Steven D'Aprano, Nov 12, 2009
    #5
  6. Terry Reedy

    mcherm Guest

    On Nov 11, 7:38 pm, Vincent Manis <> wrote:
    > 1. The statement `Python is slow' doesn't make any sense to me.
    > Python is a programming language; it is implementations that have
    > speed or lack thereof.

    [...]
    > 2. A skilled programmer could build an implementation that compiled
    > Python code into Common Lisp or Scheme code, and then used a
    > high-performance Common Lisp compiler...


    I think you have a fundamental misunderstanding of the reasons why
    Python is
    slow. Most of the slowness does NOT come from poor implementations:
    the CPython
    implementation is extremely well-optimized; the Jython and Iron Python
    implementations use best-in-the-world JIT runtimes. Most of the speed
    issues
    come from fundamental features of the LANGUAGE itself, mostly ways in
    which
    it is highly dynamic.

    In Python, a piece of code like this:
    len(x)
    needs to watch out for the following:
    * Perhaps x is a list OR
    * Perhaps x is a dict OR
    * Perhaps x is a user-defined type that declares a __len__
    method OR
    * Perhaps a superclass of x declares __len__ OR
    * Perhaps we are running the built-in len() function OR
    * Perhaps there is a global variable 'len' which shadows the
    built-in OR
    * Perhaps there is a local variable 'len' which shadows the
    built-in OR
    * Perhaps someone has modified __builtins__

    In Python it is possible for other code, outside your module to go in
    and
    modify or replace some methods from your module (a feature called
    "monkey-patching" which is SOMETIMES useful for certain kinds of
    testing).
    There are just so many things that can be dynamic (even if 99% of the
    time
    they are NOT dynamic) that there is very little that the compiler can
    assume.

    So whether you implement it in C, compile to CLR bytecode, or
    translate into
    Lisp, the computer is still going to have to to a whole bunch of
    lookups to
    make certain that there isn't some monkey business going on, rather
    than
    simply reading a single memory location that contains the length of
    the list.
    Brett Cannon's thesis is an example: he attempted desperate measures
    to
    perform some inferences that would allow performing these
    optimizations
    safely and, although a few of them could work in special cases, most
    of the
    hoped-for improvements were impossible because of the dynamic nature
    of the
    language.

    I have seen a number of attempts to address this, either by placing
    some
    restrictions on the dynamic nature of the code (but that would change
    the
    nature of the Python language) or by having some sort of a JIT
    optimize the
    common path where we don't monkey around. Unladen Swallow and PyPy are
    two
    such efforts that I find particularly promising.

    But it isn't NEARLY as simple as you make it out to be.

    -- Michael Chermside
     
    mcherm, Nov 12, 2009
    #6
  7. Terry Reedy

    Joel Davis Guest

    On Nov 12, 10:07 am, mcherm <> wrote:
    > On Nov 11, 7:38 pm, Vincent Manis <> wrote:
    >
    > > 1. The statement `Python is slow' doesn't make any sense to me.
    > > Python is a programming language; it is implementations that have
    > > speed or lack thereof.

    >    [...]
    > > 2. A skilled programmer could build an implementation that compiled
    > > Python code into Common Lisp or Scheme code, and then used a
    > > high-performance Common Lisp compiler...

    >
    > I think you have a fundamental misunderstanding of the reasons why
    > Python is
    > slow. Most of the slowness does NOT come from poor implementations:
    > the CPython
    > implementation is extremely well-optimized; the Jython and Iron Python
    > implementations use best-in-the-world JIT runtimes. Most of the speed
    > issues
    > come from fundamental features of the LANGUAGE itself, mostly ways in
    > which
    > it is highly dynamic.
    >
    > In Python, a piece of code like this:
    >     len(x)
    > needs to watch out for the following:
    >     * Perhaps x is a list OR
    >       * Perhaps x is a dict OR
    >       * Perhaps x is a user-defined type that declares a __len__
    > method OR
    >       * Perhaps a superclass of x declares __len__ OR
    >     * Perhaps we are running the built-in len() function OR
    >       * Perhaps there is a global variable 'len' which shadows the
    > built-in OR
    >       * Perhaps there is a local variable 'len' which shadows the
    > built-in OR
    >       * Perhaps someone has modified __builtins__
    >
    > In Python it is possible for other code, outside your module to go in
    > and
    > modify or replace some methods from your module (a feature called
    > "monkey-patching" which is SOMETIMES useful for certain kinds of
    > testing).
    > There are just so many things that can be dynamic (even if 99% of the
    > time
    > they are NOT dynamic) that there is very little that the compiler can
    > assume.
    >
    > So whether you implement it in C, compile to CLR bytecode, or
    > translate into
    > Lisp, the computer is still going to have to to a whole bunch of
    > lookups to
    > make certain that there isn't some monkey business going on, rather
    > than
    > simply reading a single memory location that contains the length of
    > the list.
    > Brett Cannon's thesis is an example: he attempted desperate measures
    > to
    > perform some inferences that would allow performing these
    > optimizations
    > safely and, although a few of them could work in special cases, most
    > of the
    > hoped-for improvements were impossible because of the dynamic nature
    > of the
    > language.
    >
    > I have seen a number of attempts to address this, either by placing
    > some
    > restrictions on the dynamic nature of the code (but that would change
    > the
    > nature of the Python language) or by having some sort of a JIT
    > optimize the
    > common path where we don't monkey around. Unladen Swallow and PyPy are
    > two
    > such efforts that I find particularly promising.
    >
    > But it isn't NEARLY as simple as you make it out to be.
    >
    > -- Michael Chermside


    obviously the GIL is a major reason it's so slow. That's one of the
    _stated_ reasons why Google has decided to forgo CPython code. As far
    as how sweeping the directive is, I don't know, since the situation
    would sort of resolve itself if one committed to Jython application
    building or just wait until unladen swallow is finished.
     
    Joel Davis, Nov 12, 2009
    #7
  8. On Thu, 12 Nov 2009 08:35:23 -0800, Joel Davis wrote:

    > obviously the GIL is a major reason it's so slow.


    No such "obviously" about it.

    There have been attempts to remove the GIL, and they lead to CPython
    becoming *slower*, not faster, for the still common case of single-core
    processors.

    And neither Jython nor IronPython have the GIL. Jython appears to scale
    slightly better than CPython, but for small data sets, is slower than
    CPython. IronPython varies greatly in performance, ranging from nearly
    twice as fast as CPython on some benchmarks to up to 6000 times slower!

    http://www.smallshire.org.uk/suffic...ython-2-5-performance-compared-to-python-2-5/

    http://ironpython-urls.blogspot.com/2009/05/python-jython-and-ironpython.html


    Blaming CPython's supposed slowness on the GIL is superficially plausible
    but doesn't stand up to scrutiny. The speed of an implementation depends
    on many factors, and it also depends on *what you measure* -- it is sheer
    nonsense to talk about "the" speed of an implementation. Different tasks
    run at different speeds, and there is no universal benchmark.


    --
    Steven
     
    Steven D'Aprano, Nov 12, 2009
    #8
  9. * Steven D'Aprano:
    > On Thu, 12 Nov 2009 08:35:23 -0800, Joel Davis wrote:
    >
    >> obviously the GIL is a major reason it's so slow.



    http://en.wikipedia.org/wiki/Global_Interpreter_Lock

    Uh oh...


    > No such "obviously" about it.
    >
    > There have been attempts to remove the GIL, and they lead to CPython
    > becoming *slower*, not faster, for the still common case of single-core
    > processors.
    >
    > And neither Jython nor IronPython have the GIL. Jython appears to scale
    > slightly better than CPython, but for small data sets, is slower than
    > CPython. IronPython varies greatly in performance, ranging from nearly
    > twice as fast as CPython on some benchmarks to up to 6000 times slower!
    >
    > http://www.smallshire.org.uk/suffic...ython-2-5-performance-compared-to-python-2-5/
    >
    > http://ironpython-urls.blogspot.com/2009/05/python-jython-and-ironpython.html
    >
    >
    > Blaming CPython's supposed slowness


    Hm, this seems religious.

    Of course Python is slow: if you want speed, pay for it by complexity.

    It so happens that I think CPython could have been significantly faster, but (1)
    doing that would amount to creating a new implementation, say, C++Python <g>,
    and (2) what for, really?, since CPU-intensive things should be offloaded to
    other language code anyway.


    > on the GIL is superficially plausible
    > but doesn't stand up to scrutiny. The speed of an implementation depends
    > on many factors, and it also depends on *what you measure* -- it is sheer
    > nonsense to talk about "the" speed of an implementation. Different tasks
    > run at different speeds, and there is no universal benchmark.


    This also seems religious. It's like in Norway it became illegal to market lemon
    soda, since umpteen years ago it's soda with lemon flavoring. This has to do
    with the *origin* of the citric acid, whether natural or chemist's concoction,
    no matter that it's the same chemical. So, some people think that it's wrong to
    talk about interpreted languages, hey, it should be a "language designed for
    interpretation", or better yet, "dynamic language", or bestest, "language with
    dynamic flavor". And slow language, oh no, should be "language whose current
    implementations are perceived as somewhat slow by some (well, all) people", but
    of course, that's just silly.


    Cheers,

    - Alf
     
    Alf P. Steinbach, Nov 12, 2009
    #9
  10. mcherm <> writes:

    > On Nov 11, 7:38 pm, Vincent Manis <> wrote:
    >> 1. The statement `Python is slow' doesn't make any sense to me.
    >> Python is a programming language; it is implementations that have
    >> speed or lack thereof.

    > [...]
    >> 2. A skilled programmer could build an implementation that compiled
    >> Python code into Common Lisp or Scheme code, and then used a
    >> high-performance Common Lisp compiler...

    >
    > I think you have a fundamental misunderstanding of the reasons why
    > Python is
    > slow. Most of the slowness does NOT come from poor implementations:
    > the CPython
    > implementation is extremely well-optimized; the Jython and Iron Python
    > implementations use best-in-the-world JIT runtimes. Most of the speed
    > issues
    > come from fundamental features of the LANGUAGE itself, mostly ways in
    > which
    > it is highly dynamic.
    >
    > In Python, a piece of code like this:
    > len(x)
    > needs to watch out for the following:
    > * Perhaps x is a list OR
    > * Perhaps x is a dict OR
    > * Perhaps x is a user-defined type that declares a __len__
    > method OR
    > * Perhaps a superclass of x declares __len__ OR
    > * Perhaps we are running the built-in len() function OR
    > * Perhaps there is a global variable 'len' which shadows the
    > built-in OR
    > * Perhaps there is a local variable 'len' which shadows the
    > built-in OR
    > * Perhaps someone has modified __builtins__
    >
    > In Python it is possible for other code, outside your module to go in
    > and
    > modify or replace some methods from your module (a feature called
    > "monkey-patching" which is SOMETIMES useful for certain kinds of
    > testing).
    > There are just so many things that can be dynamic (even if 99% of the
    > time
    > they are NOT dynamic) that there is very little that the compiler can
    > assume.
    >
    > So whether you implement it in C, compile to CLR bytecode, or
    > translate into
    > Lisp, the computer is still going to have to to a whole bunch of
    > lookups to
    > make certain that there isn't some monkey business going on, rather
    > than
    > simply reading a single memory location that contains the length of
    > the list.
    > Brett Cannon's thesis is an example: he attempted desperate measures
    > to
    > perform some inferences that would allow performing these
    > optimizations
    > safely and, although a few of them could work in special cases, most
    > of the
    > hoped-for improvements were impossible because of the dynamic nature
    > of the
    > language.
    >
    > I have seen a number of attempts to address this, either by placing
    > some
    > restrictions on the dynamic nature of the code (but that would change
    > the
    > nature of the Python language) or by having some sort of a JIT
    > optimize the
    > common path where we don't monkey around. Unladen Swallow and PyPy are
    > two
    > such efforts that I find particularly promising.
    >
    > But it isn't NEARLY as simple as you make it out to be.
    >
    > -- Michael Chermside


    You might be right for the wrong reasons in a way.

    Python isn't slow because it's a dynamic language. All the lookups
    you're citing are highly optimized hash lookups. It executes really
    fast.

    The OP is talking about scale. Some people say Python is slow at a
    certain scale. I say that's about true for any language. Large amounts
    of IO is a tough problem.

    Where Python might get hit *as a language* is that the Python programmer
    has to drop into C to implement optimized data-structures for dealing
    with the kind of IO that would slow down the Python interpreter. That's
    why we have numpy, scipy, etc. The special cases it takes to solve
    problems with custom types wasn't special enough to alter the language.
    Scale is a special case believe it or not.

    As an implementation though, the sky really is the limit and Python is
    only getting started. Give it another 40 years and it'll probably
    realize that it's just another Lisp. ;)
     
    J Kenneth King, Nov 12, 2009
    #10
  11. On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach <>
    wrote:
    >
    > This also seems religious. It's like in Norway it became illegal to
    > market lemon soda, since umpteen years ago it's soda with lemon
    > flavoring. This has to do with the *origin* of the citric acid, whether
    > natural or chemist's concoction, no matter that it's the same chemical.
    > So, some people think that it's wrong to talk about interpreted
    > languages, hey, it should be a "language designed for interpretation",
    > or better yet, "dynamic language", or bestest, "language with dynamic
    > flavor". And slow language, oh no, should be "language whose current
    > implementations are perceived as somewhat slow by some (well, all)
    > people", but of course, that's just silly.


    Perhaps I'm missing the point of what you're saying but I don't see why
    you're conflating interpreted and dynamic here? Javascript is unarguably a
    dynamic language, yet Chrome / Safari 4 / Firefox 3.5 all typically JIT
    it. Does that make Javascript non-dynamic, because it's compiled? What
    about Common Lisp, which is a compiled language when it's run with CMUCL
    or SBCL?


    --
    Rami Chowdhury
    "Never attribute to malice that which can be attributed to stupidity" --
    Hanlon's Razor
    408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
     
    Rami Chowdhury, Nov 12, 2009
    #11
  12. * Rami Chowdhury:
    > On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach <>
    > wrote:
    >>
    >> This also seems religious. It's like in Norway it became illegal to
    >> market lemon soda, since umpteen years ago it's soda with lemon
    >> flavoring. This has to do with the *origin* of the citric acid,
    >> whether natural or chemist's concoction, no matter that it's the same
    >> chemical. So, some people think that it's wrong to talk about
    >> interpreted languages, hey, it should be a "language designed for
    >> interpretation", or better yet, "dynamic language", or bestest,
    >> "language with dynamic flavor". And slow language, oh no, should be
    >> "language whose current implementations are perceived as somewhat slow
    >> by some (well, all) people", but of course, that's just silly.

    >
    > Perhaps I'm missing the point of what you're saying but I don't see why
    > you're conflating interpreted and dynamic here? Javascript is unarguably
    > a dynamic language, yet Chrome / Safari 4 / Firefox 3.5 all typically
    > JIT it. Does that make Javascript non-dynamic, because it's compiled?
    > What about Common Lisp, which is a compiled language when it's run with
    > CMUCL or SBCL?


    Yeah, you missed it.

    Blurring and coloring and downright hiding reality by insisting on misleading
    but apparently more precise terminology for some vague concept is a popular
    sport, and chiding others for using more practical and real-world oriented
    terms, can be effective in politics and some other arenas.

    But in a technical context it's silly. Or dumb. Whatever.

    E.g. you'll find it impossible to define interpretation rigorously in the sense
    that you're apparently thinking of. It's not that kind of term or concept. The
    nearest you can get is in a different direction, something like "a program whose
    actions are determined by data external to the program (+ x qualifications and
    weasel words)", which works in-practice, conceptually, but try that on as a
    rigorous definition and you'll see that when you get formal about it then it's
    completely meaningless: either anything qualifies or nothing qualifies.

    You'll also find it impossible to rigorously define "dynamic language" in a
    general way so that that definition excludes C++. <g>

    So, to anyone who understands what one is talking about, "interpreted", or e.g.
    "slow language" (as was the case here), conveys the essence.

    And to anyone who doesn't understand it trying to be more precise is an exercise
    in futility and pure silliness -- except for the purpose of misleading.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Nov 12, 2009
    #12
  13. On Thu, 12 Nov 2009 11:24:18 -0800, Alf P. Steinbach <>
    wrote:

    > * Rami Chowdhury:
    >> On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach <>
    >> wrote:
    >>>
    >>> This also seems religious. It's like in Norway it became illegal to
    >>> market lemon soda, since umpteen years ago it's soda with lemon
    >>> flavoring. This has to do with the *origin* of the citric acid,
    >>> whether natural or chemist's concoction, no matter that it's the same
    >>> chemical. So, some people think that it's wrong to talk about
    >>> interpreted languages, hey, it should be a "language designed for
    >>> interpretation", or better yet, "dynamic language", or bestest,
    >>> "language with dynamic flavor". And slow language, oh no, should be
    >>> "language whose current implementations are perceived as somewhat slow
    >>> by some (well, all) people", but of course, that's just silly.

    >> Perhaps I'm missing the point of what you're saying but I don't see
    >> why you're conflating interpreted and dynamic here? Javascript is
    >> unarguably a dynamic language, yet Chrome / Safari 4 / Firefox 3.5 all
    >> typically JIT it. Does that make Javascript non-dynamic, because it's
    >> compiled? What about Common Lisp, which is a compiled language when
    >> it's run with CMUCL or SBCL?

    >
    > Yeah, you missed it.
    >
    > Blurring and coloring and downright hiding reality by insisting on
    > misleading but apparently more precise terminology for some vague
    > concept is a popular sport, and chiding others for using more practical
    > and real-world oriented terms, can be effective in politics and some
    > other arenas.
    >


    > But in a technical context it's silly. Or dumb. Whatever.
    >
    > E.g. you'll find it impossible to define interpretation rigorously in
    > the sense that you're apparently thinking of.


    Well, sure. Can you explain, then, what sense you meant it in?

    > You'll also find it impossible to rigorously define "dynamic language"
    > in a general way so that that definition excludes C++. <g>


    Or, for that matter, suitably clever assembler. I'm not arguing with you
    there.

    > So, to anyone who understands what one is talking about, "interpreted",
    > or e.g. "slow language" (as was the case here), conveys the essence.


    Not when the context isn't clear, it doesn't.

    > And to anyone who doesn't understand it trying to be more precise is an
    > exercise in futility and pure silliness -- except for the purpose of
    > misleading.


    Or for the purpose of greater understanding, surely - and isn't that the
    point?


    --
    Rami Chowdhury
    "Never attribute to malice that which can be attributed to stupidity" --
    Hanlon's Razor
    408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
     
    Rami Chowdhury, Nov 12, 2009
    #13
  14. * Rami Chowdhury:
    > On Thu, 12 Nov 2009 11:24:18 -0800, Alf P. Steinbach <>
    > wrote:
    >
    >> * Rami Chowdhury:
    >>> On Thu, 12 Nov 2009 09:32:28 -0800, Alf P. Steinbach <>
    >>> wrote:
    >>>>
    >>>> This also seems religious. It's like in Norway it became illegal to
    >>>> market lemon soda, since umpteen years ago it's soda with lemon
    >>>> flavoring. This has to do with the *origin* of the citric acid,
    >>>> whether natural or chemist's concoction, no matter that it's the
    >>>> same chemical. So, some people think that it's wrong to talk about
    >>>> interpreted languages, hey, it should be a "language designed for
    >>>> interpretation", or better yet, "dynamic language", or bestest,
    >>>> "language with dynamic flavor". And slow language, oh no, should be
    >>>> "language whose current implementations are perceived as somewhat
    >>>> slow by some (well, all) people", but of course, that's just silly.
    >>> Perhaps I'm missing the point of what you're saying but I don't see
    >>> why you're conflating interpreted and dynamic here? Javascript is
    >>> unarguably a dynamic language, yet Chrome / Safari 4 / Firefox 3.5
    >>> all typically JIT it. Does that make Javascript non-dynamic, because
    >>> it's compiled? What about Common Lisp, which is a compiled language
    >>> when it's run with CMUCL or SBCL?

    >>
    >> Yeah, you missed it.
    >>
    >> Blurring and coloring and downright hiding reality by insisting on
    >> misleading but apparently more precise terminology for some vague
    >> concept is a popular sport, and chiding others for using more
    >> practical and real-world oriented terms, can be effective in politics
    >> and some other arenas.
    >>

    >
    >> But in a technical context it's silly. Or dumb. Whatever.
    >>
    >> E.g. you'll find it impossible to define interpretation rigorously in
    >> the sense that you're apparently thinking of.

    >
    > Well, sure. Can you explain, then, what sense you meant it in?


    I think that was in the part you *snipped* here. Just fill in the mentioned
    qualifications and weasel words. And considering that a routine might be an
    intepreter of data produced elsewhere in program, needs some fixing...


    >> You'll also find it impossible to rigorously define "dynamic language"
    >> in a general way so that that definition excludes C++. <g>

    >
    > Or, for that matter, suitably clever assembler. I'm not arguing with you
    > there.
    >
    >> So, to anyone who understands what one is talking about,
    >> "interpreted", or e.g. "slow language" (as was the case here), conveys
    >> the essence.

    >
    > Not when the context isn't clear, it doesn't.
    >
    >> And to anyone who doesn't understand it trying to be more precise is
    >> an exercise in futility and pure silliness -- except for the purpose
    >> of misleading.

    >
    > Or for the purpose of greater understanding, surely - and isn't that the
    > point?


    I don't think that was the point.

    Specifically, I reacted to the statement that <<it is sheer nonsense to talk
    about "the" speed of an implementation>>, made in response to someone upthread,
    in the context of Google finding CPython overall too slow.

    It is quite slow. ;-)


    Cheers,

    - Alf
     
    Alf P. Steinbach, Nov 12, 2009
    #14
  15. On Thu, 12 Nov 2009 12:02:11 -0800, Alf P. Steinbach <>
    wrote:
    > I think that was in the part you *snipped* here. Just fill in the
    > mentioned qualifications and weasel words.


    OK, sure. I don't think they're weasel words, because I find them useful,
    but I think I see where you're coming from.

    > Specifically, I reacted to the statement that <<it is sheer nonsense to
    > talk about "the" speed of an implementation>>, made in response to
    > someone upthread, in the context of Google finding CPython overall too
    > slow.


    IIRC it was "the speed of a language" that was asserted to be nonsense,
    wasn't it? Which IMO is fair -- a physicist friend of mine works with a
    C++ interpreter which is relatively sluggish, but that doesn't mean C++ is
    slow...

    --
    Rami Chowdhury
    "Never attribute to malice that which can be attributed to stupidity" --
    Hanlon's Razor
    408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
     
    Rami Chowdhury, Nov 12, 2009
    #15
  16. On Thu, Nov 12, 2009 at 2:24 PM, Alf P. Steinbach <> wrote:
    >
    > You'll also find it impossible to rigorously define "dynamic language" in a
    > general way so that that definition excludes C++. <g>
    >
    > So, to anyone who understands what one is talking about, "interpreted", or
    > e.g. "slow language" (as was the case here), conveys the essence.
    >
    > And to anyone who doesn't understand it trying to be more precise is an
    > exercise in futility and pure silliness  --  except for the purpose of
    > misleading.


    You just made Rami's point. You can't define a language as <insert
    word here>. You can however describe what features it has - static vs.
    dynamic typing, duck-typing, dynamic dispatch, and so on. Those are
    features of the language. Other things, like "interpreted" vs
    "compiled" are features of the implementation. C++ for instance is
    considered language that gets compiled to machine code. However,
    Visual Studio can compile C++ programs to run on the .NET framework
    which makes them JIT compiled. Some one could even write an
    interpreter for C++ if they wanted to.
     
    Benjamin Kaplan, Nov 12, 2009
    #16
  17. On Thu, 12 Nov 2009 12:44:00 -0800, Benjamin Kaplan
    <> wrote:

    > Some one could even write an
    > interpreter for C++ if they wanted to.


    Someone has (http://root.cern.ch/drupal/content/cint)!

    --
    Rami Chowdhury
    "Never attribute to malice that which can be attributed to stupidity" --
    Hanlon's Razor
    408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
     
    Rami Chowdhury, Nov 12, 2009
    #17
  18. On Thu, 12 Nov 2009 21:02:11 +0100, Alf P. Steinbach wrote:

    > Specifically, I reacted to the statement that <<it is sheer nonsense to
    > talk about "the" speed of an implementation>>, made in response to
    > someone upthread, in the context of Google finding CPython overall too
    > slow.
    >
    > It is quite slow. ;-)


    Quite slow to do what? Quite slow compared to what?

    I think you'll find using CPython to sort a list of ten million integers
    will be quite a bit faster than using bubblesort written in C, no matter
    how efficient the C compiler.

    And why are we limiting ourselves to integers representable by the native
    C int? What if the items in the list were of the order of 2**100000? Of
    if they were mixed integers, fractions, fixed-point decimals, and
    floating-point binaries? How fast is your C code going to be now? That's
    going to depend on the C library you use, isn't it? In other words, it is
    an *implementation* issue, not a *language* issue.

    Okay, let's keep it simple. Stick to numbers representable by native C
    ints. Around this point, people start complaining that it's not fair, I'm
    not comparing apples with apples. Why am I comparing a highly-optimized,
    incredibly fast sort method in CPython with a lousy O(N**2) algorithm in
    C? To make meaningful comparisons, you have to make sure the algorithms
    are the same, so the two language implementations do the same amount of
    work. (Funnily enough, it's "unfair" to play to Python's strengths, and
    "fair" to play to C's strengths.)

    Then people invariable try to compare (say) something in C involving low-
    level bit-twiddling or pointer arithmetic with something in CPython
    involving high-level object-oriented programming. Of course CPython is
    "slow" if you use it to do hundreds of times more work in every operation
    -- that's comparing apples with oranges again, but somehow people think
    that's okay when your intention is to prove "Python is slow".

    An apples-to-apples comparison would be to use a framework in C which
    offered the equivalent features as Python: readable syntax ("executable
    pseudo-code"), memory management, garbage disposal, high-level objects,
    message passing, exception handling, dynamic strong typing, and no core
    dumps ever.

    If you did that, you'd get something that runs much closer to the speed
    of CPython, because that's exactly what CPython is: a framework written
    in C that provides all those extra features.

    (That's not to say that Python-like high-level languages can't, in
    theory, be significantly faster than CPython, or that they can't have JIT
    compilers that emit highly efficient -- in space or time -- machine code.
    That's what Psyco does, now, and that's the aim of PyPy.)

    However, there is one sense that Python *the language* is slower than
    (say) C the language. Python requires that an implementation treat the
    built-in function (say) int as an object subject to modification by the
    caller, while C requires that it is a reserved word. So when a C compiler
    sees "int", it can optimize the call to a known low-level routine, while
    a Python compiler can't make this optimization. It *must* search the
    entire scope looking for the first object called 'int' it finds, then
    search the object's scope for a method called '__call__', then execute
    that. That's the rules for Python, and an implementation that does
    something else isn't Python. Even though the searching is highly
    optimized, if you call int() one million times, any Python implementation
    *must* perform that search one million times, which adds up. Merely
    identifying what function to call is O(N) at runtime for Python and O(1)
    at compile time for C.

    Note though that JIT compilers like Psyco can often take shortcuts and
    speed up code by a factor of 2, or up to 100 in the best cases, which
    brings the combination of CPython + Psyco within shouting distance of the
    speed of the machine code generated by good optimizing C compilers. Or
    you can pass the work onto an optimized library or function call that
    avoids the extra work. Like I said, there is no reason for Python
    *applications* to be slow.


    --
    Steven
     
    Steven D'Aprano, Nov 13, 2009
    #18
  19. When I was approximately 5, everybody knew that higher level languages were too slow for high-speed numeric computation (I actually didn't know that then, I was too busy watching Bill and Ben the Flowerpot Men), and therefore assembly languages were mandatory. Then IBM developed Fortran, and higher-level languages were not too slow for numeric computation.

    When I was in university, IBM released a perfectly horrible implementation of PL/I, which dynamically allocated and freed stack frames for each procedure entry and exit (`Do Not Use Procedures: They Are Inefficient': section heading from the IBM PL/I (G) Programmer's Guide, circa 1968). Everyone knew PL/I was an abomination of a language, which could not be implemented efficiently. Then MIT/Bell Labs/GE/Honeywell wrote Multics in a PL/I subset, and (eventually) it ran quite efficiently.

    When Bell Labs pulled out of the Multics effort, some of their researchers wrote the first version of Unix in assembly language, but a few years later rewrote the kernel in C. Their paper reporting this included a sentence that said in effect, `yes, the C version is bigger and slower than the assembler version, but it has more functionality, so C isn't so bad'. Everybody knew that high-level languages were too inefficient to write an operating system in (in spite of the fact that Los Alamos had already written an OS in a Fortran dialect). Nobody knew that at about that time, IBM had started writing new OS modules in a company-confidential PL/I subset.

    When I was in grad school, everybody knew that an absolute defence to a student project running slowly was `I wrote it in Lisp'; we only had a Lisp interpreter running on our system. We didn't have MacLisp, which had been demonstrated to compile carefully-written numerical programs into code that ran more efficiently than comparable programs compiled by DEC's PDP-10 Fortran compiler in optimizing mode.

    In an earlier post, I mentioned SBCL and Chez Scheme, highly optimizing compiler-based implementations of Common Lisp and Scheme, respectively. I don't have numbers for SBCL, but I know that (again with carefully-written Scheme code) Chez Scheme can produce code that runs in the same order of magnitude as optimized C code. These are both very old systems that, at least in the case of Chez Scheme, use techniques that have been reported in the academic literature. My point in the earlier post about translating Python into Common Lisp or Scheme was essentially saying `look, there's more than 30 years experience building high-performance implementations of Lisp languages, and Python isn't really that different from Lisp, so we ought to be able to do it too'.

    All of which leads me to summarize the current state of things.

    1. Current Python implementations may or may not be performance-scalable in ways we need.

    2. Reorganized interpreters may give us a substantial improvement in performance. More significant improvements would require a JIT compiler, and there are good projects such as Unladen Swallow that may well deliver a substantial improvement.

    3. We might also get improvements from good use of Python 3 annotations, or other pragma style constructs that might be added to the language after the moratorium, which would give a compiler additional information about the programmer's intent. (For example, Scheme has a set of functions that essentially allow a programmer to say, `I am doing integer arithmetic with values that are limited in range to what can be stored in a machine word'.) These annotations wouldn't destroy the dynamic nature of Python, because they are purely optional. This type of language feature would allow a programmer to exploit the high-performance compilation technologies that are common in the Lisp world.

    Even though points (2) and (3) between them offer a great deal of hope for future Python implementations, there is much that can be done with our current implementations. Just ask the programmer who writes a loop that laboriously does what could be done much more quickly with a list comprehension or with map.

    -- v
     
    Vincent Manis, Nov 13, 2009
    #19
  20. On Thu, 12 Nov 2009 22:20:11 -0800, Vincent Manis wrote:

    > When I was approximately 5, everybody knew that higher level languages were too slow for high-speed numeric computation (I actually didn't know that then, I was too busy watching Bill and Ben the Flowerpot Men), and therefore assembly languages were mandatory. Then IBM developed Fortran, and higher-level languages were not too slow for numeric computation.


    Vincent, could you please fix your mail client, or news client, so
    that it follows the standard for mail and news (that is, it has a
    hard-break after 68 or 72 characters?

    Having to scroll horizontally to read your posts is a real pain.


    --
    Steven
     
    Steven D'Aprano, Nov 13, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sascha Kerschhofer

    SVG scaleable?

    Sascha Kerschhofer, Jul 15, 2003, in forum: XML
    Replies:
    6
    Views:
    2,043
  2. Jens Piegsa

    Scaleable Swing components

    Jens Piegsa, Dec 16, 2006, in forum: Java
    Replies:
    0
    Views:
    317
    Jens Piegsa
    Dec 16, 2006
  3. jsqrd

    Scaleable naviagtion pane

    jsqrd, Mar 2, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    293
    jsqrd
    Mar 2, 2007
  4. metaperl
    Replies:
    4
    Views:
    333
    Chris Uppal
    Mar 3, 2007
  5. Robert P. J. Day

    python simply not scaleable enough for google?

    Robert P. J. Day, Nov 11, 2009, in forum: Python
    Replies:
    11
    Views:
    706
    Robin Becker
    Nov 23, 2009
Loading...

Share This Page