Python future performance and speed

[Baalbek]

Re: Python future performance and speed

Aahz wrote:
[color=blue]
> In article <278de0e.040822 1450.324e8178@p osting.google.c om>,
> Neuruss <luismg@gmx.net > wrote:[/color]
[color=blue][color=green]
>>I didn't want to start a silly thread to discuss wether python is slow
>>or not. It is. Period.[/color]
>
>
> Nope. Speed is relative. Is a car slow? Depends whether you're trying
> to go five feet, five miles, fifty miles, five hundred miles, or five
> thousand miles -- and it also depends on the alternatives available for
> traversing that distance. Repeatedly claiming that Python is slow as an
> absolute statement only shows your ignorance and unwillingness to listen
> to other people.[/color]

Python on today's machines probably runs a lot faster than C programs
did on machines 20 years ago (or even 10 years ago).

Baalbek

[Neuruss]

Re: Python future performance and speed

> >I love Python. It's an excellent, fun, clear, well designed language[color=blue][color=green]
> >and it is fast enough for 90% of the cases. But you can't deny that
> >for some problem domains, it is slow. Very slow.[/color]
>
> That's true. If that's what you'd said in the first place, nobody would
> have argued with you...[/color]

I already replied a similar comment in my previous post.

[color=blue]
> If you're going to make a claim that speed is Python's main limitation,
> you'll need to provide evidence to support your assertion.[/color]

Same as above.

[color=blue][color=green]
> >I didn't want to start a silly thread to discuss wether python is slow
> >or not. It is. Period.[/color]
>
> Nope. Speed is relative. Is a car slow? Depends whether you're trying
> to go five feet, five miles, fifty miles, five hundred miles, or five
> thousand miles -- and it also depends on the alternatives available for
> traversing that distance. Repeatedly claiming that Python is slow as an
> absolute statement only shows your ignorance and unwillingness to listen
> to other people.[/color]

I got your point and I used those lines myself many times.
I'm not making an absolute statement as though I'm a fundamentalist
fanatic of speed. What I mean, is that it is widely known that
scripting languages have a considerably lack of speed compared with
static typed languages (I didn't discover anything new, and this is
what I mean when I repeated the statement that python is not fast).
Again, as I already explained, I'm not saying that other people's
oppinion are wrong, when I used the word "nonsense" I wanted to say
that the whole discussion is in which we were all involved is
nonsense, because there's no use in discussing whether python is slow
or not. This is a proven fact.

Your arguments regarding the relativity of speed are correct and
nobody is denying it. But I am talking about this little percentage of
applications, that use to be the most relevant (usually) in enterprise
environments or in commercial applications where high volumes of data
are processed, as well as 3d programs, games, etc..).
My point is:
It is my humble oppinion (and I already acknowledged that I SHOULD
HAVE USED THIS TERMS BEFORE), that this is the main reason that
explains the little acceptance of Python in certain professional
circles.

Now, you can agree with me or not. In that case, your oppinion is
welcome, but I don't need a moral lesson as to how I should address
these topics.
I guess I already said what I have to say about my oppinions.

If I hurted someone I'm sorry!
I hope that we can move on with this topic and you can stop dissecting
my phrases looking for something new to disavow...


[color=blue][color=green]
> >All the other comments on this thread, regarding the main limitation
> >for python's acceptance are true, but speed is critical, and this is
> >were all efforts should be concentrated.[/color]
>
> That's nice. If that's your belief, what are you doing to work on this?[/color]

Again, I already replied this.
[color=blue][color=green]
> >So my intention when I started this thread, was to learn more about
> >these projects, read other oppinions, get some news, etc... I didn't
> >mean to start a a nonsense discussion![/color]
>
> Believe me, I'm sympathetic to the fact that English is not a comfortable
> language for you. However, at this point, the problem appears to be a
> thinking problem, not a language problem. You simply hold an opinion at
> odds with the experience of many expert Python programmers, and it's one
> that is almost guaranteed to start an argument.[/color]

I don't know how to comment on this without being recursive.

[Neuruss]

Re: Python future performance and speed

> > That's true. If that's what you'd said in the first place, nobody would[color=blue][color=green]
> > have argued with you. However, this is what you said:
> >
> > It seems there are quite a few projects aimed to improve Python's
> > speed and, therefore, eliminate its main limitation for mainstream
> > acceptance.[/color]
>
> Hey, cut the boy/girl some slack. I suspect what s/he meant to say was:
>
> It seems there are quite a few projects aimed to improve Python's
> speed and, therefore, eliminate its main perceived limitation for
> mainstream acceptance.[/color]



At least someone who got it right!!!
I thought this was the spanish inquisition...

[Neuruss]

Re: Python future performance and speed

> OK guys.[color=blue]
>
> Now that you've debated at length of the first question addressed by
> Neuruss (Python limitations for mainstream acceptance), why not come
> back to the other aspects addressed:
>
> - dynamic languages getting closer to static languages in terms of
> speed
> - the future of Psyco, Pypy, Starkiller, Ironpython and other similar
> projects.[/color]


( Thanks Arthur for getting this back on track... )

