3 ms·

I use C when I have a program with tight timing and/or memory requirements. I see that this is a GC language, so am I right in assuming that it's not suitable f

by tumult 17y ago

I use C when I have a program with tight timing and/or memory requirements. I see that this is a GC language, so am I right in assuming that it's not suitable for soft or hard realtime systems?

agl 17y ago
GC pauses are current unbounded, so I wouldn't use it for that sort of thing, no.
- tumult 17y ago
  Right on, good to know, thanks :)
kaib 17y ago
Most of Google infrastructure is soft realtime so GC delays have definitely been a concern. The memory footprint for a simple hello.go on arm using 5g is currently ~70k with the optimizer not yet enabled. I'm planning to do some work on a AT91SAM7 with 256kb of flash and it should fit OK. You might be able to squeeze it into a smaller space if you drop some of the runtime.
- tumult 17y ago
  Assuming the OS threads/preemptive multitasking are playing nice (i.e. letting me devour timeslices at my leisure), how well do you think the GC would work when I need to land events in a 15 microsecond window at 40hz on a normal desktop PC? I'd be crunching a decent amount of math and discarding/creating objects between events, but total memory utilization would not be going up or down. Sorry if that's kind of specific, it's some of the limitations in one of the current problems I'm working on :)
  - kaib 17y ago
    Given the realtime GC is not done nobody really knows. However, the design goal is to have the GC interrupt time to be linear to the stack of your go-routine (with small constants). Thus you should have at least some control over event latencies through program structure. Like I said earlier, there is significant interest inside Google to make it possible to write really low latency services in Go. I personally think 15 usec is reasonable to ask for.
    - tumult 17y ago
      That's very very cool, thanks for the info
davidw 17y ago
Erlang is used for 'soft real time' applications, and it does GC.

by tumult 17y ago

I use C when I have a program with tight timing and/or memory requirements. I see that this is a GC language, so am I right in assuming that it's not suitable for soft or hard realtime systems?

agl 17y ago

GC pauses are current unbounded, so I wouldn't use it for that sort of thing, no.

tumult 17y ago
Right on, good to know, thanks :)

kaib 17y ago

Most of Google infrastructure is soft realtime so GC delays have definitely been a concern. The memory footprint for a simple hello.go on arm using 5g is currently ~70k with the optimizer not yet enabled. I'm planning to do some work on a AT91SAM7 with 256kb of flash and it should fit OK. You might be able to squeeze it into a smaller space if you drop some of the runtime.

tumult 17y ago
Assuming the OS threads/preemptive multitasking are playing nice (i.e. letting me devour timeslices at my leisure), how well do you think the GC would work when I need to land events in a 15 microsecond window at 40hz on a normal desktop PC? I'd be crunching a decent amount of math and discarding/creating objects between events, but total memory utilization would not be going up or down. Sorry if that's kind of specific, it's some of the limitations in one of the current problems I'm working on :)
- kaib 17y ago
  Given the realtime GC is not done nobody really knows. However, the design goal is to have the GC interrupt time to be linear to the stack of your go-routine (with small constants). Thus you should have at least some control over event latencies through program structure. Like I said earlier, there is significant interest inside Google to make it possible to write really low latency services in Go. I personally think 15 usec is reasonable to ask for.
  - tumult 17y ago
    That's very very cool, thanks for the info

davidw 17y ago

Erlang is used for 'soft real time' applications, and it does GC.