avo
laser
avo | laser | |
---|---|---|
10 | 6 | |
2,598 | 261 | |
- | 1.5% | |
7.0 | 3.6 | |
about 1 month ago | 4 months ago | |
Go | Nim | |
BSD 3-clause "New" or "Revised" License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
avo
-
From slow to SIMD: A Go optimization story
I wonder whether avo could have been useful here?[1] I mention it because it came up the last time we were talking about AVX operations in go.[2]
1 = https://github.com/mmcloughlin/avo
2 = https://news.ycombinator.com/item?id=34465297
- Portable Efficient Assembly Code-Generator in Higher-Level Python (PeachPy)
-
How to Use AVX512 in Golang
I thought the /r/golang comments on this post were pretty useful[1]. They also introduced me to avo[2], a tool for generating x86 assembly from go that I hadn't seen before. There are some examples listed on the avo github page for generating AVX512 instructions with avo.
1 = https://www.reddit.com/r/golang/comments/10hmh07/how_to_use_...
2 = https://github.com/mmcloughlin/avo
For writing AVX512 from scratch avo is a much better alternative.
-
SIMD Accelerated vector math
Avo is a library that simplifies writing complex go assembly, I found it very useful to figure out how instructions map onto Go's asm syntax. But you could definitely do the translation directly, it's what c2goasm did (couldn't get it to work reliably unfortunately).
-
HaxMap v0.2.0 released, huge performance improvements and added support for 32-bit systems
Curious if you're looking at using avo to write the assembly
-
HaxMap, a concurrent hashmap faster and more memory-efficient than golang's sync.Map
You can use github.com/mmcloughlin/avo for generating the assembly use Go.
-
S2: Fully Snappy compatible compression, faster and better
For normal and "better" mode I am using avo to generate different encoders for different input sizes, with and without Snappy compatibility. That currently outputs about 17k lines of assembly.
-
Branchless Coding in Go (Golang)
You could perhaps just have the Go compiler generate the assembler for your code:
go tool compile -S file.go > file_amd64.s
Then you could verify it doesn't change over time, and choose to begin maintaining by hand if it makes sense.
If you do want to go the route of rolling it yourself, I'd suggest looking into something like Avo: https://github.com/mmcloughlin/avo
-
High precision timer loop.
If you have to go with Assembly, try Avo https://github.com/mmcloughlin/avo
laser
-
From slow to SIMD: A Go optimization story
It depends.
You need 2~3 accumulators to saturate instruction-level parallelism with a parallel sum reduction. But the compiler won't do it because it only creates those when the operation is associative, i.e. (a+b)+c = a+(b+c), which is true for integers but not for floats.
There is an escape hatch in -ffast-math.
I have extensive benches on this here: https://github.com/mratsim/laser/blob/master/benchmarks%2Ffp...
-
Benchmarking 20 programming languages on N-queens and matrix multiplication
Ah,
It was from an older implementation that wasn't compatible with Nim v2. I've commented it out.
If you pull again it should work.
> Anyway the reason for your competitive performance is likely that you are benchmarking with very small matrices. OpenBLAS spends some time preprocessing the tiles which doesn't really pay off until they become really huge.
I don't get why you think it's impossible to reach BLAS speed. The matrix sizes are configured here: https://github.com/mratsim/laser/blob/master/benchmarks/gemm...
It defaults to 1920x1920 * 1920x1920. Note, if you activate the benchmarks versus PyTorch Glow, in the past it didn't support non-multiple of 16 or something, not sure today.
Packing is done here: https://github.com/mratsim/laser/blob/master/laser/primitive...
And it also support pre-packing which is useful to reimplement batch_matmul like what CuBLAS provides and is quite useful for convolution via matmul.
-
Why does working with a transposed tensor not make the following operations less performant?
For convolutions: - https://github.com/numforge/laser/blob/e23b5d63/research/convolution_optimisation_resources.md
-
Improve performance with SIMD intrinsics
You can train yourself on matrix transposition first. It's straightforward to get 3x speedup between naive transposition and double loop tiling, see: https://github.com/numforge/laser/blob/d1e6ae6/benchmarks/transpose/transpose_bench.nim#L238
What are some alternatives?
sonic - A blazingly fast JSON serializing & deserializing library
Arraymancer - A fast, ergonomic and portable tensor library in Nim with a deep learning focus for CPU, GPU and embedded devices via OpenMP, Cuda and OpenCL backends
sha256-simd - Accelerate SHA256 computations in pure Go using AVX512, SHA Extensions for x86 and ARM64 for ARM. On AVX512 it provides an up to 8x improvement (over 3 GB/s per core). SHA Extensions give a performance boost of close to 4x over native.
nim-sos - Nim wrapper for Sandia-OpenSHMEM
dingo - Generated dependency injection containers in go (golang)
ParallelReductionsBenchmark - Thrust, CUB, TBB, AVX2, CUDA, OpenCL, OpenMP, SyCL - all it takes to sum a lot of numbers fast!
rjson - A fast json parser for go
analisis-numerico-computo-cientifico - Análisis numérico y cómputo científico
gorse - Gorse open source recommender system engine
blis - BLAS-like Library Instantiation Software Framework
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
JohnTheRipper - John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs [Moved to: https://github.com/openwall/john]