4 ms·
Isn't calling into "C" (or Rust, in this case) expensive in Go because it seeds to switch stacks?
by Thiez 10y ago
Isn't calling into "C" (or Rust, in this case) expensive in Go because it seeds to switch stacks?
- lobster_johnson 10y agoExpensive in Go, but not in Rust.
- Thiez 10y agoI am aware, but the parent of my post suggested writing the "engine core" in Rust, and the other 99% in Go. Does using something that isn't Go for 1% of an application to do the "heavy lifting" and be "fast" really make sense when there is a significant cost that must be paid whenever moving between that core and the rest of the application? I imagine such a situation would need a lot of benchmarking to make sure that the end result is actually faster than writing the entire program in Go.
- deleted 10y ago[deleted]
- lobster_johnson 10y agoSorry, I thought you were asking. I agree, I don't think it makes sense.
- derefr 10y agoImagine something like NumPy. Go code to play with numbers; Rust code to actually do matrix multiplications et al. Since the "hot loop" of such code would be in the Rust part, not in the Go part, you don't see much overhead. Or, consider Firefox. Firefox's rendering engine will soon be Servo (Rust). I presume that its networking and its Javascript engine will eventually go the same way. Eventually, the only stuff left written in C in the Firefox codebase will be "glue code": business-policy logic that doesn't do heavy lifting, and doesn't need speed. In other words, the exact type of code where Go's "you'll be safer without this" assertion applies. Firefox as Go + Rust: why not?
- deleted 10y ago[deleted]
- voidlogic 10y agoIn Go 1.8; due this month, cgo calls got half as expensive. They all ready are OK as long as you are smart about them.
- strken 10y ago"Expensive" in this case is measured in tens/hundreds of nanoseconds, so it might be okay as long as your Rust code is long-running.