Re: python speed

[Isaac Gouy]

Peter Hansen wrote:
> David Rasmussen wrote:
> > Frithiof Andreas Jensen wrote:
> >>From the speed requirement: Is that correspondance chess by any chance??
> >
> > Regular chess at tournament time controls requires speed too. Any pure
> > Python chess program would lose badly to the best C/C++ programs out
> > there now.
> >
> > I would also like to see Half Life 2 in pure Python.
>
> True, but so what?  Why did you suddenly change the discussion to
> require "pure" Python?  And please define "pure" Python, given that the
> interpreter and many builtins, not to mention many widely used extension
> modules, are coded in C?  And are you not allowed to use any of the
> performance-boosting techniques available for Python, like Pyrex or
> Psyco?  Why such restrictions, when these are things Python programs use
> on a daily basis: these are *part* of Python, as much as the -O switch
> on the compiler is part of C/C++.
>
> Okay, let's compare a "pure" Python program (if you can define it in any
> meaningful, practical way) with a "pure" Java program, running on a
> non-JIT interpreter and with optimizations turned off (because, of
> course, those optimizations are umm... somehow.. not "pure"...?).
>
> Judging by the other posts in this thread, the gauntlet is down: Python
> is faster than Java.  Let those who believe otherwise prove their point
> with facts, and without artificially handcuffing their opponents with
> non-real-world "purity" requirements.
>
> -Peter

That form of argument is listed as one of the principal forms of
illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
Disprove Does Not Prove"

"The fact that there is no concrete proof against a position does not
constitute an argument in favour of the position. I cannot claim to be
right simply because you can't prove me to be wrong."

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python speed

[Isaac Gouy]

Peter Hansen wrote:
> Isaac Gouy wrote:
> > Peter Hansen wrote:
> >>Judging by the other posts in this thread, the gauntlet is down: Python
> >>is faster than Java.  Let those who believe otherwise prove their point
> >>with facts, and without artificially handcuffing their opponents with
> >>non-real-world "purity" requirements.
>
> > That form of argument is listed as one of the principal forms of
> > illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
> > Disprove Does Not Prove"
>
> Good thing this is the form of argument *against* which I was arguing,
> rather than that which I choose to use myself.  (Read very carefully, if
> you really think I was saying otherwise, and point out exactly where I
> made any such claims for my own part.  In fact, I was referencing the
> arguments of others -- who *were* supporting their arguments with facts,
> as near as I can tell -- and I was calling on the opposition to do the
> same, and without changing the rules mid-discussion.)
>
> > "The fact that there is no concrete proof against a position does not
> > constitute an argument in favour of the position. I cannot claim to be
> > right simply because you can't prove me to be wrong."
>
> Isn't that what I was saying?  That those who claim Python isn't faster
> were not supporting their arguments with actual facts?
>
> -Peter

*Python is faster than Java.  Let those who believe otherwise prove
their point with facts*

We must be looking at different threads :-)

afaict the only posting that provided something like "facts" was
http://groups.google.com/group/comp.lang.python/msg/309e439697279060

Which stated "Python is doing the heavy lifting with GMPY which is a
compiled C program with a Python wrapper" - but didn't seem to compare
that to GMPY with a Java wrapper?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python speed

[Isaac Gouy]

[EMAIL PROTECTED] wrote:
> Isaac Gouy wrote:
>
> > Which stated "Python is doing the heavy lifting with GMPY which is a
> > compiled C program with a Python wrapper" - but didn't seem to compare
> > that to GMPY with a Java wrapper?
>
> You are missing the main idea: Java is by design a general purpose
> programming language. That's why all "GMPYs" and alike are written in
> Java - now wrappers to C-libraries. Python, by design, is glue
> language. Python program is assembly of  C extensions and buildins
> wrapped in Python sintax.
>
> IHMO "real life" benchmark yuo are critisizing represents real life
> situation.

"1.1.3   What is Python good for?
Python is a high-level general-purpose programming language that can be
applied to many different classes of problems."

http://www.python.org/doc/faq/general.html#what-is-python-good-for

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python speed

[Isaac Gouy]

[EMAIL PROTECTED] wrote:
> Isaac Gouy wrote:
> > Peter Hansen wrote:
> > > Isaac Gouy wrote:
> > > > Peter Hansen wrote:
> > > >>Judging by the other posts in this thread, the gauntlet is down: Python
> > > >>is faster than Java.  Let those who believe otherwise prove their point
> > > >>with facts, and without artificially handcuffing their opponents with
> > > >>non-real-world "purity" requirements.
> > >
> > > > That form of argument is listed as one of the principal forms of
> > > > illogical thinking in "Being Logical" D.Q.McInerny - "An Inability to
> > > > Disprove Does Not Prove"
> > >
> > > Good thing this is the form of argument *against* which I was arguing,
> > > rather than that which I choose to use myself.  (Read very carefully, if
> > > you really think I was saying otherwise, and point out exactly where I
> > > made any such claims for my own part.  In fact, I was referencing the
> > > arguments of others -- who *were* supporting their arguments with facts,
> > > as near as I can tell -- and I was calling on the opposition to do the
> > > same, and without changing the rules mid-discussion.)
> > >
> > > > "The fact that there is no concrete proof against a position does not
> > > > constitute an argument in favour of the position. I cannot claim to be
> > > > right simply because you can't prove me to be wrong."
> > >
> > > Isn't that what I was saying?  That those who claim Python isn't faster
> > > were not supporting their arguments with actual facts?
> > >
> > > -Peter
> >
> > *Python is faster than Java.  Let those who believe otherwise prove
> > their point with facts*
> >
> > We must be looking at different threads :-)
> >
> > afaict the only posting that provided something like "facts" was
> > http://groups.google.com/group/comp.lang.python/msg/309e439697279060
> >
> > Which stated "Python is doing the heavy lifting with GMPY which is a
> > compiled C program with a Python wrapper" - but didn't seem to compare
> > that to GMPY with a Java wrapper?
>
> Is there such an animal? I only know about Java's BigInteger.

Google.

http://dev.i2p.net/javadoc/net/i2p/util/NativeBigInteger.html

> And if there is, it just proves my point that benchmarks are
> worthless.

How so?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python speed

[Isaac Gouy]

