3 ms·

Probably a better way of looking at it is hard real time is hard, in several senses of the term. You don't really want any operations that have variable time at

by jerf 4y ago

Probably a better way of looking at it is hard real time is hard, in several senses of the term. You don't really want any operations that have variable time at all. If that feels like a really difficult specification to work with, it is. Soft real time is more common. Soft real time theoretically has the same considerations, but in general you have enough performance that you can wave away many of these difficulties; yes, technically my hash table is not 100% reliable every time but as I can show it'll never have more than 128 entries, and I've got 25ms targets for this task I'm doing, and I've got 32MB when my code only uses about 4 max, and these numbers are all large enough that I can just not care about the resizing operation. I've got many systems I've written that are just straight-up accidentally soft-real-time in practice simply because running them on even a moderately-powerful modern PC is a hundred times more power than they really need, and they're already 10-50 times faster than they "need" to be even before optimizing them, so barring pathological network performance that would trash any system, they're essentially soft real time already. You don't back your way into hard real time, though.

fluoridation 4y ago
>I've got many systems I've written that are just straight-up accidentally soft-real-time in practice simply because running them on even a moderately-powerful modern PC is a hundred times more power than they really need, and they're already 10-50 times faster than they "need" to be even before optimizing them, so barring pathological network performance that would trash any system, they're essentially soft real time already. But the categorization of real-time depends on the requirements of the problem, not how difficult it is to meet them. If your problem tolerates a few missed deadlines every now and then and your hardware is such that a naive implementation misses deadlines so frequently that it's useless, and so you need to optimize it thoroughly to get the misses under control, it's still soft real-time. It doesn't become soft real-time when technology advances enough that even an inefficient implementation will tolerably a deadline only occasionally.

by jerf 4y ago

fluoridation 4y ago

>I've got many systems I've written that are just straight-up accidentally soft-real-time in practice simply because running them on even a moderately-powerful modern PC is a hundred times more power than they really need, and they're already 10-50 times faster than they "need" to be even before optimizing them, so barring pathological network performance that would trash any system, they're essentially soft real time already. But the categorization of real-time depends on the requirements of the problem, not how difficult it is to meet them. If your problem tolerates a few missed deadlines every now and then and your hardware is such that a naive implementation misses deadlines so frequently that it's useless, and so you need to optimize it thoroughly to get the misses under control, it's still soft real-time. It doesn't become soft real-time when technology advances enough that even an inefficient implementation will tolerably a deadline only occasionally.