You need that to do drag and drop with one mouse-down and one mouse-up.
Given that, the designer can decide if that’s an exception and everything else requires click-to-focus before being interactive, or to use focus-follows-mouse. People really seem to have individual preferences on this, so there’s no one right answer.
Storage access isn’t, though. You have to read every byte of a (non-sorted) file to find words in it. And whether it’s disk or RAM, the bandwidth is usually a key constraint.
That’ll be just as true for an ASIC NN as it is for good ole grep.
When storage bandwidth is a big enough problem, that will get addressed.
NVMe v1 wasn't released until 2011 and there was no hardware available until 2012. Before that the fastest drive interface was 6 Gbps SAS. Then we got 4 GBps (32 Gbps) with NVMe v3, 8 Gbps (64 GBps) with v4, and 16 Gbps (128 Gbps) with v5. V6 is slated to double again. v7 is currently planned to double that. This is less than 15 years of progress.
In the 1990s, we went from 33 Mbps to 66, to 100, then 133 with IDE. We went from the 40 Mbps of 1986's SCSI 1 to 80 of SCSI 2 in 1994. Since then parallel SCSI has gone to 80, 160, 320, 640 (Ultra 2 wide), 1280 (Ultra 3), 2560 (Ultra-320), and 5120 (Ultra-640) Mbps.
SAS has also gotten faster, with 6 Gbps, 12 Gbps, and 22.5 Gbps. NVMe is still lower overhead and lower latency.
Memory bandwidth can also be addressed. Stock servers with EPYC are 16 channel DDR5. That's 409.6 GBps. Four channels of DDR3 was only 102.4 GBps. Video and accelerator card memory bandwidth is also increasing.
So you don't want the top scientists, engineers and thinkers training the next generation? And you don't want popular sexy things subsidizing inventing new things that haven't had time to be popular yet?
The “next generation” gets trained by adjuncts and grad students. “Top scientists, engineers, and thinkers” are too busy with grant proposals to be bothered with teaching.
Not foolish. The constraint of no-need-for-globally-consistent-state is so important and rules out so many approaches that it was well worth stating in the article.
Indeed the statistical model described in the article does not model the distribution over server hash allocations you'd get if you allow them to be inconsistent across load balancer hosts, so the model actually models (and thus implies) a single global source of truth that they probably don't have in practice.
Well, given that I knew that I was probably missing something, and the fact that their solution made no sense with the constraints I was using, pretty strongly implied that there was an additional constraint. And that's a fairly obvious one to have.
I can't do the math to prove it, but their solution still seems wrong to me. Rather than generating and storing and searching so many hashes, it seems like you should get partway there with a different sampling procedure that doesn't do quite as well with the inconsistent sets of servers, and then only use duplication to limit the consistency loss.
Simple example: use their scheme but instead of choosing the first server to the left of the probe, grab the first two and flip a coin to decide which one to use. That already spreads the bucket variance out a bit, without using any extra space. It does have a penalty in that if one balancer has a server that the other doesn't, then it spreads out the range of probes that could get a disagreement. But I don't know how to quantify that; if the balancers disagree on the set of servers available, you have to produce different results part of the time, and I haven't thought through how to characterize when that disagreement is "bad".
Then you could extend that to looking at the previous 8 servers. Or the previous k tickets, if you give each server a ticket for each weight unit.
The math works out easier if you sample regions of probe space rather than server counts: hash the incoming task, map that to a range of space on the number line, and all servers within that range are your candidate set. Choose from that set, making the candidates be either equally weighted, weighted proportionally to their weight (size/capacity/whatever), or weighted by how much they got shafted by the random distribution of the server hashes.
I get EBRAINTOOSMALL when I try to work out the statistics, especially when I try to figure out what the inconsistency cost is, but intuitively it still seems better than recording a bajillion hashes for each server. (With the latter sampling mechanism, you'd need to deal with the possibility of probing a window with no server in it, either by double hashing the task and trying again, or expanding the probed region. Details schmetails.)
In practice, I'd probably simulate it and look at the distributions. Or nerd snipe a math geek.
The coin flip method you describe breaks the same-query same-server locality (unless adding or removing servers) that is one motivation for the consistent hashing method.
You could solve that by storing the new-query flip result, but the goal was reducing storage…
I'm assuming all coin flips are deterministic based on the task. In this case, it'd be equivalent to generating a slightly longer hash and using a couple of bits for the "coin flip". (Or just generating a new hash with 1 or 3 bits or whatever you need.)
Customers often want to pay less, and shareholders often want lower capital costs. A tasteful optimization is a win-win. The opportunity cost should be traded off against new features of course, but tasteful optimization is a good thing for customers.
No, the parameters are updated online as new run-time data comes in. Infinite different param values over time, but a constant number of params. It's a stretch really, since by this usage a one-parameter model that updates itself is also infinite over time...
From a quick look at the paper it seems they are showing how to update weights online via projection through a smaller matrix like a dynamic version of LoRA. That's weights changing, and not the architecture or training approach. Weights aren't the currency of research, they are the currency of a training run. This paper itself adds an architectural extension.
Yeah, and a pound of sugar cost 8oz of gold a few thousand years ago, so inflation isn't real and food insecurity is a myth.
If you want a fair comparison you should look at the price of storage at the capacity required for typical contemporaneous workloads. Don't quote numbers in the billions when that amount of storage didn't exist on the entire planet at the time.
this is pointless pedantry. there's an implicit "functionally equivalent, for modern (apple) devices" bit.
> It would really help perspective sometimes
It objectively and absolutely doesn't help this discussion at all. Even if taken as hyperbole, the frustration with Apple charging $200 for 256 added gigs, and filling up ~20gigs of it without consent or requirement, is unaffected by floppy prices in the 80s.
Ok, let’s talk apples to apples. I’ll talk about RAM instead of disk, and I have a workload example for you.
As a graduate student in AI in 1995, I bought (with granting body’s money) a workstation for running my PhD experiments. It was a Sun Sparcstation 5, and it had 192MB of RAM. That was a lot of RAM in those days, and we spent the money so we could do experiments at what was then then a high end personal workstation (not big iron or server rack gear).
The 192MB of RAM DIMMs cost $27K in 1995 dollars, or $58K in 2026 dollars. Just the RAM.
The maxed out Mac Studio today, with 256GB of RAM is $10,800, including an upgrade to max RAM of $4K. This machine smokes the Sparc 5 so hard it’s not even funny (as does my phone, of course). The RAM on this frontier workstation is 1/10 the price of my student workstation’s RAM, and more than a thousand times larger.
It is simply not true, however you cast it, that storage (static or dynamic) has never been more expensive.
We can talk about bloated installs without saying stuff that is not at all true. It’s good to know our history. You can call it pedantry, I just prefer true things.
RAM is ~10,000 times cheaper for today’s workstation purchasers per byte, or ~ten times cheaper for max-out-that-bastard, which normalizes for technical progress.
Social media has fried some people’s brains so much that it is incredibly anxiety inducing to make many typically mundane or routine choices, for fear of missing / missing out on something.
Given that, the designer can decide if that’s an exception and everything else requires click-to-focus before being interactive, or to use focus-follows-mouse. People really seem to have individual preferences on this, so there’s no one right answer.