Re: benchmark

Peter Otten wrote: Kris Kennaway wrote: Peter Otten wrote: [EMAIL PROTECTED] wrote: On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: jlist wrote: I think what makes more sense is to compare the code one most typically writes. In my case, I always use range() and never use psyc

Re: benchmark

Peter Otten: > In general I think that if you want to promote a particular coding style you > should pick an example where you can demonstrate actual benefits. That good thing is that Python 3 has only xrange (named range), so this discussion will be mostly over ;-) Bye, bearophile -- http://mail

Re: benchmark

Kris Kennaway wrote: > Peter Otten wrote: >> [EMAIL PROTECTED] wrote: >> >>> On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: jlist wrote: > I think what makes more sense is to compare the code one most > typically writes. In my case, I always use range() and never use >

Re: benchmark

Peter Otten wrote: [EMAIL PROTECTED] wrote: On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: jlist wrote: I think what makes more sense is to compare the code one most typically writes. In my case, I always use range() and never use psyco. But I guess for most of my work with Pyt

Re: benchmark

On Aug 11, 2:09 pm, [EMAIL PROTECTED] wrote: > On Aug 11, 10:55 am, [EMAIL PROTECTED] wrote: > > > > > On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > > jlist wrote: > > > > I think what makes more sense is to compare the code one most > > > > typically writes. In my case, I alw

Re: benchmark

[EMAIL PROTECTED] wrote: > On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: >> jlist wrote: >> > I think what makes more sense is to compare the code one most >> > typically writes. In my case, I always use range() and never use psyco. >> > But I guess for most of my work with Python

Re: benchmark

On Aug 11, 10:55 am, [EMAIL PROTECTED] wrote: > On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > jlist wrote: > > > I think what makes more sense is to compare the code one most > > > typically writes. In my case, I always use range() and never use psyco. > > > But I guess for mo

Re: benchmark

On Aug 10, 10:10 pm, Kris Kennaway <[EMAIL PROTECTED]> wrote: > jlist wrote: > > I think what makes more sense is to compare the code one most > > typically writes. In my case, I always use range() and never use psyco. > > But I guess for most of my work with Python performance hasn't been > > a is

Re: benchmark

jlist wrote: I think what makes more sense is to compare the code one most typically writes. In my case, I always use range() and never use psyco. But I guess for most of my work with Python performance hasn't been a issue. I haven't got to write any large systems with Python yet, where performan

Re: benchmark

Angel Gutierrez wrote: Steven D'Aprano wrote: On Thu, 07 Aug 2008 00:44:14 -0700, alex23 wrote: Steven D'Aprano wrote: In other words, about 20% of the time he measures is the time taken to print junk to the screen. Which makes his claim that "all the console outputs have been removed so th

Re: benchmark

Dhananjay wrote: On Aug 7, 11:58 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > Are there any implications of using psyco ? It compiles statements to machine code for each set of types used in the statement or code block over the history of the run. So code used polym

Re: benchmark

On Aug 8, 9:08 am, alex23 <[EMAIL PROTECTED]> wrote: > On Aug 8, 2:49 pm, Dhananjay <[EMAIL PROTECTED]> wrote: > > > Is it that a question of time and effort, > > or is there something that doesn't make it appropriate to python ? > > I don't think I've ever seen anyone who has raised concerns about

Re: benchmark

On Aug 8, 2:49 pm, Dhananjay <[EMAIL PROTECTED]> wrote: > Is it that a question of time and effort, > or is there something that doesn't make it appropriate to python ? I don't think I've ever seen anyone who has raised concerns about the speed of python actually offer to contribute to resolving i

Re: benchmark

On Aug 7, 2:05 am, "Jack" <[EMAIL PROTECTED]> wrote: > I know one benchmark doesn't mean much but it's still disappointing to see > Python as one of the slowest languages in the test: > > http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-p... And how does this reflect the perfor

Re: benchmark

On Aug 7, 11:58 pm, Terry Reedy <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: >  > Are there any implications of using psyco ? > > It compiles statements to machine code for each set of types used in the > statement or code block over the history of the run.  So code used > polymorphically

