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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-09 23:14 +0000 |
| Message-ID | <nbqaja$5g5$1@dont-email.me> |
| In reply to | #104453 |
On 09/03/2016 21:13, Mark Lawrence wrote: > On 09/03/2016 12:02, BartC wrote: >> On 09/03/2016 08:40, Mark Lawrence wrote: >> >> Here's another: you have a program in Python that you'd quite like to >> port to another dynamic language. Transcribing actual Python code is >> straightforward. Until you come to an import of a module that you can't >> find, because it's not written in Python. Now what? Now, you might >> appreciate the advantage of a program in 100% pure Python. >> > > That is not Python's problem, or my problem, that is your problem. Maybe that's not the best example of why someone might prefer a 'Python' program to be actually written in Python. Sometimes you want to understand how code works or what it does or simply to learn from it. (Or sometimes, to rip bits off.) Then it's frustrating when you come up against a dead-end so quickly. Because the real meat isn't in Python at all. Actually, you're doing a good job of arguing for not doing using Python for real coding! Apart from just launching tasks. > Not that it matters, when you release BartC or whatever you call your > language it'll take over the world, so I'm looking forward to dropping > Python. What is the release date? (A first version might have been around 1986. I can't remember exactly. Perhaps you think this is vapourware? It's not a commercial product at the minute, just a hobby. Originally it was a scripting language for a commercial app of mine.) > Could it be the same as that for > Performance wise will it be tested > against real world benchmarks or microbechmarks? (The byte-code compiler for the current version is written in itself. It can compile itself (some 25Kloc) in about 1 second (that's running interpreted, dynamic byte-code on a not-very-fast PC). The interpreter for the byte-code is also written in another language of mine, which statically typed. The compiler for the latter is written in the interpreted language too. I'd quite like to port either of these compilers to Python, to see what PyPy can do with them. (It would also be quite cool to have them in pure Python). But I've find these difficult to optimise, because they have diverse execution patterns, while PyPy likes loops. I'll see. A compiler is another good 'pure language' task because, apart from input and output at each end, all the computation is self-contained.) > Python 2.8 or RickedPython? Will the unicode handling be better than > that of the dread Python 3.3+, PEP393 Flexible String Representation > as repeatedly pointed out by the RUE? I'm not much interested in Unicode at the minute. I'll pass. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-09 23:35 +0000 |
| Message-ID | <mailman.98.1457566570.15725.python-list@python.org> |
| In reply to | #104455 |
On 09/03/2016 23:14, BartC wrote: > On 09/03/2016 21:13, Mark Lawrence wrote: >> On 09/03/2016 12:02, BartC wrote: >>> On 09/03/2016 08:40, Mark Lawrence wrote: >>> >>> Here's another: you have a program in Python that you'd quite like to >>> port to another dynamic language. Transcribing actual Python code is >>> straightforward. Until you come to an import of a module that you can't >>> find, because it's not written in Python. Now what? Now, you might >>> appreciate the advantage of a program in 100% pure Python. >>> >> >> That is not Python's problem, or my problem, that is your problem. > > Maybe that's not the best example of why someone might prefer a 'Python' > program to be actually written in Python. Sometimes you want to > understand how code works or what it does or simply to learn from it. > (Or sometimes, to rip bits off.) Then it's frustrating when you come up > against a dead-end so quickly. Because the real meat isn't in Python at > all. > > Actually, you're doing a good job of arguing for not doing using Python > for real coding! Apart from just launching tasks. > >> Not that it matters, when you release BartC or whatever you call your >> language it'll take over the world, so I'm looking forward to dropping >> Python. What is the release date? > > (A first version might have been around 1986. I can't remember exactly. > Perhaps you think this is vapourware? It's not a commercial product at > the minute, just a hobby. Originally it was a scripting language for a > commercial app of mine.) > >> Could it be the same as that for >> Performance wise will it be tested >> against real world benchmarks or microbechmarks? > > (The byte-code compiler for the current version is written in itself. It > can compile itself (some 25Kloc) in about 1 second (that's running > interpreted, dynamic byte-code on a not-very-fast PC). Please answer my question, will it be tested against real world benchmarks or microbenchmarks? The above paragraph, and several following paragraphs, are completely irrelevant. > > The interpreter for the byte-code is also written in another language of > mine, which statically typed. The compiler for the latter is written in > the interpreted language too. > > I'd quite like to port either of these compilers to Python, to see what > PyPy can do with them. (It would also be quite cool to have them in pure > Python). But I've find these difficult to optimise, because they have > diverse execution patterns, while PyPy likes loops. I'll see. > > A compiler is another good 'pure language' task because, apart from > input and output at each end, all the computation is self-contained.) I've no idea what this is meant to mean. > > > Python 2.8 or RickedPython? Will the unicode handling be better than > > that of the dread Python 3.3+, PEP393 Flexible String Representation > > as repeatedly pointed out by the RUE? > > I'm not much interested in Unicode at the minute. I'll pass. > Your final comment sums up perfectly your knowledge of computing in 2016. I find it fitting that something so funny is put forward on the Python mailing list/news group/whatever, given the derivation of the name Python. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 00:58 +0000 |
| Message-ID | <nbqgmi$mha$1@dont-email.me> |
| In reply to | #104456 |
On 09/03/2016 23:35, Mark Lawrence wrote: > On 09/03/2016 23:14, BartC wrote: >> (The byte-code compiler for the current version is written in itself. It >> can compile itself (some 25Kloc) in about 1 second (that's running >> interpreted, dynamic byte-code on a not-very-fast PC). > > Please answer my question, will it be tested against real world > benchmarks or microbenchmarks? The above paragraph, and several > following paragraphs, are completely irrelevant. You think a bloody great compiler is a microbenchmark?! >> A compiler is another good 'pure language' task because, apart from >> input and output at each end, all the computation is self-contained.) > > I've no idea what this is meant to mean. It means the task doesn't do any function calls to external libraries. If you're benchmarking, that's usually what you want. >> I'm not much interested in Unicode at the minute. I'll pass. > Your final comment sums up perfectly your knowledge of computing in > 2016. You're utterly determined to belittle everything I do aren't you! But, yeah, I was writing international applications decades ago. I'm not working for anyone now and don't need to bother. From what I've seen, a lot of software can't get it right anyway. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-10 12:28 +1100 |
| Message-ID | <mailman.102.1457573344.15725.python-list@python.org> |
| In reply to | #104461 |
On Thu, Mar 10, 2016 at 11:58 AM, BartC <bc@freeuk.com> wrote: >>> I'm not much interested in Unicode at the minute. I'll pass. > > >> Your final comment sums up perfectly your knowledge of computing in >> 2016. > > > You're utterly determined to belittle everything I do aren't you! > > But, yeah, I was writing international applications decades ago. I'm not > working for anyone now and don't need to bother. > > From what I've seen, a lot of software can't get it right anyway. That would be because a lot of software is written by people who don't understand Unicode. "But other people get it wrong too!" wasn't a valid excuse when I was in grade school, and it still isn't in real-world work. [1] If you are writing code in 2016 that assumes that a byte is the same thing as a character, and speak as if this is alright, then yes, we WILL belittle you for it. It's on par with thinking that an integer is a 16-bit signed two's complement number. Sure, back in the 1990s, you could probably get away with that (and you'll find a lot of games that flip at 32,767 or 65,535 - or, in one that I remember, at 3,276,700!), but nobody today would let you pretend that those are identical. Neither is a list identical to a coherent block of memory (the way a C array often is implemented) - and neither is a text string identical to a stream of bytes. Even if you're restricting your text to the ASCII set, there is still an encoding involved; a typical C string's encoding is "one character per byte, followed by 0x00", whereas a Pascal string's encoding might be "one character per byte, preceded by the character count, represented in a single byte". Every encoding has consequences, every encoding has costs. You can't get away from this. You can't pretend that you don't have an encoding. ChrisA [1] Except when you're specifically writing compatibility code, where getting it identically wrong means your program successfully interoperates with someone else's buggy code. But if you're doing that, I pity you. That is not a fun job to have.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-10 07:30 +0000 |
| Message-ID | <mailman.108.1457595070.15725.python-list@python.org> |
| In reply to | #104461 |
On 10/03/2016 00:58, BartC wrote: > On 09/03/2016 23:35, Mark Lawrence wrote: >> On 09/03/2016 23:14, BartC wrote: > >>> (The byte-code compiler for the current version is written in itself. It >>> can compile itself (some 25Kloc) in about 1 second (that's running >>> interpreted, dynamic byte-code on a not-very-fast PC). >> >> Please answer my question, will it be tested against real world >> benchmarks or microbenchmarks? The above paragraph, and several >> following paragraphs, are completely irrelevant. > > You think a bloody great compiler is a microbenchmark?! I have no interest in the speed of the compiler, I am interested in the run time speed of the applications that it produces which is what has been discussed thus far. > >>> A compiler is another good 'pure language' task because, apart from >>> input and output at each end, all the computation is self-contained.) >> >> I've no idea what this is meant to mean. > > It means the task doesn't do any function calls to external libraries. Meaning that in this dreadful place called the real world it's less than useless in many cases. Why do you think there are the better part of 50,000 entries on pypi alone, some pure Python, some C extensions, presumably some a combinaton of both? > > If you're benchmarking, that's usually what you want. > >>> I'm not much interested in Unicode at the minute. I'll pass. > >> Your final comment sums up perfectly your knowledge of computing in >> 2016. > > You're utterly determined to belittle everything I do aren't you! Yes I am, as you appear to know squat. > > But, yeah, I was writing international applications decades ago. I'm not > working for anyone now and don't need to bother. So your new language doesn't bother with unicode then? > > From what I've seen, a lot of software can't get it right anyway. > Are you referring to PEP393 having taken notice of the RUE? -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 11:50 +0000 |
| Message-ID | <nbrms1$26p$1@dont-email.me> |
| In reply to | #104477 |
On 10/03/2016 07:30, Mark Lawrence wrote: > On 10/03/2016 00:58, BartC wrote: >> You think a bloody great compiler is a microbenchmark?! > > I have no interest in the speed of the compiler, I am interested in the > run time speed of the applications that it produces which is what has > been discussed thus far. Perhaps you missed the fact that this compiler is written in the very language it compiles. The code generated /is/ the application. And compilers are real applications that people use all the time. >>>> A compiler is another good 'pure language' task because, apart from >>>> input and output at each end, all the computation is self-contained.) >>> >>> I've no idea what this is meant to mean. >> >> It means the task doesn't do any function calls to external libraries. > > Meaning that in this dreadful place called the real world it's less than > useless in many cases. Suppose you were on the development team that writes the optimising stages of a C compiler. You need to test the performance of the code it produces so that you can compare one optimisation with another. Would you: (a) Test only the code that is generated by your compiler (b) Include also the runtime of third-party libraries consisting of unknown code, written in an unknown language, with an unknown compiler and with unknown optimisation settings? You seem to be suggesting that (b) is a valid way of measuring the performance of a language. > Yes I am, as you appear to know squat. I don't think I've ever traded insults on usenet or any public forum. I'm too nice a chap. But today it's rather tempting! >> But, yeah, I was writing international applications decades ago. I'm not >> working for anyone now and don't need to bother. > > So your new language doesn't bother with unicode then? Yes, it has provision for it. But I've not got round to implementing it. Other things have more priority. Or are more interesting. As I said, I've had all that fun before. If I desperately needed to use Unicode today, then something can be arranged either with the language or around it. It's not a big deal. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-10 12:15 +0000 |
| Message-ID | <mailman.123.1457612163.15725.python-list@python.org> |
| In reply to | #104503 |
On 10/03/2016 11:50, BartC wrote: > On 10/03/2016 07:30, Mark Lawrence wrote: >> On 10/03/2016 00:58, BartC wrote: > >>> You think a bloody great compiler is a microbenchmark?! >> >> I have no interest in the speed of the compiler, I am interested in the >> run time speed of the applications that it produces which is what has >> been discussed thus far. > > Perhaps you missed the fact that this compiler is written in the very > language it compiles. The code generated /is/ the application. And > compilers are real applications that people use all the time. > >>>>> A compiler is another good 'pure language' task because, apart from >>>>> input and output at each end, all the computation is self-contained.) >>>> >>>> I've no idea what this is meant to mean. >>> >>> It means the task doesn't do any function calls to external libraries. >> >> Meaning that in this dreadful place called the real world it's less than >> useless in many cases. > > Suppose you were on the development team that writes the optimising > stages of a C compiler. You need to test the performance of the code it > produces so that you can compare one optimisation with another. Would you: > > (a) Test only the code that is generated by your compiler > > (b) Include also the runtime of third-party libraries consisting of > unknown code, written in an unknown language, with an unknown compiler > and with unknown optimisation settings? What has an optimising C compiler got to do with the run time speed of Python, which in many cases is perfectly adequate? I'll repeat for possibly the fourth time, the vast majority of people have no interest in run time speed as they are fully aware that they'll be wasting their precious development time, as they know that their code will be waiting on the file, the database or the network. What have you failed to grasp about that? > > You seem to be suggesting that (b) is a valid way of measuring the > performance of a language. > >> Yes I am, as you appear to know squat. > > I don't think I've ever traded insults on usenet or any public forum. > I'm too nice a chap. But today it's rather tempting! > >>> But, yeah, I was writing international applications decades ago. I'm not >>> working for anyone now and don't need to bother. >> >> So your new language doesn't bother with unicode then? > > Yes, it has provision for it. But I've not got round to implementing it. > Other things have more priority. Or are more interesting. As I said, > I've had all that fun before. > > If I desperately needed to use Unicode today, then something can be > arranged either with the language or around it. It's not a big deal. > Laughable. It's 2016, but "then something can be arranged either with the language or around it". It's not what you personally want, it's what the entire world wants. If you think that your language is going to take over the world without unicode support, just because it's faster than Python, I seriously suggest that you see a trick cyclist, and rather quickly. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 12:47 +0000 |
| Message-ID | <nbrq7b$eeu$1@dont-email.me> |
| In reply to | #104506 |
On 10/03/2016 12:15, Mark Lawrence wrote: > On 10/03/2016 11:50, BartC wrote: >> Suppose you were on the development team that writes the optimising >> stages of a C compiler. You need to test the performance of the code it >> produces so that you can compare one optimisation with another. Would >> you: >> >> (a) Test only the code that is generated by your compiler >> >> (b) Include also the runtime of third-party libraries consisting of >> unknown code, written in an unknown language, with an unknown compiler >> and with unknown optimisation settings? > > What has an optimising C compiler got to do with the run time speed of > Python, which in many cases is perfectly adequate? > I'll repeat for > possibly the fourth time, the vast majority of people The vast majority aren't implementing the language! > have no interest > in run time speed as they are fully aware that they'll be wasting their > precious development time, as they know that their code will be waiting > on the file, the database or the network. What have you failed to grasp > about that? Tell that to the people who have been working on optimising compilers for the last couple of decades. Why bother making that inner loop 10% faster, when the program will most likely be blocked waiting for input anyway? You just don't get it. (BTW next you have have a look at the CPython source code, count how many times the words 'fast', 'faster' and 'fastest' occur. It obviously was a preoccupation with the implementers. If Python is currently fast enough for you, then thank those people who didn't just shrug their shoulders and not bother!)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-11 00:08 +1100 |
| Message-ID | <mailman.127.1457615320.15725.python-list@python.org> |
| In reply to | #104509 |
On Thu, Mar 10, 2016 at 11:47 PM, BartC <bc@freeuk.com> wrote: >> have no interest >> in run time speed as they are fully aware that they'll be wasting their >> precious development time, as they know that their code will be waiting >> on the file, the database or the network. What have you failed to grasp >> about that? > > > Tell that to the people who have been working on optimising compilers for > the last couple of decades. Why bother making that inner loop 10% faster, > when the program will most likely be blocked waiting for input anyway? > > You just don't get it. > Both of you "just don't get" something that the other sees as critically important. Before this thread gets to fisticuffs, may I please summarize the points that probably nobody will concede? 1) Unicode support, intrinsic to the language, is crucial, even if BartC refuses to recognize this. Anything released beyond the confines of his personal workspace will need full Unicode support, otherwise it is a problem to the rest of the world, and should be destroyed with fire. Thanks. 2) Interpreter performance, and the performance of code emitted by a compiler (distinct from "compiler performance" which would be how quickly it can compile code) makes a huge difference to real-world applications, even if MarkL refuses to recognize this. While it doesn't hurt the rest of the world to have a slow implementation of a language, it does _benefit_ the world to have a _faster_ implementation, as long as that doesn't come at unnecessary costs. 3) There is a point at which performance ceases to matter for a given application. This point varies from app to app, but generally is reached when I/O wait time dwarfs CPU usage. A language which has reached this point for the majority of applications can be said to be "fast enough", not because its developers do not care about performance (particularly regressions), and not because further improvements are useless, but because there are other considerations more important than pure run-time speed. 4) Burying the bulk of something away in external API calls is a great way to make the real performance improve, but makes performance *measurement* harder. This matters to benchmarking and to real-world usage in different (almost, but not entirely, contradictory) ways. When people want better performance out of a number-crunching Python program, they have a few options. One is to rewrite their code in C or Fortran or something. Another is to make small tweaks so the bulk of the work is handled by numpy or Cython. A third is to keep their code completely unchanged, but run it under PyPy instead of whatever they were previously using (probably CPython). Generally, rewriting in C/Fortran is generally a bad idea; you pay the price over the whole application, when optimizing a small subset of it would give 99% of the performance improvement. That's why actual CPython byte-code interpretation performance isn't so critical; if we can change 5% of the code so it uses numpy, we keep 95% of it in idiomatic Python, while still having the bulk of the work done in Fortran. CPython has other priorities than performance - not to say that "slow is fine", but more that "slow and dynamic opens up possibilities that fast and static precludes, so we're happy to pay the price for the features we want". ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 14:22 +0000 |
| Message-ID | <nbrvpj$5lm$1@dont-email.me> |
| In reply to | #104512 |
On 10/03/2016 13:08, Chris Angelico wrote: > On Thu, Mar 10, 2016 at 11:47 PM, BartC <bc@freeuk.com> wrote: >> You just don't get it. > > Both of you "just don't get" something that the other sees as > critically important. Before this thread gets to fisticuffs, may I > please summarize the points that probably nobody will concede? > > 1) Unicode support, intrinsic to the language, is crucial, even if > BartC refuses to recognize this. Anything released beyond the confines > of his personal workspace will need full Unicode support, otherwise it > is a problem to the rest of the world, and should be destroyed with > fire. Thanks. I don't agree. If I distribute some text in the form of a series of ASCII byte values (eg. classic TXT format, with either kind of line separator), then that same data can be directly interpreted as UTF-8. (And as you know, the first 128 Unicode code points correspond with the 128 ASCII codes. Widening such a data-set so that each 8-bit character becomes 32-bit will also give you a set of Unicode code-points.) Importing a text file from elsewhere is a different problem of course. Although out of the thousands of times I must have done this, Unicode-related issues have been minimal. > 3) There is a point at which performance ceases to matter for a given > application. This point varies from app to app, but generally is > reached when I/O wait time dwarfs CPU usage. Also when the total runtime is negligible anyway. It doesn't matter if a program takes 200msec instead of 20msec. (Unless millions of such tasks are scheduled.) > When people want better performance out of a number-crunching Python > program, they have a few options. One is to rewrite their code in C or > Fortran or something. Another is to make small tweaks so the bulk of > the work is handled by numpy or Cython. A third is to keep their code > completely unchanged, but run it under PyPy instead of whatever they > were previously using (probably CPython). Generally, rewriting in > C/Fortran is generally a bad idea; you pay the price over the whole > application, when optimizing a small subset of it would give 99% of > the performance improvement. That's why actual CPython byte-code > interpretation performance isn't so critical; if we can change 5% of > the code so it uses numpy, we keep 95% of it in idiomatic Python, > while still having the bulk of the work done in Fortran. CPython has > other priorities than performance - not to say that "slow is fine", > but more that "slow and dynamic opens up possibilities that fast and > static precludes, so we're happy to pay the price for the features we > want". Generally agree. But also, I often develop an algorithm using a dynamic language, because it's much easier and quicker to try out different things, before porting the result to a static language. But during development, it doesn't hurt if the dynamic version isn't quite so slow! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-10 19:26 +0000 |
| Message-ID | <mailman.149.1457638067.15725.python-list@python.org> |
| In reply to | #104524 |
On 10/03/2016 14:22, BartC wrote: > > But during development, it doesn't hurt if the dynamic version isn't > quite so slow! > In [1]: import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! No mention of speed anywhere, but then what does that silly old Tim Peters know about anything? -- 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 | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-11 16:29 +1100 |
| Message-ID | <56e2579e$0$1608$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104545 |
On Fri, 11 Mar 2016 06:26 am, Mark Lawrence wrote: > On 10/03/2016 14:22, BartC wrote: > >> >> But during development, it doesn't hurt if the dynamic version isn't >> quite so slow! >> > > In [1]: import this > The Zen of Python, by Tim Peters [...] > No mention of speed anywhere, but then what does that silly old Tim > Peters know about anything? The Zen of Python doesn't say anything about being an argumentative, obnoxious, annoying zealot either, and yet here we are... What is your problem? By your aggressive nay-saying, anyone would think that having a fast, efficient programming language was *actively harmful*. If Guido announced tomorrow that Python 3.6 will include a gee-whiz new optimization that makes CPython start up in a quarter of the time and run five times as quickly with no loss or change of functionality, would you toss a hissy fit because speed isn't important? Personally, every time I have to wait five minutes for a timeit script to run, I wish Python was ten times faster. (Say, best of five, each run takes a minute.) And I absolutely stand by that: I wish Python were faster without any loss of functionality. (I also want a pony and a plastic Buddha.) Maybe if I could afford a faster computer, I would care less. Maybe if I cared more, I would decide that Python wasn't the language for me and I would prefer a language with less functionality and more speed. Either choice is fine. There's no need to aggressively hassle Bart because he cares more about speed than Python's dynamic features which he neither uses nor cares about. The truth is, most people don't -- most Python code uses very little of the dynamic features that get in the way of optimizing the interpreter, things like intentionally shadowing or monkey-patching built-ins, adding attributes to objects on the fly, or using exec and eval. In my dream language, I wish that there were a way to tell the compiler "this is code (function, class, module) is not dynamic, optimize it as much as you can". Or better still, for the compiler itself to recognise when code is static, and optimize it. Victor Stinner's FAT Python may be that compiler some day, and I for one can't wait. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-11 18:57 +0000 |
| Message-ID | <nbv496$e8q$1@dont-email.me> |
| In reply to | #104583 |
On 11/03/2016 05:29, Steven D'Aprano wrote: > On Fri, 11 Mar 2016 06:26 am, Mark Lawrence wrote: >> No mention of speed anywhere, but then what does that silly old Tim >> Peters know about anything? > The truth is, most people don't -- most Python code uses very little of the > dynamic features that get in the way of optimizing the interpreter, things > like intentionally shadowing or monkey-patching built-ins, adding > attributes to objects on the fly, or using exec and eval. In my dream > language, I wish that there were a way to tell the compiler "this is code > (function, class, module) is not dynamic, optimize it as much as you can". The problem is the compiler has to have sight of the code for that to work. That means looking inside an imported module, which I think doesn't happen when running the byte-code compiler, but executing the resulting byte-code. Anyway, I've listed some of the stumbling blocks I think that Python has in making it bit faster: http://pastebin.com/WfUfK3bc Solving all that won't magically make it a magnitude quicker, but noticeably brisker. And could open the way for further speed-ups. Unfortunately you can't these issues without radical changes to the language ... > Or better still, for the compiler itself to recognise when code is static, > and optimize it. Victor Stinner's FAT Python may be that compiler some day, > and I for one can't wait. ... unless you take the complicated approach as this project seems to! (Mine would be to design the language to be less dynamic in the first place.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-11 21:59 +0000 |
| Message-ID | <mailman.10.1457733601.12893.python-list@python.org> |
| In reply to | #104626 |
On 11/03/2016 18:57, BartC wrote:
>
> Anyway, I've listed some of the stumbling blocks I think that Python has
> in making it bit faster: http://pastebin.com/WfUfK3bc
<quote>
The String Append Benchmark
This is a microbenchmark, but makes use of a technique I use extensively
(creating a file for example by growing a string a character at a time).
def test():
s=""
for i in range(10000000):
s+="*"
print (len(s))
test()
</quote>
The minor snag that you might like to correct with your microbenchmark,
which any experienced Python programmer knows, is that you *NEVER, EVER*
create strings like this. Given that you've admitted earlier today that
you couldn't get a simple slice to work, how much, if anything, do you
actually know about Python?
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-11 22:24 +0000 |
| Message-ID | <nbvgds$ed$1@dont-email.me> |
| In reply to | #104649 |
On 11/03/2016 21:59, Mark Lawrence wrote: > On 11/03/2016 18:57, BartC wrote: > def test(): > s="" > for i in range(10000000): > s+="*" > print (len(s)) > > test() > The minor snag that you might like to correct with your microbenchmark, > which any experienced Python programmer knows, is that you *NEVER, EVER* > create strings like this. Why not? Chris said his version runs much faster (even allowing for different machines), and might have a special optimisation for it. And I think it can be optimised if, for example, there are no other references to the string that s refers to. So what's wrong with trying to fix it rather that using a workaround? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-12 16:59 +1100 |
| Message-ID | <56e3b05b$0$22142$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104654 |
On Sat, 12 Mar 2016 12:10 pm, Dennis Lee Bieber wrote: > On Fri, 11 Mar 2016 22:24:45 +0000, BartC <bc@freeuk.com> declaimed the > following: > >>On 11/03/2016 21:59, Mark Lawrence wrote: >>> On 11/03/2016 18:57, BartC wrote: >> >>> def test(): >>> s="" >>> for i in range(10000000): >>> s+="*" >>> print (len(s)) >>> >>> test() >> >>> The minor snag that you might like to correct with your microbenchmark, >>> which any experienced Python programmer knows, is that you *NEVER, EVER* >>> create strings like this. >> >>Why not? Chris said his version runs much faster (even allowing for >>different machines), and might have a special optimisation for it. >> > > Everytime that += is executed, Python has to allocate a new chunk of > memory equal (minimum -- it may chunk larger) to the combined length of > "s" and "*", COPY the bytes/characters from "s" into the new memory chunk, > copy the "*" into the end of the new memory chunk, bind the name "s" to > the new chunk, and likely deallocate the old memory chunk that used to be > bound to "s". Sometimes. What you say is true in Jython and IronPython. And it was always true in CPython until version 2.3. And it is sometimes true in CPython even today. But since Python 2.3, CPython is smart enough to recognise when a string has only one reference to it, and, *if possible*, resize it in place. This optimization seems to work well under Linux, but unfortunately due to the vagaries of how memory is managed by the OS, it seems to often fail under Windows, so Python will fall back to the slow copy-and-append implementation. [...] > The common recommendation is to accumulate the substrings into a LIST > structure (while the list will undergo resizing, that is done at a fairly > well-understood rate, and only requires copying of references to the > substrings, not the strings themselves). At the end, one invokes .join() > on the list. .join() can scan the list elements summing the lengths of the > substrings, allocate ONCE the memory to hold the result, and only then > copy the substrings into the result string. This remains the best advice for assembling strings from a large number of small pieces. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2016-03-12 10:06 +0000 |
| Message-ID | <MSREy.1473117$wX5.1467333@fx40.am4> |
| In reply to | #104654 |
On Fri, 11 Mar 2016 22:24:45 +0000, BartC wrote: > On 11/03/2016 21:59, Mark Lawrence wrote: >> On 11/03/2016 18:57, BartC wrote: > >> def test(): >> s="" >> for i in range(10000000): >> s+="*" >> print (len(s)) >> >> test() > >> The minor snag that you might like to correct with your microbenchmark, >> which any experienced Python programmer knows, is that you *NEVER, >> EVER* >> create strings like this. > > Why not? Chris said his version runs much faster (even allowing for > different machines), and might have a special optimisation for it. > > And I think it can be optimised if, for example, there are no other > references to the string that s refers to. > > So what's wrong with trying to fix it rather that using a workaround? because the "workarround" is not a workarround it is the correct way to do it the code above is a workarround for somone who does not know the pythonic method to do this S= "*"*10000000 -- A little kid went up to Santa and asked him, "Santa, you know when I'm bad right?" And Santa says, "Yes, I do." The little kid then asks, "And you know when I'm sleeping?" To which Santa replies, "Every minute." So the little kid then says, "Well, if you know when I'm bad and when I'm good, then how come you don't know what I want for Christmas?"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 10:31 +0000 |
| Message-ID | <nc0r0q$srq$1@dont-email.me> |
| In reply to | #104684 |
On 12/03/2016 10:06, alister wrote: > On Fri, 11 Mar 2016 22:24:45 +0000, BartC wrote: > >> On 11/03/2016 21:59, Mark Lawrence wrote: >>> On 11/03/2016 18:57, BartC wrote: >> >>> def test(): >>> s="" >>> for i in range(10000000): >>> s+="*" >>> print (len(s)) >>> >>> test() >> >>> The minor snag that you might like to correct with your microbenchmark, >>> which any experienced Python programmer knows, is that you *NEVER, >>> EVER* >>> create strings like this. >> >> Why not? Chris said his version runs much faster (even allowing for >> different machines), and might have a special optimisation for it. >> >> And I think it can be optimised if, for example, there are no other >> references to the string that s refers to. >> >> So what's wrong with trying to fix it rather that using a workaround? > > because the "workarround" is not a workarround it is the correct way to > do it > the code above is a workarround for somone who does not know the pythonic > method to do this > > S= "*"*10000000 This is a benchmark that measures the cost of adding to a string a character at a time. In practice the final length of the string is not known, and the characters added at each stage are not known. Although the strings won't usually be that big; the benchmark exaggerates here to highlight a possible issue with += on strings. And it worked, as there can be big difference with or without the += optimisation in place. It also showed a possible bug or problem with PyPy. You can't demonstrate all this by just writing s="*"*10000000. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-12 10:51 +0000 |
| Message-ID | <mailman.33.1457779939.12893.python-list@python.org> |
| In reply to | #104686 |
On 12/03/2016 10:31, BartC wrote: > On 12/03/2016 10:06, alister wrote: >> On Fri, 11 Mar 2016 22:24:45 +0000, BartC wrote: >> >>> On 11/03/2016 21:59, Mark Lawrence wrote: >>>> On 11/03/2016 18:57, BartC wrote: >>> >>>> def test(): >>>> s="" >>>> for i in range(10000000): >>>> s+="*" >>>> print (len(s)) >>>> >>>> test() >>> >>>> The minor snag that you might like to correct with your microbenchmark, >>>> which any experienced Python programmer knows, is that you *NEVER, >>>> EVER* >>>> create strings like this. >>> >>> Why not? Chris said his version runs much faster (even allowing for >>> different machines), and might have a special optimisation for it. >>> >>> And I think it can be optimised if, for example, there are no other >>> references to the string that s refers to. >>> >>> So what's wrong with trying to fix it rather that using a workaround? >> >> because the "workarround" is not a workarround it is the correct way to >> do it >> the code above is a workarround for somone who does not know the pythonic >> method to do this >> >> S= "*"*10000000 > > This is a benchmark that measures the cost of adding to a string a > character at a time. > > In practice the final length of the string is not known, and the > characters added at each stage are not known. > > Although the strings won't usually be that big; the benchmark > exaggerates here to highlight a possible issue with += on strings. And > it worked, as there can be big difference with or without the += > optimisation in place. > > It also showed a possible bug or problem with PyPy. > > You can't demonstrate all this by just writing s="*"*10000000. > There is no possible issue with += on strings, there is a known issue. What to do about has all ready been discussed by myself, Dennis Lee Bieber, Michael Torrie and Steven D'Aprano, but you've chosen to ignore what we've written. -- 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 | alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2016-03-12 15:36 +0000 |
| Message-ID | <aIWEy.1472685$AB2.92779@fx39.am4> |
| In reply to | #104686 |
On Sat, 12 Mar 2016 10:31:39 +0000, BartC wrote: > On 12/03/2016 10:06, alister wrote: >> On Fri, 11 Mar 2016 22:24:45 +0000, BartC wrote: >> >>> On 11/03/2016 21:59, Mark Lawrence wrote: >>>> On 11/03/2016 18:57, BartC wrote: >>> >>>> def test(): >>>> s="" >>>> for i in range(10000000): >>>> s+="*" >>>> print (len(s)) >>>> >>>> test() >>> >>>> The minor snag that you might like to correct with your >>>> microbenchmark, >>>> which any experienced Python programmer knows, is that you *NEVER, >>>> EVER* >>>> create strings like this. >>> >>> Why not? Chris said his version runs much faster (even allowing for >>> different machines), and might have a special optimisation for it. >>> >>> And I think it can be optimised if, for example, there are no other >>> references to the string that s refers to. >>> >>> So what's wrong with trying to fix it rather that using a workaround? >> >> because the "workarround" is not a workarround it is the correct way to >> do it the code above is a workarround for somone who does not know the >> pythonic method to do this >> >> S= "*"*10000000 > > This is a benchmark that measures the cost of adding to a string a > character at a time. > > In practice the final length of the string is not known, and the > characters added at each stage are not known. > > Although the strings won't usually be that big; the benchmark > exaggerates here to highlight a possible issue with += on strings. And > it worked, as there can be big difference with or without the += > optimisation in place. > > It also showed a possible bug or problem with PyPy. > > You can't demonstrate all this by just writing s="*"*10000000. So you are bench marking python performance on a programming paradigm that is not good python practice. A pointless exercise what may be the best way to achieve a rsult in one language is not necessarily the best way to achieve it in another. if you wish to compare performance between one versio of python and another at least try to start with pythonic code -- There are two ways of disliking poetry; one way is to dislike it, the other is to read Pope. -- Oscar Wilde
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web