Assembly incurs a function call cost (non-inlineable AFAIU), but Cgo
incurs a function call cost with additional work for C stack and call
conventions translation as said by Tamás.




On Fri, 2019-03-01 at 08:13 -0800, Jason E. Aten wrote:
> If I include a chunk of assembly .s code in my Go code, does my
> program pay 
> the CGO transition cost of locking and changing to a C stack?
> 
> I'm pretty sure the answer is no. But my knowledge of the Go
> internals is 
> low enough that I thought I would like confirm that before I go
> pulling in 
> .s code.
> 
> Then for numerical work, if I need to call some Fortran 90 compiled
> library 
> routines, does it not just look like assembly? I suppose not... in
> the 
> sense that it makes certain assumptions about being able to grow the
> stack 
> it is running on without running out of space. Are there assumptions
> beyond 
> the stack that are used? Probably some "standard library" runtime 
> dependencies? 
> 
> So on to my central question: Can the CGO transition stack switching
> cost 
> be minimized by telling Go to run my main (single threaded) Go
> routine on a 
> C thread to start with?  In other words, can I minimize the CGO
> switching 
> cost by doing runtime.LockOSThread() or similar?
> 
> It seems like if we are already on a C thread, then perhaps *some
> large 
> part* of the cost of Go -> f90 can be avoided. Of course the Go
> compiler 
> doesn't know we are on a C thread in the general case, right(?), so
> it 
> probably can't optimize those transitions by omitting change-the-
> stack code.
> 
> Returning to the original throught about .s code, what would happen
> if that 
> code tried to grow the stack too far?  Just crash? Is there guidance
> about 
> how far assembly can grow the stack before it needs to check back
> with the 
> runtime?
> 
> Thanks!
> 
> J
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to