5 ms·

Another weird thing is, the background collection is still using a core (plus somewhat slowing foreground code, with write barriers) when it runs. It's kinda li

Another weird thing is, the background collection is still using a core (plus somewhat slowing foreground code, with write barriers) when it runs. It's kinda like you have a varying amount of CPU power. One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twiddle without looking too glitchy, maybe you can figure out some way to shed work when you start to fall behind. It'd be really cool to see someone attempt a game or such in Go--boundary pushing's always fun, more so when the boundaries are recently expanded.

pjmlp 11y ago
Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development. No sane game developer would use anything other than Assembly. The more things change, the more they stay the same.
- twotwotwo 11y ago
  Wasn't to discourage at all--was trying to give my understanding (based on the design docs, talks, etc.) of what your CPU budget looks like and speculate about ways to deal. "It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.
  - pjmlp 11y ago
    That was my point as well. The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways. Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly. The compilers weren't that good generating code and they didn't want to loose the power of Assembly. Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago. We need to keep the spirit of taking things far alive, because in computing seeing is believing.

pjmlp 11y ago

Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development. No sane game developer would use anything other than Assembly. The more things change, the more they stay the same.

twotwotwo 11y ago
Wasn't to discourage at all--was trying to give my understanding (based on the design docs, talks, etc.) of what your CPU budget looks like and speculate about ways to deal. "It'd be really cool" was absolutely sincere; the Go folks have given us some new toys and it'd be neat to see how far we can take 'em.
- pjmlp 11y ago
  That was my point as well. The culture in the gamedev world is such that the big teams only switch tooling when forced to do so. Only amateurs tend to try out new ways. Back when the move from Assembly to higher level languages started, many games would be filled with inline Assembly. The compilers weren't that good generating code and they didn't want to loose the power of Assembly. Just like now with the managed runtimes and having tons of C and C++ underneath. Languages that weren't that speedy 30 years ago. We need to keep the spirit of taking things far alive, because in computing seeing is believing.