Re: Static typing [was Re: Python and the need for speed]
Gregory Ewing writes: > A JIT compiler works by observing the actual values To be pedantic, that's called a "tracing JIT". Other runtime code generation is also frequently called JIT compilation even when it's fairly stupid combining of assembly code templates, or the like. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
Steve D'Aprano wrote: You seem to be describing a *tracing JIT* compiler. Well, yes, but it seems to me that a JIT compiler that *doesn't* use tracing is just an AOT compiler that you happen to run immediately before executing the program. Cython doesn't do any of that -- it's just a plain, boring, standard ahead-of-time compiler that goes by the type info you give it and nothing more. That cannot be the full story, because Cython can optimize some regular, unannotated Python code. Maybe, but the point is that it does it using only information present in the source. Also, it's usually run once ahead of time to generate object code that's stored. I think we may be using different definitions of "JIT". If you define it simply as running the compiler just before you execute the code, then *some* ways of using Cython might *barely* qualify -- you can set things up so that a Python import will trigger compiling Cython code if necessary. But that doesn't seem like a useful way of defining JIT to me. Such a compiler is not a different kind of beast from an AOT compiler. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Tue, 18 Apr 2017 03:43 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> I'm not sure why the Cython devs maintain this is not a JIT compiler. >> Perhaps I misunderstand something. > > A JIT compiler works by observing the actual values taken on > by variables at run time, and if it notices that a particular > variable seems to always have a particular type, it compiles > a special version of the code to handle that type, protected > by appropriate guards. You seem to be describing a *tracing JIT* compiler. > Cython doesn't do any of that -- it's just a plain, boring, > standard ahead-of-time compiler that goes by the type info > you give it and nothing more. That cannot be the full story, because Cython can optimize some regular, unannotated Python code. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
Steve D'Aprano wrote: I'm not sure why the Cython devs maintain this is not a JIT compiler. Perhaps I misunderstand something. A JIT compiler works by observing the actual values taken on by variables at run time, and if it notices that a particular variable seems to always have a particular type, it compiles a special version of the code to handle that type, protected by appropriate guards. Cython doesn't do any of that -- it's just a plain, boring, standard ahead-of-time compiler that goes by the type info you give it and nothing more. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Mon, 17 Apr 2017 08:52 pm, Steve D'Aprano wrote: > but research does continue into using gradual typing for optimizations: > > http://dl.acm.org/citation.cfm?id=2069175 Another interesting research project into speeding up Jython using type hints: http://scholar.colorado.edu/ecen_gradetds/57/ and more about gradual typing in Python: http://homes.soic.indiana.edu/mvitouse/talks/stop12.pdf -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
Steve D'Aprano writes: > On the other hand, there's Cython. Cython claims *not* to be a JIT compiler, One of the uses of "JIT compiler" these days is what's sometimes called a tracing JIT, like PyPy or LuaJIT or the Javascript flavor-of-the-week. That means it interprets the program while collecting execution traces to figure out the actual types the program uses at runtime, then generates machine code for those specific code paths, with some guards in case an unexpectedly typed value shows up. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Mon, 17 Apr 2017 04:18 pm, Paul Rubin wrote: > Steve D'Aprano writes: >> Since it is *optional*, it is only a hint, not a fact. You can tell the >> compiler that you believe that n will be an int, but it's not guaranteed. > > The runtime could check at the entry to the function that n is an int, > and then it wouldn't have to keep re-checking on the inside of a loop. > That's what a JIT compiler does in the absence of annotations, more or > less; Funnily enough, in the very post you quote, I did write: "There are clever Just In Time compiler tricks that can optimize the code, which is what Psycho did and PyPy still does, but they don't need type hints." The reason being that at runtime the compiler knows the type of the value and the type hint is redundant. On the other hand, there's Cython. Cython claims *not* to be a JIT compiler, but I don't really understand why. As I understand it, Cython can operate in two ways: (1) as a Python interpreter, with some optimizations switched on or off at runtime according to the types and/or values actually used by the program; (2) as a pseudo-Python to C compiler, allowing you to write Python-ish code that is compiled to C (plus a Python runtime for anything that's too hard to translate into C). I'm not sure why the Cython devs maintain this is not a JIT compiler. Perhaps I misunderstand something. > but the annotations make life easier for ahead-of-time compilers. > Again this type of thing has been standard in Lisp since the 1960's. Indeed it has. The state of the art of optimizations for dynamically typed languages has been badly neglected for many years. Fortunately in the last decade or so there's been a lot more interest in this. See, for example, Steve Yegge: http://steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Sun, 16 Apr 2017 02:27 pm, Steve D'Aprano wrote: > Are you aware that optional static typing CANNOT be used for optimization? I think I've over-stated that. Considerably. In other words, I was wrong. As Steve Yegge points out, dynamic languages like Smalltalk and Lisp were, back in the 1980s, heavily optimized and were competitive with statically-typed languages like C: http://steve-yegge.blogspot.com.au/2008/05/dynamic-languages-strike-back.html While this is true: > Since it is *optional*, it is only a hint, not a fact. You can tell the > compiler that you believe that n will be an int, but it's not guaranteed. > As the Dude says, the type hint is > > that's, like, only your opinion man > > and the compiler cannot trust it. It must still guard the operation with a > runtime check that n actually is an int, The conclusion that I drew: > and so you lose most or all of > the benefit of telling the compiler that it's an int. is not necessarily the case. If you're doing lots of little operations on disparate variables, with lots and lots of guard checks and not much optimized code, it will go badly for you, but on the other hand for big loops with only a few up-front checks and predictable types, there may be opportunities for optimization. Honestly, I'm not quite sure what I was thinking: that sort of "optimized code with a guard" is exactly what Psycho does, and what FATPython is hoping to bring to CPython some day. At the present time, the state of the art of gradual typing is still keeping the emphasis on optional static typing for *correctness*, not optimization: http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/ but research does continue into using gradual typing for optimizations: http://dl.acm.org/citation.cfm?id=2069175 [...] > Python's gradual typing is not about optimization, it is about testing > program correctness and helping to find bugs at compile time*. That's the motivation for MyPy. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
Steve D'Aprano writes: > Since it is *optional*, it is only a hint, not a fact. You can tell the > compiler that you believe that n will be an int, but it's not guaranteed. The runtime could check at the entry to the function that n is an int, and then it wouldn't have to keep re-checking on the inside of a loop. That's what a JIT compiler does in the absence of annotations, more or less; but the annotations make life easier for ahead-of-time compilers. Again this type of thing has been standard in Lisp since the 1960's. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Mon, 17 Apr 2017 05:16 am, bartc wrote: > But it was OK for Steve to 'win' the benchmark by substituting my test > code with something only vaguely related, and much simpler? Okay, you're now being obnoxious, and telling lies about me. What I said was "FOR WHAT IT'S WORTH [emphasis added], on my machine (2GB RAM and 1.2GHz CPU) I can add up 100 million ints in 14 seconds" which is just to give an indication of the speed of my machine. I wasn't trying to "win" your stupid, inefficient benchmark. If I was, would I then have run *your code* and report a time nearly three times longer than you? "time taken: 93.543194 seconds" How is this me winning by running different code? You also ignored the entire point of my post, which is to comment on Justin's generator version: "If I can run Bart's test on my slow old computer in a minute and a half, my guess is that your generator must have been doing something terribly wrong to still not be complete after six minutes." and misrepresent me as doing something underhanded and dishonorable to "win". And that, Bart, is dirty pool. I don't think you're arguing in good faith. I've spent months defending your right to criticise Python on this forum even when others have wanted you banned (an excessive reaction) or have kill-filed you so they don't see your posts. Even when I disagree with your conclusions, even if I think they are terribly naive, the sorts of things a lone cowboy developer can get away with but not suitable for a mature, widely used language like Python, I've respected your point of view. But at this point, I think *you* are being dishonest. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Mon, Apr 17, 2017 at 5:16 AM, bartc wrote: > On 16/04/2017 20:00, Chris Angelico wrote: >> >> On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote: > > >> Sure! If all you care about is winning benchmarks, > > > The benchmarks should be about comparing things. But they have to be like > for like. You're the one who suggested using a formula to calculate the sum of a sequence of integers. > But it was OK for Steve to 'win' the benchmark by substituting my test > code with something only vaguely related, and much simpler? Steven was, far as I can tell, reimplementing the same algorithm in more Pythonic code. But I'm not sure. I didn't look at the details. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On 16/04/2017 20:00, Chris Angelico wrote: On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote: Sure! If all you care about is winning benchmarks, The benchmarks should be about comparing things. But they have to be like for like. Since this was about the effects of type annotations, it would be interesting to see how they would affect timings in the Python example. (I showed the affect on another language, where I got a factor of about 100:1 between slowest and fastest by using type declarations. A bit of a cheat though as the typed language was really a separate one.) you could easily create a sum() that recognizes when it's given a range object. Let's start with a baseline. I took the code from the link Steven posted (and renamed Timer to Stopwatch), and: 49995000 time taken: 1.143872 seconds Ehh, too fast. It is fast. My Python 3.4 on Intel 3.2GHz took 6 seconds. Even pypy took over 4 seconds. time taken: 0.16 seconds Hey look! We win at benchmarks. But it was OK for Steve to 'win' the benchmark by substituting my test code with something only vaguely related, and much simpler? -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Mon, Apr 17, 2017 at 4:43 AM, bartc wrote: >> >> For what it's worth, on my machine (2GB RAM and 1.2GHz CPU) I can add up >> 100 >> million ints in 14 seconds: >> >> py> with Stopwatch(): >> ... sum(range(1)) >> ... >> 49995000 >> time taken: 14.032116 seconds > > > I'm surprised it took that long. If a 'range' is no longer expanded to a > list, and 'sum' is built-in, isn't there a formula that can be used to sum a > sequence? At least when the step is +1. Sure! If all you care about is winning benchmarks, you could easily create a sum() that recognizes when it's given a range object. Let's start with a baseline. I took the code from the link Steven posted (and renamed Timer to Stopwatch), and: 49995000 time taken: 1.143872 seconds Ehh, too fast. I'll add another zero onto it. 45 time taken: 11.413530 seconds Better. Now then. _orig_sum = sum def sum(iterable, start=0): if isinstance(iterable, range) and iterable.step == 1: # I don't feel like dealing with non-unity steps n = iterable.stop * (iterable.stop - 1) // 2 if iterable.start: n -= iterable.start * (iterable.start + 1) // 2 return start + n return _orig_sum(iterable, start) 45 time taken: 0.16 seconds Hey look! We win at benchmarks. Of course, to do this, I had to make every other sum() call slightly slower (maybe not a lot, but slower by the price of one instance check at best), but what a benefit! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On 16/04/2017 18:13, Steve D'Aprano wrote: On Mon, 17 Apr 2017 02:20 am, justin walters wrote: On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote: What were the results with Python on your machine? Well, at first I tried to implement it with a generator. I gave up on waiting for the program to complete after about 6 minutes. That seems... excessive. For what it's worth, on my machine (2GB RAM and 1.2GHz CPU) I can add up 100 million ints in 14 seconds: py> with Stopwatch(): ... sum(range(1)) ... 49995000 time taken: 14.032116 seconds I'm surprised it took that long. If a 'range' is no longer expanded to a list, and 'sum' is built-in, isn't there a formula that can be used to sum a sequence? At least when the step is +1. factor of ten between friends? Of course the built-in sum() is a bit faster than the version Bart uses. It's almost like he is deliberately writing the least efficient Python code he can... (or maybe he just doesn't know Python very well). Yes, it was low-level code, which is a large part of what optimising a language is about. You can't always write just high-level code that calls fast built-in routines; sometimes the language has to do some actual work of its own! And the same algorithm (if you can call it that) was used in all the examples. That it wasn't doing anything meaningful is not important; it is testing the same mechanisms that would be involved in a real program. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Mon, 17 Apr 2017 02:20 am, justin walters wrote: > On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote: > >> What were the results with Python on your machine? > > > > Well, at first I tried to implement it with a generator. I gave up on > waiting for the program to complete > after about 6 minutes. That seems... excessive. For what it's worth, on my machine (2GB RAM and 1.2GHz CPU) I can add up 100 million ints in 14 seconds: py> with Stopwatch(): ... sum(range(1)) ... 49995000 time taken: 14.032116 seconds which isn't fast but it's within an order of magnitude of fast. What's a factor of ten between friends? Of course the built-in sum() is a bit faster than the version Bart uses. It's almost like he is deliberately writing the least efficient Python code he can... (or maybe he just doesn't know Python very well). Here's his version again (slightly adapted): def add(a, b): return a + b def testfn(): total = a = b = 0 for i in range(1): total += add(a, b) a += 1 b += 2 return (a, b, total) And the results: py> with Stopwatch(): ... testfn() ... (1, 2, 149985000) time taken: 93.543194 seconds If I can run Bart's test on my slow old computer in a minute and a half, my guess is that your generator must have been doing something terribly wrong to still not be complete after six minutes. The timer I used (Stopwatch) is basically this: http://code.activestate.com/recipes/577896-benchmark-code-with-the-with-statement/ > After using your code almost exactly I get: Sum: 149985000 ***Execution Time: 17.33912420272827 *** > > That's with Python 3.5 on an Intel I5-6600k 3.9Ghz cpu and 16GB DDR4 > memory. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Sun, Apr 16, 2017 at 8:46 AM, bartc wrote: > What were the results with Python on your machine? Well, at first I tried to implement it with a generator. I gave up on waiting for the program to complete after about 6 minutes. After using your code almost exactly I get: >>> Sum: 149985000 >>> ***Execution Time: 17.33912420272827 *** That's with Python 3.5 on an Intel I5-6600k 3.9Ghz cpu and 16GB DDR4 memory. > (Nice-looking language, I hadn't heard of it.) Yeah, it's pretty neat. Some parts of Nim aren't really production ready yet, but I think it has a bright future. proc test() = > var > sum = 0 > a = 0 > b = 0 > for i in 0..<1: > > Loop iterations should be 100 million, if this is one less. Missing one out > won't affect the timing, but will give a different result if comparing > implementations to see if they do the same thing. > It's not one less. It will execute exactly 100 million times. Meaning it will execute when i is 99,999,999 but not when i is 100,000,000. This gives exactly 100,000,000 iterations including the iteration for i = 0. It could alternatively be written as: for i in 1..1: Didn't realize I had messed up the increment on var b with my Nim implementation! Fixed: === import times proc add(a, b: int): int = result = a + b proc test() = var sum = 0 a = 0 b = 0 for i in 0..<1: sum += add(a, b) a += 1 b += 2 echo "a: " & $a & " b: " & $b & "\n" echo "Sum: " & $sum when isMainModule: var t0 = cpuTime() test() var t1 = cpuTime() echo "***Execution Time: " & $(t1 - t0) & "***\n" === The above Nim code is a tad bit slower with the larger var b: >>> a: 1 b: 2 >>> Sum: 149985000 >>> ***Execution Time: 2.888533*** With Speed Optimization: >>> a: 1 b: 2 >>> Sum: 149985000 >>> ***Execution Time: 2.843629*** With size optimization: >>> a: 1 b: 2 >>> Sum: 149985000 >>> ***Execution Time: 2.844876*** Compiled with release flag: >>> a: 1 b: 2 >>> Sum: 149985000 >>> ***Execution Time: 2.842312*** > Hmm, the optimiser is similar to mine then! I'm pretty new when it comes to compilers. Been trying to learn more and build my own but progress is fairly slow. I'm not sure what `nimc` is doing under the hood, but I do know that it transpiles to C before running either `gcc` or `clang`. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On 16/04/2017 16:00, justin walters wrote: On Sun, Apr 16, 2017 at 3:55 AM, bartc wrote: Example C of the same silly program in Python: def add(a,b): return a+b def testfn(): sum=a=b=0 for i in range(1): sum += add(a,b) a += 1 b += 2 print (a,b,sum) testfn() Timings: A (Pure HLL**) 13 seconds (dynamic/interpreted) A (With ASM module) 3 B (my compiler) 0.5 (static/compiled) C (Python 2/xrange) 30 C (Python 3)38 C (Pypy) 5 Just for fun I wanted to write this up in Nim to compare execution time. Nim has Python-esqe syntax but is statically (Nice-looking language, I hadn't heard of it.) typed and compiled. I think this is relevant to the discussion. Code looks like this: ``` import times proc add(a, b: int): int = result = a + b proc test() = var sum = 0 a = 0 b = 0 for i in 0..<1: Loop iterations should be 100 million, if this is one less. Missing one out won't affect the timing, but will give a different result if comparing implementations to see if they do the same thing. With 100M, the results are (of a,b and sum): 1 2 149985000 sum += add(a, b) a += 1 b += 1 b += 2, both to the ensure the same output, and in case there's a sneaky optimisation it can do for b+=1... echo "a: " & $a & " b: " & $b & "\n" echo "Sum: " & $sum when isMainModule: var t0 = cpuTime() test() var t1 = cpuTime() echo "***Execution Time: " & $(t1 - t0) & "***\n" ``` No optimization: ***Execution Time: 2.876923*** Optimized for speed: ***Execution Time: 2.844163*** Optimized for size: ***Execution Time: 2.844901*** Hmm, the optimiser is similar to mine then! Release option: ***Execution Time: 2.844021*** So, generally around 2.8 seconds. Not too bad for a GC'd language. There are probably some more optimizations I could make to improve execution time. What were the results with Python on your machine? -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Sun, Apr 16, 2017 at 3:55 AM, bartc wrote: > Example C of the same silly program in Python: > > def add(a,b): > return a+b > > def testfn(): > sum=a=b=0 > for i in range(1): > sum += add(a,b) > a += 1 > b += 2 > > print (a,b,sum) > > testfn() > > > Timings: > > A (Pure HLL**) 13 seconds (dynamic/interpreted) > A (With ASM module) 3 > A (With ASM module) 2(older version; hmmm...) > > B (my compiler) 0.5 (static/compiled) > B (via C/gcc-O3) 0.14 > > C (Python 2) 163 > C (Python 2/xrange) 30 > C (Python 3)38 > C (Pypy) 5 > Just for fun I wanted to write this up in Nim to compare execution time. Nim has Python-esqe syntax but is statically typed and compiled. I think this is relevant to the discussion. Code looks like this: ``` import times proc add(a, b: int): int = result = a + b proc test() = var sum = 0 a = 0 b = 0 for i in 0..<1: sum += add(a, b) a += 1 b += 1 echo "a: " & $a & " b: " & $b & "\n" echo "Sum: " & $sum when isMainModule: var t0 = cpuTime() test() var t1 = cpuTime() echo "***Execution Time: " & $(t1 - t0) & "***\n" ``` No optimization: ***Execution Time: 2.876923*** Optimized for speed: ***Execution Time: 2.844163*** Optimized for size: ***Execution Time: 2.844901*** Release option: ***Execution Time: 2.844021*** So, generally around 2.8 seconds. Not too bad for a GC'd language. There are probably some more optimizations I could make to improve execution time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Sun, Apr 16, 2017 at 8:55 PM, bartc wrote: > On 16/04/2017 05:27, Steve D'Aprano wrote: >> >> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: >> >>> apparently, the py-devs believe we >>> only deserve type declarations that do nothing to speed up >>> code execution (aka: type-hints), instead of type >>> declarations that could actually speed up the code. Go >>> figure! >>> >>> I'm not a fan of forced static typing, but i am a fan of >>> optional static typing. >> >> >> Are you aware that optional static typing CANNOT be used for optimization? >> >> Since it is *optional*, it is only a hint, not a fact. You can tell the >> compiler that you believe that n will be an int, but it's not guaranteed. > > > No, Rick distinguished between hints, and actual declarations. It doesn't > matter if the latter are optional. > > I played around with this at one time. All variables were of type 'variant', > unless they had an explicit type declaration. All of this is ignoring one very important point: subclassing. If I declare a variable "int", can it or can it not accept a subclass of int? Hint: neither answer is correct for the general case. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On 16/04/2017 05:27, Steve D'Aprano wrote: On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: apparently, the py-devs believe we only deserve type declarations that do nothing to speed up code execution (aka: type-hints), instead of type declarations that could actually speed up the code. Go figure! I'm not a fan of forced static typing, but i am a fan of optional static typing. Are you aware that optional static typing CANNOT be used for optimization? Since it is *optional*, it is only a hint, not a fact. You can tell the compiler that you believe that n will be an int, but it's not guaranteed. No, Rick distinguished between hints, and actual declarations. It doesn't matter if the latter are optional. I played around with this at one time. All variables were of type 'variant', unless they had an explicit type declaration. But it got complicated. I decided to keep the dynamic language pure, as after all I had a statically compiled language with exactly the same syntax if I needed it faster! Examples A and B here: https://pastebin.com/D89zP3LF Example C of the same silly program in Python: def add(a,b): return a+b def testfn(): sum=a=b=0 for i in range(1): sum += add(a,b) a += 1 b += 2 print (a,b,sum) testfn() Timings: A (Pure HLL**) 13 seconds (dynamic/interpreted) A (With ASM module) 3 A (With ASM module) 2(older version; hmmm...) B (my compiler) 0.5 (static/compiled) B (via C/gcc-O3) 0.14 C (Python 2) 163 C (Python 2/xrange) 30 C (Python 3)38 C (Pypy) 5 (Python 2 with 'range' locked up my machine for nearly 3 minutes because it presumably exhausted the 4GB memory just executing a simple loop. Have I mentioned that building a massive list just to execute 'for' was a stupid idea?) The pypy timing is not bad, however it is misleading: you can't for example deduce the execution time of one iteration by dividing by 100 million, as you can with the others (gcc-O3 excepted as I've no idea what it does). You only get that timing if you actually wanted 100 million iterations. (That doesn't necessarily mean that you have to use type declarations, like in C, Pascal and Java. A good modern compiler can infer types, like in ML and Haskell.) Yes a good, but more sophisticated, compiler. Unlike mine! (** The pure HLL timing might be reduced to ~ 9 seconds using 'label-pointers' for dispatching, but this limited portability when converted to C code, as not all C compilers support them. But it doesn't matter as I can use the ASM version for speed. I believe CPython also makes use of label-pointers when compiled with gcc - as happens on Linux - but not when compiled with MSVC, so that CPython on Windows is a little slower for that reason. I don't know if this is still the case. Those Python timings were on Windows...) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Sun, 16 Apr 2017 09:48:15 +, alister wrote: > On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote: > >> On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: >> >>> apparently, the py-devs believe we only deserve type declarations that >>> do nothing to speed up code execution (aka: type-hints), instead of >>> type declarations that could actually speed up the code. Go figure! >>> >>> I'm not a fan of forced static typing, but i am a fan of optional >>> static typing. >> >> Are you aware that optional static typing CANNOT be used for >> optimization? >> >> Since it is *optional*, it is only a hint, not a fact. You can tell the >> compiler that you believe that n will be an int, but it's not >> guaranteed. As the Dude says, the type hint is >> >> that's, like, only your opinion man >> >> and the compiler cannot trust it. It must still guard the operation >> with a runtime check that n actually is an int, and so you lose most or >> all of the benefit of telling the compiler that it's an int. >> >> There are clever Just In Time compiler tricks that can optimize the >> code, which is what Psycho did and PyPy still does, but they don't need >> type hints. Type hints are superfluous to a JIT compiler, since it >> already knows the runtime type information. But JIT compilers have >> their limitations, like the necessity of warm up time, increased >> complexity, and much heavier memory requirements. >> >> If you want to use type hints for the purposes of compile-time >> optimizations, then typing must be compulsory and enforced by the >> compiler. >> No longer optional hints, but mandatory statements of indisputable >> fact. >> >> (That doesn't necessarily mean that you have to use type declarations, >> like in C, Pascal and Java. A good modern compiler can infer types, >> like in ML and Haskell.) >> >> Python's gradual typing is not about optimization, it is about testing >> program correctness and helping to find bugs at compile time*. As such, >> the fact that type hints are optional and "only your opinion" doesn't >> matter. The promise made by the type checker is: >> >> IF what you say is true (the type hints are correct) >> THEN this code will be sound >> >> (or alternatively, it's unsound because you have a type mismatch, and >> get a compile-time error). As a fallback, you still have the runtime >> dynamic type checks. >> >> Unit and functional tests are great, and necessary. Just because your >> code compiles in C, Java or Pascal doesn't mean that it is correct. You >> still have to run the code and test that it does what you expect. >> >> "It compiles! Quick, ship it!" -- attributed to Microsoft developers >> >> Nevertheless, the problem with testing is that it can only prove the >> presence of bugs, not their absence. A test that fails proves that your >> code has at least one bug. A test that passes doesn't prove that there >> are no bugs. >> >> Static type checking helps to shrink the gap between "all of my tests >> pass, >> so there are no known bugs" and "there are no unknown bugs". And that's >> an important and powerful tool, especially for large and complex >> programs. >> >> Python's type-hints are for writing correct code, not fast code. I find >> it amusing when people argue that Python's type hints are pointless or >> useless. Do they realise they're effectively arguing that correct, >> bug-free code is pointless? >> >> "Your code is buggy. It calculates the wrong result." >> >> "Maybe so, but look how fast it does it!" > > I think you have (deliberately?) miss understood RR by optional Static > typing I think he means you don't have to use it as is in suing static > types is optional) but when you define a variable as static then its > type is fixed, not simply a hint. > > whether or not this could increase code deficiency or complicate the > compiler further I have no idea Actually isn't this a feature of cython? -- Armadillo: To provide weapons to a Spanish pickle. -- https://mail.python.org/mailman/listinfo/python-list
Re: Static typing [was Re: Python and the need for speed]
On Sun, 16 Apr 2017 14:27:28 +1000, Steve D'Aprano wrote: > On Sat, 15 Apr 2017 11:55 am, Rick Johnson wrote: > >> apparently, the py-devs believe we only deserve type declarations that >> do nothing to speed up code execution (aka: type-hints), instead of >> type declarations that could actually speed up the code. Go figure! >> >> I'm not a fan of forced static typing, but i am a fan of optional >> static typing. > > Are you aware that optional static typing CANNOT be used for > optimization? > > Since it is *optional*, it is only a hint, not a fact. You can tell the > compiler that you believe that n will be an int, but it's not > guaranteed. As the Dude says, the type hint is > > that's, like, only your opinion man > > and the compiler cannot trust it. It must still guard the operation with > a runtime check that n actually is an int, and so you lose most or all > of the benefit of telling the compiler that it's an int. > > There are clever Just In Time compiler tricks that can optimize the > code, which is what Psycho did and PyPy still does, but they don't need > type hints. Type hints are superfluous to a JIT compiler, since it > already knows the runtime type information. But JIT compilers have their > limitations, like the necessity of warm up time, increased complexity, > and much heavier memory requirements. > > If you want to use type hints for the purposes of compile-time > optimizations, then typing must be compulsory and enforced by the > compiler. > No longer optional hints, but mandatory statements of indisputable fact. > > (That doesn't necessarily mean that you have to use type declarations, > like in C, Pascal and Java. A good modern compiler can infer types, like > in ML and Haskell.) > > Python's gradual typing is not about optimization, it is about testing > program correctness and helping to find bugs at compile time*. As such, > the fact that type hints are optional and "only your opinion" doesn't > matter. The promise made by the type checker is: > > IF what you say is true (the type hints are correct) > THEN this code will be sound > > (or alternatively, it's unsound because you have a type mismatch, and > get a compile-time error). As a fallback, you still have the runtime > dynamic type checks. > > Unit and functional tests are great, and necessary. Just because your > code compiles in C, Java or Pascal doesn't mean that it is correct. You > still have to run the code and test that it does what you expect. > > "It compiles! Quick, ship it!" -- attributed to Microsoft developers > > Nevertheless, the problem with testing is that it can only prove the > presence of bugs, not their absence. A test that fails proves that your > code has at least one bug. A test that passes doesn't prove that there > are no bugs. > > Static type checking helps to shrink the gap between "all of my tests > pass, > so there are no known bugs" and "there are no unknown bugs". And that's > an important and powerful tool, especially for large and complex > programs. > > Python's type-hints are for writing correct code, not fast code. I find > it amusing when people argue that Python's type hints are pointless or > useless. Do they realise they're effectively arguing that correct, > bug-free code is pointless? > > "Your code is buggy. It calculates the wrong result." > > "Maybe so, but look how fast it does it!" I think you have (deliberately?) miss understood RR by optional Static typing I think he means you don't have to use it as is in suing static types is optional) but when you define a variable as static then its type is fixed, not simply a hint. whether or not this could increase code deficiency or complicate the compiler further I have no idea -- Fay: The British police force used to be run by men of integrity. Truscott: That is a mistake which has been rectified. -- Joe Orton, "Loot" -- https://mail.python.org/mailman/listinfo/python-list
