Arraymancer VS awesome-tensor-compilers

It is a small DSL written using macros at https://github.com/mratsim/Arraymancer/blob/master/src/array....

Nim has pretty great meta-programming capabilities and arraymancer employs some cool features like emitting cuda-kernels on the fly using standard templates depending on backend !

Nim has also a powerful deep learning library called Arraymancer. It's selling point is that you don't have to rewrite your code from research to production. It's used in various machine learning projects, but one recent one that caught my eye was https://github.com/amkrajewski/nimCSO "Composition Space Optimization"

https://github.com/mratsim/Arraymancer

- https://github.com/mratsim/Arraymancer/blob/master/src/array...

It's worth noting that nim async/await transformation is fully implemented as a library in macros.

https://github.com/mratsim/Arraymancer 11. « Premature optimisation is the root of all evil », Donald Knuth, The art of computer Programming It would be quite useful that someone writes one with examples for all these recommendations and more ...

In particular for deep learning as bobsyourunkl already mentioned there is arraymancer on the one hand and also flambeau on the other. The latter is a Nim wrapper around libtorch (i.e. the PyTorch C++ backend). It is missing things (to be wrapped by adding a few lines) and has some rough edges, but if one needs to get stuff done, it's possible.

how are u compiling (optimization, custom compilation flags etc.?) In my case https://github.com/mratsim/Arraymancer big project compile under your 4.2s so or you have like 10k+ lines of codes with macros or you just pass some debug flags to compiler :D

We have both raw wrappers for BLAS:

https://github.com/andreaferretti/nimblas

as well as LAPACK:

https://github.com/andreaferretti/nimlapack

For an example, consider calling the least squares routine `dgelsd` in arraymancer:

https://github.com/mratsim/Arraymancer/blob/master/src/array...

wrapped up in a nicer user facing API.

Feel free to hop onto matrix, if you have more questions!

> So long as Pytorch only practically works with Nvidia GPUs, everything else is little more than a rounding error.

This is changing.

https://github.com/merrymercy/awesome-tensor-compilers

There are more and better projects that can compile an existing PyTorch codebase into a more optimized format for a range of devices. Triton (which is part of PyTorch) TVM and the MLIR based efforts (like torch-MLIR or IREE) are big ones, but there are smaller fish like GGML and Tinygrad, or more narrowly focused projects like Meta's AITemplate (which works on AMD datacenter GPUs).

Hardware is in a strange place now... It feels like everyone but Cerebras and AMD/Intel was squeezed out, but with all the money pouring in, I think this is temporary.

I think this is true of AI compilation in general. Torch MLIR, AITemplate and really everything here fly under the radar.

https://github.com/merrymercy/awesome-tensor-compilers#open-...

> I really want to do some great work and help people.

Have you looked into ML compilation?

https://github.com/merrymercy/awesome-tensor-compilers

IMO there is low hanging fruit in the space between high performance ML compilers/runtimes and the actual projects people use. If you practice porting projects you use to these frameworks, that would give you a massive performance edge.

While not all "languages" persay, I am excited about the various ML compilation efforts:

https://github.com/merrymercy/awesome-tensor-compilers

Modern ML training/inference is inefficient, and lacks any portability. These frameworks are how that changes.

You might be interested in this: https://github.com/merrymercy/awesome-tensor-compilers

* collection of papers in https://github.com/merrymercy/awesome-tensor-compilers

I also have an interest in the community more widely associated with pandas/dataframes-like languages (e.g. modin/dask/ray/polars/ibis) with substrait/calcite/arrow their choice of IR

Compiling from high-level lang to GPU is a huge problem, and we greatly appreciate efforts to solve it.

If I understand correctly, this (CM) allows for C-style fine-level control over a GPU device as though it were a CPU.

However, it does not appear to address data transit (critical for performance). Compilation and operator fusing to minimize transit is possibly more important. See Graphcore Poplar, Tensorflow XLA, Arrayfire, Pytorch Glow, etc.

Further, this obviously only applies to Intel GPUs, so investing time in utilizing low-level control is possibly a hardware dead-end.

Dream world for programmers is one where data transit and hardware architecture are taken into account without living inside a proprietary DSL Conversely, it is obviously against hardware manufacturers' interests to create this.

Is MLIR / LLVM going to solve this? This list has been interesting to consider:

https://github.com/merrymercy/awesome-tensor-compilers