> 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
Garnet – A new remote cache-store from Microsoft Research
21–30 of 120 posts
Re: Garnet – A new remote cache-store from Microsoft Research
#22Earlier 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.
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?
Re: Garnet – A new remote cache-store from Microsoft Research
#23So what's the catch, where this doesn't perform well? Would be neat to see benchmarks on smaller instance types too, 72vcpu is quite chunky boi
Re: Garnet – A new remote cache-store from Microsoft Research
#24After 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?
Re: Garnet – A new remote cache-store from Microsoft Research
#25Garnet’s storage layer, called Tsavorite, was forked from OSS FASTER, and includes strong database features such as thread scalability, tiered storage support (memory, SSD, and cloud storage), fast non-blocking checkpointing, recovery, operation logging for durability, multi-key transaction support, and better memory management and reuse.
https://www.microsoft.com/en-us/research/blog/introducing-ga...
Re: Garnet – A new remote cache-store from Microsoft Research
#26Earlier quoted context omitted.
surprised to see a garbage collected language project (C# for Garnet) beat redis/dragonfly
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.
Re: Garnet – A new remote cache-store from Microsoft Research
#27> 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
I tried to compare the source trees. They are nearly identical except for replacing Faster with Tsavorite which makes a direct comparison much harder as they renamed directories and files.
Re: Garnet – A new remote cache-store from Microsoft Research
#28Earlier quoted context omitted.
Plus that it's easier to have unmanaged code in C# than in Java.
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.
Re: Garnet – A new remote cache-store from Microsoft Research
#29Earlier 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.
In C# you usually don't want to mix in C++. Manipulating off-heap memory is indeed easy - nowadays pointers to both object interiors, stack and unmanaged memory can be represented as `ref T` where T is byte, int, etc.
These are then subsequently wrapped by `Span` and `ReadOnlySpan` respectively. This way a span can be a slice of memory that can have any origin:
var fromStack1 = (stackalloc byte[32]);
var fromStack2 = (Span)[0x20, 0x20, 0x20, 0x20];
var fromHeap = new byte[32].AsSpan();
unsafe
{
var ptr = NativeMemory.Alloc(32);
var fromMalloc = new Span(ptr, 32);
// Don't forget to free :)
}Re: Garnet – A new remote cache-store from Microsoft Research
#30Earlier 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'm not the person you are replying too, but I believe that of course, the pattern holds if you keep shifting it down. I.E. using a faster CPU will speed up all programs running on it, each (already optimized) ASIC has to be optimized further individually.