skavi

4 ms·

1.
by skavi 6d ago
direct link: https://www.servethehome.com/micron-evolving-memory-architec...
2.
by skavi 7d ago
> Are you sure you don't just have an axe to grind? Because that is an exceedingly uncommon edge case. Typically you only have a few threads and you aren't inundating the allocator with requests thus it is unlikely to make any
3.
by skavi 7d ago
very naive question: does organ even have a strict enough definition for discussions like this to be worthwhile?
4.
by skavi 8d ago
> seems likely to be a wash at absolute best maybe i give it too much weight, but: > massive oversubscription of physical CPU cores (ie tens of thousands of threads) where TLS becomes utterly wasteful while also thrashing the cache se
5.
by skavi 8d ago
yeah that’s a common mistake when evaluating tcmalloc. gperftools tcmalloc diverged quite a while ago. doesn’t have a lot of the fancier features of modern tcmalloc [0]. [0]: https://github.com/google/tcmalloc/blob
6.
by skavi 8d ago
my feeling is that the space efficiency gains are probably more significant than the reduction in core migration costs. many applications have far more threads than the system has cores.
7.
by skavi 8d ago
https://docs.kernel.org/userspace-api/rseq.html cost for interruption in an rseq critical section is that the PC gets overwritten to the rseq abort entry point before the task is rescheduled. no management thread neces
8.
by skavi 8d ago
https://google.github.io/tcmalloc/rseq.html i don’t believe rseq based cpu local caches require memory barriers on the fast path.
9.
by skavi 8d ago
no article, sorry, grabbed the numbers from an old PR. to confirm, you were using tcmalloc from https://github.com/google/tcmalloc and not from https://github.com/gperftools/gperftools , right? the
10.
by skavi 8d ago
i think we agree that per cpu caching seems superior. i’m looking for the other side of this. most allocators seem to have stuck with per thread.
11.
by skavi 8d ago
does anyone familiar with the art have thoughts on why only tcmalloc switched from thread caches to cpu caches? would it make linux behavior diverge too much from other platforms?
12.
by skavi 8d ago
https://github.com/aardappel/goose/blob/master/docs/tutorial... this bit seems a bit messy.
13.
by skavi 9d ago
a while back, our tests with a proprietary app led us to tcmalloc (new). https://news.ycombinator.com/item?id=47403847
14.
by skavi 9d ago
we actually ended up with (new) tcmalloc. for us, tc was among the fastest in runtime while being very space efficient [0]. large rust application using far too many threads. we’ve since also had great success with tc’s built in profiling t
15.
by skavi 9d ago
so happy GNOME exists. I hear great things about KDE internals, but Plasma and KDE apps are so ugly. modern GNOME is honestly a more consistently clean interface than even (modern) macOS.
16.
by skavi 9d ago
yup and the characterization of each allocator is so fuzzy, with zero methodology provided. allocators are so simple to just swap into your program. if you can put together a few representative workloads, you should just try out a few alloc
17.
by skavi 9d ago
that's something you, the user, are free to enforce with priorities, pinning, etc.
18.
by skavi 14d ago
Houthis use engineering and education to develop guided weapons
19.
by skavi 16d ago
All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem defin
20.
by skavi 17d ago
That design was explored years ago with earlier foldables. The market consolidated on the two screen design pretty early. not entirely sure why, but i’d guess there were durability concerns with the screen wrapping around the edge. might ha
21.
by skavi 18d ago
not really your point, but "If you're smart enough to solve this Navier-Stokes problem, you're smart enough to read a TOS" isn't really true. people are smart in very different ways.
22.
by skavi 18d ago
Under this framework, Rust's async fns would not be colored, since any function in the callstack could be blocking on an executor. if you consider "spawn point" a part of the callstack, many other languages are similar. This
23.
by skavi 23d ago
seems not as great for consumer software in uncontrolled environments. static allocation means the application hordes memory that the OS should probably be able to provide to other processes. constant work probably leads to higher average p
24.
by skavi 29d ago
> Please report user interface bugs using GitHub issues. We are aware that the menus require a long press on iPhone/iPad (and maybe Android) and we are working to fix that. in case anyone else didn’t notice this. wonder how that got
25.
by skavi 1mo ago
This was super fun. Dude’s been on an absolute tear recently.
26.
by skavi 1mo ago
this one actually did get me typing faster. and also helped me get over my desire to look at the keyboard. it’s been a while since I used it but I recall it being good at targeting certain patterns that you struggled with.
27.
by skavi 1mo ago
Waiting for RA to build up the full in memory data structure for a large workspace is so painful. Honestly, I'd just assumed that was the only way and didn't realize Rust Rover was different. Does anyone have experience using that
28.
by skavi 1mo ago
is that a distinct process from DRAM training?
29.
by skavi 2mo ago
MLIR is more a library for building a compiler than a compiler itself IIUC. LLVM can be thought of similarly, but IMO, it's more self contained.
30.
by skavi 2mo ago
I'd assume Mojo does more complex transformations at the MLIR level than Rust does at its MIR level.

More ›