Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🥳 awesome & some rough edges fuond #1

Open
Licenser opened this issue Aug 23, 2024 · 4 comments
Open

🥳 awesome & some rough edges fuond #1

Licenser opened this issue Aug 23, 2024 · 4 comments

Comments

@Licenser
Copy link
Contributor

Licenser commented Aug 23, 2024

First of all, this is some truely inspired and awesome work. Thank you!

I saw it and had to give it a spin with simd-json, the results are great and I haven't even gotten it through everything. You definitely are onto something with thins, especially for applications like json parsing where there are tight loops and small functions with results this seems to do wonders!

While adding iex I ran into a few snags, most of them I could work around one I couldn't. I figured even with this being experimental and new it wouldn't hurt to report them :)

@Licenser
Copy link
Contributor Author

adding one, the iex attribute invalidates other features it seems:
image

@purplesyringa
Copy link
Member

purplesyringa commented Aug 23, 2024

return's of other iex functions seem not to work directly but need a layer of indirection over ? and OK

Yes. When two return's are used in the function, their types have to match, but #[iex] Result is an opaque type, so that's not the case. This can be mitigated once Rust 2024 arrives.

Ok's with complex content doesn't get translated

Strange. I'll take a look. Something to do with type inference maybe?

constructing an err in a macro isn't recognized and requires inlining

Weird, I'll take a look.

? in macros aren't recognized (this I couldn't work around)

There was an iex_try! macro that worked like ? but also in macros. I removed it because it was unsound. I have since found a way to make it sound, so I'm going to introduce it back.

adding one, the iex attribute invalidates other features it seems:

Oops. That should be easy to fix, will do.

Thank you for your attempt to use this in a real project! And thanks for great feedback too. I'll iterate on this in the next few days.

@Licenser
Copy link
Contributor Author

Licenser commented Aug 24, 2024

Thank you for the great work and kind response :), even in its current state, I'd roll that out as an opt-in feature for all simd-json internals; it's just that good :D I'm super eager to see the final gains when the string parsing can be iex-ified as well as they happen so darn often o.o

edit: I'll try to make minimal examples as a PR for some of the things, it's probably a lot easier to look at then a whole lot of simd-json code ;)

@Licenser
Copy link
Contributor Author

Licenser commented Aug 24, 2024

Ok's with complex content doesn't get translated

was a false positive, some other part of the function temporary needed me to change that , I Could roll it back

constructing an err in a macro isn't recognized and requires inlining

smae

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants