# High performance, fixed size 1D and 2D arrays on a CPU

**URL:** <https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023>\
**Category:** General\
**Created:** [July 27, 2025, 9:18am UTC](https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023 "2025-07-27T09:18:44Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![pauljurczak](https://avatars.discourse-cdn.com/v4/letter/p/87869e/32.png) [@pauljurczak](https://forum.modular.com/u/pauljurczak)\
**Post date:** [July 27, 2025, 9:18am UTC](https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023/1 "2025-07-27T09:18:44Z")

</div>

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.](https://github.com/Mojo-Numerics-and-Algorithms-group/NuMojo) and somewhat complex [tensor\_builder | Modular](https://docs.modular.com/mojo/kernels/layout/tensor_builder/). Is there a performance difference between these two on a CPU? Any other options I missed?

---

<div class="post-metadata">

**Author:** ![owenhilyard](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/owenhilyard/32/41_2.png) [@owenhilyard](https://forum.modular.com/u/owenhilyard)\
**Post date:** [July 28, 2025, 3:47pm UTC](https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023/2 "2025-07-28T15:47:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pauljurczak](https://avatars.discourse-cdn.com/v4/letter/p/87869e/32.png) [@pauljurczak](https://forum.modular.com/u/pauljurczak)\
**Post date:** [July 29, 2025, 8:06am UTC](https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023/3 "2025-07-29T08:06:46Z")

</div>

Do you mean `LayoutTensor` type? I see notices of `Tensor` being deprecated. Any issues with using seemingly more user-friendly NuMojo library?

---

<div class="post-metadata">

**Author:** ![Olobor](https://avatars.discourse-cdn.com/v4/letter/o/67e7ee/32.png) [@Olobor](https://forum.modular.com/u/Olobor)\
**Post date:** [July 29, 2025, 8:53am UTC](https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023/4 "2025-07-29T08:53:26Z")

</div>

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.

> <https://github.com/Mojo-Numerics-and-Algorithms-group/NuMojo/blob/main/numojo/core/ndarray.mojo#L41>

This is because Mojo itself currently lacks support for Python’s buffer protocol.

> <https://github.com/modular/modular/issues/1515>
>
> \### 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/)

---

<div class="post-metadata">

**Author:** ![owenhilyard](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.modular.com/owenhilyard/32/41_2.png) [@owenhilyard](https://forum.modular.com/u/owenhilyard)\
**Post date:** [July 29, 2025, 4:28pm UTC](https://forum.modular.com/t/high-performance-fixed-size-1d-and-2d-arrays-on-a-cpu/2023/5 "2025-07-29T16:28:58Z")

</div>

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.
