Hacker News new | ask | show | jobs
by magicalhippo 1913 days ago
A tangent, but I was exposed to the Galerkin approximation when learning about the Finite Element Method, well over 10 years ago.

As part of the course I got introduced to the FEniCS project[1].

They had Python code looking very much like the math equations generating C++ code at runtime, compiling it into a Python module which got dynamically loaded and executed.

This way they got speeds which rivaled or surpassed handwritten C++, as the C++ code could be optimized around the specific problem, but with superior ergonomics of writing the equations almost directly.

It really blew my mind. I had heard about Java doing JIT but this was on another level for me. Not terribly fancy these days but at the time it really helped me expand my thinking about how to solve problems.

[1]: https://fenicsproject.org/

2 comments

Another project that works like this is devito https://www.devitoproject.org/ - the python code generates C code, calls gcc to compile it, dynamically links the object code with dlopen(), then calls the compiled code. That way, the hot code loop doesn't run in Python
You really should check out Approxfun.jl and DifferentialEquations.jl. The julia ecosystem for this type of thing is incredibly well developed. You get autodiff, auto-sparsity detection, auto-vectorization and more for free. Also, these tools leverage the fact that Julia is fast and has a good macro system so the code you generate is just normal Julia code, which can be used with any of the other tools of the language. Also multiple dispatch means that you don't have to use anything complicated to write this. Just write your equations "normally" and this all just works.
The constant shilling for Julia gets old after a while. When it comes to numerical mathematics the implementation language is just a way to express ideas that are more or less independent of whatever language you are using. Last time I checked Julia had close to no professional grade libraries for PDE solving , while there are multiple deal.ii, FenICs, petsc high quality libraries for C++. Don’t get me wrong Julia is great, but what really matters is the quality of the available libraries. The differential equations work in Julia is nice and obviously the resulting code is performant, but a ton of work in numerical mathematic is spent on adapting methods to specific problems and at that point C++ feels like a much nicer choice to me in many cases.
Julia has some young projects that look promising as future broad FEM/PDE discretization libraries, like Gripap.jl, but they are certainly not at the level of the more mature C++-based libraries you mention.

For my own work I would never say C++ is a nicer choice; I hate writing and dealing with C++ code. It is however a necessary choice since that is where many of best the libraries live.

These packages you mention are not suitable for the typical use cases of the finite element method. There are some packages in the Julia ecosystem that may be suitable. I have no recent experience on using them though.