I’m just kicking Mojo’s tires at the moment. What are the data types of high performance, fixed size at runtime, 1D and 2D arrays on a CPU? I found GitHub - Mojo-Numerics-and-Algorithms-group/NuMojo: NuMojo is a library for numerical computing in Mojo 🔥 similar to numpy in Python. and somewhat complex tensor_builder | Modular . Is there a performance difference between these two on a CPU? Any other options I missed?
You should use Tensors, since those integrate with the rest of the Mojo ecosystem in a much better way. Fixed-size at runtime just means no capacity variable.
High performance is a matter of perspective, since Mojo is a systems language you can make a normal List perform pretty close to what Numpy can do with a bit of effort. That for that last 1% it might matter, but instead of chasing that last 1% of CPU it might be worthwhile to instead investigate GPUs, where Mojo can run away with a performance win compared to most other options.
1 Like
Do you mean LayoutTensor type? I see notices of Tensor being deprecated. Any issues with using seemingly more user-friendly NuMojo library?
Olobor
July 29, 2025, 8:53am
4
I’m a Mojo noob @pauljurczak . NuMojo seems like a good option, but there’s a caveat. When you interop between Python’s numpy.ndarray and NuMojo’s NDArray, you ideally want zero‑copy access so both sides share the same memory buffer instead of doing expensive data copies. NuMojo needs an NDArrayView type (a lightweight view into an existing buffer) but that isn’t implemented yet.
# 4) Returns *
# 5) Raises *
# 6) SEE ALSO
# 7) NOTES
# 8) REFERENCES
# 9) Examples *
# (Items marked with * are flavored in "Mojo docstring style guide")
#
# ===----------------------------------------------------------------------===#
# TODO: Consider whether we should add vectorization for _get_offset.
# TODO: Create NDArrayView that points to the buffer of the raw array.
# This requires enhancement of functionalities of traits from Mojo's side.
# The data buffer can implement an ArrayData trait (RawData or RefData)
# RawData type is just a wrapper of `UnsafePointer`.
# RefData type has an extra property `indices`: getitem(i) -> A[I[i]].
# TODO: Rename some variables or methods that should not be exposed to users.
# TODO: Remove some methods, `mdot()`, `rdot()`, `row()`, `col()`, etc,
# that does not belong to the NDArray type.
# TODO: Special checks for 0d array (numojo scalar).
# ===----------------------------------------------------------------------===#
This is because Mojo itself currently lacks support for Python’s buffer protocol.
opened 06:06AM - 19 Dec 23 UTC
enhancement
mojo-stdlib
mojo
mojo-python-interop
mojo-repo
### Review Mojo's priorities
- [X] I have read the [roadmap and priorities](h… ttps://docs.modular.com/mojo/roadmap.html#overall-priorities) and I believe this request falls within the priorities.
### What is your request?
This enhancement request is to add support for Python's `memoryview` builtin and support for python buffer protocol. Here are some ideas about what kind of tasks and level of effort might be involved:
- Add a new Mojo trait (`Bufferable`?) which has dunder methods: ` __buffer__` and ` __release_buffer__`.
- Add support for python's builtin `memoryview()` on Mojo structs. `__buffer__` returns `memoryview` so this has to be builtin to Mojo (not a python module import).
- Add support for the C data interface defined here [python buffer protocol](https://docs.python.org/3.8/c-api/buffer.html#bufferobjects). This would allow Mojo structs implementing the C data interface as `Py_buffer` https://docs.python.org/3/c-api/buffer.html to be called from Python. Or maybe they could be wrapped in a PythonObject and returned as a `memoryview`?
### What is your motivation for this change?
Currently Mojo 0.6 has poor (nonexistent?) support for zero-copy shared memory buffers with Python.
For example in Mojo's documentation the [Ray Tracing notebook](https://docs.modular.com/mojo/notebooks/RayTracing.html) has an example of raster imagery being copied into a numpy array, using MLIR ops. Not only is this an unnecessary memory copy, it's also too verbose, undocumented, and not pythonic. See `def to_numpy_image(self) -> PythonObject:` in [source notebook](https://docs.modular.com/mojo/notebooks/RayTracing.html).
Mojo should enable and encourage interop with existing scientific computing packages in the most efficient manner. For example the [Apache Arrow format](https://arrow.apache.org/).
> The Arrow C data interface is inspired by the [Python buffer protocol](https://www.python.org/dev/peps/pep-3118/), which has proven immensely successful in allowing various Python libraries exchange numerical data with no knowledge of each other and near-zero adaptation cost. [Arrow Spec](https://arrow.apache.org/docs/format/CDataInterface.html#inspiration)
This enhancement would also lay the groundwork for supporting the [Python array API standard](https://data-apis.org/array-api/latest/).
### Any other details?
### Related Discussions/Issues:
- https://github.com/modularml/mojo/issues/1210
- https://github.com/modularml/mojo/discussions/1281
### Reference PEPs:
- [PEP 3118 – Revising the buffer protocol (Python 3.0)](https://peps.python.org/pep-3118/)
- [PEP 688 – Making the buffer protocol accessible in Python (Python 3.12)](https://peps.python.org/pep-0688/)
1 Like
Yes, I mean LayoutTensor. NuMojo isn’t really integrated with the rest of the Mojo ecosystem, and LayoutTensor is the core datatype for linear algebra and you have to use it if you want to use MAX.