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 <[email protected]> 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, <[email protected]> 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 <[email protected]> >> 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 [email protected]. >>> 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 [email protected]. >> 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 [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
