3 ms·

That’s certainly a fair way to put it. I guess I don’t encounter the type who really get upset that ”Python is too slow!! I’d rather use C++” because that takes

That’s certainly a fair way to put it. I guess I don’t encounter the type who really get upset that ”Python is too slow!! I’d rather use C++” because that takes a certain type of person who is technically able but practically challenged. I personally find myself surrounded by the opposite peoples.

mlthoughts2018 8y ago
This is the beauty of Cython & numba for me. It lets you selectively target just the small sections of the code that need a speed-up for an understood reason. You can use nice Python profiling tools to gather evidence about which program hotspots truly are too slow, and then just target those for specialization either as extension module functions/classes in Cython (or even a manually written extension module, or a plain C library used via cffi), or as a JIT function or class with numba. You can use the annotation features of Cython & numba to further profile locations that have avoidable CPython API overhead, and it becomes a very evidence-based and iterative optimization cycle. At the end, for 90% of the Python code that was more than fast enough already and didn’t touch performance critical sections, you just got to save all the time & trouble of needing to rewrite it (usually painfully) and debug it and re-test it all in C or C++. This is why, for me, the entire idea that you should start a project out in C++ or C is a giant type of premature optimization in a lot of cases (not all cases but a lot). Did you prototype the boilerplate parts in Python and actually measure the sort of performance hotspots you’ll have to optimize, to a degree that you know for sure that some light sprinkling of Cython & numba certainly won’t work? If not, it’s probably premature optimization to presume you’ll need C or C++ as the primary implementation language.
- SlowRobotAhead 8y ago
  I use C day in day out for embedded. So you’ll get no complaints from me! What I’ll find interesting is if the CPyrhon idea is ever pushed to embedded. Because right now the state of microPython or Zerynth trying to be a one stop shops for micros but in Python isn’t attractive. Then again, I don’t want or need pythons standard libs - what I really want is all C code with an option to ultra lightweight run scripting in Python. So 90% C, 10% Py. No option exists yet.
  - AlexCoventry 8y ago
    Lua sounds like a good fit.
    - SlowRobotAhead 8y ago
      Lua for embedded is pretty bad. We tried it, and the all options lacked something. eLua is out of date and tries to be 90%-100% Lua by wanting you to run the VM exclusively and the micro support is cortex M3 at best where they want you to use their headers and peripheral libs. No one seems to have the concept of a FFI (foreign function interface) worked out correctly that would allow for 90% C and calling C funcs from Lua. Lua Proper can’t ever agree on Lua VM or JIT. JIT is bad for embedded because bytecode is really what you want for serialization. Lua overall seems good but find me a 20-30K ROM non- dynamic memory VM that doesn’t include std lib nonsense you wouldn’t want on a micro (time, strings, etc)... because I looked and didn’t see anything close. Roll your own is for hobbiests or 30+ person teams. I’d take Lua or Python, but the lightweight scripting VM isn’t ready for embedded yet. Which is why I have hopes for Python (bringing this full circle) because of its natural relationship to C.
      - AlexCoventry 8y ago
        That's a shame. (About Lua. Hope it works out with cython.)
      - blattimwind 8y ago
        Is Pawn still around?
  - jononor 8y ago
    Maybe Cython can be compiled to target microcontrollers via LLVM? Right now I'm usually writing embedded application logic as C++ in a pure functional style. Then exposing this to Python using pybind11 and testing/evaluating it in Python. Which is pretty decent
- CogitoCogito 8y ago
  Your defense of python in these comments is great! I feel like you're presenting my own personal philosophy...just more coherently than I usually manage. I agree the python first micro-optimizations second approach is usually so much better than anything else unless you absolutely know you're going to need something else for [insert reason]. Even then I think it can be great for an initial throw-away implementation (at least the high-level ideas) simply because it's so easy to focus on the idea over the details.
