Lemmy feature request: Show my negative “karma” in my profile page. You can make it opt-in if you must.
It would be a cool if you report back in a separate post if you discovered anything interesting. It’s not like we’re overwhelmed by too much activity here.
Also, while I think it should be obvious, but I forgot to clarify that if you’re inheriting from a profile with codegen-units = 1, then you need to set that explicitly to a higher value in the inheriting profile.
Make sure you’re using a fast linker. Although I think lld is the default now, so that should be less of a concern these days. But see if mold or wild would help.
More relevantly, you should be using cranelift for codegen in dev builds.
If you have codegen-units = 1 in your release profile, make sure you have a separate dev profile that doesn’t.
If you still experience decapitating slowness (doubtful), and it’s actually the rust compiler being slow (super doubtful), you can try the parallel frontend. Apparently there are almost™ no bugs left in its implementation (It’s one of the project priorities now).
Needless to say, but you should be checking your --timings to really know what’s going on.
Enthusiasts will care because it could save them storage space for equivalent quality
That’s the thing, even if you ignore that such scenarios involve lossy-to-lossy re-encodes (bad), and even when you ignore the general lack of psychovisual tuning in new encoders, the advertised so called objective “20%-30% improvement” is not universal, and only applies to bit-starved resolution-maxed encodes.
Your file is 1080p or 720p? you won’t get that improvement, even in not-fit-for-purpose “objective” measures.
You want to encode at a higher bitrate than YouTube to actually get good quality? you won’t get that improvement either.
So if you embark on such a futile journey, you could be wasting a lot of computing power for no, or even negative, gain.
now
Full-length encodes will take days to finish, and we are not talking single digits.
An almost, but not really, practical encoder will probably take at least a year of development before it’s ready.
And anyway, do end-users still care about codecs (beyond decoding complexity/hardware support)?
LRU inversion: the problem with not caring about it is that it’s not a visible problem until it very suddenly is. Your system will not gradually degrade but very suddenly and unpredictably hit a wall that it cannot get itself over.
All this talk just confirms my feelings that there is a general lack of understanding of actual modern workloads.
RAM (normal w/wo zram) doesn’t get full, then stay full forever in real workloads. Not only is that not realistic at the “opened apps”/“running processes” level, it’s not real at the heap allocation level within tasks within processes. And this is much more pronounced with code written in modern languages like Rust and some styles of C++. Modern heap allocators batch and cache (primarily to help with performance). But still, A LOT of memory is getting allocated and deallocated all the time, even from the kernel’s PoV.
LRU itself is an imperfect approximation, not a goal. In the setup described in my other comment (fast SSD swap storages only used sparingly most of the time), so called LRU inversion gets auto-cancelled relatively quickly, as free space in RAM(+zram) gets available all the time, and some “LRU-hot” pages in SSD swap turn out to be actually cold, and those ones are the only ones that actually stay there.
This is why, I would imagine a lot of fake scenarios, and “benchmarks” based on them, may fail to replicate the practical reality of many (overall system) use-cases.
More tangentially, the oversized concern for file caching pages also points to specific aligned use-cases in mind, as if everyone is running DB-centric workloads or something.
This is not a good thing btw. Any unused anonymous page takes up space that could instead be used for file-backed pages that make your system faster.
Can you expand here. I think my attempt at brevity in this part wasn’t helpful.
Swap is not tiered storage!
I meant tiered with priorities only, yes.
Cool tech but it’s dead and was quite niche even when it was alive.
We are not talking about the original purpose of Optane as supported on Windows. It’s just a (perhaps somewhat outdated) example of a storage device “smaller but faster than your average SSD storage”, which is very much not did tech.
Not a thing you actually want to use for swap
Depends on the use-case. But yes, this can also be used as the fastest disk tier/priority of normal swap devices, which is why I mentioned both.
This makes no sense at all unless you are extremely space-constrained on the NVMe and absolutely must not OOM – even if progress stalls to an absolute crawl.
Why would you want to see killed processes when you go back to your workstation, in the 1/10000th scenario where something runs amok pushing memory usage to unexpected high levels? When you can simply investigate the reason behind the rare occurrence, then move all the pages off the slowest devices immediately with swapoff?
It was just an example of a “smaller+faster than your average SSD”.
and I was mentioning something similar to my setup instead of an imaginary use-case.
Alright, I will only reply to you, since you raised a fair question.
First of all, I must admit that I thought what was linked was an earlier similar writing, but the general theme is still the same.
The problem with the writing is that it focuses on use-cases like Android and some servers, but doesn’t take into account other use-cases. It also seems to come with the assumption that setup is done by the distributor only, or if it’s done by the user, it’s a configure-and-forget situation.
What he represents is:
Now let’s look at a possible modern workstation setup:
This last point in particular should make it clear why his “imagination” was rather limited in his LRU inversion section.
If you’re going to hand out free advice, at least make sure the advice is worth the price of admission.
This is very ironic, considering your comment is a mix of straw man and wrong.
It’s shit info. zram is actually better, more so with high ram size+high usage situations.
Oh, you wrote “easy” not “early” in OP. In any case, this looks stupid. But to each their own, I guess.
Why do you think 32GiB is special compared to 16GiB?
And wtf is EasyOOM?
You maximize the usefulness of zram by actually increasing sappiness, and giving zram devices high priority. e.g.
sysctl vm.swappiness=100
for i in {1..8}; do
swapon /dev/zram${i} -p 32767
done
Then you enable other swap devices with lower priority.
This is the way regardless of how much RAM you have. I mean, it may be pointless if you never ever exceed, let’s say 10/32GiB (including caching). But it still wouldn’t be harmful in any way.
zram makes sense if you do not have swap.
wrong.
zswap is probably enabled by default in most distros.
wrong
You should look up the genetic fallacy. And using phrases like “hand-craft code” make you look stupid.
If you’re posting from Desktop Linux, your comment utilized at least 10 liberally licensed libraries. And that’s before it got into the wire. GPL packages are a MINORITY, not a majority with exceptions.
There are a lot less GPL projects in your system than you might think. Your core system is already filled with liberally licensed libraries and programs. Case in point, since you talked about rust rewrites, original sudo is not GPL software.
I2P is a fully connected network where everyone is a relay, a UDP transport exists iirc, and there are many other significant technical differences.
And if you’re dreaming of significant masses moving to the shadows, you might as well dream of them using distributed solutions. Otherwise, the monsters will simply find and shutdown the hosts/servers of whatever the good kids are consuming.
There is a connection between August and freedom. Do you know what is it?