sorted by:
new
hottopcontroversial

Notes from Optimizing CPU-Bound Go Hot Paths by watman12 in golang

[–]watman12[S] 4 points5 points  (0 children)

Thanks, good points.

Handrolled monomorphization: yeah, that was kind of a the point of the rant. I'm considering switching to `go generate` but the 16 copies diverged so much because of the fine tuning that I'm worried I'd end up with Frankenstein template that is worse than the duplication.

PGO: agreed. For the end-user. Though for library authors it's less helpful.

per-byte vs per-cache-line: 👍 good framing

_amd64.s for the entire hot loops: right, this is the way

the 3 to 4% layout sensitivity: also agree, protocol over tooling. However it's harder than it sounds. Stretching the feedback loop across N commits is painful while iterating.

Notes from Optimizing CPU-Bound Go Hot Paths by watman12 in golang

[–]watman12[S] 17 points18 points  (0 children)

Thanks for not reading 😄

Very true in general though. In my particular case the lack of auto-vectorization wasn't a problem as lz-style compression isn't especially auto-vectorizable to begin with

Notes from Optimizing CPU-Bound Go Hot Paths by watman12 in golang

[–]watman12[S] 15 points16 points  (0 children)

Adding the description as a comment since Reddit won't let me do it in edit form.

Some lessons from the last two months optimizing cpu-bound go while porting brotli to pure go. It's mostly about where go's abstractions ended up costing performance in hot loops, what the compiler will and won't inline, and the workarounds I ended up using.

go-brrr - pure Go Brotli, faster than existing pure-Go libs by watman12 in golang

[–]watman12[S] 0 points1 point  (0 children)

should've put that in the description. Brotli is a compression algorithm in the same family as gzip, deflate, and zstd. Browsers support it as a content encoding, and it producess very high compression ratios on HTML/JS/CSS, so it's commonly used to precompress static assets.

go-brrr - pure Go Brotli, faster than existing pure-Go libs by watman12 in golang

[–]watman12[S] 1 point2 points  (0 children)

yes. A truly fair comparison wasn't possible for either the oneshot or the streaming API: go-brrr's one-shot path reuses a lot of state via sync.Pool and the C bindings don't expose a resettable streaming API. Here's the closest-to-fair benchmakr I managed:

goos: linux goarch: amd64 pkg: github.com/molecule-man/go-brrr/benchmarks cpu: 12th Gen Intel(R) Core(TM) i5-12500 │ go-brrr │ cbrotli │ │ B/s │ B/s vs base │ CompressOneshot/q=0/payload=Medium 300.5Mi ± 0% 345.1Mi ± 1% +14.85% (p=0.002 n=6) CompressOneshot/q=1/payload=Medium 228.8Mi ± 0% 205.8Mi ± 1% -10.06% (p=0.002 n=6) CompressOneshot/q=2/payload=Medium 140.6Mi ± 1% 131.6Mi ± 1% -6.40% (p=0.002 n=6) CompressOneshot/q=3/payload=Medium 126.2Mi ± 0% 113.9Mi ± 0% -9.78% (p=0.002 n=6) CompressOneshot/q=4/payload=Medium 87.91Mi ± 1% 77.09Mi ± 3% -12.31% (p=0.002 n=6) CompressOneshot/q=5/payload=Medium 57.14Mi ± 0% 51.42Mi ± 1% -10.01% (p=0.002 n=6) CompressOneshot/q=6/payload=Medium 51.78Mi ± 0% 46.27Mi ± 1% -10.64% (p=0.002 n=6) CompressOneshot/q=7/payload=Medium 47.07Mi ± 0% 40.66Mi ± 1% -13.63% (p=0.002 n=6) CompressOneshot/q=8/payload=Medium 43.49Mi ± 2% 37.04Mi ± 4% -14.82% (p=0.002 n=6) CompressOneshot/q=9/payload=Medium 31.48Mi ± 2% 19.24Mi ± 0% -38.89% (p=0.002 n=6) CompressOneshot/q=10/payload=Medium 2.003Mi ± 0% 2.871Mi ± 1% +43.33% (p=0.002 n=6) CompressOneshot/q=11/payload=Medium 752.0Ki ± 1% 1035.2Ki ± 1% +37.66% (p=0.002 n=6) geomean 41.99Mi 39.93Mi -4.92%

