0xd34df00d — C++11-threading правда соснул, OpenMP ...

0xd34df00d 18.12.2012 19:06 Azoth_primary

C++11-threading правда соснул, OpenMP рулез, на адекватность шедулинга полагаться не приходится. Восьмиядерная машина, два варианта параллелизации — через openmp (#pragma parallel for) и через std::async/std::future.
Вариант с OpenMP — http://bpaste.net/show/FBDFdJvyHNzRZhCjl... , ≈200 мс.
Вариант с ручным выставлением шедулинга и преаллокацией массива, чтобы избежать дорогих реаллокаций в критической секции — http://bpaste.net/show/EpbqoPHYhYMUhG7zZ... , 185-190 мс.
Вариант с std::async/std::thread — http://bpaste.net/show/1N6mDCGZNNKQyni1z... , 370 мс.

При этом само время работы программы в один поток — 500-600 мс. Так что OpenMP тоже соснул. Такие дела.

c++, говно

Recommended by:

@pooq: моча съела говно

#tfeoii

64 comments

recommend

bookmark

tree plain

1. radjah 18.12.2012 19:08 Miranda

А ручная ебля точно не надоест?

#tfeoii/1

2. 0xd34df00d → radjah /1 18.12.2012 19:09 Azoth_primary

Надоест, тем более, что экономия в 5% хуита.

#tfeoii/2

3. 238328 18.12.2012 19:39

2013 год а в крестах не реализовали и половины функциональных возможностей питона!

#tfeoii/3

4. 0xd34df00d → 238328 /3 18.12.2012 19:40 Azoth_primary

Хаскеля.

#tfeoii/4

5. hirthwork 18.12.2012 20:13

1. я не понимаю, почему ты используешь прагмы вместо встроенного в гоцаце parallel mode в std::for_each
2. я не понимаю, почему ты используешь вектор и критическую секцию вместо массива фиксированного размера, в который можно производить lock free запись используя atomic индекс записываемого элемента

соснули не библиотеки, соснул wannabe-программист

#tfeoii/5

6. 0xd34df00d → hirthwork /5 18.12.2012 20:14 Azoth_mac

Возможно, потому, что я не хочу ебаться лишний раз? Возможно, потому, что я знаю нормальные инструменты, от parMap в х-ле до QtConcurrent::mapped?

Я знаю про локфри, и знаю про атомики и атомик_инкремент для индекса, но зачем?
А параллел_моде уже позволит мне регулировать шедулинг, как в примере 2?

#tfeoii/6

7. hirthwork → 0xd34df00d /6 18.12.2012 20:20

> Я знаю про локфри, и знаю про атомики и атомик_инкремент для индекса, но зачем?
пиздец. пизде-е-ец. «Зачем мне думать головой и использовать lock-free алгоритмы, я лучше поставлю ещё одну критическую секцию. Кококо, я пишу критические секции сотнями, а потом обсираю в бложике чужие библиотеки для параллельных вычислений. Я — дедфуд, завидуйте мне»

#tfeoii/7

8. 0xd34df00d → hirthwork /7 18.12.2012 20:24 Azoth_primary

Пруф, что здесь критическая секция — узкое место.

#tfeoii/8

9. 0xd34df00d → hirthwork /7 18.12.2012 20:24 Azoth_primary

И какого хуя в 2012 году я должен раз за разом ебаться с лоу-левел говном там, где это совсем не нужно?

#tfeoii/9

10. hirthwork → 0xd34df00d /8 18.12.2012 20:26 talkonaut-iphone_5.91_67b1c873

в отличии от тебя у меня нет полного примера, в котором бы я мог поменять четыре строки и сравнить скорость. так что придётся тебе это сделать самому

#tfeoii/10

11. 0xd34df00d → hirthwork /10 18.12.2012 20:26 Azoth_mac

#tfeoii/11

12. hirthwork → 0xd34df00d /9 18.12.2012 20:27 talkonaut-iphone_5.91_67b1c873

какого хуя ты 2012 году вообще параллелишь задачи, которые требуют меньше секунды? запусти в отдельном потоке последовательный алгоритм, а пользователя в это время отвлеки плавной анимацией открывающегося окошка

#tfeoii/12

13. 0xd34df00d → hirthwork /12 18.12.2012 20:32 Azoth_mac

Потому что нет никаких окошек, запустились, обучились, классифицировали, вышли.
И да, это сейчас, а потом — скользящий контроль по LOO, что автоматически увеличивает время выполнения в сто раз в моем случае.

#tfeoii/13

14. hirthwork → 0xd34df00d /13 18.12.2012 20:34

> в сто раз
с каких пор такие мелочи волнуют человека столь смело использующего критические секции вместо одного атомика?

#tfeoii/14

15. 0xd34df00d → 0xd34df00d /13 18.12.2012 20:34 Azoth_mac

А, хотя пизжу, даже при LOO картинки-то один раз при запуске читаться будут.
Ну там тогда сам LOO параллелить буду, похуй.

#tfeoii/15

16. 0xd34df00d → hirthwork /14 18.12.2012 20:35 Azoth_mac

Чо.

#tfeoii/16

17. hirthwork 18.12.2012 20:37 talkonaut-iphone_5.91_67b1c873

кр. содержание предыдущей серии: ты — хуй и будешь оставаться им пока не выложишь замеры скорости без критической секции, но с атомик-индексом (и код тож,. ога)

#tfeoii/17

18. ulidtko → hirthwork /17 18.12.2012 21:33

знатно ты его

#tfeoii/18

19. hirthwork → ulidtko /18 18.12.2012 21:44 talkonaut-iphone_5.91_67b1c873

есть у меня подозрение, что он сейчас напишет «на самом деле задача стояла несколько иная, и алгоритм пришлось переделать» и представит публике новый кусок кода, в котором будут атомики, но из-за изменённого алгоритма сравнивать скорость будет нельзя и дедфуд кагбэ и ни при чём окажется и никто не узнает какое говно он в /0 написал

#tfeoii/19

20. 0xd34df00d → hirthwork /19 18.12.2012 21:46 Azoth_primary

Таки нет.

#tfeoii/20

21. hirthwork → 0xd34df00d /20 18.12.2012 21:47 talkonaut-iphone_5.91_67b1c873

именно ради этого /19 и был написан

#tfeoii/21

22. 0xd34df00d → hirthwork /21 18.12.2012 21:51 Azoth_primary

Че.

#tfeoii/22

23. hirthwork → 0xd34df00d /22 18.12.2012 21:53 talkonaut-iphone_5.91_67b1c873

результаты тестрования на атомиках давай, вот чего, предсказуемый ты наш

#tfeoii/23

24. 0xd34df00d → hirthwork /23 18.12.2012 21:54 Azoth_primary

Не изменились, уже потестил.

#tfeoii/24

25. 0xd34df00d → 0xd34df00d /24 18.12.2012 21:54 Azoth_primary

Правда, это мой первый код с атомиками из C++11, мог попутать.

#tfeoii/25

26. 0xd34df00d → 0xd34df00d /25 18.12.2012 21:55 Azoth_primary

learnData [std::atomic_fetch_add<size_t> (&learnIdx, 1)] = { img, type }; // СУТЬ

#tfeoii/26

27. 0xd34df00d 18.12.2012 21:57 Azoth_primary

Чятик, ты живой?

#tfeoii/27

28. hirthwork → 0xd34df00d /24 18.12.2012 22:06

критическую секцию-то убрать не забыл?

#tfeoii/28

29. 0xd34df00d → hirthwork /28 18.12.2012 22:06 Azoth_primary

Нет.

#tfeoii/29

30. hirthwork 18.12.2012 22:14

хм, а ты не пробовал сделать %s/const auto/const auto\&/g ? а то есть у меня подозрение что ты где-то перебрал с auto.

#tfeoii/30

31. 0xd34df00d → hirthwork /30 18.12.2012 22:15 Azoth_primary

Пробовал, сегфолт тогда, ибо каким-то хуем entry инвалидируется, и остается dangling reference.

#tfeoii/31

32. hirthwork → 0xd34df00d /31 18.12.2012 22:23

ну охуеть вообще. т.е. переписать на полноценный std::for_each, где всеми объектами управляешь ты, ты не осилил. т.е. у тебя куча копирований объектов, а ты гонишь на библиотеки, которыми распараллеливаешь?

#tfeoii/32

33. 0xd34df00d → hirthwork /32 18.12.2012 22:26 Azoth_primary

Еб твою. По-твоему, 600 миллисекунд (в однопоточной версии) занимает скопировать сто векторов по тыще пар даблов? Да не смеши мои тапочки.
И какого хуя спидап не 8x все равно?
Ладно, хер с ним, 4x, гипетрединг же.

#tfeoii/33

34. hirthwork → 0xd34df00d /33 18.12.2012 22:29 talkonaut-iphone_5.91_67b1c873

у тебя не только вектора копируются, но и всякие их path, наверняка

#tfeoii/34

35. 0xd34df00d → hirthwork /34 18.12.2012 22:31 Azoth_primary

-____-

#tfeoii/35

36. hirthwork → 0xd34df00d /35 18.12.2012 22:34 talkonaut-iphone_5.91_67b1c873

ты мог упереться во что угодно. в диск, в память, в устройство отрисовки. расслабься, у тебя и так трёхкратное ускорение на четырёх физических ядрах, это считается очень хорошим результатом

#tfeoii/36

37. 0xd34df00d → hirthwork /36 18.12.2012 22:35 Azoth_primary

> отрисовки
Его нет.
> IO
Его нет.
> трехкратное
Задача абсолютно параллельная, да и между make -j4 и make -j8 у меня почти двухкратное различие. Хотя я не ебу, конечно, какие блоки шарятся в HT, которые используются в этом всем матане.

#tfeoii/37

38. hirthwork → 0xd34df00d /37 18.12.2012 22:36 talkonaut-iphone_5.91_67b1c873

блядь, как нет io, если у тебя файлы там какие-то?

#tfeoii/38

39. 0xd34df00d → hirthwork /38 18.12.2012 22:37 Azoth_primary

Да все прокешировалось давно и и так в tmpfs.

#tfeoii/39

40. hirthwork → 0xd34df00d /39 18.12.2012 22:39 talkonaut-iphone_5.91_67b1c873

всё равно каждое чтение требует перехода в режим ядра. попробуй целиком в массивы предзагрузить свои файлы, а после того как загрузил — засекай всемя

#tfeoii/40

41. 0xd34df00d → hirthwork /40 18.12.2012 23:15 Azoth_primary

Вообще охуеть. Не может туда столько тратиться, будет как с атомиками.

О, кстати, это все — отличный повод изучить возможности Intel vTune для профилирования говна в многопоточных приложениях, чо ж я сразу-то не?

#tfeoii/41

42. hirthwork → 0xd34df00d /41 19.12.2012 06:18

ещё как может. чистый переход в режим ядра на моём ноуте требует порядка одной микросекунды. далее вопрос уже в том как часто ты переходишь и сколько у тебя аллокаций памяти в процессе работы.

в общем, ты можешь сколько угодно исходить говном из-за того, что у тебя эффективность параллельного алгоритма оказалась 75%, но я продолжу тебя считать мудаком, ибо на лабе на четвёртом курсе я от msvs теми же самыми прагмами получал эффективность в 91% на сортировке слияниями.

#tfeoii/42

43. 238328 → 0xd34df00d /4 19.12.2012 08:27

2014 год на дворе, а в реальном мире не реализовали потребностей и в половине функциональных возможностей Хаскеля!

#tfeoii/43

44. 238328 → 0xd34df00d /9 19.12.2012 08:28

потому что кресты

#tfeoii/44