[go-nuts] Re: Concurrent access to map

It is not safe to do so and you're understandably asking yourself "but why? my goroutines are working on different already existing entries, so what's going on exactly?". It turns out that a go builtin map is an opaque stucture that is free to completely reorganize itself at any write operation.

[go-nuts] Re: [ANN] Ugarit

Em segunda-feira, 15 de maio de 2017 09:30:20 UTC-3, mhh...@gmail.com escreveu: > > On the code itself, > i suspect you don t know yet about *go fmt*, > I strongly suggest you to use it, > just because its a great idea. > > https://github.com/luisfurquim/ugarit/blob/master/epub20/book.go#L66 > T

[go-nuts] Re: Concurrent access to map

On Tuesday, 16 May 2017 10:57:46 UTC+3, Val wrote: > > It is not safe to do so and you're understandably asking yourself "but > why? my goroutines are working on different already existing entries, so > what's going on exactly?". > It turns out that a go builtin map is an opaque stucture that i

[go-nuts] Re: Is it ok to separate Open and Close logic?

My dear friend st ov, I think you better have a very compeling reason NOT to use defer, because every Go programmer on Earth will expect the defer pattern in such scenarios. By avoiding defer, code becomes different than the norm and so, harder to understand. The poor reader will keep wondering

[go-nuts] exec.CommandContext wrong behavior

