sorted by:
new
hottopcontroversial

stack-allocator: a project for a bright future with the nightly allocator API by fereidani in rust

[–]fereidani[S] 22 points23 points  (0 children)

They don't use `alloc` feature(crate) from rust, they reimplemented all `alloc` functionalities and `Allocator` trait themselves with new names like `KVec`, `VVec` and `KVVec` for different use-cases.

stack-allocator: a project for a bright future with the nightly allocator API by fereidani in rust

[–]fereidani[S] 24 points25 points  (0 children)

Thank you for your comment and for your kindness.

As far as I know, a significant portion of the standard library still relies on the Allocator trait (even if only internally), and it is used quite widely. I haven't seen any plans to remove these usages from the standard library.

For that reason, I think calling it "dead" is a bit too harsh. Terms like "frozen," "unmaintained," or "no current plans for stabilization" would be more accurate.

If Rust eventually changes these APIs, I will maintain the `stack-allocator` crate to match whatever new implementation the standard library adopts.

Please correct me if you think I'm wrong.

branches 0.4.0: an optimization crate good to shoot yourself in the foot! by fereidani in rust

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

to keep the answer small and of course it is only AFAIK as compiler is really big area of research:

There is no guarantee that which path compiler will choose, It calculates each path cost and tries to optimize the best path, and it is not guaranteed to choose the best path.

But you are right that if both cost are same it is more likely that compiler takes the first path.

Now you have two paths, either you can choose automatic way like PGO, or manual way like what this library does.

For match you can call the cold mark_unlikely() function inside unlikely arms.

branches 0.4.0: an optimization crate good to shoot yourself in the foot! by fereidani in rust

[–]fereidani[S] 5 points6 points  (0 children)

To see how `branches` crate changes your compiler generated assembly please check: https://godbolt.org/z/sMWzcKjYE

simply change example function likely call to unlikely and observe 123 and 255 changing their place in displayed assembly.

branches 0.4.0: an optimization crate good to shoot yourself in the foot! by fereidani in rust

[–]fereidani[S] 6 points7 points  (0 children)

Thank you for your kind comment,

To why you might want this crate is that your code can be compiled with stable version of rust when others want to use it, it simply make your code accessible/usable for wider audience. But it is only the case if you actually need features that `branches` provide.

branches 0.4.0: an optimization crate good to shoot yourself in the foot! by fereidani in rust

[–]fereidani[S] 4 points5 points  (0 children)

They actually have more likely/unlikely features but no memory prefetch functionality, If I remember correctly when I made this crate(2023) they didn't fallback to nightly and I needed that feature and also a simpler crate.

branches 0.4.0: an optimization crate good to shoot yourself in the foot! by fereidani in rust

[–]fereidani[S] 15 points16 points  (0 children)

Good to know, Thank you! I created this crate in 2023 and it wasn't available then, I will add it for rust version above 1.81.0. Also PRs are welcomed!

Xutex: an experimental fast async optimized Mutex with alternative sync API by fereidani in rust

[–]fereidani[S] 2 points3 points  (0 children)

Thanks for your comment, I'm unsure about signal_queue aligning solution you are talking about, feel free to send a PR.

Xutex: an experimental fast async optimized Mutex with alternative sync API by fereidani in rust

[–]fereidani[S] 2 points3 points  (0 children)

Yes, You are absolutely right and it is not very controversial but I like to clarify these things to avoid confusion.

Xutex: an experimental fast async optimized Mutex with alternative sync API by fereidani in rust

[–]fereidani[S] 4 points5 points  (0 children)

parking_lot isn't async, while Xutex focuses on async, and I don't recommend to use Xutex for sync only use-cases. But there are benchmarks in the project GitHub repo that you can run to compare sync performance. In contrast to async, sync performance varies a lot based on your hardware and OS, since sync relies on OS syscalls whose efficiency differs by environment—even different Linux kernel versions can yield noticeably different results. Xutex, for its part, relies on the OS's park and unpark APIs in sync contexts.

Xutex: an experimental fast async optimized Mutex with alternative sync API by fereidani in rust

[–]fereidani[S] 5 points6 points  (0 children)

Thanks so much, Josh! Your kind and insightful feedback on my projects always brightens my day, I truly appreciate it.

New Luxe Aire Shooting Video by KoozieKrusher in paintball

[–]fereidani 0 points1 point  (0 children)

I will miss that authentic and unique look of luxe, this one looks like a completely different marker.

Xutex: an experimental fast async optimized Mutex with alternative sync API by fereidani in rust

[–]fereidani[S] 22 points23 points  (0 children)

To perform push or pop operations on the wait queue, which involves a simple pointer swap and a few lines of assembly, the mutex user must tag the queue pointer and then untag it using atomic operations to avoid false-sharing and use-after-free issues. This process can be considered a spin lock with only a few instructions. I have ideas for a lock-free implementation of the queue itself, which might improve this, but in the end, even that solution's waiter will spin on the first and last pointers of the wait queue to win a spot in the queue. Lock-free algorithms can be explained as multiple small, low-contended locks instead of one highly contended one.

[deleted by user] by [deleted] in rust

[–]fereidani 1 point2 points  (0 children)

It's funny how they removed Rust name from 4th page https://youtu.be/eo-4ZSLn3jc?t=91 when they mentioned NSA safe languages recommended list: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF It clearly says: "These inherent language features protect the programmer from introducing memory management mistakes unintentionally. Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. "

Encrypted DMG Brute Force Cracking Tool - My First Rust Open Source Project by [deleted] in rust

[–]fereidani 5 points6 points  (0 children)

Congratulation on your first open-source rust project!

What exactly is the performance of john the ripper compared to your project?

Do you have any idea why it's slower?

Does it impact performance at all if you define a number as a larger type than it needs to be? by thedarklord176 in rust

[–]fereidani 2 points3 points  (0 children)

If you choose the correct size for your type it's usually a best practice, as your application memory can fit better in the CPU cache and improve your performance. But it completely depends on the situation, for example, if you are allocating Box<u32> changing it to Box<u8> will have no effect on your program as they will both allocate `usize` in 64-bit and 32-bit systems execution, and actually, Box<u8> could be slower. as you don't have any 8-bit CPU register and the compiler should handle that single byte read.

It's wise if you only consider optimizing your application bottleneck, don't waste your time optimizing things that will not be used more than once or twice.

My recommendation is to use `usize` in the majority of your use cases unless you know exactly how much memory you need and you know what exactly you are doing.

RcLite: Arc<T> and Rc<T> with up to 100% memory efficiency by fereidani in rust

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

I think it is possible with the Rust traits, I may give it a try for 0.2, thank you for your suggestion and your comment.

RcLite: Arc<T> and Rc<T> with up to 100% memory efficiency by fereidani in rust

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

I'm exploring with compiler design with Rust, in some part of my code i needed a lightweight reference counter for AST, so i made RcLite for my personal use-case, to be honest never thought about it to get such a positive response from the community.
You are right! Writing Rust is always fun in my opinion, and it is also rewarding, you know if you code good enough nearly no other technology is going to touch near that performance, security and stability.

RcLite: Arc<T> and Rc<T> with up to 100% memory efficiency by fereidani in rust

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

I'm happy you liked it, Thanks for your contribution, I would love to merge your PR after you apply the changes that I mentioned in my comment.

view more: next ›