Thread performance with global objects

[Nitorami]

I made a simulation program whose core is encapsulated in Class TSim.

For optimum performance on multi core processors, I run two instances of TSim in separate threads, and combine their results after they have finished. In comparison to single thread operation, I get 50%...90% performance gain on a dual core CPU.

The simulation needs a lot of random numbers, therefore I replaced FPC's own Mersenne Twister by a simple but very fast random generator, encapsulated in object TRandGen.

I started with a single global instance of TRandGen, which is probably not the best idea. Manipulating RandGen's internal state by two concurrent processes might be detrimental to the generators properties... not sure. I expect that FPC's random generator uses critical sections to avoid that.
But that is not the issue. What puzzled me is that the global RandGen seems to cause a bottleneck, and performance breaks down to almost single core operation.

I can easily get round it by making the instances of TRandGen local to TSim. But why does the standard FPC generator, which is global in unit systems, not seem to cause this bottleneck ?

[Jonas Maebe]

I don't know where the performance difference could come from, unless you added a critical section. FPC's standard random number generator is not protected by a critical section, so you cannot safely use it from multiple threads at the same time.

[Nitorami]

Thank you. Is that generally true for system functions ? For instance when copying memory sections using "move", would I have to protect that by a Critical Section ?

As regards performance, I found that it drops severely if several threads try to write to the same global variables concurrently. I had not intended that, but it seems that the constants and initialized constants within my Rand function are global, no local as I thought, although the function is encapsulated within an object. That is a pitfall to remember, and in my case not only a performance issue but a fault, because instances of the generator should be independent.

Code: Pascal  [Select][+][-]

1. function TRandGen.MWC256: dword; //not thread safe
2. // MWC256 from Usenet posting by G. Marsaglia - Period 2^8222
3. var   t : qword;
4. const c : dword = 362436; //global !
5.       i : byte  = $FF;  //global !
6. begin
7.   inc (i);
8.   t := qword (809430660) * Q[i] + c;
9.   c      := hi (t);
10.   Q[i]   := lo (t);
11.   result := lo (t);
12. end;

 

[Leledumbo]

I had not intended that, but it seems that the constants and initialized constants within my Rand function are global, no local as I thought, although the function is encapsulated within an object.

Indeed, otherwise typed constants can't remember their values between function calls Use initialized variable instead if you want to keep them local.

[Nitorami]

Yes, of course. And my question on system.move was stupid, obviously it would cause problems to use move on the same memory location in several threads... think I had blinkers on.

Still, is there a way to know which library functions are thread safe and which are not ? The documentation does not seem to tell.

[User137]

Why would use of global constants make it not thread safe?

edit: I re-read the code, it seems he is modifying the values in code.

[taazz]

2 generic rules on thread safe functions
1) if it is not stated in the documents that it is thread safe then it is not.
2) if it accesses global variables it is not.

Keep in mind that when it comes to multi threading access to the code is mandatory your question is a good example of what not to do, ee "why my code is not as fast as yours" with out code to look at is not going to get much attention.

[Thaddy]

The above goes for any compiler, not just FPC... Thread safe programming is not easy.

[Nitorami]

@taazz: Thank you. To me, the question was of a principle nature rather than "where is the bug in my code". I feel I put it correctly, because I got responses that helped me understand the issue.

@User137: "use" of global variables is not the problem, of course threads may read global variables. Writing to global variables is the problem.

[argb32]

But that is not the issue. What puzzled me is that the global RandGen seems to cause a bottleneck, and performance breaks down to almost single core operation.

This may be caused by the fact that there are writes to the same memory block each time. CPU should load the values from memory and can't use L1 cache to ensure cache coherency. The issue may be hidden by storing the variables in registers by compiler but it seems not the case but may be the case with standard random().
Using own random generator with encapsulated state for each thread is best solution.

[taazz]

@taazz: Thank you. To me, the question was of a principle nature rather than "where is the bug in my code". I feel I put it correctly, because I got responses that helped me understand the issue.

Your feeling is wrong. The only thing that question is good is if you were thinking out loud.