I had a similar experience with HardCaml back in 2015/2016. The benefits where overwhelming: higher productivity, higher reusability, less intractable bugs, tighter TTM, and no more slippage in deliverables timeline. The performance where comparable to Verilog-only project (density, path length). In the end, the effort was shut down by management because the approach was “too complicated”.
@saurabhsharan Signed up; my account page is blank and I am not getting any result. I am not getting any way to unlink my accounts or check what is being done with my information. Seems a little fishy so far.
Wikileaks believed at the time that Clinton was ready to send a drone to get rid of Assange. Between due process and a drone attack, I take due process any day.
You may be right about the DE -> Fellow promotion, although I only heard of it once, and that person was pretty spectacular. The Fellow -> DE path is unheard of. As is the RSM -> DE. All the DEs I know came from SWG and were STSM.
Re: my “dilution” comment, i was not thinking about DEs. I was thinking about non-technical people (management, law, accounting, ...) that have been creeping up the Fellowship lately. Also the bluewashed executive that were given a fellowship package to seeeten the pot.
The IBM ranks are inaccurate. Fellows are not above DEs. Both are the highest ranks indeed, but of two different tracks. DE is the highest rank of the engineering track, while Fellow is the highest rank of the research track. Fellowship have also be granted to non-research people over the past 20 years, diluting the merit of the title IMHO. Examples of fellows are: John Backus, Gene Amdahl, Ken Iverson, Benoit Mandelbrot, etc.
Both levels may reside in different pay bands, but they are both at the executive level. And DEs cannot become fellows, and vice versa (some exceptions to the rule may have existed).
I was in undergrad and grad school in Grenoble where I had F. Maraninchi and P. Caspi as teachers for the synchronous programming and VLSI classes (embedded system track). We did a lot of Lustre. It's a pretty great way to get acquainted with synchronous programming and all the fun stuff that derives from it (cf. SDF, code generation, soft/hard real-time, and FPGA programming). Fun times.
The ordinance of Villers-Coterets[1] was limited to legal documents, whereas the efforts led during the Terror were aimed at eradicating local languages[2], seen as so many shackles keeping the peasants from being enlightened.
It certainly is not "the French". It's the "French Republic". Local dialects lived happily in France for over a Millennia under the Monarchy. The French dialect, mostly spoken in the Jacobin circles in Paris, was imposed by the revolutionaries as a mean to achieve "equality".
Niklaus Wirth is one of those unsung geniuses of computer science. He invented Pascal, the Modulas, Oberon ...
Then he woke up one morning wanting to reboot his life's work for his class and, undeterred by the fact the original targeted processor did not exist anymore, settled to write his own computer architecture on a Xilinx Spartan.
He then successfully ported the Oberon system and compiler to this architecture to demonstrate to his students.
> Which is to say, you're saying "detrimental impact on performance" and yet this seems to be a significant win over BSD sockets.
The point I was trying to drive home is that, while 30% overhead reduction compared to BSD socket is nothing to laugh at, a fully user-space UDP/TCP network stack combined with memory-mapped buffer sharing usually gives performance improvement measured in the "x" and not in the "%".
Now, there is not much in terms of experiment protocol in their material so its very hard to tell. You mention uncompressed video so they could be sending humongous frames, which I doubt as no one ever would send raw frames over the network (that would be several MB per frame for a 720p front camera). But if that is the case then the data copy operation becomes the predominant bottleneck and getting rid of one may justify the improvement. But that is not a realistic scenario.
The more realistic scenario is that they sent compressed delta-frames across the network (H264 or HEIF), which would then considerably reduce the transferred payload size. In that scenario, data copy is not the predominant overhead anymore and 30% overhead reduction is underwhelming, telling me that they still are calling expensive operations like syscalls/uIPC on the critical data path.
> I doubt they would have explicitly put TCP if it was not true
I am not doubting they have some sort of user-space TCP implementation. I am trying to understand how much of TCP they moved out of the kernel. From what I can gather they still have enough of it in the kernel such that the related syscall/uIPC overhead does not allow more than the 30% performance improvement announced.
Re: your clipboard issues, which platform are you running on? I am using vim+iTerm2 on OSX and vim+st on OpenBSD and the clipboard integration works flawlessly.