Earlier quoted context omitted.
In HFT single-threaded performance is king so that's why we're all still on Intel. AMD is making progress but not just quite there yet.
Huh. My experience has been that AMD wins that unless your application is so small that it can fit into Intel's smaller cache. And the new 3D architecture from AMD I thought would make your developers drool, allowing them to actually inline everything instead of being scared of building apps that are too big to fit into cache
Magic-trace – High-resolution traces of what a process is doing
101–110 of 146 posts
Re: Magic-trace – High-resolution traces of what a process is doing
#102Earlier quoted context omitted.
In HFT single-threaded performance is king so that's why we're all still on Intel. AMD is making progress but not just quite there yet.
To be clear: bitcharmer says "we" to mean "fellow HFTs" not "Jane Street".
Re: Magic-trace – High-resolution traces of what a process is doing
#103Re: Magic-trace – High-resolution traces of what a process is doing
#104Earlier quoted context omitted.
how do you access this DDIO feature if you are writing a C or C++ application? intrinsics?
DDIO operates mostly transparently to software, with the I/O controller feeding DMAs into a slice of L3. Hardware can opt out by setting PCIe TLP header hints, and you have some system-wide configurability via MSRs, but it's not something a userspace application can take into its own hands.
Re: Magic-trace – High-resolution traces of what a process is doing
#105Earlier quoted context omitted.
I think they are mostly here to hire people. Not to educate.
If by "here" you mean "at academic conferences", then I'd ask you why they bother to actually do primary research and publish it if they have no interest in sharing knowledge. If all they wanted was to hire people, they... would. You don't have to sponsor a conference to attend or hire from that conference. And you especially also don't need to sponsor additional workshops, or carbon neutrality initiatives, or anythi…
Re: Magic-trace – High-resolution traces of what a process is doing
#106Earlier quoted context omitted.
I doubt that it is used for actual trading. Maybe the OP can elaborate what the live infrastructure and backtesting setup look like?
Of course they use it for trading and everything around for many years.
Re: Magic-trace – High-resolution traces of what a process is doing
#107Being a person who works with FPGAs. For all their difficulties, waveforms of both simulation and real-time tapping capabilities are indispensable for tracking what happens before, during, and after an erroneous event occurs. One thing I always miss when going back to software development is some sort of 'waveform' of what the process has done over time and tracking the state of the system over that same course of ti…
Re: Magic-trace – High-resolution traces of what a process is doing
#108You should make it clearer in the magic trace Readme that the UI service fork used for viewing and analyzing the traces is also available should one want to deploy it locally or in a situation without Internet access: https://github.com/janestreet/perfetto/ It is mentioned in the documentation but for anyone quickly skimming and expecting a SaaS pricing model underneath (I think many do now), that isn't obvious. From…
The magic of PR's :)
Re: Magic-trace – High-resolution traces of what a process is doing
#109I worked on a very similar (if not identical lol) project at a job once upon a time and the biggest problem I had (and one that I never really solved well) was recovering call stacks from trace data. I effectively ended up using DWARF and just simulating execution and keeping a call stack in the decoder. This mostly worked fine for small and simple programs, but I ran into SO MUCH trouble because I found that (at least on my generation of cores) IPT actually overflows and drops packets very frequently if you have too many calls/returns too quickly. This is largely not an issue for C code but once you start getting into more dynamic languages with fancy features, IPT cannot keep up. Once packets get dropped, the entire call stack for the entire rest of the thread is ruined since you have no idea who called/returned in the dropped packets.
One option that we had but didn't really chase down due to time was maybe combining IPT with low frequency stack traces so that we can both just reset every so often and, if needed, work backwards/apply heuristics in order to arrive at that next callstack.
How did y'all manage this? Your call stacks look totally correct and I'm very impressed :)
Re: Magic-trace – High-resolution traces of what a process is doing
#110Earlier quoted context omitted.
I think for a lot of people there's a pretty big difference between these two business models: - We use cash to buy circuit boards, screens, enclosures, etc, write software, and sell mobile phones. - We use cash to rent a building, order pallets of inventory, and sell that inventory locally to walk-in customers. - We use cash to buy shares, hold onto them for a bit, and sell those same shares and make money off the s…
Yes, this is pretty much it. As I said in another comment, Jane Street does not have customers for whom they provide goods or services. Their primary business model is using the company's own money for investments, and that's a business model that I don't love.
Not exploiting teenagers in some 3rd world country?
Not gambling with your pension?
Not manipulating some physical commodity like oil?
What’s the problem here?