This Week In Veloren 29

3 minute read19 August 2019

Authored by AngelOnFira

Thanks to all of the contributors this week, @imbris, @Zesterer, @Xacrimon, @Qutrin, @scott-c, @Pfau, @Geno, @haslersn, and @luc-fauvel!


Optimizations by @Xacrimon

A bit about the optimizations I have been working on. Last week, I focused on new specs storage. After looking around the specs code for something unrelated it occurred to me that we were using VecStorage<T> for everything. This felt both badly thought out and horribly memory wasteful. And as it turns out, both were true.

So I set out to lower memory waste which essentially means packing components together more densely without impacting performance heavily. So the obvious solution is to just use HashMapStorage<T> right? Not so fast. As it turns out HashMapStorage<T> has quite some overhead for operations. Though more memory efficient they consume significantly more cycles do to and thus the game runs a lot slower.

Some of Zesterer's work this past week

So as it turns out there isn't a fantastic ready-made optimization here. I needed to come up with something that increasing memory efficiency without decreasing performance. So I ended up writing my own storage type. It is essentially an improved version of DenseVecStorage<T>. That data structure is quite optimized so there is no point right? Well as it turns out DenseVecStorage<T> is quite cache inefficient. This is due to it using a separate Vec<T> for the redirection table.

What my storage type does differently is that it places the redirection table inside the data vector by interleaving it. That boils down to storing x nodes of a normal redirection table inside each data entry and then using some custom indexing logic to first lookup the redirection entry which then points to an actual data entry. This has worked very well and managed to decrease memory usage in Veloren without a significant cost.

This week I went through the code looking for mutexes from the standard library and mpsc channels. That's because there are very good faster alternatives to both of these available, namely crossbeam for channels and parking_lot for locks. This optimization essentially consisted of stepping through the codebase and rewriting sections of code to use these faster alternatives.

The new jungle biome by @Sharp

Other Work

This week, @Pfau worked on moving some of the hotbar and XP UI elements over to VOX formats. He also did a redesign of these elements so make sure to check that out! @Zesterer added water, so now they're no longer just blue blocks! @Geno has been working hard since the beginning of this version to get world saving in. This will be quite a large component of 0.4. @Sharp has been working on adding a jungle biome, as well as humidity.

See you next week!