Re: [go-nuts] Re: How to do vdso calls in my own code?

[Pure White]

Wow, sounds great!
Really looking forward to this feature!
在 2021年4月28日 +0800 PM12:22，Ian Lance Taylor ，写道：
> On Tue, Apr 27, 2021 at 8:26 PM Pure White  wrote:
> >
> > I think this is a good idea. But I suppose this will meet the same problem 
> > I have met  syscall package is outside of the runtime.
>
> We can introduce hooks into the runtime that are only for the standard
> library, because we know exactly how they will be used.
>
> Ian
>
>
>
> > 在2021年4月28日星期三 UTC+8 上午12:54:25 写道：
> > >
> > > I'm not sure if calling through the VDSO is the best solution to this 
> > > specific issue, though it does sound like a case that would certainly 
> > > benefit.
> > >
> > > Regardless, one fairly clean way we could support this would be to make 
> > > x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather 
> > > than performing the syscall. That is always a valid operation (the VDSO 
> > > will make the syscall if it doesn't support the specific options passed), 
> > > and I think would solve this problem without even changing the API. It 
> > > seems we don't do that already for simplicity of implementation and prior 
> > > lack of need.
> > >
> > > On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  
> > > wrote:
> > > >
> > > > On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo  
> > > > wrote:
> > > > >
> > > > > Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor 
> > > > > ha scritto:
> > > > > >
> > > > > > On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
> > > > > >  wrote:
> > > > > > >
> > > > > > > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha 
> > > > > > > scritto:
> > > > > > > >
> > > > > > > > So I really want to know what is the right way to do vdso call 
> > > > > > > > outside runtime?
> > > > > > > >
> > > > > > > What about using a different function instead of time.Now, and 
> > > > > > > using RawSyscall?
> > > > > >
> > > > > > That wouldn't be a VDSO call. VDSO calls are in general faster than
> > > > > > system calls. There is more background at
> > > > > > https://man7.org/linux/man-pages/man7/vdso.7.html.
> > > > > >
> > > > > > Ian
> > > > >
> > > > >
> > > > > Yes, that wouldn't a VDSO call. But since a VDSO call will require 
> > > > > cgo , maybe RawSyscall will be more efficient?
> > > >
> > > >
> > > > The meaningful comparison is to time.Now, which uses VDSO. I suppose it 
> > > > is possible that RawSyscall of clock_gettime with a coarse clock would 
> > > > be faster than time.Now, but I would be surprised.
> > > >
> > > > 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...@googlegroups.com.
> > > >
> > > > To view this discussion on the web visit 
> > > > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/a57afc3e-a91a-4564-b540-dce9ff0e2429n%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/e350ffd1-7f5e-4fed-b816-17b338c4c28a%40Spark.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Ian Lance Taylor]

On Tue, Apr 27, 2021 at 8:26 PM Pure White  wrote:
>
> I think this is a good idea. But I suppose this will meet the same problem I 
> have met  syscall package is outside of the runtime.

We can introduce hooks into the runtime that are only for the standard
library, because we know exactly how they will be used.

Ian



> 在2021年4月28日星期三 UTC+8 上午12:54:25 写道：
>>
>> I'm not sure if calling through the VDSO is the best solution to this 
>> specific issue, though it does sound like a case that would certainly 
>> benefit.
>>
>> Regardless, one fairly clean way we could support this would be to make 
>> x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather than 
>> performing the syscall. That is always a valid operation (the VDSO will make 
>> the syscall if it doesn't support the specific options passed), and I think 
>> would solve this problem without even changing the API. It seems we don't do 
>> that already for simplicity of implementation and prior lack of need.
>>
>> On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:
>>>
>>> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo  wrote:

 Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha 
 scritto:
>
> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo  
> wrote:
> >
> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha 
> > scritto:
> >>
> >> So I really want to know what is the right way to do vdso call outside 
> >> runtime?
> >>
> > What about using a different function instead of time.Now, and using 
> > RawSyscall?
>
> That wouldn't be a VDSO call. VDSO calls are in general faster than
> system calls. There is more background at
> https://man7.org/linux/man-pages/man7/vdso.7.html.
>
> Ian


 Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo , 
 maybe RawSyscall will be more efficient?
>>>
>>>
>>> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it is 
>>> possible that RawSyscall of clock_gettime with a coarse clock would be 
>>> faster than time.Now, but I would be surprised.
>>>
>>> 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...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/a57afc3e-a91a-4564-b540-dce9ff0e2429n%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/CAOyqgcWhmvpWoV5k0BhKsSfPAoS_MuprZzbjEqAjHvM0OhZb_g%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Pure White]

