ohr

(Author here) yes! I also wrote about this (specifically in Python->Rust FFI) in another article:

https://ohadravid.github.io/posts/2023-03-rusty-python/#v2--...

(Author here) thanks! Even as an experienced Rust developer, this is a lot of syntax which is part of what makes it archaic I think.

As usual with Rust most of it is due to inherent complexity: for example, when you deal with raw pointers, you need to specify if they are const or mut, and you must have a syntax that’s not &, and not too wordy: so * is a good choice (might be changed to &raw in the future!). And if you want to say that something is generic and the generic parameter is a pointer… you just end up with a lot of syntax.

But if you let it run the tests, it’ll just do that on its own (or delete the tests, but usually it won’t), which is very useful and seems to match the article’s sentiment.

Used the Save Page WE Chrome extension to capture the html (after cleaning up with inspect element + delete), and added a bit of custom JavaScript to scroll everything to the right place. Needed the extension for the styling to be captured correctly.

(Author here) I'm a huge fan of the "How to speed up the Rust compiler" series! I was hoping to capture the same feeling :)

I think that since the 1.5% one is only for aarch64 it's a bit unfair to claim the full number, more like 1/2 if you consider arm/x86 to be the majority of the (future) deployments

Thanks! Would be interesting to see if Rust/LLVM folks can get the compiler to apply this optimization whenever possible, as Rust can be much more accurate w.r.t memory initialization.

(Author here) Thanks! That's useful feedback.

I also agree - the final article isn't skim-friendly enough, which drives away some readers.

In WMI, the fields are lazy loaded when you do a `*` query, but the real crate [does use the same Serde reflection tricks](https://github.com/ohadravid/wmi-rs/blob/main/src/query.rs#L...) to create the correct field list when you query a struct which improves perf a lot!

> don't you have to get your version's struct data member type correct

No, since Serde will happyly fill a `u64` field with any other `u{8,16,32}` value, and even with signed types (as long as the actual value is non-negative) - this is sort of what happens when you deserialize a JSON `[1, 2, 3]` into `[u64]`.

That's understandable, but I think it depends on how many different structs like this you have and how many fields you need to work with (for our usecase, we had tens of structs with tens of fields each).

There's also an Alternatives section in the article about other approaches that can achieve similar results, but of course 'do nothing' is also a valid option.

Edit: > If actually concerned about the need to know UI8 ..

Just a small note: even if you don't care about the fact that it's a UI8, you still have to use the correct type. For example, if the field happens to be returned as UI4, this code won't work!

(Author here) I needed to do a bit of "reflection" in a Rust crate but didn't want to implement a procedural macro, so I used Serde (which is a (de)serialization crate) instead.

This is also a deep dive into Serde internals - hope you'll like it!

Thanks, I hate it! Jk, but would you consider this a good solution overall?

well yes! also calling an answer which mentions c++ as well “off-topic”, it’s not like I wrote a haiku about marmalade.

And why insist on deleting if people found it useful? It’s literally at the bottom of the page, so it’s not a public menace or anything.

The magic for HN! Added this link to the post as well, thanks!

(author here): on the contrary, my point is that I was wrong(ish), and I often think about that before I get angry at other people on the internet.

The other point is that there's (usually) no need to choose between good moderation and civility, and at least IMO "blatantly off-topic and should be deleted" really fails at being civil.

author here: but do you find the article helpful in making you less angry?

also:

> I'd be angry all the time if I was coding C or C++ or C/.C++ or C-- or anything to do with C

lol

Author here: actually, in this analogy (as this is just a demo library), the polygons change each time so we couldn't use this type of optimization (at least not in a straightforward way).

Author here:

For the original library we did all the numpy tricks we could think of, but we really needed to do this type of exhaustive search for some of the data.

If someone wants to open a PR with a "fully optimized" numpy code, that would be very cool just for comparison :)

Author here: I agree, that's a great perf advice (esp. when you can restructure your code).

I couldn't get into a this in the article (would be too long), but this is a great point and the original library does this in a lot of places.

One problem in our use case is that the actual structs members are pretty big & that we need to group/regroup them a lot.

The fastest approach for us was to do something like in the article for the initial filtering, then build a hashmap of SoAs with the needed data, and do the heavier math on that.