Fredrik Lundh wrote:
> Cameron Laird wrote:
>
> >>You are missing the main idea: Java is by design a general purpose
> >>programming language. That's why all "GMPYs" and alike are written in
> >>Java - now wrappers to C-libraries. Python, by design, is glue
> > .
> > I don't understand the sentence, "That's why all 'GMPYs' and alike ..."
> > Are you saying that reuse of code written in languages other than Java
> > is NOT important to Java?  I think that's a reasonable proposition; I'm
> > just having trouble following your paragraph.
>
> replace "now" with "not" or perhaps "instead of being implemented as",
> and it may become a bit easier to parse.
>
> and yes, the proposition matches my experiences.  java heads prefer to do
> everything in java, while us pythoneers happily mix and match whenever we
> can...  (which is why guoy's "benchmarks" says so little about Python; if you
> cannot use smart algorithms and extensions where appropriate, you're not
> really using Python as it's supposed to be used)
>
> 

If you can't use C where appropriate, you're not really using Python as
it's supposed to be used? :-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python speed

[Isaac Gouy]

Fredrik Lundh wrote:
> Isaac Gouy wrote:
>
> >> and yes, the proposition matches my experiences.  java heads prefer to do
> >> everything in java, while us pythoneers happily mix and match whenever we
> >> can...  (which is why guoy's "benchmarks" says so little about Python; if 
> >> you
> >> cannot use smart algorithms and extensions where appropriate, you're not
> >> really using Python as it's supposed to be used)
> >
> > If you can't use C where appropriate, you're not really using Python as
> > it's supposed to be used? :-)
>
> who's talking about C ?  and what's the connection between C and smart
> algorithms ?
>
> 

[EMAIL PROTECTED] wrote:
> Python program is assembly of  C extensions and buildins
> wrapped in Python sintax.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Duck typing alows true polymorfisim

[Isaac Gouy]

The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, Tor Iver Wilhelmsen
> <[EMAIL PROTECTED]>
>  wrote
> on 31 Aug 2006 18:31:15 +0200
> <[EMAIL PROTECTED]>:
> > The Ghost In The Machine <[EMAIL PROTECTED]> writes:
> >
> >> Also, one language is very conspicuous by its absence: C#.
> >
> > He does not date any of the updates, so it's unclear how recently it
> > has been updated (a lot of the web is stale, like a rotting tree in a
> > forest.)
>
> Aye; my webpage has a similar problem. :-)
>
> >
> >> AmigaBasic -- Microsoft-sponsored Amiga variant
> >
> > Well, at the time Microsoft were the makers of the de-facto BASIC
> > implementations - M-BASIC for CP/M, the various variants in VC-20 and
> > C-64 and later derivates of those, and many other home computers.
> > "Sponsored" should probably be "created" instead - I assume they were
> > paid for the job.
>
> OK, "created" then. :-)
>
>
> >
> >> Also, Java now has templates. (The implementation is pretty gross
> >> and has some quirks, IMO, but it's better than nothing.) C++ has a
> >> typing system ("type_of" or some such; I'd have to look) which
> >> yields little more than the mangled type name and static inheritance
> >> testing capabilities. Of course C++ doesn't have dynamic inheritance
> >> anyway.
> >
> > There's the virtual stuff, and you could conceivably implement dynamic
> > inheritance via the bare-bones C layer - like function pointers. The
> > type information in C++ (RTTI) is optional.
>
> Oh yeah, that's true.  Still not all that dynamic, though, unless
> one recompiles.
>
> >
> >> Dynamic type creation. I don't know if Java has this or not. One can
> >> of course attempt bytecode synthesis -- I think that's what BCEL
> >> uses -- but that's a bit of a hack.
> >
> > Groovy could possibly be used for that; also IIRC Java 6 adds some
> > features for that. I seem to recall security implications being one
> > reason this ability wasn't included from the start.
>
> Not familiar with Groovy; I'll have to look into that.
> It's amazing what's out there; one of the problems with
> Free Open Source Software (FOSS) is that there's multiple
> choices for the obvious stuff. :-)
>
> >
> >> Dynamic method creation. Java does *not* have this. AIUI
> >> Smalltalk-80 does; one can take an existing class and add methods
> >> thereto.
> >
> > Yes, but that's because a Smalltalk program lives inside a big binary
> > "image" that is mutable. Woe unto you if that big binary file gets
> > corrupted.
>
> Indeed.
>
> I for one would want Smalltalk to have the ability to
> transcript certain messages but would have to look.
> (One might call that an edit audit trail.)

The comments "Woe unto you if that big binary file gets corrupted" are
plain wrong.

For at least 25 years (and perhaps back to Smalltalk-72?) Smalltalk
implementations have comprised an image file, a sources file, and a
change log. The change log records changes to objects, as Smalltalk
statements that can be replayed to reproduce those changes - and as
Smalltalk classes and methods are just objects, that means code changes
are recorded in the change log and can be reproduced even if the image
file is somehow corrupted.

By the late '80s, commercial Smalltalk development had adopted tightly
integrated, fine grained, multi-user version control - everytime a
method was compiled a new edition of the method was recorded in the
version control system, which really helps continuous integration
across the team.

>
> >
> >> Dynamic method deletion. I for one might only want this in the
> >> context of a "sandbox" but if one can create methods, one should be
> >> able to delete them as well if only because of undo.
> >
> > The problem with deleting a method is whether the runtime can handle
> > it: Smalltalk has doesNotUnderstand:#aMessage, Java has
> > NoSuchMetohdError - what does C++ do? A zeroed virtual method would
> > cause a pure virtual method call error, which I guess C++ programmers
> > are trained to take into account.
>
> I'd frankly have to look.  My thinking is that it's a message followed
> by an exit().
>
> > Also, if class A has a method and
> > you delet it in subclass B, it breaks the Liskov Substitution
> > Principle, there B should be able to function where an A is wanted.
>
> Heh...an interesting name; I'm not familiar with that
> issue.  Of course it's important for B to be an A in
> many cases, though AFAICT usually what happens is that
> A declares a method virtual with an implementation and B
> munges it.
>
> >
> >> Dynamic method rename. This could lead to much madness but this
> >> might be useful during sandboxing.
> >
> > A method's name and its "address" are distinct, but for dynamic method
> > dispatch, what about any other code that doesn't know the new name but
> > assumes the method is called the same?
>
> What indeed?  Much madness.
>
> >
> >> Dynamic inheritance. For those languages that support inheritance
> >> one might liken it to changing what the langua

Re: Python vs. Lisp -- please explain

[Isaac Gouy]

Steven D'Aprano wrote:
> On Tue, 21 Feb 2006 09:46:27 -0800, Donn Cave wrote:
>
> > In article <[EMAIL PROTECTED]>,
> >  Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > ...
> >> Hey Donn, here is a compiled program for the PowerPC,
> >> or an ARM processor, or one of IBM's Big Iron
> >> mainframes. Or even a Commodore 64. What do you think
> >> the chances are that you can execute it on your
> >> x86-compatible PC? It's compiled, it should just
> >> work!!! Right?
> >>
> >> No of course not. If your CPU can't interpret the
> >> machine code correctly, the fact that the code is
> >> compiled makes NO difference at all.
>
> [snip for brevity]
>
> > Sure, all this is true, except for the term "interpreter."
> > You would surely not use the word that way, unless you
> > just didn't want to communicate.
>
> Do you honestly believe that the CPU doesn't have to interpret the machine
> code, or are you just deliberately playing silly buggers with language?
>
> In modern CPUs, there is an intermediate layer of micro-code between the
> machine code your C compiler generates and the actual instructions
> executed in hardware. But even if we limit ourselves to obsolete hardware
> without micro-code, I ask you think about what an interpreter does, and
> what the CPU does, in the most general way possible.
>
> Both take a stream of instructions. Both have to take each instruction,
> and execute it. In both cases the link between the instruction and the
> effect is indirect: for example, the machine code 0101 on the
> Zilog Z80 processor causes the CPU to decrement the B processor register.
> In assembly language this would be written as DEC B. There is absolutely
> nothing fundamental about the byte value 5 that inherently means
> "decrement B processor register".
>
> In other words, machine language is a language, just like it says, and
> like all languages, it must be interpreted.
>
> > Your paragraph above that starts with "No of course not",
> > even omits a point that everyone understands, you can in
> > fact expect a .py file will work independent of machine
> > architecture - like any interpreted language.
>
> Amazing. In your previous post you were telling everybody how the
> *disadvantage* of interpreted programs is that they won't run unless the
> interpreter is present, and in this post you are telling us that
> interpreted languages will just work. What happened to the requirement for
> an interpreter?
>
> Let's see you run that Python program on a Zilog Z80 without a Python
> interpreter. Can't be done. No interpreter, whether in hardware or
> software, and the program won't run, whether in source code or byte code
> or machine code.
>
> If I allow that the machines have an interpreter, perhaps you'll return
> the favour and install an interpreter for machine language (often called
> an emulator). Now your compiled C or Lisp code also will run independent
> of machine architecture.
>
> In order to force "interpreted language" and "compiled language" into two
> distinct categories, rather than just two overlapping extremes of a single
> unified category, you have to ignore reality. You ignore interpreted
> languages that are compiled, you ignore the reality of how machine code is
> used in the CPU, you ignore the existence of emulators, and you ignore
> virtual machines.
>
>
> > We all know
> > what native code compilation buys you and what it doesn't.
>
> Did you fail to learn *anything* from my parable of interpreted Lisp on a
> Macintosh II running faster than compiled Lisp running on a Mac II fitted
> with a Lisp processor?
>
>
> --
> Steven

A different perspective:

"Although we refer to Lua as an interpreted language, Lua always
precompiles source code to an intermediate form before running it.
(This is not a big deal: Most interpreted languages do the same.) The
presence of a compilation phase may sound out of place in an
interpreted language like Lua. However, the distinguishing feature of
interpreted languages is not that they are not compiled, but that any
eventual compiler is part of the language runtime and that, therefore,
it is possible (and easy) to execute code generated on the fly. We may
say that the presence of a function like dofile is what allows Lua to
be called an interpreted language."

p57 Programming in Lua

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is python very slow compared to C

[Isaac Gouy]

Steven D'Aprano wrote:
> On Sun, 12 Feb 2006 03:03:20 -0800, bearophileHUGS wrote:
>
> > 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...
>
> 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".

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?


>  The benchmark you pointed to are of limited use for application
>  developers. (Their value to language designers is another story.)

Limited use for what purpose?
(Yes it really is difficult to make all our assumptions explicit in our
writing.)

> 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.

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

>
> 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.

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'.

>
> 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.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My newbie annoyances so far

[Isaac Gouy]

On May 6, 6:09 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > John Nagle <[EMAIL PROTECTED]> wrote:
>
> >>[EMAIL PROTECTED] wrote:
>
> >>>On Apr 27, 9:07 am, John Nagle <[EMAIL PROTECTED]> wrote:
>
> The CPython implementation is unreasonably slow compared
> to good implementations of other dynamic languages such
> as LISP and JavaScript.
>
> >>>Why do you say CPython is slower than JavaScript? Please provide
> >>>examples.
>
> >>See
>
> >>  http://www.mozilla.org/projects/tamarin/faq.html
>
> >>Tamarin is a just-in-time compiler for Javascript.
>
> > ...and is not yet released, as far as I can tell; this makes it kind of
> > diffcult to verify any kinds of claims about its speed.
>
> Tamarind is inside the current implementation of Flash, but it's
> not into Firefox yet, apparently.  The current SpiderMonkey implementation
> is nothing to get excited about in terms of performance.

It was my impression that the "current SpiderMonkey implementation is
nothing to get excited about in terms of performance" which made your
unfavourable comparison to CPython so puzzling (and does the tamarin
website actually show any performance comparisons with CPython?)


> My point is that there are optimizing hard-code compiler implementations
> of many dynamic languages, including LISP, Self, and Smalltalk, but not 
> Python.

I guess Lisp is a safe-ish example but I don't think Self really made
it out of the lab, and it really depends which Smalltalk
implementation you have in mind and what you think about Pysco.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My newbie annoyances so far

[Isaac Gouy]

On May 6, 9:29 pm, John Nagle <[EMAIL PROTECTED]> wrote:
> Isaac Gouy wrote:
> > On May 6, 6:09 pm, John Nagle <[EMAIL PROTECTED]> wrote:
>
> >>Alex Martelli wrote:
>
> >>>John Nagle <[EMAIL PROTECTED]> wrote:
>
> >>>>[EMAIL PROTECTED] wrote:
>
> >>>>>On Apr 27, 9:07 am, John Nagle <[EMAIL PROTECTED]> wrote:
>
> >>>>>>The CPython implementation is unreasonably slow compared
> >>>>>>to good implementations of other dynamic languages such
> >>>>>>as LISP and JavaScript.
> >>My point is that there are optimizing hard-code compiler implementations
> >>of many dynamic languages, including LISP, Self, and Smalltalk, but not 
> >>Python.
>
> > I guess Lisp is a safe-ish example but I don't think Self really made
> > it out of the lab, and it really depends which Smalltalk
> > implementation you have in mind and what you think about Pysco.
>
> See
>
>http://research.sun.com/self/papers/third-generation.html
>
> on a high performance Self implementation.  That laid the groundwork
> for Java's JIT system.

I don't think Java HotSpot equates to Self getting out of the lab.
(And wasn't that more directly related to Strongtalk?)


> Here are some early Tamarin benchmarks.
>
> http://www.playercore.com/pub/Tamarin/Avmplus_vs._javascript.htm
>
> Tamarin doesn't do type inference, though, so they get the best
> performance only with type declarations.
>
> John Nagle

Thank you Neil Hodgson :-)

I wonder where the runtime was hosted? I wonder what current
measurements look like?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py 2.5 on Language Shootout

[Isaac Gouy]

[EMAIL PROTECTED] wrote:
> Alioth is a great site for selecting the language in which to implement
> primitives. Usually it's C.

And for selecting a language for which you might need to implement
primitives in C :-)