I think this is a good idea. But I suppose this will meet the same problem 
I have met  syscall package is outside of the runtime.

在2021年4月28日星期三 UTC+8 上午12:54:25 写道：

> I'm not sure if calling through the VDSO is the best solution to this 
> specific issue, though it does sound like a case that would certainly 
> benefit.
>
> Regardless, one fairly clean way we could support this would be to make 
> x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather 
> than performing the syscall. That is always a valid operation (the VDSO 
> will make the syscall if it doesn't support the specific options passed), 
> and I think would solve this problem without even changing the API. It 
> seems we don't do that already for simplicity of implementation and prior 
> lack of need.
>
> On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  
> wrote:
>
>> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo  
>> wrote:
>>
>>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha 
>>> scritto:
>>>
 On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo  
 wrote: 
 > 
 > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha 
 scritto: 
 >> 
 >> So I really want to know what is the right way to do vdso call 
 outside runtime? 
 >> 
 > What about using a different function instead of time.Now, and using 
 RawSyscall? 

 That wouldn't be a VDSO call. VDSO calls are in general faster than 
 system calls. There is more background at 
 https://man7.org/linux/man-pages/man7/vdso.7.html.
>>>
>>> Ian
>>>
>>>
>>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo 
>>> , maybe RawSyscall will be more efficient? 
>>>
>>
>> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it 
>> is possible that RawSyscall of clock_gettime with a coarse clock would be 
>> faster than time.Now, but I would be surprised.
>>
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/a57afc3e-a91a-4564-b540-dce9ff0e2429n%40googlegroups.com.

[go-nuts] Recommendations of Go front-ends for single page SaaS application

[Joseph Jones]

Hi Everyone,

I am trying to decide what front-end to use with a Go backend. It seems 
natural to use a Go frontend framework as well but I have not found a lot 
of them. 

At this point I am considering using NextJS with filepond.js with 
netlifyCMS because the user experience seems richer than from the Go 
front-end examples that I have seen. 

Open to suggestions.  Thank you for your time. 

-- 
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/fea146ed-77f5-418d-903e-0029decbceb3n%40googlegroups.com.

Re: [go-nuts] How to do vdso calls in my own code?

[Ian Lance Taylor]

On Tue, Apr 27, 2021 at 10:04 AM Manlio Perillo
 wrote:
>
> Il giorno martedì 27 aprile 2021 alle 00:40:17 UTC+2 Ian Lance Taylor ha 
> scritto:
>>
>> On Mon, Apr 26, 2021 at 1:24 AM Pure White  wrote:
>> > [...]
>> > So I really want to know what is the right way to do vdso call outside 
>> > runtime?
>>
>> The right way is to use cgo. But probably the cost of making the cgo
>> call will overwhelm the speed advantage of using the coarse clocks.
>>
>> Using go:linkname to call systemstack is completely unsupported, and
>> is even less maintainable than your first method.
>>
>> I have to admit that I don't see a way to do this at all. What is the
>> application? How much difference will it make to use the coarse
>> timestamps?
>>
>> Ian
>
>
> Is it technically possible to generate fast unguarded cgo code, using some 
> directive like `//cgo:fastcall` ?

It is technically possible, but unlikely to be implemented.  There is
some discussion at https://golang.org/issue/42469.

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/CAOyqgcXfpPLaNwKAv2gc5YnjWq41%3DqNUHSrpVgaKiHddFVfppw%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Ian Lance Taylor]

