• Can you provide a test file that allows us to easily verify the performance increase?

Yes I will, but so far is simple, you can create a simple sphere, add a particle system, and create 4 million particles in frame 1, you will see speed increase inmediately, but I will prepare a blend so anyone can use the same file.

• Please remove the old comment, it does not add any value. Also remove the timing code which should not be part of this patch.

Ok

• I think it should not be a define anymore after this change. Just use a normal function call.

I left the define because I was not sure if that variable was used in some other place, I'm new modifying this kind of code, so you mean that I just create a function "static int MAX_PARTICLES_PER_TASK(void)" and call that function instead of using the variable?

• Please run clang-format (make format) on the changes to ensure that the code style is correct.

Ok

• Generally I wonder why the max number should be higher when there are more cores.

Can anyone explain why this makes sense? Maybe it's just a coincidence because more cores could mean that the CPU cache is larger?

We are also not sure, but we reached the same conclussion, the CPU cache, but the test gave us better performance depending on the CPU and teh max amount of particles when working with large amount of particles.

I'll do the changes ASAP and upload them.

Thanks!

I left the define because I was not sure if that variable was used in some other place, I'm new modifying this kind of code, so you mean that I just create a function "static int MAX_PARTICLES_PER_TASK(void)" and call that function instead of using the variable?

You could just do a simple search for that define on the entire code base. It is only used in this one place.
When making it a function, it should have a name that is not all upper case.
Maybe you don't even need this function when you implement the simplification you talked about in blender-chat.

As discussed on blender.chat, for the 4 million particles case and the tested CPUs, I think this logic boils down to:

int numtasks = min_ii(max_ii(BLI_system_thread_count(), 16), endpart - startpart);

Basically, change the strategy from batches of 256 tasks to about 1 task per thread.

This would help avoid the overhead locking that you have with many tasks. The downside is if you have an uneven distribution of work some threads may be idle, but not sure that's much of a concern for particle. And you could probably increase the number of tasks a bit by e.g. 4x without much overhead.

int numtasks = min_ii(BLI_system_thread_count() * 4, endpart - startpart);

I just tested the patch in a Windows 10 64 bits i9 16 threads 32 GB and the difference with 10.000.000 particles is huge. Using current master takes more than 1'5 minutes, but with the new patch is +/- 5 seconds.