Re: benchmark

alex23: > Honestly, performance benchmarks seem to be the dick size comparison > of programming languages. I don't agree: - benchmarks can show you what language use for your purpose (because there are many languages, and a scientist has to choose the right tool for the job); - it can show where a

Re: benchmark

[EMAIL PROTECTED] wrote: Is there any reason why the psyco is not a part of the core python feature set ? Psyco was a PhD project. I do not believe the author ever offered it. Last I knew, it was almost but not completely compatible. Is there a particular reason it is better to be kept

Re: benchmark

On Aug 7, 6:12 pm, alex23 <[EMAIL PROTECTED]> wrote: > On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: > > > Really how silly can it be when you suggest someone is taking a > > position and tweaking the benchmarks to prove a point [...] > > I certainly didn't intend to suggest that you had tweaked -any

Re: benchmark

On Thu, Aug 7, 2008 at 9:09 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Thu, 07 Aug 2008 06:12:04 -0700, alex23 wrote: > >> On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: >>> Really how silly can it be when you suggest someone is taking a >>> position and tweaking the benchmarks to prove a poi

Re: benchmark

On Thu, 07 Aug 2008 06:12:04 -0700, alex23 wrote: > On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: >> Really how silly can it be when you suggest someone is taking a >> position and tweaking the benchmarks to prove a point [...] > > I certainly didn't intend to suggest that you had tweaked -anything

Re: benchmark

On Thu, Aug 7, 2008 at 8:12 AM, alex23 <[EMAIL PROTECTED]> wrote: > On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: >> Really how silly can it be when you suggest someone is taking a >> position and tweaking the benchmarks to prove a point [...] > > I certainly didn't intend to suggest that you had twe

Re: benchmark

> > Honestly, performance benchmarks seem to be the dick size comparison > of programming languages. > But in the honour of dick size: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all -- http://mail.pyth

Re: benchmark

On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: > Really how silly can it be when you suggest someone is taking a > position and tweaking the benchmarks to prove a point [...] I certainly didn't intend to suggest that you had tweaked -anything- to prove your point. I do, however, think there is littl

Re: benchmark

On Aug 7, 2:52 pm, [EMAIL PROTECTED] wrote: > On Aug 7, 6:38 am, [EMAIL PROTECTED] wrote: > > > On Aug 7, 2:05 am, "Jack" <[EMAIL PROTECTED]> wrote: > > > > I know one benchmark doesn't mean much but it's still disappointing to see > > > Python as one of the slowest languages in the test: > > > >ht

Re: benchmark

On Aug 7, 5:05 am, "Jack" <[EMAIL PROTECTED]> wrote: > I know one benchmark doesn't mean much but it's still disappointing to see > Python as one of the slowest languages in the test: > > http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-p... I was actually disappointed myself wi

Re: benchmark

Stefan Behnel a écrit : Jack wrote: I know one benchmark doesn't mean much but it's still disappointing to see Python as one of the slowest languages in the test: http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/ Just ignore that. If the co

Re: benchmark

jlist: > I think what makes more sense is to compare the code one most > typically writes. In my case, I always use range() and never use psyco. If you don't use Python 3 and your cycles can be long, then I suggest you to start using xrange a lot :-) (If you use Psyco you don't need xrange). M8R

Re: benchmark

On Aug 7, 12:44 pm, alex23 <[EMAIL PROTECTED]> wrote: > Steven D'Aprano wrote: > > In other words, about 20% of the time he measures is the time taken to > > print junk to the screen. > > Which makes his claim that "all the console outputs have been removed > so that the benchmarking activity is no

Re: benchmark

Steven D'Aprano a écrit : On Thu, 07 Aug 2008 07:49:45 +0200, Stefan Behnel wrote: Jack wrote: I know one benchmark doesn't mean much but it's still disappointing to see Python as one of the slowest languages in the test: http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java- p

Re: benchmark

On Aug 7, 6:38 am, [EMAIL PROTECTED] wrote: > On Aug 7, 2:05 am, "Jack" <[EMAIL PROTECTED]> wrote: > > > I know one benchmark doesn't mean much but it's still disappointing to see > > Python as one of the slowest languages in the test: > > >http://blog.dhananjaynene.com/2008/07/performance-comparis

