Cache and Efficiency

Today, the use of multiple CPU cores has become a challenge for every programmer. For a slightly experienced programmer, OMP is undoubtedly the fastest shortcut and has a very high effect, which can basically increase the efficiency by 1.8 times (dual-core CPU ).

The endurance child has read the OMP Introduction Article and put it into practice in 3D applications. The results are remarkable. It is handy for using bone computing, skin computing, vertex coordinates, texture coordinates, and normal interpolation, on the Rise, after the key part of computing was rewritten using the SSE command, the overall efficiency was improved by about 4 times.

Some problems are found in this process:

1. Use the SSE command to write a function for processing one data and a function for processing multiple data. From the perspective of a single thread, it is obvious that reducing the overhead of function calls can improve the efficiency. Therefore, the following statement is used to process a piece of data:

1. // Num_threads: Number of OMP threads started
2. Int num_threads = omp_get_max_threads ();
3. // SPT: Data allocated to each thread
4. Int SPT = ucount/num_threads;
5. If (SPT> 0)
6. {
7. // Each thread processes a continuous data segment
8. # Pragma OMP parallel
9. For (INT I = 0; I <num_threads; ++ I)
10. {
11. Int nstart = I * SPT;
12. Sse_processdatas (buff + nstart, SPT );
13. }
14. }
15. For (INT I = num_threads * SPT; I <ucount; ++ I)
16. Sse_processdata (buff [I]);

The test results almost didn't show my chin dislocation, and the results showed that the running result of this writing method is not as fast as that of a single thread. The single-threaded code is as follows:

1. For (INT I = 0; I <ucount; I + = 4)
2. {
3. Sse_processdata (buff [I]);
4. }

