Peter, I agree with you. I don't believe this is true for the same reasons you outlined. It almost reads like a throwaway statement that would've been easily corrected if properly reviewed and unrushed.
Also, please correct me if I am wrong but, looking at the Table Of Contents on Amazon, it seems like each topic gets only 1 or 2 pages of treatment on average. This leads me to believe that this is a pretty cursory overview of HFT topics. Frankly, any one of the areas involving low-latency coding techniques & configuration could take several pages of background explanation, code examples, benchmarks + graphs, etc. to give it its full due. And I think such treatment is warranted considering that HFT (and Gaming, for that matter) often appear like a foreign world for devs coming from other industries (heck, the C++ community even gave us our own standards committee with SG14). Clocking in at only 280 total pages, I'm beginning to think I may be onto something here with this book characterization. On Fri, Jul 1, 2022 at 10:54 PM Peter Veentjer <alarmnum...@gmail.com> wrote: > Hi, > > I'm reading the following book "Developing High-Frequency Trading > Systems". My goal is not to write any high-frequency trading systems, but > to get some insights into the domain and learn as much as possible from the > applied techniques. It is a Packt book and they are not known for their > quality. But it is written by 3 engineers with a combined HFT experience of > almost 50 years. > > On page 62 of the book, they make the following claim. If you are using a > hyper-threading and there is an interrupt or a system call on one logical > core, then the hyper-sibling will stall as well because both need access to > the kernel (mode switch). > > I don't believe this is correct. Each logical core has its own > architectural state; so its own set of architectural registers and its own > APIC including an interrupt descriptor table. The current privilege level > is stored in the first 2 bits of the CS register and since every logical > core has its own copy of that, the hyper siblings should be able to run > independently no matter if there is a mode switch. > > Of course, disabling hyper-threading will lead to improved performance of > a single core, because it doesn't need to share any resources like rob, > line fill buffers, store buffers, load buffets, execution units, > reservation stations, caches, etc. So that is a valid reason to disable > hyper-threading. > > I'm by no means an X86 expert and certainly not a high-frequency trading > expert. So perhaps I'm missing something. > > Regards, > > Peter. > > > -- > 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. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdChA2kzo1RXHUB3Zh1H5GonVs82BhkCzG7ap4Q1PaUvdg%40mail.gmail.com > <https://groups.google.com/d/msgid/mechanical-sympathy/CAGuAWdChA2kzo1RXHUB3Zh1H5GonVs82BhkCzG7ap4Q1PaUvdg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/mechanical-sympathy/CAFvqqVcpZvyWZbLDSGDpmGu7Zf-TdeotrnmeFS2SZWdpcc_tiw%40mail.gmail.com.
