Symbolics.jl VS glow

It’s not up to parity with SymPy/Matlab by far yet - here’s the tracking issue on it https://github.com/JuliaSymbolics/Symbolics.jl/issues/59

Hello Juila Community. This is my second day working with Julia, having come over from Sympy due to performance reasons. I am working on a project that requires calculating matrix determinants and adjugates for families of matrices with symbolics entries. I am using Symbolics.jl for the symbols and using Juilia 1.8.2.

After spending some time reading the documentation, it turns out that JuliaSymbolics also lacks factorizations functionality (according to [Link](https://github.com/JuliaSymbolics/Symbolics.jl/issues/59))

You can also get an expression for the partial of β with respect to h using Symbolics.jl:

The example is applied to the right-hand side of a generated mass-matrix ODE (DAE) which is then solved using the adaptive time stepping methods of DifferentialEquations.jl. It's a test example that comes from the robotics / rigid body dynamics simulation groups (specifically interested in control) where they before were generating the governing equations with SymPy, and recently switched to try Symbolics.jl (and we got the example because of some performance issues that needed fixing). The comparison is with and without applying the code simplifier before solving. The table shows an average global induced error of 1e-12 when chopping off the 1e-11 * sin(x) terms and smaller. Thus there's nothing "competitive" against standard adaptive time stepping here: it's used to enhance the simulation of generated models that are simulated with the adaptive time steppers.

Done. https://github.com/JuliaSymbolics/Symbolics.jl/issues/215

Pytorch supports other kinds of accelerators (e.g. FPGA, and https://github.com/pytorch/glow), but unless you want to become a ML systems engineer and have money and time to throw away, or a business case to fund it, it is not worth it. In general, both pytorch and tensorflow have hardware abstractions that will compile down to device code. (XLA, https://github.com/pytorch/xla, https://github.com/pytorch/glow). TPUs and GPUs have very different strengths; so getting top performance requires a lot of manual optimizations. Considering the the cost of training LLM, it is time well spent.

It's pretty clear its referring to the output of Apache TVM and Meta's Glow

I also disagree with this. For example, Meta seems desperate about AI accelerators, and in fact is already doing "hardware customers develop software stack themselves" I mentioned above: Glow is that stack. Meta is doing Glow even if there is no promising AI accelerators right now, they are that desperate.

For reference: In Tensorflow and JAX, for example, the tensor gets compiled to the intermediate XLA format (https://www.tensorflow.org/xla), then passed to the XLA complier (https://github.com/tensorflow/tensorflow/tree/master/tensorflow/compiler/xla/service) or the new TFRT runtime (https://github.com/tensorflow/runtime/blob/master/documents/tfrt_host_runtime_design.md), or some more esoteric hardware (https://github.com/pytorch/glow).

The main reasons are hiring, and depth and breadth of the product.

Compilers are hard, device support is hard, the compiler community is small and closed source compilers quickly become weird tech islands.

https://github.com/pytorch/glow