The meme don’t make sense. An SRAM cache of that size would be so slow that you would most likely save clock cycles reading directly from RAM an not having a cache at all…
- 0 Posts
- 8 Comments
I’m hosting a matrix server with a TURN server and it’s fairly easy to selfhost. This sounds exaggerated.
Smoolak@lemmy.worldto Technology@lemmy.world•Spotify caught hosting hundreds of fake podcasts that advertise selling drugsEnglish1·2 months agoI second this.
Smoolak@lemmy.worldto Steam Deck@sopuli.xyz•Valve confirms it'll support the ROG Ally with its Steam Deck operating system77·11 months agoThis will make that device so much more usable.
You can take a look here: https://fosstorrents.com/
On the contrary AUR seems to have a lot more binary packages than source packages in my experience. Tons of package also have a “-bin” version (e.g. yay).
Your “unsupported” comment is a bit weird. It’s the AUR user community that supports Arch and makes AUR compatible with it. I don’t know why somebody would contemplate the other way around. I mean, it’s the while philosophy of the AUR.
I’ve been using it for the past 12 years and I rarely got any issues with it. I think you fear mongering quite a bit. Sure, you get over some abandoned packages from time to time and once in a blue moon you get a dependency that doesn’t install properly. When that happen you post a comment on the AUR or flag the package and it’s solved in a matter of days most of the time. It’s surprising that such a system would work so well, but it does.
deleted by creator
Most people I know just use Arch Linux and the AUR. It seems to be the easiest system around for maximal package support and it’s well maintained.
Smoolak@lemmy.worldto Fediverse@lemmy.world•Sublinks Aims to Be a Drop-In Replacement for LemmyEnglish13·1 year agoRemoved by mod
I agree. When evaluating cache access latency, it is important to consider the entire read path rather than just the intrinsic access time of a single SRAM cell. Much of the latency arises from all the supporting operations required for a functioning cache, such as tag lookups, address decoding, and bitline traversal. As you pointed out, implementing an 8 GB SRAM cache on-die using current manufacturing technology would be extremely impractical. The physical size would lead to substantial wire delays and increased complexity in the indexing and associativity circuits. As a result, the access latency of such a large on-chip cache could actually exceed that of off-chip DRAM, which would defeat the main purpose of having on-die caches in the first place.