>
> Two of the alioth benchmarks, Partial-sums and Spectral-norm, could be
> done using Numarray, or would be done with Numarray if most of the
> program was in Python and there was a need to implement a similar
> numerical procedure. The speed would be up near the compiled language
> benchmarks. However the specific wording of these benchmarks prohibits
> this approach. Spectral-norm must pretend the dataset is infinite, and
> Partial-sums has to be implemented in a simple dumb loop.

And we wouldn't use a naïve recursive algorithm to find fibonnaci
numbers ... unless we were interested in recursion for its own sake.

Maybe the author of spectral-norm was interested in function calls.
Maybe the author of partial-sums was interested in simple dumb loops
and simple dumb Math.


> Looking over the benchmarks, one gains the impression that Python is a
> slow language.

What does that even mean - a slow language?


> My first serious Python programming exercise involved converting a 900
> line Bash Shell program to a 500 line Python program, with a speedup
> factor of 17. Using Python allowed an OO structure and advanced
> containers, meaning the program was more maintainable and portable,
> which were the main aims of the exercise. The speedup was a surprising
> and welcome side benefit. I think it was mosly because the Python
> byte-code interpreter is probably an order of magnitude faster than
> Bash's direct interpretation, and because in Python system calls to
> recurse directories and create symbolic links were not forked to
> separate processes. In fact I would guess that the overall speed of the
> Python program would be little less than a C program, given that most
> of the time would be spent in system calls.

