4 ms·
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 curren
by 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 agoAssuming 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 agoGiven 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 agoThat's very very cool, thanks for the info