Re: [go-nuts] insane idea to eliminate CGO latency

[Jason E. Aten]

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 
think I read it years ago). 

On Sunday, March 14, 2021 at 9:54:43 PM UTC-5 ren...@ix.netcom.com 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 routines that make C calls only need to ensure a C minimum 
> stack size. The state I was referring to supports the determination of “is 
> running native” and if so “leave it alone” until it returns to Go code. As 
> long as the pointers passed to the C code are either native (non heap) or 
> tracked the C code is “safe”. 
>
> So to that point, it’s confusing as to why the scheduler is the bottleneck 
> in calling C code. 
>
> > On Mar 14, 2021, at 9:38 PM, Ian Lance Taylor  wrote:
> > 
> > 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 the conversation but I'm not sure I
> > understand the point. I think you were the first person to mention GC
> > coordination. I don't think there is any GC coordination issue here.
> > There is a scheduler coordination issue, specifically the need to
> > inform Go's goroutine scheduler that the goroutine is changing
> > behavior.
> > 
> > Ian
> > 
> > 
> >> So if the scheduling is the source of inefficiency there are more 
> simple ways to tackle than this proposal.
> >> 
>  On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor  
> wrote:
> >>> 
> >>> 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 already has easy native C type mapping the FFi should be 
> very efficient depending on types used.
> >>> 
> >>> Go and Java are pretty different here. The type mapping overhead from
> >>> Go to C is effectively non-existent--or, to put it another way, it's
> >>> pushed entirely onto the programmer The GC housekeeping is, as you
> >>> say, low. The heaviest cost is the scheduling housekeeping: notifying
> >>> the scheduler that the goroutine is entering a new scheduling regime,
> >>> so that a blocking call in C does not block the entire program. A
> >>> minor cost is the change is the calling convention.
> >>> 
> >>> As Jason says, if all of the C code--and I really do mean all--can be
> >>> compiled by a Go-aware C compiler, then the scheduling overhead can be
> >>> largely eliminated, and pushed into the system call interface much as
> >>> is done for Go code. But that is a heavy lift. Compiling only some
> >>> of the C code with a Go-aware C compiler seems unlikely to provide any
> >>> significant benefit.
> >>> 
> >>> Ian
> >>> 
> >>> 
> >>> 
>  On Mar 14, 2021, at 11:37 AM, Jason E. Aten  
> wrote:
>  
>  > 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 
> inserting the pre-emption points just like the Go compiler does into the 
> generated code. Or the same checks for blocking.
>  
>  --
>  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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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...@googlegroups.com.
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.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...@googlegroups.com.
> >>> To view this 

Re: [go-nuts] insane idea to eliminate CGO latency

[Robert Engels]

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 size. The 
state I was referring to supports the determination of “is running  native” and 
if so “leave it alone” until it returns to Go code. As long as the pointers 
passed to the C code are either native (non heap) or tracked the C code is 
“safe”. 

So to that point, it’s confusing as to why the scheduler is the bottleneck in 
calling C code. 

> On Mar 14, 2021, at 9:38 PM, Ian Lance Taylor  wrote:
> 
> 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 the conversation but I'm not sure I
> understand the point.  I think you were the first person to mention GC
> coordination.  I don't think there is any GC coordination issue here.
> There is a scheduler coordination issue, specifically the need to
> inform Go's goroutine scheduler that the goroutine is changing
> behavior.
> 
> Ian
> 
> 
>> So if the scheduling is the source of inefficiency there are more simple 
>> ways to tackle than this proposal.
>> 
 On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor  wrote:
>>> 
>>> 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 already has easy native C type mapping the FFi should be 
 very efficient depending on types used.
>>> 
>>> Go and Java are pretty different here.  The type mapping overhead from
>>> Go to C is effectively non-existent--or, to put it another way, it's
>>> pushed entirely onto the programmer  The GC housekeeping is, as you
>>> say, low.  The heaviest cost is the scheduling housekeeping: notifying
>>> the scheduler that the goroutine is entering a new scheduling regime,
>>> so that a blocking call in C does not block the entire program.  A
>>> minor cost is the change is the calling convention.
>>> 
>>> As Jason says, if all of the C code--and I really do mean all--can be
>>> compiled by a Go-aware C compiler, then the scheduling overhead can be
>>> largely eliminated, and pushed into the system call interface much as
>>> is done for Go code.  But that is a heavy lift.  Compiling only some
>>> of the C code with a Go-aware C compiler seems unlikely to provide any
>>> significant benefit.
>>> 
>>> Ian
>>> 
>>> 
>>> 
 On Mar 14, 2021, at 11:37 AM, Jason E. Aten  wrote:
 
 > 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 inserting 
 the pre-emption points just like the Go compiler does into the generated 
 code. Or the same checks for blocking.
 
 --
 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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.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/CAOyqgcVSphZ4w%2BNaCFnkHOmoZ%2BOdD-Ob3K%2BbcjVn02fivJRX%2Bg%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 

Re: [go-nuts] insane idea to eliminate CGO latency

