Гость
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Особенности многопоточности виндовса и линукса, AMD и Intel / 25 сообщений из 116, страница 1 из 5
08.04.2019, 15:08
    #39798188
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Запушил трассировщик CardRaytracer распаралелленный на акторах.

Исходники
...
Рейтинг: 0 / 0
09.04.2019, 09:22
    #39798533
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Смержил. Вечером потещу.
...
Рейтинг: 0 / 0
09.04.2019, 20:41
    #39799037
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Затестил. Пока результат .. не очень. Складывается ощущение что где-то идет жесткая конкуренция
между вычислительными потоками. Приложение в 1 поток отработало быстрее чем многопоточные кейсы.

Я слегка изменил скриптик добавив 3-й опциональный параметр от 1.. до 12
Код: sql
1.
2.
3.
4.
5.
6.
7.
#!/bin/bash -v

for i in {1..12}
do
   echo "Start with $i thread(s)"
   time ./card-raytracer-cpp-mt.exe $i.ppm $i
done



Щас приаттачу лог и цифирки.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
#!/bin/bash -v

for i in {1..12}
do
   echo "Start with $i thread(s)"
   time ./card-raytracer-cpp-mt.exe $i.ppm $i
done
Start with 1 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 1 threads to file 1.ppm ...
Init end: 36 msec

------- STAT -------
thread_max     1
parallel_run   1
thread_create  1
thread_wake_up 1
try_wake_up    243
msg_create     262144
actor_create   3
actor_get      0
actor_find     4
actor_not_run  0
cache_found    2
cache_bad      0
cache_full     524529
resource_lock  1
msg_send       786432
msg_send/sec   79889

Time: 9844 msec

real	0m9.851s
user	0m9.868s
sys	0m0.016s
Start with 2 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 2 threads to file 2.ppm ...
Init end: 53 msec

------- STAT -------
thread_max     2
parallel_run   2
thread_create  2
thread_wake_up 2
try_wake_up    49
msg_create     262144
actor_create   3
actor_get      0
actor_find     8
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262195
resource_lock  2
msg_send       786432
msg_send/sec   40544

Time: 19397 msec

real	0m19.403s
user	0m20.665s
sys	0m13.215s
Start with 3 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 3 threads to file 3.ppm ...
Init end: 69 msec

------- STAT -------
thread_max     5
parallel_run   4
thread_create  5
thread_wake_up 3
try_wake_up    172
msg_create     262144
actor_create   3
actor_get      0
actor_find     14
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262601
resource_lock  3
msg_send       786432
msg_send/sec   44193

Time: 17795 msec

real	0m17.801s
user	0m21.843s
sys	0m23.147s
Start with 4 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 4 threads to file 4.ppm ...
Init end: 70 msec

------- STAT -------
thread_max     5
parallel_run   4
thread_create  5
thread_wake_up 4
try_wake_up    113
msg_create     262144
actor_create   3
actor_get      0
actor_find     15
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262299
resource_lock  4
msg_send       786432
msg_send/sec   38652

Time: 20346 msec

real	0m20.352s
user	0m26.864s
sys	0m43.069s
Start with 5 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 5 threads to file 5.ppm ...
Init end: 67 msec

------- STAT -------
thread_max     6
parallel_run   5
thread_create  6
thread_wake_up 5
try_wake_up    206
msg_create     262144
actor_create   3
actor_get      0
actor_find     18
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     263025
resource_lock  5
msg_send       786432
msg_send/sec   28075

Time: 28011 msec

real	0m28.016s
user	0m34.124s
sys	1m26.774s
Start with 6 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 6 threads to file 6.ppm ...
Init end: 68 msec

------- STAT -------
thread_max     7
parallel_run   6
thread_create  7
thread_wake_up 6
try_wake_up    201
msg_create     262144
actor_create   3
actor_get      0
actor_find     21
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262507
resource_lock  6
msg_send       786432
msg_send/sec   26394

Time: 29795 msec

real	0m29.801s
user	0m37.429s
sys	1m59.716s
Start with 7 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 7 threads to file 7.ppm ...
Init end: 53 msec

