On Fri, Jan 21, 2022 at 2:06 AM Sean <s.tolstoyev...@gmail.com> wrote: > > I'm currently using Cgo heavily for a game. But microseconds don't > matter to me. The calls must not exceed milliseconds, and it all depends > on the C api I wrote. > I'm currently in testing and development, there doesn't seem to be a > problem now but I don't know what to do if Cgo in production will be a > problem for me. > Dropt this wonderful std and switching to C++ will be a nightmare for me. > > I'm trying some untested things in the Golang world. > > Hopefully, CFFI performance will eventually get on the Golang team's > radar and improve.
It's on our radar but it's a hard problem. Ian > On 20/01/2022 23:25, Ian Lance Taylor wrote: > > On Thu, Jan 20, 2022 at 2:54 AM Sean <s.tolstoyev...@gmail.com> wrote: > >> I know CGO is not performing well in Golang at the moment. > > That is true, but we should quantify it. The last time I tested it, a > > cgo call took about 10 times as long as an ordinary function call. So > > that is pretty bad if you are calling a tiny function, but it doesn't > > really matter if you are calling a function that does I/O. > > > >> If we use a dll will this performance issue decrease? > > I don't know but I don't think so. > > > >> If I do the cgo calls with syscall, will there be no performance > >> improvements? > > I haven't measured but I don't see why using the syscall package would > > be any faster. > > > >> When I think about it, Golang always has to make syscall calls on the os > >> it's running on. For example, in Windows, the net package has to talk to > >> the socket api of Windows. > >> My assumptions are that syscall should be better than Cgo. > >> If syscall calls are no different from Cgo, how does Golang build this > >> performance in the core library? > > The Go runtime has two advantages. First, it can make the call > > directly in the system ABI rather than having to translate from the Go > > ABI to the system ABI. Second, it can know that certain system calls > > can never block, and can use that to optimize the way that they are > > handled. > > > > Also, of course, system calls by their nature tend to be a bit slow, > > so the overhead is less important. As mentioned above, the overhead > > of a cgo call is most important when calling a small C function. Most > > system calls are not small. > > > > Ian > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7c15358f-f906-a693-6df4-de434915fa17%40gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXmyzuzC%3DPfVra-a5m8juu0CR4zktGJ4yvSmhcw3RxU5A%40mail.gmail.com.
