Re: [go-nuts] External/internal linker and cgo packages
Hello Ian, Thank you again for your reply! I thought Go would compile all the C files in one .go, that makes sense. By the way, how Go would deal with those files if cgo is not enabled - meaning the internal linker will do the job? How the internal linker can deal with that? Le jeudi 30 avril 2020 07:52:03 UTC+4, Ian Lance Taylor a écrit : > > On Tue, Apr 28, 2020 at 10:49 PM Vincent Blanchon > > wrote: > > > > I'm building a simple program that has a dependency to > github.com/DataDog/zstd, a wrapper of a C code. > > So by default, Go will use the external linker. When debugging with, I > can see > > > > host link: "clang" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" > "-Wl,-pagezero_size,400" "-o" > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-build122622791/b001/exe/a.out" > > "-Qunused-arguments" > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/go.o" > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/00.o" > [...] > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/53.o" > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/54.o" > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/55.o" > "-g" "-O2" "-g" "-O2" "-g" "-O2" "-lpthread" "-g" "-O2" "-framework" > "CoreFoundation" "-framework" "Security" "-no-pie" > > > > It links 55 files, from 00.o to 55.oIf I had more custom debug, > I can see than those files are mostly duplication: > > > > 04.o is > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d > > github.com/DataDog/zstd > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x005.o) > > > > 05.o is > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d > > github.com/DataDog/zstd > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x006.o) > > > > > > I can see 40 times this zstd package among the 55 files. Is it expected? > What is the difference between them? > > > > Also, what would happen to the non known cgo packages (not net, os/user > or runtime/cgo) if cgo is not enabled? How the internal linker will manage > this cgo package? > > I may be missing something, but that doesn't look like duplication to > me. It looks like different files from an archive. The first one is > _x005.o and the second one is _x006.o. > > You will get files like these for each .c file in a package that uses cgo. > > 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/38760d5d-b8e3-4a42-b087-8b81ab4ebd87%40googlegroups.com.
[go-nuts] External/internal linker and cgo packages
Hello, I'm building a simple program that has a dependency to github.com/DataDog/zstd, a wrapper of a C code. So by default, Go will use the external linker. When debugging with, I can see host link: "clang" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" "-Wl,-pagezero_size,400" "-o" "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-build122622791/b001/exe/a.out" "-Qunused-arguments" "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/go.o" "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/00.o" [...] "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/53.o" "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/54.o" "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/55.o" "-g" "-O2" "-g" "-O2" "-g" "-O2" "-lpthread" "-g" "-O2" "-framework" "CoreFoundation" "-framework" "Security" "-no-pie" It links 55 files, from 00.o to 55.oIf I had more custom debug, I can see than those files are mostly duplication: 04.o is /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d github.com/DataDog/zstd /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x005.o) 05.o is /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d github.com/DataDog/zstd /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x006.o) I can see 40 times this zstd package among the 55 files. Is it expected? What is the difference between them? Also, what would happen to the non known cgo packages (not net, os/user or runtime/cgo) if cgo is not enabled? How the internal linker will manage this cgo package? Thank you -- 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/db2d65de-8fc5-460e-b309-57f27cdf86cf%40googlegroups.com.
[go-nuts] "Timers rely on the network poller", why is that?
Hi everyone, >From what I understand, timers are ran by: - the P holding them - other P if timer-stealing happen (thanks to the async preemption that should not happen often) - sysmon thread that, periodically, check if some timers have to run But, in the comments of the code, I have seen this sentence "Timers rely on the network poller". I wonder how is it related to the net poller, I do not get the relation here. Any help is appreciated :) Thank you -- 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/f0b2a756-aeff-4d0c-83c3-015f43018842%40googlegroups.com.
Re: [go-nuts] issue with past-the-end pointer
Thank you Ian! Le mercredi 18 mars 2020 23:20:15 UTC+4, Ian Lance Taylor a écrit : > > On Wed, Mar 18, 2020 at 9:33 AM Vincent Blanchon > > wrote: > > > > In this proposal > https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md, > > it is mentioned past-the-end pointer and the fact it should be avoided. My > assumption is that it could lead to a bad memory tracking/cleaning since > the write barriers keep track of the change in the pointers. Is that > correct? > > Pretty much, yes. A past-the-end pointer looks like a pointer to the > next object, and the write barrier can't tell the difference. > > 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/ed6c6b51-0c19-4ccc-847f-48d629570016%40googlegroups.com.
[go-nuts] issue with past-the-end pointer
Hi all, In this proposal https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md, it is mentioned past-the-end pointer and the fact it should be avoided. My assumption is that it could lead to a bad memory tracking/cleaning since the write barriers keep track of the change in the pointers. Is that correct? Thank you -- 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/123409ca-4742-4def-9643-2f23d00bab61%40googlegroups.com.
Re: [go-nuts] Re: stringer command and generated String() function
Yes, definitely, good point. Both are them are good depending on the case actually. Le mardi 18 février 2020 16:55:02 UTC+4, Jan Mercl a écrit : > > On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon > > wrote: > > > However, in real code, I guess we will have that many constants, so it > does not make really sense to increase the number. > > Design decisions may be driven by the desire to maximize the > performance in the average case or in the worst case scenario. > > That's why Go has a regexp package that's slower in the average case > wrt PCRE, but it guarantees linear, not exponential, performance of > the worst case. > -- 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/69db18c0-31a4-4d52-94c6-a168ef815e0a%40googlegroups.com.
Re: [go-nuts] Re: stringer command and generated String() function
With 100 constants: Stringer-4 4.96ns ± 0% StringerWithSwitch-4 4.99ns ± 1% StringerWithMap-4 30.40ns ± 0% The gap between the switch and the current implement is much smaller. I guess it is due to the number of JMP instructions the code has to go through. It confirms that the results before was accurate. I guess if I increase the number of constant, the current implementation will become faster. However, in real code, I guess we will have that many constants, so it does not make really sense to increase the number. It does not explain why this choice of design^^ The only thing I can see is the binary size... it is slightly bigger with the switch and 100 constants. Le mardi 18 février 2020 14:24:55 UTC+4, pierr...@gmail.com a écrit : > > > I did not add it since it was not the original question ^^ >> But why can't we have the check and a switch? >> >> > Definitely can. Just didnt see it. My response was somewhat tangential to > your question, sry. > -- 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/9fa488e0-73ae-49fc-9a01-f60f7ebc6cfb%40googlegroups.com.
Re: [go-nuts] Re: stringer command and generated String() function
@Jan Thank you for the feedback. I will try with a higher number of
constants. By the way, my benchmark tries all the path:
func BenchmarkStringerWithSwitch(b *testing.B) {
for i := 0; i < b.N ; i++ {
p := Pill(i%20)
_ = p.String()
}
}
> I can't find any compile time check in your code
I did not add it since it was not the original question ^^
But why can't we have the check and a switch?
Here is the code:
package main
import "strconv"
func _() {
// An "invalid array index" compiler error signifies that the constant
values have changed.
// Re-run the stringer command to generate them again.
var x [1]struct{}
_ = x[Placebo-0]
_ = x[Aspirin-1]
_ = x[Ibuprofen-2]
}
func (i Pill) String() string {
switch i {
case 0: return "Placebo"
case 1: return "Aspirin"
case 2: return "Ibuprofen"
case 3: return "Paracetamol"
default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
}
}
Le mardi 18 février 2020 14:06:14 UTC+4, Jan Mercl a écrit :
>
> On Tue, Feb 18, 2020 at 10:37 AM Vincent Blanchon
> > wrote:
>
> > @Jan, yes definitely. By the way, here are some numbers from a benchmark
> I made with 20 constants:
> >
> > name time/op
> > Stringer-4 4.16ns ± 2%
> >
> > StringerWithSwitch-4 3.81ns ± 1%
> >
> > StringerWithMap-4 28.60ns ± 2%
>
> 20 is a small number. In general, measuring things where one iteration
> is in single digit nanoseconds can be misleading as discussed earlier.
> The probably most important thing is how a chosen implementation
> scales. To measure that, I suggest to make the number of the constants
> in hundreds, if not thousands and having the loop exercise all the
> paths, so the branch predictor cannot learn a single, happy one. In
> any case, it's much safer to shift the time/op to at least
> microseconds, otherwise the overhead of the test per se becomes
> comparable to the measured thing and it just adds noise at minimum.
>
> > @Pierre, the compilation check can also be done if we do not have a
> slice. In my example with the switch, I still kept the compilation check.
>
> I can't find any compile time check in your code (the one using the
> switch) that can detect a constant has changed its value since
> stringer was run.
>
--
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/ee65758b-274f-4e20-b6ef-7a449b55221b%40googlegroups.com.
[go-nuts] Re: stringer command and generated String() function
@Brian, this code is generated by the stringer command based on this
code: https://play.golang.org/p/JNfRC5TZYlo
@Jan, yes definitely. By the way, here are some numbers from a benchmark I
made with 20 constants:
name time/op
Stringer-4 4.16ns ± 2%
StringerWithSwitch-4 3.81ns ± 1%
StringerWithMap-4 28.60ns ± 2%
Map is definitely the slowest one.
@Pierre, the compilation check can also be done if we do not have a slice.
In my example with the switch, I still kept the compilation check. This
check just use the constants, no relation with the "String()" function.
Le mardi 18 février 2020 13:20:01 UTC+4, pierr...@gmail.com a écrit :
>
> The const/slice implementation should be faster as Jan said.
>
> Note that there is also a blank function that fails at compile time if
> items have been added or changed and stringer has not been rerun since.
> The const/slice implementation allows for that (useful!) check.
>
>
> Le mardi 18 février 2020 07:42:41 UTC+1, Vincent Blanchon a écrit :
>>
>> Hello,
>>
>> I was wondering why the stringer command has been implemented that way:
>>
>> const _Pill_name = "PlaceboAspirinIbuprofen"
>>
>> var _Pill_index = [...]uint8{0, 7, 14, 23}
>>
>> func (i Pill) String() string {
>>if i < 0 || i >= Pill(len(_Pill_index)-1) {
>> return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>>}
>>return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
>> }
>>
>>
>>
>> When it could be simpler and faster with a simple enum:
>>
>> func (i Pill) String() string {
>>switch i {
>>case 0: return "Placebo"
>>case 1: return "Aspirin"
>>case 2: return "Ibuprofen"
>>case 3: return "Paracetamol"
>>default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
>>}
>> }
>>
>>
>> After running a benchmark with a higher number of values (20), the enum
>> is always faster. I also was surprised to see the binary is not bigger
>> (maybe it will be with more values).
>>
>> Does someone know what advantages the current design brings?
>>
>
--
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/e99ed426-a5ff-4582-9e6a-89143812ee46%40googlegroups.com.
[go-nuts] stringer command and generated String() function
Hello,
I was wondering why the stringer command has been implemented that way:
const _Pill_name = "PlaceboAspirinIbuprofen"
var _Pill_index = [...]uint8{0, 7, 14, 23}
func (i Pill) String() string {
if i < 0 || i >= Pill(len(_Pill_index)-1) {
return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
}
return _Pill_name[_Pill_index[i]:_Pill_index[i+1]]
}
When it could be simpler and faster with a simple enum:
func (i Pill) String() string {
switch i {
case 0: return "Placebo"
case 1: return "Aspirin"
case 2: return "Ibuprofen"
case 3: return "Paracetamol"
default: return "Pill(" + strconv.FormatInt(int64(i), 10) + ")"
}
}
After running a benchmark with a higher number of values (20), the enum is
always faster. I also was surprised to see the binary is not bigger (maybe
it will be with more values).
Does someone know what advantages the current design brings?
--
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/02c41c35-1453-4b0b-9379-be9bd87a6f1c%40googlegroups.com.
Re: [go-nuts] loop & CX register
I got it, Thank you Ian! Le jeudi 2 janvier 2020 07:36:39 UTC+4, Ian Lance Taylor a écrit : > > On Wed, Jan 1, 2020 at 7:25 PM Vincent Blanchon > > wrote: > > > > Here is a loop in Go: https://play.golang.org/p/G4wdLi26LZ4 > > With looking at the assembly, I can see that the loop counter uses AX > register while the total (t) use the CX register: > > > > 0x004c 00076 (main.go:7) INCQ AX > > 0x004f 00079 (main.go:8) ADDQ DX, CX > > > > I have a basic knowledge of assembly, but out of curiosity, why does the > loop counter not use the counter register CX? Isn't it the purpose of it? > > And should not "t" use AX that looks more designed for that? > > > > I guess since they are historical registers and have a general-purpose, > it does not matter the way the language uses them? > > On modern x86 processors the various registers are essentially > interchangeable, except for a few special purpose instructions. > > 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/9735d342-124f-434c-bd98-dd294e31ea33%40googlegroups.com.
[go-nuts] loop & CX register
Hi, Here is a loop in Go: https://play.golang.org/p/G4wdLi26LZ4 With looking at the assembly, I can see that the loop counter uses *AX* register while the total (t) use *the CX* register: 0x004c 00076 (main.go:7) INCQ AX 0x004f 00079 (main.go:8) ADDQ DX, CX I have a basic knowledge of assembly, but out of curiosity, why does the loop counter not use the counter register *CX*? Isn't it the purpose of it? And should not "t" use *AX* that looks more designed for that? I guess since they are historical registers and have a general-purpose, it does not matter the way the language uses 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/9b21c787-0ef9-4049-a8ea-a1bdcae84f24%40googlegroups.com.
[go-nuts] Re: GOMAXPROCS > num of CPU
Hello Serhat, Yes, I do not see a use case either. This is why I opened this thread, to know if someone sees a use case since it has been mentioned on GitHub :) Le jeudi 5 décembre 2019 11:33:10 UTC+4, Serhat Şevki Dinçer a écrit : > > In runtime it says: > > The GOMAXPROCS variable limits the number of operating system threads that > can execute user-level Go code simultaneously. There is no limit to the > number of threads that can be blocked in system calls on behalf of Go code; > those do not count against the GOMAXPROCS limit. This package's GOMAXPROCS > function queries and changes the limit. > > So normally it does not make sense to increase it beyond available > physical "HW threads" (I think this is what you meant with cpu) count > (since blocked threads do not count towards this limit). > As long as "active thread accounting" is accurate in the OS, I dont see > any reason to set it higher. I think it is easy to test >HWthreads effects > with a concurrent cpu-intensive job. > > On Wednesday, December 4, 2019 at 8:24:13 PM UTC+3, Vincent Blanchon wrote: >> >> Hello, >> >> >> I've read on GitHub ( >> https://github.com/golang/go/issues/20303#issuecomment-329418911) "there >> are good reasons" to set GOMAXPROCS to > num CPU. >> Just out of curiosity, I want to know if someone has an example of it or >> any good reason to set it up more than the number of CPUs? >> >> Thanks >> > -- 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/e281fe24-26f2-4a20-89ee-b43888c557c2%40googlegroups.com.
[go-nuts] GOMAXPROCS > num of CPU
Hello, I've read on GitHub (https://github.com/golang/go/issues/20303#issuecomment-329418911) "there are good reasons" to set GOMAXPROCS to > num CPU. Just out of curiosity, I want to know if someone has an example of it or any good reason to set it up more than the number of CPUs? Thanks -- 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/ea6e3dd2-9d27-44b4-bd8a-2bb32f3eb236%40googlegroups.com.
[go-nuts] Are M always detached from P when syscall?
Hello, I was wondering about the behavior of syscalls. It looks like Go always wraps syscall - whatever blocking or not - with calling entersyscallblock() and exitsyscall() later. The first one automatically detaches M from the P when exit tries to acquire the same P or move the G to the global queue. In the case of non-blocking syscall, why do we have to detach M from the P? Did I miss something? Thanks in advance for anyone that could clarify that. -- 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/f88b2609-19d5-47a5-a2e4-f5900d265622%40googlegroups.com.
Re: [go-nuts] mcache per P or per M?
Thank you, Ian! With the CL it is much more clear now Le mardi 5 novembre 2019 02:27:00 UTC+4, Ian Lance Taylor a écrit : > > On Sat, Nov 2, 2019 at 4:58 AM Vincent Blanchon > > wrote: > > > > Reading the code, I can see the structs m and p hold a mcache instance. > I'm curious to understand why both of them need an instance of mcache? > > Also, I see that those instances are the same ones (runtime/proc.go init > the p.mcache with m.cache and vice versa), is it correct? Should we > consider that mcache belongs to m or p? > > The mcache belongs to the P. > > We used to have the possibility of an M using the mcache of a P even > though it was not running on the P. That happened in the helpgc > function which was run by gchelpers. But gchelpers was removed in > https://golang.org/cl/134785, so it may be that we no longer need the > mcache field on an M. > > Out of curiosity, I tried that: https://golang.org/cl/205239. > > 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/95207d0d-ffab-4ddc-8011-89e8d4310d65%40googlegroups.com.
[go-nuts] mcache per P or per M?
Hello, Reading the code, I can see the structs m and p hold a mcache instance. I'm curious to understand why both of them need an instance of mcache? Also, I see that those instances are the same ones (runtime/proc.go init the p.mcache with m.cache and vice versa), is it correct? Should we consider that mcache belongs to m or p? Thank you for the ones that will take time to reply :) -- 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/bba54eca-6b54-4566-b5c7-933f7ce6f401%40googlegroups.com.
[go-nuts] Re: causal profiling in Go
That's interesting, thanks for sharing. Also interested to know if someone got results with a similar approach. > -- 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/9a6bf539-96b7-4588-9b67-e370af71ab1c%40googlegroups.com.
[go-nuts] garbage collector forced to run every two minutes
Hi, I was wondering what problem *gcTriggerTime* is supposed to solve? Why does the language need to force the GC every two minutes if it did not run? Thanks in advance -- 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/03220b37-cd7a-40f3-810d-e5eec135be30%40googlegroups.com.
[go-nuts] CPU profiling with pprof
Hi, The documentation of the profiling (https://blog.golang.org/profiling-go-programs) explains that: "Go program stops about 100 times per second". However, in the code, I could see that the collector has a sleep of 100ms https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go#L779. Therefore, it collects data only 10 times per second? Also, it does not stop the program since it is a separated goroutine https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go#L764. Did I miss something here? -- 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/3d516ed5-f657-40a6-bbab-c3002a0ba65b%40googlegroups.com.
Re: [go-nuts] Go compiler - syntax tree vs AST?
Hello Ian, Thank you for your answer. Why do you ask? Just out of curiosity, I was working with the SSA package for a tool, and since the compiler uses this package as well I wanted to go a bit deeper on that and write a small article on it. That's quite an interesting part but the usage of two different syntax tree was a bit confusing. Hope this helps Yes, a lot. Thanks again! Le mardi 3 septembre 2019 17:54:38 UTC+4, Ian Lance Taylor a écrit : > > On Tue, Sep 3, 2019 at 6:23 AM Vincent Blanchon > wrote: > > > > The compiler documentation mentions a syntax tree in the parsing phase > when the AST transformation phase mentions a conversion from the syntax > tree to the compiler's AST representation. > > If I do not misunderstand, the command "go tool compile -W" will display > the AST. > > > > I was wondering how far is different the syntax tree from the AST? Where > could I get documentation or an example of this syntax tree? > > Note that AST just means Abstract Syntax Tree, so it's a little > confusing to talk converting a syntax tree to an AST. What we really > have is two different ASTs. > > Unfortunately none of this stuff is well documented. The parser > generates a syntax tree as defined in cmd/compile/internal/syntax. > That is then converted to the Node tree defined in > cmd/compile/internal/gc/syntax.go. The -W option dumps the latter. I > don't know of a way to dump the former, but perhaps there is one. > > > Also, is this syntax tree mandatory? Is it not possible to build the AST > directly from the lexer+parser? > > The use of two different syntax trees is entirely historical due to > the evolution of the compiler. The original code base was a C > compiler written in C which became a Go compiler written in C which > was machine translated from C to Go. There has been a lot of cleanup > but there is still a lot of historical cruft. As far as I know the > most likely next evolutionary step in this area will be to replace the > Node tree with the cmd/compile/internal/syntax tree. > > Hope this helps, and I hope someone will correct me if I made a mistake. > > Why do you ask? > > 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/73d829f2-bdcc-4615-b82e-3dce43abd8cf%40googlegroups.com.
[go-nuts] Go compiler - syntax tree vs AST?
Hi all, The compiler documentation mentions a syntax tree in the parsing phase when the AST transformation phase mentions a conversion from the syntax tree to the compiler's AST representation. If I do not misunderstand, the command "*go tool compile -W" *will display the AST. I was wondering how far is different the syntax tree from the AST? Where could I get documentation or an example of this syntax tree? Also, is this syntax tree mandatory? Is it not possible to build the AST directly from the lexer+parser? Thanks in advance -- 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/a48a5771-e504-4078-8f45-bb803e10ea75%40googlegroups.com.
