Author here — I work on Tesseract at Pasteur Labs, and I wrote this up because the "what if this was possible" was bugging me for way too long :)
I was surprised by how well this worked, the LFortran + Enzyme stack seems to be a very clean way to get gradients through Fortran code via LLVM IR transformations. Pretty cool to see a 220-line Fortran heat solver turn into ~6,900-line reverse pass automatically if I dare say so.
Would be awesome to see this applied to a real scientific codebase, and I hope that the demo is enough to convince people that it’s worth trying.
Very interesting. Does LFortran have the same internal array layout as the standard C runtime ?
A shared layout and a shared calling convention would be very nice.
Sorry about my naive question. Haven't touched Fortran directly in three decades I think.
EDIT: thanks for your reply. For some reason it has been flagged dead. So am responding here. You can mail dang hn at ycombinator dot co m about the flagging. He is very nice.
I would also like to know this. Fortran itself is column-major, so I would guess the internal layout isn't same for multi-dimensional arrays when compared to row-major C? I'm not sure how LFortran represents arrays internally though.
reply▲assemmedhat2 hours ago
[-] LFortran internally uses column-major, so interchanging data with C should be done carefully for multi-dimensional arrays.
If row-major representation is highly needed feature, We can introduce a flag to do that. I'm not totally sure about that but it's doable under some conditions for sure.
reply▲Lots of scientific code in Fortran has sparse arrays, so a NxN array that only has values on 5 diagonals will store that as 5xN array to save memory allowing you to run a larger problem.
reply▲That's a very orthogonal issue.
Sparse arrays are supported on C libraries too. I have done my time with CSC and CSR even inside Python that called out to C libraries.
