( uid_2716 | 2008. 11. 20., cs – 05:14 )

Alapvetően igazad van. Hadd legyek közhelyes: programozó ideje kontra gép ideje.

A széles fejlesztőtömegek számára az fontos, hogy legyen egy (több) megbízható, hatékony és biztonságos fejlesztést támogató, automatikusan párhuzamosodó / eloszló eszköz, még azon az áron is, hogy az egyes csomópontok (mag vagy gép) erejének mondjuk kétharmada elmegy a futtató környezetre.

Szükség lesz azonban (bár biztosan lényegesen kisebb súllyal) olyan alkalmazásokra is, ahol a fenti arány (más szóval (nem-pejoratívan értett!) "megalkuvás") nem fogadható el. Bár egy időben én is lelkesen kontárkodtam a Haskell-lel (még a monádokat is értegettem, úgy-ahogy, bár úgy látom, ezen mindenképpen érdemes lesz még átrágnom magam), azért a hobbim a C-hegesztés, ezért volt az előző példám ilyen irányban elfogult. Ismétlem, természetesen igazad van, hogy általánosságában távolodni akarunk az explicit párhuzamosság-kódolástól, illetve ha muszáj azon belül maradnunk, akkor inkább az üzenetküldözgetés felé tendálunk.

A proggit-on egyébként mindennapos a flamewar a témában. Lásd például (és ez egy gyenge példa): Multicore parallel death match! Parallel Haskell, `par`, and C.

Gyorsan kerestem is a témák között egy kicsit, hátha találok Számodra néhány linket, amely (magától értetődően) sokkal frappánsabban és részletesebben leírja, amit fent elbanalizáltam:

Making the transition from sequential to implicit parallel programming: Part 6 -- So, why aren't we using functional languages yet?

Making the transition from sequential to implicit parallel programming: Part 8 -- Turning parallel Haskell (pH) into a production language

Embedded software stuck at C -- No parallel languages for multi-core on horizon

Interviewing the Parallel Programming Idols

(Ezért is írok hajnali ötkor...)

Tegyük hozzá, az adok-kapok nemcsak a mezei programozók fórumain folyik az imperatív ill. funkcionális (deklaratív) hívők között, hanem a nagyok csatornáin is. Nyilván sokkal kifinomultabb eszközökkel, de azért vegyük észre, hogy amikor arról írnak részletes cikket, hogy hogyan készíthetünk lock-mentes adatszerkezeteket C-ben, amelynek még specifikált memóriamodellje sincs, és hogy minden processzor-architektúra ill. fordító máshogy rendezi át az utasításaidat és másféle barrier-eket igényel(ne), meg hogy milyen megfontolásokkal érdemes spinlock-ot használni súlyos mutex helyett, akkor nem biztos, hogy jó irányba sugallmazzák a széles néptömegeket. (Persze aki ilyen cikket ír, az általában hozzáteszi a végén, hogy "tudod mit, inkább felejtsd ezt el, és zárolj inkább".) Példák (szerintem érdemes mindegyikbe legalább belekukkantani):

The "Double-Checked Locking is Broken" Declaration

Writing Lock-Free Code: A Corrected Queue -- Think in transactions, know who owns what, and use ordered atomic variables

Multicores and Publication Safety

Who ordered memory fences on an x86?

Who ordered sequential consistency?

The JSR-133 Cookbook for Compiler Writers