To get something like Redis or Riak you would have to build API, clustering, etc. on top of it. So it's more analogous to libraries like RocksDB, BoltDB, BDB etc.
Paper: https://www.microsoft.com/en-us/research/uploads/prod/2018/0...
To get something like Redis or Riak you would have to build API, clustering, etc. on top of it. So it's more analogous to libraries like RocksDB, BoltDB, BDB etc.
Paper: https://www.microsoft.com/en-us/research/uploads/prod/2018/0...
As low as possible maybe, but there's lots of limiting factors with P/Invoke, such as:
- They are not inlined
- Registers need to be saved pessimistically
- The state at the point of the call is visible to observers outside of code the compiler controls so options for scheduling are constrained
- Objects need to be materialised
- All parameter values need to be available even if they aren't actually used
- Objects passed have to be pinned or given an indirect handle
- The caller has to be in a safepoint so GC can keep running
- The compiler has to juggle things into place for the C ABI, where it may normally lay things out differently
- etc
Going through a P/Invoke call is a whole inconvenient circus compared to an intrinsic.
Should be usable in NetCoreApp 2.0 and up, or .NET full framework 4.6 and up. In other words, yes, it will work on recent versions of NetCore and classic .Net.
However I also see a .dll file in use https://github.com/Microsoft/FASTER/blob/master/cs/src/core/...
Which suggests that this won't work in NetCoreApp on linux. It's not crossplatform unless it eliminates this or supplies linux .so binaries and so on.
Looks like some file IO functions and __rdtsc