modin VS awesome-tensor-compilers

The interesting thing about Polars is that it does not try to be a drop-in replacement to pandas, like Dask, cuDF, or Modin, and instead has its own expressive API. Despite being a young project, it quickly got popular thanks to its easy installation process and its “lightning fast” performance.

Yeah, tried Polars a couple of times: the API seems worse than Pandas to me too. eg the decision only to support autoincrementing integer indexes seems like it would make debugging "hmmm, that answer is wrong, what exactly did I select?" bugs much more annoying. Polars docs write "blazingly fast" all over them but I doubt that is a compelling point for people using single-node dataframe libraries. It isn't for me.

Modin (https://github.com/modin-project/modin) seems more promising at this point, particularly since a migration path for standing Pandas code is highly desirable.

If anyone wants a faster version of pandas it’s not hard to find, modin for example uses multiple cores to speed it up, so if you have 4 cores it’s about 4 times faster than pandas, and has the same API as pandas.

Modin should fit. It implements Pandas APIs with e.g. Ray as backend. https://github.com/modin-project/modin

If you really want speed you should try modin.pandas which makes pandas multi-threaded.

I am guessing XGB is fairly optimised as it is. If you would want to use the sklearn libraries with pandas, look into Modin

Source

> 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