Hacker News Reader

Comment by jsheard | Hacker News Reader

Good ol' "SIGGRAPH realtime", when a graphics paper describes itself as achieving realtime speeds you always have to double check that they mean actually realtime and not "640x480 at 20fps on the most expensive hardware money can buy". Anything can be realtime if you set the bar low enough.

View on HN

Depending on what you’re doing, that really isn’t a low bar. Saying you can get decent performance on any hardware is the first step.

> get decent performance

The issue is that in Computer Science "real-time" doesn't just mean "pretty fast", it's a very specific definition of performance[0]. Doing "real-time" computing is generally considered hard even for problems that are themselves not too challenging, and involves potentially severe consequences for missing a computational deadline.

Which leads to both confusion and a bit of frustration when sub-fields of CS throw around the term as if it just means "we don't have to wait a long time for it to render" or "you can watch it happen".

[0] https://en.wikipedia.org/wiki/Real-time_computing

That link defines it in terms of simulation as well: "The term "real-time" is also used in simulation to mean that the simulation's clock runs at the same speed as a real clock." and even states that was the original usage of the term.

I think that pretty much meets the definition of "you can watch it happen".

Essentially there is real-time systems and real-time simulation. So it seems that they are using the term correctly in the context of simulation.

I don't think it's reasonable to expect the larger community to not use "real time" to mean things other than "hard real time as understood by a hardware engineer building a system that needs guaranteed interrupt latencies".

I think it’s reasonable to assume that it means what you described on this site.

Of course. I'm in the "Reality is just 100M lit, shaded, textured polygons per second" kind of guy- realtime is about 65 FPS with no jank.

>> Anything can be realtime if you set the bar low enough.

I was doing "realtime ray tracing" on Pentium class computers in the 1990s. I took my toy ray tracer and made an OLE control and put it inside a small Visual Basic app which handled keypress-navigation. It could run in a tiny little window (size of a large icon) at reasonable frame rates. Might even say it was using Visual Basic! So yeah "realtime" needs some qualifiers ;-)

Fair, but today it could probably run 30FPS full-screen at 2K resolution, without any special effort, on an average consumer-grade machine; better if ported to take advantage of the GPU.

Moore's law may be dead in general, but computing power still increases (notwithstanding the software bloat that makes it seem otherwise), and it's still something to count on wrt. bleeding edge research demos.

Microsoft once set the bar for realtime as 640x480 @ 10fps. But this was just for research purposes. You can make out what it is trying to do and the update rate was JUST acceptable enough to be interactive.

I’d actually call that a good bar. If you’re looking 5-10 years down the line for consumers, it’s reasonable. If you think the results can influence hardware directions sooner than that (for better performance) it’s also reasonable.

It can be run real time. Might be 640x480 or 20 fps, but many algorithms out there could never been run on an $10k graphics card or even a computing cluster in real time.

I mean A100's were cutting edge a year or so ago now we're at what H200 and B200 or is it 300's like it may be a year or 2 more but the A100 speed will trickle down to the average consumer as well.

And, from the other end, research demonstrations tend to have a lot of low-hanging fruits wrt. optimization, which will get picked if the result is interesting enough.

Reply on news.ycombinator.com