On Tue, Apr 27, 2021 at 9:59 AM Michael Pratt  wrote:
>
> Oops, I should say the syscall package could do this. x/sys/unix has the 
> extra complexity of not being tied to a Go release.

It's a good idea, although I'll note that the syscall package does not
currently define ClockGettime.

I think it would be manageable to use build tags to do this in x/sys/unix.

Ian


> On Tue, Apr 27, 2021, 12:53 Michael Pratt  wrote:
>>
>> I'm not sure if calling through the VDSO is the best solution to this 
>> specific issue, though it does sound like a case that would certainly 
>> benefit.
>>
>> Regardless, one fairly clean way we could support this would be to make 
>> x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather than 
>> performing the syscall. That is always a valid operation (the VDSO will make 
>> the syscall if it doesn't support the specific options passed), and I think 
>> would solve this problem without even changing the API. It seems we don't do 
>> that already for simplicity of implementation and prior lack of need.
>>
>> On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:
>>>
>>> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo  
>>> wrote:

 Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha 
 scritto:
>
> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo  
> wrote:
> >
> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha 
> > scritto:
> >>
> >> So I really want to know what is the right way to do vdso call outside 
> >> runtime?
> >>
> > What about using a different function instead of time.Now, and using 
> > RawSyscall?
>
> That wouldn't be a VDSO call. VDSO calls are in general faster than
> system calls. There is more background at
> https://man7.org/linux/man-pages/man7/vdso.7.html.
>
> Ian


 Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo , 
 maybe RawSyscall will be more efficient?
>>>
>>>
>>> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it is 
>>> possible that RawSyscall of clock_gettime with a coarse clock would be 
>>> faster than time.Now, but I would be surprised.
>>>
>>> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/CAOyqgcX69R0dEmPjhBvJ0Z5twMqysuP6WMV6dq5WzsPeLSto3A%40mail.gmail.com.

Re: [go-nuts] How to do vdso calls in my own code?

[Manlio Perillo]

Il giorno martedì 27 aprile 2021 alle 00:40:17 UTC+2 Ian Lance Taylor ha 
scritto:

> On Mon, Apr 26, 2021 at 1:24 AM Pure White  wrote: 
> > [...]
> > So I really want to know what is the right way to do vdso call outside 
> runtime? 
>
> The right way is to use cgo. But probably the cost of making the cgo 
> call will overwhelm the speed advantage of using the coarse clocks. 
>
> Using go:linkname to call systemstack is completely unsupported, and 
> is even less maintainable than your first method. 
>
> I have to admit that I don't see a way to do this at all. What is the 
> application? How much difference will it make to use the coarse 
> timestamps?
>
Ian


Is it technically possible to generate fast unguarded cgo code, using some 
directive like `//cgo:fastcall` ?

Thanks
Manlio 

-- 
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/b843477e-b863-4d49-bdc6-4b2d6401383fn%40googlegroups.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

['Michael Pratt' via golang-nuts]

Oops, I should say the syscall package could do this. x/sys/unix has the
extra complexity of not being tied to a Go release.

On Tue, Apr 27, 2021, 12:53 Michael Pratt  wrote:

> I'm not sure if calling through the VDSO is the best solution to this
> specific issue, though it does sound like a case that would certainly
> benefit.
>
> Regardless, one fairly clean way we could support this would be to make
> x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
> than performing the syscall. That is always a valid operation (the VDSO
> will make the syscall if it doesn't support the specific options passed),
> and I think would solve this problem without even changing the API. It
> seems we don't do that already for simplicity of implementation and prior
> lack of need.
>
> On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:
>
>> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
>> wrote:
>>
>>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
>>> scritto:
>>>
 On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
 wrote:
 >
 > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
 scritto:
 >>
 >> So I really want to know what is the right way to do vdso call
 outside runtime?
 >>
 > What about using a different function instead of time.Now, and using
 RawSyscall?

 That wouldn't be a VDSO call. VDSO calls are in general faster than
 system calls. There is more background at
 https://man7.org/linux/man-pages/man7/vdso.7.html.
>>>
>>> Ian
>>>
>>>
>>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo
>>> , maybe RawSyscall will be more efficient?
>>>
>>
>> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it
>> is possible that RawSyscall of clock_gettime with a coarse clock would be
>> faster than time.Now, but I would be surprised.
>>
>> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/CALoThU9C6uQHtHKFE7v38J-z5Ek5QgnUgHigQYOS6ZBp%3DRkY6Q%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

['Michael Pratt' via golang-nuts]

I'm not sure if calling through the VDSO is the best solution to this
specific issue, though it does sound like a case that would certainly
benefit.

Regardless, one fairly clean way we could support this would be to make
x/sys/unix.ClockGettime (and Gettimeofday) call through the VDSO rather
than performing the syscall. That is always a valid operation (the VDSO
will make the syscall if it doesn't support the specific options passed),
and I think would solve this problem without even changing the API. It
seems we don't do that already for simplicity of implementation and prior
lack of need.

On Tue, Apr 27, 2021 at 12:13 PM Ian Lance Taylor  wrote:

> On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
> wrote:
>
>> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
>> scritto:
>>
>>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
>>> wrote:
>>> >
>>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
>>> scritto:
>>> >>
>>> >> So I really want to know what is the right way to do vdso call
>>> outside runtime?
>>> >>
>>> > What about using a different function instead of time.Now, and using
>>> RawSyscall?
>>>
>>> That wouldn't be a VDSO call. VDSO calls are in general faster than
>>> system calls. There is more background at
>>> https://man7.org/linux/man-pages/man7/vdso.7.html.
>>
>> Ian
>>
>>
>> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo ,
>> maybe RawSyscall will be more efficient?
>>
>
> The meaningful comparison is to time.Now, which uses VDSO.  I suppose it
> is possible that RawSyscall of clock_gettime with a coarse clock would be
> faster than time.Now, but I would be surprised.
>
> 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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%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/CALoThU-sH_HvNbZz-NSR-OOa3tZNybw2YNYK43YqWsYkmT-XsA%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Amnon]

https://blog.cloudflare.com/its-go-time-on-linux/

A bit old, but still relevant.

Also https://github.com/dterei/gotsc may be useful depending on your 
requirements.


On Tuesday, 27 April 2021 at 16:54:38 UTC+1 manlio@gmail.com wrote:

> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha 
> scritto:
>
>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo  
>> wrote: 
>> > 
>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha 
>> scritto: 
>> >> 
>> >> So I really want to know what is the right way to do vdso call outside 
>> runtime? 
>> >> 
>> > What about using a different function instead of time.Now, and using 
>> RawSyscall? 
>>
>> That wouldn't be a VDSO call. VDSO calls are in general faster than 
>> system calls. There is more background at 
>> https://man7.org/linux/man-pages/man7/vdso.7.html.
>
> Ian
>
>
> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo , 
> maybe RawSyscall will be more efficient? 
>
>
> Manlio
>

-- 
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/93b1edd8-cc53-4fef-b713-d563d69ea876n%40googlegroups.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Ian Lance Taylor]

On Tue, Apr 27, 2021, 8:55 AM Manlio Perillo 
wrote:

> Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha
> scritto:
>
>> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo 
>> wrote:
>> >
>> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha
>> scritto:
>> >>
>> >> So I really want to know what is the right way to do vdso call outside
>> runtime?
>> >>
>> > What about using a different function instead of time.Now, and using
>> RawSyscall?
>>
>> That wouldn't be a VDSO call. VDSO calls are in general faster than
>> system calls. There is more background at
>> https://man7.org/linux/man-pages/man7/vdso.7.html.
>
> Ian
>
>
> Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo ,
> maybe RawSyscall will be more efficient?
>

The meaningful comparison is to time.Now, which uses VDSO.  I suppose it is
possible that RawSyscall of clock_gettime with a coarse clock would be
faster than time.Now, but I would be surprised.

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/CAOyqgcX9mfSFq5gucrTCi0PJyVdLzA2xGXNByDeOGOyaFLo1hA%40mail.gmail.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Manlio Perillo]

