to my high freak friends.

Nonius · Post by **Nonius** » Tue Jul 26, 2016 2:07 pm

qSharp seems to work reasonably well

TonyC · Post by **TonyC** » Thu Jul 28, 2016 5:04 am

take it from an APLer, if your using kdb/q, pick up a book called "q tips" by Psaris ... and "q for mortals" by Borror

TonyC · Post by **TonyC** » Thu Jul 28, 2016 5:05 am

take it from an APLer, if your using kdb/q, pick up a book called "q tips" by Psaris ... and "q for mortals" by Borror

jslade · Post by **jslade** » Fri Jul 29, 2016 1:12 am

If Nonius was using q before talking to me, I would have to fly out to London and issue a noogie.

qSharp is an IPC framework though; no relation to the APL awesome-sauce.

If you need a non-blocking socket, http://liblfds.org is pretty good.

Nonius · Post by **Nonius** » Fri Jul 29, 2016 5:03 am

hey jslade! apologies I ain't using it! promise!

the guy sending me some messages might be. Ok, I'll reach out to him.

thanks for the nonblocking socket link.

ast4 · Post by **ast4** » Sun Aug 14, 2016 5:12 pm

A bit slow to the party, but what exactly are you trying to solve? Are you running single strategy/config process because you're very sensitive to latency? Or are you running multi strategy/config out of a single process and only somewhat latency sensitive? etc..

Another poster pointed this out, which I agree with - the definition of 'better' is largely problem dependent. For example, in the second example I gave, you may run into issues if you're doing spin and processing all book events as a flood of events comes in.

Since someone else mentioned core pinning. You can also look into setting the scheduling policy (http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html) and priority (http://man7.org/linux/man-pages/man2/setpriority.2.html).

liblfds-admin · Post by **liblfds-admin** » Sun Aug 21, 2016 7:39 pm

> If you need a non-blocking socket, http://liblfds.org is pretty

> good.

Hi. I am the author of liblfds.

There are no socket APIs in the library. I may be wrong, but I think you may mean a queue?

The library as of version 7.1.0 contains the "standard" M&S queue for many/many/unbounded, but the performance of that queue is poor (better than all locking queues using the same design, but still, poor; and be aware that if all threads are on the same physical core, the M&S queue will always be slower than locking queues).

There is a bounded/many/many queue, but it is not lock-free; there is a very small window where locking can occur. There is also no benchmark, so there are no hard figures for performance. I expect it to be about three times faster than the M&S queue, but I could be completely wrong.

There is bounded/single/single queue, which is memory barrier only, and so goes like the blazes - no benchmark yet, but I expect ten million plus operations per second. The problem is bounding.

7.2.0 - not yet released - contains an unbounded/single/single, which should fulfill that particular niche well.

netmonk · Post by **netmonk** » Wed Sep 14, 2016 11:58 am

Not only pinning process to one core is required, also isolating this specific core (and may be others) from the scheduler (isolcpu) to avoid other process to run on this specific core.

You can also avoid the kernel tick which introduce huge jitter (tickless mode).

You can also pine network interruption on specific core if you are not doing kernel bypass. With good care of wich core you bind them to have efficient cache communication with kernel and process.

Then you can tweak sysctl, tcp/udp queue size, steering... vmstat.interval.

Non blocking socket, infinite pooling.

If you are interested and i see some java here, you can join the "mechanical sympathy" google groups for very good technical talks about low latency and "high freaks" especially for Java

(im not using java btw).

Regards