3 ms·

GC 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 u

by tormeh 6y ago

GC 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 ago
  I 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 ago
  Those 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 ago
    Just like you have to avoid malloc() in C written games.
    - jstimpfle 6y ago
      First, 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 ago
        First, 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 ago
        Oh, come on.
todd8 6y ago
Advanced 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

by tormeh 6y ago

GC 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 ago
I 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 ago
Those 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 ago
  Just like you have to avoid malloc() in C written games.
  - jstimpfle 6y ago
    First, 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 ago
      First, 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 ago
        Oh, come on.

todd8 6y ago

Advanced 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