Re: [Python-Dev] FAT Python (lack of) performance

About benchmarks ... I've been there and it's not benchmarks that decide whether something succeeds or fails. (I found this old discussion which mentions FIB (also TAK , which is

Re: [Python-Dev] FAT Python (lack of) performance

Please stop. I'm sorry about messing up this thread. I just wanted to represent why I'm very interested in Victor's efforts. Regards. On Thu, Jan 28, 2016 at 4:58 PM, Nick Coghlan wrote: > On 28 January 2016 at 04:40, Sven R. Kunze wrote: > > On

Re: [Python-Dev] FAT Python (lack of) performance

On 28 January 2016 at 18:30, INADA Naoki wrote: > Please stop. > > I'm sorry about messing up this thread. Not your fault at all! This is just a particular bugbear of mine, since software architecture design (including appropriate programming language selection) is an

Re: [Python-Dev] FAT Python (lack of) performance

Brett Cannon writes: > the core team has an implicit understanding that any performance > improvement is taken into consideration in terms of balancing > complexity in CPython with how much improvement it gets us. EIBTI. I can shut up now. Thank you!

Re: [Python-Dev] FAT Python (lack of) performance

On 28 January 2016 at 04:40, Sven R. Kunze wrote: > On 27.01.2016 12:16, Nick Coghlan wrote: >> Umm, no, that's not how this works > That's exactly how it works, Nick. > > INADA uses Python as I use crossroads each day. Daily human business. > > If you read his post carefully,

Re: [Python-Dev] FAT Python (lack of) performance

Terry Reedy writes: > So you agree that the limit of 39 is not intrinsic to the fib function > or its uses, but is an after-the-fact limit imposed to mask the bug > proneness of using substitutes for integers. I don't know what the limit used in the benchmark is, but it must be quite a bit

Re: [Python-Dev] FAT Python (lack of) performance

On 27.01.2016 11:59, Terry Reedy wrote: On 1/26/2016 12:35 PM, Sven R. Kunze wrote: I completely agree with INADA. I an not sure you do. I am sure I am. He wants to solve a problem the way that is natural to him as a unique human being. It's like saying, because a specific crossroad

Re: [Python-Dev] FAT Python (lack of) performance

On 1/27/2016 9:12 AM, Stephen J. Turnbull wrote: Without that knowledge and effort, choosing a programming language based on microbenchmarks is like choosing a car based on the leg-length of the model sitting on the hood in the TV commercial. +1 QOTD

Re: [Python-Dev] FAT Python (lack of) performance

On Wed, 27 Jan 2016 at 10:12 Sven R. Kunze wrote: > On 27.01.2016 11:59, Terry Reedy wrote: > > On 1/26/2016 12:35 PM, Sven R. Kunze wrote: > > I completely agree with INADA. > > > I an not sure you do. > > > I am sure I am. He wants to solve a problem the way that is natural to

Re: [Python-Dev] FAT Python (lack of) performance

On 27.01.2016 12:16, Nick Coghlan wrote: On 27 January 2016 at 03:35, Sven R. Kunze wrote: I completely agree with INADA. It's like saying, because a specific crossroad features a higher accident rate, people need to change their driving behavior. No! People won't change and

Re: [Python-Dev] FAT Python (lack of) performance

On 27.01.2016 19:33, Brett Cannon wrote: And this is why this entire email thread has devolved into a conversation that isn't really going anywhere. This whole thread has completely lost track of the point of Victor's earlier email saying "I'm still working on my FAT work and don't take any

Re: [Python-Dev] FAT Python (lack of) performance

On 27 January 2016 at 03:35, Sven R. Kunze wrote: > I completely agree with INADA. > > It's like saying, because a specific crossroad features a higher accident > rate, people need to change their driving behavior. > No! People won't change and it's not necessary either. The

Re: [Python-Dev] FAT Python (lack of) performance

On 1/26/2016 12:51 PM, Stephen J. Turnbull wrote: Terry Reedy writes: > On 1/26/2016 12:02 AM, INADA Naoki wrote: > > > People use same algorithm on every language when compares base language > > performance [1]. > > The python code is NOT using the same algorithm. The proof is that

Re: [Python-Dev] FAT Python (lack of) performance

Python has test_dynamic which tests such corner cases. For example, test_modify_builtins_while_generator_active(): "Modify the builtins out from under a live generator." https://hg.python.org/cpython/file/58266f5101cc/Lib/test/test_dynamic.py#l49 Victor 2016-01-27 10:28 GMT+01:00 Paul Moore

Re: [Python-Dev] FAT Python (lack of) performance

On 27 January 2016 at 05:23, Sjoerd Job Postmus wrote: > On Mon, Jan 25, 2016 at 11:58:12PM +0100, Victor Stinner wrote: >> ... >> Oh, they are a lot of things to do! ... > > Just wondering, do you also need a set of (abusive) test-cases which > check 100% conformity to the

Re: [Python-Dev] FAT Python (lack of) performance

On 1/26/2016 12:35 PM, Sven R. Kunze wrote: I completely agree with INADA. I an not sure you do. It's like saying, because a specific crossroad features a higher accident rate, *people need to change their driving behavior*. *No!* People won't change and it's not necessary either. The

Re: [Python-Dev] FAT Python (lack of) performance

On 26 January 2016 at 17:16, Stephen J. Turnbull wrote: > Our universities are doing an awful job at getting "big picture thinking" > across to our students. That problem isn't specific to Japan - I'm not aware of *anywhere* that does a particularly good job of teaching

Re: [Python-Dev] FAT Python (lack of) performance

On Mon, Jan 25, 2016 at 11:58:12PM +0100, Victor Stinner wrote: > ... > Oh, they are a lot of things to do! ... Just wondering, do you also need a set of (abusive) test-cases which check 100% conformity to the CPython semantics? I'm sure many of us would be able to whip up some ideas of things

Re: [Python-Dev] FAT Python (lack of) performance

On 1/26/2016 12:02 AM, INADA Naoki wrote: People use same algorithm on every language when compares base language performance [1]. The python code is NOT using the same algorithm. The proof is that the Python function will return the correct value for, say fib(50) while most if not all the

Re: [Python-Dev] FAT Python (lack of) performance

On January 25, 2016 9:59:36 PM CST, Chris Angelico wrote: >On Tue, Jan 26, 2016 at 2:32 PM, INADA Naoki >wrote: >> >> I know. >> But people compares language speed by simple microbench like >fibbonacci. >> They doesn't use listcomp or libraries to

Re: [Python-Dev] FAT Python (lack of) performance

Hi, 2016-01-26 3:21 GMT+01:00 INADA Naoki : > How can I help your work? I don't know exactly yet, but I started to write a documentation to explain how to contribute: http://faster-cpython.readthedocs.org/fat_python.html#how-can-you-contribute You may contact me directly

Re: [Python-Dev] FAT Python (lack of) performance

On Wed, Jan 27, 2016 at 2:28 AM, Ryan Gonzalez wrote: >>rosuav@sikorsky:~$ gcc fib.c && time ./a.out >>1134903170 >> >>real 0m9.104s >>user 0m9.064s >>sys 0m0.000s >>rosuav@sikorsky:~$ cat fib.c >>#include >> >>unsigned long fib(unsigned long n) >>{ >>if (n < 2) return n;

Re: [Python-Dev] FAT Python (lack of) performance

Hi, will look into it soon. :) Best, Sven On 26.01.2016 16:32, Victor Stinner wrote: Hi, 2016-01-26 3:21 GMT+01:00 INADA Naoki : How can I help your work? I don't know exactly yet, but I started to write a documentation to explain how to contribute:

Re: [Python-Dev] FAT Python (lack of) performance

I completely agree with INADA. It's like saying, because a specific crossroad features a higher accident rate, *people need to change their driving behavior*. *No!* People won't change and it's not necessary either. The crossroad needs to be changed to be safer. Same goes for Python. If

Re: [Python-Dev] FAT Python (lack of) performance

Nick Coghlan writes: > On 26 January 2016 at 17:16, Stephen J. Turnbull wrote: > > Our universities are doing an awful job at getting "big picture > > thinking" across to our students. > > That problem isn't specific to Japan - I'm not aware of *anywhere* > that does a

Re: [Python-Dev] FAT Python (lack of) performance

Terry Reedy writes: > On 1/26/2016 12:02 AM, INADA Naoki wrote: > > > People use same algorithm on every language when compares base language > > performance [1]. > > The python code is NOT using the same algorithm. The proof is that the > Python function will return the correct value

Re: [Python-Dev] FAT Python (lack of) performance

On Jan 25, 2016, at 19:32, INADA Naoki wrote: > >> On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert wrote: >> On Jan 25, 2016, at 18:21, INADA Naoki wrote: >> > >> > I'm very interested in it. >> > >> > Ruby 2.2 and PHP 7 are

Re: [Python-Dev] FAT Python (lack of) performance

Do you say I and many people are so fool? People use same algorithm on every language when compares base language performance [1]. [1] There are no solid definition about "Base language performance". But it includes function call, method lookup, GC. It may include basic string and arithmetic

Re: [Python-Dev] FAT Python (lack of) performance

INADA Naoki writes: > For example, http://benchmarksgame.alioth.debian.org/u64q/php.html > In Japanese, many people compares language performance by > microbench like fibbonacci. True enough. But as a teacher in a Japanese engineering school, I am ashamed to see that posted to a public list.

Re: [Python-Dev] FAT Python (lack of) performance

On Tue, Jan 26, 2016 at 2:32 PM, INADA Naoki wrote: > > I know. > But people compares language speed by simple microbench like fibbonacci. > They doesn't use listcomp or libraries to compare *language* speed. > Well, that's a stupid way to decide on a language. Here,

Re: [Python-Dev] FAT Python (lack of) performance

On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert wrote: > On Jan 25, 2016, at 18:21, INADA Naoki wrote: > > > > I'm very interested in it. > > > > Ruby 2.2 and PHP 7 are faster than Python 2. > > Python 3 is slower than Python 2. > > Says who? > For

Re: [Python-Dev] FAT Python (lack of) performance

On January 25, 2016 9:32:07 PM CST, INADA Naoki wrote: >On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert >wrote: > >> On Jan 25, 2016, at 18:21, INADA Naoki >wrote: >> > >> > I'm very interested in it. >> > >> > Ruby 2.2 and

Re: [Python-Dev] FAT Python (lack of) performance

On Tue, Jan 26, 2016 at 2:44 PM, Andrew Barnert wrote: > On Jan 25, 2016, at 19:32, INADA Naoki wrote: > > On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert > wrote: > >> On Jan 25, 2016, at 18:21, INADA Naoki

[Python-Dev] FAT Python (lack of) performance

Hi, Summary: FAT Python is not faster, but it will be ;-) -- When I started the FAT Python as a fork of CPython 3.6, I put everything in the same repository. Last weeks, I focused on splitting my giant patch (10k lines) into small reviewable patches. I wrote 3 PEP (509 dict version, 510

Re: [Python-Dev] FAT Python (lack of) performance

Hi Victor, I encourage you to proceed here. I would love to see your PEPs (509-511) incorporated into CPython. It's not that I consider Python slow (although some folks claim so), but performance improvements are always welcome; especially when I glance over diagrams like those:

Re: [Python-Dev] FAT Python (lack of) performance

Hi, Just thanks for this big contribution. And maybe this project could give new ideas to optimize Python, who knows ? At least, you've win a beer for the FOSDEM event this week-end ;-) Have a nice week. -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ 2016-01-25 19:16 GMT+01:00 Victor Stinner

Re: [Python-Dev] FAT Python (lack of) performance

Hi, 2016-01-25 22:20 GMT+01:00 Ludovic Gasc : > Just thanks for this big contribution. > And maybe this project could give new ideas to optimize Python, who knows ? Sorry for my long email. I should try to summarize next time :-) In short: FAT Python is not fast today, but it

