Upscaling, CUDA threads and memory blocks
Here we will demonstrate how easy it is to scale up existing simulations. In this context, we will address some CUDA-specific settings. The presented feature is especially useful to e.g. scale up small evolution simulations afterwards and thus increase the population size arbitrarily.
What you will see
1. Loading an appropriate simulation
A good demonstration for that feature is the startup example. We load it from the file ./examples/simulations/startup.sim. It contains some interesting replicating machines in a rather small world. Zooming out to 1x, we can see the entire world at a glance. Each world in alien has periodic boundary in the sense that you go from the left border directly to the right and vice versa. The same is true for above and below. We have this phenomenon also on the surface of a torus. You should now see something like the following:
2. Enlarging the world with content scaling
Now let us say we wanted to generate a larger world from this. The basic idea behind the up-scaling function is that the newly generated space will be filled with duplicates from the original world. For this we open the General settings dialog under Settings.
The interesting stuff is the world size and the check box labeled as "scale content [...]". If checked the additional space is filled with content from the original one. Likewise, this option removes objects when the space shrinks. But be careful! If you scale up the world too much, then what will happen is that the reserved GPU memory will no longer be sufficient. This is a reason why you can set other technical parameters in this dialog. For instance:
- number of threads per block: In CUDA, threads are grouped into blocks. The total number of threads is the number of blocks times the number of threads per block. It is not so trivial to find the optimal number and depends on the simulation data. For instance, each cell cluster is calculated by a thread block. If there are many larger cell clusters, it is more favorable for performance to choose more threads per block. However, if the number of threads per block is set too high, the simulation will slow down because many threads will be idle.
- number of blocks: Here, too, an optimal value must be found, which strongly depends on the simulation data. Too low a value leads to poor performance, while too high a value can lead to crashes.
- maximum entities/dynamic memory: The entire simulation code is written in CUDA and operates on predefined memory blocks. Currently there is no automatism that calculates and dynamically adjusts the sizes. Therefore, you need to specify the maximum number of cells, clusters, particles and tokens in advance. In addition, memory is required for dynamic processes (to perform the cell functions) and for storing metadata (e.g. colors, names, descriptions and program code of cells). If you upscale a world a lot, you may also need to adjust these values accordingly.
For our concrete example, we scale the world up to 4x, i.e. set the size to 1,600 x 400 units. The CUDA parameters do not need to be adjusted here. The After confirming with OK, the world is recalculated and the view is reset to default. We then zoom out to level 1x and should see the following:
3. Shrinking and enlarging again
Next, we will shrink our world. In this case, if the "Scale content [...]" checkbox is set, the content will be cut off. For example, we now choose a size of 1,000 x 400 and get:
For comparison, expanding the world again to 1,600 x 400, but this time without content scaling, provides:
When scaling down to 1,600 x 300 without content scaling, we see that areas overlap that were previously separate:
This is due to the aforementioned torus topology and the fact that the content is now not truncated.
4. Provoking a crash
Finally, let us provoke a crash. We scale up the world to 16,000 x 400 and get the error message after some loading time:
The error dialog gives possible hints to the cause ("array size for cells is too small") and allows sending a bug report to alien-project.org if the user wishes to do so. The most common causes of crashes are too high thread block count or too small array sizes for the entities. If you cannot solve the problem, it would be very nice of you if you could send a bug report.
Created with the Personal Edition of HelpNDoc: Write eBooks for the Kindle