Hi, all. I have some code: ... func RunTimeout(c *exec.Cmd, cnl context.CancelFunc) error { defer cnl() if err := c.Start(); err != nil { return err } return c.Wait() } func main() { ctx, cnl := context.WithTimeout(context.Background(), 10*time.

[go-nuts] Realizing SSD random read IOPS

Hey guys, We wrote this simple program to try to achieve what Fio (linux program) does. Fio can easily achieve 100K IOPS on an Amazon i3.large instance with NVMe SSD. However, with Go we're unable to achieve anything close to that. https://github.com/dgraph-io/badger-bench/blob/master/randread/

[go-nuts] Realizing SSD random read IOPS

I'd start with the execution profile, specially how many goroutines are running concurrently. Your workload may be accidentally sequential due to the interaction between the scheduler and the syspoll background thread. -- You received this message because you are subscribed to the Google Group

[go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Generational and Compact gc have already been thought best practice. But golang doesn't adopt it. Who can tell me the reason? -- 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

Re: [go-nuts] exec.CommandContext wrong behavior

On Tue, May 16, 2017 at 4:56 AM, wrote: > > I have some code: > > ... > > func RunTimeout(c *exec.Cmd, cnl context.CancelFunc) error { >defer cnl() >if err := c.Start(); err != nil { > return err >} > >return c.Wait() > } > > func main() { >ct

Re: [go-nuts] Realizing SSD random read IOPS

On Tue, May 16, 2017 at 4:59 AM, Manish Rai Jain wrote: > > 3 is slower than 2 (of course). But, 2 is never able to achieve the IOPS > that Fio can achieve. I've tried other things, to no luck. What I notice is > that Go and Fio are close to each other as long as number of Goroutines is > <= numbe

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 16, 2017 at 2:01 AM, wrote: > > Generational and Compact gc have already been thought best practice. But > golang doesn't adopt it. Who can tell me the reason? This has been discussed in the past. Ignoring details, the basic advantages of a compacting GC are 1) avoid fragmentation,

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

This is a really great response. I appreciated the high-level overview in one place like this, and I feel like I learned something. Thanks for writing it up, Ian. On Tue, May 16, 2017 at 10:05 AM, Ian Lance Taylor wrote: > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compac

[go-nuts] go generate, go run, and cross compilation with GOOS

Hi everyone, recently, I replaced a script which we used for code generation by a small go program with the same functionality. The reason for this change was that windows failed running the script because it can't interprete the script's shebang and tried to treat it like a compiled executable

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Thanks for the enlightening and interesting reply, Ian. One quick question: do you have a link or a short description of why “modern memory allocation algorithms, like the tcmalloc-based approach used by the Go runtime, have essentially no fragmentation issues”? I was curious, but a quick searc

[go-nuts] Prometheus - NATS Exporter

For those interested, the NATS.io team have released a Prometheus exporter, you can find it here: https://github.com/nats-io/prometheus-nats-exporter Via the readme: *The Prometheus NATS Exporter consists of both a both a package and application that exports NATS server metrics to Prometheus

Re: [go-nuts] exec.CommandContext wrong behavior

On 16 May 2017 at 12:56, wrote: > > [... kill does not kill all the processes ...] Is this normal behavior? It > seems strange. > One moment of enlightenment for me was to discover why CTRL-C at the terminal kills all of the processes, while kill(pid, SIG{whatever}) to the parent process does not

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 16, 2017 at 9:06 AM Ian Lance Taylor wrote: > On Tue, May 16, 2017 at 2:01 AM, wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the reason? > > This has been discussed in the past. > Perhaps, then,

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

The Johnstone / Wilson paper "The memory fragmentation problem: solved?" [1] is the original source. Modern malloc systems including Google's TCMalloc, Hoard [2], and Intel's Scalable Malloc (aka Mcrt Malloc [3]) all owe much to that paper and along with other memory managers all segregate obje

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

See also: Norman R. Nielsen. Dynamic memory allocation in computer simulation. Communications of the ACM, 20(11):864–873, November 1977. This was the first place I saw this result. A later improvement was realizing this allowed headerless BIBOP organization of allocated memory. I think the firs

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

What a fantastic discussion. Thanks so much, folks! -- 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. For more options, vi

[go-nuts] recommended folder structure convention for a cgo static library?

I have a go package foo, it is in $GOPATH/src/github.com/org/foo/ And I want to build a static library for C code to consume the Go library. But in order to do so, the cgo wrapper wrapper.go file needs to be using package main(see https://golang.org/cmd/go/#hdr-Description_of_build_modes , "

Re: [go-nuts] go generate, go run, and cross compilation with GOOS

On Tue, May 16, 2017 at 7:39 AM, wrote: > > recently, I replaced a script which we used for code generation by a small > go program with the same functionality. The reason for this change was that > windows failed running the script because it can't interprete the script's > shebang and tried to

Re: [go-nuts] Realizing SSD random read IOPS

So, I fixed the rand and removed the atomics usage (link in my original post). Setting GOMAXPROCS definitely helped a lot. And now it seems to make sense, because (the following command in) fio spawns 16 threads; and GOMAXPROCS would do the same thing. However, the numbers are still quite a bit of

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Thanks for your patient and wonderful reply. 在 2017年5月16日星期二 UTC+8下午10:06:25，Ian Lance Taylor写道： > > On Tue, May 16, 2017 at 2:01 AM, > wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the reason? > > This ha

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

Thanks for your patient and wonderful reply. 在 2017年5月16日星期二 UTC+8下午10:06:25，Ian Lance Taylor写道： > > On Tue, May 16, 2017 at 2:01 AM, > wrote: > > > > Generational and Compact gc have already been thought best practice. But > > golang doesn't adopt it. Who can tell me the reason? > > This ha

Re: [go-nuts] Realizing SSD random read IOPS

On further thought about GOMAXPROCS, and its impact on throughput: A file::pread would block the OS thread. Go runs one OS thread per core. So, if an OS thread is blocked, no goroutines can be scheduled on this thread, therefore even pure CPU operations can't be run. This would lead to core wastag

Re: [go-nuts] Realizing SSD random read IOPS

> So, if an OS thread is blocked, no goroutines can be scheduled on this thread, therefore even pure CPU operations can't be run. The runtime will spawn a new thread to replace the one that is blocked. On Wednesday, 17 May 2017 13:05:49 UTC+10, Manish Rai Jain wrote: > > On further thought about

Re: [go-nuts] Realizing SSD random read IOPS

> The runtime will spawn a new thread to replace the one that is blocked. Realized that after writing my last mail. And that actually explains some of the other crashes we saw, about "too many threads", if we run tens of thousands of goroutines to do these reads, one goroutine per read. It is obv

[go-nuts] beginner seeks peer review

https://github.com/kbfastcat/nrmetrics if you have any helpful suggestions, I'd appreciate it... 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-n

Re: [go-nuts] Re: go build gives "import .a: not a package file" error

This solution worked for me. Kind of late to the party though. :) On Thursday, 21 August 2014 07:42:52 UTC-4, Dave Cheney wrote: > > Just rm -rf $GOPATH/pkg and you should be fine. > On 21 Aug 2014 21:38, "mark mellar" > > wrote: > >> Thanks for your reply Dave. Unfortunately go install is giv

[go-nuts] Re: Go 1.8.1 is released

Great work! On Saturday, April 8, 2017 at 2:02:49 AM UTC+8, Chris Broadfoot wrote: > > Hi gophers, > > We have just released Go version 1.8.1, a minor point release. > > This release includes fixes to the compiler, runtime, documentation, go > command, and the > crypto/tls, encoding/xml, image/pn

[go-nuts] Re: Delve v1.0.0-rc.1 release

:clap: On Monday, May 8, 2017 at 11:42:43 AM UTC-7, Derek Parker wrote: > > Hey all, > > Just wanted to make some noise about the latest Delve > release, v1.0.0-rc.1 > > . >

[go-nuts] Re: Stop HTTP Server with Context cancel

Will this be OK? func ListenAndServe(ctx context.Context, srv *http.Server) error { ctx,cancel := context.WitchCancel(ctx) wg := sync.WaitGroup{} defer wg.Wait() wg.Add(1) go func(ctx context.Context) { defer cancel() err := srv.ListenAndServe() fmt.Println("Server err is", err)

[go-nuts] humble file watcher

Anyone here can do this... But if you really need a simple file watcher. $ watchfile index.html diff index.html index_old.html This command example will watch file index.html for changes. Once detected run a command diff index.html index_old.html. A command to run can be anything. Is it bareb

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

It's not clear why when you use "a set of per-thread caches" you "lose advantages of bump allocator". At any point of time, a single goroutine is executed on a thread. The points when a goroutine gains and loses the execution context of a thread, and when it is transferred from one thread to ano

Re: [go-nuts] Why golang garbage-collector not implement Generational and Compact gc?

On Tue, May 16, 2017 at 8:27 PM, wrote: > > It's not clear why when you use "a set of per-thread caches" you "lose > advantages of bump allocator". At any point of time, a single goroutine is > executed on a thread. The points when a goroutine gains and loses the > execution context of a threa

Re: [go-nuts] Realizing SSD random read IOPS

On Tue, May 16, 2017 at 8:04 PM, Manish Rai Jain wrote: > > Ideally, the disk reads could be happening via libaio, causing the OS > threads to not block, so all goroutines can make progress, increasing the > number of read requests that can be made concurrently. This would then also > ensure that

Re: [go-nuts] Realizing SSD random read IOPS

On Tue, May 16, 2017 at 9:26 PM, Manish Rai Jain wrote: >> The runtime will spawn a new thread to replace the one that is blocked. > > Realized that after writing my last mail. And that actually explains some of > the other crashes we saw, about "too many threads", if we run tens of > thousands of

Re: [go-nuts] Realizing SSD random read IOPS

Rather than guessing what is going on, I think it's time to break out the profiling tools Manish. On Wed, 17 May 2017, 15:23 David Klempner wrote: > > On May 16, 2017 22:03, "Ian Lance Taylor" wrote: > > On Tue, May 16, 2017 at 9:26 PM, Manish Rai Jain > wrote: > >> The runtime will spawn a ne