3 ms·

> (pseudo) real-time performance critical work, such as robotics control and 3d gaming. In reality all interactive applications are real-time performance criti

> (pseudo) real-time performance critical work, such as robotics control and 3d gaming. In reality all interactive applications are real-time performance critical. Any normal user would say that an unresponsive application is unacceptable. Sadly the entire stack of our contemporary desktop runtime environments grew out of background batch processing systems. This means that an application becoming unresponsive can be a sign of normal system operation. Even if you avoid malloc, any memory access can trigger swapping which can block your main thread indeterminately. Or if you are running a high enough amount of CPU-hungry processes concurrently, your main thread can block indeterminately. Millions of programmers carry on building applications for these systems blissfully unaware of these fundamental flaws. Application runtimes like Electron flourish, riddled with thousands of unbounded operations on every mouse click.

com2kid 5y ago
> Even if you avoid malloc, Way too many people believe the difference between malloc/new+free/delete vs a GC is that one is deterministic and the other isn't. (It doesn't help that textbooks still teach this!) Both are subject to the whims of the system's memory and, if swap is enabled, IO systems. And unless you understand your call graph very well, constructing an object that constructs other objects is not something you are likely to be capable of calculating the performance of in a non-GC language. Same goes for destructors. The actual difference is that in language without GC's typically have explicit syntax for dynamic memory allocation (though it can happen by surprise in C++ from time to time!), which means if you are writing latency sensitive code, you can just avoid dynamic allocation altogether. But there is no reason why GC languages can't do the same! In fact, newer GC languages sometimes do, and nowadays C# give you more control over stack allocation, so careful C# coding can also avoid using dynamic memory.

com2kid 5y ago

> Even if you avoid malloc, Way too many people believe the difference between malloc/new+free/delete vs a GC is that one is deterministic and the other isn't. (It doesn't help that textbooks still teach this!) Both are subject to the whims of the system's memory and, if swap is enabled, IO systems. And unless you understand your call graph very well, constructing an object that constructs other objects is not something you are likely to be capable of calculating the performance of in a non-GC language. Same goes for destructors. The actual difference is that in language without GC's typically have explicit syntax for dynamic memory allocation (though it can happen by surprise in C++ from time to time!), which means if you are writing latency sensitive code, you can just avoid dynamic allocation altogether. But there is no reason why GC languages can't do the same! In fact, newer GC languages sometimes do, and nowadays C# give you more control over stack allocation, so careful C# coding can also avoid using dynamic memory.