/I would guess/

> Its almost possible to make a large Python program arbitrarily fast by
> profiling it and implementing slow bits as primitives. Size is probably
> of greater concern.

We could read that simply as - /it's not possible/ to make a large
Python program arbitrarily fast. Is that what you meant?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py 2.5 on Language Shootout

[Isaac Gouy]

[EMAIL PROTECTED] wrote:
> Isaac Gouy wrote:
> > [EMAIL PROTECTED] wrote:
> > > Alioth is a great site for selecting the language in which to implement
> > > primitives. Usually it's C.
> >
> > And for selecting a language for which you might need to implement
> > primitives in C :-)
>
> Well if you like C so much, just do it in C. ":-)"

iirc I've never written a program in C or C++ (although I may have
fixed one or two that someone else wrote).


>
> >
> > >
> > > Two of the alioth benchmarks, Partial-sums and Spectral-norm, could be
> > > done using Numarray, or would be done with Numarray if most of the
> > > program was in Python and there was a need to implement a similar
> > > numerical procedure. The speed would be up near the compiled language
> > > benchmarks. However the specific wording of these benchmarks prohibits
> > > this approach. Spectral-norm must pretend the dataset is infinite, and
> > > Partial-sums has to be implemented in a simple dumb loop.
> >
> > And we wouldn't use a naïve recursive algorithm to find fibonnaci
> > numbers ... unless we were interested in recursion for its own sake.
> >
> > Maybe the author of spectral-norm was interested in function calls.
> > Maybe the author of partial-sums was interested in simple dumb loops
> > and simple dumb Math.
>
> I am not disputing this. I think you take my point though.

I'm confident in my ability to misunderstood the point someone intended
to make - I think your point is some variation on 'we wouldn't write
the program like that' '"real-world" programs aren't like that'.


>
> >
> >
> > > Looking over the benchmarks, one gains the impression that Python is a
> > > slow language.
> >
> > What does that even mean - a slow language?
> >
>
> The alioth benchmarks provide a set of numbers by which
> languages may be compared.

Unless we notice that sometimes there's more than one language
implementation for some languages; unless we notice that sometimes
there's more than one program for the same language implementation.
(Unless we read the bold text on the homepage.)


>
> >
> > > My first serious Python programming exercise involved converting a 900
> > > line Bash Shell program to a 500 line Python program, with a speedup
> > > factor of 17. Using Python allowed an OO structure and advanced
> > > containers, meaning the program was more maintainable and portable,
> > > which were the main aims of the exercise. The speedup was a surprising
> > > and welcome side benefit. I think it was mosly because the Python
> > > byte-code interpreter is probably an order of magnitude faster than
> > > Bash's direct interpretation, and because in Python system calls to
> > > recurse directories and create symbolic links were not forked to
> > > separate processes. In fact I would guess that the overall speed of the
> > > Python program would be little less than a C program, given that most
> > > of the time would be spent in system calls.
> >
> > /I would guess/
>
> I don't have the time, or interest, to recode it in C to find out.
> In reality the choice would be C++ because of OO and STL.
> Perhaps traversing and linking a tree containing about 1000 files would
> not
> take a full second. I might be wrong. All i know is, its a lot faster
> than Bash.
>
> >
> > > Its almost possible to make a large Python program arbitrarily fast by
> > > profiling it and implementing slow bits as primitives. Size is probably
> > > of greater concern.
> >
> > We could read that simply as - /it's not possible/ to make a large
> > Python program arbitrarily fast. Is that what you meant?
>
> No. I meant that if my Python program is too big in terms of its
> execution memory
> requirements, then that would be a difficult issue to deal with. Rather
> than
> optimizing execution hotspots, I might have to use another language.
> 
> Cheers,
>  P.S. Alioth is a great site.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py 2.5 on Language Shootout

[Isaac Gouy]

