2014-04-02 “Is Parallel Programming Hard, And, If So, What Can You Do About It?”
by Vasil KolevПреди няколко седмици излезе първото издание на “Is Parallel Programming Hard, And, If So, What Can You Do About It?” – книга под creative commons на Paul McKinley (по принцип kernel developer). Полезна е и информацията в нея е доста прясна и точна (а и като гледам, голяма част от нещата там не са се променяли от доста време, и има неща като RCU, memory бариери и т.н.) и я препоръчвам на всички.
Аз разпечатах десетина копия, и в момента има по едно в initLab, VarnaLab, BurgasLab и hackafe, като се планира втори print run, ако има хора, които имат желание да си вземат. Цената ще е около 30лв на копие, ако имате желание, пишете.
(или може да си я четете online или да си я разпечатате сами, не е сложно:) )
Tags: книги
April 3rd, 2014 at 17:37
Когато единственият инструмент, с който разполагаш, е чук, то всички проблеми започват да ти приличат на пирони. По всичко изглежда, че това важи с пълна сила за разработчиците на Linux ядрото.
“OpenMP: This set of compiler directives can be used to parallelize loops. It is thus quite specific to this task, and this specificity often limits its performance.”
Това щеше да е вярно преди 6 (шест) години, но тогава версия 3.0 на OpenMP спецификацията добави явни задачи (explicit tasks), с които стана възможно да се реализират огромен клас паралелни алгоритми, включително рекурсивни такива. Често производителността на добре написани OpenMP програми е същата или много близка до тази на програми, използващи явно POSIX threads, а размерът на изходния код е в пъти (или дори на порядъци) по-малък. Актуалната спецификация версия 4.0, освен че добавя зависимости между задачите и възможност за ранно прекратяване на паралелните конструкции, също така позволява части от кода да се компилират за и изпълняват върху GPGPU и копроцесори като Intel Xeon Phi.
“MPI: … In theory, it is general purpose, but it is mainly used for scientific and technical computing. Its productivity is believed by many to be even lower than that of C/C++ “locking plus threads” environments.”
Последното изказване е в стил “една леля в магазина каза” и въобще не отговаря на реалността. Вярно е, че кривата на научаване при MPI е значително по-стръмна в началото, главно поради трудностите да се осмисли Single Program Multiple Data модела. След това обаче MPI е значително по-продуктивен от моделите със споделена памет, главно поради липсата на несинхронизиран достъп до споделени данни (data races) и широката му преносимост.
Не бих препоръчал на човек, който тепърва прохожда в паралелното програмиране и се нуждае от широк поглед върху областта, да започва точно с тази книга.
April 3rd, 2014 at 22:40
@физик, ами препоръчай книга за MPI :) Иначе по това, което гледам поне при мен, mpi-то не е подходящо за типа задачи, които са ми интересни, т.е. системно програмиране и т.н. (зарових се, нещо не успявам да намеря например web сървър, написан с mpi).
April 4th, 2014 at 13:12
@физик: ” Често производителността на добре написани OpenMP програми е същата или много близка до тази на програми, използващи явно POSIX threads, а размерът на изходния код е в пъти (или дори на порядъци) по-малък.” … една леля в магазина каза :P … дай peer reviewed paper, в който ги пише тия работи и е за web scale project.
April 4th, 2014 at 16:07
Естествено, че няма да намерите web сървър, който да използва MPI или OpenMP. По същата причина, поради която няма да намерите операционна система, която да използва MPI като механизъм за IPC в ядрото си, или градско автомобил с ракетен двигател. Има класове проблеми, при които жертването на преносимостта в името на производителността е напълно допустимо. Има класове проблеми, при които допълнителните външни зависимости като MPI и/или OpenMP runtime са нежелателни. И не на последно място, има класове проблеми, които лежат отвъд областта, покривана от даден програмен модел.