The Concurrency Revolution

Очень интересно... жаль только я английского не знаю, а то бы точно прочитал эту новость.

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

отсюда следствия: нечего прогреммить неподъёмные программы, рассчитывая на более быстрый процессор завтра -- раз, и надо учиться писать многопотоковые программы -- два

а завтра AMD или Intel выпустит очередную свистульку и нужно будет писать справа налево

Да надо перресадить всех этих е####### программистов на 286, и глядишь появятся легковесные программы...

>и глядишь появятся легковесные программы...

Под DOS что ли?

почемуж? пущай лялих портируют на двушку и буит фсем щастье

>а надо перресадить всех этих е####### программистов на 286, и глядишь появятся легковесные программы...

надо всех заставить ляпать на жабе или нете и будет вам щастье. Нехуй на сях и плюсах извращаться - от них проги тормозные получаются.

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

Помнится я такое читал лет эдак 13-14 назад про 486 и частоту, что-то около 66 МГц.

да, были такие статьи о пороге в 100MHz (на моей памяти). Но тогда все же прогресс был постоянным, и все (наверное) в уме держали что спутниковые рессиверы работают на гораздо больших частотах. сейчас я тоже вижу время от времени мелькание на лентах о том что очередной рекорд по частоте переключений транзистора поставлен (лень искать, но думаю около 100GHz есть). да только одиночный транзистор погоды не делает, потому что у него тепловыделение может быть очень немаленьким и это никого не испугает, а когда таких транзисторов 10**9 - совсем другая ситуация.

Помнится в ЛЭТИ (Питер) мой препод по микросхемотехнике убедительно доказывал, что максимальная частота проца - 80 Мгц. Кстати очень убедительно - с формулами, расчетами времени открытия/закрытия затворов, характеристиках материалов (Si - германий все-така дорого...). На мой вопрос про "Альфу" мол они уже к 200 подбираются - ответил, что мол все это происки капиталистов... в шутку, конечно... Я это к тому, что человек существо очень изворотливое. Ну остановим мы гонку мегагерцных вооружений - начнем улучшать алгоритмы, когда этот ресурс будет исчерпан она снова начнется - не спрашивайте меня как - мой препод тоже не знал...

Да, хорошая статья. И автор, очевидно, профи.

Единственный тренд который он не упомянул, это то, что затраты на многопоточность станут гораздо ниже. Мы сможем спокойно "употреблять" параллелизм меньшими гранулами. И это значит, что то что сегодня параллелить невыгодно, завтра будет выгодно параллелить. Т.е. класс задач которые можно эффективно параллелить на существующем железе будет расширятся.

По поводу

> We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon.

было бы интересно почитать. Первое что приходит в голову по этому поводу это что подходы ныне находящиеся в "загоне": функциональный (и в первую очередь чистый функциональный) и логический, могут послезавтра стать мейнстримом. Из-за того что замечательно автоматически параллелятся.

Хорошая поддержка мелкозернистого параллелизма железом, может дать этим подходам вторую жизнь, т.е. перевесить их минусы.

логический подход это что? пролог?

http://directory.google.com/Top/Computers/Programming/Languages/Logic-based/

не понимаю я как можно _автоматически_ распаралелить задачи, которые принципиально не распаралеливаются. для опровержения можешь пользоваться lisp, prolog, c++, c или asm на свое усмотрение

Даже в нераспараллелтваемых алгоритмах есть куча кода, который можно распараллелить.

Программист должен стараться использовать алгоритмы с минимальным зацеплением по данным, а машина дорлжна параллелить выполнение программы автоматом и ждать только разрешения конфликтов по данным.

Проще говоря, машина с управлением потоком данных автоматом параллелит любой алгоритм на любом языке.

> не понимаю я как можно _автоматически_ распаралелить задачи, которые принципиально не распаралеливаются. для опровержения можешь пользоваться lisp, prolog, c++, c или asm на свое усмотрение

Приведи конкретную задачу. Я попробую. На самом деле я уверен, что параллелятся >99% задач. Просто очень малый процент из них хорошо подходят для крупнозернистого параллелизма. В качестве иллюстрации укажу что современные процы практически любой код параллелят в 1.5-3 раза, но они это делают в очень мелких гранулах.

Причем они это делают даже на убогом наборе инструкций x86'ых.

давно портировали, придурок.

>почемуж? пущай лялих портируют на двушку и буит фсем щастье

http://elks.sourceforge.net/

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