Re: [go-nuts] Type Parameters Proposal: constraint.Number should be replaced with constraints.Integer in the examples

[Ian Lance Taylor]

On Fri, Jan 21, 2022 at 7:30 AM Manlio Perillo  wrote:
>
> There is a typo in the List[T].Range method, in  
> golang.org/design/43651-type-parameters#list-transform.
> The return type is *Iterator[T] but Iterator[T] is returned, instead.

Thanks again, fixed.

> Another issue is the implementation of AbsoluteDifference, in 
> golang.org/design/43651-type-parameters#absolute-difference.
> The code is invalid due to #45639, but I suspect that the suggestion to use a 
> struct
>
>   type ComplexAbs[T OrderedNumeric] struct {  X T  }
>
> will not solve the problem.
> Moreover the code suggested in the issue:
>
> func (a ComplexAbs[T]) Abs() ComplexAbs[T] {d := 
> math.Hypot(float64(real(a.X)), float64(imag(a.X))) return 
> ComplexAbs[T](complex(d, 0)) }
>
> does not compile.

Thanks, I'm going to leave this as is for now.  45639 is still open.

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/CAOyqgcU%3DQciAXgySUbGAAFE1Uv2qs7RySPgdAN%2B8A8YbzUPpug%40mail.gmail.com.

[go-nuts] Re: Writing SIMD ASM

[Greg Lowe]

> If you want to use some of the instructions as soon as possible

I can wait, and workaround with hardcoded words in the meantime.

> I'm working on these issues.

Glad to know that this is tracking along. 

I'm looking forward to trying out SVE on Graviton 3.

On Friday, January 21, 2022 at 3:57:45 PM UTC+13 eric...@arm.com wrote:

> > I see there's an existing issue to add a bunch of Neon floating point 
> instructions:
> > https://github.com/golang/go/issues/41092
> >
> > I actually spent a while having a go at adding the instructions myself, 
> but couldn't figure it out.
> >
> > I also see that there is also a proposal and a MR to refactor the Arm64 
> assembler.
> > https://github.com/golang/go/issues/44734
> >
> > Is there any ongoing work there, or has that effort stalled?
>
> I'm working on these issues. The plan is refactoring the assembler first, 
> the newly designed assembler should make it easier to add instructions. As 
> you said, there are a large number of arm64 instructions (NEON, SVE) that 
> are not supported and we want to spend as little effort as possible on this.
>
> But this will take some time, although the code is already under review. 
> If you want to use some of the instructions as soon as possible, please 
> submit an issue, or use word to workaround it first.  Thanks~
> 在2022年1月21日星期五 UTC+8 10:15:26 写道：
>
>> Hi team,
>>
>> I'm a recent Gopher, and have had great success over the past year 
>> developing an insurance modelling application. The tooling is great, thanks 
>> to the team for creating it.
>>
>> 1) SIMD Workflow
>>
>> I've got hot functions in my application which are doing element wise 
>> operations on float slices. Some are just element-wise addition, and 
>> multiplication, some are slightly more complicated.
>>
>> I'm currently deploying on AWS Lambda X86 which as AX2 support (Xeon 
>> Haswell+), but I'm also experimenting with Arm64 (Graviton 2), and would 
>> also like to do some benchmarking on Graviton 3 (only available on EC2 ATM).
>>
>> I've been experimenting with implementing the hot functions in Go's ASM 
>> dialect, and using some simple code generation, to handle all the 
>> repetition. Nothing fancy, not much more than string templating. The 
>> results have been pretty good, but the workflow is pretty slow.
>>
>> As a side project I've been toying with the idea of writing a slightly 
>> more advanced tool, that could read a "SIMD kernel" written as a simple Go 
>> function with a specific form, and generate ASM implementations for it. No 
>> fancy optimisations, just loop unrolling and vector instructions.
>>
>> For example:
>>
>> import . asmgen
>>
>> // Implementation in a generated .s file
>> func Foo(dst []float32, a float32, x, y []float32)
>>
>> // AST used as input to ASM codegen
>> func kernelFoo(i int, dst []float32, a float32, x, y []float32) {
>> dst[i] = min(a * x[i], y[i])
>> }
>>
>> In reality, I probably don't have the time to do that, but it does feel 
>> like something minimal that would actually cover most of my immediate use 
>> cases is not a huge amount of work.
>>
>> I guess this is basically just a limited form of c2goasm . See: 
>> https://github.com/minio/c2goasm
>>
>> So maybe I should just use that, however including big blobs of hex 
>> encoded ASM doesn't seem great either. See: 
>> https://github.com/apache/arrow/blob/master/go/parquet/internal/utils/min_max_neon_arm64.s
>>
>> So apologies that this question is a bit vague and rambly. But the 
>> workflow for SIMD here is pretty slow, and it feels like there could be a 
>> better way to solve this. So I'm basically just reaching out to see if 
>> anyone else has been working on this, or thinking about it, or has ideas 
>> about better solutions.
>>
>>
>> 2) Arm64 ASM Neon Instructions:
>>
>> One problem that's come up, is there's a bunch of ARM instructions which 
>> aren't defined in Go's assembler. So it looks like I'm going to have to 
>> write some code to generate the hex for these. I can probably copy the 
>> approach used here: 
>> https://github.com/minio/asm2plan9s/blob/master/asm2plan9s_arm64.go
>>
>> For example - I'm currently writing:
>>
>> WORD $0x4E24D400 // fadd v0.4s, v0.4s, v4.4s
>>
>> But would like write:
>>
>> VFADD V0.S4, V0.S4, V4.S4
>>
>> I see there's an existing issue to add a bunch of Neon floating point 
>> instructions:
>> https://github.com/golang/go/issues/41092
>>
>> I actually spent a while having a go at adding the instructions myself, 
>> but couldn't figure it out.
>>
>> I also see that there is also a proposal and a MR to refactor the Arm64 
>> assembler.
>> https://github.com/golang/go/issues/44734
>>
>> Is there any ongoing work there, or has that effort stalled?
>>
>> Anyways, thanks for reading my big wall of text.
>>
>> Cheers,
>> Greg.
>>
>

