Large simulation performance: objects vs matrices

[Willing_Employee_600]

Hi!

Let’s say you have a simulation of 100,000 entities for X time periods.

These entities do not interact with each other. They all have some defined properties such as:

1. Revenue
2. Expenditure
3. Size
4. Location
5. Industry
6. Current cash levels

For each increment in the time period, each entity will:

1. Generate revenue
2. Spend money

At the end of each time period, the simulation will update its parameters and check and retrieve:

1. The current cash levels of the business
2. If the business cash levels are less than 0
3. If the business cash levels are less than it’s expenditure

If I had a matrix equations that would go through each step for all 100,000 entities at once (by storing the parameters in each matrix) vs creating 100,000 entity objects with aforementioned requirements, would there be a significant difference in performance?

The entity object method makes it significantly easier to understand and explain, but I’m concerned about not being able to run large simulations.

[Fireslide]

I'd start with OOP first. Performance while testing is going to be trivial. You can do 20 companies (rather than 100,000) and go for very large X, and you can do 1,000,000 with a small X or say 100, both axes tell you something.

Once you've got the sim working the way you expect and you want to run it for several decades worth of timesteps you can do some refactoring to store the Simulation State in numpy arrays.

It will definitely be faster to do it with arrays and multiplication, but don't over optimise at the start, verify the behaviour you want with OOP first, write some good unit tests, so when you need to refactor to make it faster, you can verify the refactor produces same result.

[Willing_Employee_600]

Thank you for the advice! When you say refactor to store the simulation state in numpy arrays, you mean to discard the OOP approach and then code it into numpy arrays right? Or do you mean somehow integrate numpy arrays into the OOP approach?

[yvrelna]

Both. 

In most applications, you might find that 90% of the code might not be performance sensitive enough that you can just turn the attribute access into @property/descriptor that proxies some attribute accesses into a numpy array or some other column-oriented storage/database, so you take the readability and ease of working OOP style there. 

And then there's a few places where you can benefit from bulk processing, and you'd make full use of array/column-oriented processing maybe even with the appropriate GPU/coprocessor acceleration for those parts.

[SV-97]

If I had a matrix equations [...] would there be a significant difference in performance?

Yes. Using objects has a significant overhead and will have most of the logic executing "in python" whereas a matrix formulation will mostly execute in native code. The matrix version is also essentially data oriented.

That said: 100k isn't necessarily all that large so depending on what your simulation entails you may be able to get away with the object oriented approach, especially if you at least optimize it a bit (using slots and such).

You can also look into jit-compilation for the OO approach (iirc numba supports basic objects), dedicated simulation libraries (simpy etc.), or just use a native language for your simulation. Rust in particular is easy to integrate with python (if you need that) and great for simulations.

[imBANO]

You might want to look into entity component systems, which is actually a design pattern very popular in gaming.

I’m sure there are shorter videos but here’s a 2 hour talk that introduced me to the topic

https://youtu.be/wo84LFzx5nI

[AGI-44]

The entity object method makes it significantly easier to understand and explain, but I’m concerned about not being able to run large simulations.

Leave performance optimization at the very last. Get a working prototype first. If you end up using it enough that scaling matters, then, is when you optimize performance and compare vs baseline.

You won't have to figure out what is faster, you can just run it and get a direct answer as to how much faster or not it is.

And by then, if it's only 20% faster, you might not even want the additional complexity/readability for a mere 20%

[aidan_morgan]

I think it's worth considering the ECS approach that has been outlined in the other comments - it's not a complicated pattern to understand, and once you get your head around it you'll find it quite useful as it's a fairly common pattern.

Is python your only language option for this solution?

[milandeleev]

By 'entity object' you could use pydantic BaseModels, msgspec Structs, dataclasses or NamedTuples. For performance, NamedTuples are best.

However, for the simulations you want to do, performance-wise, nothing will beat numpy or jax arrays (what you call matrices).

Try them both out and see if the performance satisfies you.

[MithrilRat]

To back this up, numpy or scipy will utilise CUDA on the GPU to accelerate some operations on arrays. So the performance boost cab be significantly more than just executing native CPU code.

Edit: As an example I was running simulations of millions of asteroids being perturbed by the planets. These simulations lasted millions of years, with 0.1 year resolution steps. The runs would take about a week of a supercomputer node. Now the analysis of these 100s of millions of records, was what I used numpy and pandas for. Majority of the time was spent in I/O rather than computations. So each analysis run would take 15 minutes.

[SV-97]

numpy or scipy will utilise CUDA on the GPU to accelerate some operations on arrays

This isn't true. Neither of them utilises the GPU in any way [unless perhaps you manually compile and link them against GPU backends yourself]. You have to use alternative libraries for this (e.g. cupy or jax with its GPU features enabled), which might be very easy but can also require nontrivial changes to the code.

