0
Oh, we do also heavily parallelize. This blog post is just focusing on the single-core perf.
From the mouth of this post's author: yes.
Definitely possible! However, I prefer to avoid cgo wherever possible for more than just the overhead. In my experience: - It complicates builds by requiring a C toolchain - It makes single, static binaries more…
AFAICT, that still doesn't support 8-bit integer dot product? (To clarify, I was using int8 to mean 8-bit integer, not 8-byte)
Copying in a response to a similar question on Reddit: I should really add some discussion around BLAS in particular, which has an good implementation[0] of the float32 dot product that outperforms any of the float32…
I did consider Avo! I even went as far as to implement a version using Avo since it has a nice dot product example I could use as a starting point. But ultimately, for as small as these functions are, I felt that Avo…
Thanks for the feedback! > Will that end up on Github? It's already there! I just haven't cut a release since the change. > Most often I want to return just the first error. In many cases, I do too, which is why…
> nice work Thanks! > The default concurrency GOMAXPROCS is almost never what I want. FWIW, the default concurrency has been changed to "unlimited" since the 0.1.0 release. > Aggregated errors are almost never what I…
Fair criticism. The nice thing about the current API is it works with any input that's iterable (channels, slices, readers, etc.) and any output (callback, channel, append to slice, etc.). In most code I write, I avoid…
> panics aren't "goroutine scoped" in terms of their potential impact I'm with ya there. However, there are also many classes of logic errors that are not goroutine-scoped. And there are many panics that do not have…
> run different things in the background and gather the results in different ways I'd be curious to see an example of the type of task you want to be able to do more safely
> The WaitGroup looks suspiciously like errgroup I heavily used errgroup before creating conc, so the design is likely strongly influenced by that of errgroup even if not consciously. Conc was partially built to address…
Whoops, yep, thanks for pointing it out. Just fixed it
Nope, just a catchy short form of "concurrent"
This is exactly correct. Behavior is equivalent, performance is not. It's probably still not a great example because if reading from a channel already, you're probably better off spawning 10 tasks that read off that…
Hi! Author here. Conc is the result of generalizing and cleaning up an internal package I wrote for use within Sourcegraph. Basically, I got tired of rewriting code that handled panics, limited concurrency, and ensured…
My favorite project to give kids who are just dipping their toes in the water is a Madlib. It prompts you for the blank words, then prints out the complete story with the blanks filled.
The flexibility of Fluentd and the community around it are great, but ultimately the resource intensity proved to be too high and too unpredictable for our use case. We ended up building our own general purpose log…
0
Oh, we do also heavily parallelize. This blog post is just focusing on the single-core perf.
From the mouth of this post's author: yes.
Definitely possible! However, I prefer to avoid cgo wherever possible for more than just the overhead. In my experience: - It complicates builds by requiring a C toolchain - It makes single, static binaries more…
AFAICT, that still doesn't support 8-bit integer dot product? (To clarify, I was using int8 to mean 8-bit integer, not 8-byte)
Copying in a response to a similar question on Reddit: I should really add some discussion around BLAS in particular, which has an good implementation[0] of the float32 dot product that outperforms any of the float32…
I did consider Avo! I even went as far as to implement a version using Avo since it has a nice dot product example I could use as a starting point. But ultimately, for as small as these functions are, I felt that Avo…
Thanks for the feedback! > Will that end up on Github? It's already there! I just haven't cut a release since the change. > Most often I want to return just the first error. In many cases, I do too, which is why…
> nice work Thanks! > The default concurrency GOMAXPROCS is almost never what I want. FWIW, the default concurrency has been changed to "unlimited" since the 0.1.0 release. > Aggregated errors are almost never what I…
Fair criticism. The nice thing about the current API is it works with any input that's iterable (channels, slices, readers, etc.) and any output (callback, channel, append to slice, etc.). In most code I write, I avoid…
> panics aren't "goroutine scoped" in terms of their potential impact I'm with ya there. However, there are also many classes of logic errors that are not goroutine-scoped. And there are many panics that do not have…
> run different things in the background and gather the results in different ways I'd be curious to see an example of the type of task you want to be able to do more safely
> The WaitGroup looks suspiciously like errgroup I heavily used errgroup before creating conc, so the design is likely strongly influenced by that of errgroup even if not consciously. Conc was partially built to address…
Whoops, yep, thanks for pointing it out. Just fixed it
Nope, just a catchy short form of "concurrent"
This is exactly correct. Behavior is equivalent, performance is not. It's probably still not a great example because if reading from a channel already, you're probably better off spawning 10 tasks that read off that…
Hi! Author here. Conc is the result of generalizing and cleaning up an internal package I wrote for use within Sourcegraph. Basically, I got tired of rewriting code that handled panics, limited concurrency, and ensured…
My favorite project to give kids who are just dipping their toes in the water is a Madlib. It prompts you for the blank words, then prints out the complete story with the blanks filled.
The flexibility of Fluentd and the community around it are great, but ultimately the resource intensity proved to be too high and too unpredictable for our use case. We ended up building our own general purpose log…