Yep. Most the ASIC stuff I have seen has been trivial algorithms where
speed was the most important thing.

On Mon, Apr 9, 2018 at 5:03 PM, Wojciech Kudla <wojciech.ku...@gmail.com>
wrote:

> 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.
>>
>


-- 
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.

Reply via email to