hyc

violino:/home/software/leveldb> ./db_bench_mdb --intkey=1
LMDB:       version LMDB 0.9.14: (September 20, 2014)
Date:       Fri Feb  6 01:18:51 2015
CPU:        4 * Intel(R) Core(TM)2 Extreme CPU Q9300  @ 2.53GHz
CPUCache:   6144 KB
Keys:       4 bytes each
Values:     100 bytes each (50 bytes after compression)
Entries:    1000000
RawSize:    99.2 MB (estimated)
FileSize:   51.5 MB (estimated)

hyc

/* Author: Howard Chu <hyc@symas.com> 2023-05-20
 *
 * monitor keyboard activity and toggle keyboard backlight
 * for Lenovo Legion 7 gen6.
 */
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>

hyc

The backtrace for this clearly shows that the GSSAPI library is closing a socket that doesn't belong to it.

Thread 1 (Thread 0x7fc11edfe700 (LWP 54101)):
#0  0x00007fc65e1c7207 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007fc65e1c88f8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007fc65e1c0026 in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007fc65e1c00d2 in __assert_fail () from /lib64/libc.so.6

hyc

root@randomx:~/RandomX/build# ./randomx-benchmark --auto --verify
RandomX benchmark v1.1.4
 - Argon2 implementation: reference
 - light memory mode (256 MiB)
 - JIT compiled mode 
 - hardware AES mode
 - small pages mode
Initializing ...
Memory initialized in 1.42558 s
Initializing 1 virtual machine(s) ...

hyc

commit a4838d293e34ea9eb52a52183ba31ee62f54d036
Author: Howard Chu <hyc@symas.com>
Date:   Thu May 30 10:06:44 2019 +0100

    debug branch

diff --git a/src/cryptonote_core/blockchain.cpp b/src/cryptonote_core/blockchain.cpp
index 108de6a0c..86c44c38f 100644
--- a/src/cryptonote_core/blockchain.cpp
+++ b/src/cryptonote_core/blockchain.cpp

hyc

[hyc@gamba dbbench]$ bin/t_lmdb
LMDB: version LMDB 0.9.70: (December 19, 2015)
Date:      Sat Oct  7 19:18:38 2017
CPU:            4 * AMD A10-4600M APU with Radeon(tm) HD Graphics
CPUCache:   2048 KB
Keys:      16 bytes each
Values:  100 bytes each (50 bytes after compression)
Entries:        1000000
RawSize:        110.6 MB (estimated)
FileSize:   62.9 MB (estimated)

hyc

violino:/home/software/dbbench/bin> foreach i (*)
foreach? rm -rf /tmp/dbbench-1000/*
foreach? ./$i
foreach? end
Basho LevelDB: version 1.9
Date:	   Thu Sep 28 02:45:11 2017
CPU:		4 * Intel(R) Core(TM)2 Extreme CPU Q9300  @ 2.53GHz
CPUCache:   6144 KB
Keys:	   16 bytes each
Values:	 100 bytes each (50 bytes after compression)

hyc

I believe this is directly comparable to the results published here
 http://influxdb.com/blog/2014/06/20/leveldb_vs_rocksdb_vs_hyperleveldb_vs_lmdb_performance.html

My laptop has 8GB of RAM but I pared it down to 4GB by turning off swap and creating a large enough file
in tmpfs to drop free RAM down to 4GB.

This is the code prior to using Sorted Duplicates.

The RocksDB performance is amazingly poor.

hyc

/* RFC6238 TOTP */

#include <openssl/sha.h>
#include <openssl/hmac.h>

#define HMAC_setup(ctx, key, len, hash)	HMAC_CTX_init(&ctx); HMAC_Init_ex(&ctx, key, len, hash, 0)
#define HMAC_crunch(ctx, buf, len)	HMAC_Update(&ctx, buf, len)
#define HMAC_finish(ctx, dig, dlen)	HMAC_Final(&ctx, dig, &dlen); HMAC_CTX_cleanup(&ctx)

typedef struct myval {

hyc

Inspired by this RocksDB post, I started playing with this "readwhilewriting" test as well. 
https://github.com/facebook/rocksdb/wiki/RocksDB-In-Memory-Workload-Performance-Benchmarks

Of course the data here is only a tiny fraction of the size of the RocksDB report. (I have
a larger test running that's of a more comparable size, but it will probably be a couple
more days before all of the tests finish.)

So - tested LevelDB 1.17, Basho LevelDB 1.9, BerkeleyDB 5.3.21, HyperLevelDB 1.14,
LMDB 0.9.12rc, RocksDB 3.2, TokuDB 4.6.119, and WiredTiger 2.2.0 (both LSM and Btree).
That's a lot of tests to run, trust me.