------- STAT -------
thread_max     8
parallel_run   7
thread_create  8
thread_wake_up 7
try_wake_up    167
msg_create     262144
actor_create   3
actor_get      0
actor_find     24
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262445
resource_lock  7
msg_send       786432
msg_send/sec   26198

Time: 30018 msec

real	0m30.025s
user	0m39.843s
sys	2m27.361s
Start with 8 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 8 threads to file 8.ppm ...
Init end: 62 msec

------- STAT -------
thread_max     9
parallel_run   8
thread_create  9
thread_wake_up 8
try_wake_up    312
msg_create     262144
actor_create   3
actor_get      0
actor_find     27
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     263302
resource_lock  8
msg_send       786432
msg_send/sec   26198

Time: 30018 msec

real	0m30.022s
user	0m41.379s
sys	2m53.991s
Start with 9 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 9 threads to file 9.ppm ...
Init end: 62 msec

------- STAT -------
thread_max     10
parallel_run   9
thread_create  10
thread_wake_up 9
try_wake_up    162
msg_create     262144
actor_create   3
actor_get      0
actor_find     29
actor_not_run  0
cache_found    2
cache_bad      0
cache_full     262347
resource_lock  9
msg_send       786432
msg_send/sec   26570

Time: 29598 msec

real	0m29.603s
user	0m42.097s
sys	3m19.522s
Start with 10 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 10 threads to file 10.ppm ...
Init end: 57 msec

------- STAT -------
thread_max     11
parallel_run   10
thread_create  11
thread_wake_up 10
try_wake_up    399
msg_create     262144
actor_create   3
actor_get      0
actor_find     33
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     265511
resource_lock  10
msg_send       786432
msg_send/sec   26454

Time: 29728 msec

real	0m29.734s
user	0m43.622s
sys	3m47.234s
Start with 11 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 11 threads to file 11.ppm ...
Init end: 57 msec

------- STAT -------
thread_max     12
parallel_run   11
thread_create  12
thread_wake_up 11
try_wake_up    351
msg_create     262144
actor_create   3
actor_get      0
actor_find     36
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     263099
resource_lock  11
msg_send       786432
msg_send/sec   26665

Time: 29493 msec

real	0m29.500s
user	0m44.572s
sys	4m12.562s
Start with 12 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 12 threads to file 12.ppm ...
Init end: 65 msec

------- STAT -------
thread_max     13
parallel_run   12
thread_create  13
thread_wake_up 16
try_wake_up    185
msg_create     262144
actor_create   3
actor_get      0
actor_find     46
actor_not_run  0
cache_found    2
cache_bad      0
cache_full     262307
resource_lock  15
msg_send       786432
msg_send/sec   26488

Time: 29690 msec

real	0m29.695s
user	0m44.418s
sys	4m42.378s

...
Рейтинг: 0 / 0
09.04.2019, 21:50
    #39799042
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Еще заметно что рабочие потоки не загружают ядра на 100%. Как будто они где-то простаивают.
...
Рейтинг: 0 / 0
09.04.2019, 21:58
    #39799043
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
После 6 потоков время не растет. Запирает как будто есть какой-то ограничитель.
И вообще .. должно не расти а уменьшаться.
...
Рейтинг: 0 / 0
09.04.2019, 22:01
    #39799044
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Скрин где видно простой процессоров на 10 потоках.
...
Рейтинг: 0 / 0
10.04.2019, 08:13
    #39799136
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
maytonЗатестил. Пока результат .. не очень. Складывается ощущение что где-то идет жесткая конкуренция
между вычислительными потоками. Приложение в 1 поток отработало быстрее чем многопоточные кейсы.

Я слегка изменил скриптик добавив 3-й опциональный параметр от 1.. до 12
Код: sql
1.
2.
3.
4.
5.
6.
7.
#!/bin/bash -v

for i in {1..12}
do
   echo "Start with $i thread(s)"
   time ./card-raytracer-cpp-mt.exe $i.ppm $i
done



Щас приаттачу лог и цифирки.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
#!/bin/bash -v

for i in {1..12}
do
   echo "Start with $i thread(s)"
   time ./card-raytracer-cpp-mt.exe $i.ppm $i
