I think it is more of using a specialized compiler on unmodified C code and
expecting it to work.
> On Mar 15, 2021, at 3:58 PM, Andy Balholm wrote:
>
>
> By the way, this existed at one point. Early versions of the Go toolchain
> included C compilers (6c, 8c, etc.) designed to work togethe
By the way, this existed at one point. Early versions of the Go
toolchain included C compilers (6c, 8c, etc.) designed to work together
nicely with Go code. If I remember right, most of the Go runtime was
written in C, and compiled with these compilers. But they used an
unusual dialect of C (wh
Totally agree and that was my point. If the desire is to speed up calls to C
there are many options - done explicit (like marking calls non blocking), or
implicit - once a routine makes a “unknown” C native call that routine is
always bound to a dedicated thread - clearly you are trading perform
Hello fellow gophers,
Here is a helpful link that gives an overview of some of what impacts cgo
performance, including the slides have pointers into the code for anyone
interested in going deeper:
https://speakerdeck.com/filosottile/why-cgo-is-slow-at-capitalgo-2018
That was a 2018 presentati
On Mon, Mar 15, 2021 at 12:17 PM Jason E. Aten wrote:
>
> On Monday, March 15, 2021 at 12:58:38 PM UTC-5 Ian Lance Taylor wrote:
>>
>> I think it is too strong to say that the scheduler is the "bottleneck"
>> in calling C code, but I believe that the operations required to tell
>> the scheduler wh
On Monday, March 15, 2021 at 12:58:38 PM UTC-5 Ian Lance Taylor wrote:
> I think it is too strong to say that the scheduler is the "bottleneck"
> in calling C code, but I believe that the operations required to tell
> the scheduler what is happening to the goroutine are the most costly
> parts
On Sun, Mar 14, 2021 at 7:54 PM Robert Engels wrote:
>
> True. I was collapsing the two because why does Go care. If the routine is in
> a C native call don’t switch the routine assigned to the thread. Similarly.
> If the thread is in C native it can’t affect stacks / heap structures - so
> rou
Go "cares" because in Go it's common for a single OS thread to correspond
to 25-100% of runnable goroutines.
So the accounting for "how many OS threads are available to run goroutines"
tends to be fine-grained,
otherwise weird failure-to-schedule bugs can occur. It's likely it could be
improved
Interesting. I have no idea how the GC would interact with "Go-aware" C
code.
I suppose the hardest thing about the new compiler would be to emulate what
Go does at blocking system calls to not actually block the whole process.
(Notice somehow, and start a new thread; not sure if this is still
True. I was collapsing the two because why does Go care. If the routine is in a
C native call don’t switch the routine assigned to the thread. Similarly. If
the thread is in C native it can’t affect stacks / heap structures - so
routines that make C calls only need to ensure a C minimum stack si
On Sun, Mar 14, 2021 at 1:46 PM Robert Engels wrote:
>
> That was my point, based on Java, there is the ability to make the GC
> coordination extremely efficient a read and two writes per Go to C complete
> call trip - and this can often be eliminated in tight loops.
I don't mean to drag out th
That was my point, based on Java, there is the ability to make the GC
coordination extremely efficient a read and two writes per Go to C complete
call trip - and this can often be eliminated in tight loops.
So if the scheduling is the source of inefficiency there are more simple ways
to tackle
On Sun, Mar 14, 2021 at 12:00 PM Robert Engels wrote:
>
> Based on two decades of Java FFI - the overhead comes from type mapping not
> the housekeeping to control GC. The latter can be as simple as a volatile
> read and 2 writes per call and can usually be coalesced in tight loops. Since
> Go
Based on two decades of Java FFI - the overhead comes from type mapping not the
housekeeping to control GC. The latter can be as simple as a volatile read and
2 writes per call and can usually be coalesced in tight loops. Since Go already
has easy native C type mapping the FFi should be very eff
> I'm no authority here, but I believe a large (major?) part of the Cgo
overhead is caused by scheduling overhead. As I understand it, a C function
call is non-preemptible and the Go runtime don't know whether the call will
block.
But that part would be handled by the C-compiler-that-knows-Go
On Sun, 14 Mar 2021 12:56:43 +0100
"Elias Naur" wrote:
> > It incentivises us to rewrite C codebases into proper Go.
> Rewriting (and maintaining!) mature and well-maintained libraries is
> impractical.
> Rewriting platform-bound APIs (OpenGL, Cocoa) is impossible.
> A rewrite is one thing, mai
There's something to be said to the notion of being able to better inter-op
with C code bases, though.
If we had a C compiler written in Go (like modernc.org/cc perhaps), integrated
with the Go compiler (yes, that's an additional maintenance issue), that would
spit off Go-compatible ASM, then we
On Sun Mar 14, 2021 at 13:03, Jan Mercl wrote:
> On Sun, Mar 14, 2021 at 12:57 PM Elias Naur wrote:
>
> > > Eg. if you really need to hook at battle-tested C code that needs no
> > > further maintenance, you may try https://github.com/minio/c2goasm
> > > It lets you bootstrap fast, then you may
On Sun, Mar 14, 2021 at 12:57 PM Elias Naur wrote:
> > Eg. if you really need to hook at battle-tested C code that needs no
> > further maintenance, you may try https://github.com/minio/c2goasm
> > It lets you bootstrap fast, then you may aim at a proper rewrite.
> >
>
> A rewrite is one thing,
On Sun Mar 14, 2021 at 12:30, Wojciech S. Czarnecki wrote:
> On Sat, 13 Mar 2021 22:57:11 -0800 (PST)
> "Jason E. Aten" wrote:
>
> > Iminimize the cost of crossing the CGO barrier from Go code into C code and
> > back.
>
> I personally regard this cost as godsend ;) It incentivises us to rewrite
On Sat, 13 Mar 2021 22:57:11 -0800 (PST)
"Jason E. Aten" wrote:
> Iminimize the cost of crossing the CGO barrier from Go code into C code and
> back.
I personally regard this cost as godsend ;) It incentivises us to rewrite C
codebases into proper Go.
> Instead of teaching the Go compiler how
I was noodling about how to minimize the cost of crossing the CGO barrier
from Go code into C code and back.
Then I thought, what if I look at this the other way around.
Instead of teaching the Go compiler how to better run C code, what if a C
compiler (e.g. clang) was taught to generate code t
22 matches
Mail list logo
