4 ms·
Code gets reused, even if you don't plan for it. Prototypes go to production. Chunks of code from one project, where performance doesn't matter, wind up in anot
by burfog 6y ago
Code gets reused, even if you don't plan for it. Prototypes go to production. Chunks of code from one project, where performance doesn't matter, wind up in another project where performance is important.
For this reason, starting with slow code (either Python or just lazy OO-heavy C++) sets you down a path to future trouble. There will never be time for a rewrite, and if you think there is time then a case of "second system syndrome" may be what stops you.
There is also the matter of personal habit. You use what you are comfortable with. If you get comfortable writing slow code, then you'll start projects with slow code by default. You'll hit the above problems far more often than somebody who is in the habit of writing fast code by default.
- monkpit 6y agoNo offense, but that seems like bikeshedding to me. At what point do you stop making premature optimizations like that? The commenter had a need, wrote a package to fulfill the need in a language they were comfortable with, and got the job done. Performance is important to the project and the performance goals are met. Why should they have spent more time to accomplish the same goal and same performance?
- milesvp 6y agoI think the parent post also may be making an assumption that C++ code takes little more effort/time to write than python. My experience is that this couldn't be further from the truth. I recently did some DSP work, and prototyping it in python then rewriting the code in C++ easily saved me calendar time as well as effort and headache. Python code has a tendency to just work for numerical applications and it would have been a bigger headache to check my work in C++ without answers that were easier to verify in python (I remember reading years ago a thread on benchmarking that got shut down hard by someone pointing out that only the python code was giving the correct answers due to various floating point issues). On top of that, I needed to use templates to get more compile time substitution to squeeze out performance, and struggling with templates and the type checker would have been a context switching nightmare without having the algorithms already working.
- burfog 6y agoFor your use case I believe the standard is to write in Matlab, and then use a tool that converts Matlab code to C.
- ageofwant 6y agoThat's hardly the standard. In 2020 you will write your code in Python using numpy and or numba and your done. I process 4 concurrent HD video streams in Python in real time on a 4 core embedded device.
- dialamac 6y agoHow much time is actually spent in the python runtime/interpreter? That python can glue some libraries together at a high level was never really in doubt.
- ageofwant 6y agoHow does that matter in any meaningful way ? Are you building real-world software or fretting about problems that you don't actually have ?
- JanisL 6y agoI'm a bit surprised to hear this, is this a common thing to do in the DSP world in 2020?
- cycomanic 6y agoBtw I highly recommend using pythran for your use case which apart from speeding up python significantly allows you to translate your python code directly to C++. Here is a blog post exactly about this use case: https://serge-sans-paille.github.io/pythran-stories/pythran-as-a-bridge-between-fast-prototyping-and-code-deployment.html https://serge-sans-paille.github.io/pythran-stories/pythran-...