done
Start with 1 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 1 threads to file 1.ppm ...
Init end: 36 msec

------- STAT -------
thread_max     1
parallel_run   1
thread_create  1
thread_wake_up 1
try_wake_up    243
msg_create     262144
actor_create   3
actor_get      0
actor_find     4
actor_not_run  0
cache_found    2
cache_bad      0
cache_full     524529
resource_lock  1
msg_send       786432
msg_send/sec   79889

Time: 9844 msec

real	0m9.851s
user	0m9.868s
sys	0m0.016s
Start with 2 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 2 threads to file 2.ppm ...
Init end: 53 msec

------- STAT -------
thread_max     2
parallel_run   2
thread_create  2
thread_wake_up 2
try_wake_up    49
msg_create     262144
actor_create   3
actor_get      0
actor_find     8
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262195
resource_lock  2
msg_send       786432
msg_send/sec   40544

Time: 19397 msec

real	0m19.403s
user	0m20.665s
sys	0m13.215s
Start with 3 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 3 threads to file 3.ppm ...
Init end: 69 msec

------- STAT -------
thread_max     5
parallel_run   4
thread_create  5
thread_wake_up 3
try_wake_up    172
msg_create     262144
actor_create   3
actor_get      0
actor_find     14
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262601
resource_lock  3
msg_send       786432
msg_send/sec   44193

Time: 17795 msec

real	0m17.801s
user	0m21.843s
sys	0m23.147s
Start with 4 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 4 threads to file 4.ppm ...
Init end: 70 msec

------- STAT -------
thread_max     5
parallel_run   4
thread_create  5
thread_wake_up 4
try_wake_up    113
msg_create     262144
actor_create   3
actor_get      0
actor_find     15
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262299
resource_lock  4
msg_send       786432
msg_send/sec   38652

Time: 20346 msec

real	0m20.352s
user	0m26.864s
sys	0m43.069s
Start with 5 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 5 threads to file 5.ppm ...
Init end: 67 msec

------- STAT -------
thread_max     6
parallel_run   5
thread_create  6
thread_wake_up 5
try_wake_up    206
msg_create     262144
actor_create   3
actor_get      0
actor_find     18
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     263025
resource_lock  5
msg_send       786432
msg_send/sec   28075

Time: 28011 msec

real	0m28.016s
user	0m34.124s
sys	1m26.774s
Start with 6 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 6 threads to file 6.ppm ...
Init end: 68 msec

------- STAT -------
thread_max     7
parallel_run   6
thread_create  7
thread_wake_up 6
try_wake_up    201
msg_create     262144
actor_create   3
actor_get      0
actor_find     21
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262507
resource_lock  6
msg_send       786432
msg_send/sec   26394

Time: 29795 msec

real	0m29.801s
user	0m37.429s
sys	1m59.716s
Start with 7 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 7 threads to file 7.ppm ...
Init end: 53 msec

------- STAT -------
thread_max     8
parallel_run   7
thread_create  8
thread_wake_up 7
try_wake_up    167
msg_create     262144
actor_create   3
actor_get      0
actor_find     24
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     262445
resource_lock  7
msg_send       786432
msg_send/sec   26198

Time: 30018 msec

real	0m30.025s
user	0m39.843s
sys	2m27.361s
Start with 8 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 8 threads to file 8.ppm ...
Init end: 62 msec

------- STAT -------
thread_max     9
parallel_run   8
thread_create  9
thread_wake_up 8
try_wake_up    312
msg_create     262144
actor_create   3
actor_get      0
actor_find     27
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     263302
resource_lock  8
msg_send       786432
msg_send/sec   26198

Time: 30018 msec

real	0m30.022s
user	0m41.379s
sys	2m53.991s
Start with 9 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 9 threads to file 9.ppm ...
Init end: 62 msec

------- STAT -------
thread_max     10
parallel_run   9
thread_create  10
thread_wake_up 9
try_wake_up    162
msg_create     262144
actor_create   3
actor_get      0
actor_find     29
actor_not_run  0
cache_found    2
cache_bad      0
cache_full     262347
resource_lock  9
msg_send       786432
msg_send/sec   26570