-- 
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 g

[go-nuts] Re: Intentionally omitting requires in go.mod - alternative to multi-module repository?

['Bryan C. Mills' via golang-nuts]

On Thursday, January 13, 2022 at 12:45:13 PM UTC-5 rhcar...@gmail.com wrote:

> Hello fellow Gophers!
>
> I help maintain an SDK module 
>  that includes 
> packages that provide middleware to different web frameworks (e.g. echo 
> ).
>
> The SDK started out as a single module in a Git repository, and we have 
> considered 
> and hesitated splitting it into multiple modules 
>  in a single 
> repository because of the implications that it has on maintenance, 
> development, testing and release processes.
>
> The root package implements the core functionality of the SDK and has no 
> external dependencies, it only needs the standard library. That's what most 
> people need. The other packages each depend on a web framework module, and 
> downstream users typically only need to use one of those packages and do 
> not want to bother about the others.
>
> The current `/go.mod` file is littered with dependencies to many web 
> frameworks 
> 
>  
> and their dependencies, and that has caused problems and confusion to our 
> downstream users , 
> especially when one of those dependencies end up flagged by tools like 
> Dependabot as containing a CVE. (Code security scanners seem to typically 
> operate on the Go module level and not at the package level, so they often 
> report problems even though the affected module/package is not part of the 
> final build list of the main package.)
>

As you noted, this is one of the use-cases we had in mind for module graph 
pruning in Go 1.17.
So one option is to run 'go mod tidy -go=1.17' to upgrade your module to 
support pruning, so that the consumers of your module won't themselves need 
to download irrelevant dependencies. That shouldn't harm any of your users 
on older Go versions (we designed it to be backward-compatible), although 
they won't see the benefits of pruning until they upgrade.

Independently, if your users have automated tools that are issuing 
false-positive CVE warnings based on the module graph instead of the 
package-import graph, you may want to suggest that they file issues against 
those tools. Ideally automated tools ought to be using the package-import 
graph instead of the module graph; however, if that's too involved they 
could still get a better approximation by consulting the `go.sum` file for 
the main module. (Modules that contribute packages relevant to the build 
will have source-code checksums in the `go.sum` file; modules that are in 
the module graph but not otherwise relevant will have only `/go.mod` 
checksums.)


