5 ms·

For those wondering what this is, it is not a client/server app, from what I can tell, but an embedded engine. It looks like it's intended to be a library, and

For those wondering what this is, it is not a client/server app, from what I can tell, but an embedded engine. It looks like it's intended to be a library, and it's been implemented in two languages (C# and C++). 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/08/p809-chandramouli.pdf https://www.microsoft.com/en-us/research/uploads/prod/2018/0...

dlahoda 8y ago
c++ part is one liner intrinsic which may be supported directly with new .net and several io methods which would be heavy on pinvoke calls like 5 per method if in c#, but these are very simple. so c++ part could be done in c and easily ported to unix. i guess c# should allow for pinvoke strategy like in lua to replace c++ more.
- int_19h 8y ago
  What kind of different strategies did you have in mind? So far as I know, P/Invoke already tries to be as low overhead as possible - e.g. primitive types and blittable structs are just passed as is, with no conversions. The recently added Span<T> is also special-cased for P/Invoke.
  - chrisseaton 8y ago
    > So far as I know, P/Invoke already tries to be as low overhead as possible 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.
yarper 8y ago
Can anyone work out what platforms it works on? .net core?
- SideburnsOfDoom 8y ago
  Here is the relevant metadata: https://github.com/Microsoft/FASTER/blob/master/cs/src/core/FASTER.core.csproj#L4 https://github.com/Microsoft/FASTER/blob/master/cs/src/core/... 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/FASTER.core.csproj#L35 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.
  - benaadams 8y ago
    src is in native https://github.com/Microsoft/FASTER/tree/master/cs/src/native https://github.com/Microsoft/FASTER/tree/master/cs/src/nativ... Looks like some file IO functions and __rdtsc

dlahoda 8y ago

c++ part is one liner intrinsic which may be supported directly with new .net and several io methods which would be heavy on pinvoke calls like 5 per method if in c#, but these are very simple. so c++ part could be done in c and easily ported to unix. i guess c# should allow for pinvoke strategy like in lua to replace c++ more.

int_19h 8y ago
What kind of different strategies did you have in mind? So far as I know, P/Invoke already tries to be as low overhead as possible - e.g. primitive types and blittable structs are just passed as is, with no conversions. The recently added Span<T> is also special-cased for P/Invoke.
- chrisseaton 8y ago
  > So far as I know, P/Invoke already tries to be as low overhead as possible 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.

yarper 8y ago

Can anyone work out what platforms it works on? .net core?

SideburnsOfDoom 8y ago
Here is the relevant metadata: https://github.com/Microsoft/FASTER/blob/master/cs/src/core/FASTER.core.csproj#L4 https://github.com/Microsoft/FASTER/blob/master/cs/src/core/... 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/FASTER.core.csproj#L35 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.
- benaadams 8y ago
  src is in native https://github.com/Microsoft/FASTER/tree/master/cs/src/native https://github.com/Microsoft/FASTER/tree/master/cs/src/nativ... Looks like some file IO functions and __rdtsc