LPython Is The Latest Python Implementation Aiming To Be Very Fast, Multiple Backends

[Vorpal]

Reported here:

https://github.com/lcompilers/lpython/issues/2231

They actually seems to be taking it mostly with grace (while of course also looking for ways to improve the lpython code)! Props to them.

[oleid]

Note, using std::vector<bool> actually hurts here. While it is more space efficient (n * 1 bits instead of e.g. n * 8 bits for char/uint8_t), the extra bit shuffling/masking makes this slower.

Ah, true, another optimisation possibility!
I should have taken it, thanks for reminding me

[onlyLinuxLuvUBack]

how does it look when you want to run the same code on linux/win/bsd/muck ?
what the install procedure and what the finale file?
multiple binaries for different os?

[certik]

Original author of LPython here. Thank you all for trying it and for reporting the bug. As I wrote there, we'll use the absolute best C++ implementation to benchmark against. I am not interested in benchmarking against imperfect code. I knew when we posted it that probably our benchmarks are not perfect, it's really hard to do this well. But I like publishing some benchmarks that people can run, and we can improve it as you are doing. We really appreciate your help with this. Right now C++ is winning, so we are implementing the "reserve" feature into LPython, and then we'll do round two (or three I guess). We'll publish everything in a follow up post. If you discover any more improvements to the C++ code, please let us know.

While I am here, I am happy to answer any questions. I saw this one:

> A question: How many python implementation do we have nowadays? Has anyone ever counted it?

It's 28. We have a full list at the bottom of https://lpython.org/. If there is anything missing, please let us know, we'll add it.

Some of the other questions: yes, you have to modify your code to tell LPython the types. The code however runs in regular CPython and the "emulation" layer is thin, here is our current implementation: https://github.com/lcompilers/lpytho...hon/lpython.py, most of them are a no-op in CPython.

Think of Mojo like a superset of Python, and LPython like a subset of Python. Consequently, any LPython code is also a CPython code (but not vice-versa), so you can use existing Python tooling with LPython and you are also not locked in. Regarding the current need for the "lpython.py" module, I think we could probably later teach LPython about other ways to define types, so that you don't have to use our "lpython.py" at all.

[gnattu]

OK, tested things and, really, it seems to be one more case where the algorithms and the data map choice is, one more time, inappropriate. To me, the claim about Python having a better or close enough performance to C or C++ (or Rust) is, once again, debunked.

If you look at their response at the github issue that oleid reported: https://github.com/lcompilers/lpython/issues/2231 you will find that they are giving very positive response and start optimizing lpython from the optimized cpp code. And from their latest numbers in the github issue, optimized lpython is close enough to optimized c++. I really like their reaction to this. If cpp can be written in a faster way, then there is more optimization they could do to match that performance, and this is what they are doing.

[acobar]

If you look at their response at the github issue that oleid reported: https://github.com/lcompilers/lpython/issues/2231 you will find that they are giving very positive response and start optimizing lpython from the optimized cpp code. And from their latest numbers in the github issue, optimized lpython is close enough to optimized c++. I really like their reaction to this. If cpp can be written in a faster way, then there is more optimization they could do to match that performance, and this is what they are doing.

I'm following the discussion there. I can't say I'm a big fan of Python, but, as a user, I have to commend the community for it is really trying hard to tackle any shortcoming they find.

[Flaburgan]

I love to see people working together to improve things, even if they are coming for different communities. Free software is awesome.