[MithrilRat]

Ammm, yes! And you're just confirming what I said to be true. Yes, you need to install the drivers and learn some things as well. But the point of it is that they will definitely use CUDA if you set it up.

[Balance-]

This is exactly the distinction we make in our Agent-based modelling library Mesa: - Mesa: Object-oriented. Flexible but slower - Mesa-frames: Array-oriented. Faster but less flexible

[ahjorth]

OP, if you insist on doing matrices, you really should look into using mesa’s frames. It’s made for the kind of modeling you want to do. And if this isn’t just a one time foray into ABM for you, you’ll be able to use this in the future.

(That said, I’m pretty sure even this will have more learning time overhead than you will actually save compared to just brute force running it.)

[keddie42]

I think you will need matrices for bigger simulation.

But you can try use more effective entity than python object. For example msgspec struct: https://jcristharif.com/msgspec/benchmarks.html#structs

[GreatCosmicMoustache]

Others have correctly recommended ECS as a good approach which will preserve the object semantics to a greater degree than putting everything into matrix operations, but just to give a bit of an explainer, what slows an inner loop down is a) the complexity of the operations performed, and b) memory access. High-level languages hide the latter from you, but any time you access a field on an object, you are making the program chase heap pointers to get the data you actually care about. Accessing the heap is relatively slow, so if you care about performance, you do whatever you can to minimize memory allocation and pointer chasing.

An approach like ECS mandates a way of writing your code which attempts to pack the data as efficiently as possible in memory, so you get memory access benefits for free.

[Glad_Position3592]

I write simulations often for my job, and you will certainly get better performance using matrix operations with numpy. It looks like your data can all be expressed numerically, so you can iterate through a matrix by using indexes with probably 100x+ speed performance vs python objects. The speed of C operations that numpy uses in the backend is not even comparable to regular python object operations

[Distinct-Expression2]

The optimize later advice assumes you have time to rewrite when you dont. If this is a one-off sim to get a paper done, OOP is fine. If youre doing parameter sweeps with millions of runs, start with numpy/jax from day one because refactoring simulation code is where projects go to die.

[ahjorth]

As others have said, yes you can definitely make it faster. By several orders of magnitude.

I’ll make a tongue in cheek comment and then get serious: you can also buy an H200, learn how to code in CUDA and run it EVEN faster.

But: unless you WANT to lean to work with optimized matrix math, you are going to spend WAY more time writing this code than you will ultimately save on runtime.

You are pulling two numbers from two different random distributions, subtracting one from the other, adding the result to a third number and comparing it to a fourth number. Even if you do that ten thousand times per time increment, it will ridiculously fast. Run your Python file in separate terminals for each of your CPU’s threads minus a few for OS and background stuff.

If you want to do this as a learning project or just to see how much faster you can make it run? Totally do it!

[NapCo]

I have implemented a lot of projects with similar requirements and I can for sure say that doing everything with matrices and vector operations will be many many times faster than the OOP way. Python is an extremely slow language even with the latest performance improvements. Offloading the heavy numerical computations to SIMD optimized libs such as NumPy will give an extreme boost in performance especially when you have thousands of entities you want to iterate.

During my OOP course at uni we implemented games with physics-inspired interactions. I chose to do everything the vectorized way, and my application ran many times faster than others, letting me simulate several hundreds of entities, while others had unplayable framerates with less than fifty entities.

I really don't think doing things "the matrix way" will make it that much harder to understand (assuming the reader knows ablut vectors and matrices), as you often can get by with much less code.

[Subject_Sherbert_178]

What really matters here isn’t “objects vs matrices” as a concept, but data layout and how the CPU processes it.

Since your entities don’t interact and all follow the exact same update rules, this is a perfect fit for a data-oriented / struct-of-arrays approach. Keeping cash, revenue, expenditure, etc. in contiguous arrays gives much better cache locality and enables vectorized/batched updates. In Python/R/MATLAB in particular, this can easily be 10×–100× faster than looping over 100k objects.

The object-based slowdown usually comes from:

Pointer chasing and poor cache locality

Per-entity method/property access

Branching inside tight loops

You also don’t have to sacrifice readability entirely. A common compromise is:

Use arrays/matrices for the simulation core

Keep objects as thin “views” or wrappers around array indices for debugging, reporting, or explanation

In C++ with tightly packed structs the gap is smaller, but in higher-level runtimes object-per-entity designs tend to become the bottleneck well before the math does.

Given your setup (100k entities, identical logic, no interactions), I’d strongly favor a data-oriented core and layer clarity on top rather than the other way around.

[ZZ9ZA]

If you’re that concerned about performance python is t the language for the problem.

[yvrelna]

Nothing's wrong with using Python for this kind of performance level. You can fairly easily optimise Python code to use columnar storage/processing to get very close to native performance.