Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #104645 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2016-03-12 08:36 +1100 |
| Last post | 2016-03-12 15:29 +0000 |
| Articles | 20 on this page of 314 — 29 participants |
Back to article view | Back to comp.lang.python
The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-12 08:36 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 01:16 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-11 21:02 -0800
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 11:50 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 14:13 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 13:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 15:40 +0200
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 20:24 +0100
Re: The Cost of Dynamism Chris Angelico <rosuav@gmail.com> - 2016-03-13 08:18 +1100
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-13 21:05 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 00:40 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 20:26 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 22:14 +0000
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-13 21:08 +0100
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 20:20 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-12 23:52 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 03:22 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 08:45 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-13 00:10 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 09:19 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-13 00:57 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 23:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-13 01:10 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 19:39 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-13 22:12 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 17:17 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 17:53 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-14 20:25 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 18:39 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 20:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:55 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-15 13:10 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 11:52 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 14:58 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 18:28 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-14 07:57 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 22:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Christian Gollwitzer <auriocus@gmx.de> - 2016-03-13 22:26 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-14 08:44 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Paul Rubin <no.email@nospam.invalid> - 2016-03-13 16:25 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 10:24 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 00:25 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 00:50 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 01:15 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 01:28 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 12:35 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 02:04 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 13:07 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-21 13:11 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-21 17:41 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-21 00:07 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-21 18:47 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 03:30 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 16:51 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-23 17:09 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-23 10:34 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 21:48 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-23 13:41 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-24 14:24 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-23 20:38 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 13:01 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-24 09:33 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-24 16:16 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-24 07:37 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 22:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 05:10 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 19:54 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 22:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-24 21:02 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-25 11:06 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-26 03:22 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-25 22:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-26 13:19 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-26 13:45 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-24 20:49 -0600
Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 02:50 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Marko Rauhamaa <marko@pacujo.net> - 2016-03-25 18:57 +0200
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 13:46 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Random832 <random832@fastmail.com> - 2016-03-25 22:56 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-25 19:59 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 23:21 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 00:22 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-26 14:09 +0000
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 01:30 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-26 15:24 +0000
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-26 23:34 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 12:31 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-27 09:47 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 15:43 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ned Batchelder <ned@nedbatchelder.com> - 2016-03-27 08:48 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Terry Reedy <tjreedy@udel.edu> - 2016-03-27 12:39 -0400
Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:26 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] Terry Reedy <tjreedy@udel.edu> - 2016-03-28 15:34 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 17:58 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ned Batchelder <ned@nedbatchelder.com> - 2016-03-27 10:19 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 21:18 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ned Batchelder <ned@nedbatchelder.com> - 2016-03-27 14:55 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 23:11 +0100
Statements as expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 11:54 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Paul Rubin <no.email@nospam.invalid> - 2016-03-27 18:40 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-29 19:26 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Paul Rubin <no.email@nospam.invalid> - 2016-03-29 01:54 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Chris Angelico <rosuav@gmail.com> - 2016-03-29 20:09 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Marko Rauhamaa <marko@pacujo.net> - 2016-03-29 12:23 +0300
Re: Statements as expressions [was Re: Undefined behaviour in C] BartC <bc@freeuk.com> - 2016-03-29 12:31 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-30 11:05 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-29 08:15 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] BartC <bc@freeuk.com> - 2016-03-28 12:11 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-28 13:55 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Paul Rubin <no.email@nospam.invalid> - 2016-03-28 11:27 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Rustom Mody <rustompmody@gmail.com> - 2016-03-29 20:14 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-29 23:49 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-30 15:26 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Rustom Mody <rustompmody@gmail.com> - 2016-03-30 09:59 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Random832 <random832@fastmail.com> - 2016-03-30 13:07 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] Rustom Mody <rustompmody@gmail.com> - 2016-03-30 10:28 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-30 19:01 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] Random832 <random832@fastmail.com> - 2016-03-30 20:15 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-27 18:31 -0400
Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:45 +1100
Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:24 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] Chris Angelico <rosuav@gmail.com> - 2016-03-28 12:38 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] Tim Chase <python.list@tim.thechases.com> - 2016-03-27 21:59 -0500
Re: Useless expressions [was Re: Undefined behaviour in C] Chris Angelico <rosuav@gmail.com> - 2016-03-28 14:29 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] BartC <bc@freeuk.com> - 2016-03-28 13:18 +0100
Re: Useless expressions [was Re: Undefined behaviour in C] Marko Rauhamaa <marko@pacujo.net> - 2016-03-28 16:29 +0300
Re: Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-29 18:12 +1100
Re: Useless expressions Ben Finney <ben+python@benfinney.id.au> - 2016-03-29 18:35 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 18:50 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-03-27 10:51 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-26 23:13 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 18:40 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-27 00:52 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-27 21:06 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-03-27 22:16 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Marko Rauhamaa <marko@pacujo.net> - 2016-03-26 10:37 +0200
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-26 08:23 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 18:13 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-25 22:30 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 21:39 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-26 23:03 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-26 10:43 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Terry Reedy <tjreedy@udel.edu> - 2016-03-26 16:44 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-26 22:02 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-26 22:54 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 08:58 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 13:44 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 13:52 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-26 23:34 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-27 00:13 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-25 21:07 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 00:50 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-25 01:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:28 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-24 18:30 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:04 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 14:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:16 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-24 16:34 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:49 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-24 10:53 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 15:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 15:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 15:25 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-24 11:30 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 04:56 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 19:07 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 04:44 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Matt Wheeler <m@funkyhat.org> - 2016-03-24 14:22 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 14:51 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 04:27 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-24 21:24 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-24 18:14 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-24 08:30 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 16:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-24 10:13 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 18:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-24 17:30 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Tim Golden <mail@timgolden.me.uk> - 2016-03-23 10:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 22:28 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-23 08:40 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-23 16:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-23 12:24 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-24 10:55 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-23 20:12 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-24 11:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 01:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-23 23:21 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-23 20:26 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-23 16:09 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 03:59 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-21 17:38 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 18:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-21 09:20 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 02:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 19:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 19:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-21 13:18 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-21 18:59 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 12:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 11:05 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-22 22:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 12:59 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:13 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-22 13:46 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 01:02 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-22 15:07 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 02:18 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 14:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-22 07:15 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 01:31 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-23 12:14 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 12:21 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-22 13:43 -0600
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 09:23 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-23 17:07 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 17:28 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-22 04:23 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ian Foote <ian@feete.org> - 2016-03-22 11:27 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-22 07:45 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-22 22:55 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 23:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 23:03 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 14:52 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:00 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 15:15 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:24 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 15:32 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:38 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 15:49 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Larry Hudson <orgnut@yahoo.com> - 2016-03-22 22:17 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-20 22:21 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 12:34 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 23:59 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 00:48 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-21 10:04 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 02:09 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-21 08:39 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-22 02:45 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 17:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-21 20:20 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-21 06:02 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 13:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) MRAB <python@mrabarnett.plus.com> - 2016-03-21 13:17 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 02:11 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 17:31 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 18:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-21 19:20 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 00:49 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-22 02:01 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-22 04:15 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-22 17:53 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-22 09:24 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-22 07:44 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-21 20:13 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-21 05:08 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 12:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-21 06:12 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-21 19:50 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 00:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-22 00:42 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 01:00 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-24 13:49 -0600
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 13:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 02:30 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 22:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 08:48 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 11:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-12 11:27 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 13:51 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 13:42 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 16:38 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 03:56 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 17:54 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 20:07 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 18:30 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 20:39 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 13:16 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-14 14:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 13:00 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 14:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 16:21 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-14 11:55 -0600
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-14 19:45 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 20:31 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Christian Gollwitzer <auriocus@gmx.de> - 2016-03-14 22:00 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 21:17 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 21:00 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:27 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 01:35 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:12 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-15 08:25 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-15 09:20 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 12:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-15 23:20 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-15 11:17 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-15 12:14 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:19 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:11 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-12 23:10 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-12 23:28 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 00:06 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 15:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 02:30 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 16:42 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-12 17:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 12:20 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-13 01:32 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 13:03 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-13 13:33 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-13 01:43 -0500
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Gene Heskett <gheskett@wdtv.com> - 2016-03-13 09:14 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-12 19:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-12 15:29 +0000
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-24 13:01 +0000 |
| Message-ID | <nd0oaa$rsb$1@dont-email.me> |
| In reply to | #105585 |
On 24/03/2016 03:24, Chris Angelico wrote: > On Thu, Mar 24, 2016 at 12:41 AM, BartC <bc@freeuk.com> wrote: >> To extend this analogy better, executing byte-code to directly perform a >> task itself might be equivalent to travelling on foot, while everyone is >> suggesting taking the bus, tube or taxi. > It's easy to see that carrying five boxes of books will slow down > you're walking *dramatically*. In fact, it's probably quicker to take > just one of them, and then come back for another one, and so on. When > you travel by car, it's much harder to measure the cost of the five > boxes, but it made so much difference in walking time that you should > probably take one box at a time, right? > > This is how you're currently evaluating Python. Instead of starting > with the most simple and obvious code and refining from there, you're > starting from a whole lot of preconceived ideas about what's "fast" or > "slow", and assuming/expecting that they'll all still be valid. Many > of them won't be, yet you still persist in doing things based on what > you expect to be the case (because of what's fast/slow in C or some > other language). We've explained this a number of times, and one by > one, we're coming to the conclusion that you not only don't understand > Python, you don't *want* to understand Python; and until you actually > understand how the language works, timing stats are dubious. > > Do you understand why people aren't taking your results very seriously? I've been using interpreted languages since the 80s, when they were much cruder and slower (and when hardware was much slower too). Yet I could still use them effectively. (I reckoned that when used sensibly and in the right balance, a solution using a dynamic language would only be between one and two times slower than using compiled, native code. But it was many times more productive.) So I understand perfectly that such languages have a huge range of applications no matter what the speed of the underlying byte-code. However.... once you start looking at tasks where the speed /might/ matter, then you have to start measuring properly. And forgetting Python for a minute and concentrating only on its byte-code as a language in its own right, how would you go about the job of streamlining it? You might start with profiling it to see which codes are more expensive, which are called most then, all the usual stuff. But there are all sorts of micro-micro-benchmarks that can concentrate on a single byte-code. For example, how long does it take to call an empty function with no parameters? Just putting such a call into a simple loop can be effective: Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted, presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns, but this is not executing code indirectly as most of the rest have to. [Timings include loop overheads that need to be factored out.] So there might be room for improvement, but those faster languages are also simpler. Is Python's richness or dynamism the main factor here? If so there is probably little to be done; if not... This is where the fun starts. But I understand that most people aren't interested in this kind of sport. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-24 09:33 -0400 |
| Message-ID | <mailman.93.1458826344.2244.python-list@python.org> |
| In reply to | #105606 |
On Thu, 24 Mar 2016 13:01:54 +0000, BartC <bc@freeuk.com> declaimed the
following:
>
>And forgetting Python for a minute and concentrating only on its
>byte-code as a language in its own right, how would you go about the job
>of streamlining it?
>
Given that the "byte-code" likely does change between major version
releases, and maybe even minor version (but not on builds within a minor
version)... Which is why pyc files may need to be regenerated when updating
a Python interpreter... AND that the "Jython" and "IronPython" variations
are on totally different run-times (Java virtual machine and .NET as I
recall), unless you specify the base CPython (not to be confused with
Cython), any comparison is likely meaningless. It is on par with trying to
discuss the byte-codes of BASIC without specifying QuickBASIC, GWBASIC,
Visual BASIC (though that is closer to a full native compiler for v6, and
.NET for later)... Or worse -- the byte-code of the P4 Pascal compiler (or
UCSD) vs the threaded code of FORTH.
As for the timings -- do you exclude the initial compilation phase
(stuff things into a module and create a pyc file from that... Or, since
speed seems your focus, create pyo files -- then time the use of the pyo
file, not the source).
From what I can tell -- your focus is at the level of comparing single
operations between x86, 68K, and ARM processors, and objecting because one
does something faster so shouldn't the others implement the operation the
same way -- even if it means changing half the support architecture. (The
original x86 segment registers may have made large memory operations
slower, as one had to load both segment and offset registers... But made
64K code position independent on 16-byte boundaries, as one only had to
load the segment register once, and henceforth only needed to work with a
16-bit offset register -- vs a 68K processor that had to load the full
address register [24 to 32 bits] each time even on a 16-bit bus)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-24 16:16 +0200 |
| Message-ID | <8737rgnepk.fsf@elektro.pacujo.net> |
| In reply to | #105606 |
BartC <bc@freeuk.com>: > And forgetting Python for a minute and concentrating only on its > byte-code as a language in its own right, how would you go about the > job of streamlining it? CPython's bytecode is not crucial for CPython's execution speed. The bytecode is mainly a method of improving the performance of loading modules. IOW, it seeks to optimize parsing. CPython's VM does not have to execute the bytecode as-is. It can further compile and reprocess it internally to optimize speed and other attributes. As far as CPython is considered, a .pyc file contains precisely the same information as the .py file. Thus, executing .pyc is no faster than executing a .py file (ignoring the parsing overhead). The only advantage of streamlining bytecode is to speed up load times, which is a complete nonissue in most production environments. Really, your optimization efforts should concentrate not on bytecode but on runtime data structures, algorithms, heuristics, equivalence transformations, reachability analysis, profiling and such. Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-03-24 07:37 -0700 |
| Message-ID | <aae26857-9ef5-41e7-b552-3163cb28cc87@googlegroups.com> |
| In reply to | #105615 |
On Thursday, March 24, 2016 at 7:46:55 PM UTC+5:30, Marko Rauhamaa wrote: > BartC : > > > And forgetting Python for a minute and concentrating only on its > > byte-code as a language in its own right, how would you go about the > > job of streamlining it? > Really, your optimization efforts should concentrate not on bytecode but > on runtime data structures, algorithms, heuristics, equivalence > transformations, reachability analysis, profiling and such. 'A' is a scientific programmer; he optimizes his scientific programs 'C' is a financial programmer; he optimizes his finance programs 'B(art)' is a bytecode-interpreter programmer; How does he optimize his bytecode interpreters?
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-24 22:43 +0000 |
| Message-ID | <mailman.113.1458859448.2244.python-list@python.org> |
| In reply to | #105620 |
On 24/03/2016 14:37, Rustom Mody wrote: > On Thursday, March 24, 2016 at 7:46:55 PM UTC+5:30, Marko Rauhamaa wrote: >> BartC : >> >>> And forgetting Python for a minute and concentrating only on its >>> byte-code as a language in its own right, how would you go about the >>> job of streamlining it? > >> Really, your optimization efforts should concentrate not on bytecode but >> on runtime data structures, algorithms, heuristics, equivalence >> transformations, reachability analysis, profiling and such. > > 'A' is a scientific programmer; he optimizes his scientific programs > 'C' is a financial programmer; he optimizes his finance programs > 'B(art)' is a bytecode-interpreter programmer; How does he optimize his bytecode > interpreters? > 'A' makes sure as best they can that their program is correct. 'C' makes sure as best they can that their program is correct. 'B' doesn't care provided it is quick. -- 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-25 05:10 +1100 |
| Message-ID | <56f42d9f$0$1618$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105606 |
On Fri, 25 Mar 2016 12:01 am, BartC wrote:
> But there are all sorts of micro-micro-benchmarks that can concentrate
> on a single byte-code. For example, how long does it take to call an
> empty function with no parameters? Just putting such a call into a
> simple loop can be effective:
>
> Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted,
> presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns,
> but this is not executing code indirectly as most of the rest have to.
"Might"? Are you making those numbers up?
> [Timings include loop overheads that need to be factored out.]
Then those numbers are pointless. The Python figure, for example, might be
199ns for the loop overhead and 1ns for the function call, or 1ns for the
loop overhead and 199ns for the function call. Or anything in between. How
do you know which is which?
> So there might be room for improvement, but those faster languages are
> also simpler.
Right.
Let's compare two almost identical looking lines in Python and C:
y = x + 1
y = x + 1;
Apart from the semi-colon, they do exactly the same thing, right?
Well, no. Not even close.
In the case of C, the line is limited to working with some specific type
(say, an int32). Even there, if the addition might overflow, the behaviour
is undefined and the compiler can do anything it wants (including time
travel, or erasing your hard disk).
In the case of Python, the line will work with a potentially infinite number
of types: int, float, complex, Fraction, Decimal, subclasses of all the
above, custom numeric types, and anything else that quacks like a number.
There's no undefined behaviour: at worst, you will get an exception.
There's no integer overflow: you can set x = 10**100 and add one to it, and
the result will be mathematically exact.
Even though the two lines *look* the same, they are as different as chalk
and cheese. If you wrote C code that had the same semantics as the Python
code, chances are it wouldn't be much faster than Python.
This shouldn't be surprising. Python, or at least the standard CPython
interpreter, is written in C. It is, effectively, a DSL ("Domain Specific
Language") for C: all the things which are hard in C, like memory
management, polymorphic code, not segfaulting, etc., are handled for you.
So yes, faster languages are often simpler. They are fast because they do
less. As the saying goes, the fastest code is the code that isn't run.
> Is Python's richness or dynamism the main factor here? If
> so there is probably little to be done; if not... This is where the fun
> starts.
>
> But I understand that most people aren't interested in this kind of sport.
Checkout the benchmark game:
http://benchmarksgame.alioth.debian.org/
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-24 19:54 +0000 |
| Message-ID | <nd1ggm$v4q$1@dont-email.me> |
| In reply to | #105644 |
On 24/03/2016 18:10, Steven D'Aprano wrote:
> On Fri, 25 Mar 2016 12:01 am, BartC wrote:
>> Python 3 (on Windows) might take 200ns. Clisp is 1300ns (interpreted,
>> presumably). Ruby 170ns. Lua 80ns. Mine 10-20ns. Unoptimised C is 4ns,
>> but this is not executing code indirectly as most of the rest have to.
>
> "Might"? Are you making those numbers up?
No.
>> [Timings include loop overheads that need to be factored out.]
>
> Then those numbers are pointless.
Yes, they would need some adjustment to do this stuff properly. FWIW the
loop overheads were about 30% in Python, 40% in Ruby, and 20% in mine.
> The Python figure, for example, might be
> 199ns for the loop overhead and 1ns for the function call, or 1ns for the
> loop overhead and 199ns for the function call. Or anything in between. How
> do you know which is which?
It sounds like they would both need some work!
>> So there might be room for improvement, but those faster languages are
>> also simpler.
> In the case of C, the line is limited to working with some specific type
> (say, an int32). Even there, if the addition might overflow, the behaviour
> is undefined and the compiler can do anything it wants (including time
> travel,
I'm pretty sure it can't do time travel...
or erasing your hard disk).
>
> In the case of Python, the line will work with a potentially infinite number
> of types: int, float, complex, Fraction, Decimal, subclasses of all the
> above, custom numeric types, and anything else that quacks like a number.
Yes, it has to do some dynamic type dispatch. All the languages except C
were dynamic (C cheats in so many ways).
However, my bit of code (a for-loop calling an empty function) doesn't
on the surface, do anything that requires type dispatch, or does it?
This is where we come to the first differences between how Python works
and how, say, my language works (I don't know about Lua, Ruby and Lisp.)
Python bytecode for empty function bill():
4 0 LOAD_CONST 0 (None)
3 RETURN_VALUE
Inner loop calling bill():
>> 13 FOR_ITER 13 (to 29)
16 STORE_FAST 0 (n)
8 19 LOAD_GLOBAL 1 (bill)
22 CALL_FUNCTION 0 (0 positional... )
25 POP_TOP
26 JUMP_ABSOLUTE 13
My bytecode for function bill():
0: 000 --------- return
My inner loop bytecode:
1: 005 %4:
1: 006 --------- call [&t.bill], 0
1: 006 --------- to_f %4, [t.start.av$1:-1]
Half the explanation is right here: I use 1 op in the function, and 2 in
the loop. Python uses 2 in the function, and 6 in the loop.
(I use a dedicated repeat-N-times loop that needs no explicit loop
variable, only an internal integer count. I use a special 'proc' form of
function with no return value. And I use static functions so the
byte-code knows the function being called, and knows it returns no value
that needs to be popped.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-24 22:18 +0000 |
| Message-ID | <mailman.111.1458857991.2244.python-list@python.org> |
| In reply to | #105649 |
On 24/03/2016 19:54, BartC wrote: > On 24/03/2016 18:10, Steven D'Aprano wrote: >> On Fri, 25 Mar 2016 12:01 am, BartC wrote: > >> >> Then those numbers are pointless. > > Yes, they would need some adjustment to do this stuff properly. Please give up before you get sued by the families of the people who have died laughing. -- 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 | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-24 21:02 -0400 |
| Message-ID | <mailman.124.1458867719.2244.python-list@python.org> |
| In reply to | #105649 |
On Thu, 24 Mar 2016 19:54:54 +0000, BartC <bc@freeuk.com> declaimed the
following:
>
>(I use a dedicated repeat-N-times loop that needs no explicit loop
>variable, only an internal integer count. I use a special 'proc' form of
>function with no return value. And I use static functions so the
>byte-code knows the function being called, and knows it returns no value
>that needs to be popped.)
Well, that sure wouldn't support a Python for-loop, which works with
indefinite iterable objects... Python for-loops end when the iterator says
it has no more data to provide to the loop. Python does not do a "counted"
loop.
Changing this behavior would break oh so many existing programs. Think
of the Python for-loop as being something similar to a C while-loop with an
assignment in the conditional
Python:
for itm in iterator:
pass
C:
while (Null != (itm = iterator());
Though actually that should maybe be done with C++ exception catching
and a for-loop with no exit conditional... Something like [I just pulled
down the C++ book -- don't expect anything that compiles]
C++:
try
{
for (itm = iterator(); ; itm = iterator())
;
}
catch (end_iteration)
;
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-25 11:06 +0000 |
| Message-ID | <nd35tr$7dd$1@dont-email.me> |
| In reply to | #105670 |
On 25/03/2016 01:02, Dennis Lee Bieber wrote: > On Thu, 24 Mar 2016 19:54:54 +0000, BartC <bc@freeuk.com> declaimed the > following: > > >> >> (I use a dedicated repeat-N-times loop that needs no explicit loop >> variable, > Well, that sure wouldn't support a Python for-loop... If I may, I'll reply to this point outside the group, at this link: http://pastebin.com/hfAKN2jg -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-26 03:22 +1100 |
| Message-ID | <56f565e4$0$1614$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105686 |
On Fri, 25 Mar 2016 10:06 pm, BartC wrote:
> On 25/03/2016 01:02, Dennis Lee Bieber wrote:
>> On Thu, 24 Mar 2016 19:54:54 +0000, BartC <bc@freeuk.com> declaimed the
>> following:
>>
>>
>>>
>>> (I use a dedicated repeat-N-times loop that needs no explicit loop
>>> variable,
>
>> Well, that sure wouldn't support a Python for-loop...
>
> If I may, I'll reply to this point outside the group, at this link:
>
> http://pastebin.com/hfAKN2jg
Why split the discussion to *Pastebin*, of all places?
Anyway, this is (in my opinion) the only relevant part of your comments
there:
[quote]
But it is an optimisation that /could/ be done by the byte-code compiler
when it sees a construct such as:
for i in range(100):
.....
and 'i' isn't used within the loop. (I don't know what Python says about the
value of i after the loop terminates.)
[end quote]
i is guaranteed to have the same value outside the loop as it last had
inside the loop, unless you explicitly unbind the name using "del" (or
something equivalent).
So after:
for i in range(100):
pass
print(i)
"99" will be printed. Likewise:
for i in range(100):
if i == 50: break
print(i)
"50" will be printed.
[quote]
This change would require a new byte-code (one that goes at the end of a
loop, not the start), which probably wouldn't be popular either. And, by
itself, would have very little impact on the majority of programs. (Also,
if loops are that much of a problem, this is where PyPy excels.)
[end quote]
I am pretty sure that PyPy takes lots of efforts to optimize loops, but I
can't tell you precisely what.
I would also expect that Victor Stinner's FAT Python project will
(eventually) look at optimizing such for-loops too. If you see something
like:
for i in range(N):
do_stuff()
and three conditions hold:
(1) i is unused in the loop body;
(2) range is still bound to the expected built-in function, and no
other "range" in a nearer scope (say, a local variable called "range", or a
global) exists to shadow it; and
(3) and the body of the for-loop has no side-effects that might affect the
truth of (1)
then it should be safe to replace this loop with a fast, C loop that just
calls the body of the loop N times. And that in turn might be fully or
partly unrolled, e.g.
for i in range(4):
spam()
could become:
spam()
spam()
spam()
spam()
(This is a pretty standard compiler optimization technique, and if I recall
correctly, PyPy already does this.)
#1 (is i used in the loop?) can be detected at compile-time. There might be
some tricky corner cases involving calls to nested functions, and of course
any call to eval or exec make the analysis intractable, but I think it is
otherwise easy to tell whether or not i is used in the for-loop.
#2 (is range the expected range) can be handled by assuming it is, and
keeping a guard for the case that it isn't. That's what FAT Python will do.
I think PyPy does something similar.
I don't have an intuition on how hard #3 (does the loop body have any
side-effects that might affect this optimization?) might be, except to say
that the presence of an eval or exec inside the body will probably make the
optimization unsafe.
It wouldn't surprise me if the unmaintained but still working Psycho project
handled this, as well as such newer projects as pyjion, pyston, numba and
theano.
Bart, possibly something you have missed in this discussion: many of the
optimizations you are surprised not to see are not, and may never be, in
the vanilla Python language. But they are being included in language
add-ons. There is a thriving, experimental but still usable, culture of JIT
compilers for Python. Here is one of the oldest:
http://www.ibm.com/developerworks/library/l-psyco/index.html
Pyscho is unmaintained and doesn't work on anything better than 2.6, but the
author has gone on to be one of the lead devs in PyPy, and it has inspired
newer projects like numba and theano. The attitude of the core developers,
especially Guido, is that the reference interpreter CPython should stick to
only the easiest, least controversial optimizations (if any!) and leave the
hard ones to third-party add-ons.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-25 22:08 +0000 |
| Message-ID | <nd4cms$kl$1@dont-email.me> |
| In reply to | #105693 |
On 25/03/2016 16:22, Steven D'Aprano wrote: > On Fri, 25 Mar 2016 10:06 pm, BartC wrote: (OK, I'll risk the wrath of Mark Lawrence et al by daring to post my opinions.) >> But it is an optimisation that /could/ be done by the byte-code compiler > I would also expect that Victor Stinner's FAT Python project will > (eventually) look at optimizing such for-loops too. If you see something > like: > > for i in range(N): > do_stuff() > > > and three conditions hold: > > (1) i is unused in the loop body; > > (2) range is still bound to the expected built-in function, and no > other "range" in a nearer scope (say, a local variable called "range", or a > global) exists to shadow it; and The volatility of 'range' I'd completely forgotten about. Python really doesn't make this stuff easy, does it? Checking this at runtime, per loop (I don't think it's necessary per iteration) is a possibility, but now an extra overhead is introduced. It might worth it if the body of the loop is also optimised, but this is getting into the territory covered by tracing JITs. My kind of approach would try to keep it simple, and that would be helped tremendously by special language constructs (something like Ruby's 100.times) where you can use a streamlined loop, and possible unrolling, straight off. (Personally, if I was creating a byte-code intepreter for Python as-is, I would have a -dynamic:on or -dynamic:off switch.) > Here is one of the oldest: > > http://www.ibm.com/developerworks/library/l-psyco/index.html Yes, I tried that long ago. It's very fast on certain benchmarks. (Both psyco and pypy can run my lexer at around 170Klps. And this is code using string compares and long if-elif chains, that would be crazy in any other language. From that point of view, it's very impressive (I can only get half that speed using the same methods). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-26 13:19 +1100 |
| Message-ID | <56f5f1ba$0$1621$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105711 |
On Sat, 26 Mar 2016 09:08 am, BartC wrote: > On 25/03/2016 16:22, Steven D'Aprano wrote: >> On Fri, 25 Mar 2016 10:06 pm, BartC wrote: > > (OK, I'll risk the wrath of Mark Lawrence et al by daring to post my > opinions.) Please ignore Mark Lawrence when he is acting as an obnoxious troll, as he is now. He occasionally has something useful or helpful to say, but most of the time he thinks he is the self-appointed Guardian of Python's Honour, a job he is singularly ill-equipped for even if Python's honour needed defending, which it doesn't. >>> But it is an optimisation that /could/ be done by the byte-code compiler > >> I would also expect that Victor Stinner's FAT Python project will >> (eventually) look at optimizing such for-loops too. If you see something >> like: >> >> for i in range(N): >> do_stuff() >> >> >> and three conditions hold: >> >> (1) i is unused in the loop body; >> >> (2) range is still bound to the expected built-in function, and no >> other "range" in a nearer scope (say, a local variable called "range", or >> a global) exists to shadow it; and > > The volatility of 'range' I'd completely forgotten about. Python really > doesn't make this stuff easy, does it? True. But it makes *other things* much more easy. Things which are impossible or very difficult in other, stricter languages are trivially easy in Python. > Checking this at runtime, per loop (I don't think it's necessary per > iteration) is a possibility, but now an extra overhead is introduced. It > might worth it if the body of the loop is also optimised, but this is > getting into the territory covered by tracing JITs. Detecting whether or not range has been shadowed or replaced doesn't need a full tracing JIT. Victor's work isn't complete, but preliminary results suggest strongly that the overhead of checking guards will be insignificant. > My kind of approach would try to keep it simple, and that would be > helped tremendously by special language constructs (something like > Ruby's 100.times) where you can use a streamlined loop, and possible > unrolling, straight off. Ruby is an interesting case, because Ruby is even more dynamic than Python. Python doesn't allow you to replace or add methods to built-ins, but Ruby does, so in principle, you have no idea what 100.times is going to do until runtime. That's no different from Python and range. Up until a few years ago, Ruby was considered even slower than Python, by a factor of two or five or so. I'm lead to believe that the latest version of Ruby reverses that, and I've seen claims that it is now faster than Python, but I haven't seen it for myself so I'm not sure if I believe it entirely. > (Personally, if I was creating a byte-code intepreter for Python as-is, > I would have a -dynamic:on or -dynamic:off switch.) > >> Here is one of the oldest: >> >> http://www.ibm.com/developerworks/library/l-psyco/index.html > > Yes, I tried that long ago. It's very fast on certain benchmarks. (Both > psyco and pypy can run my lexer at around 170Klps. And this is code > using string compares and long if-elif chains, that would be crazy in > any other language. From that point of view, it's very impressive (I can > only get half that speed using the same methods). The Python philosophy seems to prefer the use of specialist JIT compilers to speed up bottlenecks rather than language features. I've seen Guido comment that he doesn't believe static AOT optimization is worthwhile in Python and that people should concentrate on JIT optimizations. I suspect he's right. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-26 13:45 -0400 |
| Message-ID | <mailman.50.1459014275.28225.python-list@python.org> |
| In reply to | #105693 |
On Sat, 26 Mar 2016 03:22:58 +1100, Steven D'Aprano <steve@pearwood.info>
declaimed the following:
>(3) and the body of the for-loop has no side-effects that might affect the
>truth of (1)
>
<snip>
>I don't have an intuition on how hard #3 (does the loop body have any
>side-effects that might affect this optimization?) might be, except to say
>that the presence of an eval or exec inside the body will probably make the
>optimization unsafe.
>
Probably very difficult, if the loop is at top-level (making "i" a
module global), and if the loop body can call any function that might
declare "global i" within the same module.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-03-24 20:49 -0600 |
| Message-ID | <mailman.128.1458874165.2244.python-list@python.org> |
| In reply to | #105649 |
On 03/24/2016 04:18 PM, Mark Lawrence wrote: > On 24/03/2016 19:54, BartC wrote: >> On 24/03/2016 18:10, Steven D'Aprano wrote: >>> On Fri, 25 Mar 2016 12:01 am, BartC wrote: >> >>> >>> Then those numbers are pointless. >> >> Yes, they would need some adjustment to do this stuff properly. > > Please give up before you get sued by the families of the people who > have died laughing. Mark, please stop with the disparaging remarks. Just ignore this thread since it bother's you so much. Whether or not you or anyone else disagrees with Bart's programming techniques, his use of Python, or anything else, this is no excuse for name disparaging remarks. If Bart doesn't wish to learn whatever it is you wish to teach, that's his problem. I know you're a long-time poster to this list, but your comments of late have been getting a bit inflammatory. I am a bit amazed that Bart is still willing to communicate on this list after the flack he's got from you and a couple of others. I applaud Steve's voice of reason from time to time on this thread. I've been trying to follow things on this thread, and I understand a bit about Pythonic ideomatic style and I know what Python is really good at and some of what it's not so good at, but it seems like one of Bart's original contentions was that given a certain problem, coded in a non-pythonic way, got slower under Python 3 than it was under Python 2 (if I recall correctly). In other words a performance regression. Somehow this seems to have gotten lost in the squabble over how one should use Python.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-26 02:50 +1100 |
| Subject | Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f55e2e$0$1619$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105649 |
On Fri, 25 Mar 2016 06:54 am, BartC wrote: >> In the case of C, the line is limited to working with some specific type >> (say, an int32). Even there, if the addition might overflow, the >> behaviour is undefined and the compiler can do anything it wants >> (including time travel, > > I'm pretty sure it can't do time travel... > > or erasing your hard disk). You are absolutely, and potentially catastrophically, mistaken on that. Undefined behaviour does not mean "implementation specific behaviour". Nor does it mean "something sensible will happen but we don't promise what it will be". It means "the compiler can do anything", including ignoring the code you actually wrote and substituting its own faster code, which may or may not do what your original code did. We can presume that no non-malicious C compiler will *intentionally* erase your hard drive because you added 1 to an integer without checking for overflow, but it is certainly true that undefined behaviour can lead to any behaviour at all. Undefined behaviour in C is a major cause of bugs and security vulnerabilities. Raymond Chen, one of Microsoft's luminaries, describes how undefined behaviour can travel backwards in time to affect code that executes *before* the undefined behaviour occurs: https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/ Many people assume that if your code has undefined behaviour, you might have no idea what happens from that point on, but at least you can reason correctly about the state of the program prior to that. THIS IS INCORRECT. The C standard makes no such promise, and in fact explicitly states that the effect of undefined behaviour can affect code that runs before the undefined behaviour occurs. Here is an excellent three part article about undefined behaviour: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html And three-parter: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/226 http://blog.regehr.org/archives/232 Bruce Dawson: https://randomascii.wordpress.com/2014/05/19/undefined-behavior-can-format-your-drive/ And I love the title of this talk from Robert C Seacord at CERT: "Dangerous Optimizations and the Loss of Causality" http://bsidespgh.com/2014/media/speakercontent/DangerousOptimizationsBSides.pdf Undefined behaviour in C is a minefield waiting to blow your program's legs off, because the designers of the language made the explicit choice that they wanted the language to be as fast and efficient as possible, even at the cost of safe, reproducible behaviour. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-25 18:57 +0200 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <87wpoq1omm.fsf@elektro.pacujo.net> |
| In reply to | #105692 |
Steven D'Aprano <steve@pearwood.info>: > Undefined behaviour in C is a minefield waiting to blow your program's > legs off, because the designers of the language made the explicit > choice that they wanted the language to be as fast and efficient as > possible, even at the cost of safe, reproducible behaviour. Yes, although the same could be true for Python as well. For example, you could have this program: ===begin poof.py======================================================== assert 1 < 0 ===end poof.py========================================================== When it is run, you might see this: ======================================================================== $ python3 poof.py python3: the VM vanished in a puff of logic while executing 'poof.py' ======================================================================== Java's Hotspot produces very aggressive optimizations, essentially identifying bugs in the code and deducing the coder knows the bugs will never be realized at runtime and so the code paths that lead to the bug can be removed. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-26 13:46 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f5f81d$0$1585$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105696 |
On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:
> Steven D'Aprano <steve@pearwood.info>:
>
>> Undefined behaviour in C is a minefield waiting to blow your program's
>> legs off, because the designers of the language made the explicit
>> choice that they wanted the language to be as fast and efficient as
>> possible, even at the cost of safe, reproducible behaviour.
>
> Yes, although the same could be true for Python as well.
Is this a philosophical question? Yes, it *could* be true, in some alternate
universe, but it isn't actually true.
Python does not have undefined behaviour in the C sense. Like any language
which doesn't have a formal IEEE standard behind it (and even some that
do), it has implementation-specific behaviour, or under- or unspecified
behaviour. But that is not the same as C Undefined Behaviour. Please read
the links I gave.
Culturally, C compiler writers have a preference for using undefined
behaviour to allow optimizations, even if it means changing the semantics
of your code. The C compiler is allowed to ignore your code, move it around
so that things happen in a different order, or add its own code, even if
that changes the semantics of the code.
Python has nothing even remotely like that. If you shoot yourself in the
foot with Python, you can say it is because you didn't understand what your
code would do, but you can't say it is because Python moved code around to
execute it in an unexpected order, or ignored it.
> For example, you could have this program:
>
> ===begin poof.py========================================================
> assert 1 < 0
> ===end poof.py==========================================================
The semantics of "assert condition" are equivalent to:
if __debug__:
if not condition:
raise AssertionError
so assert is intentionally a no-op when Python runs with debug mode disabled
(the -O command-line switch).
> When it is run, you might see this:
>
> ========================================================================
> $ python3 poof.py
> python3: the VM vanished in a puff of logic while executing 'poof.py'
> ========================================================================
I assume that the "vanished" quip is your editorial. Otherwise, the only way
to get that result would be if you linked the python3 executable to
something other than Python 3.
There are only two behaviours a conforming Python interpreter can do
with "poof.py":
- by default, it must raise AssertionError;
- if run with optimizations switched on (debugging mode turned off),
it must do nothing.
Anything else would be a bug in the interpreter or compiler.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-03-25 22:56 -0400 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.16.1458961014.28225.python-list@python.org> |
| In reply to | #105720 |
On Fri, Mar 25, 2016, at 22:46, Steven D'Aprano wrote: > Culturally, C compiler writers have a preference for using undefined > behaviour to allow optimizations, even if it means changing the semantics > of your code. The C compiler is allowed to ignore your code, move it > around > so that things happen in a different order, or add its own code, even if > that changes the semantics of the code. Er, the point of undefined behavior is that your code doesn't *have* semantics.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-25 19:59 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <87io0a6j1w.fsf@nightsong.com> |
| In reply to | #105720 |
Steven D'Aprano <steve@pearwood.info> writes: > Culturally, C compiler writers have a preference for using undefined > behaviour to allow optimizations, even if it means changing the semantics > of your code. If your code has UB then by definition it has no semantics to change. Code with UB has no meaning.
[toc] | [prev] | [next] | [standalone]
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web