Earlier quoted context omitted.
Can you point to any resources to read up on this?
https://docs.cilium.io/en/latest/network/kubernetes/local-re...
Thanks!
Garnet – A new remote cache-store from Microsoft Research
91–100 of 120 posts
Re: Garnet – A new remote cache-store from Microsoft Research
#92Earlier 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.
I assume it's similar to the 1 billion row challenge with java - C# and Java have sufficiently advanced VM's that they can compete with C/CPP performance - assuming you go out of your way to optimize for it. https://github.com/gunnarmorling/1brc
Comparison between languages: https://hotforknowledge.com/2024/01/13/1brc-in-dotnet-among-...
Re: Garnet – A new remote cache-store from Microsoft Research
#93Earlier quoted context omitted.
> the library ecosystem I don't really see many gaps. There tends to be fewer libraries, but the libraries available generally feel more complete and well thought out because users tend to cluster around the known libraries. Many of the first party libraries are really, really good. EF Core is a prime example of possibly one of the best ORMs on the market right now in terms of productivity, ergonomics, and performanc…
> I don't really see many gaps isn't that the "works on my machine" of this discussion? What's the Apache Tika for .net then? I don't mean, pdf parsing, I don't mean .docx parsing, I mean a framework for interacting with all their supported types https://tika.apache.org/2.9.1/formats.html > with one surface area?
The entirety of Apache ecosystem pretty much mandates using Java or you are being left out with no or at best second-citizen experience. It's not a fault of every other language, but of that particular ecosystem itself.
There are exceptions in the form of well-written community-maintained libraries, but these exist for minority of Apache projects and vary a lot between languages.
Luckily, there are often (but not always) plenty of alternatives to whatever it is that you seek from Apache.
Re: Garnet – A new remote cache-store from Microsoft Research
#94Earlier quoted context omitted.
https://github.com/KevM/tikaondotnet ?
> https://github.com/KevM/tikaondotnet/releases/tag/v1.17.1 - Apr 3, 2018 You're right, how silly of me, I'll install some rando's 6 year old build of it right away. But in seriousness, that readme did remind me of the thing I was thinking of: http://www.ikvm.net/userguide/ikvmc.html
Maybe your question is the wrong one to ask. My inclination is that a package or library that isn't actively maintained has no utility. If that's the case, then the assumptions underlying that package are perhaps not relevant.
Personally, I'd say it is probably the case that there are better alternatives. Azure Document Intelligence being one of those. Sure, it can't handle the variety of formats, but again, we have to come back to the underlying assumptions: .docx, .pdf, and a few handful of formats probably covers 99% of business use cases. Everything else would be considered niche.
Re: Garnet – A new remote cache-store from Microsoft Research
#95Earlier 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.
> Redis for 99% of the intended use-cases and companies will be just fine.
Except when Windows is the architecture.
This may be a place where Garnet is a good alternative.
Re: Garnet – A new remote cache-store from Microsoft Research
#96This is excellent news for people who needs to run Redis (or compatible in this case) directly on Microsoft Windows Server, without relying on WSL2. Previously, there was a Redis port available [1] (which is now in archive status) that had memory usage issues (mainly because of memory-mapped files AFAIK) and, of course, is no longer supported.
It's also quite intriguing for me to see it's written in C#, as that's my native tongue. I'd be keen on dedicating some time to delve into the code.
Re: Garnet – A new remote cache-store from Microsoft Research
#97Earlier quoted context omitted.
It’s great but you’re locked into visual studio if you want the most out of it (they put 95% of their effort in tooling there). You want to use visual studio?
I work in .NET on the daily on an M1 MBP using primarily VS Code and occasionally Rider. There's no need for VS for most (any?) .NET workloads these days. That's why I wrote it was an early mis-step. Nowadays, it's easy to do .NET dev on any platform. In fact, we ship our production runtime to AWS t4g (Arm64) instances.
I primarily use JetBrains Rider for my daily tasks, and I agree that while you can use VS Code or even Vim with LSP support for many projects, working with substantial ones such as the runtime or ASP.NET Core development might practically necessitate using Visual Studio. By the way, the Visual Studio Community Edition is available for free for virtually all projects I can think of, mainly for personal, non-commercial, or open-source usage. The license details can be somewhat unclear, but that's my understanding of it.
Re: Garnet – A new remote cache-store from Microsoft Research
#98Earlier 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.
I don’t think so, because it is the runtime JIT (Just-In-Time) optimizer that is the critical speed advantage that allows the CLR and JVM to beat C and C++.
The inlining of virtual calls is the critical optimization that enables this. Because C/C++ is optimized statically and never at runtime, it is unable to optimize results of function pointer lookups (in C, and thus also virtual calls in C++). However, the JITs can inline through function pointer lookups.
In sufficiently complex programs, where polymorphism is used (i.e. old code that calls new code without knowing about it), this yields an unsurpassed speed advantage. Polymorphism is critical to managing complexity as an application evolves (even the Linux kernel, written in C, uses polymorphism, e.g. see struct file_operations).
Re: Garnet – A new remote cache-store from Microsoft Research
#99From 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
Manual memory management vs garbage collection trades speed of allocation for speed of freeing memory. Freeing memory is expensive in a garbage collected language, but allocation is basically free.
Modern garbage collectors are very good and handle many common use cases rather efficiently, with minimal or zero pauses, such as freeing short-lived objects. Many GC operations are done in parallel threads without stopping the application (you just pay the CPU overhead cost).
Also JITs in both the CLR and the JVM perform optimizations such as escape analysis, which stack-allocate objects that never escape a function’s scope. These objects thus do not have to be GC’d.
So really with a GC’d language, you mostly have to worry about pauses and GC CPU overhead. Most GCs can be tuned for a predictable workload. (A bigger challenge for a GC is a variable workload.)
Re: Garnet – A new remote cache-store from Microsoft Research
#100From 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.
Who would trust microsoft to not shoehorn in some telemetry, or worse?