slice_deque
Disruptor
slice_deque | Disruptor | |
---|---|---|
2 | 30 | |
152 | 17,056 | |
- | 0.5% | |
0.0 | 5.4 | |
over 2 years ago | 4 months ago | |
Rust | Java | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
slice_deque
-
A lock-free ring-buffer with contiguous reservations (2019)
> It's not an attack on the wording, but the correctness of your first bullet point. `unsafe` is appropriate for the initialization of a ring buffer in Rust. That's true for using `mmap` or anything in "pure" Rust using the allocator API to get the most idiomatic representation (which can't be done in safe or stable Rust). It's not one line. It's also not platform dependent, the code is the same on MacOS, Linux, and Windows the last I tried it.
We're not talking about the same thing then.
I'm talking about this code here: <https://github.com/gnzlbg/slice_deque/tree/master/src/mirror...> It is absolutely platform specific.
Yes, most ring buffer implementations feature a little bit of `unsafe` code. No, it doesn't make sense to say "I have a tiny amount of `unsafe` already, so adding more has no cost."
> But if your bottleneck is determined by the frequency at which channels get created or how many exist then I would call architecture into the question. ... This last month I've written a lock-free ring buffer to solve a problem and there's exactly one in an application that spawns millions of concurrent tasks.
Okay, but a lot of applications or libraries are written to support many connections, and you don't necessarily know when writing the code (or even when your server receives them) if those connections will be just cycled very quickly or will be high-throughput long-lived affairs. Each of those probably has a send buffer and a receive buffer. So while it might make sense for your application to have a single ring buffer for its life, applications which churn through them heavily are completely valid.
-
Go is about to get a whole lot faster
There is a single contiguous memory allocation, which mirrors itself.
One thread produces elements and pushes them at the tail (e.g. I/O bytes, in batch), and one thread consumes as many elements as possible in batch from the other end (e.g. all bytes available, in batch).
The mirror is required to allow processing all elements in the deque as if they were adjacent in memory.
This is the library i am using, the array contains an explanation : https://github.com/gnzlbg/slice_deque
Disruptor
-
Gnet is the fastest networking framework in Go
https://lmax-exchange.github.io/disruptor/#_what_is_the_disr.... Unfortunately IIUC writing this in Go still prevents the spin-locked acceptor thread from achieving the kind of performance you could get in a non-GC language, unless you chose to disable GC, so I'd guess Envoy is still faster.
https://gnet.host/docs/quickstart/ it's nice that you can use this simply though. Envoy is kind of tricky to setup with custom filters, so most of the time it's just a standalone binary.
[0] https://blog.envoyproxy.io/envoy-threading-model-a8d44b92231...
[1] https://lmax-exchange.github.io/disruptor/#_what_is_the_disr...
-
A lock-free ring-buffer with contiguous reservations (2019)
See also the Java LMAX Disruptor https://github.com/LMAX-Exchange/disruptor
I've built a similar lock-free ring buffer in C++11 https://github.com/posterior/loom/blob/master/doc/adapting.m...
-
JEP Draft: Deprecate Memory-Access Methods in Sun.misc.Unsafe for Removal
"Why we chose Java for our High-Frequency Trading application"
https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
LMAX Disruptor customers
https://lmax-exchange.github.io/disruptor/
Among many other examples.
-
LMAX Disruptor – High Performance Inter-Thread Messaging Library
Current documentation
https://lmax-exchange.github.io/disruptor/
-
Progress on No-GIL CPython
LMAX Disruptor has on their wiki that average latency to send a message from one thread to another at 53 nanoseconds. For comparison a mutex is like 25 nanoseconds and more if Contended but a mutex is point to point synchronization.
The great thing about it is that multiple threads can receive the same message without much more effort.
https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...
https://gist.github.com/rmacy/2879257
I am dreaming of language that is similar to Smalltalk that stays single threaded until it makes sense to parallise.
I am looking for problems to parallelism that are not big data. Parallelism is like adding more cars to the road rather than increasing the speed of the car. But what does a desktop or mobile user need to do locally that could take advantage of the mathematical power of a computer? I'm still searching.
- Disruptor 4.0.0 Released
-
Anything can be a message queue if you use it wrongly enough
Database config should be two connection strings, 1 for the admin user that creates the tables and anther for the queue user. Everything else should be stored in the database itself. Each queue should be in its own set of tables. Large blobs may or may not be referenced to an external file.
Shouldn't a message send be worst case a CAS. It really seems like all the work around garbage collection would have some use for in-memory high speed queues.
Are you familiar with the LMAX Disruptor? Is is a Java based cross thread messaging library used for day trading applications.
https://lmax-exchange.github.io/disruptor/
-
Any library you would like to recommend to others as it helps you a lot? For me, mapstruct is one of them. Hopefully I would hear some other nice libraries I never try.
Disruptor for inter-thread messaging
-
Measuring how much Rust's bounds checking actually costs
I have never worked in any industries where a perf margin was that small. It is funny, in HFT there are folks using Lmax (Java) and then you have folks writing their own TCP/IP stacks on FPGAs to do trading.
What are some alternatives?
JCTools
Agrona - High Performance data structures and utility methods for Java
fastutil - fastutil extends the Java™ Collections Framework by providing type-specific maps, sets, lists and queues.
MPMCQueue.h - A bounded multi-producer multi-consumer concurrent queue written in C++11
Eclipse Collections - Eclipse Collections is a collections framework for Java with optimized data structures and a rich, functional and fluent API.
Javolution
HPPC - High Performance Primitive Collections for Java
Primitive-Collections - A Primitive Collection library that reduces memory usage and improves performance and provides a lot of QoL
Trove
GS Collections - GS Collections has been migrated to the Eclipse Foundation, re-branded as Eclipse Collections. https://www.eclipse.org/collections/
salsa - A generic framework for on-demand, incrementalized computation. Inspired by adapton, glimmer, and rustc's query system.
Koloboke - Java Collections till the last breadcrumb of memory and performance