Is python very slow compared to C

[fox@ultratechnology.com]

Re: Is Forth for real?

rickman wrote:[color=blue]
> The original post seems to be missing, but my answer to the title
> question is, No, Forth is not real.[/color]

Not for real, for Integer.

[Isaac Gouy]

Re: Is python very slow compared to C

Steven D'Aprano wrote:[color=blue]
> On Sun, 12 Feb 2006 03:03:20 -0800, bearophileHUGS wrote:
>[color=green]
> > Steven D'Aprano>Very slow to do what, compared to what? The decay time
> > of the tau meson?<
> >
> > Probably every answer I can give you is wrong for you, so answering is
> > almost useless...[/color]
>
> We do actually agree. You did explain why the speed of the language itself
> is rarely the critical factor. My criticism is that whatever good your
> post would have done was nullified by your opening comment stating that
> Python is very slow -- a comment which I think is not only harmful, but
> wrong, benchmarks like the one you linked to not withstanding.
>
> I think it is wrong to call Python "very slow" just because it is slower
> than some other language or languages, for the same reason it would be
> wrong to describe the population of the UK as "very low" because 60
> million people is a smaller number than China or India's one billion plus.
> Doing so merely reinforces the premature optimizer's message that any
> language that isn't C (and sometimes Lisp) is "not fast enough".[/color]

There was some context: Is python very slow compared to C?

With similar context your example becomes: Is the population of the UK
very low compared to the population of China or India? (Which seems to
be a reasonable question.)

We can make the missing context in the OP's question more obvious like
this: Is the population of the UK very /slow/ compared to the
population of China or India?

[color=blue]
> The benchmark you pointed to are of limited use for application
> developers. (Their value to language designers is another story.)[/color]

Limited use for what purpose?
(Yes it really is difficult to make all our assumptions explicit in our
writing.)
[color=blue]
> Given
> that Ocaml is (say) 200 times faster than Python on average, it tells the
> application developer virtually nothing about the performance of his
> application. And that's what user's care about -- they couldn't care less
> about binary trees or partial sums, they care about how long it takes to
> render a JPEG, open an email, save their files, query the database,
> display a window, and so forth. Few application level tasks are limited by
> the speed of the language, not these days.[/color]

As in

http://shootout.alioth.debian.org/miscfile.php?file=benchmarking&title=Flawed%20Benchmarks

[color=blue]
>
> You don't believe me? Consider the following:
>
> When you drag your mouse over text in a graphical text editor, the text
> highlights. How much money would you be prepared to pay to make that
> highlighting occur 200 times faster? $100? $1? One cent? Chances are you
> wouldn't pay a thing, because it is already fast enough, and making it
> faster is of zero value to you -- even if highlighting ten gigabytes of
> text might be uncomfortably slow.
>
> What about opening an email? How much would you pay to reduce the time it
> takes to open and display an email from a hundredth of a second to
> virtually instantaneously ? I suggest that most people would consider 0.01s
> to already be be "virtually instantaneously ".
>
> The important question isn't "is Python fast or slow?", it is "is Python
> fast enough?". That's a question that doesn't have a simple answer,
> because it depends. Fast enough to do what?
>
> But, in general, more often than not, Python is fast enough. The extra
> value of using something like Lua or Ocaml or even C is just not enough to
> make up for the disadvantages of using those languages.[/color]

Seems like you're having your cake and eating it too - if it's
meaningless for others to talk in generalities about fast or slow, and
it's just as meaningless to talk in generalities about 'more often than
not'.
[color=blue]
>
> Of course Python isn't always fast enough. Please don't waste your time
> coming up with practical examples where pure Python is objectively too
> slow for a certain task, because you won't be telling me anything I don't
> already know.
>
> But the developer doesn't have to write pure Python, he can call a module
> written in C, or change the algorithm, or find another way to accomplish
> the same end result. Or even decide that for this specific task, Python is
> not the language to use. These are all good solutions, but they don't mean
> that Python is "very slow" in general. Even C is not always fast enough,
> but we wouldn't say C is "very slow" just because it can't calculate the
> first million Mersenne Primes in twenty milliseconds.
>
>
> --
> Steven.[/color]

[Magnus Lycka]

Re: Is python very slow compared to C

Isaac Gouy wrote:[color=blue][color=green]
>>I think it is wrong to call Python "very slow" just because it is slower
>>than some other language or languages, for the same reason it would be
>>wrong to describe the population of the UK as "very low" because 60
>>million people is a smaller number than China or India's one billion plus.
>>Doing so merely reinforces the premature optimizer's message that any
>>language that isn't C (and sometimes Lisp) is "not fast enough".[/color]
>
> There was some context: Is python very slow compared to C?[/color]

But that is a stupid context. It doesn't really tell us
anything. Slow at what?

No one writes a program for the purpose of doing loops,
comparing integers, setting up stack frames or jumping
between instructions.

The context for programming typically involves solving some
problem or executing a function that matters to the user.