Il giorno martedì 27 aprile 2021 alle 17:51:46 UTC+2 Ian Lance Taylor ha 
scritto:

> On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo  
> wrote: 
> > 
> > Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha 
> scritto: 
> >> 
> >> So I really want to know what is the right way to do vdso call outside 
> runtime? 
> >> 
> > What about using a different function instead of time.Now, and using 
> RawSyscall? 
>
> That wouldn't be a VDSO call. VDSO calls are in general faster than 
> system calls. There is more background at 
> https://man7.org/linux/man-pages/man7/vdso.7.html.

Ian


Yes, that wouldn't a VDSO call.  But since a VDSO call will require cgo , 
maybe RawSyscall will be more efficient? 


Manlio

-- 
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/d9be55ac-1837-42db-8286-fbc45a02a25cn%40googlegroups.com.

Re: [go-nuts] Re: How to do vdso calls in my own code?

[Ian Lance Taylor]

On Tue, Apr 27, 2021 at 7:43 AM Manlio Perillo  wrote:
>
> Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha scritto:
>>
>> So I really want to know what is the right way to do vdso call outside 
>> runtime?
>>
> What about using a different function instead of time.Now, and using 
> RawSyscall?

That wouldn't be a VDSO call.  VDSO calls are in general faster than
system calls.  There is more background at
https://man7.org/linux/man-pages/man7/vdso.7.html.

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/CAOyqgcWVtD_x0%3D--GhsRX_jUsE93ZPi-YT5XnBLW6pLLb%2BL5-w%40mail.gmail.com.

