Common wisdom was that it's impossible to design an ASIC-proof Proof of Work algorithm. tevador, SChernyk, and I proved that bit of "wisdom" wrong with RandomX. Folks who understand hardware design actually get it. np.reddit.com/r/Buttcoin/com…
We started over 2 years ago from the simple insight that ASICs can only optimize individual algorithms, and thus we needed a dynamic approach. old.reddit.com/r/Monero/comme…
Months of prototyping and testing went in before we arrived at the current design.
It would be a fair statement to say that we've changed the world's understanding of Proof of Work and ASIC resistance. tevador has gone on to design other dynamic algorithms for different work scenarios, like Equi-X for the TOR Project. lists.torproject.org/pipermail/tor-…
These insights aren't unique, but are perhaps too rare these days.
Donald Knuth summed it up well back in 1968. "By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality."
To be a good software engineer you must understand the hardware as well.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Symas is still working on this. But the Samba LDB modules are unsuitable for use within slapd. We are, unfortunately, reimplementing most of them as slapd overlays, tho still reusing as many Samba libs as possible.
Samba team won't accept OpenLDAP code.
@jpmens Understandably; they lack expertise to maintain it. Just as OpenLDAP Project would reject code we cannot maintain.
@jpmens Project integrations like this require a 3rd party competent with both projects. Thus, Symas' involvement.
Designing software for efficiency is more important than designing for scale. Achieving efficiency gives you scale for free.
Writing efficient software means you compute only what is needed - no more and no less. It's a simple rule but with far-reaching effects. The OpenLDAP 20yr retrospective offers multiple examples for illustration:
@fanf42@walterbio LMDB is significant of course, but even back-bdb/hdb had dropped latency down to 0.8ms. There were huge improvements all across the stack. Faster encode/decode in liblber, faster processing in libldap, complete restructuring of slapd internal APIs, etc.
@fanf42@walterbio The result of years of intensive profiling and testing.
Some simple rules throughout, of course: avoid memcpy, avoid malloc, avoid strlen. These 3 functions used to be 75% of execution time. E.g. liblber now does zero-copy decode.
@fanf42@walterbio Use of plain char* C strings inside slapd was eliminated; use Bervals everywhere instead. Saved endless repeated calls to strlen. (Another rule - don't repeat the same computation over the same data; keep the result if it will be needed again soon.)