51–60 of 84 posts
Earlier quoted context omitted.
Microsoft tends to choose bad names: See Visual Studio Code, the most ungooglable name ever.
What are your thoughts on how "Googleable" these product names are: ".NET" and "Azure Functions"
"What differentiates FASTER are its cache-optimized index that achieves very high performance — up to 160 million operations per second when data fits in memory;" I really dislike when papers make performance claims like this in the introduction. That "160 million" number is so meaningless at face value because everything from the runtime environment to the hardware is going to play a huge role in ops. I rather see h…
If you want concrete benchmarks, they compare to RocksDB and Redis around page 10 of their academic paper. ( https://www.microsoft.com/en-us/research/uploads/prod/2018/0... ) TL;DR: I find their choice of benchmarks to be very convenient. They tested on in-memory 8 byte payloads and were way faster than RocksDB and Redis. They then tested against only different configurations of themselves for configurations that hit…
> They then tested against only different configurations of themselves for configurations that hit disk. In the case of Redis, AFAIK it can't support larger than memory use cases, right? And in fact they do compare to RocksDB for larger-than-memory, see Fig 10. Granted, it could be more detailed, but I think it makes their point.
Earlier quoted context omitted.
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.
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 is also special-cased for P/Invoke.
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.
What are the use cases for such a library?
I have seen plenty of local-machine fast key-value stores, such as LevelDB (By Google), or RocksDB (By Facebook), but I have a hard time imagining what they are for. What are the use cases for such a library?
One solution is to maintain such state in some key-value store. Different functions of your service can query this state within the data center and never have to suffer disk delays - which are often much longer than the internal network of your data center.
I have seen plenty of local-machine fast key-value stores, such as LevelDB (By Google), or RocksDB (By Facebook), but I have a hard time imagining what they are for. What are the use cases for such a library?
Imagine you want to run a service. This service needs to maintain some intermediate state. This state might’ve frequently read. There might be little value in persisting this state. Also, your service is used by many users, so this state can grow to be pretty big. For example, contents of a shopping cart. One solution is to maintain such state in some key-value store. Different functions of your service can query thi…
"What differentiates FASTER are its cache-optimized index that achieves very high performance — up to 160 million operations per second when data fits in memory;" I really dislike when papers make performance claims like this in the introduction. That "160 million" number is so meaningless at face value because everything from the runtime environment to the hardware is going to play a huge role in ops. I rather see h…
It would be nice if they said what workload patterns they’ve optimized for, and which ones they perform poorly on.
The VLDB reviewers of their paper [1] must not have thought much of it because it's accepted as a short paper, which is not a great signal. No comment on the quality of the work though, as I only just started reading it. [1] https://www.microsoft.com/en-us/research/uploads/prod/2018/0...
[2] https://www.microsoft.com/en-us/research/uploads/prod/2018/0... [3] https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt