The argument for the Exception price is that we told you Exceptions were for Exceptional situations. This argument feels reasonable until you see it in context as a library author.
Suppose I'm writing a Clown Redemption library. It's possible to Dingle a Clown during redemption, but if the Clown has already dingled that's a problem so... should I raise an exception? Alice thinks obviously I should raise an exception for that, she uses a lot of Clowns, the Clown Redemption library helps her deliver high quality Clown software and it's very fast, she has never dingled a Clown and she never plans to, the use of exceptions suits Alice well because she can completely ignore the problem.
Unfortunately Bob's software handles primarily dingling Clowns, for Bob it's unacceptable to eat an exception every single damn time one of the Clowns has already been dingled, he demands an API in which there's just a return value from the dingling function which tells you if this clown was already dingled, so he can handle that appropriately - an exception is not OK because it's expensive.
Alice and Bob disagree about how "exceptional" the situation is, and I'm caught in the middle, but I have to choose whether to use exceptions. I can't possibly win here.
Like I said, this argument doesn’t work because you can use options in c++ but you can’t use exceptions in rust. So when there’s an occasion where you want to avoid the overhead of an option or result in rust - well too bad.
If all you care about is outright performance, having the option for exceptions is easily the superior choice. The binary does get bigger but those are cold pages so who cares (since exceptions are exceptional, right?)
I mean, it's outperforming C as well in that particular benchmark.
Lies, damn lies, and benchmarks?
I can at least say, the performance difference between C, C++, and Rust, is splitting hairs.
If you want to write something performant, low level, with predictable timing, all three will work.
I'm spending a lot of time building projects with Rust & C++ these days. The issue/tradoff isn't performance with C++, but that C++ is better for writing unsafe code than Rust.
Datadog | Senior Video Conferencing Engineer, Backend Systems Engineer | Full-time | Remote (US) |
Description:
My team @ Datadog is actively looking to hire a Senior Video Application Engineer, and a Backend Systems Engineer, to work closely with the CoScreen (www.coscreen.co) team on developing our next generation remote collaboration tool.
Anyone with experience with real-time media streaming, video conferencing, and WebRTC, particularly with low-level skills (If you’ve integrated with or ripped into the low-level details of libwebrtc, ffmpeg, gstreamer, pion, etc etc) we’d love to chat with you.
Also if you’re a low level developer with experience developing desktop applications, particularly with Rust, or C++ skills, we’d love to hear from you. We are looking for someone who can work on a diverse set of challenging and interesting problems, from remote application control on OSX and Windows, to maintaining Rust based backend infrastructure.
We still aren't using hardware accelerated encoding. It's the last, and biggest contributor to CPU we see after profiling.
Moving to Rust was more of a decision for safety, than for performance, since most of the code we ported to Rust was in C++ already. The good news is we didn't see dramatic differences in performance between C++ and Rust.
Rust has a bunch of highly optimized, fantastic libraries, that helped with testing, profiling, and evaluating hardware acceleration/SIMD.
We will be putting together a blog about our experiences with Rust & C++, that goes into the nitty gritty of the good, the bad, and the ugly of our experiences here.
A great deal of the optimizations came from better profiling, better tooling, and a focus in that area. There is still a ways to go, and we are continuously working on improvements in this area.
Rust has been an incredible tool on reducing the work required to maintain, and change, core components, and we have even been able to have Rust target a static cylib library, and linked it in from a large C++ library.
The really great thing with Rust is it has a very minimal runtime, and integrates well with C++. It's not an all-or-nothing proposition to integrate it into a project. The maturity of the tooling, third party libraries, the build and package system, have been incredibly useful tools.
I am an avid Synergy user, and what they have accomplished in terms of direct mouse/keyboard input synchronization is very impressive, and I use it on a daily basis.
I can say however, it's very different than CoScreen and what CoScreen seeks to achieve, and is performed in a technically different manner.
CoScreen injects mouse interaction and keyboard presses directly into a window on OSX (if it isn't a weird type of window like an emulator, or something that captures and handles input on a very low level).
Synergy simulates mouse movements/events directly over windows, interfering with the position/location and current state of the remote cursor. It's much more like a remote mouse-driver for a lack of a better comparison.
In many ways this is more performant, simpler, and works on a wider variety of windows right out of the box.
On another level it interferes more with remote users, and prevents multi-player collaboration.
I definitely could see us producing a mode that is LAN focussed and which provides synergy like behavior, but the current remote collaboration is really geared from a UX perspective around multi-player in CoScreen.
I think cutting through the hype-train is something every engineer learns with time, but some times there are diamonds to be picked out.
At least for my own anecdotal experience, Rust has lived up to a lot of the hype for the time-critical low-level projects I was formerly performing with C/C++.
Agreed, though I’m sad it isn’t more often used. It’s certainly picking up steam, but it seems to have a ways to go before it’s going to be a serious contender for new projects in the embedded, video game, etc spaces where C/C++ still reign (by which I mean something like “before the majority of new projects are implemented in Rust”).
There was a time when memory was conventionally expensive, memory allocation of large blocks was slow, and small blocks was much faster (malloc would find a small block faster than a large one on a highly fragmented heap).
Before having gigantic caches that would engulf nearly any sized contiguous list, linked lists were sort of vogue, frugal, and thought of as being fairly performant.
That time is still there in embedded hardware. Even potent ARM chips (except the cellphone ones maybe) have some KB of cache at best, and similar amounts of SRAM. While code size is still at a premium since XIP (execute-in-place from in-built flash) is slower.
Isn't the overhead for C++ exceptions quite significant, especially if an exception is thrown?
Exception handling can also increase the size of the binary because of the additional data needed to handle stack unwinding and exception dispatch.
I think a number of optimizations are made quite a bit more complex by exception handling as well.