[pclmulqdq]

I also see the update in response to this comment, and it puts everything into perspective. You haven't changed the meaning of "write done," you have just been comparing your reciprocal throughput against Redis's latency, and I think you have been confusing those two.

"600 ns" then really means "1.6M QPS of throughput," which is a good number but is well within the capabilities of many similar offerings (including several databases that are truly persistent). It also says nothing about your latency. If you want to say you are 2-6x faster than Redis, you are going to have to compare that number to Redis's throughput.

[mehrant]

Reading your comment about comparing the throughput to Redis, it seems to me that you haven't read the benchmark article really. In there, we're in fact comparing the "throughput" and not the latency. allow me to quote some of the throughput numbers from the article mentioned above:

Single Operation Performance

Redis Single Operations

SET: 273,672.69 requests per second (p50=0.095 ms)

GET: 278,164.12 requests per second (p50=0.095 ms)

HPKV Single Operations

INSERT: 1,082,578.12 operations per second

GET: 1,728,939.43 operations per second

DELETE: 935,846.09 operations per second

Batch Operation Performance

Redis Batch Operations

SET: 2,439,024.50 requests per second (p50=0.263 ms)

GET: 2,932,551.50 requests per second (p50=0.223 ms)

HPKV Batch Operations

INSERT: 6,125,538.03 operations per second

GET: 8,273,300.27 operations per second

DELETE: 5,705,816.00 operations per second

The latency of 600ns as I mentioned is a local vectored interface call and not over the network. the is not how we compared the system with Redis. the above numbers are using our RIOC API over the network, in which HPKV behaves like a server similar to a Redis server.

The numbers above are compared with Redis in-memory and HPKV is still 2-6x faster. even if you assume HPKV as just an in-memory KV store with no persistence.