RocksDB VS skywater-pdk

RocksDB: A high-performance embedded database optimized for multi-core CPUs and fast storage like SSDs. Its use of a log-structured merge-tree (LSM tree) makes it suitable for applications requiring high throughput and efficient storage, such as streaming data processing.

[RocksDB](https://rocksdb.org/) isn’t a distributed storage system, fwiw. It’s an embedded KV engine similar to LevelDB, LMDB, or really sqlite (though that’s full SQL, not just KV)

To output the top 3 rocks, our engine has to first store all the rocks in some sorted way. To do this, we of course picked RocksDB, an embedded lexicographically sorted key-value store, which acts as the sorting operation's persistent state. In our RocksDB state, the diffs are keyed by the value of weight, and since RocksDB is sorted, our stored diffs are automatically sorted by their weight.

The in-memory version of Memgraph uses Delta storage to support multi-version concurrency control (MVCC). However, for larger-than-memory storage, we decided to use the Optimistic Concurrency Control Protocol (OCC) since we assumed conflicts would rarely happen, and we could make use of RocksDB’s transactions without dealing with the custom layer of complexity like in the case of Delta storage.

I was looking at https://github.com/facebook/rocksdb/ but it seems to not allow queries by value, as my last requirmenet.

Tuning RocksDB well is a very very hard challenge, and one that I am happy to not do day to day anymore. RocksDB is very powerful but it comes with other very sharp edges. Compaction is one of those, and all answers are likely workload dependent.

If you are worried about write amplification then leveled compactions are sub-optimal. I would try the universal compaction.

- https://github.com/facebook/rocksdb/wiki/Universal-Compactio...

It's fairly challenging to write a KV database, and takes several years of development to get the balance right between performance and reliability and avoiding data loss. Maybe read through the documentation for RocksDB https://github.com/facebook/rocksdb/wiki/RocksDB-Overview and watch the video on why it was developed and that may give you an impression of what is involved.

LMDB is much more sain in the sense that it supports real ACID transactions instead of savepoints for RocksDB. The latter is heavy and consumes a lot more memory for a lot less read throughput. However, RocksDB has a much better parallel and concurrent write story, where you can merge entries with merge functions and therefore write from multiple CPUs.

https://github.com/facebook/rocksdb/issues?q=is%3Aissue+clic...

Here are some bugs in JeMalloc:

Preferably Intel compatible or able to run Linux? Something I can build in my garage or in a simple microprocessor fab.

https://github.com/google/skywater-pdk

It looks neat, but the process node is 1 um with 3 metal layers.

The open Skywater PDK is 130 nm : https://github.com/google/skywater-pdk (though I don't know how reliable the PDK is?)

From working in a somewhat related discipline, the PDKs for the high end nodes (think tsmc N16 and lower) are quite hard to obtain and require your org to pass security audit. In addition to that the cadence licenses are priced very much for a big-org rather than a startup.

Does your chip absolutely need a modern node? I'm assuming you've seen the open source skywater pdk, but here it is just in case. https://github.com/google/skywater-pdk

If you need a free PDK, check out: https://github.com/google/skywater-pdk

That would be really neat, but I haven't seen anyone even make a CMOS imager on SKY130.

https://github.com/google/skywater-pdk

One could make an array of thermopiles, like the hacker that made their own imager out of discrete diodes (digiOBSCURA) . But each pixel would cost $7.

https://www.digikey.com/en/products/detail/excelitas-technol...

One might be able to make an array of thermistors (possibly with active cooling using a peltier) like the diycamera (digiOBSCURA) below. Might be an application of combining many RC oscillators in a tree and recovering the signal with an FFT. I have a gut feeling this is possible, but haven't show it.

https://www.digikey.com/en/products/detail/panasonic-electro...

https://github.com/IdleHandsProject/diycamera (digiOBSCURA)

One could experiment with microbolometers on tinytapeout. https://elicit.org/search?q=cmos+microbolometer

https://tinytapeout.com/

Unlike x86_64 which can only legally be produced by two and one-quarter companies, RISC-V is a permissively open-sourced ISA so anyone can make a chip. Literally, you can download Verilog of Berkeley Rocket cores from Github and run it on an FPGA, or prep it to send to SkyWater to fab at 130nm.

Taping out an actual chip inevitably involves IP that's not yours, e.g. the standard cell library and other 'physical' IP like memories and flash. You cannot open source that as it is not yours and in general the owners of it won't want to open source it either (though there are exceptions e.g. the Skywater 130nm PDK https://github.com/google/skywater-pdk).

In OpenTitan we've built all the 'logical' IP ourselves from the ground up. This is the Verilog RTL you can see in our repository but you need the 'physical' IP to make a real chip. We haven't built any physical IP so we need to get it from the traditional industry sources which means traditional industry licensing (i.e. very much not open).