Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nuitka — A Python Compiler

kayhayen24x7.homelinux.org

Post reply on HN
Print view View original

11–20 of 34 posts

Re: Nuitka — A Python Compiler

#11

Post by eru »

Goladus wrote: post #10
zachbeane wrote: post #9

I sometimes see people ask about translating a language like Python to Common Lisp (or another language that can be compiled) as a kind of optimization. The problem, in general, isn't that Python and languages like it don't have a compiler, it's that the semantics of the language are hostile to good performance by traditional means of compilation. To do what the programmer requests requires doing things at runtime th…

Compilation also helps distribution, though. Distributing a single compiled binary for a particular platform is a lot easier than telling people they need to have some particular version of Python and libraries installed.

Though you could just bundle your program up with the interpreter and all the libraries to make this work. No translation to binary necessary.

Re: Nuitka — A Python Compiler

#12

Post by eru »

mycroftiv wrote: post #3
truiu wrote: post #2

The licence (GPLv3) limits its use a bit - at least for people who prefer other licences like BSD or MIT. The generated C++ source contains the following comment: // This code is in part copyright Kay Hayen, license GPLv3. This has the consequence that // your must either obtain a commercial license or also publish your original source code // under the same license unless you don't distribute this source or its bina…

I'm confused by this. I thought the license used by a compiler had no effect on the licenses that could be used for programs compiled by it. If the author of Nuitka is claiming that software compiled by Nuitka is in fact a derivative work of Nuitka, that is indeed very problematic.

Couldn't you construct such a license?

Re: Nuitka — A Python Compiler

#13

Post by vanschelven »

stygianguest wrote: post #4

Personally I have more faith in JITs for dynamic languages such as Python. It just seems a more natural match. That said, I'm sure there are many Python programs out there that are essencially static. Did anybody else notice the large number of compilers/interpreters/tools built for python in comparison to many other languages out there? I think it might partly be the advantage of having an easy to parse language wit…

"I think it might partly be the advantage of having an easy to parse language with well defined semantics."

Either that or the combination of a popular language and poor performance

Re: Nuitka — A Python Compiler

#14

Post by hogu »

codedivine wrote: post #7

I was developing a compiler called unPython for a while but I have not yet released it openly. Plan to do so "soon". It is a compiler for annotated subset of Python (particularly NumPy, rest of it being very slow or not supported) to a C++ Python module. Will post here once I release it.

Why wouldn't you just use Cython? it has good numpy integration as well as being quite good for everything else?

Re: Nuitka — A Python Compiler

#15

Post by dmm »

mycroftiv wrote: post #3
truiu wrote: post #2

The licence (GPLv3) limits its use a bit - at least for people who prefer other licences like BSD or MIT. The generated C++ source contains the following comment: // This code is in part copyright Kay Hayen, license GPLv3. This has the consequence that // your must either obtain a commercial license or also publish your original source code // under the same license unless you don't distribute this source or its bina…

I'm confused by this. I thought the license used by a compiler had no effect on the licenses that could be used for programs compiled by it. If the author of Nuitka is claiming that software compiled by Nuitka is in fact a derivative work of Nuitka, that is indeed very problematic.

GCC has a runtime exception for exactly this reason.

Re: Nuitka — A Python Compiler

#16

Post by zachbeane »

Goladus wrote: post #10
zachbeane wrote: post #9

I sometimes see people ask about translating a language like Python to Common Lisp (or another language that can be compiled) as a kind of optimization. The problem, in general, isn't that Python and languages like it don't have a compiler, it's that the semantics of the language are hostile to good performance by traditional means of compilation. To do what the programmer requests requires doing things at runtime th…

Compilation also helps distribution, though. Distributing a single compiled binary for a particular platform is a lot easier than telling people they need to have some particular version of Python and libraries installed.

I hear that idea put forth sometimes. When was the last time you downloaded a single compiled binary from someone? I don't think I've ever done that, except maybe for darcs.

Re: Nuitka — A Python Compiler

#17

Post by DisposaBoy »

scg wrote: post #8

Here's a simple test for the curious. It's not a benchmark. import math num_primes = 0 for i in xrange(2, 500000): if all(i % j for j in xrange(2, int(math.sqrt(i)) + 1)): num_primes += 1 print num_primes Here's the code above translated to C++ by Nuitka: http://pastebin.com/41ueyTEB # CPython 2.6.6 $ time python hello.py 41538 real 0m6.377s user 0m6.350s sys 0m0.020s # Nuitka & g++-4.5 $ time ./hello.exe 41538 real…

i ran each test 3 times and picked the fastest. I shutdown all servers(mysql, apache), closed music player to minimize the system effect on the test.

Python:

    real    0m12.775s
    user    0m12.636s
    sys    0m0.037s
Nuitka:

    real	0m7.096s
    user	0m6.930s
    sys	0m0.093s
Lua:

    real	0m2.641s
    user	0m2.410s
    sys	0m0.010s
LuaJit:

    real	0m0.613s
    user	0m0.600s
    sys	0m0.000s
from experience experimenting with a toy scripting language where tried to make it as minimal as possible, essentially every operation was a function call so it just figured out what the right function was and called the corresponding function directly via a C++ function pointer. In the end it was slightly faster than LuaJit at doing some math for 100,000 times. It was a file with the same operation pasted 100,000 times which tested parsing speed... anyway...

TL;DR If you want to know why Python and Nuitka are so much slower, run the test through callgrind or something that reports the number of functions calls being made. You will find Python(possibly Nuitka as well) making billions of functions and allocations while lua's count in maybe a couple hundred million at most.

Also, I tested my Lua code converted to Python but it only shaved less than 1 second of fastest so no difference.

test.lua:

    local sqrt = math.sqrt
    num_primes = 0
    for i = 2, 500000 do
        n = 1
        for j = 2, sqrt(i) do
            if (i % j) == 0 then
                n = 0
                break
            end
        end
        num_primes = num_primes + n
    end
    print (num_primes)

Re: Nuitka — A Python Compiler

#18

Post by petsos »

zachbeane wrote: post #16
Goladus wrote: post #10

Earlier quoted context omitted.

Compilation also helps distribution, though. Distributing a single compiled binary for a particular platform is a lot easier than telling people they need to have some particular version of Python and libraries installed.

I hear that idea put forth sometimes. When was the last time you downloaded a single compiled binary from someone? I don't think I've ever done that, except maybe for darcs.

Downloading compiled binaries from someone is what you usually do on Mac and Windows.

Re: Nuitka — A Python Compiler

#20

Post by zachbeane »

petsos wrote: post #18
zachbeane wrote: post #16

Earlier quoted context omitted.

I hear that idea put forth sometimes. When was the last time you downloaded a single compiled binary from someone? I don't think I've ever done that, except maybe for darcs.

Downloading compiled binaries from someone is what you usually do on Mac and Windows.

I've never done that; I always see either dmgs (on Mac) or installers of some sort (on Mac and Windows). The thing you download is a single file, but they expand into a lot of files. The Mac makes it look nicer with the .app idea, but you're still getting a bunch of files in there, one of which might be an interpreter for some of the other files.
Post reply on HN