Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #104132 > unrolled thread
| Started by | Tony van der Hoff <tony@vanderhoff.org> |
|---|---|
| First post | 2016-03-06 11:34 +0000 |
| Last post | 2016-03-07 19:02 +0000 |
| Articles | 20 on this page of 142 — 20 participants |
Back to article view | Back to comp.lang.python
Pyhon 2.x or 3.x, which is faster? Tony van der Hoff <tony@vanderhoff.org> - 2016-03-06 11:34 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-07 01:41 +1100
Re: Pyhon 2.x or 3.x, which is faster? Tony van der Hoff <tony@vanderhoff.org> - 2016-03-07 10:45 +0000
Re: Pyhon 2.x or 3.x, which is faster? Andrew Jaffe <a.h.jaffe@gmail.com> - 2016-03-07 11:54 +0000
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-07 17:33 -0500
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 11:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Marko Rauhamaa <marko@pacujo.net> - 2016-03-07 13:11 +0200
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 11:38 +0000
Re: Pyhon 2.x or 3.x, which is faster? Fabien <fabien.maussion@gmail.com> - 2016-03-07 13:19 +0100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 13:25 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 02:31 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 18:34 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 06:10 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 20:19 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 07:47 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 22:39 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 10:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 00:22 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 00:43 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 11:45 +1100
Re: Pyhon 2.x or 3.x, which is faster? MRAB <python@mrabarnett.plus.com> - 2016-03-08 00:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-07 20:29 -0500
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-07 22:51 -0500
Re: Pyhon 2.x or 3.x, which is faster? Michael Torrie <torriem@gmail.com> - 2016-03-08 17:34 -0700
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 13:01 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-09 11:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 11:05 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:00 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 01:12 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 02:45 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 11:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 16:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 19:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 20:44 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 22:38 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 10:59 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-09 08:40 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 12:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-09 21:13 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 23:14 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-09 23:35 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 00:58 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 12:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 07:30 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 11:50 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 12:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 12:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 00:08 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 14:22 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 19:26 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-11 16:29 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-11 18:57 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-11 21:59 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-11 22:24 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-12 16:59 +1100
Re: Pyhon 2.x or 3.x, which is faster? alister <alister.ware@ntlworld.com> - 2016-03-12 10:06 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-12 10:31 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-12 10:51 +0000
Re: Pyhon 2.x or 3.x, which is faster? alister <alister.ware@ntlworld.com> - 2016-03-12 15:36 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-13 14:22 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-12 10:34 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-12 21:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 07:07 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-11 16:06 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 16:36 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 13:18 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 00:30 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 13:46 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-10 18:43 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 18:55 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 12:59 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 12:19 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 10:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 23:48 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 11:03 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-10 02:38 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 14:43 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 01:30 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-10 13:29 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 14:32 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 13:45 +1100
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-10 11:21 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 12:23 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:33 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 12:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 12:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 02:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 13:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? MRAB <python@mrabarnett.plus.com> - 2016-03-08 02:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 11:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-08 13:45 +0200
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 12:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-07 22:39 -0500
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 03:48 +0000
What will I get when reading from a file? (was: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 11:09 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-08 13:12 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 11:53 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 10:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 00:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-09 11:36 +1100
Re: Pyhon 2.x or 3.x, which is faster? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-08 21:03 -0500
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 03:07 +1100
Re: Pyhon 2.x or 3.x, which is faster? Serhiy Storchaka <storchaka@gmail.com> - 2016-03-08 14:48 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-08 12:34 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 12:49 +1100
Re: Pyhon 2.x or 3.x, which is faster? Serhiy Storchaka <storchaka@gmail.com> - 2016-03-08 15:05 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-08 12:19 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:41 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-08 15:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 13:49 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 16:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? wxjmfauth@gmail.com - 2016-03-08 09:23 -0800
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 19:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 11:04 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 01:28 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 13:18 +1100
Re: Pyhon 2.x or 3.x, which is faster? wxjmfauth@gmail.com - 2016-03-09 02:11 -0800
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 14:03 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 01:11 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 14:39 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 01:54 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 02:33 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 02:58 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 14:56 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 02:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 01:57 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 02:04 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 16:53 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 01:54 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 15:06 +0000
Re: Pyhon 2.x or 3.x, which is faster? Tim Golden <mail@timgolden.me.uk> - 2016-03-09 15:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 02:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-09 10:42 -0500
Re: Pyhon 2.x or 3.x, which is faster? wxjmfauth@gmail.com - 2016-03-09 09:04 -0800
Re: Pyhon 2.x or 3.x, which is faster? Marko Rauhamaa <marko@pacujo.net> - 2016-03-09 08:08 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 22:52 +1100
Re: Pyhon 2.x or 3.x, which is faster? Marko Rauhamaa <marko@pacujo.net> - 2016-03-09 14:53 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 03:53 +1100
Re: Pyhon 2.x or 3.x, which is faster? Michael Torrie <torriem@gmail.com> - 2016-03-08 17:42 -0700
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 02:53 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-07 19:02 +0000
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Tony van der Hoff <tony@vanderhoff.org> |
|---|---|
| Date | 2016-03-06 11:34 +0000 |
| Subject | Pyhon 2.x or 3.x, which is faster? |
| Message-ID | <mailman.238.1457265255.20602.python-list@python.org> |
Hi, I've been experimenting with a short test program under python 2.7 and python 3.4.2. It's a simple read from file, and locate a word therein. I get the (subjective) impression that python2 is slightly faster than python3. Is that correct? Is there any documentation to support this? Thanks, -- Tony van der Hoff | mailto:tony@vanderhoff.org Buckinghamshire, England |
[toc] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-07 01:41 +1100 |
| Message-ID | <56dc41b5$0$1585$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104132 |
On Sun, 6 Mar 2016 10:34 pm, Tony van der Hoff wrote: > Hi, I've been experimenting with a short test program under python 2.7 > and python 3.4.2. It's a simple read from file, and locate a word therein. > > I get the (subjective) impression that python2 is slightly faster than > python3. Is that correct? Is there any documentation to support this? I believe that, overall, Python 3 is still slightly slower than Python 2, but it's a near thing. Have a look at the latest performance benchmarks: https://speed.python.org/comparison/ Eyeballing the graph, I estimate that the latest 3.x version is probably about 10% slower overall, although different benchmarks show different speeds. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Tony van der Hoff <tony@vanderhoff.org> |
|---|---|
| Date | 2016-03-07 10:45 +0000 |
| Message-ID | <mailman.14.1457347521.10335.python-list@python.org> |
| In reply to | #104144 |
On 06/03/16 14:41, Steven D'Aprano wrote: > On Sun, 6 Mar 2016 10:34 pm, Tony van der Hoff wrote: > >> Hi, I've been experimenting with a short test program under python 2.7 >> and python 3.4.2. It's a simple read from file, and locate a word therein. >> >> I get the (subjective) impression that python2 is slightly faster than >> python3. Is that correct? Is there any documentation to support this? > > I believe that, overall, Python 3 is still slightly slower than Python 2, > but it's a near thing. Have a look at the latest performance benchmarks: > > https://speed.python.org/comparison/ > > Eyeballing the graph, I estimate that the latest 3.x version is probably > about 10% slower overall, although different benchmarks show different > speeds. Excellent, just what I was looking for. Thank you very much, Steven. -- Tony van der Hoff | mailto:tony@vanderhoff.org Buckinghamshire, England |
[toc] | [prev] | [next] | [standalone]
| From | Andrew Jaffe <a.h.jaffe@gmail.com> |
|---|---|
| Date | 2016-03-07 11:54 +0000 |
| Message-ID | <mailman.16.1457351677.10335.python-list@python.org> |
| In reply to | #104144 |
On 06/03/2016 14:41, Steven D'Aprano wrote: > On Sun, 6 Mar 2016 10:34 pm, Tony van der Hoff wrote: > >> Hi, I've been experimenting with a short test program under python 2.7 >> and python 3.4.2. It's a simple read from file, and locate a word therein. >> >> I get the (subjective) impression that python2 is slightly faster than >> python3. Is that correct? Is there any documentation to support this? > > I believe that, overall, Python 3 is still slightly slower than Python 2, > but it's a near thing. Have a look at the latest performance benchmarks: > > https://speed.python.org/comparison/ > > Eyeballing the graph, I estimate that the latest 3.x version is probably > about 10% slower overall, although different benchmarks show different > speeds. > Dumb question, and this probably isn't the place for it, but the three Pythons being tested are: 64-bit CPython on Li... latest in branch '2.7' 64-bit CPython on Li... latest in branch '3.5' 64-bit CPython on Li... latest I understand that the first two are the released 2.7 and 3.5 versions; is the third the most recent 3.x build? Andrew
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-03-07 17:33 -0500 |
| Message-ID | <mailman.54.1457390032.10335.python-list@python.org> |
| In reply to | #104144 |
On 3/7/2016 6:54 AM, Andrew Jaffe wrote:
> Dumb question, and this probably isn't the place for it, but the three
> Pythons being tested are:
>
> 64-bit CPython on Li... latest in branch '2.7'
> 64-bit CPython on Li... latest in branch '3.5'
> 64-bit CPython on Li... latest
> I understand that the first two are the released 2.7 and 3.5
> versions; is the third the most recent 3.x build?
I am rather sure that none are released versions and that all three
refer to the current tip ('latest') of each branch in the repository,
with third being the default branch.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-07 11:02 +0000 |
| Message-ID | <nbjmv7$ad5$1@dont-email.me> |
| In reply to | #104132 |
On 06/03/2016 11:34, Tony van der Hoff wrote: > Hi, I've been experimenting with a short test program under python 2.7 > and python 3.4.2. It's a simple read from file, and locate a word therein. > > I get the (subjective) impression that python2 is slightly faster than > python3. Is that correct? Is there any documentation to support this? I've also found that 3 was consistently slower than 2 on various benchmarks. Perhaps 10 to 20% slower (also 3.4 vs. 2.7). One example (processing a jpeg file), both with CPython on Windows[1]: Python 3.4: 6.8 seconds Python 2.7: 5.4 seconds But then: PyPy: 2.1 seconds [2] PyPy I think is only compatible with Python 3 code (there are a few other issues too). ([1] Windows Python I believe is a little slower than on Linux, for the same version of Python and on the same hardware. I think due to CPython being compiled with MSVC not gcc. But it would affect 2 and 3 equally.) ([2] With larger data, PyPy gets progressively faster compared with normal Python, as it can optimise big loops better. This test was with 0.5 Mpixels of data) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-07 13:11 +0200 |
| Message-ID | <87d1r6iltx.fsf@elektro.pacujo.net> |
| In reply to | #104206 |
BartC <bc@freeuk.com>: > I've also found that 3 was consistently slower than 2 on various > benchmarks. Perhaps 10 to 20% slower (also 3.4 vs. 2.7). Python doesn't exist for performance-critical parts of your solution. Also, Python programs tend to take huge amounts of space. Where that is a problem, use some other programming language like C. Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-07 11:38 +0000 |
| Message-ID | <nbjp1e$jhv$1@dont-email.me> |
| In reply to | #104207 |
On 07/03/2016 11:11, Marko Rauhamaa wrote: > BartC <bc@freeuk.com>: > >> I've also found that 3 was consistently slower than 2 on various >> benchmarks. Perhaps 10 to 20% slower (also 3.4 vs. 2.7). > > Python doesn't exist for performance-critical parts of your solution. > Also, Python programs tend to take huge amounts of space. I'm not complaining. For my purposes (implementing a similar language that competes with Python for speed), I welcome the slower speed of Python 3! (Although competing with CPython is too easy. PyPy is more of a problem. With the Jpeg benchmark I mentioned, I can beat PyPy up to 6Mpix, but then PyPy starts to get faster. At 80Mpix, PyPy is 60% faster.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Fabien <fabien.maussion@gmail.com> |
|---|---|
| Date | 2016-03-07 13:19 +0100 |
| Message-ID | <nbjrjm$m16$1@gioia.aioe.org> |
| In reply to | #104209 |
On 03/07/2016 12:38 PM, BartC wrote: > > (Although competing with CPython is too easy. PyPy is more of a problem. > With the Jpeg benchmark I mentioned, I can beat PyPy up to 6Mpix, but > then PyPy starts to get faster. At 80Mpix, PyPy is 60% faster.) Just out of curiosity: are you also competing against numpy/scipy?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-07 13:25 +0000 |
| Message-ID | <nbjvas$h22$1@dont-email.me> |
| In reply to | #104211 |
On 07/03/2016 12:19, Fabien wrote: > On 03/07/2016 12:38 PM, BartC wrote: >> >> (Although competing with CPython is too easy. PyPy is more of a problem. >> With the Jpeg benchmark I mentioned, I can beat PyPy up to 6Mpix, but >> then PyPy starts to get faster. At 80Mpix, PyPy is 60% faster.) > > Just out of curiosity: are you also competing against numpy/scipy? No, I only compare basic language functions. I understand that Python depends on complex built-in functions, and external libraries such as numpy, for it to be used viably. But I'm also interested in using such languages directly. Take the jpeg benchmark. Of course both Python and my language are hopelessly slow and impractical compared with a C implementation, but this is still a useful test (and in fact the interpreted version was used to more easily develop a streamlined decoder that was then back-ported to C, doubling its speed). (The Python version of that program is here: http://pastebin.com/cHx3UhQb. It should work with any Python.) For example, suppose you wanted to do crude animation by loading a series of small 640x480 images. Loading such an image gives you the following frame rates, excluding the extra overheads of displaying the results: Python 2.7: 0.33 fps Python 3.4: 0.25 fps PyPy: 0.55 fps (don't known what version) Mine: 3.77 fps You can't really call the first three animated (more like a slide show), but 4 fps just about cuts it! Sometimes pushing an interpreted language a bit further can be useful (hence the existence of the PyPy project). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 02:31 +1100 |
| Message-ID | <mailman.17.1457364684.10335.python-list@python.org> |
| In reply to | #104214 |
On Tue, Mar 8, 2016 at 12:25 AM, BartC <bc@freeuk.com> wrote: > No, I only compare basic language functions. I understand that Python > depends on complex built-in functions, and external libraries such as numpy, > for it to be used viably. But I'm also interested in using such languages > directly. > > Take the jpeg benchmark. Of course both Python and my language are > hopelessly slow and impractical compared with a C implementation, but this > is still a useful test (and in fact the interpreted version was used to more > easily develop a streamlined decoder that was then back-ported to C, > doubling its speed). > > (The Python version of that program is here: > http://pastebin.com/cHx3UhQb. It should work with any Python.) Actually, it won't work with any Python - not if it gets a broken file. Your abortjpeg() function doesn't work :) But what you have there is a messy mixture of old-style classes used as if they were C structs, array.array() as if it were a C array, and utterly uncommented code that looks like it was ported from, again, C. You're not going to prove anything useful about Python - any version of Python - by using it badly. Try implementing JPEG decoding in a more Pythonic way - or, better still, use pillow and don't write that kind of code yourself at all. Benchmarking Py2 vs Py3 on that kind of code is like trying to figure out whether it's easier to drag a 747 by your teeth or your toes. Yeah, you might get a result, but it's a useless one. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-07 18:34 +0000 |
| Message-ID | <nbkhei$dg6$1@dont-email.me> |
| In reply to | #104215 |
On 07/03/2016 15:31, Chris Angelico wrote: > On Tue, Mar 8, 2016 at 12:25 AM, BartC <bc@freeuk.com> wrote: >> (The Python version of that program is here: >> http://pastebin.com/cHx3UhQb. It should work with any Python.) > > Actually, it won't work with any Python - not if it gets a broken > file. Your abortjpeg() function doesn't work :) What does it do when it doesn't work? I just get 'can't load file' then it stops if there's no such file. With an extra message if there's a format error. (I'm not sure what 'raise' does, but it doesn't complain about it. I think I realised I didn't know what came next and left it.) > But what you have there is a messy mixture of old-style classes used > as if they were C structs, array.array() as if it were a C array, and > utterly uncommented code that looks like it was ported from, again, C. > Benchmarking Py2 vs Py3 on that kind of code is like trying to figure > out whether it's easier to drag a 747 by your teeth or your toes. > Yeah, you might get a result, but it's a useless one. I disagree. The program does its job perfectly (you will have to take it further to verify the results, such as writing out the .ppm file and viewing the contents). But Py3 is slower doing this task than Py2 by 10 or 20% (or even 30% for a smaller file). /This is in line with other observations./ > You're not going to prove anything useful about Python - any version > of Python - by using it badly. Try implementing JPEG decoding in a > more Pythonic way - or, better still, use pillow and don't write that > kind of code yourself at all. Before I wrote this, I looked at three other existing Python decoders, all more Pythonic (one had been ported from C++ I think and was crammed full of classes). One worked so poorly that it was dismissed. The other two were full of bugs and didn't fully support the 3 main colour formats, but when they did work, were 3-6 times slower than my version IIRC. They also only worked with Python 2 (so presumably would have been even slower on 3!) It also meant I couldn't test PyPy on them. I tried psyco but it made little difference. And actually the main purpose was to have something substantial to try PyPy on. So I don't know who's using Python more badly: me or those other authors. (I'm quite pleased with my version: smaller, faster, works on all the Pythons, supports all 3 colour formats and no decoding bugs that I'm aware of, and it's the first Python program I've written that does something useful.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 06:10 +1100 |
| Message-ID | <mailman.43.1457377845.10335.python-list@python.org> |
| In reply to | #104243 |
On Tue, Mar 8, 2016 at 5:34 AM, BartC <bc@freeuk.com> wrote:
> On 07/03/2016 15:31, Chris Angelico wrote:
>>
>> On Tue, Mar 8, 2016 at 12:25 AM, BartC <bc@freeuk.com> wrote:
>
>
>>> (The Python version of that program is here:
>>> http://pastebin.com/cHx3UhQb. It should work with any Python.)
>>
>>
>> Actually, it won't work with any Python - not if it gets a broken
>> file. Your abortjpeg() function doesn't work :)
>
>
> What does it do when it doesn't work? I just get 'can't load file' then it
> stops if there's no such file. With an extra message if there's a format
> error. (I'm not sure what 'raise' does, but it doesn't complain about it. I
> think I realised I didn't know what came next and left it.)
Here's your code:
def abortjpeg(mess):
print ("Error:",mess)
raise
Here's my Python:
$ python3
Python 3.6.0a0 (default:bbfbde6ee9d0, Feb 19 2016, 12:43:06)
[GCC 5.3.1 20160121] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> raise
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: No active exception to reraise
The only try/except in your code (an except block is the only way
you'll have an "active exception") is this abomination:
def getfile(file):
try:
data=open(file,"rb").read()
except:
return 0
...
>> But what you have there is a messy mixture of old-style classes used
>> as if they were C structs, array.array() as if it were a C array, and
>> utterly uncommented code that looks like it was ported from, again, C.
>> Benchmarking Py2 vs Py3 on that kind of code is like trying to figure
>> out whether it's easier to drag a 747 by your teeth or your toes.
>> Yeah, you might get a result, but it's a useless one.
>
>
> I disagree. The program does its job perfectly (you will have to take it
> further to verify the results, such as writing out the .ppm file and viewing
> the contents).
>
> But Py3 is slower doing this task than Py2 by 10 or 20% (or even 30% for a
> smaller file). /This is in line with other observations./
What's your meaning of "perfectly"? You're implementing things in a
very C way, and then showing that two different Python interpreters
have different performance. You haven't actually shown how a
properly-written program would perform.
>> You're not going to prove anything useful about Python - any version
>> of Python - by using it badly. Try implementing JPEG decoding in a
>> more Pythonic way - or, better still, use pillow and don't write that
>> kind of code yourself at all.
>
> Before I wrote this, I looked at three other existing Python decoders, all
> more Pythonic (one had been ported from C++ I think and was crammed full of
> classes).
>
> One worked so poorly that it was dismissed. The other two were full of bugs
> and didn't fully support the 3 main colour formats, but when they did work,
> were 3-6 times slower than my version IIRC.
>
> They also only worked with Python 2 (so presumably would have been even
> slower on 3!) It also meant I couldn't test PyPy on them. I tried psyco but
> it made little difference. And actually the main purpose was to have
> something substantial to try PyPy on.
>
> So I don't know who's using Python more badly: me or those other authors.
Did you try the 'pillow' library?
https://pypi.python.org/pypi/Pillow
It supports 2.6/2.7 and 3.2+, and would be most people's "one obvious
way" to do things. At very least, it should get a mention in your
performance comparisons.
> (I'm quite pleased with my version: smaller, faster, works on all the
> Pythons, supports all 3 colour formats and no decoding bugs that I'm aware
> of, and it's the first Python program I've written that does something
> useful.)
"all the Pythons" meaning what, exactly? And, no decoding bugs? Maybe,
but I wouldn't bet my life on it. Unless your code is a pure port of
someone else's (and unless that someone else could guarantee that the
original C code was bug free), I wouldn't trust code that I can't
completely analyze in one sitting. Virtually all code has bugs in it;
the only code that doesn't is code that's so trivially simple that you
can completely understand it in one "headspace".
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-07 20:19 +0000 |
| Message-ID | <nbknir$avu$1@dont-email.me> |
| In reply to | #104247 |
On 07/03/2016 19:10, Chris Angelico wrote:
> On Tue, Mar 8, 2016 at 5:34 AM, BartC <bc@freeuk.com> wrote:
> def abortjpeg(mess):
> print ("Error:",mess)
> raise
>
> Here's my Python:
> RuntimeError: No active exception to reraise
OK I'll have a look. (Or maybe just change 'raise' to 'exit(0)'. It just
needs to crash out at this point, but should be a bit more graceful than
what you had.)
>> I disagree. The program does its job perfectly (you will have to take it
>> further to verify the results, such as writing out the .ppm file and viewing
>> the contents).
>>
>> But Py3 is slower doing this task than Py2 by 10 or 20% (or even 30% for a
>> smaller file). /This is in line with other observations./
>
> What's your meaning of "perfectly"? You're implementing things in a
> very C way, and then showing that two different Python interpreters
> have different performance.
Two interpreters executing exactly the same code and exactly the same
algorithm. And for a real task which deliberately doesn't just delegate
to high-level features (otherwise you're just comparing libraries).
What can be more perfect for comparing two implementations?
> You haven't actually shown how a
> properly-written program would perform.
If I could find one that worked, I would have used that! (But I was more
interested in 3 vs. PyPy than 2 vs. 3.)
> Did you try the 'pillow' library?
>
> https://pypi.python.org/pypi/Pillow
>
> It supports 2.6/2.7 and 3.2+, and would be most people's "one obvious
> way" to do things. At very least, it should get a mention in your
> performance comparisons.
I don't understand. This is an external library that appears to be
written in C. How does that help me compare the performance of two
implementations of Python?
One could be ten times slower than the other (in executing its native
bytecode), but if it spends 99% of its time an a C image library, how do
you measure that?
>> (I'm quite pleased with my version: smaller, faster, works on all the
>> Pythons, supports all 3 colour formats and no decoding bugs that I'm aware
>> of, and it's the first Python program I've written that does something
>> useful.)
>
> "all the Pythons" meaning what, exactly?
I means versions 2 and 3 of the language, tested on CPython versions
2.5, 2.7, 3.1 and 3.4, as well as PyPy. The other decoders I tried were
for 2.x.
> And, no decoding bugs? Maybe,
> but I wouldn't bet my life on it. Unless your code is a pure port of
> someone else's (and unless that someone else could guarantee that the
> original C code was bug free), I wouldn't trust code that I can't
> completely analyze in one sitting. Virtually all code has bugs in it;
> the only code that doesn't is code that's so trivially simple that you
> can completely understand it in one "headspace".
Let's put it this way: I don't have to hand a jpeg file that it can't
decode. When one turns up then I will fix that. (I can't say for sure
there aren't any subtle chroma or quality problems, but there's nothing
obvious.) I can't say that for the decoders I looked at.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 07:47 +1100 |
| Message-ID | <mailman.49.1457383632.10335.python-list@python.org> |
| In reply to | #104253 |
On Tue, Mar 8, 2016 at 7:19 AM, BartC <bc@freeuk.com> wrote:
>>> I disagree. The program does its job perfectly (you will have to take it
>>> further to verify the results, such as writing out the .ppm file and
>>> viewing
>>> the contents).
>>>
>>> But Py3 is slower doing this task than Py2 by 10 or 20% (or even 30% for
>>> a
>>> smaller file). /This is in line with other observations./
>>
>>
>> What's your meaning of "perfectly"? You're implementing things in a
>> very C way, and then showing that two different Python interpreters
>> have different performance.
>
>
> Two interpreters executing exactly the same code and exactly the same
> algorithm. And for a real task which deliberately doesn't just delegate to
> high-level features (otherwise you're just comparing libraries).
>
> What can be more perfect for comparing two implementations?
def valueOf(digit):
return ord(digit) - ord('0')
class Float:
def __init__(self, string):
self.value = 0
self.scale = 0
have_dot = 0
for i in range(len(string)):
if string[i] == '.': have_dot = 1
else:
self.value = self.value * 10 + valueOf(string[i])
if have_dot: self.scale += 1
rosuav@sikorsky:~$ python2 -m timeit -s 'from fp import Float'
'Float("1234.567")'
1000000 loops, best of 3: 1.84 usec per loop
rosuav@sikorsky:~$ python3 -m timeit -s 'from fp import Float'
'Float("1234.567")'
100000 loops, best of 3: 2.76 usec per loop
Look! Creating a floating-point value is faster under Python 2 than
Python 3. What could be more perfect?
This is like a microbenchmark in that it doesn't tell you anything
about real-world usage. Your example also has the problem that it does
file I/O, which adds a ton of noise to your numbers. When you
reimplement a C-designed algorithm in Python, it's often NOT going to
be the best use of the language; and if you're comparing two poor uses
of a language, what do you prove by showing that one interpreter is
faster than another?
>> Did you try the 'pillow' library?
>>
>> https://pypi.python.org/pypi/Pillow
>>
>> It supports 2.6/2.7 and 3.2+, and would be most people's "one obvious
>> way" to do things. At very least, it should get a mention in your
>> performance comparisons.
>
>
> I don't understand. This is an external library that appears to be written
> in C. How does that help me compare the performance of two implementations
> of Python?
I'm not sure that it is written in C, but the point is that this is a
much better way to compare code. Use the language well, not badly.
> One could be ten times slower than the other (in executing its native
> bytecode), but if it spends 99% of its time an a C image library, how do you
> measure that?
You write *real world* code and then profile that. You get actual real
programs that you actually really use, and you run those through
timing harnesses. (Or throughput harnesses, which are pretty much the
same thing. With a web application, "performance" doesn't so much mean
"how long it takes to run", but "how many requests per second the
system can handle". Same thing, opposite way of measuring it.)
>>> (I'm quite pleased with my version: smaller, faster, works on all the
>>> Pythons, supports all 3 colour formats and no decoding bugs that I'm
>>> aware
>>> of, and it's the first Python program I've written that does something
>>> useful.)
>>
>>
>> "all the Pythons" meaning what, exactly?
>
>
> I means versions 2 and 3 of the language, tested on CPython versions 2.5,
> 2.7, 3.1 and 3.4, as well as PyPy. The other decoders I tried were for 2.x.
CPython 2.5 and 2.7 are very different. Even 2.7.0 and 2.7.11 are
going to differ in performance. And that's without even looking at
what core devs would refer to as "other Pythons", which would include
IronPython, Jython, PyPy (well, you got that, but you're treating it
as an afterthought), MicroPython, Brython, wpython, Nuitka,
Cython..... these are *other Pythons*. What you're looking at is
closer to *all the versions of CPython*, but not even that, since
there are so many different ways that they can be built, and the
performance of array.array() is far from stable. It's not a core
language feature; you're using it because it's the most obvious
translation of your C algorithm, not because it's the best way to use
Python. So I say again, your measurement has little to no significance
to real-world code.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-07 22:39 +0000 |
| Message-ID | <nbkvq2$j5s$1@dont-email.me> |
| In reply to | #104255 |
On 07/03/2016 20:47, Chris Angelico wrote:
> On Tue, Mar 8, 2016 at 7:19 AM, BartC <bc@freeuk.com> wrote:
>> What can be more perfect for comparing two implementations?
> rosuav@sikorsky:~$ python2 -m timeit -s 'from fp import Float'
> 'Float("1234.567")'
> 1000000 loops, best of 3: 1.84 usec per loop
> rosuav@sikorsky:~$ python3 -m timeit -s 'from fp import Float'
> 'Float("1234.567")'
> 100000 loops, best of 3: 2.76 usec per loop
>
> Look! Creating a floating-point value is faster under Python 2 than
> Python 3. What could be more perfect?
> This is like a microbenchmark in that it doesn't tell you anything
> about real-world usage.
Microbenchmarks have their uses, when you are concentrating on a
particular aspect of a language. But I tried your code, calling Float a
million times, and 2.7 took 8.3 seconds; 3.4 took 10.5 seconds. But that
is meaningless according to you.
(3.1 took 8.5 seconds. What happened between 3.1 and 3.4 to cause such a
slow-down? Do you think it might be a good idea for /someone/ at least
to take pay some attention to that, before it grinds to a halt
completely by version 4.0?)
(I tried near-equivalent code on my byte-coded language. It took 0.7
seconds. Then I tried a fairer test, as I use a bit of ASM to help the
interpreter along: I created a C source version of the interpreter,
compiled it with Tiny C, which generates some of the worst code around,
and ran it again on the byte-code. It took 3 seconds; still faster than
either of the Pythons!)
Anyway, is reading a jpeg not real world usage? It's a task normally
done with a compiled language, but can also be a good test for an
interpreted one.
> You write *real world* code and then profile that. You get actual real
> programs that you actually really use, and you run those through
> timing harnesses.
Sorry, but that is useless. It tells you that slow, interpreted
languages can be viable with certain kinds of usage. Everyone knows that
(I've been creating applications which balance compiled code and
interpreted code since about the mid-80s).
If you want an interpreted language to take on wider range of tasks,
then you need to make it faster, and that means measuring how efficient
it is at executing algorithms itself, not measuring how long some
library in a different language takes to execute.
> CPython 2.5 and 2.7 are very different. Even 2.7.0 and 2.7.11 are
> going to differ in performance. And that's without even looking at
> what core devs would refer to as "other Pythons", which would include
> IronPython, Jython, PyPy (well, you got that, but you're treating it
> as an afterthought), MicroPython, Brython, wpython, Nuitka,
> Cython..... these are *other Pythons*.
What are you suggesting here? That all these Pythons are going to be
faster or slower than each other? I would guess that most of them are
going to be roughly the same, other than PyPy. If there was a fast
version, then I would have heard about it!
> the
> performance of array.array() is far from stable. It's not a core
> language feature; you're using it because it's the most obvious
> translation of your C algorithm,
I'm using it because this kind of file reading in Python is a mess. If I
do a read, will I get a string, a byte sequence object, a byte-array, or
array-array, or what?
Are you saying there array.array will not work on some implementations?
In that case it's more of a mess than I thought!
> not because it's the best way to use
> Python. So I say again, your measurement has little to no significance
> to real-world code.
Real world use of Python appears to be as a scripting language and for
glue code, with most of the real work done in libraries implemented in
native code. I acknowledge that. And I understand that the 10-20%
difference between Py2 and Py3 will largely disappear for these kinds of
uses.
But I also said I am interested in using the languages to directly
implement programs and algorithms not just for scripting. Then you need
to be able to measure what the core language is capable of.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 10:40 +1100 |
| Message-ID | <mailman.3.1457394034.15725.python-list@python.org> |
| In reply to | #104261 |
On Tue, Mar 8, 2016 at 9:39 AM, BartC <bc@freeuk.com> wrote: > > What are you suggesting here? That all these Pythons are going to be faster > or slower than each other? I would guess that most of them are going to be > roughly the same, other than PyPy. If there was a fast version, then I would > have heard about it! Try them, then you'll know. They all have different strengths and weaknesses. >> the >> performance of array.array() is far from stable. It's not a core >> language feature; you're using it because it's the most obvious >> translation of your C algorithm, > > I'm using it because this kind of file reading in Python is a mess. If I do > a read, will I get a string, a byte sequence object, a byte-array, or > array-array, or what? Uhh.... you'll get either a text string or a byte string, depending on whether you opened the file as text or binary. Where's the mess? > Are you saying there array.array will not work on some implementations? In > that case it's more of a mess than I thought! No, it'll always be there (at least, I'm pretty sure it will). I said that its *performance* is all over the place. Try coding in the simplest possible way first, and only turn to array.array afterward. > Real world use of Python appears to be as a scripting language and for glue > code, with most of the real work done in libraries implemented in native > code. I acknowledge that. And I understand that the 10-20% difference > between Py2 and Py3 will largely disappear for these kinds of uses. Real world use of Python includes writing full-scale applications in it... not sure whether the myriad web apps written with Flask/Django/etc count as "most of the real work done in native libraries". But what does "real work" mean? When you write a data processing program in Python, you could spend most of your time doing integer arithmetic using the native 'int' type, or you could spend most of your time using numpy. One of those is using a third-party library written in Fortran; the other is using the language facilities directly. But in CPython, the latter means you're using C. Where's the difference? All your most important code - all the "real work" in terms of algorithms etc - is in Python. The underlying facilities are completely generic. > But I also said I am interested in using the languages to directly implement > programs and algorithms not just for scripting. Then you need to be able to > measure what the core language is capable of. Yeah, because the value of human legs is proven by walking from one city to the next and seeing how long it takes. You're still using the language inefficiently, and then proving that one inefficient use is less inefficient than another. Congratulations. I'm done. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 00:22 +0000 |
| Message-ID | <nbl5po$bfo$1@dont-email.me> |
| In reply to | #104273 |
On 07/03/2016 23:40, Chris Angelico wrote:
> On Tue, Mar 8, 2016 at 9:39 AM, BartC <bc@freeuk.com> wrote:
>> I'm using it because this kind of file reading in Python is a mess. If I do
>> a read, will I get a string, a byte sequence object, a byte-array, or
>> array-array, or what?
>
> Uhh.... you'll get either a text string or a byte string, depending on
> whether you opened the file as text or binary. Where's the mess?
(Is a byte string the same as a byte array? Is a byte array the same as
an array.array? If I remove this line from my code, where 'data' has
just been read from a file:
data=array.array('B',data)
then it still works - Python 3. But not on Python 2. If I do .read on a
binary file I get a byte string in Python 3, but a string in Python 2.
That sort of mess.
And how do I write that deceptively simple header on the output file
without array.array because I tried all sorts:
f = open(file+".ppm", "wb")
s="P6\n%d %d\n255\n" % (hdr.width, hdr.height)
sbytes=array.array('B',list(map(ord,s)))
f.write(sbytes)
Note this file mixes text and binary mode - blame the ppm format - but
is mostly binary.)
>> But I also said I am interested in using the languages to directly implement
>> programs and algorithms not just for scripting. Then you need to be able to
>> measure what the core language is capable of.
>
> Yeah, because the value of human legs is proven by walking from one
> city to the next and seeing how long it takes. You're still using the
> language inefficiently, and then proving that one inefficient use is
> less inefficient than another. Congratulations.
So whoever created the speed comparison site linked to at the start of
the thread is wasting their time?
Obviously some people are interested in this stuff, even if you're not.
The slow speed of Python (and a number of other scripting languages) is
well known. But obviously that is not any sort of issue, and these
people working flat out on tracing JIT compilers are all wasting their
time too!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 00:43 +0000 |
| Message-ID | <mailman.12.1457397847.15725.python-list@python.org> |
| In reply to | #104283 |
On 08/03/2016 00:22, BartC wrote: > > The slow speed of Python (and a number of other scripting languages) is > well known. But obviously that is not any sort of issue, and these > people working flat out on tracing JIT compilers are all wasting their > time too! > The slow speed of Python hasn't stopped it gaining a huge following in just about every possible area of computing. Who cares about speed when you're waiting for the file, database or network to respond? Sure, some people want things faster, but I suspect that 99% couldn't care less. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 11:45 +1100 |
| Message-ID | <mailman.13.1457397949.15725.python-list@python.org> |
| In reply to | #104283 |
On Tue, Mar 8, 2016 at 11:22 AM, BartC <bc@freeuk.com> wrote:
>
> (Is a byte string the same as a byte array? Is a byte array the same as an
> array.array? If I remove this line from my code, where 'data' has just been
> read from a file:
>
> data=array.array('B',data)
>
> then it still works - Python 3. But not on Python 2. If I do .read on a
> binary file I get a byte string in Python 3, but a string in Python 2. That
> sort of mess.
The default string in Py2 *is* a byte string.
ChrisA
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web