Hi Robert, you misunderstand my point. Your first response was talking
about the difference between chan and mutex implementation, here I am
comparing mutex with difference number of goroutines.
Basically what you suspected doesn't match what was observed from
statistics.
On Tuesday, August 27,
Another thing to keep in mind, udp is unreliable so different outbound
interfaces will most likely take different paths and many under stress will
drop udp traffic - some always, especially on unknown ports - which is not
correct behavior but it happens over the internet. You shouldn’t see this
Begin forwarded message:
> From: Robert Engels
> Date: August 26, 2019 at 7:38:20 PM CDT
> To: Tanner Ryan
> Subject: Re: [go-nuts] Multiple interface addresses and UDPConn.WriteToUDP
>
> If the network is set up properly the kernel should chose the correct network
> interface based on the
Hi,
I was hoping someone could help me with an issue. I have a simple UDP
server that listens on a specific port, responding with a message back.
conn, err := net.ListenUDP("udp", &net.UDPAddr{IP: net.IPv4(0, 0, 0, 0),
Port: *port})
When reading messages, I use the source address for sending a
This is a perennial issue.
We all want to know and understand; it is the sign of true intellect to
feel a need to own the details. It is also true that measuring “out of
context” is literally to measure something different and often that
difference is bigger than the measurement. It can be very di
I said in my very first response to you, that the mechanisms of the implementation are different, with the in-kernel futex of the channel implementation faster that the Go. Much of this is probably because the thread is dedicated at this point. All that means is that up to a certain point - the CAS
Incidentally, it just happened again without involving the GC stop the
world, where all 8 P's were running and had the same program counters for 4
seconds. They are the same as those in the previous email.
On Mon, Aug 26, 2019 at 2:11 PM Michael Andersen
wrote:
> Hi
>
> I was concerned that perh
Hi
I was concerned that perhaps the stacks that I dumped after the scheduling
stall did not reflect the actual PC's of the goroutines during the stall,
so I modified schedtrace to dump out g.sched.pc and g.m.vdsoPC for each G
currently on the P at the time schedtrace prints.
It just occurred agai
Based on the pprof graph, I would rather believe that the massive
performance drop happens because of the `semacquire1` implementation.
When the number of goroutines is small, most of the `semacquire1` success
in the `cansemacquire ` fast path, or a middle path where a lock was
required but then
You might want to try 'perf mem' to report the access delays - it may be contention on the memory controller as well.Thinking about it again, I wouldn't expect a large jump if things were fair - for example, if at 100 they all fit in the cache, at 110, some are still in the cache, but some operatio
Did I do anything wrong, the cache hint ratio decrease linearly, is it an
expected result? I thought the cache hint ratio would have a significant
drop:
[image: chart.png]
Raw data:
#goroutines cache-references cache-misses hint/(hint+miss)
2400 697103572 17641686 0.9753175194
3200 798160789 54
Hello Michael,
I've posted a reply at
https://github.com/golang/go/issues/32326#issuecomment-524997226 but
perhaps I'll inline it below:
Hello @MichaelTJones, thank you for the patience! We are working on trying
to diagnose why it is that by the time that the test executes, that your
machi
Another method would be to change the operation under test, to touch and read a large memory block - turning off the timer while this happens - so that only the concurrency ops are timed - I think then you will no longer see the 'super high performance' with the low routine counts. That is, do 'mor
You can run the process under 'perf' and monitor the cpu cache hit/miss ratio.-Original Message-
From: changkun
Sent: Aug 26, 2019 2:23 PM
To: golang-nuts
Subject: Re: [go-nuts] sync.Mutex encounter large performance drop when goroutine contention more than 3400
Your cache theory is very
Your cache theory is very reasonable, but this was clear in the beginning
post: "before or after the massive increase, performance drops linearly".
Your hypothesis is reasonable, but how can you prove your hypothesis? By
host machine cache usage monitoring?
Matching of a concept is still not pe
Which is what I would expect - once the number of routines exhaust the cache, it will take the next level (or never since its main memory) to see an massive increase in time. 4800 is 30% slower than 3600 - so it is increasing linearly with the number of Go routines.-Original Message-
From:
I implemented a Library [1] and a CLI [2] for automatic log rotation.
Library:
Very useful for log rotation by its own binary.
CLI:
Very useful for making standard output rotation directly.
[1] https://github.com/moisespsena-go/glogrotation
[2] https://github.com/moisespsena-go/glogrotation-cli
On Mon, Aug 26, 2019 at 10:48 AM wrote:
>
> I am planning to replace C++ threadpool class with goroutines. I see several
> go implementations for threadpool.
Without getting into how to do this, why do you want to do this?
Goroutines work very well for Go code, but when Go code calls into C++
co
Hi,
I am planning to replace C++ threadpool class with goroutines. I see
several go implementations for threadpool.
few are
https://github.com/panjf2000/ants/
I am having issue, when i need to call back and forth . preferably, I need
to keep C++ function has main. C++ function calls SubmitTa
According to your formula let's sample three points:
2400 goroutines: 2.508s/(5000*2400) = 2.09 × 10^-11 s
3600 goroutines: 12.219s/(5000*3600) = 6.7883 × 10-11 seconds
4800 goroutines: 16.020s/(5000*4800) = 6.67500 × 10^-11 s
One can observe that 3600 and 4800 mostly equal to eac
And it looks like the `semacquire1` executed too many `gopark`, which means
indicating that `cansemacquire` failed a lot when too much contention
happens.
On Monday, August 26, 2019 at 6:27:14 PM UTC+2, changkun wrote:
>
> Sorry for late response. Do you mean the total execution was not the same
Sorry for late response. Do you mean the total execution was not the same?
If so then it is not true, you see below two bench are executed both 5000
times:
goos: linux
goarch: amd64
BenchmarkMutexWrite/goroutines-2400-8 5000
46.5 ns/op
Type: cpu
Time: Aug 26, 2
You have to be careful with this approach and high volume (longer latency) tcp. Often there can be TCP "stalls" and if you have a messaging type protocol, you need to make sure you can handle partial reads and re-combine, because the deadline may fire during the read (typically a problem with text
>
> I could not get a goroutine to shut down if it is waiting on user input
> from a socket, or a dropped connection, although that begs the question of
> how to get the socket-reading goroutine to now shut down.
>
My usual approach is to set 100ms read deadlines and then check for the
shutdow
Excellent! Thank you, Klaus!
It sounds like it does, but just to be clear: does S2 also replace/upgrade
the snappy *streaming* format (the outer format that is different from
snappy itself; e.g. https://github.com/glycerine/go-unsnap-stream )?
On Monday, August 26, 2019 at 6:29:29 AM UTC-4, Kl
Hi!
S2 is an extension of Snappy. It can decode Snappy content but S2 content
cannot be decoded by Snappy. S2 is aimed for high throughput, so it
features concurrent compression for bigger payloads (streams).
Benefits over Snappy:
-
Better compression
-
Concurrent stre
The only weird thing I've done is some manual upgrade of go (Ubuntu had not
gotten modules so I did some wget thing to get a newer version I think). I
do go build in bash because the modules thing has broken VS Code (or I have
a mismatch of VS Code plugins, etc. etc. -- all acceptable pains). I
27 matches
Mail list logo
