Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Garnet – A new remote cache-store from Microsoft Research

github.com

Post reply on HN
Print view View original

31–40 of 120 posts

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

#31

Post by blackoil »

theLiminator wrote: post #26
blackoil wrote: post #10

Earlier quoted context omitted.

The investment in optimization in CLR or JVM can be huge as they impact millions of applications. While each C / C++ code will have to be hand optimized. Also limits on number of people in given time who can write optimal C code vs C# will also make managed code better.

Couldn't you just replace the CLR and JVM with llvm and gcc and then replace C with assembly and arrive at the same conclusion.

Now commenting beyond my expertise, I understand both ecosystems have developed orthogonally, C#/Java assumes code to be higher level and "dumb" and optimization are in library/CLR/JVM. While C/C++ are developed with code at lower level and developer making sure code is optimized.

Now, I could be talking out of ass, haven't done enough C/C++ coding in over a decade.

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

#32

Post by zigzag312 »

amir734jj wrote: post #14
west0n wrote: post #5

Earlier quoted context omitted.

What surprises me the most is that this project is developed in C#, while Dragonfly is developed in C++, and Redis is in C.

If you look at the store code you see a lot of "unsafe" C# code (i.e pointer manipulation)

Shows how flexible C# is.

You can trade high-level expressiveness for low-level control where needed and you don't have to deal with any FFI to do it.

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

#33

Post by gigatexal »

hipadev23 wrote: post #13
west0n wrote: 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…

> Redis may require a significant performance optimization. Redis is single-threaded, it’s simple and effective. I’m not sure it needs optimization, and we have 3 alternatives here. Garnet however is the first alternative to actually outperform Redis at both low and high levels of concurrency, which is remarkable. I can’t wait to try it out.

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.

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

#35

Post by LeonidBugaev »

hipadev23 wrote: post #13
west0n wrote: 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…

> Redis may require a significant performance optimization. Redis is single-threaded, it’s simple and effective. I’m not sure it needs optimization, and we have 3 alternatives here. Garnet however is the first alternative to actually outperform Redis at both low and high levels of concurrency, which is remarkable. I can’t wait to try it out.

Plus in production, with high load, Redis cluster is way more common, which kind of solve single-threaded concern.

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

#36

Post by moritonal »

gigatexal wrote: post #33
hipadev23 wrote: post #13

Earlier quoted context omitted.

> Redis may require a significant performance optimization. Redis is single-threaded, it’s simple and effective. I’m not sure it needs optimization, and we have 3 alternatives here. Garnet however is the first alternative to actually outperform Redis at both low and high levels of concurrency, which is remarkable. I can’t wait to try it out.

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.

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

#37

Post by orthoxerox »

mordae wrote: post #24
wokwokwok wrote: post #8

After the aborted/abandoned attempt to port redis to windows (0) this feels like a second-try at the same thing, but first party. Of course, as a research project it doesn't have the same stability / support, etc. as redis, but I could easily imagine this rolling into a real product if it's popular. ...and as an MIT license, if nothing else, the code is a fun read. :) [0] - https://github.com/microsoftarchive/redis?t…

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"

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

#38

Post by pjmlp »

whimsicalism wrote: post #6
west0n wrote: 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

Not all garbage collected languages are made equal, some of them, like C# and .NET, do provide all the performace knobs that are needed for C++ like coding.

People only have to learn how to use them, instead of placing all garbage collected languages into the same basket.

In this specific case, MSIL and .NET were designed to support C++ as well, and languages like C# and F# do have ways to access those features, and even if some feature isn't exposed at the language grammar level, you can emit the same MSIL that C++/CLI would generate.

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

#39

Post by pjmlp »

rfoo wrote: post #16
blackoil wrote: post #10

Earlier quoted context omitted.

The investment in optimization in CLR or JVM can be huge as they impact millions of applications. While each C / C++ code will have to be hand optimized. Also limits on number of people in given time who can write optimal C code vs C# will also make managed code better.

Plus that it's easier to have unmanaged code in C# than in Java.

True, I still look forward to have Valhala, eventually.

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

#40

Post by easton »

mordae wrote: post #24
wokwokwok wrote: post #8

After the aborted/abandoned attempt to port redis to windows (0) this feels like a second-try at the same thing, but first party. Of course, as a research project it doesn't have the same stability / support, etc. as redis, but I could easily imagine this rolling into a real product if it's popular. ...and as an MIT license, if nothing else, the code is a fun read. :) [0] - https://github.com/microsoftarchive/redis?t…

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

IIRC, it’s to allow them to relicense contributions in the event they decide to move away from MIT?
Post reply on HN