zlacker

[parent] [thread] 6 comments
1. Neywin+(OP)[view] [source] 2025-12-05 15:26:12
Hmmm disagree on your chain there. Plenty of easy hardware algorithms are hard for software. For example, in hardware (including FPGAs), bit movement/shuffling is borderline trivial if it's constant, while in software you have to shift and mask and or over and over. In hardware you literally just switch which wire is connected to what on the next stage. Same for weird bit widths. Hardware doesn't care (too much) if you're operating on 9 bit quantities or 33 or 65. Software isn't that granular and often you'll double your storage and waste a bunch.

I think they certainly go hand in hand in that algorithms relatively easier for software vs previously are easier for hardware vs previously and vice versa, but they are good at different things.

replies(1): >>cogman+t4
2. cogman+t4[view] [source] 2025-12-05 15:45:23
>>Neywin+(OP)
I'm not claiming that software will be more efficient. I'm claiming that things that make it easy to go fast in hardware make it easy to go fast in software.

Bit masking/shifting is certainly more expensive in software, but it's also about the cheapest software operation. In most cases it's a single cycle transform. In the best cases, it's something that can be done with some type of SIMD instruction. And in even better cases, it's a repeated operation which can be distributed across the array of GPU vector processors.

What kills both hardware and software performance is data dependency and conditional logic. That's the sort of thing that was limited in the AV1 stream.

replies(1): >>IshKeb+dM3
◧◩
3. IshKeb+dM3[view] [source] [discussion] 2025-12-06 22:15:30
>>cogman+t4
> Bit masking/shifting is certainly more expensive in software, but it's also about the cheapest software operation. In most cases it's a single cycle transform.

He's not talking about simple bit shifts. Imagine if you had to swap every other bit of a value. In hardware that's completely free; just change which wires you connect to. In software it takes several instructions. The 65 bit example is good too. In hardware it makes basically no difference to go from 64 bits to 65 bits. In software it is significantly more complete - it can more than double computation time.

I think where software has the advantage is sheer complexity. It's harder to design and verify complex algorithms in hardware than it is in software, so you need to keep things fairly simple. The design of even state-of-the-art CPUs is surprisingly simple; a cycle accurate model might only be a few tens of thousands of lines of code.

replies(2): >>Neywin+1S3 >>cogman+yS3
◧◩◪
4. Neywin+1S3[view] [source] [discussion] 2025-12-06 23:04:26
>>IshKeb+dM3
Right. It's bit packing and unpacking. Currently dealing with a 32 bit system that needs to pack 8 11 bit quantities each subsisting of 3 multi bit values into a 96 bit word. As you can imagine, the assembly is a mess of bit manipulation and it takes forever. Ridiculously it's to talk to a core that extracts them effortlessly. I'm seriously considering writing an accelerator to do this for me
◧◩◪
5. cogman+yS3[view] [source] [discussion] 2025-12-06 23:09:37
>>IshKeb+dM3
I just have to repeat myself

> I'm not claiming that software will be more efficient. I'm claiming that things that make it easy to go fast in hardware make it easy to go fast in software.

replies(1): >>IshKeb+fU3
◧◩◪◨
6. IshKeb+fU3[view] [source] [discussion] 2025-12-06 23:21:33
>>cogman+yS3
Right... That's what I was disagreeing with. Hardware and software have fairly different constraints.
replies(1): >>cogman+w14
◧◩◪◨⬒
7. cogman+w14[view] [source] [discussion] 2025-12-07 00:21:46
>>IshKeb+fU3
I don't think you have an accurate view on what makes an algorithm slow.

The actual constraints on what makes hardware or software slow are remarkably similar. It's not ultimately the transforms on the data which slow down software, it's when you inject conditional logic or data loads. The same is true for hardware.

The only added constraint software has is a limited number of registers to operate on. That can cause software to put more pressure on memory than hardware does. But otherwise, similar algorithms accomplishing the same task will have similar performance characteristics.

Your example of the bitshift is a good illustration of that. Yes, in hardware it's free. And in software it's 3 operations which is pretty close to free. Both will spend far more time waiting on main memory to load up the data for the masking than they will spend doing the actual bit shuffling. The constraint on the software is you are burning maybe 3 extra registers. That might get worse if you have no registers to spare forcing you to constantly load and store.

This is the reason SMT has become ubiquitous on x86 platforms. Because CPUs spend so much time waiting on data to arrive that we can make them do useful work while we wait for those cache lines to fill up.

Saying "hardware can do this for free" is an accurate statement, but you are missing the 80/20 of the performance. Yes, it can do something subcycle that costs software 3 cycles to perform. Both will wait for 1000 cycles while the data is loaded up from main memory. A fast video codec that is easy to decode with hardware gets there by limiting the amount of dataloads that need to happen to calculates a given frame. It does that by avoiding wonky frame transformations. By preferring compression which uses data-points in close memory proximity.

[go to top]