Ramon Diaz-Uriarte wrote:
> On 1/20/07, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >  >>> Looking over the benchmarks, one gains the impression that Python is a
> >  >>> slow language.
> >  >> What does that even mean - a slow language?
> >  >>
> >  >
> >  > The alioth benchmarks provide a set of numbers by which
> >  > languages may be compared.
> >
> > Wrong. The benchmarks provide a set of numbers by which
> > _implementations_ of languages can be compared. After all, it is
> > possible that someone implements a magic-pixie-dust-interpreter that
> > executes Python programs several orders of magnitude fastes than
> > CPython. Or you could say that C is slow because if you use CINT, a C
> > interpreter ( http://root.cern.ch/root/Cint.html ) to execute it, it is
> > slow.
>
>
> Yeah, but this is hair-splitting. Except for Jython, IronPython, and
> Stackless, I think when we say "Python is slow/fast" we think CPython
> (otherwise, we qualify the implementation). For that matter it is
> often said "the GIL ..."; oh, but wait, Stackless ...

When we say "Python is slow/fast" what does "slow/fast" mean?


>
> With other languages (e.g., Common Lisp) the separation between the
> language and the implementation is key because, to begin with, there
> is something external from, and independent of, any particular
> implementation. That is not the case with Python.
>
> And the example of CINT is hair-splitting to the nth power.To begin
> with, I do not think CINT implements the full standard C. But even if
> it were, when people think of C they rarely think of CINT.

And that's why the existence of CINT is such a stark reminder of the
separation between the language and the implementation. When people
think of C what do they think of - gcc? tiny-c? intel c? microsoft c?
some mythical C implementation?


>
> I think readers understood the previous poster.
>
> Best,
>
> R.
> >
> > Cheers,
> >
> > Carl Friedrich Bolz
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
>
> --
> Ramon Diaz-Uriarte
> Statistical Computing Team
> Structural Biology and Biocomputing Programme
> Spanish National Cancer Centre (CNIO)
> http://ligarto.org/rdiaz

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Py 2.5 on Language Shootout

[Isaac Gouy]

Ramon Diaz-Uriarte wrote:
> On 20 Jan 2007 11:34:46 -0800, Isaac Gouy <[EMAIL PROTECTED]> wrote:
> >
> > Ramon Diaz-Uriarte wrote:
> > > On 1/20/07, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote:
> > > > [EMAIL PROTECTED] wrote:
> > > >  >>> Looking over the benchmarks, one gains the impression that Python 
> > > > is a
> > > >  >>> slow language.
> > > >  >> What does that even mean - a slow language?
> > > >  >>
> > > >  >
> > > >  > The alioth benchmarks provide a set of numbers by which
> > > >  > languages may be compared.
> > > >
> > > > Wrong. The benchmarks provide a set of numbers by which
> > > > _implementations_ of languages can be compared. After all, it is
> > > > possible that someone implements a magic-pixie-dust-interpreter that
> > > > executes Python programs several orders of magnitude fastes than
> > > > CPython. Or you could say that C is slow because if you use CINT, a C
> > > > interpreter ( http://root.cern.ch/root/Cint.html ) to execute it, it is
> > > > slow.
> > >
> > >
> > > Yeah, but this is hair-splitting. Except for Jython, IronPython, and
> > > Stackless, I think when we say "Python is slow/fast" we think CPython
> > > (otherwise, we qualify the implementation). For that matter it is
> > > often said "the GIL ..."; oh, but wait, Stackless ...
> >
> > When we say "Python is slow/fast" what does "slow/fast" mean?
> >
>
> Oh, well, I have no idea. I guess you'd have to define what "speed"
> and, if that is a single number, then we can just rank languages. We'd
> probably never agree on how to obtain a single number. But I think
> most of us, when looking at the shootout, can see that there are some
> languages that, for most of the programs, are consistently faster than
> the rest, and others that are consistently slower. But really, I think
> the shootout page has large, detailed and  statements about the
> perils and pitfalls of measuring these things. (And I do not go to the
> shootout to hear the oracle tell me which language I should use in my
> next project).

That's wise ;-)

Yes the shootout page has statements about the perils and pitfalls of
measuring these things - it's encouraging that at least one person has
noticed :-)


>
>
>
> >
> > >
> > > With other languages (e.g., Common Lisp) the separation between the
> > > language and the implementation is key because, to begin with, there
> > > is something external from, and independent of, any particular
> > > implementation. That is not the case with Python.
> > >
> > > And the example of CINT is hair-splitting to the nth power.To begin
> > > with, I do not think CINT implements the full standard C. But even if
> > > it were, when people think of C they rarely think of CINT.
> >
> > And that's why the existence of CINT is such a stark reminder of the
> > separation between the language and the implementation. When people
> > think of C what do they think of - gcc? tiny-c? intel c? microsoft c?
> > some mythical C implementation?
> >
> >
>
> Really, this ain't my war. Sure, there are two things: the language
> and the implementation. But, for practical purposes, when most people
> today say Python they mean CPython, whereas if the say Scheme, they
> certainly need to say _which_ Scheme (I think only PLT is in the
> official shootout page; there are others in the beta tests). If people
> want to mean Jython or Stackless, they just say that. As for C, I
> think people will need to qualify what exactly they mean.
>
> I think all these issues do not really lead to confusion for most of
> us; certainly not if you go to the shootout page. But as I said, this
> ain't my war. I was simply pointing out that correcting one poster for
> talking about languages when referring to python was hair splitting.
>
> And I think we are all running in circles, because I guess we all
> agree. This is turning into what in Spain (a country of catholic
> tradition) we call a discussion about "the sex of the angels" (el sexo
> de los angeles), i.e., whether angels are male or female or something
> else. Since sexing angels is not my area of expertise, I'll just shut
> up (I actually don't really know why I even said anything about this
> issue; please, forgive my chatiness).


In England the corresponding expression is "Counting Angels on a
Pinhead"

Re: IronPython vs CPython: faster in 1.6 times?

[Isaac Gouy]

On Feb 5, 11:47 am, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] schrieb:
>
> > Mike C. Fletcher:
> >> Not sure if Mono also provides a speedup.
>
> > There is a set of good benchmarks here, the answer is negative:
> >http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang...
>
> This doesn't look like Mono to me:
>
> IronPython 1.1 (1.1) on .NET 2.0.50727.42
>
> Stefan

Have you actually looked at the version string from IronPython-1.1-
Bin.zip running on Mono?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IronPython vs CPython: faster in 1.6 times?

[Isaac Gouy]

On Feb 6, 12:04 am, [EMAIL PROTECTED] wrote:
> Stefan Behnel:
>
> > This doesn't look like Mono to me:
> >IronPython 1.1 (1.1) on .NET 2.0.50727.42
>
> You are right!

No.

> I think this shows that IronPython isn't faster than
> CPython at all :-) (And it uses more memory).


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: IronPython vs CPython: faster in 1.6 times?

[Isaac Gouy]

On Feb 6, 1:54 pm, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Isaac Gouy wrote:
> > On Feb 5, 11:47 am, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] schrieb:
>
> >>> Mike C. Fletcher:
> >>>> Not sure if Mono also provides a speedup.
> >>> There is a set of good benchmarks here, the answer is negative:
> >>>http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all〈...
> >> This doesn't look like Mono to me:
>
> >> IronPython 1.1 (1.1) on .NET 2.0.50727.42
>
> >> Stefan
>
> > Have you actually looked at the version string from IronPython-1.1-
> > Bin.zip running on Mono?
>
> Why? Would that look like Mono? :)
>
> Stefan

Why? Because then you'd be doing more than expressing your personal
ignorance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Isaac Gouy]

