5 ms·
When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Men
by na85 6y ago
When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future.
By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just to avoid garbage collection.
Plus, now that Mozilla has gutted the Rust team, one wonders what future Rust has, if any.
- tormeh 6y agoGC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.
- na85 6y ago>GC is a no-go, as it causes unacceptable frame-rate dips. Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.
- pirocks 6y agoI play a lot of minecraft and GC related framerate issues are usually not a problem, but when they are a problem they can be quite annoying. You tune gc performance for your gameplay workload to a certain extent but obviously most players don't.
- Scramblejams 6y agoThose games will have been written in such a way as to avoid allocations like the plague, giving the GC very little to do. Sometimes your game can be written that way -- sometimes it can't.
- pjmlp 6y agoJust like you have to avoid malloc() in C written games.
- jstimpfle 6y agoFirst, you don't have to avoid malloc() or similar allocators in games necessarily. You should avoid it in performance constrained situations. And you only should avoid calling malloc. It's not necessarily a problem to use these allocations in those situations. That's quite unlike Java, unless you're a GC wizard, and I'm not sure how far even those wizards can circumvent problems. Second, to my knowledge it's still very cumbersome to avoid GC allocations in Java. By comparison, it's easy to reduce calls to global heap allocators in C.
- pjmlp 6y agoFirst, also possible in GC enabled languages. That is what profilers are for. Second, it is relatively easy to do native memory allocation in Java, but apparently people keep forgetting to learn their toolbox properly. Third, calling malloc() is such an issue that there used to be companies specialised in selling optimised versions of malloc()/free().
- jstimpfle 6y agoOh, come on.
- todd8 6y agoAdvanced garbage collectors have short pause times. In [1], the author cites Twitter statistics showing approximately two 0.5ms "pause" times per GC cycle for the go language garbage collector, and during the GC cycle only 25% of the CPU was used by the GC. It doesn't seem like this is going to cause frame-rates to dip. To be fair, every application is going to differ, and perhaps games need tighter control of memory than a high performance GC is capable of, but automatic GC does make programming a lot easier. [1] https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
- iphorde 6y agoThere is nothing wrong with Java except the issues surrounding protecting your code from reverse engineering.
- pjmlp 6y agoThat applies to any language. Hex-Rays and similar are also a thing for native compiled code.
- iphorde 6y agoYes/no, what hex-rays ida gives you is not worth the effort. It is a guess, and it doesn't do well with complex algorithms. Go try it on libjpeg. Compile it to release, no symbols, and let me know what you can extract. That is what I tested it with, and I didn't get much.