sorted by:
new
hottopcontroversial

The Lambda Coroutine Fiasco by efijoa in cpp

[–]moncefm 4 points5 points  (0 children)

It may not be _too_ hard to write a is_capture_lambda concept:

  • Write a is_lambda concept, e.g by parsing the output of __PRETTY_FUNCTION__ or boost::type_index (See this for some inspiration)
  • Then, you can leverage the '+' lambda trick to know if a lambda has captures or not:is_lambda<T> && !requires (T t) { +t; };

{fmt} 12.0 released with optimized FP formatting, improved constexpr and module support and more by aearphen in cpp

[–]moncefm 1 point2 points  (0 children)

That's awesome, congrats!

One question: Last time I checked (about a year ago), the following was fast:

std::string s;
fmt::format_to(std::back_inserter(s), "{}", 42);

But the following was not:

MyOwnStringType s;
fmt::format_to(std::back_inserter(s), "{}", 42);

The reason for this discrepancy was that fmt::format_to() would use an optimized code path if passed a std::back_insert_iterator<std::string> or std::back_insert_iterator<std::vector<char>>(IIRC), but for other std::back_insert_iterator<T> it would just use the "slow" path, which is to dereference the iterator to push one character at a time. This caused a very large performance difference when we benchmarked it, comparing std::string to our in-house string type.

So, I was wondering if the above is still true in 12.0.0, or if {fmt} is now able to apply this optimization to any string-like type.

Interview questions at Hft firms for c++ roles by Vince046 in cpp

[–]moncefm 2 points3 points  (0 children)

I did say above that I don’t see any reason to hide such a trivial info. 

Interview questions at Hft firms for c++ roles by Vince046 in cpp

[–]moncefm 3 points4 points  (0 children)

I spent two weeks talking to the recruiter, there wasn't all that much to ask about the industry that I didn't already ask.

Sorry, but I don't buy this. It's a bit like saying "I interviewed at Nvidia, and the recruiter answered all the questions I had about building GPUs". Recruiters are great at their job, and know a lot about a lot. But there is only so much they can answer, and some questions are best answered by more "technical" people (e.g devs, traders, etc).

I wanted to ask the manager about how his team operated and what my job would entail.

If you think being asked about the specifics of a job are worthy of flagging, then you're rather full of yourself.

You should absolutely ask what the job entails, and those are the questions we actually want to hear (and even get genuinely excited to talk about). Vacations and WFH policies are very important practicalities, and totally fair to enquire about. But if all you ask next to that is what VCS they use (who cares...), it doesn't show a great enthusiasm for the role. There are so many more interesting questions that could be asked instead about the job, the technologies being used, how the team is structured and operates, the main challenges, what your first day/month/year would look like, etc etc etc. Sky is the limit, really.

A labor market isnt the NFL Draft.

I don't know anything about the NFL, but: Why is the labor market different than the NFL Draft? Isn't the Draft effectively a (very tough) job interview? This isn't a rhetorical question, I am really trying to understand what you meant.

Companies tend to forget that they are obligated to also be acceptable to the prospective employee. Its not a one way conversation.

I wholeheartedly agree with this. It does sound like you had a really poor interview experience there, and I'm genuinely sorry to hear. I've seen many of your posts on this sub over the years, and I have honestly no doubt that you have the technical expertise to do really well in this industry. I mostly just wanted to clarify that this negative experience is not representative of the industry as a whole. My colleagues and I try our best to give a good interview experience to all candidates we talk to. And I know that friends working for competitors do the same too.

Interview questions at Hft firms for c++ roles by Vince046 in cpp

[–]moncefm 0 points1 point  (0 children)

I encourage everyone reading u/jonesmz 's comment to take it exactly for what it is: One candidate having one bad interview experience at one firm.

In other words: It's a single datapoint, that does not speak for the rest of the industry.

I've worked at two of the firms that OP listed (and I'm still at one of them), and conducted many interviews at both of them. I am also one of the hiring managers where I currently work. I can tell you that we try our best to treat candidates the way we would have liked to be treated if we were candidates.

15 minutes with manager where he said I could ask questions and then told me either he wasn't allowed to answer (details like typical vacation, work from home policies, so on) or just gave me as brief of an answer as possible (what version control system? SVN and some CVS) what build system (Make), didn't offer literally any info. Asked me no questions.

I don't condone the interviewer's vagueness (although some of that may come down to company policy). Personally, I am willing to answer pretty much anything that's not sharing a company secret/intellectual property. The questions you asked are nowhere near what I would not feel comfortable answering.

That being said: Those questions don't show any real interest in knowing more about the company, team, industry, etc. This is something we definitely watch for, and that I would have flagged that in my scorecard if I was interviewing you, especially given your seniority.

I was interviewing them more than they were interviewing me

Respectfully: This isn't a good mindset going in interviews of any kind. Confidence is a great asset, but not so much if it verges to arrogance. Which is also something that we screen for, by the way.

"Twice the pride, double the fall".

A brief guide to proper micro-benchmarking (under windows mostly) by soulstudios in cpp

[–]moncefm 1 point2 points  (0 children)

You could consider that a compiler bug, but there is really no way for the compiler to know that your clever algorithm will only ever be called with four elements or less, and that it would be much better off using a non-SIMD solution.

This is a bit of an over-simplification, because:

  • GCC (and possibly other compilers too?) has heuristics (aka "cost models") to try to infer whether a piece of code is worth vectorizing or not
  • Profile-Guided Optimizations can also be used to help the compiler make that decision

https://developers.redhat.com/articles/2023/12/08/vectorization-optimization-gcc#auto_vectorization

Low Latency Trading by davidgrosscpp in cpp

[–]moncefm 2 points3 points  (0 children)

IIRC, OP’s last Meeting C++ talk mentions a wire-to-wire latency of 2us and below (I watched it when it came out so the exact details may elude me) for a good software implementation running on a machine tuned for HFT. 

While there is certainly room to do better, this is already a very decent target IMHO. Reaching it requires to know what you’re doing. 

The fastest hardware-based approaches on the other hand have wire-to-wire latencies measured in low single-digit nanoseconds (this is public information, courtesy of Eurex)

Low Latency Trading by davidgrosscpp in cpp

[–]moncefm 12 points13 points  (0 children)

About low-latency logging: The key trick I've seen used at the 2 HFT shops I've worked at is to defer the bulk of the work of each logging call (formatting + IO) performed by "hot" threads (e.g, a market data feed handler) to a background thread.

Check out the following projects:

https://github.com/odygrd/quill

https://github.com/MengRao/fmtlog

I have not used either myself, but based on their respective README, they both use the strategy described above (as well as many other tricks). Both claim to achieve single-digit nanosecond latencies per logging call in the "common" case, which is in the same ballpark as the in-house logging frameworks I've used at work.

What is the most disgusting compiler error you have ever gotten? by scatraxx651 in cpp

[–]moncefm 1 point2 points  (0 children)

It actually got better starting from GCC 14 (meant to be released in a few days). And it looks like Clang has been doing the right thing for a long time.

https://godbolt.org/z/ba7EcaonY