birdwatcher: (Default)
birdwatcher ([personal profile] birdwatcher) wrote2007-04-11 07:49 am

Саттер

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

Саттер сказал следующее:
  • раньше, если программа работала медленно, можно было год ничего не делать, и она сама собой начинала работать быстро: появлялся более быстрый процессор.
  • больше более быстрых процессоров не будет.
  • потому что прогресс процессорных технологий состоит в размещении большего количества транзисторов на квадратный сантиметр; но никто не знает, что с ними делать:
  • возрастающее количество транзисторов перестало влиять на быстродействие, потому что кэш еще большего размера уже ничего не дает, и более сложная оптимизация в процессоре тоже уже ничего не дает.
  • и тактовую частоту увеличить тоже нельзя, потому что электрические сигналы, распространяясь со скоростью света, не будут успевать долетать с одного конца чипа до другого (7 GHz).
  • поэтому из этого гигантского количества транзисторов будут собирать все больше и больше процессоров на одном чипе; например, можно прямо сейчас собрать сто штук Пентиумов 1 на чип.
  • так что, если взять медленную программу и год ничего не делать, то через год ее можно будет запустить на вдвое большем количестве процессоров; но это будет так же медленно, поскольку она неправильно написана и не будет их загружать.
  • И вот Саттер [в Майкрософте] придумывает, как встраивать в языки программирования такую поддержку параллелизма, чтобы эффективно писать на неогранниченное количество процессоров; по сравнению с ней обычные threads и locks будут напоминать программирование на ассемблере.
  • потому что машина с восемью процессорами (два слота для четырехкорных процессоров сегодня) - это совершенно другая машина, у которой случайно совпадает набор команд, но программировать ее надо совершенно по-другому.

    Вот:
  • [identity profile] yan.livejournal.com 2007-04-11 01:08 pm (UTC)(link)
    enjoy the что?

    no way

    [identity profile] eeik.livejournal.com 2007-04-11 01:26 pm (UTC)(link)
    явно же написано the dork :)

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

    Re: no way

    [identity profile] birdwatcher.livejournal.com 2007-04-11 01:29 pm (UTC)(link)
    Он говорит, вся сила будет в транзакционной памяти. Попробовали гору переменных поменять - потом все разом утвердили или откатили. Внутри незаметно хранятся версии. Как в базе данных.
    (deleted comment)

    Re: no way

    [identity profile] birdwatcher.livejournal.com 2007-04-11 01:51 pm (UTC)(link)
    Можно будет использовать опыт, накопленный в программировании баз данных, где проблема параллелизма исчерпывающе решена.

    Re: no way

    [identity profile] eeik.livejournal.com 2007-04-11 02:04 pm (UTC)(link)
    это я и сейчас могу сделать - скопировал во временную переменную по локом, поменял временную переменную, скопировал под локом обратно. никаких дедлоков, все локи строго локальны. вот тебе и транзакционная память (ну версий нет, и фиг сними). только вот хитрым ручным расставление локов мы можем добиться лучшей производительности.

    Re: no way

    [identity profile] birdwatcher.livejournal.com 2007-04-11 02:08 pm (UTC)(link)
    Правильно, просто он это хочет обязательно встроить в язык, чтобы не двигать руками локи. Он все время повторял, что можно и на чистом C писать полностью объектно, если самому сделать vtables; так же и тут.

    Re: no way

    [identity profile] eeik.livejournal.com 2007-04-11 02:26 pm (UTC)(link)
    ну про С понятно - на каком хаскелле ни пиши, процессор все равно что-то глубоко свое выполняет.

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

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

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

    Re: no way

    [identity profile] birdwatcher.livejournal.com 2007-04-11 02:35 pm (UTC)(link)
    Это социальная проблема, а не инженерная -- вопрос не в том, как организовать threads на четырех процессорах наиболее эффективно, а в том, как стимулировать абсолютно всех абсолютно всё писать параллельно, потому что к 2012 году процессоров всё равно обязательно будет сто на каждой машине.

    [identity profile] green-fr.livejournal.com 2007-04-12 07:37 am (UTC)(link)
    synchronize в java это практически всего лишь запрет на параллельный доступ к какому-то элементу (переменной или коду) из двух и более потоков. Не совсем то.

    Re: no way

    [identity profile] birdwatcher.livejournal.com 2007-04-11 02:20 pm (UTC)(link)
    P.S. во: http://en.wikipedia.org/wiki/Software_transactional_memory

    Re: no way

    [identity profile] zverx.livejournal.com 2007-04-13 10:20 am (UTC)(link)
    Причем немного повышает прозводительнось концепция: один писатель-много читателей
    Раскуривать у Рихтера "Создание эффективных WIN32-приложений"

    PS: возможно и так знаете.
    ak_47: (Default)

    Завидую!

    [personal profile] ak_47 2007-04-11 06:11 pm (UTC)(link)
    Он ЛенинаСаттера видел!

    Re: Завидую!

    [identity profile] birdwatcher.livejournal.com 2007-04-11 06:12 pm (UTC)(link)
    Тот самый случай!

    [identity profile] cema.livejournal.com 2007-04-11 07:53 pm (UTC)(link)
    Вообще-то этими вопросами много людей занимаются много лет. Может быть, наконец-то пойдёт в дело.

    [identity profile] averros.livejournal.com 2007-04-11 09:29 pm (UTC)(link)
    My current target development chip has 16 64-bit CPUs on it, and gets to 32 GIPS.

    http://cavium.com/OCTEON-Plus_CN58XX.html

    As always, the reality is somewhat different from what software guys like Herb Sutter think. The problem is not what to do with a bunch of symmetrical parallel CPUs, but, rather, in the insufficient memory bandwidth. Which can only be fixed by learning to program efficiently on non-uniform memory access architectures.

    [identity profile] birdwatcher.livejournal.com 2007-04-11 09:36 pm (UTC)(link)
    Package: 1521 pins FCBGA
    У него натурально 1521 ножка?

    [identity profile] averros.livejournal.com 2007-04-11 10:05 pm (UTC)(link)
    У него нету ножек вообще:) У Ball Grid Array (BGA) снизу много-много шариков из припоя - они припаиваются прямо к площадкам на плате. Кстати, 1521 - это всего-лишь 39*39.

    http://en.wikipedia.org/wiki/Ball_grid_array

    [identity profile] birdwatcher.livejournal.com 2007-04-11 10:23 pm (UTC)(link)
    Тоже удобно
    nine_k: A stream of colors expanding from brain (Default)

    [personal profile] nine_k 2007-04-15 06:56 pm (UTC)(link)
    It seems to me that NUMA architectures are not exactly new. Probably, we don't have enough good books of 'Programming Supercomputers' kind, because today's desktop are 15-years-ago's high end machines.

    [identity profile] averros.livejournal.com 2007-04-11 10:24 pm (UTC)(link)
    ...oh, and Sutter completely forgot the main reason why parallel programming sucks: you generally cannot do regression testing on a parallel program, because timing conditions (such as preemption) are not controllable within the test harnesses. Though, judging by the quality of the MS code, they never do it anyway.