Re:Selecting a programming language can be a form of prematu...
by typon on Monday November 15, 2021 @09:44AM
(#29227948)
This is something I do except the slow parts are in Python and the fast parts are in C++ with pybdind11 connecting the two worlds
Re:Selecting a programming language can be a form of prematu...
by Kye on Monday November 15, 2021 @09:20AM
(#29227681)
I thought the C++ tendency was to optimize performance sensitive parts with C or assembly.
Re:Selecting a programming language can be a form of prematu...
by taylodl on Monday November 15, 2021 @10:44AM
(#29228693)
C++ is C. We used to optimize with assembly but nowadays with a processor's superpipelined architecture and the compiler's global register optimizations and so forth your inlined assembly is more likely to throw a monkey wrench into the whole works and make everything run slower. It's a better use of your time to look for a better algorithm.
Re:Selecting a programming language can be a form of prematu...
by khoobid_shoma on Monday November 15, 2021 @05:57PM
(#29234057)
Not really. C++ is not C, nor faster than C.
e.g. TCO in C++ is awful due to ctor/dtor (could be mitigated by some compiler hints if available).
Re:Selecting a programming language can be a form of prematu...
by xapata on Monday November 15, 2021 @11:19AM
(#29229121)
Isn't that what Python is? Except C and not C++.
Re:Selecting a programming language can be a form of prematu...
by xscott on Monday November 15, 2021 @01:13PM
(#29230524)
No, because you wouldn't have to pay the virtual machine overhead (among others). Another possibility would be using Cython - write the prototype in pure Python, then Cythonize the parts which need to run more quickly.
You would initially trade some of the C++ performance, but the code shouldn't be more complicated or difficult to write or compile than Python. Then, you'd only need to change the performance sensitive parts to use real C++ arrays or structs.