OCaml All the Way Down – How Jane Street Builds FPGA Designs [video] | Hacker News Reader

OCaml All the Way Down – How Jane Street Builds FPGA Designs [video]

janestreet.com

170 pointssnaky30 comments

This is a talk. In case you just want the youtube link, it's here: https://www.youtube.com/watch?v=X1cgRXhpQLY

I do appreciate the presenters sense of humor.

"I know what you're thinking. I know what you're thinking. That's like ten lines of Verilog, right? Naaaah. That's not how I roll. That's more like two hundred... thousand... lines of Ocaml."

How does Jane St. use FPGAs to make money trading? My impression was that unless the application demands real speed (i.e., microseconds), write it as software that run in a general purpose processor, not in an FPGA. x86s always get the latest semiconductor processes, while FPGAs always lag.

High-frequency trading in a developed market demands response times on the order of nanoseconds, whereas anything in software is unlikely to get under a microsecond. If you're too slow, all the obvious efficiencies in the market have already been corrected by faster firms, so you miss out on a bunch of easy trades.

Where does this nanosecond number come from for HFT? 1 ns is the time light takes to travel 30 cm in a vacuum. Are these firms only trading with firms that are a few meters away? How about round trip times? I believe only 10s of microseconds are significant, not nanoseconds.

That is exactly what is happening in high frequency trading. Firms are paying crazy money to be colocated in the same data centers as the exchanges.

And we as a society know that and think it is normal. Crazy.

I don't think it's a bad thing - theyre business model relies upon low latency, and so they do everything they can to reduce it

https://www.smbc-comics.com/comic/trading

Exactly. At an investment bank for which I used to work in NYC, they moved their datacenter to be next door to the exchange's datacenter just to reduce latency.

Because in HFT, every fraction of a second can mean the difference between 10s or even 100s of millions of dollars in profit/loss.

You're right. A 100MHz clock has a period of 10nS. I can tell you exactly how many of them my data path will take (I've only ever used clocks up to about 300MHz in an FPGA - 600 for things like DDR4 memory).

What GP means is that the portion of the overall latency which you can control must respond as quickly as possible, and you do count nanoseconds. Obviously HFT has not invented superluminal communication techniques.

> Obviously HFT has not invented superluminal communication techniques.

They haven't, but they've put in tremendous resources into going above the speed of light in optical fibre, including the use of point-to-point microwave links and, when it's impossible to place towers for microwave links (for example, across the Atlantic Ocean), the use of HF/shortwave (as in 3-30MHz stuff) radio.

My question may show my ignorance but how would anyone or anything go above the speed of light? Could you elaborate please?

Speed of light in fibre is lower than speed of light in air, so you can beat fibre speed of light by building fast wireless networks.

Thanks. I just looked it up and really wasn't aware of the huge difference.

It's not really the fibre that slows down the signal as much as the opto-electrical repeaters that relay the signal many times as it travels vast distances.

Light can only go a few km before it needs to be boosted

This is wrong on both accounts.

The speed of light in a fiber is only about 70% of speed of light in vacuum.

Modern single mode fiber has very low attenuation (less than 0.01dB/km). But more importantly you don't have to use opto-electrical repeaters to boost the signal. What you do is using purely passive dispersion control by mixing different kinds of fiber and compensate for the rest dispersion using chirped fiber bragg gratings. To boost the signal you splice in rare earth doped fibers (Erbirum, Yttrium) which acts as optically pumped optical amplifier.

When you write "modern" how long ago would that have been installed?

/me trying to get a handle on optical development.

The basic principle has been invented over 30 years ago in 1987: https://ieeexplore.ieee.org/document/4258955

They're used in long haul communication for some 15 years or so. They're especially useful in submarine cables, for the sole reason, that new optical transmission schemes(modulation, wavelength multiplexing and so on) can be implemented by just replacing the equipment on either end, without the need to replace components down there on the seabed.

Speed of light is a universal physical constant. What you referring is that the space the light has to travel in the optic cable is way bigger then what it would be with straight line of sight between MW towers.

The constant referred to as "speed of light" is speed of light in vacuum. Light slows down different amounts in different media.

Semantics, at best...

Lots of things depend on latency, which an FPGA can tune by creating custom data pipelines. Microseconds is really a long time in FPGA land.

But more importantly, FPGAs are parallel in a way conventional processors aren't.

> x86s always get the latest semiconductor processes, while FPGAs always lag

Two issues with this:

1) You cannot compare an FPGA architecture to a general purpose CPU. FPGAs are massively parallel by design and have near zero overhead, so 100 MHz in an FPGA != a 100 MHz CPU.

2) FPGAs do not lag that far behind and are moving to 16 nm and beyond for higher end products. Besides, due to 1), there really is no real need to move to lower nodes yet.

Can anyone who watched the video summarize? I'm interested in the subject, but don't have the time/concentration for long videos when an article often suffices.

my notes:

* HardCaml - DSP for FPGA/ASIC, * embedded SW in OCaml (running on Xilinx MicroBlaze), * HardCaml example: AXI interface, GPIO, SPI, cordic, * FPGA: LUTs and regs, BRAM, DSP,

skip to 9:40 if you are familiar with FPGA, skip to 17:50 if you know HDLs, go to 37:10 for a demo

* HardCaml datatypes: registers, wires (can be used before they are assigned), memory, ...

* API: arithmetic, logic, `pipeline`, `reg`, bit selects, `width` --> useful for HW generation, `inst` - use VHDL and Verilog in HardCaml

* signed and unsigned types: checks at compilation, * `bits` = non-synthesizable, `signal`= synthesizable, * `Always` ~ Verilog `always` - used mainly for FSM

* built-in cycle-accurate simulator: supports multiple process, MicroBlaze simulator (instruction set simulator)

* terminal-based waveform viewer and VCD export

* formal verification: SAT solvers - boolean function --> SAT/UNSAT

* software: Ocaml -> bytecode -> Ocaml interpreter for MB, C-stubs in Ocaml library, no signals, no threads, no Unix

* code for HardCaml available on Jane Street GitHub

What are some good resources for HardCaml?

Github: https://github.com/janestreet/hardcaml

And Andy Ray and co's stuff:

Blogs: http://www.ujamjar.com/

Getting started overview and tutorials: http://www.ujamjar.com/hardcaml/

Running OCAML Bytecode in hardware: https://github.com/ujamjar/hardcaml-zinc

actually, we don't care how jane street does this and that with ocaml. it's such hype bullshit that makes me wanna vomit. Stop giving it publicity it doesnt deserve.

Any mention of what vendor Jane Street is buying FPGAS from?

maybe: Arty A7 hobbyist FPGA board from Xilinx

Reply on news.ycombinator.com