Some of the stuff I had a chance to work on managed to handle market data
in single digit micros and trading in low tens. That's Java/c++.
With modern day hardware it would be extremely hard (and costly) to push it
much further.
I can easily imagine how going for ASIC and staying under 1 microsecond
produces an edge worth investing in.
Tangentially, there's more to gain from shaving off latency on network
paths than there is from affinitizing work to cores/dies. But that's
digressing from the OP.



On Mon, 9 Apr 2018, 09:00 Avi Kivity, <a...@scylladb.com> wrote:

> Seriously, people are trading on ASICs?
>
>
> The amount of effort going into this is astounding. I can't help thinking
> that it won't end well.
>
> On 04/09/2018 10:55 AM, Greg Young wrote:
>
> To be fair many of the fpga based things have also moved to asics. You
> know you are in for fun when a fpga is too slow.
>
> On Mon, Apr 9, 2018 at 12:58 AM, Martin Thompson <mjpt...@gmail.com>
> wrote:
>
>> 5+ years ago it was pretty common for folks to modify the Linux kernel or
>> run cut down OS implementations when pushing the edge of HFT. These days
>> the really fast stuff is all in FPGAs in the switches. However there is
>> still work done on isolating threads to their own exclusive cores. This is
>> often done by exchanges or those who want good predictable performance but
>> not necessarily be the best.
>>
>> A simple way I have to look at it. You are either predator or prey. If
>> predator then you are mostly likely on FPGAs and doing some pretty advanced
>> stuff. If prey then you don't want to be at the back of the herd where you
>> get picked off. For the avoidance of doubt if you are not sure if you are
>> prey or predator then you are prey. ;-)
>>
>>
>> On Sunday, 8 April 2018 13:51:52 UTC+1, John Hening wrote:
>>>
>>> Hello,
>>>
>>> I've read about thread affinity and I see that it is popular in
>>> high-performance-libraries (for example
>>> https://github.com/OpenHFT/Java-Thread-Affinity). Ok, jugglery a thread
>>> between cores has impact (generally) on performance so it is reasonable to
>>> bind a specific thread to a specific core.
>>>
>>> *Intro*:
>>> It is obvious that the best idea to make it possible that any process
>>> will be an owner of core [let's call it X] (in multi-core CPU). I mean that
>>> main thread in a process will be one and only thread executed on core X.
>>> So, there is no problem with context-switching and cache flushing [with
>>> expect system calls].
>>> I know that it requires a special implementation of scheduler in kernel,
>>> so it requires a modification of [Linux] kernel. I know that it is not so
>>> easy and so on.
>>>
>>> *Question*:
>>> But, we know that we have systems that need a high performance. So, it
>>> could be a solution with context-switching once and at all. So, why there
>>> is no a such solution? My suspicions are:
>>>
>>> * it is pointless, the bottleneck is elsewhere [However, it is
>>> meaningful to get thread-affinity]
>>> * it is too hard and there is too risky to make it not correctly
>>> * there is no need
>>> * forking own linux kernel doesn't sound like a good idea.
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Studying for the Turing test
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to