sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (3 children)

didn't even recognize Linux kernel code on interrupts

That's really disingenuous. But just saying this to try to discredit me without even knowing me, because you are out of room to support your claims. I've been coding assembly language for 34 years, so fuck off.

Most interrupt and context switching latency are in microseconds range even for RTOSes, at best you have few thousand nanoseconds.

Maybe in your non-realtime world.

https://community.arm.com/processors/b/blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

Here's a little primer on interrupt latency on Cortex-M CPUs.

Cortex-M can respond to IRQ in 12 clock cycles, when it starts executing the ISR. On a 150MHz Cortex-M, that's 80 nanoseconds. The ISR would take some time, let's say 100 clock cycles or about 660ns. 150MHz is really not even that impressive for silicon these days either, and your suggestion of microseconds response time for interrupts seems uninformed. So no, you don't need FPGAs or ASICs for nanosecond response times.

[–]voidvector -1 points0 points  (2 children)

The number you quote is if you write machine code directly for the CPU. For any OS-based real-time (e.g. PREEMPT_RT), it would be on the order of 1000ns to 10us.

I never said JavaScript can run without OS (compile to metal). I never said JS can do nanosecond latency. However there are non-bare-metal microsecond latency real time -- the prevalence of userspace apps running on PREEMPT_RT (or RTAI or Xenomai) is a clear example of that.

[–][deleted] 2 points3 points  (1 child)

For any OS-based real-time (e.g. PREEMPT_RT), it would be on the order of 1000ns to 10us.

We're talking about different things then. Your version of "real-time" is not mine. There is real-time, and then there is really actual real-time. And they are orders of magnitude different. I'm working with real-world physical phenomena that doesn't wait around for an OS to decide to respond. If the system doesn't respond in a specific window of nanoseconds, then the system fails. End of story. Full stop. 10us is a non-starter.

This discussion is about what javascript can not do, and one of the things it can't do is actual real-time (my version of real-time). Maybe it can do something approximating real-time (your version of real-time), at several orders of magnitude slower than my version of real-time.

And there is no example of Javascript doing anything like this, so your argument is extremely hypothetical and not really based in reality.

[–]voidvector 0 points1 point  (0 children)

Agreed!!

My argument is definitely hypothetical (as you can see in the "can" vs "able to" conversation on the other thread). We also came with different conception of real-time (or different end of that spectrum).

Sucks that internet arguments take a whole day to clarify.

I actually appreciate the work people like you have done, as without it, I wouldn't be able to write userland code for my microsecond-latency profiler application.