Time: 29598 msec

real	0m29.603s
user	0m42.097s
sys	3m19.522s
Start with 10 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 10 threads to file 10.ppm ...
Init end: 57 msec

------- STAT -------
thread_max     11
parallel_run   10
thread_create  11
thread_wake_up 10
try_wake_up    399
msg_create     262144
actor_create   3
actor_get      0
actor_find     33
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     265511
resource_lock  10
msg_send       786432
msg_send/sec   26454

Time: 29728 msec

real	0m29.734s
user	0m43.622s
sys	3m47.234s
Start with 11 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 11 threads to file 11.ppm ...
Init end: 57 msec

------- STAT -------
thread_max     12
parallel_run   11
thread_create  12
thread_wake_up 11
try_wake_up    351
msg_create     262144
actor_create   3
actor_get      0
actor_find     36
actor_not_run  0
cache_found    1
cache_bad      0
cache_full     263099
resource_lock  11
msg_send       786432
msg_send/sec   26665

Time: 29493 msec

real	0m29.500s
user	0m44.572s
sys	4m12.562s
Start with 12 thread(s)
compile Apr  9 2019 20:27:37
lite_thread 12 threads to file 12.ppm ...
Init end: 65 msec

------- STAT -------
thread_max     13
parallel_run   12
thread_create  13
thread_wake_up 16
try_wake_up    185
msg_create     262144
actor_create   3
actor_get      0
actor_find     46
actor_not_run  0
cache_found    2
cache_bad      0
cache_full     262307
resource_lock  15
msg_send       786432
msg_send/sec   26488

Time: 29690 msec

real	0m29.695s
user	0m44.418s
sys	4m42.378s


Забыл вывод статистики отключить, запушил, обновись.

Результаты очень странные, свел в таблицу
Потоков Время мс19844219397317795420346528011629795730018830018929598 102972811294931229690
Время должно уменьшаться, а тут наоборот. Запусти еще с ключом 0, это исходный однопоточный код без акторов.
Затестил у себя на i7-3770К 4 ядра + HT
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
C:\Test>card_raytracer.exe 1.ppm 1
C:\Test>card_raytracer.exe 1.ppm 0
compile Apr 10 2019 09:11:59
original code to file 1.ppm ...
Time: 13610 msec

compile Apr 10 2019 09:11:59
lite_thread 1 threads to file 1.ppm ...
Init end: 34 msec
Time: 13741 msec

C:\Test>card_raytracer.exe 1.ppm 2
compile Apr 10 2019 09:11:59
lite_thread 2 threads to file 1.ppm ...
Init end: 36 msec
Time: 6999 msec

C:\Test>card_raytracer.exe 1.ppm 3
compile Apr 10 2019 09:11:59
lite_thread 3 threads to file 1.ppm ...
Init end: 53 msec
Time: 5198 msec

C:\Test>card_raytracer.exe 1.ppm 4
compile Apr 10 2019 09:11:59
lite_thread 4 threads to file 1.ppm ...
Init end: 42 msec
Time: 4146 msec

C:\Test>card_raytracer.exe 1.ppm 5
compile Apr 10 2019 09:11:59
lite_thread 5 threads to file 1.ppm ...
Init end: 55 msec
Time: 3757 msec

C:\Test>card_raytracer.exe 1.ppm 6
compile Apr 10 2019 09:11:59
lite_thread 6 threads to file 1.ppm ...
Init end: 54 msec
Time: 3494 msec

C:\Test>card_raytracer.exe 1.ppm 7
compile Apr 10 2019 09:11:59
lite_thread 7 threads to file 1.ppm ...
Init end: 64 msec
Time: 3192 msec

C:\Test>card_raytracer.exe 1.ppm 8
compile Apr 10 2019 09:11:59
lite_thread 8 threads to file 1.ppm ...
Init end: 63 msec
Time: 3057 msec