However, simply adding the OMP command in front of a Single-thread Code improves the efficiency by about 0.9 times (AMD 3800 +, dual-core CPU:

1. # Pragma OMP parallel
2. For (INT I = 0; I <ucount; I + = 4)
3. {
4. Sse_processdata (buff [I]);
5. }

Incredible.

I am not a special root-user. Everything starts with practice. At the same time, I keep in mind the next rule: The OMP optimization rules are good, and some seemingly clever tips are not good. I am always honest and practical with OMP. Under the guidance of this idea, other optimizations will be smooth and exciting. I started to explain to my wife how to link OMP and MPI with shoes. When I drank several packets of coffee during the day, I began to suffer from insomnia in the middle of the night.

As the saying goes, we often see rivers and lakes drifting. How can we leave without a knife? How can we avoid wet shoes? OMP gave me another lesson when doing Ray and model triangle-by-triangle interaction. According to the previous experience, this code is very conservative and well-disciplined:

Single-thread code:

1. Float fmaxdistance = flt_max;
2. Int ntriangle =-1;
3. For (INT I = 0; I <ncount; I + = 3)
4. {
5. Float temp; // Ray and triangle surface (pvertex [pindex [I + 0], pvertex [pindex [I + 1], pvertex [pindex [I + 2]) intersection distance
6. If (false = intersecttriangleline (pvertex [pindex [I + 0],
7. Pvertex [pindex [I + 1],
8. Pvertex [pindex [I + 2],
9. Ray, null, & temp ))
10. Continue;
11. If (temp <0)
12. Continue;
14. If (temp <fmaxdistance)
15. {
16. Fmaxdistance = temp;
17. Ntriangle = I;
18. }
19. }

Multi-threaded code. A typical version of OMP for minimum value:

1. Int NTT [2] = {-1,-1 };
2. Float f [2] = {flt_max, flt_max };
3. # Pragma OMP parallel for num_threads (2)
4. For (INT I = 0; I <ncount; I + = 3)
5. {
6. Float temp; // Ray and triangle surface (pvertex [pindex [I + 0], pvertex [pindex [I + 1], pvertex [pindex [I + 2])
8. Intersection distance
9. If (false = intersecttriangleline (pvertex [pindex [I + 0],
10. Pvertex [pindex [I + 1],
11. Pvertex [pindex [I + 2],
12. Ray, null, & temp ))
13. Continue;
14. If (temp <0)
15. Continue;
17. Int threadid = omp_get_thread_num ();
18. If (temp <F [threadid])
19. {
20. F [threadid] = temp;
21. NTT [threadid] = I;
22. }
23. }
25. If (F [0] <F [1])
26. {
27. Fmaxdistance = f [0];
28. Ntriangle = NTT [0];
29. }
30. Else
31. {
32. Fmaxdistance = f [1];
33. Ntriangle = NTT [1];
34. }

I am very happy to conduct the test (my unit test habits are good), and the results almost didn't let my chin dislocation again-the efficiency has dropped by about 1/8!

After that, I repeatedly tried to modify it. Is it possible that the OMP should not be synchronized? Is the variable reasonably shared, private, or firstprivate? Check the information, access the Internet, and read msdn ..... the 17th martial arts were used up and basically abandoned. Finally, I thought of using the last weapon: ASM. because of the test efficiency, all previous compilation and tests were carried out in the release version. After the OMP code is added to the Assembly, it is more difficult to understand and many variables do not know the value, change this time to debug for efficiency testing. soon, the results are shown below:
First case

1. # Pragma OMP parallel
2. For (INT I = 0; I <ucount; I + = 4)
3. {
4. Sse_processdata (buff [I]);
5. }

The OMP optimization result is

1. // Thread 0:
2. For (INT I = 0; I <ucount; I + = 8)
3. {
4. Sse_processdata (buff [I]);
5. }
6. // Thread 1:
7. For (INT I = 4; I <ucount; I + = 8)
8. {
9. Sse_processdata (buff [I]);
10. }

In the second case, the OMP optimization result is:

1. // Thread 0:
2. For (INT I = 0; I <ucount/2; I + = 3)
3. {
4. ...
5. }
6. // Thread 1:
7. For (INT I = ucount/2; I <ucount; I + = 3)
8. {
9. ...
10. }

Obviously, the difference lies in the way of loop. what are the rules for the differences between OMP compilation results? Obviously, they are related to context or pointer usage. if anyone knows these details, please let us know.

Report a suspicious attitude and modify the code in the second case as follows:

1. Int NTT [2] = {-1,-1 };
2. Float f [2] = {flt_max, flt_max };
3. # Pragma OMP parallel sections num_threads (2)
4. {
5. # Pragma OMP Section
6. {
7. Int threadid = omp_get_thread_num ();
8. For (INT I = 0; I <ncount; I + = 6)
9. {
10. Float temp;
11. If (false = intersecttriangleline (pvertex [pindex [I + 0],
12. Pvertex [pindex [I + 1],
13. Pvertex [pindex [I + 2],
14. Ray, null, & temp ))
15. Continue;
16. If (temp <0)
17. Continue;
19. If (temp <F [threadid])
20. {
21. F [threadid] = temp;
22. NTT [threadid] = I;
23. }
24. }
25. }
26. # Pragma OMP Section
27. {
28. Int threadid = omp_get_thread_num ();
29. For (INT I = 3; I <ncount; I + = 6)
30. {
31. Float temp;
32. If (false = intersecttriangleline (pvertex [pindex [I + 0],
33. Pvertex [pindex [I + 1],
34. Pvertex [pindex [I + 2],
35. Ray, null, & temp ))
36. Continue;
37. If (temp <0)
38. Continue;
40. If (temp <F [threadid])
41. {
42. F [threadid] = temp;
43. NTT [threadid] = I;
44. }
45. }
46. }
47. }
49. If (F [0] <F [1])
50. {
51. Fmaxdistance = f [0];
52. Ntriangle = NTT [0];
53. }
54. Else
55. {
56. Fmaxdistance = f [1];
57. Ntriangle = NTT [1];
58. }

(Supplement: The above code is not the final code. The final code is grouped and cyclically calculated based on the current number of CPU cores. The code is not at hand and will not be presented if it is not complex)

 

That is to say, for two threads, Thread 0 processes an odd number of triangles, and thread 1 processes an even number of triangles.
The test results show that the efficiency has been improved by more than 0.8.

"Hey, hey, buddy, you have already passed the article. Why are you still not having to answer the question ?" -- The Reader roared and looked around for pebbles or rotten eggs.
"WUSA... quiet, quiet, I have been hanging on the title !" ---- I raised an umbrella that I had prepared long ago.

Why? Why? Why?
One thing I did not mention in the previous article: To take care of GPU Cache Optimization, all of my model data is cache optimized for 16 vertices cached by geforce2, that is, this is also an advantage when the CPU processes these vertices. In two threads, two triangles are processed simultaneously. If they are processed at the same speed, they are basically processing the adjacent triangles, and these adjacent triangles, whether they are indexes, or vertex, the probability of being in the cache of the CPU is quite large, and the efficiency of the cache effect is relatively small. When data is divided into two segments for processing, the CPU needs to cache four segments of memory at the same time (two indexes and two vertices ), when the cache is not large enough (AMD's U cache is small), the efficiency reduction caused by the cache effectiveness directly offsets the Efficiency Improvement of multithreading and even slows down!

To verify this, when I loaded the model, I randomly replaced the Triangle Index to disrupt the CPU cache vertex data. The test again showed that the efficiency had dropped significantly.

 

I have no questions!