Саттер

[birdwatcher]

Прослушал доклад Херба Саттера про параллельное программирование. Кого интересует параллельное программирование? А потому, что я по его книге (и по другой, Скотта Мейерса) много лет назад готовился к интервью.

Саттер сказал следующее:

раньше, если программа работала медленно, можно было год ничего не делать, и она сама собой начинала работать быстро: появлялся более быстрый процессор.

больше более быстрых процессоров не будет.

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

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

и тактовую частоту увеличить тоже нельзя, потому что электрические сигналы, распространяясь со скоростью света, не будут успевать долетать с одного конца чипа до другого (7 GHz).

поэтому из этого гигантского количества транзисторов будут собирать все больше и больше процессоров на одном чипе; например, можно прямо сейчас собрать сто штук Пентиумов 1 на чип.

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

И вот Саттер [в Майкрософте] придумывает, как встраивать в языки программирования такую поддержку параллелизма, чтобы эффективно писать на неогранниченное количество процессоров; по сравнению с ней обычные threads и locks будут напоминать программирование на ассемблере.

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

Вот:

Comments

Re: no way

[eeik.livejournal.com]

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

Re: no way

[birdwatcher.livejournal.com]

Правильно, просто он это хочет обязательно встроить в язык, чтобы не двигать руками локи. Он все время повторял, что можно и на чистом C писать полностью объектно, если самому сделать vtables; так же и тут.

Re: no way

[eeik.livejournal.com]

ну про С понятно - на каком хаскелле ни пиши, процессор все равно что-то глубоко свое выполняет.

но я чувствую какую-то глубинную разницу между vtables и тредами/локами.
и если автоматизация vtables это просто помощь программмсту, чтобы пальцы не стирались; то автоматизация тредов/локов - вставление палок ему в колеса, imho.

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

кстати, плохо знаю java - там же есть synchronize - это разве не оно?

Re: no way

[birdwatcher.livejournal.com]

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

[green-fr.livejournal.com]

synchronize в java это практически всего лишь запрет на параллельный доступ к какому-то элементу (переменной или коду) из двух и более потоков. Не совсем то.

Re: no way

[birdwatcher.livejournal.com]

P.S. во: http://en.wikipedia.org/wiki/Software_transactional_memory

Re: no way

[zverx.livejournal.com]

Причем немного повышает прозводительнось концепция: один писатель-много читателей
Раскуривать у Рихтера "Создание эффективных WIN32-приложений"

PS: возможно и так знаете.