I've been trying to find a way to eliminate the problems of the current 
> single-module-per-repo setup while avoiding the implications of going 
> multi-module-per-repo, as we have limited resources to maintain the SDK.
>
> The recent idea I had was to simply omit `require` entries in the 
> `/go.mod` file 
> , 
> essentially making the module "untidy" (as in `go mod tidy` would 
> re-introduce the missing requires), but I haven't found any mention to 
> that approach on the Internet.
>

We have tests of cmd/go behavior in that kind of configuration, but we 
don't recommend it. Leaving your module untidy makes builds of your 
packages less reproducible for users, and in some cases can also cause 
extra work for the `go` command to resolve the latest versions of those 
dependencies. If you leave dependencies out of your own `go.mod` file, then 
those dependencies will be resolved and added to your users' `go.mod` files 
when they run `go mod tidy` — but they are resolved to the latest release 
of each missing dependency, which means a bit more latency to identify what 
the latest release is, and an increased risk of breakage from incompatible 
changes in those dependencies.

We designed module graph pruning specifically to address use-cases like 
yours, so I would suggest leaning on that feature — and please do file 
issues (or feel free to shoot me an email!) if you run into bugs or rough 
edges.


That idea seems hacky and possibly not conforming to the spec, but perhaps 
> not totally invalid.
> As I read https://go.dev/ref/mod#go-mod-file and 
> https://go.dev/ref/mod#go-mod-file-updates, I understand that the 
> important `go.mod` file is the one of the main module (i.e. the `go.mod` 
> file of our downstream users), and as long as the main module requires the 
> same web framework as expected by the SDK middleware (when used), the Go 
> tool should be able to determine versions and complete the build.
>
>
> I'd like to hear thoughts from others -- has anyone tried something 
> similar?
> Should I expect obvious problems for downstream co

Re: [go-nuts] Re: golang-announce is blocked in Google Groups?

[Roland Müller]

Same applies for me. Most of mail for this group would be moved to 'Spam'.
Only a custom rule prevents that to take place.

Am Fr., 21. Jan. 2022 um 20:31 Uhr schrieb Bruno Albuquerque :

> FWIIW, the same happens here. When creating a filter (assuming one is
> using GMail) you can tell it to never send emails that match the filter to
> Spam and that6 is what I ended up doing.
>
>
> On Fri, Jan 21, 2022 at 8:43 AM Peter Aronoff 
> wrote:
>
>> On Thu, Jan 20, 2022 at 2:35 PM Ian Lance Taylor  wrote:
>>
>>> On Thu, Jan 20, 2022 at 4:51 AM peterGo  wrote:
>>> >
>>> > Jochen,
>>> >
>>> > I get that message too.
>>> >
>>> > https://groups.google.com/g/golang-announce
>>> >
>>> > Google is also trying to lock me out of my gmail accounts, but they do
>>> that all the time.
>>> >
>>> > I don't think Google puts their best people on security.
>>>
>>> Hmmm, it is working for me at the moment.  Are other people still
>>> seeing the warning?
>>
>>
>>> It's unfortunately the case that announce groups tend to pick up these
>>> spam warnings, as people forget they signed up for the group and then
>>> mark messages as spam.
>>>
>>
>>
>> I'm not sure whether this is the same issue, but most email from
>> golang-nuts ends up in my spam folder. I keep marking them all as not spam,
>> but so far, without any effect. Roughly 80% of the mail for this group ends
>> up in the spam folder. Additional info: I recently created this Gmail
>> account (for all things go-related), and I have a rule to funnel all email
>> from golang-nuts into its own folder. Despite the rule, most email from the
>> group goes straight to spam.
>>
>> Peter
>>
>> --
>> 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/CAHnuShzJk-7rQp4V0391j_Sr5asQJ%2BG%3Dzr7NGtGo%3DLU6UXSsrA%40mail.gmail.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/CAEd86TxJyyuqRHmeng-_A5CpeLuJRxPpO4EVH%3D_ryC%2BvnDc%3DuQ%40mail.gmail.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/CA%2B8p0G3wKWVkJ%3DzOVjRAZKM1V5yFKBpgESSu7LVjvPSAy5q1HQ%40mail.gmail.com.

