Live data from Hacker News

Garnet – A new remote cache-store from Microsoft Research

github.com

41–50 of 120 posts

Re: Garnet – A new remote cache-store from Microsoft Research

#41
post #15
post #7

Earlier quoted context omitted.

I think it is rare, but isn't impossible. I remember in the 2000's watching someone do a demo of Java/JVM beating the pants off a C++ application. If I remember correctly, it was something about how the JIT was doing an optimization that you would have had to write assembly in order to optimize it to the same level.

There are at least two reasons I can think of why a JIT language with GC can outperform C/c++: 1. Memory management with a GC often has higher throughput. With the downside that you can have high latency when a garbage collection occurs. 2. The JIT compilation can potentially do a better job of optimizing, because it has information about how the code has been run so far. It is possible for c or c++ (or rust) to get…

3. The runtime also supports C++, and one emits the same MSIL code sequence that the C++ compiler would generate.

Which is why WASM isn't that great novelty for grey beards.

Re: Garnet – A new remote cache-store from Microsoft Research

#42

Earlier quoted context omitted.

Redis for 99% of the intended use-cases and companies will be just fine. It has always been rock solid when we used it. It was the opposite of DNS: it was never a problem.

Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.

isitdns.com

Re: Garnet – A new remote cache-store from Microsoft Research

#43
post #4

From the benchmark performance charts( https://microsoft.github.io/garnet/docs/benchmarking/results... ), the throughput of the GET command exceeds that of Dragonfly by more than tenfold. While 50% latency is slightly higher than Dragonfly, the 99th percentile is slightly lower than Dragonfly. Both the throughput and latency of Garnet and Dragonfly are far better than Redis, indicating that Redis may require a signif…

surprised to see a garbage collected language project (C# for Garnet) beat redis/dragonfly

There's a series of blog posts by Oren Eini that shows that C# can be sufficiently fast even when you don't really optimize anything. Beating Redis in every benchmark is a whole another level, of course.

https://ayende.com/blog/197412-B/high-performance-net-buildi...

Re: Garnet – A new remote cache-store from Microsoft Research

#44
It is interesting to see how Microsoft and the .NET team are building some very impressive hack-your-own-infrastructure project. Yarp is a reverse proxy/API gateway/whatever you do. Now Garnet for memory caches.

Seems they have tons of internal need and are willing to share.

Re: Garnet – A new remote cache-store from Microsoft Research

#45
post #28
post #22

Earlier quoted context omitted.

Is it possible to have unmanaged code in Java at all… or you mean linking libs and exposing them through Java API in the lang?

Ah, I meant Java code manipulating off-heap memory. For Java I don't think there's a way to mix managed and unmanaged code like you do in C#/C++ CLR.

Panama has helped into that direction, it isn't like C# though, for feature parity we will eventually need Valhalla, which since they want to keep existing JARs working, it is taking its time.

Ignoring the type systems from Eiffel, Objective-C, Oberon and Modula-3 linage, even though they were inspirations for Java, has been shown to have been a bad decision in hindsight.

Re: Garnet – A new remote cache-store from Microsoft Research

#46
post #24

Earlier quoted context omitted.

MIT license, but with CLA. It's bizzare. What more rights could they possibly want on top of MIT to warrant CLA?

It's probably a blanket requirement by the MSFT legal team so they can just release everything as "(c) Microsoft" instead of "(c) Microsoft and 999 more contributors, one of which has actually forgot to put their name in the AUTHORS.txt and thus we're technically violating the terms of the license"

Yep, the CLA only applies if you want to merge your changes into the project.

Re: Garnet – A new remote cache-store from Microsoft Research

#47

Earlier quoted context omitted.

Redis for 99% of the intended use-cases and companies will be just fine. It has always been rock solid when we used it. It was the opposite of DNS: it was never a problem.

Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.

It's weird since DNS is one of the most rock solid systems we have, with redundancy at every level.

1. Clients query a list of servers (IPs) and handle failover when you don't quickly get a reply.

2. Most of those servers at the root and TLD level are actually anycasted from multiple locations globally, so you connect to the closest instance.

3. Those instances are often clusters of physical servers. The big ones have fully redundant networking, so any router or switch failing doesn't take it down. Some run different DNS server software on each physical server, so even software bugs won't take down the whole system.

Re: Garnet – A new remote cache-store from Microsoft Research

#48

I just wish they had something like this embedded into Azure App Service, so it wouldn't be necessarily to use a remote service for caching. For reference, something commonly used with IIS for ASP.NET apps was to have an out-of-process "session state" store, so that if the web app process restarted, users wouldn't lose their sessions and have to log in from scratch. Sure, you can put this somewhere central like SQL S…

This is (one reason why) I love k8s with cilium. I can set up a service to always go to the local service (or any other routing topology). It is great for any kind of dns or application cache.

Re: Garnet – A new remote cache-store from Microsoft Research

#50

> Garnet’s storage layer, called Tsavorite, was forked from our prior open-source project FASTER Would be interesting to know why it was forked, why the changes can't be incorporated and wether FASTER continues to be developed

“Our” may be the key word here. In other words, it may be political; they wanted the freedom to make changes to their original project without having to deal with PRs to the current maintainers.
Post reply on HN