Regarding Starkiller, I'm eagerly waiting for its release.
I sent Mike Salib an email asking for the current state of the project
(this was by the end of june) and he kindly replied that he was
redoing some parts in an effort to make the code comprehendable and
maintainable.
According to him, it would be released in a few weeks.

IMHO, a static type inferencer with a c++ compiler for python would
completely change the position of python against other alternatives.
Just imagine having all the flexibility and dynamism of python with
near c speed.
Developers would start using it for problem domains that where
previously dominated by java, c++ or other static typed languages. And
all this without having to write any extension in C.
No more "python as a glue" language, or "python for quick on-time
scripts", this would stabilish it as a solid alternative for
performance critical applications (I know it's being already used for
many important projects--please don't start a flame war-- but still it
is considered by many as a language for simple things).
Mike Salib goes as far as stating than in two years, python will be
faster than C/C++.

I also have news about Ironpython. According to a comment posted by
Jim Hugunin in his new blog, he has high hopes about the combination
of static type inference and dynamic languages.

However, it is my impression that there's a little bit of distrust
about these claims (it's just my impression, I might be wrong).
I wonder what's the oppinion of the other participants of this mailing
list...

[Jacek Generowicz]

Re: Python future performance and speed

Peter Hansen <peter@engcorp. com> writes:
[color=blue]
> The last time I checked, Java and C++ (even C) were widely
> considered to be high level languages.[/color]

The fact many people hold an erroneous belief, does not make said
belief any less erroneous.
[color=blue]
> Has someone been raising the bar while I wasn't looking?[/color]

The developers of all the truly high-level languages ?

There was a time when assembler was high-level.

[Jacek Generowicz]

Re: Python future performance and speed

beliavsky@aol.c om writes:

[color=blue]
> (2) The Python approach to OOP is very different -- looser -- than
> that of C++ and has less support for data hiding. For example, one can
> add an attribute to an object anywhere, which seems like a dubious
> freedom to me.[/color]

Seems like a damn useful freedom to me. But then I've worked with
people who refused to take the obvious clean, efficent, clear design
decision only because it violated some principle they were told about
in some OOA&D class ... only to insist on creating a program which was
slow, ugly, difficult to understand, difficult to maintain, and had a
few less useful features.
[color=blue]
> (3) The beginning of a Python function only tells you about the
> arguments, not the result. I prefer not to scan the entire body of a
> function to see what it returns. Compiled languages like C++, Fortran,
> and Pascal put the argument and result info in one place.[/color]

And compiled lanugages like Lisp[1] and Python[2] don't. Oh, you meant
"explicitly statically typed", rather than "compiled", I see :-)

But caring about the type to this extent is not a very productive way
of programming in Python. You should understand the purpose of the
function, and thereby understand the duck types it accepts and returns
.... and duck types are not expressible in a way that wouldn't make a
explicitly static compiler smoke.

Of course, those coming from the bondage school of programming (C++,
Java ...) will run screaming when confronted with duck typing, but
that's their loss.
[color=blue]
> (4) Python does not look like C++. Some programmers think that any
> alternative to C++ must still look like it. I think this argument is
> weak, but Java's cosmetic similarity to C++ probably has boosted its
> popularity.[/color]

This is one of the greatest tragedies: C++ is accepted as the starting
point. We're doomed.



[1] Compiled to native machine code (usually).

[2] Compiled to bytecode (usually).

[Roy Smith]

Re: Python future performance and speed

Jacek Generowicz <jacek.generowi cz@cern.ch> wrote:[color=blue][color=green]
>> (2) The Python approach to OOP is very different -- looser -- than
>> that of C++ and has less support for data hiding. For example, one can
>> add an attribute to an object anywhere, which seems like a dubious
>> freedom to me.[/color]
>
> Seems like a damn useful freedom to me. But then I've worked with
> people who refused to take the obvious clean, efficent, clear design
> decision only because it violated some principle they were told about
> in some OOA&D class[/color]

Yeah, tell me about it. We had a really smart young guy who grew up on
C++ and was convinced that C++ was the be-all and end-all of OOP. He
told me flat out that Python was not an OOPL because it didn't have
private data. Of course, he never actually tried Python, because he
"just couldn't get past the whole indenting thing".

Then he quit and took a higher paying job with a big financial company
maintaining legacy Fortran code. Go figure.

[Peter Hansen]

Re: Python future performance and speed

Jacek Generowicz wrote:[color=blue]
> Peter Hansen <peter@engcorp. com> writes:[color=green]
>>The last time I checked, Java and C++ (even C) were widely
>>considered to be high level languages.[/color]
> The fact many people hold an erroneous belief, does not make said
> belief any less erroneous.[/color]

Though if you are the only one who holds the "correct" belief,
and everyone else has the erroneous belief, it should suggest
a possible direction for you to look in resolving the conflict. ;-)
[color=blue][color=green]
>>Has someone been raising the bar while I wasn't looking?[/color]
> The developers of all the truly high-level languages ?
>
> There was a time when assembler was high-level.[/color]

For those of us who still use assember from time to time,
C is definitely still a high level language...

-Peter