Re: [go-nuts] How to do vdso calls in my own code?

[Kurtis Rader]

This feels like a "XY Problem"  but probably is
not an example of that class of problems. Nonetheless, as Ian points out,
the Go community can probably provide more useful answers if given more
context regarding why you feel the need for this optimization. In my
experience applications that call the equivalent of `gettimeofday()` so
frequently that function call is a bottleneck tend to have more serious
problems. See also questions such as
https://stackoverflow.com/questions/58189790/do-clock-monotonic-and-clock-monotonic-coarse-have-the-same-base
.

On Mon, Apr 26, 2021 at 1:24 AM Pure White  wrote:

> Hi all,
>
> I'm trying to get time using `CLOCK_REALTIME_COARSE` and
> `CLOCK_MONOTONIC_COARSE` for performance reasons, and need to use vdso call
> by hand-written assembly code. That is, I want to reimplement `time.Now`
> using `CLOCK_REALTIME_COARSE` and `CLOCK_MONOTONIC_COARSE`.
>
> I referenced the code in runtime and found that there's an issue #20427
> indicates that I need to switch to g0 for vdso calls, so I tried two
> methods but neither is good.
>
> ## The first method
>
> The first method I tried is just copy the code in runtime and simply
> change the clockid, but this requires copying all the runtime type
> definations as well to make the compiler generate "go_asm.h" for me.
>
> The code runs well, but this is really ugly and unmaintainable as the type
> definations may change across different go versions.
>
> ## The second method
>
> The second method I tried is to link the `runtime.systemstack` and use it
> to do vdso calls:
> ```go
> //go:linkname systemstack runtime.systemstack
> //go:noescape
> func systemstack(fn func())
> ```
>
> My code is something like this:
>
> ```go
> // now calls vdso and is implemented in asm
> func now() (sec int64, nsec int32, mono int64)
>
> func Now() {
>   var sec, mono int64
>   var nsec int32
>   systemstack(func() {
> sec, nsec, mono = now()
>   })
>   ... // logic copied from time.Now()
> }
> ```
>
> The code runs well without `-race`(test isn't enough), but I encountered
> fatal error under `-race` mode.
> For detailed information, I've filed an issue:
> https://github.com/golang/go/issues/45768.
>
> ## The right way?
>
> So I really want to know what is the right way to do vdso call outside
> runtime?
>
> Thanks very much!
>
> --
> 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/49e183dc-4f13-4627-b0ae-cab2c15ae931n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-o%3DbP6DB-zxoS8NTi8Yd7Cim3M02cYzG%2B2SVHZTWd%2BBA%40mail.gmail.com.

[go-nuts] Re: How to do vdso calls in my own code?

[Manlio Perillo]

Il giorno lunedì 26 aprile 2021 alle 10:24:09 UTC+2 Pure White ha scritto:

> Hi all,
>
> I'm trying to get time using `CLOCK_REALTIME_COARSE` and 
> `CLOCK_MONOTONIC_COARSE` for performance reasons, and need to use vdso call 
> by hand-written assembly code. That is, I want to reimplement `time.Now` 
> using `CLOCK_REALTIME_COARSE` and `CLOCK_MONOTONIC_COARSE`.
>
> I referenced the code in runtime and found that there's an issue #20427 
> indicates that I need to switch to g0 for vdso calls, so I tried two 
> methods but neither is good.
> < [...]
>

> ## The right way?
>
> So I really want to know what is the right way to do vdso call outside 
> runtime?
>
> Thanks very much!
>

What about using a different function instead of time.Now, and using 
RawSyscall?

Manlio 

-- 
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/30b8d7f3-499b-4aab-a7f0-a5fad865a14an%40googlegroups.com.

Re: [go-nuts] Re: How to manage replace directives in go.mod files when code versioning ?

[Ilia Choly]

I usually just use patch commits:

git add -p

On Tuesday, April 27, 2021 at 10:24:51 AM UTC-4 Reto wrote:

> On Mon, Apr 26, 2021 at 11:59:47PM -0700, christoph...@gmail.com wrote:
> > Thank you for pointing this out. I wasn’t aware of it. But the question
> > still holds for published main programs.
>
> If you have such a tight dependency that you need to develop them in 
> parallel
> (and hence need replace directives to a local fork) maybe they ought to 
> life
> in the same module?
> Then you don't need to have a replace directive in the first place.
>
> Other than that, git is your friend... *Do* commit the change and then 
> rebase
> the thing away when you don't need it anymore.
>

-- 
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/8819e1bd-3b47-4036-802f-a4f8c6dd21b3n%40googlegroups.com.

Re: [go-nuts] Re: How to manage replace directives in go.mod files when code versioning ?

[Reto]

On Mon, Apr 26, 2021 at 11:59:47PM -0700, christoph...@gmail.com wrote:
> Thank you for pointing this out. I wasn’t aware of it. But the question
> still holds for published main programs.

If you have such a tight dependency that you need to develop them in parallel
(and hence need replace directives to a local fork) maybe they ought to life
in the same module?
Then you don't need to have a replace directive in the first place.

Other than that, git is your friend... *Do* commit the change and then rebase
the thing away when you don't need it anymore.

-- 
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/20210427142415.4gdlpfcvstn5axgh%40feather.localdomain.

[go-nuts] Re: How to manage replace directives in go.mod files when code versioning ?

[christoph...@gmail.com]

Thank you for pointing this out. I wasn’t aware of it. But the question 
still holds for published main programs. 

Le mardi 27 avril 2021 à 07:27:58 UTC+2, Uli Kunitz a écrit :

> Are you aware of "replace directives only apply in the main 
> module's go.mod file and are ignored in other modules. See Minimal 
> version selection  for 
> details."?
>
> You can find it here: https://golang.org/ref/mod#go-mod-file-replace
>
> On Tuesday, April 27, 2021 at 7:23:52 AM UTC+2 christoph...@gmail.com 
> wrote:
>
>> When debugging or testing we may need to add a replace directive in the 
>> go.mod file.
>>
>> This change intended to be local only may interfere with code versioning. 
>> The replace directive may be accidentally committed and published. What is 
>> the proper way to manage replace directives when it comes to code 
>> versioning ? 
>>
>> Apparently we are supposed to remove replace directives before commits, 
>> and put it back to continue testing. That is boring and error prone. Is 
>> there a better way ?
>>
>

-- 
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/93675842-5e9f-44dc-a4e2-44c7643824b2n%40googlegroups.com.

Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?

[Brian Candler]

On Tuesday, 27 April 2021 at 07:28:39 UTC+1 christoph...@gmail.com wrote:

> It seam that C is wrong on this one and Go is right. The rationale is that 
> a NaN must propagate through operations so that we can detect problems 
> (avoid silent NaNs). See https://en.wikipedia.org/wiki/NaN
>
> Thus any operation involving a NaN must return an NaN and this includes 
> Max and Min. 
>  
>

That Wikiepedia page has a paragraph about this specific case:

*In section 6.2 of the old IEEE 754-2008 
 standard, there are 
two anomalous functions (the maxNum and minNum functions, which return the 
maximum of two operands that are expected to be numbers) that favor 
numbers — if just one of the operands is a NaN then the value of the other 
operand is returned. The IEEE 754-2019 
 revision has 
replaced these functions as they are not associative 
 (when a signaling NaN 
appears in an operand).[4] 
[5] 
*

Reference [4] is:  David H.C. Chen (21 February 2017). "The 
Removal/Demotion of MinNum and MaxNum Operations from IEEE 754™-2018" 
 
(PDF). 
It very clearly describes the problem and gives the behaviours of some 
selected implementations.

Given that this was only fixed in 2019, you can hardly blame C for getting 
it wrong :-)

