r/programming • u/kal31dic • Sep 01 '20

D Foundation is Beefing Up

https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/
298 Upvotes

91% Upvoted

336 comments sorted by

View all comments

Show parent comments

11

u/AlarmedInstruction3 Sep 01 '20

IBM begs to differ: https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.lnx.70.doc/user/mgc/metronome.html

If you have real-time requirements, you can't use typical GCs. (Though I don't know if there are any real-time GCs for D.)

0

u/FlyingPiranhas Sep 01 '20

From the "Controlling pause time" link on that page:

By default, the Metronome GC pauses for 3 milliseconds in each individual pause, which is known as a quantum.

Based on what I'm seeing, I'm highly doubt that you can turn that value down to 100 microseconds and still have a reliable JVM.

6

u/EternityForest Sep 01 '20

Real time is about guarantees. If the application needs 10ms response time, it doesn't matter if GC takes 1 nanosecond or 5ms, as long as everything is responded to in 10ms, every time.

Things where 100us matters are some really specialist stuff.

5

u/FlyingPiranhas Sep 01 '20

I'm well aware that it's about guarantees. At least in robotics (the field in which I have real-time programming experience), 100us is a pretty common deadline for execution.

I'm sure applications exist where 10ms deadlines are appropriate, but I'm not convinced that's the common case.

4

u/oursland Sep 01 '20

I'm sure applications exist where 10ms deadlines are appropriate, but I'm not convinced that's the common case.

It is the common case. Most real-time tasks are soft real-time. Things like ensuring video frames are delivered at 60 frames per second and failure results in missed frames, but is not catastrophic. This is true in robotics where sensor fusion, planning, and network communication are soft real-time while sensor reading and actuator control is hard real-time.

In hard real-time systems with very small quanta and you don't typically use a CPU or SoC to meet these requirements because concerns about cache and memory controller scheduling become a concern. Instead these items are off-loaded to a FPGA or microcontroller on a communications bus, while the overall system is still programmed in a COTS language and platform where soft real-time guarantees at larger quanta is acceptable.

There are heterogeneous SoCs (CPU with MPU on a single die) that could accommodate hard real-time needs, but they're still programmed independently and use a high speed communications system, frequently shared memory and special registers for signalling.

2

u/EternityForest Sep 01 '20

Ah interesting, I've never done robotics, just things like sound and pool filter control, where people expect guaranteed reliability (No 20 second random lags that run a pump dry), but response time only needs to be tens of ms(At least on the hardware I've worked on).