[Ian Lance Taylor]

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 the conversation but I'm not sure I
understand the point.  I think you were the first person to mention GC
coordination.  I don't think there is any GC coordination issue here.
There is a scheduler coordination issue, specifically the need to
inform Go's goroutine scheduler that the goroutine is changing
behavior.

Ian


> So if the scheduling is the source of inefficiency there are more simple ways 
> to tackle than this proposal.
>
> > On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor  wrote:
> >
> > 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 already has easy native C type mapping the FFi should be 
> >> very efficient depending on types used.
> >
> > Go and Java are pretty different here.  The type mapping overhead from
> > Go to C is effectively non-existent--or, to put it another way, it's
> > pushed entirely onto the programmer  The GC housekeeping is, as you
> > say, low.  The heaviest cost is the scheduling housekeeping: notifying
> > the scheduler that the goroutine is entering a new scheduling regime,
> > so that a blocking call in C does not block the entire program.  A
> > minor cost is the change is the calling convention.
> >
> > As Jason says, if all of the C code--and I really do mean all--can be
> > compiled by a Go-aware C compiler, then the scheduling overhead can be
> > largely eliminated, and pushed into the system call interface much as
> > is done for Go code.  But that is a heavy lift.  Compiling only some
> > of the C code with a Go-aware C compiler seems unlikely to provide any
> > significant benefit.
> >
> > Ian
> >
> >
> >
> >> On Mar 14, 2021, at 11:37 AM, Jason E. Aten  wrote:
> >>
> >> > 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 inserting 
> >> the pre-emption points just like the Go compiler does into the generated 
> >> code. Or the same checks for blocking.
> >>
> >> --
> >> 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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.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/CAOyqgcVSphZ4w%2BNaCFnkHOmoZ%2BOdD-Ob3K%2BbcjVn02fivJRX%2Bg%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/CAOyqgcXNJRiAPjejVzroX908XMtgOJqYyb0Nm0%2B5G8GFDfwk%2Bg%40mail.gmail.com.

Re: [go-nuts] Re: Go compiler - where and how the implicit interface "comparable" used?

[messi...@gmail.com]

Thanks for your explanation, that's very helpful :-) 

On Friday, March 12, 2021 at 3:03:00 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> On Fri, Mar 12, 2021 at 4:55 AM messi...@gmail.com  
> wrote:
>
>> Does it use for generics constraints only?
>
>
> That is my understanding.
>  
>
>> As described at 
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#comparable-types-in-constraints
>>  
>> . If so the type comparison and this interface is two unrelated things?
>>
>
> They are related in the sense that `comparable` expresses exactly the 
> constraint of being able to compare values of a type. But the compiler 
> already knows how to compare values of the same type, if that type is 
> comparable. And the `comparable` interface won't be usable as an actual 
> type which can have a value (that would be useless - you need two values of 
> the same concrete type to actually compare, but there is, in general, no 
> guarantee that two values of an interface type are the same concrete type). 
> So there doesn't have to be a direct connection between the two.
>  
>
>>
>> On Friday, March 12, 2021 at 11:42:07 AM UTC+8 messi...@gmail.com wrote:
>>
>>> Hi, 
>>>
>>> I'm reading the new typechecker source code of go compiler(under 
>>> directory cmd/compile/internal/types2), during the initialization process, 
>>> universe.go registers an implicit interface "comparable" inside function 
>>> defPredeclaredComparable 
>>> ,
>>>  
>>> I know it's supposed to be used for type comparison 
>>> but failed to find 
>>> where and how this interface and related method "==" is used. 
>>>
>>> In predicates.go 
>>> 
>>>  there's 
>>> a function 'Comparable" to check whether a type is comparable or not, but 
>>> seems there's nothing to do with the interface.
>>>
>>> And I don't understand the lookup logic for method "==" in type.go 
>>> 
>>>  neither, 
>>> how could an Interface type have method named "=="?
>>>
>>> I searched a lot from the code base but failed to find the answer, could 
>>> anybody kindly give me some clue?
>>>
>>> Thanks a lot :-)
>>>
>> -- 
>> 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/50661f0e-289e-43f3-a9d7-a42feb77f7fbn%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/14cc2521-a155-48db-b000-a5300c6711f1n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 9:25 AM Space A.  wrote:
>
> And Russ didn't write academic paper regarding it (before accepting proposal 
> in less than a month after it was published). =)