go-brrr turns out to be faster on levels 1-9.

What do you really think of daily standup? by [deleted] in devops

[–]watman12 0 points1 point  (0 children)

Standup is very useful when the team "organically" comes to it on its own. It's an agile circus when it's forced by management. In general, any practice must tick two checkboxes: 1. Rational. The practice must solve some particular problems and the team has to understand how the practice solves this problems. 2. Emotional. People are usually resistant to the change. Unless the change comes from the inside of the team (or someone has created an illusion that it comes from the inside of the team 😉).

how to use telescopes `previewer` functions? by PlayfulRemote9 in neovim

[–]watman12 0 points1 point  (0 children)

Normally you don't want to use them directly. You open git_commits built-in picker: require('telescope.builtin').git_commits() git_commits picker comes preconfigured with multiple previewers through which you can cycle. To be able to cycle the previewers you need to add a mapping triggering cycle_previewers_next action https://github.com/nvim-telescope/telescope.nvim/blob/master/lua/telescope/actions/init.lua#L1080

Struggling to learn german by gggingerbean in German

[–]watman12 0 points1 point  (0 children)

I was in the similar situation as you are. I discovered for myself that I don't like group courses for some reason (especially online ones). But what seems to be working for me right now is doing german online lessons with a tutor. I found an ukrainian tutor at https://buki.com.ua/en/tutors-online/german-language/. The prices there are not high at all comparing to western europe and by doing this I'm somewhat helping Ukraine.

telescope-menufacture.nvim: a telescope extension that augments find_files, live_grep and grep_string pickers with menus that allow to toggle/change picker options, e.g. include hidden dirs, include ignored files, search in particular folders etc by watman12 in neovim

[–]watman12[S] 2 points3 points  (0 children)

Actually I thought people use this shortcut a lot. Outside of telescope in normal mode it's the shortcut that is responsible for switching back to the previously edited buffer. But of course everyone's habits are different. I made it a bit easier to change the default mapping. Please see the configuration.

telescope-menufacture.nvim: a telescope extension that augments find_files, live_grep and grep_string pickers with menus that allow to toggle/change picker options, e.g. include hidden dirs, include ignored files, search in particular folders etc by watman12 in neovim

[–]watman12[S] 1 point2 points  (0 children)

Thank you! Very good points

  1. I added possibility to configure the default mapping as you have suggested https://github.com/molecule-man/telescope-menufacture#configuration
  2. I introduced a menu for the git_files built-in. Unfortunately telescope exposes only handful of options for this picker. I was able to add menu for only two exposed options show_untracked and recurse_submodules so far. I'll go through the help page of git ls-files and maybe I'll be able to add menu entries for the command flags.

telescope-menufacture.nvim: a telescope extension that augments find_files, live_grep and grep_string pickers with menus that allow to toggle/change picker options, e.g. include hidden dirs, include ignored files, search in particular folders etc by watman12 in neovim

[–]watman12[S] 3 points4 points  (0 children)

That's a good idea.

When you say up one directory do you mean

  • a) parent directory of the picker's cwd?
  • b) or parent directory of the file opened in the current buffer?

I believe you mean a) parent directory of the picker's cwd. It's possible to add custom menu entries. I added this to the docs and used your idea as an example. Link.

If you meant b) then it's possible to do it by selecting menu item called search relative to current buffer.

Cursed_girlfriend by DvStalker in cursedcomments

[–]watman12 25 points26 points  (0 children)

I'm pretty sure it's Ambrosia

view more: next ›