wallstprog

- pldd (https://man7.org/linux/man-pages/man1/pldd.1.html) shows the actual dynamic libs linked into a running process. (Contrast this with ldd, which shows what the dynamic libs would be based on the current shell environment).

- libtree (https://github.com/haampie/libtree) which shows dependencies similarly to ldd, but in tree format.

Comment · 2 years ago

You might want to take a look at https://github.com/nyfix/memleaktest

We've open-sourced the tools we use to run valgrind (and ASAN) on large mixed C++/Java code bases. The JVM in particular triggers a slew of errors which can make filtering valgrind output impractical, but the scripts we developed can handle that. FWIW, we use these tools every day on the code that goes into NYFIX Marketplace (https://www.broadridge.com/financial-services/capital-market...).

Comment · 2 years ago

I thought it was a brilliant design, but it was dog-slow on hardware at the time. I keep hoping someone would revive the design for current silicon, would be a good impedance match for modern languages, and OS's.

Comment · 2 years ago

So it seems that TB prioritizes throughput over latency, similar to VoltDB for instance -- is that correct?

Comment · 3 years ago

At my day job we run > 50 million messages per day through ZeroMQ, and have been quite pleased with its performance and stability (https://github.com/nyfix/OZ/tree/master#who-uses-it).

But the truth is that ZeroMQ has a steep learning curve, and some rather sharp edges that can leave nasty cuts if one is not careful.

If you're interested in becoming familiar with ZeroMQ, you might want to check out our implementation: <https://github.com/nyfix/OZ/>.

Comment · 3 years ago

Well, the original non-thread-safe sockets (e.g., ZMQ_SUB, etc.) were that way because they support multi-part messages. And yes, the fact that they are not thread-safe is a bit of a stumbling-block for ZeroMQ newbies (including me, back in the day).

However, it's not that hard to work around their non-thread-safe nature with a single dispatch thread (e.g., see <https://github.com/nyfix/OZ/blob/master/src/transport.c#L457>), and that approach has other potential benefits.

In any case, newer socket types (e.g., ZMQ_CLIENT) have since been defined that are thread-safe, but necessarily don't support multi-part messages. (They tend to be different in other ways as well -- e.g., ZMQ_RADIO/ZMQ_DISH are "sort of" replacements for the original ZMQ_PUB/ZMQ_SUB sockets, but have other constraints as well).

Comment · 3 years ago

Unlikely, but they seem to be different things altogether. BlazingMQ appears to be a traditional message queue (think ActiveMQ), with message peristence. ZeroMQ is more of a network middleware (think Tibco Rendezvous), and does not include persistence.

BlazingMQ also appears to be more of a "platform" or "service" that an app can use (sort of like Oracle, say) -- ZeroMQ includes libraries that one can use to build an app, service or platform, but none is provided "out of the box".

Which makes it harder to get started with ZeroMQ, since by definition every ZeroMQ app is essentially built "from scratch".

If you're interested in ZeroMQ, you may want to check out OZ (https://github.com/nyfix/OZ), which is a Rendezvous-like platform that uses the OpenMAMA API (https://github.com/finos/OpenMAMA) and ZeroMQ (https://github.com/zeromq/libzmq) transport to provide a full-featured network middleware implementation. OZ has been used in our shop since 2020 handling approx 50MM high-value messages per day on our global FIX network.