391–400 of 416 posts
Earlier quoted context omitted.
Hear me out- artisanal DRAM.
Every transistor carefully hand-wired with love, giving each bit its own individual characteristic, for more organic, natural data.
We could bring it back.
Earlier quoted context omitted.
Or maybe models that are much more task-focused? Like models that are trained on just math & coding?
isn't that what the mixture of experts trick that all the big players do is? Bunch of smaller, tightly focused models
Anyone want to start a fab with me? We can buy an ASML machine and figure out the rest as we go. Toronto area btw
Earlier quoted context omitted.
You don't happen to play Foxhole [0] do you? Because if not, the logistics Collies in SOL could make good use of a person with your talents. :-) [0] https://store.steampowered.com/app/505460/Foxhole/
Hadn't heard of it before.. > Foxhole is a massively multiplayer game where nope, not my cup of tea, but thanks for the "if you like this you might like this" rec :)
Earlier quoted context omitted.
Which tells me your experience is incredibly limited. Intel was very good, and when they partnered with Micron, made objectively the best SSD's ever made (3DXPoint Optanes). I lament that they sold their storage business unit, though of all the potential buyers, SK was probably the best case scenario (they since rebranded that into Solidigm). The intel X25-E was a great drive, but it is not great by modern standards…
My experience is 10 drives from 2009-2012 that still work and 10 drives from 2014 that have failed.
Hell, as you admitted that your experience is limited to intel, I'd wager at least one of those drives that failed were probably the 660P's, no? Intel was not immune from making trash either, even if they did also make some good stuff (which for their top tier stuff, was technically was mostly Micron's doing).
I've deployed countless thousands of solid state drives - hell well over a thousand all-flash-arrays - that in aggregate probably now exceeds an exabyte of raw capacity since. This is my job. I've deployed individual systems with more SSD's than you've owned in total from the sound of it. And part of why it's hard to kill those old drives is they are literal orders of magnitude slower, meaning it takes literal orders of magnitude more time to write the same amount of data. That doesn't make them good drives, it makes them near-worthless even when they work, especially considering the capacity limitations that come with it.
I'm not claiming bad drives don't exist, they most certainly do, and would consider over 50% of what's available in the consumer market to fit that bill, but I also have vastly higher standards than most, because if I fuck something up, the cost to fix it is often astronomical. Modern SSD's aren't inherently bad, they can be, but not necessarily so. Just like they aren't inherently phenomenal, they can be, but not necessarily so. But they do exist, at a variety of price points and use-cases.
TL;DR Making uninformed purchasing decisions often leads to bad outcomes.
Earlier quoted context omitted.
Apps can't be 100MB on modern displays, because there are literally too many pixels involved. Not that I know what's going on in an Electron app heap (because there's no inspection tools afaik), but I'm guessing much of it is compiled code and the rest is images and text layout related.
Are you 100% sure every single window needs to have 8k resolution?
Earlier quoted context omitted.
> Yes, DDR3 is the lowest CAS latency and lasts ALOT longer. DDR5 is more reliable. Where are you getting this info that DDR3 lasts longer? DDR5 runs at lower voltages, uses modern processes, and has on-die ECC. This is already showing up in reduced failure rates for DDR5 fleets: https://ieeexplore.ieee.org/document/11068349 The other comment already covered why comparing CAS latency is misleading. CAS latency is mea…
It has on-die ECC _because_ it is so unreliable. ECC is there to fix its terribleness from factory.
Many things in electrical engineering use ECC on top of less reliable processes to produce a net result that is more reliable on the whole. Everything from hard drives to wireless communication. It's normal.
Earlier quoted context omitted.
> Apps can't be 100MB on modern displays, because there are literally too many pixels involved. What? Are you talking about assets? You'd need a considerable amount of very high-res, uncompressed or low-compressed assets to use up 100MB. Not to mention all the software that uses vector icons, which take up a near-zero amount of space in comparison to raster images. Electron apps always take up a massive amount of spa…
No, I'm talking about window buffers. This is about memory not disk space.
But window buffers are usually in VRAM, not regular RAM, right? And I assume that their size would be relatively fixed in system and depend on your resolution (though I don't know precisely how they work). I would think that the total memory taken up by window buffers would be relatively constant and unchanging no matter what you have open - everything else is overhead that any given program ordered, which is what we're concerned about.