-- 
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/9879b8f5-2ac4-4f26-b7d4-f62177730e28n%40googlegroups.com.

Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?

[Bakul Shah]

>From the wikipedia article:

There are differences of opinion about the proper definition for the result of 
a numeric function  that receives a 
quiet NaN as input. One view is that the NaN should propagate to the output of 
the function in all cases to propagate the indication of an error. Another 
view, and the one taken by the ISO C99  and 
IEEE 754-2008  standards 
in general, is that if the function has multiple arguments and the output is 
uniquely determined by all the non-NaN inputs (including infinity), then that 
value should be the result.

Should Go be updated to follow IEEE 754-2008? [I assume currently it is 
following IEEE 754]

-- Bakul

> On Apr 26, 2021, at 11:28 PM, christoph...@gmail.com 
>  wrote:
> 
> It seam that C is wrong on this one and Go is right. The rationale is that a 
> NaN must propagate through operations so that we can detect problems (avoid 
> silent NaNs). See https://en.wikipedia.org/wiki/NaN 
> 
> 
> Thus any operation involving a NaN must return an NaN and this includes Max 
> and Min. 
>  
> Le jeudi 22 avril 2021 à 12:43:23 UTC+2, jesper.lou...@gmail.com a écrit :
> On Thu, Apr 22, 2021 at 11:54 AM 'Dan Kortschak' via golang-nuts 
>  > wrote:
> 
> Does anyone know the reason for this? (Looking through other languages,
> the situation in general seems to be a mess).
> 
> 
> I looked at OCaml, which provides both variants:
> 
> Float.max : float -> float -> float
> Float.max_num : float -> float -> float
> 
> The `max` function includes NaNs in the computation, while `max_num` omits 
> them. Another important treatment the documentation mentions is `max -0.0 
> +0.0`.
> 
> I also looked at Matlab and R. They essentially provide ways to either 
> include the NaN or omit it from the computation, usually when you have a 
> vector of numbers where some of the numbers are unknown. I.e., they take 
> extra (optional) flags to their functions which tells you how to treat NaN 
> values.
> 
> The "pure" solution is clearly the one where NaN's yield a NaN. It is 
> isomorphic to a Monoid based on optional values with the NaN forming the 
> unknown element, often called the option-monoid or the maybe-monoid. Or said 
> otherwise: for any type a, where a is a monoid, so is 'option a':
> 
> forall a. Monoid a => Monoid (Option a)
> 
> Since the max function itself is a monoid with the neutral element taken as 
> the minimal value, -inf, we can thus "lift" NaN values on top and still have 
> some mathematical consistency.
> 
> But if you have an array of values, where some of them can be NaN, it is 
> probably smart to provide a function which filters the array of NaN values 
> and computes the remaining values. R provides the function `na.omit(..)` for 
> this. So do option types in languages such as OCaml or Haskell. Here, we are 
> not that concerned about what is sound from a formal point of view, but more 
> concerned with data cleanup before we start using the formality.
> 
> Max of two values is a special case. The generalized version takes an 
> array/vector of values and provides the maximum in the structure.
> 
> All of this leads me to conclude you probably want both variants in the end. 
> In some situations, it is better to include NaN values in the computation, 
> and in other situations, the right move is to omit/exclude them.
> 
> 
> 
> -- 
> 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/9950a06b-1222-4543-b979-763f37516e2an%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/CEEB3353-7441-4D50-84FA-61E6EFCC83F4%40iitbombay.org.

Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?

