HN user

rbultje

398 karma
Posts6
Comments78
View on HN
Dav2d 2 months ago

Lets see AI take the AV2 spec and Dav1d code and try to make a working high performance AV2 decoder.

That sounds like one of these high-risk, high-reward things that are great for people / projects / companies who have nothing to lose, but is not a great baseline strategy for an established market player. AV2 is here with support from aomedia and its members. AV2 will be used, and we need a production-grade decoder regardless of where AI is at, so it makes much more conservative business sense to use established approaches (language: c/asm, devteam: ffmpeg/dav1d) as a starting point. While that's happening, we can dabble in AI and other risky stuff and see if it helps. If so, great, and if not, nothing lost.

Dav2d 2 months ago

dav2d author here - the 5x number is just where we currently are, it's not the theoretical limit. We're hopeful that a significant amount of the increase we observe in dav2d relative to dav1d is in math code, which should be easier to optimize using hand-written assembly or other algorithmic optimizations. If that holds true, the practical slowdown once everything has been optimized may be substantially less, possibly 2x.

The opposite of what you're saying is "perfection is the enemy of progress", so let's move past them. I'm asking for more than "this is not the way". What is the way? How will we do this? This is critical, and we've failed to do anything since early 2022. Democrats are clearly not at all interested. My (Dem) congressman responded directly to my enquiry with "fixing section174 just wouldn't be good optics". I agree republicans can't be taken very seriously either if OB3 is the highest of highs. But we all want this fixed. So: how?

This isn't changing if it is taxed or not.

This is untrue. The rule is not about taxation, but deductions/expenses. If your expenses cover most revenue, you owe little in taxes. With this rule, a particular type of expense (software engineering salaries) is no longer deductible from revenue to calculate taxable income over which taxes are owed. So you might previously owe no taxes, but now you do. The deduction might carry over to the next few years and eventually (after 6 years) you will reach the same point - assuming your salaries don't go up and your business doesn't grow. The remainder in deductions will be returned after the business stops employing software engineers. I'm not sure why anyone would want the tax code to incentivize a business outcome that all of us would consider failure.

We don't talk about this enough. International R&D is not offshoring of call-centers to India. International R&D is the IP for the next generation of global communication standards being owned by US-based or foreign corporations, because international (e.g. Canadian, European) standards experts/developers become un-affordable for US-based corporations and are forced to work for our "adversaries" instead. Crazy.

Large companies always find a way to not pay taxes. It's the little guys that end up paying (a lot!) more, to the extend that it cripples and kills them. But transformative innovation happens with the little guys. As a result, this tax change cements monopolies for megacorps. They will be fine and still pay nothing.

This is a weird take. Employees are supposed to be business expenses, that's the core idea of running a business: profit = revenue - expenses, where expenses are personnel / materials, and pay taxes over profit. Since the R&D change, businesses can't fully expense employees and need to pay (business) taxes over their salaries. Employees - of course - still pay personal taxes also (as was always the case).

I sure hope a broader exploration precedes micro-optimizing register allocation and calling conventions.

It should be obvious that both are pursued independently whenever it makes sense. The idea that one should precede the other or is more important than the other is simply untrue.

Binary size was a concern, so excessive inlining was undesirable.

And don't forget that any asm-optimized variant always has a C fallback for generic platforms lacking a hand-optimized variant which is also used to verify the asm-optimized variant using checkasm. This might not be linked into your binary/library (the linker eliminated it because it's never used), but the code exists nonetheless.

If it's so heavy in assembly, the fact that ffmpeg works on my Mac seems like a miracle. Is it ported by hand?

Not ported, but rather re-implemented. So: yes.

A bit more detail: during build, on x86, the FFmpeg binary would include hand-written AVX2 (and SSSE3, and AVX512, etc.) implementations of CPU-intensive functions, and on Arm, the FFmpeg binary would include hand-written Neon implementations (and a bunch of extensions; e.g. dotprod) instead.

At runtime (when you start the FFmpeg binary), FFmpeg "asks" the CPU what instruction sets it supports. Each component (decoder, encoder, etc.) - when used - will then set function pointers (for CPU-intensive tasks) which are initialized to a C version, and these are updated to the Neon or AVX2 version depending on what's included in the build and supported by this specific device.

So in practice, all CPU-intensive tasks for components in use will run hand-written Neon code for you, and hand-written AVX2 for me. For people on obscure devices, it will run the regular C fallback.

Sadly no mention of Section-174, which is a contributing factor. As a reminder, TCJA (2017) amended Section-174 (with a 5-year deferral) to require amortization over 5 (domestic) or 15 (foreign) years of all R&E expenses, and included all software development under R&E. This went into effect in 2022. This causes unexpected employer tax bills over money that has been spent on employee salaries and over which these employees are also taxed.

There have been repeated promises by congress to fix it but these efforts have failed so far. The latest attempt, HR7024, received overwhelming support in the house but stalled in the senate over objections by Idaho senator Mike Crapo and was later voted down (mostly by senate Rs, but also notable by a handful of progressive Ds).

Blog author (and dav1d/ffmpeg dev) here. My talk at VDD 2023 (https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=9290s) did a comparison like the ones asked above. I compared an intrinsics implementation of the AV1 inverse transform with the hand-written assembly one found in dav1d. I analyzed the compiler-generated version (from intrinsics) versus the hand-written one in terms of instruction count (and cycle runtime, too) for different types of things a compiler does (data loads, stack spills, constant loading, actual multiply/add math, addition of result to predictor, etc.). Conclusion: modern compilers still can't do what we can do by hand, the difference is up to 2x - this is a huge difference. It's partially because compilers are not as clever as everyone likes to think, but also because humans are more clever and can choose to violate ABI rules if it's helpful, which a compiler cannot do. Is this hard? Yes. But at some scale, this is worth it. dav1d/FFmpeg are examples of such scale.

Who does this benefit in a zero-sum competition scenario, assuming that everybody is affected.

Foreign-run software companies not affected by this law, big companies with deep pockets that don't need to fear upstart competition, and other industries that are not R&E but can enjoy the lower tax rates from TCJA that were paid for with this revenue.