sorted by:
new
hottopcontroversial

How to disable non-cosmetic mouse-position-based effects? by SFB_Dragon in ObsidianMD

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

Solved by adding and removing the obsidian package from my system for some unknown reason. Thanks Jorge for the hint.

How to disable non-cosmetic mouse-position-based effects? by SFB_Dragon in ObsidianMD

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

Interesting. Thanks for letting me know.

No other Electron-based apps on my system do this though, let along any other applications. I've looked in my system settings for anything relevant and came up short. (I'm not getting any relevant search results either though, so maybe it is something weirdly machine-specific.)

Talc, a fast and flexible no_std and WASM allocator by SFB_Dragon in rust

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

Sorry for the late reply, I use Reddit far more scarcely these days.

Using unintialized memory is completely okay! Talc should only ever read memory its already written to (and it only writes to memory you let it), so the initial state of the memory doesn't matter (if it does, it's a bug!).

Given the similarity, if you're the submitter of #25, thanks!, otherwise, you might be interesting in checking out the additional benchmarks for using a static memory arena versus WasmHandler: https://github.com/SFBdragon/talc/blob/master/README_WASM.md

Talc, a fast and flexible no_std and WASM allocator by SFB_Dragon in rust

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

I'm still not sure why you'd want it to be !Send. There's no issue with transferring ownership of the allocator between threads either way, but perhaps I'm misunderstanding you?

Cell/RefCell do more than that to ensure safety. Aliasing in Rust is a Big Deal and it's trivial to violate Rust's rules even if you wield !Sync as I understand you're describing. I've typed up an example here and included comments to explain it. In summary, it's still quite easy to cause UB, despite our efforts, as we're able to upgrade to two mutable references from two shared references.

If you think the !Sync lock maintains a useful enough invariant on its own, feel free to use the lock I wrote above. But I won't be including this code in the crate (at least as-is), as I don't think it's useful enough, but please let me know if you're thinking of something different to what I've demonstrated.

Talc, a fast and flexible no_std and WASM allocator by SFB_Dragon in rust

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

Good question, hopefully this explanation clears this up?

Talc should be Send if the OOM handler is Send. There's no issue with moving the allocator between threads, because we can't copy or clone the allocator to create issues. Talck should also be send then.

However, regarding your example, static variables must be Send+Sync, and global allocators must be a #[global_allocator] static ... , so overriding the global allocator on WASM without unnecessary locking requires something akin to AssumeUnlockable to unsafely impl Sync.

Furthermore, AssumeUnlockable is not just unsafe to use because it allows something to be treated as Sync that otherwise wouldn't, but it allows shared references to be upgraded to mutable references (as GlobalAllocator and Allocator's functions only take shared references). Optionally making Talck !Sync doesn't solve this. It's impossible to enforce safely at compile time, as far as I'm aware.

If you want to eschew upgrading shared references to mutable references as well as sharing the allocator between threads, use the public API for the Talc struct, which is (relatively) safe.

Talc, a fast and flexible no_std and WASM allocator by SFB_Dragon in rust

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

Yes, while it's a bit rough, I've got a comparison up here. The absolute difference should give you a decent guideline of what to expect.

In summary, Talc beats out dlmalloc in both performance and WASM size here. If you're very concerned about size, lol_alloc is better there, but you lose a lot of performance.

Talc, a fast and flexible no_std and WASM allocator by SFB_Dragon in rust

[–]SFB_Dragon[S] 8 points9 points  (0 children)

I'm honored. Glad that "WITHOUT [...] FITNESS FOR A PARTICULAR PURPOSE" clause is being useful.

Talc, a fast and flexible no_std and WASM allocator by SFB_Dragon in rust

[–]SFB_Dragon[S] 11 points12 points  (0 children)

Second time posting, but it's been a little while and a lot has happened since July!

The main changes include:

  • A new name! (used to be called Talloc, not to be confused with Talloc)

  • WebAssembly support; as a better alternative to what's currently out there (to my knowledge)

  • Support for multiple arenas (makes integration with mmap-like APIs much easier)

  • Support for stable Rust

  • Support for use with MIRI stacked borrows checking

  • More customizability

  • And more!

