HN user
when exceptions would add no overhead
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.
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.
https://www.p99conf.io/2022/09/07/uninitialized-memory-unsaf...
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.
Senior Video Conferencing Engineer: https://careers.datadoghq.com/detail/5103763/?gh_jid=5103763
Backend Systems Engineer: https://careers.datadoghq.com/detail/5103658/?gh_jid=5103658
Tech stack: Rust, C++, Typescript, Electron, WebRTC, XMPP, Jitsi.
Compensation: $130000.00 - $300000.00, plus a competitive equity package, and may include variable compensation.
Contact: ben.papismedov@datadoghq.com, jason.thomas@datadoghq.com
Sorry I missed this.
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.
We're good friends with the Jitsi guys, and I have worked with Jitsi for many years now.
Here is a interview I did of Emil Ivov, the founder of the Jitsi project:
Jason Thomas, former CoScreen CTO here.
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.
For a full blown Linux client, we haven't yet set that date.
We are working on a headless Linux client that will allow you to stream first pty/terminals, and then windows, into a CoScreen from Linux systems.
It's going to be a very small utility, and we hope to provide access to it by May/June.
This will eventually evolve into a full blown client.
In the meantime we will have a web client which will work on Linux released shortly, it's currently being privately tested within DataDog.
We are using WebRTC for both Audio/Video and screen sharing.
The Audio/Video are using VP9 SVC, and are a pretty typical configuration, using Jitsi as the backend.
The screen sharing is accomplished via a combination of libwebrtc and native Rust.
I always look for practical application.
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++.
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.
The reality hammer hits quite a bit harder when people are playing the "fake it until you make it" game with C++ versus other languages as well.
I started as an embedded software engineer in the early 90's, and at the time there were lots of well paying jobs compared to other software engineering diciplines.
In the 2ks/10's, at least in my area, embedded jobs dried up. Mobile development produced a lot of very high performance SoCs that were cheap, and had high quality already developed middleware layers (Android for instance). They sort of conquered a lot of the embedded media processing space I was an expert in.
As a result I jumped ship to mobile, but it was much higher level programming far away from the SoC, and most of the lower level code was being written in China/South Korea.
This basically meant for the engineers that weren't able to shift, they basically weren't scouting around for, or finding other jobs (in general).
So even though there is a small pool of engineers with these skills, a lot of people left the embedded space at a time when some of those jobs are starting to shift back, leaving a shortfall, but also a pay gap.
I'm really surprised at how stable and widely supported Rust's FFI is.
I have several C++ projects that integrate a portion written in Rust, where the Rust project produces a .a file that is ultimately linked with clang into a larger C++ project.
I definitely agree Rust has a long road to adoption in embedded/low level systems, and particularly areas with custom compilers/toolchains that rely heavily on system specific undefined behavior.
But it's a lot closer than I had thought it was a year or so ago.
HireVue AI Assessment.
Now is the time to hone your skills in a highly in-demand area, with little competition.
Get Linux on your computer, study the Linux kernel, and learn about EBPF.
Write some monitoring software using EBPF, learn all about it. Learn about the Linux Kernel, and LDD.
Then apply for jobs in these areas, be ambiguous about your on-the-job experience.
Speak competently when you get the interview about the tech, the companies that are hiring for these skills are desperate to hire for them, there aren't people with these skills falling out of trees.
It's a bad time in the industry, but unemployment is something like 2.3%. There is a position out there for you.
So many creational design patterns rely on static factory methods too.
I'm not really sure what they're on about.
I imagine part of the strategy should be to use the funds from the tax to counter the negative effects of the product.
This was an effective strategy for smoking. Stopping ads for soda, and similarly producing ads that inform people of the risks of high amounts of soda consumption with the tax.
AFAIK Pharo is a fork of Squeak, which is much more open about it being a smalltalk programming system implementation.
The dish soap method worked best for me. But the best method was getting lasik, now my old glasses are in a drawer gathering dust.
This is so beautiful.
Super cool not having manual thread joining code.
I would guess just having a lot of blockchain experts on staff, and since the blockchain is pretty much an open, unencrypted, public ledger; analyzing it is a pretty natural and not entirely unethical thing to do.
I think the issue is really just working with ICE, and the ethical concerns that brings up.
I'm similar in that I've jumped between embedded, web dev, etc etc.. through my career, and it was always easy to learn new things.
I think it was actually the newness of the things that made me interested and kept me focussed on them enough to break through and make changes.
The JS world has left me feeling similarly fatigued when every couple of years there is a new variation on what seems to be the same old concepts, with very little conceptually different enough to make it feel like I'm learning something of value.
Maybe deep inside your brain it knows this latest thing you're going to learn is likely to be quickly deprecated, and it just can't bring the dopamine levels in your brain up high enough to keep you focussed and interested.
Definitely it can be burnout, but I wonder also if it could be ADHD linked? Inability to focus on something you have to focus on for your livelihood will absolutely lead to anxiety and depression.
Switching to a different field (Cybersecurity) and writing EBPF tracing stuff really helped restore my confidence that I really enjoy writing software.
A change of scenery can really help, and there are so many interesting new things to choose from out there.
I downloaded Solar Winds from a BBS when I was a kid, and I have played it several times again throughout the years. I get strong nostalgic feelings from playing it.
Solar Winds Galaxy is solid too, but not as engaging or as interesting of a story line.
UQM is definitely way more complex and involved. I remember dedicating days to it just to end up losing because of the deadline which I found pretty frustrating.
I worked on some data acquisition software that was in a beam-line (SLAC), but we just made sure to surround everything with lead bricks.
I've never sent any hardware into space, but some former colleagues of mine were working on OWL around the time I left: https://asd.gsfc.nasa.gov/archive/owl/science.html
So, it was a long time ago, and I did use a JTAG emulator/debugger called the "Partner JET:" https://www.kmckk.co.jp/eng/gigatrace_index.html
It was extremely expensive, and commercial, I'm honestly surprised I could even find a website for it.
It was extremely cool to basically scroll through memory, our hardware had an on-board FPGA that gathered waveforms from a photomultiplier tube attached to a scintillator, and when I was writing the driver for it, I could watch the memory in real-time with the debugger changing.
Setting initial values of memory to something like 0xDEADBEEF, and using this thing, was an incredibly powerful debugging strategy, especially when dealing with hardware.
I haven't, to be honest I'm not much of a writer.
I have a good friend however who is a great writer, and who has written a lot about her experiences, and who is working there again: https://www.jamiezvirzdin.com/
She didn't work much on the software/hardware side of things, however.
Maybe one day I'll sit down and put some of it to paper, I definitely have a lot of stories to tell.
We used SH4 chips for the cosmic-ray surface detector array for the Telescope Array project: http://telescopearray.org/
I cut my embedded development teeth writing device drivers and custom firmware targeting it.
The reason we used SH4 is because the Dreamcast had failed, so there was a huge surplus of them available on the market at the time.
It was easily one of the most interesting and rewarding projects of my life to work on.
I think in Python, I saw a good deal of adoption in the Sciences early on.
I worked on a Physics experiment almost 15 years ago, there were inklings of Python dripping in to doing numerical analysis.
NumPy just using existing Fortran libraries is a good example of it just being bootstrapped by the scientific community.
Most of these guys come from a Fortran background, and some used the C++ ROOT framework.
Ruby was just too alien for them.
ROOT had made some excellent Ruby bindings, and I spent some time showing some of my colleagues how much time they could save using them, but they just found it to be too different.
It's sort of funny to think, because languages made for AI originally like LISP used functional concepts like map, collect, etc etc...
I think the AI trend using Python was boosted by numerical analysis/computing libraries already being present.
Full disclosure, we still use hackerrank for just this internally.
I just think if a candidate scores a 70%, I don't expect them to be better or worse than a candidate who scores 100%.
Having criteria to perform an interview is one thing, but if your interview is just to go in with another toy challenge on a whiteboard, I think it would be much better to do a demo project, and immediately pair-program before making the decision to hire.
Fair, you could use a lot of other platforms to do the same thing.
But you can't fault me for plugging CoScreen ;)