Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #41834 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2013-03-26 08:51 +1100 |
| Last post | 2013-03-28 12:39 +0000 |
| Articles | 20 on this page of 206 — 30 participants |
Back to article view | Back to comp.lang.python
Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 08:51 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-25 23:35 +0000
Re: Performance of int/long in Python 3 Dan Stromberg <drsalists@gmail.com> - 2013-03-25 17:12 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 17:26 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-26 13:38 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 01:08 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-26 16:41 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 03:54 +1100
Re: Performance of int/long in Python 3 Terry Reedy <tjreedy@udel.edu> - 2013-03-26 14:24 -0400
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-26 11:50 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 06:03 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-26 13:44 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-26 20:50 +0000
Re: Performance of int/long in Python 3 Grant Edwards <invalid@invalid.invalid> - 2013-03-26 21:08 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 08:14 +1100
Re: Performance of int/long in Python 3 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-03-27 12:10 +1300
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-03-26 19:19 -0400
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-26 21:26 +0000
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-03-26 17:28 -0400
Re: Performance of int/long in Python 3 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-03-26 23:14 -0400
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-27 13:30 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 07:52 +1100
Re: Performance of int/long in Python 3 Ned Deily <nad@acm.org> - 2013-03-26 17:00 -0700
Re: Performance of int/long in Python 3 rurpy@yahoo.com - 2013-03-26 21:31 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-27 00:20 +0000
Re: Performance of int/long in Python 3 Ned Deily <nad@acm.org> - 2013-03-26 18:31 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-27 11:51 +0000
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 01:47 +0000
flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-27 20:18 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rusi <rustompmody@gmail.com> - 2013-03-27 20:49 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 05:20 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rusi <rustompmody@gmail.com> - 2013-03-27 22:42 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 07:48 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rurpy@yahoo.com - 2013-03-28 12:54 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-28 13:31 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Grant Edwards <invalid@invalid.invalid> - 2013-03-29 14:52 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-29 08:51 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Grant Edwards <invalid@invalid.invalid> - 2013-03-29 16:50 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rurpy@yahoo.com - 2013-03-29 14:26 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-29 16:07 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-31 00:35 -0700
ASCII versus non-ASCII [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-31 08:22 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-31 13:55 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-03-31 22:33 -0700
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-31 23:52 -0600
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-01 16:57 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 08:14 +0000
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-01 08:15 -0400
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-01 06:11 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 17:02 +0000
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 17:07 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 04:20 +1100
Re: Performance of int/long in Python 3 MRAB <python@mrabarnett.plus.com> - 2013-04-01 18:53 +0100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-01 12:15 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 06:28 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-01 13:28 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 07:35 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 22:38 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 22:43 +0100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-02 10:43 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 00:24 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 19:03 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-02 08:35 +0000
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 02:24 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 10:43 +0100
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 11:58 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 06:42 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-02 14:03 +0000
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 15:39 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 16:02 +0100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 08:12 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 16:43 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 10:08 -0700
Re: Performance of int/long in Python 3 Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-02 17:33 -0400
Re: Performance of int/long in Python 3 Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-02 23:40 +0100
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-02 08:09 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 15:12 +0100
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 16:03 +0100
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-02 08:17 -0700
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 09:57 -0700
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 11:22 -0700
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 11:50 -0700
Re: Performance of int/long in Python 3 Lele Gaifax <lele@metapensiero.it> - 2013-04-03 00:52 +0200
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 02:20 -0700
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-02 13:44 -0600
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 14:31 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 20:53 -0700
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 15:03 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 22:11 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:22 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:28 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 00:38 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 00:10 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 19:15 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:25 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 00:34 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 05:32 +0000
Re: Performance of int/long in Python 3 Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-03 02:19 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 17:27 +1100
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:25 +1100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 17:29 +1100
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:52 +1100
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 01:06 -0600
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 18:24 +1100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 18:37 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-03 01:07 -0700
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 19:22 +1100
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 06:20 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 22:05 +1100
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 07:52 -0400
Sorting [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 14:43 +0000
Re: Sorting [was Re: Performance of int/long in Python 3] Roy Smith <roy@panix.com> - 2013-04-03 11:00 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:30 -0600
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 13:51 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-04 09:58 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 07:53 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 19:02 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-03 01:08 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 12:27 +0100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:43 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 01:17 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 15:07 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 08:57 +1100
Re: Performance of int/long in Python 3 Serhiy Storchaka <storchaka@gmail.com> - 2013-04-06 12:09 +0300
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-07 07:24 +1000
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-06 14:58 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:29 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 19:58 -0600
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-06 22:18 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 23:22 -0600
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 08:29 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 20:00 -0600
Re: Performance of int/long in Python 3 Serhiy Storchaka <storchaka@gmail.com> - 2013-04-07 11:02 +0300
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-07 16:14 +0100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 15:02 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:38 -0600
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 17:43 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 08:55 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 23:39 +0100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 20:49 -0400
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-03 09:10 -0700
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-03 10:09 -0700
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 20:46 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:53 -0600
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-02 20:28 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 14:56 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 20:54 +0100
Re: Performance of int/long in Python 3 roy@panix.com (Roy Smith) - 2013-04-01 16:31 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 00:35 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 21:22 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ned Deily <nad@acm.org> - 2013-03-28 13:23 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-27 23:12 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 02:03 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Foote <ian@feete.org> - 2013-03-28 09:36 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-28 23:11 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 13:01 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 07:12 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 01:38 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 08:14 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 02:21 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 08:45 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Terry Reedy <tjreedy@udel.edu> - 2013-03-28 12:01 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:11 -0600
Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 00:39 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 11:54 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 02:37 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 13:44 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-29 00:11 -0600
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-29 00:22 -0600
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Terry Reedy <tjreedy@udel.edu> - 2013-03-29 14:06 -0400
Re: Surrogate pairs in new flexible string representation Christian Heimes <christian@python.org> - 2013-03-29 23:05 +0100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-29 01:03 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 12:10 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] MRAB <python@mrabarnett.plus.com> - 2013-03-29 02:00 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 03:16 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:01 -0600
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 14:34 +1100
unicode and the FSR [was: Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ethan Furman <ethan@stoneleaf.us> - 2013-03-28 21:56 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 16:33 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 16:46 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] MRAB <python@mrabarnett.plus.com> - 2013-03-28 14:51 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 14:57 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 02:07 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-03-28 09:47 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 21:30 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 06:34 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:33 -0600
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 09:55 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 04:13 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 10:48 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 04:55 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 13:26 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 08:45 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Terry Reedy <tjreedy@udel.edu> - 2013-03-28 19:12 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-03-28 13:29 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 14:11 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 14:33 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] MRAB <python@mrabarnett.plus.com> - 2013-03-28 21:50 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-03-28 14:52 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-03-28 19:53 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 11:03 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-29 00:15 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 14:40 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] 88888 Dihedral <dihedral88888@googlemail.com> - 2013-03-28 16:04 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] 88888 Dihedral <dihedral88888@googlemail.com> - 2013-03-28 16:04 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-28 12:39 +0000
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 17:29 +1100 |
| Message-ID | <iaadnbgQ-smCUMbMnZ2dnUVZ_qydnZ2d@westnet.com.au> |
| In reply to | #42633 |
Chris Angelico:
> I'd be curious to know the sorts of characters used. Given that it's
> probably a narrow-vs-wide Python difference we're talking here, the
> actual distribution of codepoints may well make a difference.
I was going to upload it but then I thought of potential client
-confidentiality problems and the need to audit a list that long.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-03 17:52 +1100 |
| Message-ID | <mailman.39.1364971944.3114.python-list@python.org> |
| In reply to | #42635 |
On Wed, Apr 3, 2013 at 5:29 PM, Neil Hodgson <nhodgson@iinet.net.au> wrote: > Chris Angelico: > > >> I'd be curious to know the sorts of characters used. Given that it's >> probably a narrow-vs-wide Python difference we're talking here, the >> actual distribution of codepoints may well make a difference. > > > I was going to upload it but then I thought of potential client > -confidentiality problems and the need to audit a list that long. Hmm. I was about to say "Can you just do a quick collections.Counter() of the string widths in 3.3, as an easy way of seeing which ones use BMP or higher characters", but I can't find a simple way to query a string's width. Can't see it as a method of the string object, nor in the string or sys modules. It ought to be easy enough at the C level - just look up the two bits representing 'kind' - but I've not found it exposed to Python. Is there anything? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-03 01:06 -0600 |
| Message-ID | <mailman.40.1364972837.3114.python-list@python.org> |
| In reply to | #42635 |
On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico <rosuav@gmail.com> wrote: > Hmm. I was about to say "Can you just do a quick collections.Counter() > of the string widths in 3.3, as an easy way of seeing which ones use > BMP or higher characters", but I can't find a simple way to query a > string's width. Can't see it as a method of the string object, nor in > the string or sys modules. It ought to be easy enough at the C level - > just look up the two bits representing 'kind' - but I've not found it > exposed to Python. Is there anything? 4 if max(map(ord, s)) > 0xffff else 2 if max(map(ord, s)) > 0xff else 1
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-03 18:24 +1100 |
| Message-ID | <mailman.41.1364973874.3114.python-list@python.org> |
| In reply to | #42635 |
On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico <rosuav@gmail.com> wrote: >> Hmm. I was about to say "Can you just do a quick collections.Counter() >> of the string widths in 3.3, as an easy way of seeing which ones use >> BMP or higher characters", but I can't find a simple way to query a >> string's width. Can't see it as a method of the string object, nor in >> the string or sys modules. It ought to be easy enough at the C level - >> just look up the two bits representing 'kind' - but I've not found it >> exposed to Python. Is there anything? > > 4 if max(map(ord, s)) > 0xffff else 2 if max(map(ord, s)) > 0xff else 1 Yeah, that's iterating over the whole string (twice, if it isn't width 4). The system already knows what the size is, I was hoping for an uber-quick inspection of the string header. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 18:37 +1100 |
| Message-ID | <Y9SdnZYmE9t4QcbMnZ2dnUVZ_gCdnZ2d@westnet.com.au> |
| In reply to | #42638 |
Reran the programs taking a bit more care with the encoding of the
file. This had no effect on the speeds. There are only a small amount of
paths that don't fit into ASCII:
ASCII 1076101
Latin1 218
BMP 113
Astral 0
# encoding:utf-8
import codecs, os, time
from os.path import join, getsize
with codecs.open("filelist.txt", "r", "utf-8") as f:
paths = f.read().split("\n")
bucket = [0,0,0,0]
for p in paths:
b = 0
maxChar = max([ord(ch) for ch in p])
if maxChar >= 65536:
b = 3
elif maxChar >= 256:
b = 2
elif maxChar >= 128:
b = 1
bucket[b] = bucket[b] + 1
print("ASCII", bucket[0])
print("Latin1", bucket[1])
print("BMP", bucket[2])
print("Astral", bucket[3])
Neil
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-03 01:07 -0700 |
| Message-ID | <a71c7d9b-c0c5-4c6f-ad4f-225ed7ca52aa@kw7g2000pbb.googlegroups.com> |
| In reply to | #42640 |
On Apr 3, 12:37 pm, Neil Hodgson <nhodg...@iinet.net.au> wrote:
> Reran the programs taking a bit more care with the encoding of the
> file. This had no effect on the speeds. There are only a small amount of
> paths that don't fit into ASCII:
>
> ASCII 1076101
> Latin1 218
> BMP 113
> Astral 0
>
> # encoding:utf-8
> import codecs, os, time
> from os.path import join, getsize
> with codecs.open("filelist.txt", "r", "utf-8") as f:
> paths = f.read().split("\n")
> bucket = [0,0,0,0]
> for p in paths:
> b = 0
> maxChar = max([ord(ch) for ch in p])
> if maxChar >= 65536:
> b = 3
> elif maxChar >= 256:
> b = 2
> elif maxChar >= 128:
> b = 1
> bucket[b] = bucket[b] + 1
> print("ASCII", bucket[0])
> print("Latin1", bucket[1])
> print("BMP", bucket[2])
> print("Astral", bucket[3])
>
> Neil
Can you please try one more experiment Neil?
Knock off all non-ASCII strings (paths) from your dataset and try
again.
[It should take little more than converting your above code to a
filter:
if b == 0: print
if b > 0: ignore
]
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 19:22 +1100 |
| Message-ID | <vuOdnV0t7qAPesbMnZ2dnUVZ_rednZ2d@westnet.com.au> |
| In reply to | #42643 |
rusi:
> Can you please try one more experiment Neil?
> Knock off all non-ASCII strings (paths) from your dataset and try
> again.
Results are the same 0.40 (well, 0.001 less but I don't think the
timer is that accurate) for Python 3.2 and 0.78 for Python 3.3.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-04-03 06:20 -0400 |
| Message-ID | <mailman.45.1364984455.3114.python-list@python.org> |
| In reply to | #42647 |
On 04/03/2013 04:22 AM, Neil Hodgson wrote: > rusi: > >> Can you please try one more experiment Neil? >> Knock off all non-ASCII strings (paths) from your dataset and try >> again. > > Results are the same 0.40 (well, 0.001 less but I don't think the > timer is that accurate) for Python 3.2 and 0.78 for Python 3.3. > > Neil That would seem to imply that the speed regression on your data is NOT caused by the differing size encodings. Perhaps it is the difference in MSC compiler version, or other changes made between 3.2 and 3.3 Of course, I can't then explain why Steven didn't get the same results. Perhaps the difference between 32bit Python and 64 on Windows? Or perhaps you have significantly more (or significantly fewer) "collisions" than Steven did. Before I saw this message, I was thinking of suggesting that you supply a key= parameter to sort, specifying as a key the Unicode character 65536 higher than the one supplied. That way all the keys to be sorted would be 32 bits in size. If this made the timings change noticeably, it could be a big clue. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-03 22:05 +1100 |
| Message-ID | <gcSdnY65iPFAkMHMnZ2dnUVZ_h2dnZ2d@westnet.com.au> |
| In reply to | #42650 |
Dave Angel:
> That would seem to imply that the speed regression on your data is NOT
> caused by the differing size encodings. Perhaps it is the difference in
> MSC compiler version, or other changes made between 3.2 and 3.3
Its not caused by there actually being different size encodings but
that the code is checking encoding size 2-4 times for each character.
Back in 3.2 the comparison loop looked like:
while (len1 > 0 && len2 > 0) {
Py_UNICODE c1, c2;
c1 = *s1++;
c2 = *s2++;
if (c1 != c2)
return (c1 < c2) ? -1 : 1;
len1--; len2--;
}
For 3.3 this has changed to
for (i = 0; i < len1 && i < len2; ++i) {
Py_UCS4 c1, c2;
c1 = PyUnicode_READ(kind1, data1, i);
c2 = PyUnicode_READ(kind2, data2, i);
if (c1 != c2)
return (c1 < c2) ? -1 : 1;
}
with PyUnicode_READ being
#define PyUnicode_READ(kind, data, index) \
((Py_UCS4) \
((kind) == PyUnicode_1BYTE_KIND ? \
((const Py_UCS1 *)(data))[(index)] : \
((kind) == PyUnicode_2BYTE_KIND ? \
((const Py_UCS2 *)(data))[(index)] : \
((const Py_UCS4 *)(data))[(index)] \
) \
))
There are either 1 or 2 kind checks in each call to PyUnicode_READ
and 2 calls to PyUnicode_READ inside the loop. A compiler may decide to
move the kind checks out of the loop and specialize the loop but MSVC
2010 appears to not do so. The assembler (32-bit build) for each
PyUnicode_READ looks like
mov ecx, DWORD PTR _kind1$[ebp]
cmp ecx, 1
jne SHORT $LN17@unicode_co@2
lea ecx, DWORD PTR [ebx+eax]
movzx edx, BYTE PTR [ecx+edx]
jmp SHORT $LN16@unicode_co@2
$LN17@unicode_co@2:
cmp ecx, 2
jne SHORT $LN15@unicode_co@2
movzx edx, WORD PTR [ebx+edi]
jmp SHORT $LN16@unicode_co@2
$LN15@unicode_co@2:
mov edx, DWORD PTR [ebx+esi]
$LN16@unicode_co@2:
The kind1/kind2 variables aren't even going into registers and at
least one test+branch and a jump are executed for every character. Two
tests for 2 and 4 byte kinds. len1 and len2 don't get to go into
registers either.
Here's the full assembler output for unicode_compare:
; COMDAT _unicode_compare
_TEXT SEGMENT
_kind2$ = -20 ; size = 4
_kind1$ = -16 ; size = 4
_len2$ = -12 ; size = 4
_len1$ = -8 ; size = 4
_data2$ = -4 ; size = 4
_unicode_compare PROC ; COMDAT
; _str1$ = ecx
; _str2$ = eax
; 10417: {
push ebp
mov ebp, esp
sub esp, 20 ; 00000014H
push ebx
push esi
mov esi, eax
; 10418: int kind1, kind2;
; 10419: void *data1, *data2;
; 10420: Py_ssize_t len1, len2, i;
; 10421:
; 10422: kind1 = PyUnicode_KIND(str1);
mov eax, DWORD PTR [ecx+16]
mov edx, eax
shr edx, 2
and edx, 7
push edi
mov DWORD PTR _kind1$[ebp], edx
; 10423: kind2 = PyUnicode_KIND(str2);
mov edx, DWORD PTR [esi+16]
mov edi, edx
shr edi, 2
and edi, 7
mov DWORD PTR _kind2$[ebp], edi
; 10424: data1 = PyUnicode_DATA(str1);
test al, 32 ; 00000020H
je SHORT $LN9@unicode_co@2
test al, 64 ; 00000040H
je SHORT $LN7@unicode_co@2
lea ebx, DWORD PTR [ecx+24]
jmp SHORT $LN10@unicode_co@2
$LN7@unicode_co@2:
lea ebx, DWORD PTR [ecx+36]
jmp SHORT $LN10@unicode_co@2
$LN9@unicode_co@2:
mov ebx, DWORD PTR [ecx+36]
$LN10@unicode_co@2:
; 10425: data2 = PyUnicode_DATA(str2);
test dl, 32 ; 00000020H
je SHORT $LN13@unicode_co@2
test dl, 64 ; 00000040H
je SHORT $LN11@unicode_co@2
lea edx, DWORD PTR [esi+24]
jmp SHORT $LN30@unicode_co@2
$LN11@unicode_co@2:
lea eax, DWORD PTR [esi+36]
mov DWORD PTR _data2$[ebp], eax
mov edx, eax
jmp SHORT $LN14@unicode_co@2
$LN13@unicode_co@2:
mov edx, DWORD PTR [esi+36]
$LN30@unicode_co@2:
mov DWORD PTR _data2$[ebp], edx
$LN14@unicode_co@2:
; 10426: len1 = PyUnicode_GET_LENGTH(str1);
mov edi, DWORD PTR [ecx+8]
; 10427: len2 = PyUnicode_GET_LENGTH(str2);
mov ecx, DWORD PTR [esi+8]
; 10428:
; 10429: for (i = 0; i < len1 && i < len2; ++i) {
xor eax, eax
mov DWORD PTR _len1$[ebp], edi
mov DWORD PTR _len2$[ebp], ecx
test edi, edi
jle SHORT $LN2@unicode_co@2
; 10426: len1 = PyUnicode_GET_LENGTH(str1);
mov esi, edx
mov edi, edx
; 10428:
; 10429: for (i = 0; i < len1 && i < len2; ++i) {
sub ebx, edx
jmp SHORT $LN4@unicode_co@2
$LL28@unicode_co@2:
mov edx, DWORD PTR _data2$[ebp]
$LN4@unicode_co@2:
cmp eax, ecx
jge SHORT $LN29@unicode_co@2
; 10430: Py_UCS4 c1, c2;
; 10431: c1 = PyUnicode_READ(kind1, data1, i);
mov ecx, DWORD PTR _kind1$[ebp]
cmp ecx, 1
jne SHORT $LN17@unicode_co@2
lea ecx, DWORD PTR [ebx+eax]
movzx edx, BYTE PTR [ecx+edx]
jmp SHORT $LN16@unicode_co@2
$LN17@unicode_co@2:
cmp ecx, 2
jne SHORT $LN15@unicode_co@2
movzx edx, WORD PTR [ebx+edi]
jmp SHORT $LN16@unicode_co@2
$LN15@unicode_co@2:
mov edx, DWORD PTR [ebx+esi]
$LN16@unicode_co@2:
; 10432: c2 = PyUnicode_READ(kind2, data2, i);
mov ecx, DWORD PTR _kind2$[ebp]
cmp ecx, 1
jne SHORT $LN21@unicode_co@2
mov ecx, DWORD PTR _data2$[ebp]
movzx ecx, BYTE PTR [eax+ecx]
jmp SHORT $LN20@unicode_co@2
$LN21@unicode_co@2:
cmp ecx, 2
jne SHORT $LN19@unicode_co@2
movzx ecx, WORD PTR [edi]
jmp SHORT $LN20@unicode_co@2
$LN19@unicode_co@2:
mov ecx, DWORD PTR [esi]
$LN20@unicode_co@2:
; 10433:
; 10434: if (c1 != c2)
cmp edx, ecx
jne SHORT $LN31@unicode_co@2
mov ecx, DWORD PTR _len2$[ebp]
inc eax
add edi, 2
add esi, 4
cmp eax, DWORD PTR _len1$[ebp]
jl SHORT $LL28@unicode_co@2
$LN29@unicode_co@2:
mov edi, DWORD PTR _len1$[ebp]
$LN2@unicode_co@2:
; 10436: }
; 10437:
; 10438: return (len1 < len2) ? -1 : (len1 != len2);
cmp edi, ecx
jge SHORT $LN23@unicode_co@2
pop edi
pop esi
or eax, -1
pop ebx
; 10439: }
mov esp, ebp
pop ebp
ret 0
$LN31@unicode_co@2:
; 10435: return (c1 < c2) ? -1 : 1;
sbb eax, eax
pop edi
and eax, -2 ; fffffffeH
pop esi
inc eax
pop ebx
; 10439: }
mov esp, ebp
pop ebp
ret 0
$LN23@unicode_co@2:
; 10436: }
; 10437:
; 10438: return (len1 < len2) ? -1 : (len1 != len2);
xor eax, eax
cmp edi, ecx
pop edi
pop esi
setne al
pop ebx
; 10439: }
mov esp, ebp
pop ebp
ret 0
_unicode_compare ENDP
Neil
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-04-03 07:52 -0400 |
| Message-ID | <mailman.50.1364989980.3114.python-list@python.org> |
| In reply to | #42653 |
On 04/03/2013 07:05 AM, Neil Hodgson wrote:
> Dave Angel:
>
>> That would seem to imply that the speed regression on your data is NOT
>> caused by the differing size encodings. Perhaps it is the difference in
>> MSC compiler version, or other changes made between 3.2 and 3.3
>
> Its not caused by there actually being different size encodings but
> that the code is checking encoding size 2-4 times for each character.
>
> Back in 3.2 the comparison loop looked like:
>
> while (len1 > 0 && len2 > 0) {
> Py_UNICODE c1, c2;
>
> c1 = *s1++;
> c2 = *s2++;
>
> if (c1 != c2)
> return (c1 < c2) ? -1 : 1;
>
> len1--; len2--;
> }
>
> For 3.3 this has changed to
>
> for (i = 0; i < len1 && i < len2; ++i) {
> Py_UCS4 c1, c2;
> c1 = PyUnicode_READ(kind1, data1, i);
> c2 = PyUnicode_READ(kind2, data2, i);
>
> if (c1 != c2)
> return (c1 < c2) ? -1 : 1;
> }
>
> with PyUnicode_READ being
>
> #define PyUnicode_READ(kind, data, index) \
> ((Py_UCS4) \
> ((kind) == PyUnicode_1BYTE_KIND ? \
> ((const Py_UCS1 *)(data))[(index)] : \
> ((kind) == PyUnicode_2BYTE_KIND ? \
> ((const Py_UCS2 *)(data))[(index)] : \
> ((const Py_UCS4 *)(data))[(index)] \
> ) \
> ))
>
> There are either 1 or 2 kind checks in each call to PyUnicode_READ
> and 2 calls to PyUnicode_READ inside the loop. A compiler may decide to
> move the kind checks out of the loop and specialize the loop but MSVC
> 2010 appears to not do so.
I don't know how good MSC's template logic is, but it seems this would
be a good case for an explicit template, typed on the 'kind's values.
Or are all C++ features disabled when compiling Python? Failing that,
just code up 9 cases, and do a switch on the kinds.
I'm also puzzled. I thought that the sort algorithm used a hash of all
the items to be sorted, and only reverted to a raw comparison of the
original values when the hash collided. Is that not the case? Or is
the code you post here only used when the hash collides?
The assembler (32-bit build) for each
> PyUnicode_READ looks like
>
> mov ecx, DWORD PTR _kind1$[ebp]
> cmp ecx, 1
> jne SHORT $LN17@unicode_co@2
> lea ecx, DWORD PTR [ebx+eax]
> movzx edx, BYTE PTR [ecx+edx]
> jmp SHORT $LN16@unicode_co@2
> $LN17@unicode_co@2:
> cmp ecx, 2
> jne SHORT $LN15@unicode_co@2
> movzx edx, WORD PTR [ebx+edi]
> jmp SHORT $LN16@unicode_co@2
> $LN15@unicode_co@2:
> mov edx, DWORD PTR [ebx+esi]
> $LN16@unicode_co@2:
It appears that the compiler is keeping the three pointers in three
separate registers (eax, esi and edi) even though those are 3 aliases
for the same pointer. This is preventing it from putting other values
in those registers.
It'd probably do better if the C code manipulated the pointers, rather
than using an index i each time. But if it did, perhaps gcc would
generate worse code.
If I were coding the assembler by hand (Intel only), I'd be able to
avoid the multiple cmp operations, simply by comparing first to 2, then
doing a jne and a ja. I dunno whether the compiler would notice if I
coded the equivalent in C. (make both comparisons to 2, one for less,
and one for more)
>
> The kind1/kind2 variables aren't even going into registers and at
> least one test+branch and a jump are executed for every character. Two
> tests for 2 and 4 byte kinds. len1 and len2 don't get to go into
> registers either.
>
> Here's the full assembler output for unicode_compare:
>
> ; COMDAT _unicode_compare
> _TEXT SEGMENT
> _kind2$ = -20 ; size = 4
> _kind1$ = -16 ; size = 4
> _len2$ = -12 ; size = 4
> _len1$ = -8 ; size = 4
> _data2$ = -4 ; size = 4
> _unicode_compare PROC ; COMDAT
> ; _str1$ = ecx
> ; _str2$ = eax
>
> ; 10417: {
>
> push ebp
> mov ebp, esp
> sub esp, 20 ; 00000014H
> push ebx
> push esi
> mov esi, eax
>
> ; 10418: int kind1, kind2;
> ; 10419: void *data1, *data2;
> ; 10420: Py_ssize_t len1, len2, i;
> ; 10421:
> ; 10422: kind1 = PyUnicode_KIND(str1);
>
> mov eax, DWORD PTR [ecx+16]
> mov edx, eax
> shr edx, 2
> and edx, 7
> push edi
> mov DWORD PTR _kind1$[ebp], edx
>
> ; 10423: kind2 = PyUnicode_KIND(str2);
>
> mov edx, DWORD PTR [esi+16]
> mov edi, edx
> shr edi, 2
> and edi, 7
> mov DWORD PTR _kind2$[ebp], edi
>
> ; 10424: data1 = PyUnicode_DATA(str1);
>
> test al, 32 ; 00000020H
> je SHORT $LN9@unicode_co@2
> test al, 64 ; 00000040H
> je SHORT $LN7@unicode_co@2
> lea ebx, DWORD PTR [ecx+24]
> jmp SHORT $LN10@unicode_co@2
> $LN7@unicode_co@2:
> lea ebx, DWORD PTR [ecx+36]
> jmp SHORT $LN10@unicode_co@2
> $LN9@unicode_co@2:
> mov ebx, DWORD PTR [ecx+36]
> $LN10@unicode_co@2:
>
> ; 10425: data2 = PyUnicode_DATA(str2);
>
> test dl, 32 ; 00000020H
> je SHORT $LN13@unicode_co@2
> test dl, 64 ; 00000040H
> je SHORT $LN11@unicode_co@2
> lea edx, DWORD PTR [esi+24]
> jmp SHORT $LN30@unicode_co@2
> $LN11@unicode_co@2:
> lea eax, DWORD PTR [esi+36]
> mov DWORD PTR _data2$[ebp], eax
> mov edx, eax
> jmp SHORT $LN14@unicode_co@2
> $LN13@unicode_co@2:
> mov edx, DWORD PTR [esi+36]
> $LN30@unicode_co@2:
> mov DWORD PTR _data2$[ebp], edx
> $LN14@unicode_co@2:
>
> ; 10426: len1 = PyUnicode_GET_LENGTH(str1);
>
> mov edi, DWORD PTR [ecx+8]
>
> ; 10427: len2 = PyUnicode_GET_LENGTH(str2);
>
> mov ecx, DWORD PTR [esi+8]
>
> ; 10428:
> ; 10429: for (i = 0; i < len1 && i < len2; ++i) {
>
> xor eax, eax
> mov DWORD PTR _len1$[ebp], edi
> mov DWORD PTR _len2$[ebp], ecx
> test edi, edi
> jle SHORT $LN2@unicode_co@2
>
> ; 10426: len1 = PyUnicode_GET_LENGTH(str1);
>
> mov esi, edx
> mov edi, edx
>
> ; 10428:
> ; 10429: for (i = 0; i < len1 && i < len2; ++i) {
>
> sub ebx, edx
> jmp SHORT $LN4@unicode_co@2
> $LL28@unicode_co@2:
> mov edx, DWORD PTR _data2$[ebp]
> $LN4@unicode_co@2:
> cmp eax, ecx
> jge SHORT $LN29@unicode_co@2
>
> ; 10430: Py_UCS4 c1, c2;
> ; 10431: c1 = PyUnicode_READ(kind1, data1, i);
>
> mov ecx, DWORD PTR _kind1$[ebp]
> cmp ecx, 1
> jne SHORT $LN17@unicode_co@2
> lea ecx, DWORD PTR [ebx+eax]
> movzx edx, BYTE PTR [ecx+edx]
> jmp SHORT $LN16@unicode_co@2
> $LN17@unicode_co@2:
> cmp ecx, 2
> jne SHORT $LN15@unicode_co@2
> movzx edx, WORD PTR [ebx+edi]
> jmp SHORT $LN16@unicode_co@2
> $LN15@unicode_co@2:
> mov edx, DWORD PTR [ebx+esi]
> $LN16@unicode_co@2:
>
> ; 10432: c2 = PyUnicode_READ(kind2, data2, i);
>
> mov ecx, DWORD PTR _kind2$[ebp]
> cmp ecx, 1
> jne SHORT $LN21@unicode_co@2
> mov ecx, DWORD PTR _data2$[ebp]
> movzx ecx, BYTE PTR [eax+ecx]
> jmp SHORT $LN20@unicode_co@2
> $LN21@unicode_co@2:
> cmp ecx, 2
> jne SHORT $LN19@unicode_co@2
> movzx ecx, WORD PTR [edi]
> jmp SHORT $LN20@unicode_co@2
> $LN19@unicode_co@2:
> mov ecx, DWORD PTR [esi]
> $LN20@unicode_co@2:
>
> ; 10433:
> ; 10434: if (c1 != c2)
>
> cmp edx, ecx
> jne SHORT $LN31@unicode_co@2
> mov ecx, DWORD PTR _len2$[ebp]
> inc eax
> add edi, 2
> add esi, 4
> cmp eax, DWORD PTR _len1$[ebp]
> jl SHORT $LL28@unicode_co@2
> $LN29@unicode_co@2:
> mov edi, DWORD PTR _len1$[ebp]
> $LN2@unicode_co@2:
>
> ; 10436: }
> ; 10437:
> ; 10438: return (len1 < len2) ? -1 : (len1 != len2);
>
> cmp edi, ecx
> jge SHORT $LN23@unicode_co@2
> pop edi
> pop esi
> or eax, -1
> pop ebx
>
> ; 10439: }
>
> mov esp, ebp
> pop ebp
> ret 0
> $LN31@unicode_co@2:
>
> ; 10435: return (c1 < c2) ? -1 : 1;
>
> sbb eax, eax
> pop edi
> and eax, -2 ; fffffffeH
> pop esi
> inc eax
> pop ebx
>
> ; 10439: }
>
> mov esp, ebp
> pop ebp
> ret 0
> $LN23@unicode_co@2:
>
> ; 10436: }
> ; 10437:
> ; 10438: return (len1 < len2) ? -1 : (len1 != len2);
>
> xor eax, eax
> cmp edi, ecx
> pop edi
> pop esi
> setne al
> pop ebx
>
> ; 10439: }
>
> mov esp, ebp
> pop ebp
> ret 0
> _unicode_compare ENDP
>
> Neil
--
DaveA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-03 14:43 +0000 |
| Subject | Sorting [was Re: Performance of int/long in Python 3] |
| Message-ID | <515c400e$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42656 |
On Wed, 03 Apr 2013 07:52:42 -0400, Dave Angel wrote: > I thought that the sort algorithm used a hash of all > the items to be sorted, and only reverted to a raw comparison of the > original values when the hash collided. Is that not the case? Or is > the code you post here only used when the hash collides? Sorting does not require that the elements being sorted are hashable. If I have understood the implementation here: http://hg.python.org/releasing/3.3.1/file/2ab2a09901f9/Objects/listobject.c sorting in Python only requires that objects implement the less-than comparison. py> class Funny: ... def __init__(self, x): ... self.x = x ... def __lt__(self, other): ... return self.x < other.x ... def __gt__(self, x): ... raise AttributeError ... __le__ = __ge__ = __eq__ = __ne__ = __gt__ ... py> L = [Funny(i) for i in range(10)] py> random.shuffle(L) py> [f.x for f in L] [8, 5, 7, 0, 9, 2, 3, 6, 1, 4] py> [f.x for f in sorted(L)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] but if I change Funny.__lt__ to also raise, sorting fails. I seem to recall that "sort relies only on < operator" is a language promise, but I can't seem to find it documented anywhere official. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 11:00 -0400 |
| Subject | Re: Sorting [was Re: Performance of int/long in Python 3] |
| Message-ID | <roy-51208D.11001003042013@news.panix.com> |
| In reply to | #42676 |
In article <515c400e$0$29966$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > I seem to recall that "sort relies only on < operator" is a language > promise, but I can't seem to find it documented anywhere official. That's pretty typical for sort implementations in all languages. Except for those which rely on "less than and equal to" :-)
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-03 10:30 -0600 |
| Message-ID | <mailman.65.1365006696.3114.python-list@python.org> |
| In reply to | #42653 |
On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel <davea@davea.name> wrote: > I'm also puzzled. I thought that the sort algorithm used a hash of all the > items to be sorted, and only reverted to a raw comparison of the original > values when the hash collided. Is that not the case? Or is the code you > post here only used when the hash collides? I think you are mistaken, because I don't see how that could work. If the hashes of two items are different then you can assume they are not equal, but sorting requires a partial ordering comparison, not simply an equality comparison. You cannot determine which item is less or greater than the other from the hash values alone.
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-04-03 13:51 -0400 |
| Message-ID | <mailman.70.1365011504.3114.python-list@python.org> |
| In reply to | #42653 |
On 04/03/2013 12:30 PM, Ian Kelly wrote: > On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel <davea@davea.name> wrote: >> I'm also puzzled. I thought that the sort algorithm used a hash of all the >> items to be sorted, and only reverted to a raw comparison of the original >> values when the hash collided. Is that not the case? Or is the code you >> post here only used when the hash collides? > > I think you are mistaken, because I don't see how that could work. If > the hashes of two items are different then you can assume they are not > equal, but sorting requires a partial ordering comparison, not simply > an equality comparison. You cannot determine which item is less or > greater than the other from the hash values alone. > You are of course correct. The particular data that Neil had provided might well have had many duplicates, but that won't be the typical case, so there's not much point in doing an unordered hash. I guess I was confusing it with the key= argument for modifying sort order, where the key function might replace a slow-to-compare data type with something faster. -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-04 09:58 +1100 |
| Message-ID | <lLmdnVNU3_pTKcHMnZ2dnUVZ_rCdnZ2d@westnet.com.au> |
| In reply to | #42653 |
Neil Hodgson, replying to self:
> The assembler (32-bit build) for each
> PyUnicode_READ looks like
Don't have 64-bit MSVC 2010 set up but the code from 64-bit MSVC
2012 is better since there are an extra 8 registers in 64-bit mode:
; 10431: c1 = PyUnicode_READ(kind1, data1, i);
cmp rsi, 1
jne SHORT $LN17@unicode_co
lea rax, QWORD PTR [r9+rcx]
movzx r8d, BYTE PTR [rax+rbx]
jmp SHORT $LN16@unicode_co
$LN17@unicode_co:
cmp rsi, 2
jne SHORT $LN15@unicode_co
movzx r8d, WORD PTR [r9+r11]
jmp SHORT $LN16@unicode_co
$LN15@unicode_co:
mov r8d, DWORD PTR [r9+r10]
$LN16@unicode_co:
All the variables used in the loop are now in registers but the
tests and branches are the same. This lines up with 64-bit being better
than 32-bit on Windows but not as good as Python 3.2 or Unix.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-03 07:53 +0000 |
| Message-ID | <515be00e$0$29891$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42638 |
On Wed, 03 Apr 2013 18:24:25 +1100, Chris Angelico wrote:
> On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico <rosuav@gmail.com>
>> wrote:
>>> Hmm. I was about to say "Can you just do a quick collections.Counter()
>>> of the string widths in 3.3, as an easy way of seeing which ones use
>>> BMP or higher characters", but I can't find a simple way to query a
>>> string's width. Can't see it as a method of the string object, nor in
>>> the string or sys modules. It ought to be easy enough at the C level -
>>> just look up the two bits representing 'kind' - but I've not found it
>>> exposed to Python. Is there anything?
>>
>> 4 if max(map(ord, s)) > 0xffff else 2 if max(map(ord, s)) > 0xff else 1
>
> Yeah, that's iterating over the whole string (twice, if it isn't width
> 4).
Then don't write it as a one-liner :-P
n = max(map(ord, s))
4 if n > 0xffff else 2 if n > 0xff else 1
Here's another way:
(sys.getsizeof(s) - sys.getsizeof(''))/len(s)
should work.
There's probably also a way to do it using ctypes.
> The system already knows what the size is, I was hoping for an
> uber-quick inspection of the string header.
I'm not sure that I would want strings to have a method reporting this,
but it might be nice to have a function in the inspect module to do so.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-03 19:02 +1100 |
| Message-ID | <mailman.42.1364976141.3114.python-list@python.org> |
| In reply to | #42641 |
On Wed, Apr 3, 2013 at 6:53 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Here's another way:
>
>
> (sys.getsizeof(s) - sys.getsizeof(''))/len(s)
>
> should work.
Hmm, I had been under the impression that there was a certain "base
length" below which strings all had the same size. Yes, that also
works; though again, it's something that can be directly queried, at
the C level.
> There's probably also a way to do it using ctypes.
>
>> The system already knows what the size is, I was hoping for an
>> uber-quick inspection of the string header.
>
> I'm not sure that I would want strings to have a method reporting this,
> but it might be nice to have a function in the inspect module to do so.
Yeah, that's why I also looked in 'sys'; 'inspect' might well be a
good place for it, too. But it seems such a function doesn't exist,
which is what I was asking.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-03 01:08 -0700 |
| Message-ID | <ead2515e-c179-49b1-9f69-e600d41daa2f@h1g2000vbx.googlegroups.com> |
| In reply to | #42642 |
-------- This FSR is wrong by design. A naive way to embrace Unicode. jmf
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-03 12:27 +0100 |
| Message-ID | <mailman.49.1364988458.3114.python-list@python.org> |
| In reply to | #42644 |
On 03/04/2013 09:08, jmfauth wrote: > -------- > > This FSR is wrong by design. A naive way to embrace Unicode. > > jmf > The hole you're digging for yourself is getting bigger and bigger and I'm loving it :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 09:43 -0400 |
| Message-ID | <roy-DCD651.09430603042013@news.panix.com> |
| In reply to | #42641 |
In article <515be00e$0$29891$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 03 Apr 2013 18:24:25 +1100, Chris Angelico wrote:
>
> > On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> >> On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico <rosuav@gmail.com>
> >> wrote:
> >>> Hmm. I was about to say "Can you just do a quick collections.Counter()
> >>> of the string widths in 3.3, as an easy way of seeing which ones use
> >>> BMP or higher characters", but I can't find a simple way to query a
> >>> string's width. Can't see it as a method of the string object, nor in
> >>> the string or sys modules. It ought to be easy enough at the C level -
> >>> just look up the two bits representing 'kind' - but I've not found it
> >>> exposed to Python. Is there anything?
> >>
> >> 4 if max(map(ord, s)) > 0xffff else 2 if max(map(ord, s)) > 0xff else 1
> >
> > Yeah, that's iterating over the whole string (twice, if it isn't width
> > 4).
>
> Then don't write it as a one-liner :-P
>
> n = max(map(ord, s))
> 4 if n > 0xffff else 2 if n > 0xff else 1
This has to inspect the entire string, no? I posted (essentially) this
a few days ago:
if all(ord(c) <= 0xffff for c in s):
return "it's all bmp"
else:
return "it's got astral crap in it"
I'm reasonably sure all() is smart enough to stop at the first False
value.
> (sys.getsizeof(s) - sys.getsizeof(''))/len(s)
>
I wouldn't trust getsizeof() to return exactly what you're looking for.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web