Essentially all of the processing of the video data, barring the container format which the CPU uses to know what part of the data to send to the GPU or the Audio chip or codec.
And HW acceleration is generally a preset baked in version of the encoder or decoder. These are mostly codec specific.
So, no using hardware from previous versions.
Now, you can see some software that tries to use the GPU itself, instead of the dedicated hardware acceleration, to decode, but that isn't the HW accelerated, and may not operate in real time.
At the same time, that will consume much more power, eliminating some of the advantages or the pure HW rendition, especially important for mobile.
I could see an argument being made for encoding, if it is 2x or faster than the CPU, but I haven't looked at any in a while, so don't know the speeds.
Yes and no. It is just Zig, but that is the advantage. And compiling it to an special function that could work as an end seems to be a doable thing, so you would just have to have the compiler in your agent.
They work better for coding workloads. Essentially, the more regular the output, the more the faster model gets right, the less the big model has to do.
Writing tends to have more false positives. I haven't tried this particular one, however, but that is the general trend.
It does to an extent. One thing I will give AI, because of the nature of LLMs, you are essentially arguing with the median level of the input that trained the model. So, for someone new to the subject, you get access to patterns that will bring them up to a certain level.
As long as you don't keep calling out to the CPU, that is.
Tool calling, searches, cache movement if used, and even debug steps all stall the GPU waiting for the CPU.
There was a test of turning one of the under 1B Qwen3+ models into a kernel that didn't stall by the CPU as one GPU pass that saw quite a bit f perf lift over vLLM, I believe, showing this is an issue still.
Its been a month, so I don't remember more details than this.
Even in humans, negative stimuli carries more weight than positive, in the general case.
Without reading it yet, my first thought would be to test a general ratio, something similar to human interpersonal relationship ratios like 30% negative to mostly positive, and positive are targeted, such as reinforcement not just for the good job, but reinforcement for the improvement.
And ensure the negative is targeted, such that you point out tendencies to be avoided rather than just specific instances.
Of course, most human interaction online has none of this, so, would be hard to replicate.
The browser is faster because they went native, in particular, GPU.
Every issue described is text rendering related. Everyone.
And I would bet most of the SwiftUI issues could be solved with a text render cache.
Something like Casey Murati's refterm toy that showed what that can do with no other optimizations, or the work for GPU accelerated terminal emulators like alacritty or ghostty.
For instance, history, newer information is mixed with older authoritative information.
The same thing for religious institutions, where the older items may be the more authoritative for the purposes.