The paper linked in the ARS article (https://dl.acm.org/doi/abs/10.1145/3445814.3446723 https://dl.acm.org/doi/abs/10.1145/3445814.3446723) seems to be how they

The paper linked in the ARS article (https://dl.acm.org/doi/abs/10.1145/3445814.3446723 https://dl.acm.org/doi/abs/10.1145/3445814.3446723) seems to be how they developed it. I find it interesting that they went from C++ to hardware in order to optimize the development and verification time. In my past experience working with FPGA designers, I was always told that any C-to-H(ardware) tooling was always quicker to develop but often had significant performance implications for the resulting design in that it would consume many more gates and run significantly slower. But, if you have a huge project to undertake and your video codec is only likely to be useful for a few years, you need to get an improvement (any improvement!) as quick as possible and so the tradeoff was likely worth it for Google. Or possibly the C-to-H tooling has gotten significantly better recently? Anyone aware of what the state of the art is now with this to shed some light on it?