Re: [go-nuts] Performance of syscall calls vs. CGO

[Ian Lance Taylor]

On Fri, Jan 21, 2022 at 2:06 AM Sean  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  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.

Re: [go-nuts] Re: golang-announce is blocked in Google Groups?

[Bruno Albuquerque]

FWIIW, the same happens here. When creating a filter (assuming one is using
GMail) you can tell it to never send emails that match the filter to Spam
and that6 is what I ended up doing.


On Fri, Jan 21, 2022 at 8:43 AM Peter Aronoff 
wrote:

> On Thu, Jan 20, 2022 at 2:35 PM Ian Lance Taylor  wrote:
>
>> On Thu, Jan 20, 2022 at 4:51 AM peterGo  wrote:
>> >
>> > Jochen,
>> >
>> > I get that message too.
>> >
>> > https://groups.google.com/g/golang-announce
>> >
>> > Google is also trying to lock me out of my gmail accounts, but they do
>> that all the time.
>> >
>> > I don't think Google puts their best people on security.
>>
>> Hmmm, it is working for me at the moment.  Are other people still
>> seeing the warning?
>
>
>> It's unfortunately the case that announce groups tend to pick up these
>> spam warnings, as people forget they signed up for the group and then
>> mark messages as spam.
>>
>
>
> I'm not sure whether this is the same issue, but most email from
> golang-nuts ends up in my spam folder. I keep marking them all as not spam,
> but so far, without any effect. Roughly 80% of the mail for this group ends
> up in the spam folder. Additional info: I recently created this Gmail
> account (for all things go-related), and I have a rule to funnel all email
> from golang-nuts into its own folder. Despite the rule, most email from the
> group goes straight to spam.
>
> Peter
>
> --
> 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/CAHnuShzJk-7rQp4V0391j_Sr5asQJ%2BG%3Dzr7NGtGo%3DLU6UXSsrA%40mail.gmail.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/CAEd86TxJyyuqRHmeng-_A5CpeLuJRxPpO4EVH%3D_ryC%2BvnDc%3DuQ%40mail.gmail.com.

Re: [go-nuts] Re: golang-announce is blocked in Google Groups?

[Peter Aronoff]

On Thu, Jan 20, 2022 at 2:35 PM Ian Lance Taylor  wrote:

> On Thu, Jan 20, 2022 at 4:51 AM peterGo  wrote:
> >
> > Jochen,
> >
> > I get that message too.
> >
> > https://groups.google.com/g/golang-announce
> >
> > Google is also trying to lock me out of my gmail accounts, but they do
> that all the time.
> >
> > I don't think Google puts their best people on security.
>
> Hmmm, it is working for me at the moment.  Are other people still
> seeing the warning?


> It's unfortunately the case that announce groups tend to pick up these
> spam warnings, as people forget they signed up for the group and then
> mark messages as spam.
>


I'm not sure whether this is the same issue, but most email from
golang-nuts ends up in my spam folder. I keep marking them all as not spam,
but so far, without any effect. Roughly 80% of the mail for this group ends
up in the spam folder. Additional info: I recently created this Gmail
account (for all things go-related), and I have a rule to funnel all email
from golang-nuts into its own folder. Despite the rule, most email from the
group goes straight to spam.

Peter

-- 
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/CAHnuShzJk-7rQp4V0391j_Sr5asQJ%2BG%3Dzr7NGtGo%3DLU6UXSsrA%40mail.gmail.com.

Re: [go-nuts] Type Parameters Proposal: constraint.Number should be replaced with constraints.Integer in the examples

[Manlio Perillo]

There is a typo in the List[T].Range method, in  
golang.org/design/43651-type-parameters 

#list-transform.
The return type is *Iterator[T] but Iterator[T] is returned, instead.

Another issue is the implementation of AbsoluteDifference, in 
golang.org/design/43651-type-parameters 

#absolute-difference.
The code is invalid due to #45639, but I suspect that the suggestion to use 
a struct

  type ComplexAbs[T OrderedNumeric] struct {  X T  }