Потоков Время мс Ускорение раз0136101137411.0269991.9351982.6441463.3537573.6634943.9731924.3830574.5
i7 6700K 4 ядра без HT
Потоков Время мс Ускорение раз0115301110061.0259811.9343182.7435573.2
Похоже этот тест не очень подходит для замера производительности одного ядра, но очень сильно удивил твой результат, медленнее не должно становиться. Если это косяк моей либы с акторами, то это очень плохо, я не тестил ее на многоядерном линуксе. Сделаю загрузочную флэшку с линуксом, потестю у себя.
...
Рейтинг: 0 / 0
10.04.2019, 12:52
    #39799273
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Насколько я понимаю рендеринг картинки должен подгружать CPU.
В топе с 10-потоками висели ядра загруженные едва-ли на треть.
Где-то они простаивают.

А как отключать твои акторы? Там вроде 1 аргумент в конце только.
...
Рейтинг: 0 / 0
10.04.2019, 14:06
    #39799353
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
maytonНасколько я понимаю рендеринг картинки должен подгружать CPU.
В топе с 10-потоками висели ядра загруженные едва-ли на треть.
Где-то они простаивают.
Похоже проблема в самодельном мутексе. В линуксе многоядерном я его не запускал
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
class lite_mutex_t {
	std::atomic_flag af = ATOMIC_FLAG_INIT;

public:
	void lock() noexcept {
		while (af.test_and_set(std::memory_order_acquire)) {
#if defined LT_WIN
			Sleep(0);
#else
			usleep(20);
#endif
		}

	}
}; 


Попробуй цифру 20 на поменьше заменить.
maytonА как отключать твои акторы? Там вроде 1 аргумент в конце только.
Задать 0 потоков
Код: sql
1.
card_raytracer.exe 0.ppm 0
...
Рейтинг: 0 / 0
10.04.2019, 14:26
    #39799369
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Возможно в этом и проблема. Второе. Как фиксить?
...
Рейтинг: 0 / 0
10.04.2019, 14:37
    #39799381
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Чтобы не гадать - заменил для линукса блокировку на std::mutex, обновляйся. Должно заработать.
...
Рейтинг: 0 / 0
10.04.2019, 14:50
    #39799393
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Dima T, вечерочком. Щас я погружен в Амазоны...
...
Рейтинг: 0 / 0
10.04.2019, 18:00
    #39799595
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Я не понял как ты смотрел нагрузку в разрезе процов. Гугл предложил поставить htop, поставил.

Дал виртуалке 3 ядра (на хосте 4 без HT), htop показывает загрузку 80+% на каждом ядре, суммарно 280%, но общее время чуть меньше однопоточного (10 сек вместо 12). Может это проблема многоядерных виртуалок. Флэшку с линуксом не нашел, на реальном железе потестить не получилось. Жду твой замер.
...
Рейтинг: 0 / 0
10.04.2019, 18:11
    #39799597
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
ОК.
...
Рейтинг: 0 / 0
10.04.2019, 18:12
    #39799599
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Я кстати в пул-реквестах вижу только 1. На удаление статистики. А был ли второй?
...
Рейтинг: 0 / 0
10.04.2019, 18:21
    #39799603
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
maytonЯ кстати в пул-реквестах вижу только 1. На удаление статистики. А был ли второй?
Я так понял второй коммит в него же попал. Посмотри, там внутри должен быть коммит про замену на std::mutex

Для проверки я вынес тип блокировки в вывод. Если все нормально, то появится строчка
Код: plaintext
compile Apr 10 2019 17:47:14   LOCK: std::mutex
...
Рейтинг: 0 / 0
10.04.2019, 22:57
    #39799664
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Смержил. Смотрю. Пока - хреновенько. Щас покажу фотку с htop.
Судя по вики цветовая маркировка (зеленый - красный) должна означать соотв активность
- потоков пользователя
- потоков ядра
https://ru.wikipedia.org/wiki/Htop

В нашем случае мы слишком много сидим в ядре.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
mayton@mayton-ryzen:~/git/CardRaytracerBenchmark/cpp-mt$ ./make.sh 
#!/bin/bash -v

OPTIONS="-O3 -march=native -pthread -std=c++11"

g++ $OPTIONS card_raytracer.cpp       -o card-raytracer-cpp-mt.exe

