People using c++ usually care about programs finishing before the heat death of the universe. I had a few Python scripts that spend several seconds parsing larger files, after a rewrite to c++ that changed to almost instant.
It depends on the task. If the parsing is done once a day then several seconds is nothing, so there is no point in using C++.
If the parser is running very frequently then of course one uses a faster implementation.
Generally languages like C++ are obviously much faster, but a lot of primitive stuff in languages like python is also just C calls and may be optimised to the point of being faster, because doing things in low level compiled languages often comes with its own tricks and problems.
[1]https://stackoverflow.com/questions/9371238/why-is-reading-l...
That assertion makes zero sense if we take into account that parallelization is one of the most basic performance techniques there is, and Python's GIL simply eliminates that option except for multi-process applications which then require serializing stuff back and forth.
Python is pretty much unparalleled as a glue language, and excels at putting together small exploratory scripts for data analysis and number crunching applications, but it makes no sense to present Python as a performant alternative to C++.
In that corner case you still have slow Python glue code calling fast C++ code.
It makes no sense to claim that Python is performant based on the idea that it may be used to glue together calls to performant C++ code, while ignoring the fact that not only Python forces performance restrictions on it's code but also that C++ code is quite capable of calling performant C++ code itself.
To be honest I'm not sure what your new comment is about. If you're saying that Python is not necessarily faster than C then I'm sure no one going to dispute that; in the situation we're discussing, the performance of your code is totally dependant on the efficiency of the libraries that are doing all the work, not your glue code. If you're saying that Python is slower than C when it's doing a non-trivial amount of the execution, then sure, but no one was claiming that either. Or maybe you just want to simplistically categorise languages as "performat" and "non-performant" without thinking about the specific contexts they can be used in, but that wouldn't make any sense. Did I misunderstand?
I would not support that stance. There are areas where parallelization is helpful, like numerical weather models, graphics, and scientific number crunching, but for by far the most cases, parallelization is anything but trivial and requires a pretty deep knowledge about things like the C++ memory models, what read-write barriers, locks, and fences are, and so on. Less than 1% of C++ programmers can really handle that. And apart from that this is an area where other languages like Rust, Clojure, Scala have a strong point, because whether it is done correctly is completely implicit in a C++ program while in Rust, many errors will have the result that your program does not compile. Debugging the same mistakes in C++ will make you pull your hair.
In fact, I'd urge anyone who wants to learn principles of safe concurrent computation in C++, to learn Rust, Clojure and Scala first, they are wonderful languages with strong, highly coherent concepts, and it will make you a much better C++ programmer even if you never use them again.
Of course it is not only possible but common practice to implement parallel computation in games and such in C++, but this is not the standard application of C++.
Parellism in C++ is most often used for scientific applications and other forms of mass number crunching. It's really easy to just throw a "#pragma omp parallel for" on a loop and call it a day but of course that would also apply to C and Fortran and is somewhat limited. Parallelism libraries like Intel TBB which I'm most familiar with are very easy to use and performant. I think there's a large problem in the reluctance of educators to use libraries to teach parallelism and people always dive straight into locks, threads and atomics which are really not the way to approach parallel computing if you're looking to do parallel computing and not looking to implement parallel primitives yourself (i.e DIY tasking-system or lock-free queue)
Focusing on TBB, it facilitates efficient parallelism by providing high-level canned algorithms such as parallel_invoke, parallel_reduce, parallel_for and parallel_do which anybody who claims to know C++ should be able to use easily. It also provides a task-graph which is great for more complex processing pipelines (things like join/split, fan-in/out and queueing). If you need more low level control you operate at the task level and TBB provides customization points for that. There's other libraries out there which provide similar functionality and even the STL in C++17 provides basic parallel algorithms such as transform (equivalent of map in other langs), reduce and many others.
There are two aspects. I agree to the aspect that today, C++ is used often for such tasks.
Now, what are the reasons why C++ is used dominantly in this domain? I think more or less the only reason is performance. The good performance is what makes the authors of such libraries put up with the disadvantages of C++.
However, I think it is also true that Rust allows for a more concise and safe formulation of the computation (also Scala, for example, which serves somewhat different purposes). For scientific applications, correctness matters, and knowing that the code which compiles does not has hidden memory errors and data races is extremely valuable, because it can save a ton of time.
Also, if there are still differences between Rust and C++ performance, they are minor. In many cases, Rust is faster.
Now, if authors of scientific computing libraries were to come to the conclusion that there exist an alternative which produces at least as fast code, provides better and safer support for parallelization, and is with some learning easier to work with, why should these library authors continue to use C++?
Of course, nobody is going to ditch a large C++ project like Eigen over night and rewrite it in Rust. There is too much inertia for that. Also, GCC support is still lacking. However, one can expect that the number of new projects which use Rust is going to increase and the project which are successful there will blaze a new trail. For something like Python extension modules, users of these libraries do not need to know anything about Rust.
Also, some nitpick. C++ is used in important scientific libraries. However, many essential libraries such as Numpy are written either completely in C, or use C interfaces, because C++ does not has a stable ABI and Python uses the C ABI. This would make a switch to Rust pretty easy. In fact, I think the impulses in this domain will come first from researchers and analysts which start to write small Rust extension for Python which use the C ABI and integrate with Numpy, for example.
In that sense, C++ is not batteries included, which can be annoying for small and medium projects.
Essentially C++ and the modern ideas about computer security are at war.
Really? That's the opposite of my impression. It seems to me that they promote it as co-equal to C# as primary focus in their constellation of supported and encouraged application programming languages.
https://docs.microsoft.com/en-us/windows/apps/winui/winui3/x...
I've seen Rust being used for the layer above C++, where it doesn't have to deal with I/O, scheduling, etc that don't play well with Rust but you still want the throughput/latency and memory safety.
Hell, highly optimized numerical simulations are still being written in freaking Fortran.
In some software architectures, there are schedulers with a global view of the entire (potential) conflict graph and they have complete control of what gets executed when. These architectures don’t even require locks because the scheduler has enough visibility and control to guarantee that execution won’t be scheduled such that there would ever be a contended lock or some other concurrency conflict. No amount of mutable references to the same memory will break these models, and the correctness of some implementations have been formally verified. The scheduler can always dynamically reorder execution to guarantee the invariants of the system. These models have the added benefit of having insanely good locality properties such that throughput is excellent.
These software architectures originated in HPC over a decade ago and eventually bled over into high-end database kernels. I learned it from when I worked in HPC many years ago and have used it every since, due to its unambiguous advantages.
For example you might be able to wrap shared-mutable state in a kind of degenerate mutex and pass a "scheduler guarantee" token around that unlocks those "mutexes" without doing any runtime work.
1) Neither iOS, nor "the web" are new platforms.
2) Not only you can program with C++ on iOS, it's heavily used in certain kinds of applications.
3) Why would anyone single out a specific language and claim that it's a problem that you can't use it to build websites with it? This applies to all languages with one exception. Or it did, because now there's WebASM, which makes this argument even more bizarre.
4) C++ had and has first-class support on Windows.
2) Objective-C++ may look like C++ but their different languages. As always beware of edge cases.
3) WebAsm is somewhat “supported“ by 92% of web browsers which sounds great but isn’t enough to be viable for companies like Amazon. But hey it’s a cool toy if you don’t have real work to do.
4) I have run into plenty of missing C++ documentation when C# documentation was available on Windows. It’s supported sure, but very much a second class citizen.
Was it worth rewriting those scripts in C++? I'm not trying to be facetious; a few seconds (or minutes) of additional runtime for scripts you hardly ever run or even run only once doesn't really matter, but running such scripts often may then worth the effort to convert them to something faster.
I regularly find myself porting regularly used python/js scripts to C#/dotnet (because it's fast enough, has good collections + LINQ for your somewhat-functional-programming needs and I can skip manual memory management, and async/await programming is not perfect but available and easy enough, + nuget has a lot of stuff and so does the standard lib).
What made you pick C++ over e.g. go or rust or C#?
Mostly for development, I ended up invoking the script quite often and had to wait for the results. In production the input it ran on only changed once a week, so there was no need to run it often.
I most likely tried to run it with Pypy first, thought I am not 100% sure on that. If I ran into a similar issue today I would first try to compile it with Cython as I already try to use type annotations in every new script I write.
> What made you pick C++ over e.g. go or rust or C#?
Most of the project was already C++ and I only had to link in an Xml library for some of the output.
Since you can get within about 2x of C++ speed which still using a high-level language, that makes the argument that the times you really need C++ for performance reasons are quite limited. I'm not saying they don't exist, but they are rare.