On Dec 12, 6:58 am, bearophileh...@lycos.com wrote:
> sturlamolden:
>
> > On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3 And
> > most of that magic comes from an implementation of a dynamically typed
> > language (Smalltalk). [...]
> >http://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=all
>
> That is indeed a nice result, JavaVM has come a long way from the
> first one used for applets. That result comes mostly from the fact
> that this is a test on a 4-core CPU, that is less easy to manage from
> C. You can see that in the single 64-bit core 
> tests:http://shootout.alioth.debian.org/u64/benchmark.php?test=all〈=all


Whether or not it's less easy to manage from C is unclear, but you are
correct to point out few of those C programs have been updated to
exploit quadcore - so the reasonable comparison is with C++.


And the benchmarks game also provides x86 measurements with programs
forced onto a single core which shows GCC ahead

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all



> And take a look at the memory used too, up to 34 times higher for the
> JVM on the 4-core CPU.
>
> In the next years people that use low-level languages like C may need
> to invent a new language fitter for multi-core CPUs, able to be used
> on GPUs too (see the OpenCL), less error-prone than C, able to use the
> CPU vector instructions efficiently. (The D language is probably unfit
> for this purpose, because even if it's meant to be a system language,
> I don't think it can be used much to replace C everywhere it's used
> now.) A C+ maybe? :-)
>
> I agree that CPython may quite enjoy having something built-in like
> Psyco, but it's a lot of work for an open source project. Probably
> with 1/3 or 1/2 of the work poured on PyPy you may create that
> improvement for CPython. Maybe PyPy will someday produce some fruit,
> but I think they have used the wrong strategy: instead of trying to
> create something very new that someday will work, it's often better to
> try to improve something that today everybody uses, AND try to be
> useful from almost the very beginning.
>
> Bye,
> bearophile

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Isaac Gouy]

On Dec 12, 11:41 am, Bruno Desthuilliers
 wrote:
> sturlamolden a écrit :
> (snip)
>
> > Creating a fast implementation of a dynamic language is almost rocket
> > science. But it has been done. There is Stronghold, the fastest
> > version of Smalltalk known to man, on which the Sun Java VM is based.
> > On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3
>
> cf bearophile's comment on this point (CPU architecture and RAM)
>
> > And
> > most of that magic comes from an implementation of a dynamically typed
> > language (Smalltalk).
>
> Err... Where is _Java_ "dynamic" actually ? A benchmark of _Smalltalk_
> VM vs CPython VM would make more sense.


http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=python


>
> > Second, there are other fast implementations of dynamic languages. The
> > CMUCL and SBCL versions of Common Lisp comes to min; you can see how
> > SBCL does in the same benchmark (CMUCL tends to be even faster).
>
> Could it be that there are some type hints in the lisp versions of the
> source code ?
>
> > So Python is a lot slower than it needs to be.
>
> Please fix it, you're welcome.

--
http://mail.python.org/mailman/listinfo/python-list

Re: 2to3 used in the Shootout

[Isaac Gouy]

On Dec 23, 11:51 am, bearophileh...@lycos.com wrote:
> They have translated the Python benchmarks of the Shootout site from
> Py2 to Py3 using 2to3:
>
> http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=pyt...


So please re-write those programs to remove problems created by
automatic translation and better take advantage of Python 3
functionality...


http://shootout.alioth.debian.org/u32/faq.php#play



