6 ms·

Cython, pypy, micropython, nuitka, shedskin, ironpython, graalpython, jython, mypyc, pyjs, skuptjs, brython, activepython, stackless, transcrypt, cinder and man

• m_ke 5y ago
  Numpy, Numba and PyTorch seem to be doing ok.
  • gh02t 5y ago
    Cython is also pretty successful obviously, though I don't think it quite fits in OPs list given that it's more about writing extensions than replacing your entire Python code/stack. But I do agree with OPs sentiment even as someone who writes a lot of Python.
• fwsgonzo 5y ago
  Most of the ones you list require dynamic linking and so is hard to make use of in specialized environments. His project seems to be generating generic C code which is much easier to port to any weird platforms. In fact, it might be perfect for my use-case where dynamic linking is just extra attack surface. I understand that the project is still in the early stages, but I will be paying close attention to it. If at some point it will be possible to write "regular" Python in it (minus most of the standard library and imports), then it could be a candidate for an edge computing platform.
• nspattak 5y ago
  so much effort to match the performance of lower level languages that it would have actually been easier to use those directly :)
  • Tozen 5y ago
    Good point. And you don't have to go that low. Maybe go use Object Pascal, Nim, or Vlang. I know... the libraries. But a lot of them are bindings of C libraries. So, you can create bindings in other languages too or use Python from those languages. There are various options.
  • Zababa 5y ago
    I'm not sure, most people aren't writing ASM these days because the compilers are good enough for most cases. Compilers are great.
    • zanellia 5y ago
      I think most HPC people would disagree with this statement. State-of-the-art HPC code is still written in ASM (see e.g., https://github.com/xianyi/OpenBLAS https://github.com/xianyi/OpenBLAS) [that's what Intel is doing too]
      • guenthert 5y ago
        That ASM code is however not necessarily constructed manually. You'd think for high performance code with limited scope, a superoptimizer would be used.
        • zanellia 5y ago
          Not sure what a "superoptimizer" would look like in this context. For a reference, I know for sure that this https://github.com/giaf/blasfeo https://github.com/giaf/blasfeo (which beats Intel MKL) was coded entirely by hand.
          • giaf 5y ago
            There is more and more effort in the automatic development of high-performance linear algebra kernels. But based on my experience, it would certainly be a big challenge to have a tool able to exploit the subtle differences in the assembly languages of different architectures, if the aim is to match or even exceed an expert-crafted assembly kernel. Anyway, that's surely a very promising active research direction.
• zanellia 5y ago
  The point of prometeo is not to obtain a "performant Python". Python is used merely as a host language for an embedded domain specific language. You could do the same thing with any other language with a mature library for AST analysis :)
  • deleted 5y ago
    [deleted]
  • lvass 5y ago
    Which makes this thread's title at least confusing.
    • zanellia 5y ago
      fair enough - could not cram "embedded" into it :)
    • throw10920 5y ago
      I'd argue it's downright misleading. "Python-to-C transpiler" means Python, not "a DSL based on a subset of Python". An accurate title would be "a DSL embedded in Python for high-performance scientific computing" or something similar.
• staticautomatic 5y ago
  SpaCy is pretty incredible evidence.
• Der_Einzige 5y ago
  Not sure what you mean by "eluded by a promise of performant python". Tensorflow and Pytorch do a great job thank you very much.