zlacker

[parent] [thread] 1 comments
1. gnabgi+(OP)[view] [source] 2023-01-23 06:52:02
Granted I don't know what will happen between now and March 1st, but there are some inaccuracies in this article... is this a GPT product?

- Encoding Machine Code[0] Not sure what "Go assembly provides three instructions for representing binary machine code" is intended to mean, but go supports register moves/actions for Byte(1)/Word(2)/Long(4)/Quad(8)/Octo(16), both aligned and unaligned (depending on architecture/processor). The next section literally references a quad action (`movq`). Note O/Octo and DQ/Double Quad mean the same thing depending on instruction/arch (sigh)

- When you're using specialized features you have other commands for larger register features (eg in AVX512 on AMD64 asm:`MULPS`, goasm:`VMULPS`)

- Redirect Jump Instruction[1], what is the value of this conversion recommendation if this article is recommending an auto converter that should do this for you? Go-asm can support jumping to addresses (routine scoped), or labels.. labels can be in any case, perhaps goat requires only upper case?

- Generate Go Function Definitions[2].. err isn't this the value prop of goat[3], the point of this article, that this can be done for you? Why are `cznic`, and `cc` being introduced here?

- Function Calls[4] The "complete wrapper" won't compile (typos), I think it's supposed to be closer to [5] (in the repo)

- Function Calls[4] the "Note" makes no sense given the code is go only (missing go-asm paste?)

- The summary benchmark[6], demonstrates AVX2 (far more common) is often faster, and doesn't explain what was measured, nor on what architecture, whether it was aligned, whether any steps were taken to improve performance on the architecture. Based on the repo [7], there's no attempt at alignment, if you can't do AVX512, or AVX2, you can still do 64bit/quad operations rather than going straight to 8bit/byte ops.

- The assembly (.s) files seemingly produced by GOAT[8] are far from human readable go-asm files (the comments in the file could be go-asm source code), don't follow the convention of <file>_<arch>.s, and don't support all platforms that C/golang do (although ARM64 & AMD64 is a large market share)

[0]: https://gorse.io/posts/avx512-in-golang.html#encoding-machin... [1]: https://gorse.io/posts/avx512-in-golang.html#redirect-jump-i... [2]: https://gorse.io/posts/avx512-in-golang.html#generate-go-fun... [3]: https://github.com/gorse-io/gorse/tree/master/cmd/goat [4]: https://gorse.io/posts/avx512-in-golang.html#function-calls [5]: https://github.com/gorse-io/gorse/blob/master/base/floats/fl... [6]: https://gorse.io/posts/avx512-in-golang.html#summary [7]: https://github.com/gorse-io/gorse/tree/master/base/floats [8]: https://github.com/gorse-io/gorse/blob/master/base/floats/fl...

replies(1): >>zhengh+N4
2. zhengh+N4[view] [source] 2023-01-23 07:58:04
>>gnabgi+(OP)
Thanks, @gnabgib. Your comment is very insightful and reminds me of my mentor correcting my academic paper. The post introduces the basic idea of using AVX512 in Go by writing C codes. There are mistakes and many details are omitted. A complete example is https://github.com/gorse-io/gorse/tree/master/base/floats
[go to top]