domschl

Why was the comment of the author of the translation-site that explains the methodology flagged / dead?

The mere fact that the translation was AI-assisted shouldn't be a reason to flag a comment. AI translations, especially supervised translations, can actually achieve a reasonable level of quality.

Disagreement on AI philosophy shouldn't be a reason to flag a contribution.

Try "Lobhudelei"

How is the 'genitive case of Bangla word' a good example? This function's signature contains many hard-coded language specific assumptions.

- Bangla according to the function has only few irregularities, rest is algorithmic transformation of the word given

- Many languages have a huge number of irregularities

- Many languages express case information somewhere else in the sentence-construct, so it's not just a word-transform.

This very much seems to try to replicate the machine-translation efforts of foregone ages.

This is (partly) outdated. MPS (metal performance shaders) are now (since torch 2.x) fully integrated in standard Pytorch releases, no external backends or special torch versions are needed.

There are few limitations left when compared with other backends. Instead of using 'cuda' device, one simply uses 'MPS' as device.

What remains is: the optimizations Pytorch provides (especially compile() with 2.1) focus on cuda and it's historic restrictions that result from CUDA being _not_ unified memory, and lots of energy goes into developing architectural work-arounds in order to limit the copying between graphics HW and CPU memory, resulting in proprietary compilers (like triton) that move parts of the python code into proprietary hardware.

Apple's unified memory would make all of those super complicated architectural workarounds mostly unnecessary (which they demonstrate with their project).

Getting current D/L platforms to support both paradigms (unified/non unified) will be a lot of work. One possible avenue is the MLIR project currently leveraged by Mojo.

The main thing about this framework is, that it uses unified memory with GPU. This gives maximum performance. Neural engine one the other hand is optimized for low-energy inference (which is mostly an advantage on mobile devices), and imposes limitations and restrictions since it's hardware supports only very specific neural network operations. Thus supporting neural engine within a universal machine learning platform doesn't make much sense, it would just be a bottleneck.

The way to use neural engine is to convert existing models that strictly adhere to the limitations of the neural engine hardware (excluding many operations used in non-restricted NN models) for use in energy-restricted inference applications only. It's a different application scenario.

The project probably at least partially serves as documentation for other platforms to integrate Silicon acceleration. It basically demonstrates how to use macOS Accelerate and Metal MPS (metal performance shaders) using C++ for Machine Learning and training optimization.

Thus other platforms can simply take this backend-code and integrate it. (Pytorch basically did that already with Apple's help).

Neural engine is not helpful for training, its inference hardware, whereas this targets training and research. They use Accelerate and Metal (with seemingly similar/identical performance shaders that their Pytorch adaption uses) which allows for high performance training.

This project additionally serves as documentation for other platforms to integrate Silicon, which is good.