Hacker News Reader

Comment by burfog | Hacker News Reader

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.

View on HN

No 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?

I 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.

For your use case I believe the standard is to write in Matlab, and then use a tool that converts Matlab code to C.

That'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.

How 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.

How does that matter in any meaningful way ? Are you building real-world software or fretting about problems that you don't actually have ?

I'm a bit surprised to hear this, is this a common thing to do in the DSP world in 2020?

Btw 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-...

Reply on news.ycombinator.com