That doesn’t make sense. Memory can’t be slower than disk - disk is either physical, or memory backed - which means its upper speed limit is the memory speed limit.
If the presentation means to imply that ethernet is so fast - faster than memory busses themselves - that you could fan out to achieve speed faster than memory - that doesn’t make help - because either it is DMA - going to disk (which is slower), or going to the CPU - which can only read memory at the speed of the memory bus. You could theoretically achieve “ultra speeds” with multicasting, on a super fast ethernet bus - but the source is still probably limited to memory speeds. So the abstract you provided doesn’t jive with me. > On May 24, 2025, at 7:06 PM, Jason E. Aten <j.e.a...@gmail.com> wrote: > > This is an amazing talk from last year 2024 March 22 Qcon from > the TigerBeetle CEO, Joran Greef. Zig has lessons for Go. > > "Redesigning OLTP for a New Order of Magnitude" > https://www.infoq.com/presentations/redesign-oltp/ > > Early on the talks covers that latest trends in memory vs network vs disk, > (hint: at 800GB ethernet means memory is now the bottleneck, and > it is slower than disk(!)). > > Greef also talks about Deterministic Simulation Testing (DST) and > gives a highly compelling demo for why you want it. > > He points out that replication algorithms like Paxos and Raft, and points > out that a single sector fault on one machine can create global > data loss. Yikes. > (See 35 minutes in) > > Again, the video at 35:00 gives a very strong critique of Raft vs VSRR > > arguing raft too simple/inappropriate (assumes perfect disks) > > and for actual faulty disks can get blocked and not be fault > > tolerant at all. They use VSRR in TigerBeetle, plus NASA/Fortran > > style "pre-allocate all memory". > > > > TigerBeetle is Apache 2 open source. It is written in Zig but has > > lessons for software using Go throughout. His discussion of > > optimizing write compaction in LSM trees is fascinating, > > as is integrating consensus with replication (2018 best paper > > at FAST from Alagappan et al), and using > > speculative replicated state machine > > execution to avoid stalling on bad storage sectors -- I > > expect all of these to be the future of databases. > > > > Five stars. > > > > Enjoy, > > Jason > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/b9aab0c5-e52e-4950-a98b-11f539c56c83n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/b9aab0c5-e52e-4950-a98b-11f539c56c83n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/AF5C3378-716D-4252-990D-7087C01A39F9%40ix.netcom.com.