4 ms·

"...The benchmarks support the claim that LPython is competitive with its competitors in all features it offers. ... Our benchmarks show that it’s straightforw

"...The benchmarks support the claim that LPython is competitive with its competitors in all features it offers. ... Our benchmarks show that it’s straightforward to write high-speed LPython code. We hope to raise expectations that LPython output will be in general at least as fast as the equivalent C++ code." At least as fast as C++ is a bold claim, but this is an interestingly documented process. I'm keen. I'm quite partial to Nuitka at this point, but I'm open to other Python compilers.

certik 3y ago
We put this sentence there to drive the point home that LPython competes with C++, C and Fortran in terms of speed. The internals are shared with LFortran, and LFortran competes with all other Fortran compilers, that traditionally are often faster than C++ for numerical code. I've been using Python for over 20 years and it's hard for me to imagine that writing Python could actually be faster than Clang/C++, somehow I always think that Python is slow. Right now we are still alpha and sometimes we are slower than C++. Once we reach beta, if an equivalent C++ or Fortran code is faster than LPython, then it should be a bug to report.
- chaxor 3y ago
  What happens when including numba or pytorch, etc in the scripts? GPU acceleration in python is one really nice way of getting decent speed, but I would imagine it's difficult to shuffle over when doing this type of compiling. If the end compiled program allows for use of all available computational resources (some logic with python to determine what accelerations to allocate, what is available, etc) and then can compile to C++ speeds for CPU and use GPU where appropriate, this will be astoundingly good.
  - certik 3y ago
    Right we support (currently a subset) of NumPy (just `from numpy import ...`) and SymPy (`from sympy import ...`) and some parts of the Python standard library. We want to support PyTorch, CuPy and other such libraries in a similar way, at least the subset that can be ahead of time compiled, which is quite large. Yes, offloading to GPU we want to support naturally via NumPy syntax. We will look at this very soon, most likely via annotating that a given array lives on a GPU or host, and then array copy will copy it from host to device, etc.
- capitalsigma 3y ago
  I thought that Fortran was traditionally faster than C++ for numerical code due to stricter aliasing rules in the language, which I wouldn't expect to carry over to an IR?
  - certik 3y ago
    That, but also being simpler and higher level, having multidimensional arrays in the language itself and simpler semantics (such as you cannot just take a pointer to an arbitrary variable, it has to be marked with "target"), no exceptions, and so on. What carries over to the IR today are all the language semantic features, such as all the array operations (minloc, maxval, sum, ...) and functions (sin, cos, special functions) as well as all the other features without any lowering, and we then do optimizations at this high level, then only at the end we lower (say to LLVM). Python/NumPy can be optimized in exactly the same way, and that's what LPython does. I think C++ can also be compiled this way, but the frontend would have to understand basic structures like `std::vector`, `std::unordered_map` as well as arrays (say xtensor or Kokkos, whatever library you use for arrays), and lift it to our high level IR. Possibly we would have to restrict some C++ features if they impeded with performance, such as exceptions --- I am not an expert on C++ compilers, I am only a user of C++.
nurettin 3y ago
Nuitka is just a packaging system which places all dependencies inside of an executable. It doesn't compile into machine code. Why do you conflate it with compilers?
- quietbritishjim 3y ago
  It is absolutely a compiler. I've certainly spent enough time waiting for it to compile! On the contrary, packing dependencies is a side effect rather than its primary purpose. (Your sarcastic last sentence doesn't help your point, even if you weren't wrong.) However, it really is different from projects like this one, in that it doesn't attempt to obtain C-like speed (but does hope to do some optimisations). For example, x+=1 will still dynamically dispatch depending on the runtime type of x, and (if it's an int) do the normal Python arbitrary precision operation. But those will be called from machine code rather than interpreted byte code. (Essentially, it unrolls the main loop of the CPython interpreter, which is written in C, for every byte code operation, and eliminates every case of the switch statement inside except the one that corresponds to this operation. That's what gets compiled.)
  - nurettin 3y ago
    Just to be clear, the reason I didn't (and won't) accept nuitka as a compiler is that it doesn't do what actual compilers do, it just plays around with bytecode. I experienced no speed difference when running large programs, but the startup is considerably slower. To me, it is just a docker replacement that is 1/10th as portable.
    - mid-kid 3y ago
      "plays around with bytecode"? Even if that is so, it translates the whole program to c++, which is then compiled. It relies on libpython to implement a lot of the core language types and such, so if your program isn't very computationally intensive or makes heavy use of core data types, you might not notice much, but it's definitely a compiler.
    - certik 3y ago