Re: [Python-Dev] FAT Python (lack of) performance

On Jan 25, 2016, at 13:43, Victor Stinner wrote: > > According to microbenchmarks, the most promising optimizations are > functions inlining (Python function calls are slow :-/) and specialize > the code for the type of arguments. Can you specialize a function with a C

Re: [Python-Dev] FAT Python (lack of) performance

On Jan 25, 2016, at 14:46, Victor Stinner wrote: > > You can design an AST optimizer to compile some functions to C and > then register them as specialized code at runtime. I have a side > project to use Cython and/or pythran to specialize some functions > using type

Re: [Python-Dev] FAT Python (lack of) performance

On Jan 25, 2016, at 07:16 PM, Victor Stinner wrote: >Barry also wrote: "Did you address my suggestion on python-ideas to >make the new C API optionally compiled in?" > >Well, it is an option, but I would prefer to have the API for AST >optimizer directly built in Python. In my plan, it would be,

Re: [Python-Dev] FAT Python (lack of) performance

On Mon, 25 Jan 2016 at 14:30 Andrew Barnert via Python-Dev < python-dev@python.org> wrote: > On Jan 25, 2016, at 13:43, Victor Stinner > wrote: > > > > According to microbenchmarks, the most promising optimizations are > > functions inlining (Python function calls are

Re: [Python-Dev] FAT Python (lack of) performance

Hi, 2016-01-25 23:28 GMT+01:00 Andrew Barnert : > On Jan 25, 2016, at 13:43, Victor Stinner wrote: >> >> According to microbenchmarks, the most promising optimizations are >> functions inlining (Python function calls are slow :-/) and specialize >>

Re: [Python-Dev] FAT Python (lack of) performance

2016-01-25 22:51 GMT+01:00 Sven R. Kunze : > - they provide a great infrastructure for optimizing CPython AND > extending/experimenting Python as an ecosystem I hope that these API will create more optimizer projects than just fatoptimizer. For example, I expect more specialized

Re: [Python-Dev] FAT Python (lack of) performance

I'm very interested in it. Ruby 2.2 and PHP 7 are faster than Python 2. Python 3 is slower than Python 2. Performance is a attractive feature. Python 3 lacks it. How can I help your work? On Tue, Jan 26, 2016 at 7:58 AM, Victor Stinner wrote: > 2016-01-25 22:51

Re: [Python-Dev] FAT Python (lack of) performance

On Mon, 25 Jan 2016 at 18:22 INADA Naoki wrote: > I'm very interested in it. > > Ruby 2.2 and PHP 7 are faster than Python 2. > Python 3 is slower than Python 2. > Performance is a attractive feature. Python 3 lacks it. > That is not a fair statement to make about

Re: [Python-Dev] FAT Python (lack of) performance

On Jan 25, 2016, at 18:21, INADA Naoki wrote: > > I'm very interested in it. > > Ruby 2.2 and PHP 7 are faster than Python 2. > Python 3 is slower than Python 2. Says who? That was certainly true in the 3.2 days, but nowadays, most things that differ seem to be faster