As a very long time Haskell user, I wonder how much latency management would be controlling for the lazy evaluation thunks being evaluated at certain deterministic times.

In my gut I would not choose Haskell for my first choice for a low latency language. I would definitely have looked at Rust before Haskell.

It seems to me that part of high-performance computing is optimizing memory layout (so you can vectorize, and to avoid cache misses). I have a hard time seeing that even in Java; I have a really hard time seeing that in Haskell. Am I missing something?

As is usual in Haskell for this kind of question, you can theoretically capture the information at the type level, and there are good odds somebody is working in a GHC extension for that.

But on practice, I don't think you are missing anything.

Of course, but still, it's interesting to see how far lazy fp can be reasoned about on this topic.

I always love optim talks whatever the language (granted its not a clusterfk interpreter).

There are people with good results for high throughput Haskell (worse than C, not by much, with code almost as complex as C). But for latency, the GC alone kills it.

Haskell abstracts away order of operations. Both high performance and low latency benefit from the ability to be very specific about as much as possible and Haskell take the opposite approach. This may be good for data flow and throughput, but as soon as you need to control explicit order, state and resource usage Haskell is going to be working against you.

At least for Rust, the raw compiled code performance isn't quite there yet.

You can pick languages other than C++ or Java, but for a specialized and bespoke hardware/software combination like HFT, you'll be at a disadvantage vs other teams.

In my experience, or at least something I've seen at 3 different firms now, there's also an issue around the kind of people that pick exotic languages in terms of pragmatism. Often times the Scala/Haskell/whatever else side of the codebase is beautiful and slow moving while the hacky C++ side actually works and is agile.

Compared to the typical functional language applications, Rust is different in that it's mainly being battle tested in the kind of Firefox performance issues that are very interesting to an HFT programmer and Rust easily interfaces with C.

What kinds of performance issues are you running into? We’d love bug reports!

No real world issues yet. Every couple years I look up some Rust performance benchmarks and pass on it. Benchmarks like this: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I'm not sure if it's still an issue since I don't use Rust daily; but one recommendation I'd make concerning array bounds checking is to do something like electric-fence and allow the compiler to be told to allocate arrays to end at the page boundary such that the hardware interrupts when you go off the edge.

If the compiler restricts such an array to only being indexed with an unsigned integer, then it can be safe but forego bounds checking altogether since the lower bound is always 0 and the upper bound check is hardware accelerated.

Thanks for elaborating!

Yeah, a lot of those would be faster now, because SIMD was stabilized. That's the source of the discrepancy on n-body, for example. I don't think anyone has bothered to really submit new implementations.

Most bounds checks can be hoisted out of the compiler can’t figure it out on its own via asserts. In general it’s not a huge problem in real-world code.

> That's the source of the discrepancy on n-body…

You made that claim before, and I showed you the Rust n-body program "vector instructions using SIMD" contributed 5 months ago.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Edit: the correct URL is https://benchmarksgame-team.pages.debian.net/benchmarksgame/....

Which one of those is the right one? Number 5?

It shows 0.48 seconds, and 2 seconds, but https://benchmarksgame-team.pages.debian.net/benchmarksgame/... shows 13.27. Why isn't that one on the main page?

> Which one of those is the right one? Number 5?

HN have now corrected the URL, as I asked.

> It shows 0.48 seconds, and 2 seconds

It shows 3 different workloads:

	 secs	         N
	 0.48	   500,000
	 2.01	 5,000,000
	20.09	50,000,000

> … but … shows 13.27…

Which we can see is the time for `n-body #2` at the largest workload:

	 secs	         N
	 0.54	   500,000
	 1.33	 5,000,000
	13.27	50,000,000

> Why isn't that one on the main page?

I don't know which you consider to be the "main page".

We can see that measurements for `n-body #2` are shown on both:

    faster/rust.html

and

    measurements/rust.html

Okay, I see now. It's about the three different measurements. Thank you!

It sounds like D is in a good spot for these usages. It's fast, and you can nicely control the usage of GC - GC only gets called on allocations, and you can use @nogc attributes to statically confirm there are no allocations in the hot loop.