certik 3y ago

We put this sentence there to drive the point home that LPython competes with C++, C and Fortran in terms of speed. The internals are shared with LFortran, and LFortran competes with all other Fortran compilers, that traditionally are often faster than C++ for numerical code. I've been using Python for over 20 years and it's hard for me to imagine that writing Python could actually be faster than Clang/C++, somehow I always think that Python is slow. Right now we are still alpha and sometimes we are slower than C++. Once we reach beta, if an equivalent C++ or Fortran code is faster than LPython, then it should be a bug to report.

chaxor 3y ago
What happens when including numba or pytorch, etc in the scripts? GPU acceleration in python is one really nice way of getting decent speed, but I would imagine it's difficult to shuffle over when doing this type of compiling. If the end compiled program allows for use of all available computational resources (some logic with python to determine what accelerations to allocate, what is available, etc) and then can compile to C++ speeds for CPU and use GPU where appropriate, this will be astoundingly good.
- certik 3y ago
  Right we support (currently a subset) of NumPy (just `from numpy import ...`) and SymPy (`from sympy import ...`) and some parts of the Python standard library. We want to support PyTorch, CuPy and other such libraries in a similar way, at least the subset that can be ahead of time compiled, which is quite large. Yes, offloading to GPU we want to support naturally via NumPy syntax. We will look at this very soon, most likely via annotating that a given array lives on a GPU or host, and then array copy will copy it from host to device, etc.
capitalsigma 3y ago
I thought that Fortran was traditionally faster than C++ for numerical code due to stricter aliasing rules in the language, which I wouldn't expect to carry over to an IR?
- certik 3y ago
  That, but also being simpler and higher level, having multidimensional arrays in the language itself and simpler semantics (such as you cannot just take a pointer to an arbitrary variable, it has to be marked with "target"), no exceptions, and so on. What carries over to the IR today are all the language semantic features, such as all the array operations (minloc, maxval, sum, ...) and functions (sin, cos, special functions) as well as all the other features without any lowering, and we then do optimizations at this high level, then only at the end we lower (say to LLVM). Python/NumPy can be optimized in exactly the same way, and that's what LPython does. I think C++ can also be compiled this way, but the frontend would have to understand basic structures like `std::vector`, `std::unordered_map` as well as arrays (say xtensor or Kokkos, whatever library you use for arrays), and lift it to our high level IR. Possibly we would have to restrict some C++ features if they impeded with performance, such as exceptions --- I am not an expert on C++ compilers, I am only a user of C++.

nurettin 3y ago

Nuitka is just a packaging system which places all dependencies inside of an executable. It doesn't compile into machine code. Why do you conflate it with compilers?

quietbritishjim 3y ago
It is absolutely a compiler. I've certainly spent enough time waiting for it to compile! On the contrary, packing dependencies is a side effect rather than its primary purpose. (Your sarcastic last sentence doesn't help your point, even if you weren't wrong.) However, it really is different from projects like this one, in that it doesn't attempt to obtain C-like speed (but does hope to do some optimisations). For example, x+=1 will still dynamically dispatch depending on the runtime type of x, and (if it's an int) do the normal Python arbitrary precision operation. But those will be called from machine code rather than interpreted byte code. (Essentially, it unrolls the main loop of the CPython interpreter, which is written in C, for every byte code operation, and eliminates every case of the switch statement inside except the one that corresponds to this operation. That's what gets compiled.)
- nurettin 3y ago
  Just to be clear, the reason I didn't (and won't) accept nuitka as a compiler is that it doesn't do what actual compilers do, it just plays around with bytecode. I experienced no speed difference when running large programs, but the startup is considerably slower. To me, it is just a docker replacement that is 1/10th as portable.
  - mid-kid 3y ago
    "plays around with bytecode"? Even if that is so, it translates the whole program to c++, which is then compiled. It relies on libpython to implement a lot of the core language types and such, so if your program isn't very computationally intensive or makes heavy use of core data types, you might not notice much, but it's definitely a compiler.
  - certik 3y ago