> It shows some "performance bugs" of Python3 itself (especially
> regarding the binary-trees benchmark, that was unexpected by me), and
> two points where 2to3 may be improved, for example after the
> translation this gives error:
>          table=string.maketrans('ACBDGHK\nMNSRUTWVYacbdghkmnsrutwvy',
>                                 'TGVHCDM
> \nKNSYAAWBRTGVHCDMKNSYAAWBR')):
>
> Gives:
> TypeError: maketrans arguments must be bytes objects
>
> Bye,
> bearophile

--
http://mail.python.org/mailman/listinfo/python-list

Re: 2to3 used in the Shootout

[Isaac Gouy]

On Dec 29 2008, 8:36 am, prueba...@latinmail.com wrote:
> On Dec 23, 5:21 pm, Isaac Gouy  wrote:
>
> > On Dec 23, 11:51 am, bearophileh...@lycos.com wrote:
>
> > > They have translated the Python benchmarks of theShootoutsite from
> > > Py2 to Py3 using 2to3:
>
> > >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=pyt...
>
> > So please re-write those programs to remove problems created by
> > automatic translation and better take advantage of Python 3
> > functionality...
>
> >http://shootout.alioth.debian.org/u32/faq.php#play
>
> > > It shows some "performance bugs" of Python3 itself (especially
> > > regarding the binary-trees benchmark, that was unexpected by me), and
> > > two points where 2to3 may be improved, for example after the
> > > translation this gives error:
> > >          table=string.maketrans('ACBDGHK\nMNSRUTWVYacbdghkmnsrutwvy',
> > >                                 'TGVHCDM
> > > \nKNSYAAWBRTGVHCDMKNSYAAWBR')):
>
> > > Gives:
> > > TypeError: maketrans arguments must be bytes objects
>
> > > Bye,
> > > bearophile
>
> BTW I am not sure how to submit this or if this is actually valid to
> do, but I have a faster version for the pidigits program that uses
> basically the same algorithm but removes function calls and unused
> terms of the formula.
>
> 
> import time
>
> def pi_digits(n, width):
>     out = []
>     wrt = out.append
>     aq = 1
>     ar = 0
>     at = 1
>     k = 0
>     f = 1
>     g = 2
>     i = 0
>     while i < n:
>         y = (aq*3+ar)//at
>         while y != ((aq*4+ar)//at):
>             k += 1
>             f += 2
>             g += 4
>             ar = aq*g+ar*f
>             aq = aq*k
>             at = at*f
>             y = (aq*3+ar)//at
>         aq = 10*aq
>         ar = 10*ar-10*y*at
>         i += 1
>         wrt(str(y))
>         if not i%width:
>             wrt('\t:%d\n'%i)
>     wrt(' '*(width-i%width))
>     wrt('\t:%d\n'%i)
>     return ''.join(out)
>
> def main():
>     begin = time.time()
>     n = 1000
>     width = 70
>     print pi_digits(n,width)
>     print 'Total Time:', time.time()-begin
>
> main()
>
> 


http://shootout.alioth.debian.org/u32q/faq.php#play
--
http://mail.python.org/mailman/listinfo/python-list

Re: Performance of Python 3

[Isaac Gouy]

On Mar 1, 8:10 am, Stefan Behnel  wrote:
> Paul Rubin wrote:
> > Steve Holden  writes:
> >> I'm not sure what you think the speed of Ruby has to do with Python.
>
> > In the real world, people care about the relative speed of programs.
>
> Fine, but theShootoutonAliothisn't a particularly pythonic one. It
> deals almost exclusively with computationally intensive tasks, i.e.
> programs where any decent Python developer would either import Psyco or
> speed up the code in Cython.

It deals exclusively with small programs in isolation as if they were
the bottleneck.


> As long as that gives you improvements of
> 100-1000 times almost for free, I wouldn't bother too much with changing
> the platform just because someone shows me benchmark results of some code
> that I absolutely don't need in my daily work.


What examples do you have of 1000x improvement?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Performance of Python 3

[Isaac Gouy]

On Mar 1, 11:15 am, Thorsten Kampe  wrote:
> * Isaac Gouy (Sun, 1 Mar 2009 08:27:05 -0800 (PST))
>
> > On Mar 1, 8:10 am, Stefan Behnel  wrote:
> > > Paul Rubin wrote:
> > > > Steve Holden  writes:
> > > >> I'm not sure what you think the speed of Ruby has to do with Python.
>
> > > > In the real world, people care about the relative speed of programs.
>
> > > Fine, but theShootoutonAliothisn't a particularly pythonic one. It
> > > deals almost exclusively with computationally intensive tasks, i.e.
> > > programs where any decent Python developer would either import Psyco or
> > > speed up the code in Cython.
>
> > It deals exclusively with small programs in isolation as if they were
> > the bottleneck.
>
> Right. But they aren't.

They aren't except when they are!


> So people who draw any conclusions from that
> like "C++ is faster than C" or "Ruby is slower than Python" or "Python
> is 30 times slower than C" draw the wrong conclusions.
>
> Thorsten

--
http://mail.python.org/mailman/listinfo/python-list

Re: Performance of Python 3

[Isaac Gouy]

On Mar 1, 11:24 am, Stefan Behnel  wrote:
> Isaac Gouy wrote:
> > On Mar 1, 8:10 am, Stefan Behnel wrote:
> >> As long as that gives you improvements of
> >> 100-1000 times almost for free, I wouldn't bother too much with changing
> >> the platform just because someone shows me benchmark results of some code
> >> that I absolutely don't need in my daily work.
>
> > What examples do you have of 1000x improvement?
>
> We hear that from time to time on the Cython mailing list. Here's a recent
> example of a user who reported an 80 times speed-up before we helped in
> getting the code straight, which brought another factor of 20.
>
> http://permalink.gmane.org/gmane.comp.python.cython.devel/4619
>
> Speed-ups in the order of several hundred times are not uncommon for
> computing intensive tasks and large data sets when you move from Python to
> Cython, as it generates very optimised C code.
>
> Stefan


"Now only the def line and the return line are using Python..." ;-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Performance of Python 3

[Isaac Gouy]

On Mar 2, 12:02 am, Stefan Behnel  wrote:
> Isaac Gouy wrote:
> > On Mar 1, 11:24 am, Stefan Behnel wrote:
> >> Isaac Gouy wrote:
> >>> On Mar 1, 8:10 am, Stefan Behnel wrote:
> >>>> As long as that gives you improvements of
> >>>> 100-1000 times almost for free, I wouldn't bother too much with changing
> >>>> the platform just because someone shows me benchmark results of some code
> >>>> that I absolutely don't need in my daily work.
> >>> What examples do you have of 1000x improvement?
> >> We hear that from time to time on the Cython mailing list. Here's a recent
> >> example of a user who reported an 80 times speed-up before we helped in
> >> getting the code straight, which brought another factor of 20.
>
> >>http://permalink.gmane.org/gmane.comp.python.cython.devel/4619
>
> >> Speed-ups in the order of several hundred times are not uncommon for
> >> computing intensive tasks and large data sets when you move from Python to
> >> Cython, as it generates very optimised C code.
>
> >> Stefan
>
> > "Now only the def line and the return line are using Python..." ;-)
>
> So? I did see your smiley, but I hope you are not trying to make a point
> here. If you look at the code (especially in this case, it might be more
> C-ish in others), you will see that it's Python. It just gets translated to
> very fast C code. Cython even has a "pure Python" mode where you can let
> your code run in ordinary Python and have Cython compile it if you feel
> like it. That gives you the best of both worlds: readable, easy to maintain
> code, that you can compile to C speed when you need high performance.
>
> Coming back to the original topic of this thread, when I look at the code
> examples that are compared here, I wouldn't be surprised if Cython could
> compile them to a faster executable straight away, without modification.
> Just install Cython 0.11 (which is close to release) and add
>
>     import pyximport; pyximport.install(pyimport=True)
>
> before importing the benchmarked module. If you want more performance than
> what plain compilation gives you by itself, just add a few type
> declarations. You can use Python decorators for that, if you prefer keeping
> a standard Python program.


I think it would be silly to dispute whether or not programs that have
import psyco; psyco.bind are Python programs.

I'm not sure it would be equally silly to dispute whether or not
programs with type declarations have moved away from being Python
programs.

Of course, Cython is still kind-of neat.

--
http://mail.python.org/mailman/listinfo/python-list

set_process_affinity_mask problem - Python 2.5 gcc 4.3.2 (Ubuntu 4.3.2-1ubuntu12)

[Isaac Gouy]

For a couple of months, I've been successfully using the Python 
set_process_affinity_mask wrapper from 

http://pypi.python.org/pypi/affinity/0.1.0


Now I've upgraded from Ubuntu 8.04 to Ubuntu 8.10 (from gcc 4.2.3 to gcc 4.3.2) 
and set_process_affinity_mask seems to fail on the x86 Ubuntu install.
It still works fine, after upgrade, on the x64 Ubuntu install.


I've tried re-installing Python, and the affinity package, and gcc, and glibc, 
and ... without getting it to work.


Specifically, I have a function

 def setAffinity():
if affinitymask:
   set_process_affinity_mask(os.getpid(),affinitymask)

which is passed to a spawned process

p = Popen(commandline,...,preexec_fn=setAffinity)


Reducing setAffinity() to os.getpid() lets the program run without failure, 
trying to get_process_affinity_mask or set_process_affinity_mask gives

ERROR 22 Invalid argument


Please suggest what I can do to debug / fix this problem.



  
--
http://mail.python.org/mailman/listinfo/python-list

libgtop gtop.proc_time(pid) examples?

[Isaac Gouy]

Please show an example of using the Python libgtop wrapper to get
process time information, or say where such examples can be found.
--
http://mail.python.org/mailman/listinfo/python-list

Re: python memory use

[Isaac Gouy]

On Sep 30, 7:38 am, Gary Robinson  wrote:
> The chart 
> athttp://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=ja...is very 
> interesting to me because it shows CPython using much less memory than Java 
> for most tests.
>
> I'd be interested in knowing whether anybody can share info about how 
> representative those test results are. For instance, suppose we're talking 
> about a huge dictionary that maps integers to lists of integers (something I 
> use in my code). Would something like that really take up much more memory in 
> Java (using the closest equivalent Java data structures) than in CPython? I 
> find it hard to believe that that would be the case, but I'm quite curious.
>
> (I could test the particular case I mention, but I'm wondering if someone has 
> some fundamental knowledge that would lead to a basic understanding.)
>

1) That URL is approximate averages rather than the straight Java
measurements.

2) Unless the programs are using *a lot* of memory you're just seeing
default JVM memory use.

