Started by ceeac, May 06, 2022, 09:35:29 AM
makie and 1 Guest are viewing this topic.
// padding to increase the from 32 to 40 bytes for sync_step performance reasons.
Quote from: ceeac on May 06, 2022, 09:35:29 AMAs a result of the improved cache hit rate, for me sync_step is now about 5% faster for the big pak128 map and more than 25% faster for the yoshi map.
Quote from: ceeac on May 06, 2022, 09:35:29 AMfor me sync_step is now about 5% faster for the big pak128 map and more than 25% faster for the yoshi map.
Quote from: ceeac on May 07, 2022, 06:23:28 PMi7 6700k (4GHz), 16 GiB RAM (3200 MT/s)I used a standard Release build (i.e. CMAKE_BUILD_TYPE=Release) without LTO.
Quote from: ceeac on May 07, 2022, 07:57:25 AMI think this is because objlist_t::grow_capacity allocates 4 pointers (32 bytes total) for 2, 3 or 4 objects on a tile so that the memory is mixed in freelist if wolke_t is also 32 bytes. I think there are not many freelist allocations of 40 bytes besides wolke_t so the memory is nicely packed together.
Quote from: TurfIt on May 11, 2022, 02:10:03 AMNewer computer (5950X) sees 16% with yoshi, 4% on 12301. Interestingly the 5950 outperforms the 6700 by 40+% on yoshi, but the 6700 beats it on the big map (by like 0.01%, but still...). When the data fits the big cache, new cpus can fly!
Quote from: DrSuperGood on May 11, 2022, 06:55:18 PMThis will either be due to effective memory latency or some sort of tiny regression with multi threading.
Quote from: prissi on May 12, 2022, 02:33:22 PMMy first attempt with a template using only static members and fuctions still inreased the size of structures due to the zero member rule. So one has to use a static freelist_tpl member inside the actual class.
Quote from: prissi on May 12, 2022, 02:33:22 PMAlso to TurfIt ideas of reordering the object is sync lsit due to memory closeness: I think this is doomed for deterministic network gamies since the memory proximity may depend on the heap allocation which is beyond the control of simutrans on different architetures.