There may be some confusion here.  Are you referring to the
Featherweight Go paper (https://arxiv.org/abs/2005.11710)?  Russ
wasn't involved with that.  And it was written in early 2020, long
before the generics proposal was accepted.

Or is there some other paper that I am not aware of?

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/CAOyqgcWbDVN4Bngwm%3DxLFS-kG_pApx0dyT6oGbAbhCFiVxxJbw%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 7:59 AM Space A.  wrote:
>
> You are a smart guy, one of the smartest I have ever talked to. But it looks 
> like you somehow missed a very obvious thing. The people you mentioned (and 
> most of the so-called Go team) AFAIK are Google employees. They work for a 
> company and they are paid for the work they do. If, as you say, they spend so 
> much time, literally years, keep replying "if we find an approach that gives 
> value blablabla", how do you imagine anyone responsible for the process at 
> the end say smth like: "Alright guys, after spending so many man-years we 
> have few solutions, but we finally realized that we were moving in wrong 
> direction, so now we gonna be dropping everything for the sake of better 
> future of Go". Like c'mon? Read what's written, not just words and 
> punctuation, it was a one way ticket (and managers knew it), if you start 
> this process, start spending money and reporting man hours, you know that it 
> will land somewhere.

I understand that argument, but I don't believe that it accurately
describes the development of the language.  The clearest way to see
that is by looking at counter-examples.  There have been several
efforts to change the Go language in the past that have, to date,
failed to occur, despite people "spending money and reporting man
hours."  For example, the multiple proposals that flowed out of
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
None of them have been adopted.

The people who work on Go, including the managers, are aware of the
risks of "we've started this project so we must complete it."
Language development doesn't work that way.  It's OK to realize that
some ideas just can't be made to work.

This is helped by the fact that most language changes don't require
much work to start out.  For many years I was the only person working
on generics in Go, and I certainly wasn't doing it full time.  Then
for several years it was Robert Griesemer and I, again not full time.
Today there are several people working on generics in Go, but that is
only because we got it to the point of a proposal that could be
accepted.


> And I repeat, there wasn't a (public) question or discussion or anything 
> regarding should we drop this topic entirely.

There have been many public discussions on this mailing list as to
whether generics should be dropped entirely.

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_pYU%2BVHkhQDeQ8gTy6CXfB76g1OZdarCJ4YqY6VbGPg%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 7:19 AM Space A.  wrote:
>
> > The discussion of whether or not generics will be added to Go has been 
> > going on for more than a decade.
> That's a lie. There has never been a question of "add it or not". It was 
> always "we will add them" sooner or later.

Please remember the Go Community Code of Conduct
(https://golang.org/conduct) and be respectful and charitable when
discussing other people.  You could call a statement like this a
"mistake," if you must.  It is not a "lie."  Using a word like that in
this context is not respectful.  Please don't do it.  Thanks.

In this case it is neither a lie nor a mistake.  I've been working on
generics in Go for over ten years, on and off, and I can assure you
that, as Axel said, there was no guarantee that they would be added.

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/CAOyqgcVRjs9rRJ%3Dk%3D42Knwm_axPUwNxccggDO0ScMc8Njb2x%3Dg%40mail.gmail.com.

[go-nuts] Analysis check for leaked pointers to loop variable address

[Barisere Jonathan]

Hello everyone.

I have a question about a common programming error I have made several 
times. It regards the use of a pointer to a loop variable outside of the 
loop. Basically, we want to convert a slice, map, or channel of items (the 
source sequence) into a map, slice, or channel of pointers to respective 
items in the source sequence. But, rather than point to the actual values, 
we point to the loop variable.
I have written some code in a GitHub gist to demonstrate this mistake 
. I 
think this mistake can be caught by code analysis tools, but I don't know 
of any that catches these. If there is any, please let me know so that I 
can save my future self some unnecessary trouble. If there isn't, how can I 
make one (probably add it to vet)?
Here's the code sample, if you prefer to read it all here.


// escape_test.go

package main_test

import (
"testing"
"testing/quick"
"unsafe"
)

func all(xs []*int, f func(x *int) bool) (result bool) {
result = true
for _, v := range xs {
result = result && f(v)
}
return result
}

func Test_references_to_loop_variable_outside_the_loop_have_same_value(t 
*testing.T) {
f := func(xs []int) bool {
var loopVariableAddress uintptr
var zeroOfUintptr uintptr
var copies = make([]*int, 0, len(xs))
for _, x := range xs {
if loopVariableAddress == zeroOfUintptr {
// Store the loop variable's address for later comparison.
loopVariableAddress = uintptr(unsafe.Pointer())
}
// Copy the address of x into a slice.
copies = append(copies, )
// The append statement above is most likely a mistake.
// We probably mean
// copies = append(copies, [index]);
// assuming `index` is the ignored loop index.
}
return all(copies, func(x *int) bool {
// All values in `copies` are the same pointer address.
return uintptr(unsafe.Pointer(x)) == loopVariableAddress && *x 
== *copies[0]
})
}

if err := quick.Check(f, nil); err != nil {
t.Fatal(err)
}
}

-- 
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/cfbc843b-2acf-4440-81d2-01ab68a6628bn%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[David Skinner]

I considered generics so important to our workflow that I added it quite 
some time ago, Go is an implementation language, you may implement anything 
you like with it. If you do not like the way it does something, you can use 
it to create a different language, that is what real programmers do. And Go 
makes it very easy to do. When I first started, I was writing machine code 
in octal and years later could read hex dumps the way others could ASM. The 
real problem is that each person who implemented a generics solution did so 
lightly differently so the learning curve is steep and the talent pool is 
shallow. Having well-defined generics for everyone to use will greatly 
benefit the 10% who rolled their own solution and make it easier for 
newbies who must later maintain that code. Heaven helps those who have to 
read my obscure proprietary generics code.

The real problem is to be able to create useful abstractions. Packages 
should be orthogonal APIs, functions should be descriptive, RPCs should not 
have a plethora of microservices for no good reason. Modules and Generics 
are really great and wonderful and save time, but only if used wisely and 
correctly and only as needed. Modules introduced chaos, the dust will 
settle. Generics shall also introduce chaos, but then those who learn to 
use it wisely and effectively shall enjoy and productivity improvement, and 
then that dust will settle.

I have personal reasons to have great trust in the Go team. Go has solved a 
plethora of problems for me already.

On Saturday, March 13, 2021 at 11:35:23 AM UTC-6 axel.wa...@googlemail.com 
wrote:

> On Sat, Mar 13, 2021 at 6:24 PM Space A.  wrote:
>
>> There is a huge difference between generics and some regular questions 
>> like `Etag` implementation, isn't it? In time, investments, "community 
>> demand", commitments to upper management, etc
>>
>
> Indeed. That doesn't change the fact that Russ has a track record and I 
> trust him.
>  
>
>> And Russ didn't write academic paper regarding it
>>
>
> Apparently I missed something. I'm unaware of any papers by Russ.
>  
>
>> (before accepting proposal in less than a month after it was published). 
>> =)
>>
>
> The proposal has been evolving and discussed for almost three years before 
> that. The reason it got accepted in the space of a months is that it was 
> only published as a proposal once the authors felt confident that the 
> refinements they made in response to the public discussion were sufficient 
> to make it acceptable. In particular, it has changed very little from the 
> version they posted more than a year earlier. After three years of 
> discussion, it would have been surprising if new flaws would have surfaced 
> that made it intractable.
>
> It is a testament to how thoroughly it was discussed, not an indication 
> that it wasn't.
>
> FWIW, if you only focus on the one-month period between the proposal 
> getting posted and it being accepted, I am beginning to understand why you 
> think there was never a possibility of it being rejected. It would mean you 
> are unaware of the decade of discussion preceding it.
>
>
>
>> сб, 13 мар. 2021 г. в 19:39, Axel Wagner :
>>
>>> On Sat, Mar 13, 2021 at 4:59 PM Space A.  wrote:
>>>
 You are a smart guy, one of the smartest I have ever talked to. But it 
 looks like you somehow missed a very obvious thing. The people you 
 mentioned (and most of the so-called Go team) AFAIK are Google employees. 
 They work for a company and they are paid for the work they do.

>>>
>>> I did not miss this.
>>>  
>>>
 If, as you say, they spend so much time, literally years, keep replying 
 "if we find an approach that gives value blablabla", how do you imagine 
 anyone responsible for the process at the end say smth like: "Alright 
 guys, 
 after spending so many man-years we have few solutions, but we finally 
 realized that we were moving in wrong direction, so now we gonna be 
 dropping everything for the sake of better future of Go".

>>>
>>> The person responsible for the process (if there is any one person) is 
>>> Russ. I would have expect him to say that, if it was his opinion. He has a 
>>> good track record of acknowledging the arguments on all sides of the 
>>> process and committing to a decision - even it if goes contrary to a 
>>> previous statement of his.
>>>
>>> Here is a recent example I was involved in 
>>> . He 
>>> originally said, in no uncertain terms, that `ETag`s will be supported when 
>>> an `embed.FS` is served over `net/http`. When it became clear that we don't 
>>> have a good design to make it happen, he admitted that it's unfortunate to 
>>> break that promise, but it's better than ending with a bad design.
>>>
>>> Even then, what you are saying doesn't make a lot of sense to me. If 
>>> they spend many years saying "we may add generics, if we find a design that 
>>> 

[go-nuts] encoding/html package to generate html markup programmatically

[atd...@gmail.com]

Hi,

I am currently thinking about implementing SSR for a Go client-side 
framework.
Not only that but I would like to be able to create static html from the 
same code I use to create dynamic  wasm-based webapps.

I was trying to find a package that would enable me to generate an html 
document but seems like none exists.

Do you think it is possible to use encoding/xml to create an xhtml document?


That would allow me to create something like MarkupPy that would replace js 
DOM created element by html element.

-- 
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/1c6efb34-4028-433e-b67c-5774ea014e52n%40googlegroups.com.

Re: [go-nuts] [ANN] MQTT烙

['Dan Kortschak' via golang-nuts]

On Sun, 2021-03-14 at 15:08 -0700, Pascal de Kloe wrote:
> > Did you consider using context.Context rather than quit channels?
>
> Applying a context.Context pretty much implies using a quit channel.
> Done is the only way to receive an expiry signal.
>
> I just don't want to lock code into using the context package. The
> context setup is quite viral. For example, there is no simple way to
> construct a context from a quit channel (for some reason).
>
> The mqtt package distinguishes between cancelation before and after
> submission. It is easy to flatten the error back into the context
> format. The explicitness may even help with understanding the
> consequences more clearly.
>
> err := Publish(ctx.Done(), []byte("Hello"), "demo/+")
> switch {
> …
> case errors.Is(err, mqtt.ErrCanceled), errors.Is(err,
> mqtt.ErrAbandoned):
>   return ctx.Err()
> …
> }

Thanks. That's a yes.

Dan


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

Re: [go-nuts] [ANN] MQTT烙

[Pascal de Kloe]

>
> Did you consider using context.Context rather than quit channels?


Applying a context.Context pretty much implies using a quit channel. Done 
is the only way to receive an expiry signal.

I just don't want to lock code into using the context package. The context 
setup is quite viral. For example, there is no simple way to construct a 
context from a quit channel (for some reason).

The mqtt package distinguishes between cancelation before and after 
submission. It is easy to flatten the error back into the context format. 
The explicitness may even help with understanding the consequences more 
clearly.

err := Publish(ctx.Done(), []byte("Hello"), "demo/+")
switch {
…
case errors.Is(err, mqtt.ErrCanceled), errors.Is(err, mqtt.ErrAbandoned):
return ctx.Err()
…
}

-- 
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/7c1f13ff-48ef-4796-b1d9-71505fcbc4fbn%40googlegroups.com.

[go-nuts] addressing the issue of correlating built in structured types in generic code: float/complex

['Dan Kortschak' via golang-nuts]

Now that a proposal for an approach to generics has been approved[1],
it seems like a good time to again[2] raise the issue of how to be able
to write code that has correlated types where types are structured but
built-in, and so fields are not available to examine. The only case of
this in the language is the relationship between float and their
corresponding complex types. So for example in the case of wanting to
write a simple generic Eigen Decomposition functions we would have

type Real interface {
type float32, float64
}

func Eigen[T Real](m, n int, data []T) (left, values, right []?, ok bool) { ...

but, there is currently no way to specify that []? is a slice of
complex(T, T).

Having a syntax for this is obvious; being able to write []complex(T,
T) in this place is entirely consistent with doing the same thing with
structs where the types of struct fields are visible to the language
user. Indeed, in the current generics proposal, the Gonum quaternion,
dual, hyperdual and dual quaternion number types are easier to
integrate into a generics system than the built in complex number types
because they are based on structs.

Similarly, general utility functions that would be useful in DSP to
interconvert between complex and real would be

func AsComplex[T Real](v T) ? /* a complex(T, T) */ { ...

type Complex interface {
type complex64, complex128
}

func Abs[T Complex](v T) ? /* a float of the correct size */ { ...

Where in the latter being able to write real(T) to specify the type of
the return value.

Dan

[1]https://blog.golang.org/generics-proposal
[2]https://groups.google.com/g/golang-nuts/c/dZIdMJTO5ws/m/nQbBk7NrBgAJ


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

Re: [go-nuts] [ANN] MQTT烙

['Dan Kortschak' via golang-nuts]

On Sun, 2021-03-14 at 10:41 -0700, Pascal de Kloe wrote:
> New MQTT client library + command line tool available.
>
> https://github.com/pascaldekloe/mqtt
>
> Comments are welcome.

Did you consider using context.Context rather than quit channels?



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

Re: [go-nuts] insane idea to eliminate CGO latency

[Robert Engels]

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 than this proposal. 

> On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor  wrote:
> 
> 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 already has easy native C type mapping the FFi should be very 
>> efficient depending on types used.
> 
> Go and Java are pretty different here.  The type mapping overhead from
> Go to C is effectively non-existent--or, to put it another way, it's
> pushed entirely onto the programmer  The GC housekeeping is, as you
> say, low.  The heaviest cost is the scheduling housekeeping: notifying
> the scheduler that the goroutine is entering a new scheduling regime,
> so that a blocking call in C does not block the entire program.  A
> minor cost is the change is the calling convention.
> 
> As Jason says, if all of the C code--and I really do mean all--can be
> compiled by a Go-aware C compiler, then the scheduling overhead can be
> largely eliminated, and pushed into the system call interface much as
> is done for Go code.  But that is a heavy lift.  Compiling only some
> of the C code with a Go-aware C compiler seems unlikely to provide any
> significant benefit.
> 
> Ian
> 
> 
> 
>> On Mar 14, 2021, at 11:37 AM, Jason E. Aten  wrote:
>> 
>> > 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 inserting the 
>> pre-emption points just like the Go compiler does into the generated code. 
>> Or the same checks for blocking.
>> 
>> --
>> 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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.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/CAOyqgcVSphZ4w%2BNaCFnkHOmoZ%2BOdD-Ob3K%2BbcjVn02fivJRX%2Bg%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/FE00494B-DCD8-4760-B87B-08F3DE486165%40ix.netcom.com.

Re: [go-nuts] insane idea to eliminate CGO latency

[Ian Lance Taylor]

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 already has easy native C type mapping the FFi should be very efficient 
> depending on types used.

Go and Java are pretty different here.  The type mapping overhead from
Go to C is effectively non-existent--or, to put it another way, it's
pushed entirely onto the programmer  The GC housekeeping is, as you
say, low.  The heaviest cost is the scheduling housekeeping: notifying
the scheduler that the goroutine is entering a new scheduling regime,
so that a blocking call in C does not block the entire program.  A
minor cost is the change is the calling convention.

As Jason says, if all of the C code--and I really do mean all--can be
compiled by a Go-aware C compiler, then the scheduling overhead can be
largely eliminated, and pushed into the system call interface much as
is done for Go code.  But that is a heavy lift.  Compiling only some
of the C code with a Go-aware C compiler seems unlikely to provide any
significant benefit.

Ian



> On Mar 14, 2021, at 11:37 AM, Jason E. Aten  wrote:
>
> > 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 inserting the 
> pre-emption points just like the Go compiler does into the generated code. Or 
> the same checks for blocking.
>
> --
> 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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.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/CAOyqgcVSphZ4w%2BNaCFnkHOmoZ%2BOdD-Ob3K%2BbcjVn02fivJRX%2Bg%40mail.gmail.com.

Re: [go-nuts] insane idea to eliminate CGO latency

[Robert Engels]

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 efficient depending on 
types used.   

> On Mar 14, 2021, at 11:37 AM, Jason E. Aten  wrote:
> 
> > 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 inserting the 
> pre-emption points just like the Go compiler does into the generated code. Or 
> the same checks for blocking.
> 
> -- 
> 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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.com.

[go-nuts] [ANN] MQTT烙

[Pascal de Kloe]

New MQTT client library + command line tool available.

https://github.com/pascaldekloe/mqtt

Comments are welcome.

-- 
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/886156c4-7942-49e6-bf31-84bbec190a63n%40googlegroups.com.

Re: [go-nuts] insane idea to eliminate CGO latency

[Jason E. Aten]

> 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 inserting 
the pre-emption points just like the Go compiler does into the generated 
code. Or the same checks for blocking.

-- 
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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%40googlegroups.com.

Re: [go-nuts] insane idea to eliminate CGO latency

[Wojciech S. Czarnecki]

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, maintenance is another. Do you have the
> resources to match those poured into SQLite or Harfbuzz?

Where it is impractical there costs of CGO call (and writing a C/go wrapper to 
things like a Harfbuzz) likely are offsetted by the amount of CPU work done on 
C side, or by the amount of human work not done. Where it nears impossible 
there we are and we will be using wrappers :) Neither I advocated rewrite of 
everything — but for small to middle things it can be done and pays almost 
immediately with lower entry and usage costs (eg. https://www.gonum.org/).
 
> Elias

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210314143517.5d7983b0%40macmint.

Re: [go-nuts] insane idea to eliminate CGO latency

[Sebastien Binet]

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 could have a better inter-op story and 
retain a nice cross-compatibility feature (assuming that C compiler could 
cross-compile as the Go one).

A bit like what the Zig compiler can do.

In that scheme, one wouldn't have to maintain a C and a Go code bases. ("Just" 
the C compiler one).

-s
 Original Message 
On Mar 14, 2021, 13:27, Elias Naur wrote:

> 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 aim at a proper rewrite.
>> > >
>> >
>> > A rewrite is one thing, maintenance is another. Do you have the
>> > resources to match those poured into SQLite or Harfbuzz?
>>
>> Harfbuzz is C++ so until someone helps with converting it into pure C
>> it's off limits to ccgo. But it can handle SQLite already:
>> https://pkg.go.dev/modernc.org/sqlite. Passing more than 900k Tcl
>> tests that SQLite includes.
>
> Indeed, I didn't mean to ignore ccgo. My point was aimed at the "then
> you may aim at a proper rewrite" part which seems to argue that
> rewriting is always the better approach.
>
> Elias
>
> --
> 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/C9X2NM4AAJ4C.3UHAPTBAIMZQY%40themachine.

-- 
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/L5ADnsodJ_QYooKjh-tKOOwJPeBhQWtrwiCzURwT3ylFhGM47525LembzJc_FL0TZJU09Ys7ZSCaHrxqYTl0qcI4hnUpc5T4g9iB9KFw85Q%3D%40sbinet.org.

[go-nuts] yet another code gen: specialized datastructure

[clément auger]

hi,

I recently wanted to get the juice out of some programs. 
A queue consumer that transforms inputs over many routines,
then aggregates the results to re order them.
The order is defined by the input order.  

There was many variations written around it,
using a map, a slice, a regular heap, and finally,
a specialized heap (hand written).

Slice was best for its simplicity, regular heap made 
with the package `container/heap` was not as good as expected.
The specialized heap was the best for performance,
but having this added complexity for only one small
library of ~100LOC did not seem a good idea.

So I wrote a template, included and rewrote the tests from
`container/heap`, et voilà, it makes sense. 
It is tested, re usable, and made for perf.

The template are available at 
https://github.com/clementauger/jenjen-datastructure

Then you run (or add it via //go:gen..) 
jenjen -template=github.com/clementauger/jenjen-datastructure/heap \ 
- "U => -, T => -, Heap=>MinIntHeap , MinIntHeap:U=>int, MinIntHeap:T=> 
minInt"

It generates for you a Heap that takes in input regular ints, output 
regular ints, but internally stores them as minInt.
See 
https://github.com/clementauger/jenjen-datastructure/blob/main/examples/heap/jenjen_heap.go#L38

So does it do any good ? 

$ (cd examples/heap; go test -bench=. -benchmem -count=2)
goos: linux
goarch: amd64
pkg: github.com/clementauger/jenjen-datastructure/examples/heap
BenchmarkMinIntHeap-49439108133 ns/op   8 
B/op   0 allocs/op
BenchmarkMinIntHeap-4   1107884 ns/op   8 
B/op   0 allocs/op
BenchmarkRegularHeap-4   3523325731 ns/op  23 
B/op   0 allocs/op
BenchmarkRegularHeap-4   3433321977 ns/op  23 
B/op   0 allocs/op
PASS
ok  github.com/clementauger/jenjen-datastructure/examples/heap4.452s

(I hope i have not made a mistake writing the comparison benchmarks, i 
would not like to criticize the core language implementation in such 
fashion...)

Notes: 
1/ I have to say i was surprised to not find an existing similar project 
using genny  (a more popular code 
generator), did i miss something ?

Clément

-- 
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/1cbe6c3a-d9a7-43ec-bd28-57a84dfcda72n%40googlegroups.com.

Re: [go-nuts] insane idea to eliminate CGO latency

[Elias Naur]

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 aim at a proper rewrite.
> > >
> >
> > A rewrite is one thing, maintenance is another. Do you have the
> > resources to match those poured into SQLite or Harfbuzz?
>
> Harfbuzz is C++ so until someone helps with converting it into pure C
> it's off limits to ccgo. But it can handle SQLite already:
> https://pkg.go.dev/modernc.org/sqlite. Passing more than 900k Tcl
> tests that SQLite includes.

Indeed, I didn't mean to ignore ccgo. My point was aimed at the "then
you may aim at a proper rewrite" part which seems to argue that
rewriting is always the better approach.

Elias

-- 
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/C9X2NM4AAJ4C.3UHAPTBAIMZQY%40themachine.

Re: [go-nuts] insane idea to eliminate CGO latency

[Jan Mercl]

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, maintenance is another. Do you have the
> resources to match those poured into SQLite or Harfbuzz?

Harfbuzz is C++ so until someone helps with converting it into pure C
it's off limits to ccgo. But it can handle SQLite already:
https://pkg.go.dev/modernc.org/sqlite. Passing more than 900k Tcl
tests that SQLite includes.

-- 
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/CAA40n-W708QLO-ei4VLR_AkMq-gJ3dm%3DsMC_Vzf_-nyzmyCMxQ%40mail.gmail.com.

Re: [go-nuts] insane idea to eliminate CGO latency

[Elias Naur]

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 C 
> codebases into proper Go.
>

Rewriting (and maintaining!) mature and well-maintained libraries is 
impractical.
Rewriting platform-bound APIs (OpenGL, Cocoa) is impossible.

> > How crazy is this? :)
>
> There are more "crazy" solutions that actually work:
>
> 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, maintenance is another. Do you have the
resources to match those poured into SQLite or Harfbuzz?

Elias

-- 
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/C9X204WR6MT1.6XVL4AY3M8RX%40themachine.

Re: [go-nuts] insane idea to eliminate CGO latency

[Wojciech S. Czarnecki]

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 to better run C code, what if a C 
> compiler (e.g. clang) was taught to generate code that used the Go stack 
> and calling conventions.

Someone would need to do it, then maintain it.

> Theoretically, the cc output "in Go convention" could be linked with Go 
> code without paying the CGO penalty, no?

Not that easy. Elias Naur already said why.

> How crazy is this? :)

There are more "crazy" solutions that actually work:

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.
 
Caveats: https://github.com/golang/go/issues/40724 
https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20210314123016.12f59da6%40macmint.

Re: [go-nuts] Re: sort string slice like it contains key,val

[Vasiliy Tolstov]

вс, 14 мар. 2021 г. в 01:38, 'Axel Wagner' via golang-nuts
:
>
> One thing I would add is that you'll likely want to use the *Stable versions 
> of the sort functions, to make sure the order of equivalent elements does not 
> change.
> Apart from that, the solution posted by Carla above with an added step to 
> remove duplicates seems like the best solution.
>

Thanks for all  help

> On Sat, Mar 13, 2021 at 11:27 PM Vasiliy Tolstov  wrote:
>>
>> вс, 14 мар. 2021 г. в 01:10, Brian Candler :
>> >
>> > If I understand rightly, the values in the slice are to be interpreted 
>> > (key, value) pairs?  In that case, the natural thing to me is to build a 
>> > map.  This also takes care of "duplicate key, last value wins".  You can 
>> > then sort the keys and convert it back:
>> > https://play.golang.org/p/dTjmO18T1vQ
>> >
>> > However, I think that a slice of adjacent keys and values is not a 
>> > particularly natural way to represent this data; it's clearer to make a 
>> > structure which holds keys and vals.
>> > https://play.golang.org/p/jq358XyKLlx
>> >
>>
>> Yes, but in a small amount of items the operation on slice is faster
>> than map. My case - have not more then 16-20 elements
>>
>> > On Saturday, 13 March 2021 at 13:37:21 UTC va...@selfip.ru wrote:
>> >>
>> >> Hi!
>> >> I'm stuck at sorting stuff like
>> >> []string{"xxxkey","xxxval","zzzkey","zzzval","aaakey","aaaval","zzzkey","val"}
>> >> i need to get after sorting something like
>> >> []string{"aaakey","aaaval", "xxxkey","xxxval","zzzkey","val"}
>> >>
>> >> So i'm sort by "key" and if key is duplicated - last wins.
>> >> Mostly i want to avoid creating helper slices that contains keys and
>> >> vals dedicated, does it possible to do sorting only by swapping
>> >> "key/val" ?
>> >>
>> >> --
>> >> Vasiliy Tolstov,
>> >> e-mail: v.to...@selfip.ru
>> >
>> > --
>> > 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/8eaa86e7-8787-4fc3-bed6-761586825cefn%40googlegroups.com.
>>
>>
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>>
>> --
>> 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/CACaajQvwWX3N0tczs31Jka%3D2UDD_kK2SN-QYJTS_eO46cLAyuQ%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/CAEkBMfEpv3MD_AA5SoVGViPxwrW-Tg_h1xbWo7D7tHhFjR88%3DQ%40mail.gmail.com.



-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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/CACaajQvW9eaTDEFGgwSDN-vb9UMk1NMis68VBKf4k-w_%3Dw_DuQ%40mail.gmail.com.

[go-nuts] Re: insane idea to eliminate CGO latency

[ma...@eliasnaur.com]

On Sunday, 14 March 2021 at 07:57:12 UTC+1 Jason E. Aten wrote:
> 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 that used the Go stack 
and calling conventions.
> Theoretically, the cc output "in Go convention" could be linked with Go 
code without paying the CGO penalty, no?

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. I believe there have been proposals to mark Cgo calls as 
"non-blocking" or similar, in effect promising the runtime that the call 
will return quickly enough to elide scheduling. The problem is that if a 
"non-blocking" C call turns out to block, your program may deadlock.

I also think that it's been mentioned by authorities (probably Ian) that 
there are still gains to be made from optimizing the existing trampolines 
and calling convention adapters.

Elias




-- 
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/592f7074-962e-4ffd-8777-8644427ba3bbn%40googlegroups.com.

[go-nuts] Re: [ANN] New german translations

[HaWe]

Hello Tim.

Translating, that's a hobbyhorse I ride now and then.
(Learn something new about Go and improve your English and German in 
parallel! ;-)

No, sorry. There is no public repository. The private one right here under 
my desk is ... well ... private.

Now, about you taking up translating: that's a great idea. Many of the Go 
documents could be worth the effort; the blog posts about modules come to 
mind. (Write to me off-list if I can be of any help; email address is in 
the top box of any of the translations.)

(BTW there had been a german version of the Tour of Go from 2015 by one 
Michael Faschinger, but alas, that seems to be no longer accessible.)

I'm still thinking about rufen vs. aufrufen; since it's not only about 
calling functions but about exported types and variables as well, the 
appropriate word could be "benutzen". (Changes will be in the next release; 
following Go 1.17.)

So long
HaWe

a2800276 schrieb am Freitag, 12. März 2021 um 15:14:38 UTC+1:

> "Kode" really seems nonstandard to me. It really pops out. I'd definitely 
> spell it "Code" in German and even then it seems like colloquial usage. I'd 
> prefer Quellcode or Quelltext or Programm. 
> "Kode aus einem externen Paket rufen" should really be "aufrufen" no 
> matter how you feel about "Kode" :)
>
> Are you looking for help with the translations? I'd be happy to work with 
> you on them for a while. Is there a repo anywhere?
>  -tim
>
> On Thursday, 11 March 2021 at 20:53:43 UTC+1 HaWe wrote:
>
>> Thanks for your comments. It's nice when one's work is appreciated.
>> About choice of words, have a look at the "Wörterliste". The link is in 
>> the box at the top.
>> About Spelling: that seems to be a question of age. I learnt the word 
>> "Kode" long before I came across computers (but I do use "Computer" in 
>> german sometimes).
>>
>> Uli Kunitz schrieb am Mittwoch, 10. März 2021 um 21:53:04 UTC+1:
>>
>>> The authority on German Orthography, duden.de, recommends the writing 
>>> Code but allows Kode as well.
>>>
>>> On Wednesday, March 10, 2021 at 7:34:05 PM UTC+1 Haddock wrote:
>>>
 I don't know about using the word "Kode" in German. I've never seen it 
 different than with c as in English. Whatever, you took a big effort and 
 did a very nice job. Thank you!

 HaWe schrieb am Dienstag, 9. März 2021 um 17:26:48 UTC+1:

> Just finished german translation of the two new tutorials:
>
> https://bitloeffel.de/DOC/golang/getting-started_de.html 
> https://bitloeffel.de/DOC/golang/create-module_de.html
>
> Maybe that helps some newcomers.
>
> In the menu you'll find all the other Go documents I translated over 
> the years. I tried to keep them up-to-date.
>


-- 
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/c9aa7fea-c035-4f8e-9209-6348c3d7d4a0n%40googlegroups.com.