So that’s fairly optimal already.īut what are the alternatives? The easiest one would be to use SSE 4.2 which includes the CRC32 instruction. For precise details a paper was written about the algorithm here. In this case 8 table lookups can potentially be done in parallel. The reason is that it allows for grater instruction-level parallelism because on the standard implementation each table lookup must be completed before computing the next index. Based on the Slicing-by-8 implementation found here:Ĭonst uint8* _restrict Data = (uint8*)InData ĬRC = (CRC > 8) ^ CRCTablesSB8_DEPRECATED įor (uint32 Repeat = Length / 8 Repeat -Repeat)ĬRCTablesSB8_DEPRECATED ^Īs seen on the code, this is based on the slicing-by-8 version of CRC32, which is way faster than the standard implementation. Uint32 FCrc::MemCrc_DEPRECATED(const void* InData, int32 Length, uint32 CRC/*=0 */)
* which give values different from what a user of a typical CRC32 algorithm might expect. * These tables and functions are deprecated because they're using tables and implementations Let’s look at the code, which is also available here:
But the call to FCrc::MemCrc_DEPRECATED() seemed like a low hanging fruit since that a pretty self-contained process. Also the memset in particular is caused by build for the editor which fills up memory with a debug value (0xCD) any new allocation or before freeing an allocation. That’s something that I will try to optimize later, and that I know it will take some work. Since this is an asset baking process it is fairly normal to spend a lot of time dealing with memory so I wasn’t too surprised about the CPU time spent on memset and memcpy. In that way I unsure that the cooking process only runs through the process of verifying what needs to be done, and it should determine that there isn’t any asset to build. What I decided to cook my simple particles scene (which you can see screenshots here) once, and then cook it again but then with the profiler running. As usual I will do all the profiling on my machine: The build system would take more than 3 minutes to determine that nothing had to be built, and I’m talking about code and not assets. While this may not seem like a big deal, it is especially annoying for me since I had a pretty bad experience working with the build system at Dreamworks R&D.
The reason I found that was because I would try to cook the assets without actually saving my changes.
I found myself cooking assets quiet often but one thing I noticed was that I found that the cooking process took a while to determine which assets needed to be cooked. The process of baking the raw assets to be properly consumed by the engine is called “cooking” in Unreal Engine 4’s lingo. As I was working on the GPU particle system on Unreal Engine 4, I had to build my own scene.
0 kommentar(er)