['Dan Kortschak' via golang-nuts]

On Mon, 2021-04-26 at 23:28 -0700, christoph...@gmail.com wrote:
> It seam that C is wrong on this one and Go is right. The rationale is
> that a NaN must propagate through operations so that we can detect
> problems (avoid silent NaNs). See https://en.wikipedia.org/wiki/NaN
>
> Thus any operation involving a NaN must return an NaN and this
> includes Max and Min.

This is not what the IEEE 754 spec says for the behaviour of minNum and
maxNum. Whether a language decides to implement their min and max
functions according to the IEEE 754 spec is up to them. Note that Go
uses non-signalling NaN's and claims to use IEEE 754 floating point
numbers (https://golang.org/ref/spec#Numeric_types). So we'd expect it
to have the behaviour specified in the 754 spec. This is why I asked
the question. Jesper's answer highlighted subtlety that is worth
considering.


-- 
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/7bbb6c9daf86ae6010a273d603cb9e4c9dae743b.camel%40kortschak.io.

Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?

[christoph...@gmail.com]

It seam that C is wrong on this one and Go is right. The rationale is that 
a NaN must propagate through operations so that we can detect problems 
(avoid silent NaNs). See https://en.wikipedia.org/wiki/NaN

Thus any operation involving a NaN must return an NaN and this includes Max 
and Min. 
 
Le jeudi 22 avril 2021 à 12:43:23 UTC+2, jesper.lou...@gmail.com a écrit :

> On Thu, Apr 22, 2021 at 11:54 AM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>>
>> Does anyone know the reason for this? (Looking through other languages,
>> the situation in general seems to be a mess).
>>
>>
> I looked at OCaml, which provides both variants:
>
> Float.max : float -> float -> float
> Float.max_num : float -> float -> float
>
> The `max` function includes NaNs in the computation, while `max_num` omits 
> them. Another important treatment the documentation mentions is `max 
> -0.0 +0.0`.
>
> I also looked at Matlab and R. They essentially provide ways to either 
> include the NaN or omit it from the computation, usually when you have a 
> vector of numbers where some of the numbers are unknown. I.e., they take 
> extra (optional) flags to their functions which tells you how to treat NaN 
> values.
>
> The "pure" solution is clearly the one where NaN's yield a NaN. It is 
> isomorphic to a Monoid based on optional values with the NaN forming the 
> unknown element, often called the option-monoid or the maybe-monoid. Or 
> said otherwise: for any type a, where a is a monoid, so is 'option a':
>
> forall a. Monoid a => Monoid (Option a)
>
> Since the max function itself is a monoid with the neutral element taken 
> as the minimal value, -inf, we can thus "lift" NaN values on top and still 
> have some mathematical consistency.
>
> But if you have an array of values, where some of them can be NaN, it is 
> probably smart to provide a function which filters the array of NaN values 
> and computes the remaining values. R provides the function `na.omit(..)` 
> for this. So do option types in languages such as OCaml or Haskell. Here, 
> we are not that concerned about what is sound from a formal point of view, 
> but more concerned with data cleanup before we start using the formality.
>
> Max of two values is a special case. The generalized version takes an 
> array/vector of values and provides the maximum in the structure.
>
> All of this leads me to conclude you probably want both variants in the 
> end. In some situations, it is better to include NaN values in the 
> computation, and in other situations, the right move is to omit/exclude 
> them.
>
>
>

-- 
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/9950a06b-1222-4543-b979-763f37516e2an%40googlegroups.com.