Неявний паралелізм ^ може зняти великий тягар від багатьох програмістів, розмістивши його на комп’ютері. Отож ... чому він зараз не є більш поширеним?
Відповіді:
Тому що за кількома винятками (Haskell) немає можливості, щоб компілятор міг розмотати цикл. Проблема полягає в тому, що кожна ітерація через цикл може змінювати глобальний стан. Таким чином, якщо це зробити в іншому порядку, це може призвести до зламання речей. У haskell ви можете розраховувати, що функція є чистою, тобто, вона не читає і не змінює глобальний стан, тому вони можуть виконуватися в будь-якому порядку.
Справжня проблема полягає в тому, що, за кількома винятками, як добре робити сумісність, це все ще залишається відкритою проблемою. Громади Ерланг і Хаскелл, здається, ведуть себе досить добре, але це ще довгий шлях, перш ніж ми дійсно зрозуміємо, як запрограмувати N-основну систему для великих N.
Більшість мов програмування, якими ми зараз користуємось, прийшли в той час, коли однопотокове програмування та взаємодія одного користувача є найбільш використовуваним для багатьох додатків (наприклад: автономні програми для настільних ПК). З підвищенням веб-додатків, хмарних обчислень та багатокористувацьких додатків тепер нам потрібно більше багатопотокових програм.
Старі мови програмування намагаються підтримувати багатопотокові функції з самої мови повільно (як java додав java.util.concurrent).
Нові мови, які з’являться в майбутньому, матимуть кращу підтримку вбудованої нитки та одночасності.
Крім пунктів, згаданих в інших відповідях (важко довести, що операції незалежні, а програмісти думають серійно), є ще третій фактор, який слід врахувати: вартість паралелізації.
Правда полягає в тому, що паралелізм потоку пов'язаний з цим дуже суттєвими витратами:
Створення ниток дуже дороге: Для ядра запуск потоку - це приблизно те саме, що і запуск процесу. Я не впевнений у точних витратах, але я вважаю, що це близько десяти мікросекунд.
Спілкування потоків через мутекси є дорогим: зазвичай для цього потрібен системний виклик з кожної сторони, можливо, покладіть нитку на сон і знову прокинетесь, що спричиняє затримку, а також холодні кеші та промиті TLB. В середньому, прийняття та вивільнення мутексу коштує близько однієї мікросекунди.
Все йде нормально. Чому це проблема неявного паралелізму? Тому що неявний паралелізм найпростіше довести на малих масштабах. Одне довести, що дві ітерації простого циклу не залежать одна від одної, це зовсім інша справа - довести, що друк чогось до stdoutта відправка запиту до бази даних не залежать один від одного і можуть виконуватися паралельно ( процес з базою даних може бути з іншого боку труби!).
Тобто неявний паралелізм, який може довести комп'ютерна програма, ймовірно, невикористовується, оскільки витрати на паралелізацію перевищують перевагу паралельної обробки. З іншого боку, паралелізм великого масштабу, який може дійсно прискорити додаток, не підходить для компілятора. Подумайте, скільки роботи може виконати процесор протягом мікросекунди. Тепер, якщо паралелізація повинна бути швидшою за послідовну програму, паралельна програма повинна мати можливість утримувати всі процесори зайняті протягом декількох мікросекунд між двома викликами mutex. Для цього потрібен дійсно грубозернистий паралелізм, який майже неможливо довести автоматично.
Нарешті, жодне правило без винятку: експлуатація неявного паралелізму працює там, де жодні потоки не беруть участь, що є випадком векторизації коду (з використанням наборів інструкцій SIMD, таких як AVX, Altivec тощо). Це дійсно найкраще підходить для малого масштабу паралелізму, який порівняно легко довести.
Програмісти мислять серійно, і поточні мови побудовані для підтримки цієї моделі. За винятком мов окантовки, таких як Haskell Erlang і т. Д., Мови (я утримуюсь від використання прикметника "сучасний") - це по суті збірка високого рівня, де ми все ще розповідаємо комп'ютеру, що робити, коли це робити і як це робити. Поки ми не створимо ехосистему, де ми скажемо комп'ютеру, який результат ми хочемо отримати, ми не маємо розумових можливостей, як програмістів, повною мірою використовувати багатопотокові можливості.
тобто це не природно ......
don't have the patience, це більш точна оцінка, ніж don't have the mental capacityвсе-таки. За свою кар’єру я бачив набагато більше лінивих програмістів, ніж я бачив дурних . Мені пощастило, але мене навчали функціональному програмуванню та дрібнозернистому паралельному програмуванню поряд із процедурними та ОО на моєму першому курсі в університеті. Я підозрюю, що багатьом програмістам не пощастило, і в результаті їх думки пройшли просто.
Операції повинні бути кислотними, тому програміст в основному схильний думати про одну нитку.
Мови та платформи повинні захищати програміста від одночасності настільки, наскільки вони можуть собі дозволити
І перевірити одночасність не так просто, як саму функціональність, тому програмісти, як правило, залишають, крім цих питань, і, навіть не замислюючись про вчинення одночасності, що таке помилка