mayton@mayton-ryzen:~/git/CardRaytracerBenchmark/cpp-mt$ ./run.sh 
#!/bin/bash -v

time ./card-raytracer-cpp-mt.exe 1.ppm
compile Apr 10 2019 22:51:14   LOCK: std::mutex
lite_thread 12 threads to file 1.ppm ...
Init end: 53 msec
Time: 29553 msec

real	0m29.557s
user	0m43.150s
sys	4m41.349s

mayton@mayton-ryzen:~/git/CardRaytracerBenchmark/cpp-mt$ ./run.sh 
#!/bin/bash -v

time ./card-raytracer-cpp-mt.exe 1.ppm
compile Apr 10 2019 22:51:14   LOCK: std::mutex
lite_thread 12 threads to file 1.ppm ...
Init end: 55 msec
Time: 29554 msec

real	0m29.558s
user	0m44.557s
sys	4m39.494s
...
Рейтинг: 0 / 0
10.04.2019, 23:03
    #39799666
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Вместе с htop.
...
Рейтинг: 0 / 0
10.04.2019, 23:10
    #39799667
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Если задать последний аргумент = 0 то вроде получше. 9 секунд. И красный градусник исчезает.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
mayton@mayton-ryzen:~/git/CardRaytracerBenchmark/cpp-mt$ ./run.sh 
#!/bin/bash -v

time ./card-raytracer-cpp-mt.exe 1.ppm 0
compile Apr 10 2019 22:51:14   LOCK: std::mutex
original code to file 1.ppm ...
Time: 9472 msec

real	0m9.475s
user	0m9.473s
sys	0m0.000s