Re: benchmark

Steven D'Aprano wrote: > On Thu, 07 Aug 2008 00:44:14 -0700, alex23 wrote: > >> Steven D'Aprano wrote: >>> In other words, about 20% of the time he measures is the time taken to >>> print junk to the screen. >> >> Which makes his claim that "all the console outputs have been removed so >> that t

Re: benchmark

On Thu, 07 Aug 2008 00:44:14 -0700, alex23 wrote: > Steven D'Aprano wrote: >> In other words, about 20% of the time he measures is the time taken to >> print junk to the screen. > > Which makes his claim that "all the console outputs have been removed so > that the benchmarking activity is not in

Re: benchmark

Steven D'Aprano wrote: > In other words, about 20% of the time he measures is the time taken to > print junk to the screen. Which makes his claim that "all the console outputs have been removed so that the benchmarking activity is not interfered with by the IO overheads" somewhat confusing...he di

Re: benchmark

I think what makes more sense is to compare the code one most typically writes. In my case, I always use range() and never use psyco. But I guess for most of my work with Python performance hasn't been a issue. I haven't got to write any large systems with Python yet, where performance starts to ma

Re: benchmark

On Thu, 07 Aug 2008 07:49:45 +0200, Stefan Behnel wrote: > Jack wrote: >> I know one benchmark doesn't mean much but it's still disappointing to >> see Python as one of the slowest languages in the test: >> >> http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java- python-ruby-jython

Re: benchmark

Jack wrote: > I know one benchmark doesn't mean much but it's still disappointing to see > Python as one of the slowest languages in the test: > > http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/ > Just ignore that. If the code had been desig

Re: benchmark

On Aug 7, 2:05 am, "Jack" <[EMAIL PROTECTED]> wrote: > I know one benchmark doesn't mean much but it's still disappointing to see > Python as one of the slowest languages in the test: > > http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-p... That Python code is bad, it contains

Re: benchmark

Jack wrote: I know one benchmark doesn't mean much but it's still disappointing to see Python as one of the slowest languages in the test: http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/ -- http://mail.python.org/mailman/listinfo/python-l

Re: Benchmark [was Re: common problem - elegant solution sought]

On Jan 15, 6:18 pm, Paul Rubin wrote: > Helmut Jarausch <[EMAIL PROTECTED]> writes: > > def del_by_key(L,key) : > >for pos, (k,d) in enumerate(L): > > if k == key : > >del L[pos] > >break > > This looks very dangerous, mutating L while iterating

Re: Benchmark [was Re: common problem - elegant solution sought]

Paul Rubin wrote: > Helmut Jarausch <[EMAIL PROTECTED]> writes: >> def del_by_key(L,key) : >>for pos, (k,d) in enumerate(L): >> if k == key : >>del L[pos] >>break > > This looks very dangerous, mutating L while iterating over it. No, as Bruno Desthuilliers has pointed ou

Re: Benchmark [was Re: common problem - elegant solution sought]

Helmut Jarausch <[EMAIL PROTECTED]> writes: > def del_by_key(L,key) : >for pos, (k,d) in enumerate(L): > if k == key : >del L[pos] >break This looks very dangerous, mutating L while iterating over it. -- http://mail.python.org/mailman/listinfo/python-list

Re: Benchmark [was Re: common problem - elegant solution sought]

Helmut Jarausch: > The clear winner is > > def del_by_key(L,key) : >for pos, (k,d) in enumerate(L): > if k == key : >del L[pos] >break If you use Psyco this is faster: def del_by_key(L,key): pos = 0 for pair in L: if pair[0] == key : del L[pos]

Re: Benchmark...

Google and wikipedia! On Nov 30, 2007 9:39 AM, ArShAm Shirvani <[EMAIL PROTECTED]> wrote: > Hi > I need a benchmark for speed , comparing with other languages > > Regards > Arsham > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://search.goldwatches.com/?Search=Movado+Wa