3) More of the Java programs may have been re-written to use quad
core, which may use extra buffering.


So look for tasks that use a lot of memory and watch for time/space
tradeoffs -

2.1  Java 6 -server #229.32259,868
62   Python #614 min   674,316
167  Python #238 min   221,236

http://shootout.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=all


2.8  Java 6 -server #246.87363,488
34   Python   9 min439,196

http://shootout.alioth.debian.org/u32/benchmark.php?test=knucleotide&lang=all


2.5  Java 6 -server #42.87 473,324
6.5  Python #37.67 543,908

http://shootout.alioth.debian.org/u32/benchmark.php?test=revcomp&lang=all
-- 
http://mail.python.org/mailman/listinfo/python-list

python b.python 8 works on XP but not on Vista?

[Isaac Gouy]

At the command prompt:

   python b.py 8
works fine on both XP and Vista

   python b.python 8
works on XP (and Linux)

but on Vista

   python b.python 8

ImportError: No module named b

?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python b.python 8 works on XP but not on Vista?

[Isaac Gouy]

On Mar 6, 4:02 pm, Chris Rebert  wrote:
> On Sat, Mar 6, 2010 at 3:53 PM, Isaac Gouy  wrote:
> > At the command prompt:
>
> >   python b.py 8
> > works fine on both XP and Vista
>
> >   python b.python 8
> > works on XP (and Linux)
>
> > but on Vista
>
> >   python b.python 8
>
> > ImportError: No module named b
>
> > ?
>
> Code please.


It's the same code in both cases, I simply renamed "b.python" as
"b.py" as a test.


> Also, .python is not a standard extension for Python
> files, so why are you using it anyway?

Because it's useful for what I'm doing.

Given python 2.6.4 has no problem with a non-standard extension on MS
XP and Linux - why does python 2.6.4 have this problem with a non-
standard extension on MS Vista?


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python b.python 8 works on XP but not on Vista?

[Isaac Gouy]

On Mar 6, 4:53 pm, Chris Rebert  wrote:
> On Sat, Mar 6, 2010 at 4:42 PM, Isaac Gouy  wrote:
> > On Mar 6, 4:02 pm, Chris Rebert  wrote:
> >> On Sat, Mar 6, 2010 at 3:53 PM, Isaac Gouy  wrote:
> >> > At the command prompt:
>
> >> >   python b.py 8
> >> > works fine on both XP and Vista
>
> >> >   python b.python 8
> >> > works on XP (and Linux)
>
> >> > but on Vista
>
> >> >   python b.python 8
>
> >> > ImportError: No module named b
>
> >> > ?
>
> >> Code please.
>
> > It's the same code in both cases, I simply renamed "b.python" as
> > "b.py" as a test.
>
> The code in b.py matters. I /suspect/ it's importing itself somehow
> (probably indirectly), and Python doesn't look for ".python" files
> when importing, so it fails with an ImportError. But since you haven't
> shown the code, I can only guess.

Yes the code in b.py matters.

Why it matters is that there was another difference between XP and
Vista - the XP machine was single core but the Vista machine was multi
core - and the code behaves differently in each case.

Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python b.python 8 works on XP but not on Vista?

[Isaac Gouy]

On Mar 6, 6:50 pm, Steven D'Aprano  wrote:
> On Sat, 06 Mar 2010 21:10:02 -0500, sstein...@gmail.com wrote:
> > On Mar 6, 2010, at 8:23 PM, Isaac Gouy wrote:
>
> >> On Mar 6, 4:53 pm, Chris Rebert  wrote:
> >>> On Sat, Mar 6, 2010 at 4:42 PM, Isaac Gouy  wrote:
> >>>> On Mar 6, 4:02 pm, Chris Rebert  wrote:
> >>>>> On Sat, Mar 6, 2010 at 3:53 PM, Isaac Gouy  wrote:
> >>>>>> At the command prompt:
>
> >>>>>>   python b.py 8
> >>>>>> works fine on both XP and Vista
>
> >>>>>>   python b.python 8
> >>>>>> works on XP (and Linux)
>
> >>>>>> but on Vista
>
> >>>>>>   python b.python 8
>
> >>>>>> ImportError: No module named b
>
> >>>>>> ?
>
> >>>>> Code please.
>
> >>>> It's the same code in both cases, I simply renamed "b.python" as
> >>>> "b.py" as a test.
>
> >>> The code in b.py matters. I /suspect/ it's importing itself somehow
> >>> (probably indirectly), and Python doesn't look for ".python" files
> >>> when importing, so it fails with an ImportError. But since you haven't
> >>> shown the code, I can only guess.
>
> >> Yes the code in b.py matters.
>
> >> Why it matters is that there was another difference between XP and
> >> Vista - the XP machine was single core but the Vista machine was multi
> >> core - and the code behaves differently in each case.
>
> > Yes, and the XP machine's case was blue, therefore case color is
> > important, too.
>
> Don't forget that the XP machine was on the left hand side of the desk,
> and the Vista machine on the right. I suspect Isaac needs to physically
> move the Vista machine to the left side, and it will work perfectly.
>
> Either that, or stop pissing around and show us the actual stack trace so
> we can actually help. Isaac, stop *guessing* what the problem is.
>
> If you have to guess, try to make your guesses realistic. It's not likely
> anything to do with the CPU. If anything, Python's search path is
> different on your Vista and XP machines.
>
> --
> Steven


That was "Thanks." as in problem solved.

When the code switches on multiprocessing.cpu_count() - single core vs
multicore matters.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: If Scheme is so good why MIT drops it?

[Isaac Gouy]

On Jul 21, 10:09 pm, Raffael Cavallaro
 wrote:
> On 2009-07-21 19:06:02 -0400, Neil Hodgson
>  said:
>
> >    Python uses native threads.
>
> So it can be teh-slowness on all ur cores!
>
> 
>
> The global interpreter lock doesn't help much either.


As you've linked to programs that /have not/ been written to use
threading or multiple cores (look at the "~ CPU Load" column) I get
the feeling I'm missing the joke?



-- 
http://mail.python.org/mailman/listinfo/python-list