Imagine writing a whole article like this and only including one really unclear photo with a distracting background and not indicating which bat is which in the photo.
That worked because while the link may have been slow, it was circuit-switched and generally provided the 2400 bits. "Bad wifi" is unbelievably bad compared to an old dial-up link. It's so much worse than you're imagining.
Because IMAP sucks on bad network links. It involves a huge number of round trips to synchronize the state, and re-establishing the shared state when the connection is interrupted takes forever.
A lot of online commenters refuse to believe this but the standard Gmail interface is highly optimized to cope with bad network connections, hide latency, and recover from interruptions. If you have the code assets and initial state cached in your browser, it behaves very well under bad network conditions.
yea it's fair that you can just use IMAP and sync before your trip then send after.
but I was on a flight, didn't have Gmail or Superhuman cached and could not get either to even load. I do suspect that if it were already loaded, Gmail probably would have functioned decently well.
still Gmail and Superhuman just seem...bloated. kinda cool to just have a simple, open source interface for the Gmail REST API.
Unfortunately, Flock really has been doing some shady stuff and the alliance of 1) people with legitimate concerns about Flock operations, and 2) the much larger population of people who are accustomed to getting away with petty crimes is, together, politically successful.
It would be easy to create a camera network that is locally owned and operated by public agencies, and if any place in America could so that it should be SF.
Yeah this doesn't bother me in any way, shape, or form. We already have manned aircraft that respond to such things, unmanned aircraft are a strictly better solution. It makes sense for police and it makes even more sense for fire. An aircraft can arrive at the site of a reported fire while firemen are still buckling their pants.
This readme, this header do not seem to discuss in any way the tradeoff, which is that you're paying by the same factor with median latency to buy lower tail latency. Nobody thinks of a load as taking 800 cycles but that is the baseline load latency here.
Also, having sacrificed my own mental health to watch the disgustingly self-promoting hour-long video that announces this small git commit, I can confidently say that "Graviton doesn't have any performance counters" is one of the wrongest things I've heard in a long time.
Overall, I give it an F.
Anyway if you want to hide memory refresh latency, IBM zEnterprise is your platform. It completely hides refresh latency by steering loads to the non-refreshing bank, and it only costs half the space, not up to 92% of your space like this technique.
Nope, there isn’t a tradeoff; median latency isn’t affected. I don’t think you understand the code. The p50 is identical between a single read and the hedged strategy.
The clflush is there because the technique targets data that will miss the cache anyway. If your working set fits in L1, you don’t need this.
Also, AWS Graviton instances absolutely do not expose per-channel memory controller counter PMUs. That’s why you have to use timing-based channel discovery.
The IBM z-system is neat! But my technique will work on commodity hardware in userspace, and you can easily only sacrifice half the space if you accept 2-way instead of 8+ way hedging. It’s entirely up to you how many channel copies you want to use.
Your reply was quite rude, but I hope this is informative.
I was just trying to reconcile his reply with the charts. Have you tested how this scales down for smaller systems, as one might find in on the management side of a network switch?
I won't be tone-policed by a person who is clearly trying to mislead and confuse people. I leave it to the other HNers to read your benchmark code and see for themselves that it is an exercise in absurdity, a work-around for its own library that doesn't measure anything other than with N threads, because of the laws of probability, this technique of reading timestamps as fast as possible and cramming them into a vector yields lower measurements with higher N.
You were rude for absolutely no reason. You could point out where you think the article comes short and make suggestions on how to improve it. With this approach, you achieved nothing.
Being competent requires being knowledgeable AND getting things done. You might be knowledgeable, but you need to learn how to work with other people.
Even current Dell servers less than a year old ship with G200 graphics. If it works, why change it? A 1998 ASIC can be put in the corner of a modern chipset for pennies or less.
Sure. I picked IMPACT for having hardware textures. An interesting list would contain the first examples of processors that had things we still have today, like geometry processors. It would also contain evolutionary dead ends that tried to do things differently, like the Rendition Vérité.
reply