I haven't done game dev beyond hobbyist level, but 12.5% of your total budget for a frame seems pretty significant. Is that kind of percentage hit generally considered negligible?
Re:Writing Network Drivers in Rust [pdf]
by Kaveren on Thursday November 08, 2018 @02:59PM
(#18409421)
60 FPS is not enough, many people have monitors with much higher refresh rates (120 hz, more). You have virtual reality which basically requires a higher refresh rate than 60 FPS to begin with. Using a runtime component for garbage collection is highly sub-optimal.
Rust is possibly an ideal language for game development. Standard Rust has no runtime component, which is perfect. It's also a high-performance language.
The ecosystem for Rust game development is immature, but there's progress being made.
Re:Writing Network Drivers in Rust [pdf]
by majewsky on Thursday November 08, 2018 @06:57PM
(#18411170)
Standard Rust absolutely has runtime components. Otherwise a "Hello World" would not compile into several 100 KiB of binary. (Not saying that that's bad, just that this is how it is.)
Re:Writing Network Drivers in Rust [pdf]
by bluejekyll on Thursday November 08, 2018 @07:12PM
(#18411283)
I haven't looked since, but jemalloc I believe was a significant cost in this. Recently there was a change merged in to use the system allocator by default:
https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_j...
Re:Writing Network Drivers in Rust [pdf]
by red75prime on Thursday November 08, 2018 @10:49PM
(#18412199)
It has runtime as in "C runtime", that is the code which runs before and after `main` and the code of standard library. It doesn't have runtime as in "Java runtime" (or "C# runtime") that includes the code that runs alongside your code (garbage collection thread).
Re:Writing Network Drivers in Rust [pdf]
by Kaveren on Friday November 09, 2018 @01:07AM
(#18412645)
Yes, I was loose in my use of the term "runtime" and sacrificing correctness. Writing "runtime component" rather than "runtime" makes it more misleading. I probably should've worded my original comment more wisely.
Some embedded realtime cases might have more strict deadline requirements, or be complicated by the potential jitter that a GC might intoduce. Eg most discrete math used in motor control systems assumes a fixed sample period.