If it's easier for you to write better algorithms in Python than in C++, than your code will probably be faster while written in Python. Because better algorithms will easily get you further than 10x in terms of performance.
It's important to remember though that not all significant performance gains come from better algorithms, I've taken an industry standard C implementation of an algorithm and improved perf (as measured on production workloads) by 30x by thinking about issues that didn't really concern the original author (in particular cache locality and realizing that the entire problem could be moved into the integer domain)
In practice I have not often seen this pan out - if you've got the most common case of a GUI app with tons of callbacks which update your UI in real-time, there isn't one algorithm to optimize anywhere, but instead you die a death of a thousand cuts because each callback will be marginally slower than what it would have been in C++.
Also, it's much easier to control allocations & system calls in C++ (or other native languages for what it's worth) than in Python - and in my experience preventing those is an even better pathway to getting frames rendered in less than 5 milliseconds (which is what you want to do if you have any respect for your 144hz-screen users)
The big problem with Python GUIs is usually that the GUI framework is often written in Python. (Or it's that things like network & parsing code gets written in Python.) The framework does a lot more heavy lifting than the app does - in particular, it's responsible for converting the system events into clicks, drag&drops, submissions, etc. for the app, and for rendering components into bitmaps. If the framework is written in C++ and just exposes a Python API, there's no problem. That's how wxPython and PyQT do it.
But I've seen researchers been vastly prolific in Python. They make segmentation or registration algorithms that beet the market, and then they call us (C++ engineers) to make them "fast". Usually we do, since we're trained for that. But it's never orders of magnitude. It's like 2-3 times faster.
And there were even cases where the C++ code appeared slower in the end. Well, we use slightly different math core than the numpy does and sometimes they're doing worse.
It's an excellent deal for scientific computing, where your logic is trivial and almost all work is done in C. But it's not so rosy for user-facing applications, where it's the logic that dominates.
Weird to call it cheating when Python's strong intertop with C is a specific design goal of the language.
One particularly common performance pessimization is replacing an algorithm with one that has better big-O performance but a worse constant factor, and doing so where the particular O is much smaller than the number of times the function is called. People learn that hashmaps are O(1) while red-black trees are O(log N) and linear search is O(N), so they'll default to using a hashmap for a lookup table, even if the lookup table has 10 items but the keys are ~500 byte strings. (I'm guilty of this one myself, but at least I measured and fixed it.) Then they'll call this lookup in a loop 5000 times.
Using Python or another rapid-prototyping language can be a good idea here if you take the time to profile and identify the bottlenecks, but very frequently you end up shipping it, throwing hardware at it, and then wondering why you're spending hundreds of thousands of dollars on AWS bills. Plus, a really big problem with many common Python architectures is that they use pure Python libraries & frameworks even on the critical path. (Big offenders here include using BeautifulSoup in your 1B-page web analysis or Django on your million-user website.)
Regarding the algorithms on small data, I even made a quiz about that: https://wordsandbuttons.online/challenge_your_performance_in...
Of course, Python or C++, if you want performance, you should design with performance in mind. Measurements and profiling are implied.
(really the 'hardest thing' about software is all of the things that are true but few believes are important. Dropping the Big O can be proven empirically)
So I can run a Python script that gathers all the key-value pairs (names and pages), makes an optimized search tree out of them and spawns is out as an LLVM sheet of code. Then I only have to embed it into a trivial HTTP "answering machine", assemble it all under the target architecture as part of the deployment - and that's it.
I have more fun things to do right now, but my hosting contract expires in a year or so so I'd look for the alternatives by then.
There are a lot of these already. Serving static content quickly is not an interesting challenge any more, most of them will be able to saturate a 10GBE link over a huge number of connections. No, all the interesting effort is in dynamically assembling pages.
I don't think a lot of people would actually use asymptotically slower algorithms when using a different language.
The extra engineers needed to make a Java/C++ backend need to eat/sleep/consume and have their own environmental cost.
$$$ is a good first-order proxy of environmental cost, and lower server costs probably don't make up for engineering salaries.
Unfortunately there are a lot of those "everyone else" services out there so it becomes a death through a thousand cuts concern.
Obviously from an environmental perspective (if that is the ethical concern in question) there are probably higher priorities
Engineers are not VMs in the cloud, you don't provision them on demand. They exist as human beings, and eat, sleep and consume anyway.
> $$$ is a good first-order proxy of environmental cost, and lower server costs probably don't make up for engineering salaries.
If you run it through a heavy low-pass filter to remove all the sales-related price shenanigans. And discount salaries, because taking on an engineer at $X doesn't mean you've just increased your carbon footprint by $X.
You could actually see how taking into account salaries might be a cause of the problem. Say you can hire an engineer who'll get you a basic backend working in Python or Ruby for $100k, or an engineer who'll get you that backend in a more efficient stack - say C++ or Java, or even a more polyglot solution with hotspots optimized - for $150k. In the first case, your yearly costs of cloud servers are $20k, in the latter $5k, reflecting the 5x efficiency difference.
From the monetary point of view, you should take the less efficient option - after all, you're getting $35k ahead. From the environmental point of view, your service uses 5x the energy it should. And you're not the only company with this dilemma. If everyone chooses the cheaper option, then the whole segment of industry becomes 5x less efficient than it should be.
The incentive is there whether the company recognizes it or not. A price your customers pay matters to your business.
However the framework definitely matters here, PHP’s build the world and destroy it on every request makes a big difference.
My favourite example: slurping an entire category table on each page load and then using an O(n^2) loop to rebuild the navigation tree. On a cold cache, they had request times (server-side) of 7 seconds.
Rewriting to a recursive CTE brought the page load time (client-side) down to below 100 ms, even on a cold cache.
Java is faster than JS but let’s not kid ourselves.
I suspect that in some respects that we already optimize for this as an industry, we might have application logic in python, but the database is presumably written in a systems programming language.
And once the job is done, optimization often is off the table, because the next features await. I work for clients that are making lots of money with their sites, and not even then are they willing to spend pennies on the dollar to optimize those pages.
Maybe the highest impact you can get is working on most-used parts. Make Wordpress run 3% more efficiently and you'll have an enormous global impact. Make your own site run 3% more efficiently and it won't register globally, unless you're Google, FB etc.
Web gurus will tell you that web is slow because the specific sites are written badly.
While Linus has told that C keeps bad developers away from the kernel.
I used to work at OkCupid. The entire web application is written in C++ [1] and I was quite proficient with the language even before joining the company. Then I joined a medium sized game studio where C++ was also the most common language, and as you can guess we also decided to built the game landing pages and user management system using C++ with Boost and an in-house template system.
I am not OP but you asked to let you know if someone is a productive web developer in C++, well, I am.
The author claims that it's only twice less productive to write in assembly than in high-level languages. But the performance gains are overwhelming so it might very well pay back the effort.
FPGAs are fun, though. Saving 12 microseconds (assuming gigabit and "standard" frame sizes) of latency by sending ethernet frames (that contains frame data CRC!) before you even have all of the data to send and then modifying data at the end of frame to match with whatever CRC we sent ~12000 bit times (= 12 microseconds) before.
I know HFT guys pull of tricks like these, but no, this is either not difficult to pull off on an FPGA nor is there any NDA. Easy if you send UDP with checksums off or raw ethernet frames. Receiving party will of course need to ignore the last 4 bytes needed to make the CRC computation correct.
Would be interesting if anyone managed to do this with TCP. If it's even possible to get both TCP and ethernet frame FEC match in real time and ideally somehow even mask the data from the recipient. Probably not possible, but... who knows.
Using something like C++ Builder with its Internet VCL component libraries it is hardly any different from using Java or .NET stacks for Web development.
I'd probably default to C#, which can be decently fast and has a managed runtime.