dnautics 8y ago
it will screw you when you don't expect it. At our work we needed to profile drives (SSD, HDD) with workloads and one of our engineers wrote a disk workload replay program in python. Our results kind of didn't make sense, until I top'd it and realized that we were getting 100% CPU usage, so our workloads were CPU bound and not disk bound, so they were totally meaningless.

mlthoughts2018 8y ago

This is the beauty of Cython & numba for me. It lets you selectively target just the small sections of the code that need a speed-up for an understood reason. You can use nice Python profiling tools to gather evidence about which program hotspots truly are too slow, and then just target those for specialization either as extension module functions/classes in Cython (or even a manually written extension module, or a plain C library used via cffi), or as a JIT function or class with numba. You can use the annotation features of Cython & numba to further profile locations that have avoidable CPython API overhead, and it becomes a very evidence-based and iterative optimization cycle. At the end, for 90% of the Python code that was more than fast enough already and didn’t touch performance critical sections, you just got to save all the time & trouble of needing to rewrite it (usually painfully) and debug it and re-test it all in C or C++. This is why, for me, the entire idea that you should start a project out in C++ or C is a giant type of premature optimization in a lot of cases (not all cases but a lot). Did you prototype the boilerplate parts in Python and actually measure the sort of performance hotspots you’ll have to optimize, to a degree that you know for sure that some light sprinkling of Cython & numba certainly won’t work? If not, it’s probably premature optimization to presume you’ll need C or C++ as the primary implementation language.

SlowRobotAhead 8y ago
I use C day in day out for embedded. So you’ll get no complaints from me! What I’ll find interesting is if the CPyrhon idea is ever pushed to embedded. Because right now the state of microPython or Zerynth trying to be a one stop shops for micros but in Python isn’t attractive. Then again, I don’t want or need pythons standard libs - what I really want is all C code with an option to ultra lightweight run scripting in Python. So 90% C, 10% Py. No option exists yet.
- AlexCoventry 8y ago
  Lua sounds like a good fit.
  - SlowRobotAhead 8y ago
    Lua for embedded is pretty bad. We tried it, and the all options lacked something. eLua is out of date and tries to be 90%-100% Lua by wanting you to run the VM exclusively and the micro support is cortex M3 at best where they want you to use their headers and peripheral libs. No one seems to have the concept of a FFI (foreign function interface) worked out correctly that would allow for 90% C and calling C funcs from Lua. Lua Proper can’t ever agree on Lua VM or JIT. JIT is bad for embedded because bytecode is really what you want for serialization. Lua overall seems good but find me a 20-30K ROM non- dynamic memory VM that doesn’t include std lib nonsense you wouldn’t want on a micro (time, strings, etc)... because I looked and didn’t see anything close. Roll your own is for hobbiests or 30+ person teams. I’d take Lua or Python, but the lightweight scripting VM isn’t ready for embedded yet. Which is why I have hopes for Python (bringing this full circle) because of its natural relationship to C.
    - AlexCoventry 8y ago
      That's a shame. (About Lua. Hope it works out with cython.)
    - blattimwind 8y ago
      Is Pawn still around?
- jononor 8y ago
  Maybe Cython can be compiled to target microcontrollers via LLVM? Right now I'm usually writing embedded application logic as C++ in a pure functional style. Then exposing this to Python using pybind11 and testing/evaluating it in Python. Which is pretty decent
CogitoCogito 8y ago
Your defense of python in these comments is great! I feel like you're presenting my own personal philosophy...just more coherently than I usually manage. I agree the python first micro-optimizations second approach is usually so much better than anything else unless you absolutely know you're going to need something else for [insert reason]. Even then I think it can be great for an initial throw-away implementation (at least the high-level ideas) simply because it's so easy to focus on the idea over the details.

dnautics 8y ago

it will screw you when you don't expect it. At our work we needed to profile drives (SSD, HDD) with workloads and one of our engineers wrote a disk workload replay program in python. Our results kind of didn't make sense, until I top'd it and realized that we were getting 100% CPU usage, so our workloads were CPU bound and not disk bound, so they were totally meaningless.