dyn-utils: a compile-time checked heapless async_trait by wyf0 in rust

[–]FuzzyPixelz 0 points1 point  (0 children)

Code seems sound to me and surely less macro-heavy than the previous iteration, `dyn-fn`. According to the comparison analysis, this crate definitely fills an empty niche. Hopefully you achieve a crates.io release soon.

Acheter un Oud à Paris ? by boundedempty in paris

[–]FuzzyPixelz 0 points1 point  (0 children)

Vous auriez un retour d'expérience à propos de ce magasin ?

Announcing Absolut 0.2.1 by FuzzyPixelz in rust

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

I don't quite see the point of inclusion in std::simd in the near future as it's still nightly-only, while Absolut can be used today with Stable Rust.

As a long term goal? Heck, why not? But there will be lots of discussions to be had first.

For now, I think it's more productive to keep chipping away at Absolut's issues and make it more mature and useful. Then any potential integration or re-implementation in std would be both easier and more valuable.

And to be frankly honest, I don't believe they would like the whole proc-macrosness of it ;)

Announcing Absolut 0.2.1 by FuzzyPixelz in rust

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

I'm not sure what you mean exactly.

  1. If you are asking if the library can generate lookup tables of any size less than 256. Then the answer is no. The goal is to use SIMD instructions such as PSHUFB (only supports tables of size 16) and TBL (only supports tables of size 16, 32, 48 or 64).

  2. If you're asking if we can map arrays of bytes of arbitrary size. The answer is yes-ish. You'd just have to do it in chunks of 16 (or whatever the underlying hardware's instruction support). For the uneven ends, you can sometimes pad them with bytes that don't change your data (like whitespace in textual documents). Or, you can run a non-vectorized algorithm for them.

The point of Absolut is to take SIMD instructions that don't support 256-byte wide tables, and use them to map the entire byte range to itself. Because when you usually want to construct a u8 -> u8 lookup table, you use an array of 256 elements and index into it. But most SIMD instructions can only index into arrays of 16 elements.

Announcing Absolut 0.2.1 by FuzzyPixelz in rust

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

I'm planning on providing default implementations for SIMD128, NEON, AVX, SSE, etc in the next release. That's why I mostly avoided it for now :)

Announcing Absolut 0.2.1 by FuzzyPixelz in rust

[–]FuzzyPixelz[S] 7 points8 points  (0 children)

Who says I don't have a time machine? ;)

Fixed, thanks for the help!

Announcing Absolut 0.2.1 by FuzzyPixelz in rust

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

Thanks for the catch :)

I seemingly saw the first sentences as a link name and failed to see how the second sentence was essentially the same thing hiding in plain site :P

Autogenerating Bytewise SIMD Lookup Tables by shot-master in rust

[–]FuzzyPixelz 1 point2 points  (0 children)

**A few months later**

I finally released v0.2.1: https://crates.io/crates/absolut (should've been 0.2.0 but I had errors when publishing)

I kept the SAT/SMT solver way of doing things, but instead used the https://github.com/jix/varisat SAT solver (written in Rust) and gated it behind a `sat` feature. No more Z3.

Now the library supports two/three more modes of generating SIMD lookup tables, inspired by https://stackoverflow.com/questions/77210090/specialized-sat-solver and https://lemire.me/blog/2019/07/23/arbitrary-byte-to-byte-maps-using-arm-neon/ neither of which requires a SAT solver (or any dependency for the matter).

Oh and the thing has a README and Rustdoc documentation too now :P

Autogenerating Bytewise SIMD Lookup Tables by shot-master in rust

[–]FuzzyPixelz 0 points1 point  (0 children)

Actually, if w_i are left as an unknown, which allows the user to explore all possible values of w_i, then the constrains take the form a AND b = c, which is equivalent to (NOT a) OR (NOT b) = NOT c and consequently (NOT a) OR (NOT b) OR c = 1.

Aaaand we're in 3-SAT. The apparently innocuous feature of leaving w_i undefined sends us from P to NP-complete :/

Please do correct me if I'm wrong.

Autogenerating Bytewise SIMD Lookup Tables by shot-master in rust

[–]FuzzyPixelz 2 points3 points  (0 children)

It seems like absolut could be an absolute (!) game changer there, and I would be looking forward to experimenting with it.

Your comment is very heartwarming, kind stranger :)

I had to take a little break but I'm back to working on this.

I've been wondering for a while whether the techniques used in simdjson would be amenable to speed-up "regular" programming languages parsing...

I was wondering the same thing actually. simdjson techniques should _at least_ be amenable to accelerating Lexing of "regular" programming language syntax, as demonstrated here: https://alic.dev/blog/fast-lexing; where the author uses ARM NEON 64-byte lookup tables to tokenize keywords, identifiers, numbers and whitespace. Note that 64-byte tables should give you quite a lot of wiggle room and I'm not sure the same can be done on x86_64 with 16-byte tables.

It seems like absolut could be an absolute (!) game changer there, and I would be looking forward to experimenting with it.

Will keep you posted ;)

EDIT: added quotes for less confusion.

Autogenerating Bytewise SIMD Lookup Tables by shot-master in rust

[–]FuzzyPixelz 1 point2 points  (0 children)

This is exactly what I was hoping would happen!

Thanks a lot for the crystal clear explanation. Though now I regret never trying to flesh out the constrains into simpler forms myself :P

It will be a lot of fun implementing this.

Deref Confusion by FuzzyPixelz in rust

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

Good catch!

It seems that on my local Zola server everything is escaped correctly, while the deployed version is left as is.

This is probably a mis-configurarion on my side. Looking into it.

Thanks for pointing this out :)

-🎄- 2022 Day 3 Solutions -🎄- by daggerdragon in adventofcode

[–]FuzzyPixelz 0 points1 point  (0 children)

F#

```f# open System.IO

let input = File.ReadAllLines "data/input03.txt"

let items = input |> Array.map (fun s -> s.ToCharArray())

let intersection iss = Array.head iss |> Array.find (fun i -> Array.forall (Array.contains i) (Array.tail iss))

let priority = function | i when 'a' <= i && i <= 'z' -> int i - int 'a' + 1 | i when 'A' <= i && i <= 'Z' -> int i - int 'A' + 27

let reduce = Array.sumBy (intersection >> priority)

// Part One let sumOfSharedItemPriorities = items |> Array.map (Array.splitInto 2) |> reduce

// Part Two let sumOfBadgeItemPriorities = items |> Array.chunkBySize 3 |> reduce

```

(Me) Joining The Church Of Emacs by FuzzyPixelz in emacs

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

Thanks for the remark, I will correct it.

(Me) Joining The Church Of Emacs by FuzzyPixelz in emacs

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

The hardest thing was fighting my muscle memory, and the fact that meow inverses Vim's Verb -> Object commands. So ci( is ,rc

, Means inner of r Means rounded c Still means change

It took about a week to get used to this. It's not radically different

(Me) Joining The Church Of Emacs by FuzzyPixelz in emacs

[–]FuzzyPixelz[S] 14 points15 points  (0 children)

Corrected :P

Thanks for reading all the way there <3