It's just as database benchmarks. TPC C benchmarks tells us
how fast a certain database is at performing TPC C benchmarks.
Does that tell you anything about how fast it will be compared
to competing products for your real world problem? Probably
not. Which ever product you choose, you might end up with
situations where a particular function is too slow. You can
typically solve this either by changing the code or the
configuration of the server. Sometimes you have to rethink
your system and solve the problem in another way. Changing
from e.g. DB2 to Oracle is unlikely to have more impact than
these smaller changes. It's the same thing with most software
development.
[color=blue][color=green]
>> The benchmark you pointed to are of limited use for application
>> developers. (Their value to language designers is another story.)[/color]
>
> Limited use for what purpose?[/color]

They are more or less useless for anyone who wants to decide
what programming language to use in a real world situation.
It's simply stupid to implement sorting algorithms in Python.
It's there already. Solving Ackermann's is also rather far
from what people typically want to achieve. If people actually
had the time and resources to create real software products,
(i.e. things that take man-months to create) from the same
spec, and developed e.g. ten programs each each ten different
programming languages in cleanroom conditions, we'd probably
learn something useful about the usefulness of a certain type
of programs with certain programming languages in certain
conditions, but only in these conditions. I'm rather certain
that aspects such as team size, development methodology etc
will influence the relative ratings of programs.

I'm not saying that the typical toy benchmarks are completely
useless. They might tell us things about particular language
features that should be improved, or give us clues that a
certain way of solving a particular problem etc, but they
don't really help Joe Newbie Programmer who wants to write
yet another web site toolkit.

[igouy@yahoo.com]

Re: Is python very slow compared to C


Magnus Lycka wrote:[color=blue]
> Isaac Gouy wrote:[color=green][color=darkred]
> >>I think it is wrong to call Python "very slow" just because it is slower
> >>than some other language or languages, for the same reason it would be
> >>wrong to describe the population of the UK as "very low" because 60
> >>million people is a smaller number than China or India's one billion plus.
> >>Doing so merely reinforces the premature optimizer's message that any
> >>language that isn't C (and sometimes Lisp) is "not fast enough".[/color]
> >
> > There was some context: Is python very slow compared to C?[/color]
>
> But that is a stupid context. It doesn't really tell us
> anything. Slow at what?[/color]

As I said: We can make /the missing context/ in the OP's question more
obvious...

[color=blue]
>
> No one writes a program for the purpose of doing loops,
> comparing integers, setting up stack frames or jumping
> between instructions.
>
> The context for programming typically involves solving some
> problem or executing a function that matters to the user.
>
> It's just as database benchmarks. TPC C benchmarks tells us
> how fast a certain database is at performing TPC C benchmarks.
> Does that tell you anything about how fast it will be compared
> to competing products for your real world problem? Probably
> not. Which ever product you choose, you might end up with
> situations where a particular function is too slow. You can
> typically solve this either by changing the code or the
> configuration of the server. Sometimes you have to rethink
> your system and solve the problem in another way. Changing
> from e.g. DB2 to Oracle is unlikely to have more impact than
> these smaller changes. It's the same thing with most software
> development.
>[color=green][color=darkred]
> >> The benchmark you pointed to are of limited use for application
> >> developers. (Their value to language designers is another story.)[/color]
> >
> > Limited use for what purpose?[/color]
>
> They are more or less useless for anyone who wants to decide
> what programming language to use in a real world situation.[/color]

Good that's more explicit.

One of the program contributors told me they do something quite similar
to fasta, k-nucleotide and reverse-complement in their real world
situation.

Isn't it possible that someone would look through The Computer Language
Shootout programs and decide that language X was unusable convoluted
gobbledegook?

[color=blue]
> It's simply stupid to implement sorting algorithms in Python.
> It's there already. Solving Ackermann's is also rather far
> from what people typically want to achieve.[/color]

What "sorting algorithm" are you talking about?
There isn't one on http://shootout.alioth.debian.org/gp4/

Solving Ackermann's? Well if that was really the point then the
programs would be allowed to use memoization rather than simple
recursion.

[color=blue]
> If people actually
> had the time and resources to create real software products,
> (i.e. things that take man-months to create) from the same
> spec, and developed e.g. ten programs each each ten different
> programming languages in cleanroom conditions, we'd probably
> learn something useful about the usefulness of a certain type
> of programs with certain programming languages in certain
> conditions, but only in these conditions. I'm rather certain
> that aspects such as team size, development methodology etc
> will influence the relative ratings of programs.
>
> I'm not saying that the typical toy benchmarks are completely
> useless. They might tell us things about particular language
> features that should be improved, or give us clues that a
> certain way of solving a particular problem etc, but they
> don't really help Joe Newbie Programmer who wants to write
> yet another web site toolkit.[/color]

[rickman]

Re: Is Forth for real?


fox@ultratechno logy.com wrote:[color=blue]
> rickman wrote:[color=green]
> > The original post seems to be missing, but my answer to the title
> > question is, No, Forth is not real.[/color]
>
> Not for real, for Integer.[/color]

:-)

[astrobe@netcourrier.com]

Re: Is Forth for real?


fox@ultratechno logy.com a écrit :
[color=blue]
> rickman wrote:[color=green]
> > The original post seems to be missing, but my answer to the title
> > question is, No, Forth is not real.[/color]
>
> Not for real, for Integer.[/color]

No, it's for me and you (well, perhaps more for you than for me).
But 4IM is forever mine :)

Amicalement,
Astrobe