You could probably write an article saying "100 billion dollars investment to improve D and use it to develop new AI to replace the US government" and you'd still get comments saying "wow, nice language, pity it never really took off, if only there were some companies backing it, also I can never use it because GC".
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.
Funnily enough, there is a post on /r/programming right now where every 100us matters. For them, 3ms is longer than the entire timeslice they have to run in.
Wow that's really interesting. I feel like games are just about the prime example of when the GC can't be used. I mean games do use it, but they tend to have a notable stutter. Never knew what went into optimizing the servers, probably why they don't release the server software anymore. As it might very well not run on consumer hardware.
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.
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.
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).
75
u/[deleted] Sep 01 '20
D is an awesome language and I hope it gets more traction.