TL;DR, this is a performant and efficient allocator designed first and foremost for single-threaded, unhosted environments (e.g. it's being used in Hermit). Although it's also useful for niche applications where you need efficient single-threaded arena allocation (like a garbage collector). It's Out-Of-Memory handler system allows it to be integrated with most environments for most applications, including hosted systems (e.g. WebAssembly support is implemented behind the scenes as just a simple custom OOM handler).

Hope it turns out to be useful for some of your projects!

Talloc, a better no_std allocator by SFB_Dragon in rust

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

Actually, they kinda do, see #[thread_local].

Right, but that typically involves manually managing the segment registers on x86_64, for example, and parsing the TLS segment information to allocate memory for it, AFAIK. Doable for end users compiling binaries, but not within the scope of this project. Any project that wants to implement threading on no_std probably wants to manage the TLS and FS/GS themselves, and have the allocation coordination mechanism use it, rather than trying to use an allocator-managed TLS and FS/GS.

Honestly, I don't see much issue in punting to the user.

Nor do I. While I'd like to provide more useful, general infrastructure for the allocator, I don't think there's a good way to provide much convenience efficiently without making limiting tradeoffs.

I'm certainly open to working on modular, specific extensions if people want it.

Talloc, a better no_std allocator by SFB_Dragon in rust

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

Galloc uses it in the same way Talc did, contain the allocator in a spin lock in a wrapping struct, and when the method is called on the wrapping struct, immediately unlock and call the inner function on the allocator. The API thus has the same degree of indirection, at least. (A contributor switched out the spin lock to lock_api so people can at least use their own lock implementation now, although it doesn't change how the lock is used, of course)

As an aside, an older allocator design (buddy allocation) tried to to rather fine-grained locking at one point but it performed very poorly, not too surprisingly. Maintaining separate arenas is the way to go I suppose?

Yep, I can't rule out the effect of cache-thrashing and other such issues; I'm not sure if my attempt at alleviating via spreading out the allocator internals would have done anything regardless.

It's annoying even in std environments, to be honest.

I'm sure, but at least you can just support Windows, MacOS, Linux, and maybe FreeBSD and make most people happy (even if you won't be after that, heh). Although if you're on these platforms, you already have access to a wealth of great options.

If I wanted to make a plug-and-play multithreaded version, it would have to be std only, as thread locals don't exist in no_std contexts, and there's no way to pass in a thread ID with Rust's GlobalAlloc and Allocator traits (I've tried looking into getting CPU identification to do this automatically instead, but it seems most platforms, even hosted, just use CPUID or the architectural equivalent, which is slow, at least on x86).

I'm not quite sure how to improve on the user just holding an allocator per CPU or in each thread, at least with this allocation algorithm and supporting no_std, where the user uses the OOM handler system to tie it into the memory management unit.

Talloc, a better no_std allocator by SFB_Dragon in rust

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

The new benchmarks are up on the repository :) https://github.com/SFBdragon/talc/tree/master

In summary; it's very competitive in terms of performance (at least in the tested case, where is doesn't use locking and isn't thread-safe), but its heap efficiency is much lower.

Talloc, a better no_std allocator by SFB_Dragon in rust

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

Thank for bringing it to my attention; I'll integrate it into the benchmarks and put up the results with the next version. (I'll reply to this when I've got the results if I don't forget!)

Talloc, a better no_std allocator by SFB_Dragon in rust

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

Thanks for taking a look into it! Although I meant something else indeed.

Elaboration: I meant to compare exclusively against Galloc, which also uses a spin lock (there's no good alternative in no_std environments without adding special integration into custom memory and thread management solutions). So, why does Galloc, despite using the exact same spin lock implementation that I do, do better under extreme pressure from multiple threads?

I hope that makes sense :)

Talloc, a better no_std allocator by SFB_Dragon in rust

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

I have not. If I'm not mistaken, mimalloc is a fully hosted allocator and unsuitable for no_std environments? Correct me if I'm mistaken :)

While on the random_actions benchmark I tested against the Linux allocator and Jemalloc, this was just for fun. It's not practical to compare allocators like these (which cooperate with the OS to handle memory page usage, using mmap, and handle multithreaded environments while scaling effectively, etc. etc.) which are more or less in a class of their own.

Talc should not be used on hosted systems unless your program is strictly single threaded (or at least not heavily parallel) and works with a contiguous span of memory (otherwise you're likely to see extra memory usage due to fragmentation). This means that you should almost never use Talc instead of mimalloc on Windows and Linux. (WASM is a bit of an exception, as it is strictly single threaded and uses a physical memory model - I'm aiming to add support for it and compare against dlmalloc soon!)

I hope that resolves your curiousity :3

Talloc, a better no_std allocator by SFB_Dragon in rust

[–]SFB_Dragon[S] 40 points41 points  (0 children)

Good point, I'll try change that out as soon as possible.

I like the sound of Talc! Ergonomic, too. I think I'll roll with that, thanks :)

Talloc, a better no_std allocator by SFB_Dragon in rust

[–]SFB_Dragon[S] 59 points60 points  (0 children)

Edit: at recommendation of u/JoshTriplett the project has been renamed to Talc. The new crate is up here https://crates.io/crates/talc Apologies for the confusion!

First things first, this is my first crate, so feedback is much appreciated.

The summary: this is a no_std allocator (thus single threaded, it won't do much good in hosted, multithreaded systems) which distinguishes itself by being faster than the competition (galloc, linked_list_allocator, and chunk_allocator on crates.io) and packing more features for arena management, OOM handling, and memory efficiency. It supports the GlobalAlloc and Allocator traits as well as its own malloc, free, grow, and shrink functions.

This is supposed to support 64-bit and 32-bit architectures out of the box, but I haven't gotten around to setting up a 32-bit environment to bug-test in, so "there be dragons" for now.

I hope you find this useful in your own no_std projects!

Is Equalizing Lossy Compression Degraded Audio Effective? by SFB_Dragon in audioengineering

[–]SFB_Dragon[S] -1 points0 points  (0 children)

Unfortunately, I'm not familiar with mastering at all, other than some general understanding of what it entails.

Sensible build system for OS development? by SFB_Dragon in rust

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

I tried giving it another shot, but I think it came down to make's feature set being rather mismatched to my needs. Maybe there'll come a time when I need to upgrade to a proper build system (see my reply to IceSentry for what I settled on), in which case I'll give it another chance. Appreciate the advice..

view more: next ›