Live data from Hacker News

Magic-trace – High-resolution traces of what a process is doing

github.com

101–110 of 146 posts

Re: Magic-trace – High-resolution traces of what a process is doing

#101
post #42

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

Not my experience at all and I work across different teams who own different latency sensitive apps. Most of them have unhygienically huge working sets.

Re: Magic-trace – High-resolution traces of what a process is doing

#102
post #45

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.

To be clear: bitcharmer says "we" to mean "fellow HFTs" not "Jane Street".

Yes. Thanks, should have made that more explicit.

Re: Magic-trace – High-resolution traces of what a process is doing

#104
post #90
post #86

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

so is this taken advantage of by the OnLoad drivers of solarflare cards, for example?

Re: Magic-trace – High-resolution traces of what a process is doing

#105
post #85

Earlier 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…

because they are hoping to run into interesting people to hire. why would they share knowledge otherwise? if they are interested in doing that, why not share all the details of their tech stack and what they are doing exactly in the market? it's very hard to hire, especially with FAANGs who compete with them for talent.

Re: Magic-trace – High-resolution traces of what a process is doing

#106
post #84

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

cool, so how about the OP shares the details of how they use it for trading?

Re: Magic-trace – High-resolution traces of what a process is doing

#107

Being 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…

Ha, this was my experience as well when getting into hardware after spending forever in software. It's SO amazing being able to just shoot a program through simulation and then look at the waveform to see how an instruction propagates down a pipeline. Debugging concurrency issues on hardware (i.e. incorrect re-ordering/concurrent scheduling) is honestly so much easier than debugging software concurrency because you often can't even see the entire system state. We're starting to see software catch up with things like time-travel debug with instruction tracing (whether Intel Processor Trace or ARM CoreSight tracing) but the analysis tools for these sorts of things have nothing on wave analysis programs. They either force you into a linear interface (GDB time travel) which makes actually finding the issue a pain in the ass or they simply don't give you the granularity of data that you need.

Re: Magic-trace – High-resolution traces of what a process is doing

#108
post #34
post #14

You 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 :)

Are people generally cool with unsolicited PRs to "editorial" content? I'd have assumed that stating or not stating something in a README is mostly an intentional decision.

Re: Magic-trace – High-resolution traces of what a process is doing

#109
Can I ask an office hours type question?

I 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

#110

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

Company spends its own money to make money for itself?

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?

Post reply on HN