will not solve the problem.
Moreover the code suggested in the issue:

func (a ComplexAbs[T]) Abs() ComplexAbs[T] {d := 
math.Hypot(float64(real(a.X)), float64(imag(a.X))) return 
ComplexAbs[T](complex(d, 0)) }

does not compile.


Thanks
Manlio
On Thursday, January 20, 2022 at 8:46:19 PM UTC+1 Ian Lance Taylor wrote:

> On Thu, Jan 20, 2022 at 2:28 AM Manlio Perillo  
> wrote:
> >
> > 1. In 
> golang.org/design/43651-type-parameters#constraints-apply-even-after-constraint-type-inference
> ,
> > there is a typo in the F4 function where FromString2 should be 
> FromStrings2
>
> Thanks, fixed.
>
> > 2. In 
> golang.org/design/43651-type-parameters#operations-based-on-type-sets,
> > the link "defined later" in
> > "For special purpose operators like range loops, we permit their use
> > if the type parameter has a structural constraint, as "
> > points to 
> golang.org/design/43651-type-parameters#Constraint-type-inference.
> > This feels confusing to me. What does type inference have to do with 
> structural constraints?
> >
> > I think that the definition of "structural type" and "structural 
> constraint" should be moved in a
> > different section.
> > Note that the term "structural constraint" is also used at the start of 
> the document, in
> > golang.org/design/43651-type-parameters#background, but I'm not sure if 
> it has the
> > meaning as the term used in the type inference section.
>
> This is historical. We introduced structural constraints for
> constraint type inference, and then we started using them for some
> operations. I'm honestly not sure if we are going to keep doing that
> going forward in future language versions.
>
> I'm going to leave restructuring the documentation for later.
>
> > 3. I noted that in the design there are no examples of a generic 
> function that use the range
> > statement over array, slice, string or map. What is the reason?
>
> Because we're not really sure how that is going to work. In
> particular range is quite a different operation over []byte and
> string, so it would be unusual for a generic function to do that.
>
>
> > P.S: should I report these issues on the Github Issue or on golang-dev?
>
> Here is fine. Thanks.
>
> 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/3a5d8cc4-ea12-4dbc-bbbf-cd114f4f1196n%40googlegroups.com.

[go-nuts] Re: Go doc examples from the command line?

[Sean Liao]

nope https://github.com/golang/go/issues/26715

On Friday, January 21, 2022 at 11:38:19 AM UTC+1 steve@gmail.com wrote:

> I've been using, for example. "go doc -all encoding/csv" to display
> docs from the command line.
>
> Is there any of displaying the code examples visible from the go.dev
> site from the command line for a particular package in the std lib?
>
> -- 
> Steve Mynott 
> rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50
>

-- 
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/c5b23f4f-a53f-4477-84c8-c8834dc6f80fn%40googlegroups.com.

[go-nuts] Go doc examples from the command line?

[Steve Mynott]

I've been using, for example. "go doc -all encoding/csv" to display
docs from the command line.

Is there any of displaying the code examples visible from the go.dev
site from the command line for a particular package in the std lib?

-- 
Steve Mynott 
rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50

-- 
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/CANuZA8Tp9bpZ-au17YiwFty2N7H3so%2B9Up%2BctjWcpEwEG-jw6w%40mail.gmail.com.

Re: [go-nuts] Performance of syscall calls vs. CGO

[Sean]

Hello Ian,

Thank you for the answer.

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.


On 20/01/2022 23:25, Ian Lance Taylor wrote:

On Thu, Jan 20, 2022 at 2:54 AM Sean  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.

Re: [go-nuts] Re: golang-announce is blocked in Google Groups?

[Jochen Voss]

Same here, the problem seems to have gone away.

On Thursday, 20 January 2022 at 19:37:54 UTC seank...@gmail.com wrote:

> For me it did show as blocked a few hours earlier but works now
>


>> > -- 
>> > 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...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/113efe51-64c0-4a53-9631-8177ca8ed8fcn%40googlegroups.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/b08cd338-d908-4d92-9823-cf8920b74541n%40googlegroups.com.