Вобщем если это дело в акторах - то их надо фиксить. Они под линуксами не летают.
...
Рейтинг: 0 / 0
11.04.2019, 08:46
    #39799706
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
maytonЕсли задать последний аргумент = 0 то вроде получше. 9 секунд. И красный градусник исчезает.
Это оригинальный код без акторов. С акторами в 1 поток близкое время 21857913 , а дальше начинается какая-то хрень ((

maytonВобщем если это дело в акторах - то их надо фиксить. Они под линуксами не летают.
Сегодня сделаю флэшку загрузочную с линуксом, затестю в линуксе.

mayton
Код: sql
1.
2.
3.
4.
5.
6.
original code to file 1.ppm ...
Time: 9472 msec

real	0m9.475s
user	0m9.473s
sys	0m0.000s



Код: sql
1.
2.
3.
4.
5.
6.
lite_thread 12 threads to file 1.ppm ...
Time: 29554 msec

real	0m29.558s
user	0m44.557s
sys	4m39.494s


Если я правильно понимаю, то с акторами 90% времени проходит в режиме ядра, т.е. тратится на синхронизацию потоков.

В прошлый раз 21857731 похожее время было, так что вероятно дело не в usleep()
mayton
Код: sql
1.
2.
3.
4.
5.
Time: 29690 msec

real	0m29.695s
user	0m44.418s
sys	4m42.378s



Есть подозрение на распараллеливающийся актор (расчет одной точки), т.е. несколько однотипных обработчиков с общей очередью. Возможно когда несколько потоков пытаются одновременно из одной очереди получить сообщение, то это получается далеко не с первого раза. При увеличении количества потоков вероятность такой ситуации возрастает. Затем после расчета ситуация повторяется еще раз, т.к. все 12 потоков пишут результат в одну очередь следующего актора, который выводом занимается.

Непонятно почему в виндовсе этой проблемы нет на 8 лог. процах?

Попробую заменить std::mutex на линуксовый мутекс.
...
Рейтинг: 0 / 0
11.04.2019, 09:31
    #39799724
kealon(Ruslan)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Dima TЕсть подозрение на распараллеливающийся актор (расчет одной точки), т.е. несколько однотипных обработчиков с общей очередью. Возможно когда несколько потоков пытаются одновременно из одной очереди получить сообщение, то это получается далеко не с первого раза. При увеличении количества потоков вероятность такой ситуации возрастает. Затем после расчета ситуация повторяется еще раз, т.к. все 12 потоков пишут результат в одну очередь следующего актора, который выводом занимается.

Непонятно почему в виндовсе этой проблемы нет на 8 лог. процах?

Попробую заменить std::mutex на линуксовый мутекс.привет, ты же вроде делал sleep под виндой? у винды вытесняемая многопоточнось
...
Рейтинг: 0 / 0
11.04.2019, 10:38
    #39799765
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
kealon(Ruslan)Dima TЕсть подозрение на распараллеливающийся актор (расчет одной точки), т.е. несколько однотипных обработчиков с общей очередью. Возможно когда несколько потоков пытаются одновременно из одной очереди получить сообщение, то это получается далеко не с первого раза. При увеличении количества потоков вероятность такой ситуации возрастает. Затем после расчета ситуация повторяется еще раз, т.к. все 12 потоков пишут результат в одну очередь следующего актора, который выводом занимается.

Непонятно почему в виндовсе этой проблемы нет на 8 лог. процах?

Попробую заменить std::mutex на линуксовый мутекс.привет, ты же вроде делал sleep под виндой? у винды вытесняемая многопоточнось
Верно, под виндой spinlock + Sleep(0), но вытеснять некуда, т.к. потоков столько же сколько логических процов.
Под виндой работает, тут речь про линукс mayton`а, там тормозит и со spinlock и с std::mutex, осталось попробовать вариант с родным линуксовым мутексом.

Причем тормозит очень сильно, 12 потоков считают втрое дольше чем один. И самое главное там нагрузка на акторы мизерная, т.к. обработка сообщений достаточно тяжелая. Всего 27 тыс. сообщений в секунду при тестовой прокачке в 50 млн./сек.
...
Рейтинг: 0 / 0
11.04.2019, 10:50
    #39799774
kealon(Ruslan)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Dima TПричем тормозит очень сильно, 12 потоков считают втрое дольше чем один. И самое главное там нагрузка на акторы мизерная, т.к. обработка сообщений достаточно тяжелая. Всего 27 тыс. сообщений в секунду при тестовой прокачке в 50 млн./сек.всё логично, сброс кеша как раз раз в 5 убивает производительность памяти
sleep фактически заставлял планировщик работать с памятью только 1-му процу, притормаживая конкурирующие потоки

ну нельзя одну и ту же память долбить одновременно с разных процов :-(
...
Рейтинг: 0 / 0
11.04.2019, 13:19
    #39799858
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Dima Tkealon(Ruslan)пропущено...
привет, ты же вроде делал sleep под виндой? у винды вытесняемая многопоточнось
Верно, под виндой spinlock + Sleep(0), но вытеснять некуда, т.к. потоков столько же сколько логических процов.
Под виндой работает, тут речь про линукс mayton`а, там тормозит и со spinlock и с std::mutex, осталось попробовать вариант с родным линуксовым мутексом.

Причем тормозит очень сильно, 12 потоков считают втрое дольше чем один. И самое главное там нагрузка на акторы мизерная, т.к. обработка сообщений достаточно тяжелая. Всего 27 тыс. сообщений в секунду при тестовой прокачке в 50 млн./сек.
Ты что по 1 пикселю на поток считаешь?

Я бил картинку на прямоугольники в пропорции пополам или по золотому сечению (там
вобещем 3 стратегии деления области пополам).
И каждый поток у меня обрабатывал прямоугольник и потом на мьютексе стоял
ожидая когда освободится растр картинки чтобы слить туда результаты.

Это в реализации Java-mt.
...
Рейтинг: 0 / 0
11.04.2019, 13:22
    #39799861
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Особенности многопоточности виндовса и линукса, AMD и Intel
Еще можно посмотреть из любопытства как работает OpenMP.
В идеале добавить камент перед циклом и дальше
Код: plaintext
1.
#pragma omp parallel


- всё должно [i]взлететь в шоколаде [/i]. Вобщем как в сказке у Джоан Роулинг.
...
Рейтинг: 0 / 0
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Особенности многопоточности виндовса и линукса, AMD и Intel / 25 сообщений из 116, страница 1 из 5
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]