Hi there,
I recently managed a data parsing C library in a CGO program by for long
time network IO.
The data flow is as follows:
user socket <> socketpair[0] <---> socketpair[1] <> data store
|--Go domain|--C domain-|
With such a data f
Hi Robert,
I checked your benchmark, and it kindly solves the second question "there
is no way to optimize". Thank you :)
Best,
changkun
On Monday, September 17, 2018 at 6:19:33 PM UTC+2, Robert Engels wrote:
>
> You can run my tests at github.com/robaho/go-network-test You
Is the benchmark measured in a wrong way? Are all I/Os call via
net package suffering it?
Best,
changkun
On Monday, September 17, 2018 at 8:51:06 PM UTC+2, Ian Lance Taylor wrote:
>
> On Mon, Sep 17, 2018 at 1:41 AM, changkun > wrote:
> >
> > Thus, my first question is: C
Your answers are very decent, it solve all my doubts. Thank you very much!
I believe I need to spend some time reading how runtime scheduler works for
more deep understanding of all "magic".
Cheers,
changkun
On Monday, September 17, 2018 at 9:25:20 PM UTC+2, Ian Lance Taylor wrote:
port.
(gdb) info files
Symbols from "/Users/changkun/Desktop/demo/main".
Local exec file:
`/Users/changkun/Desktop/demo/main', file type mach-o-x86-64.
Entry point: 0x1049e20
0x01001000 - 0x0104dfcf is .text
0x00
> have adequate debugging information; it's not perfect, but we are hoping to
> get it good enough that core dumps and probes from/on running applications
> will yield useful information.
>
> Sorry for the inconvenience.
>
>
> On Thursday, September 27, 2018 at 9:38:
ories allocated in a cgo call always stands in
the same sharing heap even threading?
5. Any other theories and how cloud possibly solve the problem?
6. If I am asking a wrong question, could you shoot any ideas of
solving the issue described above?
Thank you very much in advance.
Best,
chan
On Friday, September 28, 2018 at 4:12:31 PM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Sep 28, 2018 at 7:08 AM, changkun > wrote:
> >
> > 1. Is my suspicion reasonable and correct?
>
> I wouldn't be my first guess. You say that pango memory is
> per-thre
On Friday, September 28, 2018 at 6:44:10 PM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Sep 28, 2018 at 7:45 AM, changkun > wrote:
> >
> > On Friday, September 28, 2018 at 4:12:31 PM UTC+2, Ian Lance Taylor
> wrote:
> >>
> >> On Fri
As discussed before, the every pango call is called in a non-Go newly
created thread by C.
runtime.LockOSThread doesn't work.
On Saturday, September 29, 2018 at 1:24:21 PM UTC+2, Tamás Gulácsi wrote:
>
> You should LockOSThread and process every pango-facing call in that
> goroutine.
--
You r
On Saturday, September 29, 2018 at 2:08:03 PM UTC+2, Tamás Gulácsi wrote:
>
> Yes, but is that a one and only goroutine?
No. The cgo call is opened for every new incoming user request.
Let's summarize:
- Every network request creates a goroutine without response
processing result to a user
On Saturday, September 29, 2018 at 3:46:41 PM UTC+2, Robert Engels wrote:
>
> Your description makes no sense. Why are you creating another C thread,
> you should just lock the OS thread the Go routine is on. Otherwise if you
> create another C thread, in the cgo call you need to block that thr
On Saturday, September 29, 2018 at 4:03:42 PM UTC+2, Tamás Gulácsi wrote:
>
> Create One (1) goroutine with LockOSThread and let it get the todo and
> response channel from a channel and send the response back when ready, and
> make all other goroutines communicate with this one and only one
>
Hi golang nuts:
In "mstart", there is a call "mexit" after "mstart1".
Howeverm "mstart1" will be entering sched loop and never returns.
So, my question is when will "mexit" be executed? How?
mstart1()
// Exit this thread.
if GOOS == "windows" || GOOS == "solaris" || GOOS == "plan9" || GOOS ==
Hi,
sorry for late response. Your solution is very inspiration! I solved the
problem
with letting pango call entering go domain and lock on os thread, then back
to c domain.
Thank you very much!
cheers, changkun
On Saturday, September 29, 2018 at 6:16:10 PM UTC+2, Tamás Gulácsi wrote
Hi,
Thanks for your recommendations, very interesting implementation :)
I solved the problem with a callback from c to go to c.
cheers, changkun
On Saturday, September 29, 2018 at 6:27:08 PM UTC+2, ohir wrote:
>
> On Fri, 28 Sep 2018 22:27:04 -0700 (PDT)
> changkun > wrote:
>
Thank you, I probably will use them in the future of more migrations~
cheers, changkun
On Sunday, September 30, 2018 at 12:06:09 AM UTC+2, K Davidson wrote:
>
> Not sure if it would be of any help, but maybe you can gleem some insight
> from the way these packages did things?
Just ignore this thread.
I've figured it out.
On Saturday, October 13, 2018 at 12:38:53 PM UTC+2, changkun wrote:
>
> Hi golang nuts:
>
> In "mstart", there is a call "mexit" after "mstart1".
> Howeverm "mstart1" will be entering sc
I am comparing the performance regarding sync.Mutex and Go channels. Here
is my benchmark: https://play.golang.org/p/zLjVtsSx9gd
The performance comparison visualization is as follows:
[image: sync.Mutex performance (1).png]
What are the reasons that
1. sync.Mutex encounter a large performance
wrote:
>
> On Mon, Aug 19, 2019 at 10:50 AM changkun > wrote:
> >
> > I am comparing the performance regarding sync.Mutex and Go channels.
> Here is my benchmark: https://play.golang.org/p/zLjVtsSx9gd
>
> Might be interesting to try running your benchmark
erformance drop appears. Is
it possible to determine when the performance will appear?
Best,
Changkun
On Monday, August 19, 2019 at 10:27:19 PM UTC+2, Robert Engels wrote:
>
> I think you'll find the reason that the Mutex uses the Go scheduler. The
> chan is controlled by a 'm
fair in that case.
Best, Changkun
On Tuesday, August 20, 2019 at 10:55:13 AM UTC+2, Ian Davis wrote:
>
>
> On Tue, 20 Aug 2019, at 9:33 AM, changkun wrote:
>
> Hi Robert,
>
> Thanks for your explanation. But how could I "logged the number of
> operations done per G
ot as trivial so the overhead of the locking/scheduler constructs have
> far less effect (or the worker is causing L1 evictions anyway - so you
> never see the optimum performance possible of the scheduler).
>
> -Original Message-
> From: changkun
> Sent: Aug 20, 2019 3:33 AM
0.10s 1.83% 82.82% 0.11s 2.01% sync.runtime_nanotime
0.09s 1.65% 84.46% 3.64s 66.54%
_/home/changkun/dev/tests_test.BenchmarkMutexWrite.func1.1
0.09s 1.65% 86.11% 0.09s 1.65% runtime.casgstatus
0.08s 1.46% 87.57% 0.08s 1.46% runtime.(*semaRoot).d
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 n
al to each other, but they
both three times slower than 2400.
goos: linux
goarch: amd64
BenchmarkMutexWrite/goroutines-2400-8 5000
46.5 ns/op
PASS
ok _/home/changkun/dev/tests 2.508s
goos: linux
goarch: amd64
BenchmarkMutexWrite/goroutines-3
slower than 3600 - so it is
> increasing linearly with the number of Go routines.
>
>
> -----Original Message-
> From: changkun
> Sent: Aug 26, 2019 11:49 AM
> To: golang-nuts
> Subject: Re: [go-nuts] sync.Mutex encounter large performance drop when
> goroutine
x27; 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
then `cansemacquire` success again.
The drop happens in the case that goroutines are failed for fast path and
middle path, and therefore needs to be parked, which involves runtime
schedule costs.
How do you refute to this argument?
On Monday, August 26, 2019 at 10:56:21 PM UTC+2, changkun wrote
of
> workloads.
>
> Still, you keep ignoring this aspect - in the context of actual workloads
> the difference is negligible.
>
> -Original Message-
> From: changkun
> Sent: Aug 26, 2019 4:08 PM
> To: golang-nuts
> Subject: Re: [go-nuts] sync.Mutex enco
I have upgraded my code to Go 1.13 with newly introduced errors APIs.
However, I am not able to upgrade the production environment Go version
which is Go 1.11, which means I have to run Go 1.13 code on a Go 1.11
environment.
What are the way to make my builds both happy on local and production
Hi, golang nuts,
Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG
In the code snippet, a ticker is activating and another that that is
closing, it seems that they can happen concurrently and result
in two different outcomes: either ticker case being executed first or the
o
PM UTC+2, robert engels wrote:
>
> You need to code it knowing that either can occur in any order.
>
> On Sep 8, 2019, at 10:14 AM, changkun >
> wrote:
>
> Hi, golang nuts,
>
> Let's think about this snippet: https://play.golang.org/p/3cNGho3gWTG
>
> In the
8, 2019 at 8:40 AM changkun >
> wrote:
>
>> The provided code snipped on my machine can result in different outputs,
>> which basically shows that it could occur in any order.
>>
>
> Yes
>
>
>> The randomization mechanism in select statement made
Hi Alex,
Thank you for giving such great clarification. You thought is more
sophisticated than me.
First: The close *does* happen-before the case clause of the select for the
> closed channel, as per the memory model.
>
Indeed, no question here.
> Second: If you actually establish an orde
Sincerely sorry for the typo of your name :( Axel
--
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 discussio
As we all know that a program is interrupted by a signal and entering
kernel space then switch to a userspace signal handler. After the signal
handler is accomplished, it will be reentering the kernel space then switch
back to where was interrupted.
I am recently reading the newly implemented a
n Sunday, December 8, 2019 at 7:37:12 PM UTC+1, Ian Lance Taylor wrote:
>
> On Sun, Dec 8, 2019 at 7:02 AM changkun >
> wrote:
> >
> > As we all know that a program is interrupted by a signal and entering
> kernel space then switch to a userspace signal handler. Aft
msg1)))
}
//go:nosplit
func printmsg2() {
write(2, unsafe.Pointer(&msg2[0]), int32(len(msg2)))
}
On Monday, December 9, 2019 at 12:42:42 AM UTC+1, Ian Lance Taylor wrote:
>
> On Sun, Dec 8, 2019 at 1:10 PM changkun >
> wrote:
> >
> > Thank you so much for your hin
256 run queue size is designed for the work-steal scheduler to prevent
false sharing.
128 run queue size exactly fits one cache line. Since the run queue can be
stolen half of the run queue from the tail by other Ps, 256 run queue size
prevents false sharing when the work-steal happens on diffe
mod file,
import as "io" directly.
Thanks for reading.
Changkun
--
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...@goog
>
> but the others are needed for "go build" & co.
>
This can be solved by first issuing an std module first, then using go
modules to import these packages for go build.
The idea is to separate compiler and runtime, then have a minimum go core
distribution. The Go development process then can
ouble we have making a single unified release, it's not obvious
> to me that the Go team has the bandwidth to handle separate release
> cycles that need to work together.
>
> Ian
>
>
>
> > On Mon, Jan 27, 2020 at 3:31 PM Volker Dobler > wrote:
> >>
nd see if I can find any undetailed planned
proposal leaks, sorry about any inappropriate wording.
Changkun
On Tuesday, January 28, 2020 at 11:38:20 PM UTC+8, Ian Lance Taylor wrote:
>
> On Tue, Jan 28, 2020 at 12:27 AM changkun > wrote:
> >
> > - the main repo team focus
Hi golang-nuts,
As far as I know, there are two approaches to add extra information at
build time:
1. using -ldflags="-X path/pkg.Var=${ENV_VAR}", in a Makefile
2. using `go generate ./...`, before `go build`
These approaches are good as it is if I build my binary and distribute it
to other use
That is really unfortunate. Is there any alternative solution so that I can
burn at least the version information to the binary when a user uses `go
get`?
On Wednesday, November 25, 2020 at 6:36:17 PM UTC+1 Jan Mercl wrote:
> On Wed, Nov 25, 2020 at 6:25 PM changkun wrote:
>
> >
Hi golang-nuts,
I would like to call a C function from Go and get notified about the
execution status in Go, say a goroutine wait until the C function finally
made some progress.
Initially, I thought about passing a channel to C but the cgo document does
not say anything about that:
Later, I a
nels in correspondingly invoked C functions?
Sincerely,
Changkun
--
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.
T
12:39 PM changkun wrote:
> >
> > Thanks for the hint, but I have some follow-up questions:
> >
> >>
> >> Even if there were a way to do this, an atomic variable is not a good
> >> synchronization mechanism, because the other side has to poll the
> >&
Hi golang-nuts,
I am trying out the latest type parameter, and type sets design.
The purpose is to implement a Clamp function that works for numbers and vectors.
The version for numbers is straightforward and easy:
```go
// Number is a type set of numbers.
type Number interface {
~int | ~int
Many thank for the perf tool, it is pretty awesome.
> On 27. Aug 2019, at 13:36, Robert Engels wrote:
>
> Ok maybe it wasn’t the cache issue, so then try this, below a certain number
> of go routines given the workload the spin and cas works, beyond a certain
> point it is forced into the sema
Hi golang-nuts,
I am trying out the latest type parameter and type sets design.
The purpose is to implement a Clamp function that works for numbers and
vectors.
The version for numbers is straightforward and easy:
```go
// Number is a type set of numbers.
type Number interface {
~int | ~int8 | ~
ctual breaking change?
Thanks!
Changkun
--
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 o
lot of time from a very early attempt to tackle the problem once again.
Changkun
On Tuesday, May 3, 2022 at 9:38:35 PM UTC+2 Ian Lance Taylor wrote:
> On Tue, May 3, 2022 at 12:28 PM Changkun Ou wrote:
> >
> > I wonder how the Go project defines a breaking change, specifically f
I think the new memory model does not guarantee this program always prints 1:
1. There is no synchronization guarantee between line 13 and line 14
as these atomic operations are manipulated on the different memory
locations.
2. It is *not* prohibited for the compiler to switch line 13 and line
14
of execution. The most relaxing
requirement: permit the compiler to switch the statement.
On Mon, Aug 15, 2022 at 9:32 AM Axel Wagner
wrote:
>
>
>
> On Mon, Aug 15, 2022 at 9:06 AM Changkun Ou wrote:
>>
>> I think the new memory model does not guarantee this program always pr
ations on different memory locations obey the program statements
order within a goroutine.
On Mon, Aug 15, 2022 at 10:16 AM Axel Wagner
wrote:
>
> On Mon, Aug 15, 2022 at 10:02 AM Changkun Ou wrote:
>>
>> > The memory operations in each goroutine must correspond to
golang/mobile is still maintenance. If you encounter any usage issues, feel
free to report them here: https://github.com/golang/go/issues
On Monday, September 12, 2022 at 3:33:18 AM UTC+2 sytuv ccoxf wrote:
> Is golang/mobile still active?
>
> It seems like does not committed since Jul 23 2022.
58 matches
Mail list logo
