On Mon, Nov 16, 2020 at 4:04 PM tapi...@gmail.com <tapir....@gmail.com> wrote:
> > I feel there still room between the two to explore, though I have not a > clear thought on this yet. > Many of the tricks tend to coincide with both allocator strategies as you work more on them. The methods are much more two sides of the same coin than they are different. It is easy to have manually managed memory areas: just force a data copy in and out of said area whenever you access them. Then the pointer spaces can be kept separated from each other and you don't have to run GC for the data space. This is what Erlang's ETS system is all about (If you want a pointer, lookup Linda tuple spaces for an explanation). If you allow pointers to point between spaces, then you have to handle that in some way. One way is to keep forward sets of the pointers so you can handle them, but this is usually easier if you have generational GCs as they have to do this anyway for most languages (again, Erlang is the exception to the rule here). I'm more inclined to believe that careful handling of memory in Go is more than adequate for handling a low latency scenario such as a game. If your target is 60fps, the 16.7ms window per frame should be rather easy to reach with the current GC, especially if you have some extra CPU resources to spare. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVfZD-F9-5jyN5bdHPh64UZfBDUX4ooJuRjjaeS0zCj6A%40mail.gmail.com.
