4 ms·

It got the wrong language for my example, a digital audio workstation with peer to peer collaboration. It said use Go, but Go is garbage collected and that is

It got the wrong language for my example, a digital audio workstation with peer to peer collaboration. It said use Go, but Go is garbage collected and that is unacceptable for an app that needs to process real time audio with low latency. Same thing applies to any networked video game.

d0lph 11y ago
I believe you can turn off the garbage collector in go.
- AndyKelley 11y ago
  Uh. Citation needed.
  - bitdivision 11y ago
    You can set the environment variable GOGC=off [1] There doesn't actually seem to be a way to explicitly free memory though so I doubt this is actually used. [1]: https://golang.org/pkg/runtime/ https://golang.org/pkg/runtime/
    - Zancarius 11y ago
      It's only intended for debugging purposes, near as I can tell (and I'm not sure why anyone would want to do it in the first place beyond debugging): https://github.com/golang/go/issues/13761#issuecomment-167721220 https://github.com/golang/go/issues/13761#issuecomment-16772...
  - deleted 11y ago
    [deleted]
  - d0lph 11y ago
    I stand corrected, there doesn't seem to be a way to manually allocate and de-allocate memory. Looks like there is a switch to turn off GC, but it's intended for debugging.
- bitdivision 11y ago
  You might be right, but the language certainly isn't designed around not having garbage collection.
  - hnbroseph 11y ago
    i'm not particularly experienced with go, but it does work directly with pointers iirc. all it lacks is an explicit memory free function, i think. is there more to it?
copperx 11y ago
There's only one right answer for such systems, and you know it: C/C++. They should have added "High performance desktop app" as an option.
- hnbroseph 11y ago
  "high performance" is a bit vague. maybe "particularly latency-sensitive" or "requires quasi-deterministic execution time"
tracker1 11y ago
It kind of depends, Go's GC cycle in recent releases is minimized so that no GC cycle will last more than N milliseconds (I forget the specific amount), depending on your specific timing needs, it may be acceptable... You can also write your program so that objects/references are held and GC doesn't happen, depending on your memory constraints and needs (ram is cheap, and systems with 64-256GB are possible relatively inexpensive, compared to developer pay for a month) Though Rust is probably more appropriate for your needs, in terms of more modern languages.
- AndyKelley 11y ago
  It's like 30ms which is completely unacceptable. As for your workarounds, for real time software, these workarounds are too nondeterministic. Real time is one of the primary features, so you need very predictable performance, and that implies having direct control over things like memory.
  - tracker1 11y ago
    Like I said, it really depends on your needs... In a game, even, it would depends... a blink of an eye hickup every few minutes in a game is not a huge thing, depending on the game... many games would never even need a large GC cycle on a modern computer. I mean, look at how many fun games were made in Flash... Yes, if you're doing really real-time, that's one thing... many things aren't, so it depends... that said, again, if you need really real time, a functional approach and rust may be a better option... or a number of other FP languages, for that matter... or C/C++ if you're a masochist, or really anal with your approach (not really trying to offend C/C++ guys, more pointing out that it's rarely the best pragmatic option)
  - mixedCase 11y ago
    >It's like 30ms which is completely unacceptable. Not really. https://twitter.com/brianhatfield/status/692778741567721473 https://twitter.com/brianhatfield/status/692778741567721473 I've seen 10ms mentioned as worst possible scenario, which means not coding with the GC in mind.
derefr 11y ago
This is a hard real-time problem. There's a well-known general solution for hard real-time problems: split the problem into a data plane and a control plane, and then program those separately and network the components together (e.g. as two processes communicating over a unix domain socket.) You can write your GUI in Visual Basic or Node or whatever-the-hell, as long as you've got your audio engine written in something with deterministic latency. If you specify a protocol ahead of time, those can even be separate teams with separate competencies! Sadly, none of the real-time audio/video/image processing software companies seem to have caught onto this. I guess it's only really "well-known" in the network programming world. (A few game companies seem to have figured it out as well, but not nearly the majority.)

d0lph 11y ago

I believe you can turn off the garbage collector in go.

AndyKelley 11y ago
Uh. Citation needed.
- bitdivision 11y ago
  You can set the environment variable GOGC=off [1] There doesn't actually seem to be a way to explicitly free memory though so I doubt this is actually used. [1]: https://golang.org/pkg/runtime/ https://golang.org/pkg/runtime/
  - Zancarius 11y ago
    It's only intended for debugging purposes, near as I can tell (and I'm not sure why anyone would want to do it in the first place beyond debugging): https://github.com/golang/go/issues/13761#issuecomment-167721220 https://github.com/golang/go/issues/13761#issuecomment-16772...
- deleted 11y ago
  [deleted]
- d0lph 11y ago
  I stand corrected, there doesn't seem to be a way to manually allocate and de-allocate memory. Looks like there is a switch to turn off GC, but it's intended for debugging.
bitdivision 11y ago
You might be right, but the language certainly isn't designed around not having garbage collection.
- hnbroseph 11y ago
  i'm not particularly experienced with go, but it does work directly with pointers iirc. all it lacks is an explicit memory free function, i think. is there more to it?

copperx 11y ago

There's only one right answer for such systems, and you know it: C/C++. They should have added "High performance desktop app" as an option.

hnbroseph 11y ago
"high performance" is a bit vague. maybe "particularly latency-sensitive" or "requires quasi-deterministic execution time"

tracker1 11y ago

It kind of depends, Go's GC cycle in recent releases is minimized so that no GC cycle will last more than N milliseconds (I forget the specific amount), depending on your specific timing needs, it may be acceptable... You can also write your program so that objects/references are held and GC doesn't happen, depending on your memory constraints and needs (ram is cheap, and systems with 64-256GB are possible relatively inexpensive, compared to developer pay for a month) Though Rust is probably more appropriate for your needs, in terms of more modern languages.

AndyKelley 11y ago
It's like 30ms which is completely unacceptable. As for your workarounds, for real time software, these workarounds are too nondeterministic. Real time is one of the primary features, so you need very predictable performance, and that implies having direct control over things like memory.
- tracker1 11y ago
  Like I said, it really depends on your needs... In a game, even, it would depends... a blink of an eye hickup every few minutes in a game is not a huge thing, depending on the game... many games would never even need a large GC cycle on a modern computer. I mean, look at how many fun games were made in Flash... Yes, if you're doing really real-time, that's one thing... many things aren't, so it depends... that said, again, if you need really real time, a functional approach and rust may be a better option... or a number of other FP languages, for that matter... or C/C++ if you're a masochist, or really anal with your approach (not really trying to offend C/C++ guys, more pointing out that it's rarely the best pragmatic option)
- mixedCase 11y ago
  >It's like 30ms which is completely unacceptable. Not really. https://twitter.com/brianhatfield/status/692778741567721473 https://twitter.com/brianhatfield/status/692778741567721473 I've seen 10ms mentioned as worst possible scenario, which means not coding with the GC in mind.

derefr 11y ago

This is a hard real-time problem. There's a well-known general solution for hard real-time problems: split the problem into a data plane and a control plane, and then program those separately and network the components together (e.g. as two processes communicating over a unix domain socket.) You can write your GUI in Visual Basic or Node or whatever-the-hell, as long as you've got your audio engine written in something with deterministic latency. If you specify a protocol ahead of time, those can even be separate teams with separate competencies! Sadly, none of the real-time audio/video/image processing software companies seem to have caught onto this. I guess it's only really "well-known" in the network programming world. (A few game companies seem to have figured it out as well, but not nearly the majority.)