camdencheek

7 ms·

1.
by camdencheek 5mo ago
0
2.
by camdencheek 3y ago
Oh, we do also heavily parallelize. This blog post is just focusing on the single-core perf.
3.
by camdencheek 3y ago
From the mouth of this post's author: yes.
4.
by camdencheek 3y ago
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 difficult - It makes portabi
5.
by camdencheek 3y ago
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)
6.
by camdencheek 3y ago
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 implementations in the
7.
by camdencheek 3y ago
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 was an unnecessary extr
8.
by camdencheek 4y ago
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 (*pool).With
9.
by camdencheek 4y ago
> 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 want
10.
by camdencheek 4y ago
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 channels because
11.
by camdencheek 4y ago
> 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 i
12.
by camdencheek 4y ago
> 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
13.
by camdencheek 4y ago
> 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 the shortcomings
14.
by camdencheek 4y ago
Whoops, yep, thanks for pointing it out. Just fixed it
15.
by camdencheek 4y ago
Nope, just a catchy short form of "concurrent"
16.
by camdencheek 4y ago
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 channel, but t
17.
by camdencheek 4y ago
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 goroutine cleanup. Ha
18.
by camdencheek 6y ago
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.
19.
by camdencheek 6y ago
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 parser in Go to support o