Viewing profile — rigtorp
rigtorp
HN member- Joined
- Fri, Sep 12, 2014, 10:06 PM UTC
- HN karma
- 55
- Public activity
- 49 items
- HN profile
- View on Hacker News ↗
About rigtorp
Recent public activity
-
comment
Comment #48853974
You would use one of those approaches: If you align and pad each slot there won't be any false sharing and the stream prefetcher can kick in if there's only one producer or consume…
-
comment
Comment #48851896
Here's my widely used implementation of this approach in C++: https://github.com/rigtorp/MPMCQueue
-
comment
Comment #48851869
That looks like a rewrite of my earlier work: https://rigtorp.se/ringbuffer/
-
comment
Comment #46438587
Better to use the Gmail API to incrementally backup your mail: https://github.com/rigtorp/gmbackup
-
comment
Comment #46438563
I have a tool that saves each mail as a single file using the Gmail API: https://github.com/rigtorp/gmbackup
-
comment
Comment #45293691
Interesting, of course many computations can be expressed as a graph. In the case of the bipartite graph we perform belief propagation on to decode LDPC where is the optimization f…
-
comment
Comment #45290871
How is belief propagation used for decoding LDPC codes related to FFT?
-
comment
Comment #36492105
I think it will be invalidated due to RFO when the reader reads the write index. Only when multiple readers reads the same cache line without any intervening write will the RFO heu…
-
comment
Comment #36491206
It might also be better for performance since the two cores can RFO the buffer pointer cache lines from each other.
-
comment
Comment #36491178
There might be an additional optimization in having the writer also cache it's write index on the cache line together with the read index cache. This way the writer would only do w…
-
comment
Comment #32891070
I have something similar but in C++: https://github.com/rigtorp/c2clat
-
comment
Comment #32245537
You might need to add -fno-omit-frame-pointer to help ASAN unwind the stack.
-
comment
Comment #28564816
You're incorrect, garbage collection would be the biggest problem for that use case. You have to be really careful even with your C/C++ code, warming up the branch predictor betwee…
-
comment
Comment #27760269
The standard says that a thread must eventually terminate, do an atomic operation or do IO. So the while(lock.exchange(true)); loop is different. Also keep in mind that C++11 speci…
-
comment
Comment #27759541
There's even more discussion on the lock memory ordering on Stackoverflow: https://stackoverflow.com/questions/61299704/how-c-standard-... Taking a lock only needs to be an acquire…
-
comment
Comment #27680855
Yes that's right!
-
comment
Comment #27680473
Well isn't that just a normal lock/mutex of the "lightweight" type (only enter kernel on contention)? You cannot use that in non-preemptible context.
-
comment
Comment #27680379
Deploy to production :). You can use a model checker that understands C++11 memory model.
-
comment
Comment #27680355
His rant only applies to preemptible threads. If you don't have preemptible threads spinlocks works great. The linux kernel uses them in non-preemptible contexts.
-
comment
Comment #27680275
It's nonsense to do this when you can be preempted. But you can run one thread per core and avoid preemption. You can tune the linux kernel to avoid almost all preemption, due to T…
-
comment
Comment #27680141
I now think it's actually this part of the standard that prevents it: http://eel.is/c++draft/intro.multithread#intro.progress-7 Basically a compiler can not optimize a non-deadlock…
-
comment
Comment #27680094
Yes this re-ordering can cause a deadlock. But it's not an allowed optimization to change a non-deadlocking program into a potentially deadlocking program, so this reordering can n…
-
comment
Comment #27679828
I think reitzensteinm was referring to the actual data inside the ring. There is a false sharing problem there particularly for the MPMC type ring buffer like disruptor. The soluti…
-
comment
Comment #27679801
You can align and pad each ring buffer slot to the cache line size. Example https://github.com/rigtorp/MPMCQueue/blob/master/include/rig...
-
comment
Comment #27679720
Ringbuffers and thread-per-core architecture is great for low latency transaction processing systems, like exchanges and trading systems. Sometimes you don't have time to do things…