The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

12.09.2009 01:04  Apple выпустила диспетчер потоков Mac OS X под открытой лицензией

Одним из основных нововведений очередного релиза операционной системы Mac OS X Snow Leopard от компании Apple стала технология центральной диспетчеризации (Grand Central Dispatch), исходные коды которой выпущены под открытой лицензией Apache License v2. Библиотека не зависит от фреймворка Cocoa, написана на языке Си и должна значительно облегчить разработку программ, использующих современную многоядерную процессорную архитектуру.

Технология Grand Central Dispatch — это ответ Apple на проблему параллельного программирования. С развитием современных процессоров, содержащих на одном кристалле два и более ядра, обычный домашний компьютер технологически стал похож на многопроцессорный сервер. И чтобы использовать его вычислительный ресурс на все 100% требуется каким-то образом разделить монолитную программу на ряд параллельно исполняемых независимых «нитей» (threads). Кажущаяся простота реализации этой идеи на практике даже у самых опытных программистов сопровождается такими неприятными побочными эффектами, как взаимные блокировки (deadlocks) и состояние гонки (race conditions). Связано это с тем, что различные «нити» требуют доступа к одним и тем же ресурсам, причем, зачастую одновременно.

С появлением GCD задача управления потоками целиком перекладывается на эту технологию. Предпосылка к этому очень проста: программист на этапе написания кода просто не может знать, какая самая оптимальная конфигурация многопоточности будет в момент исполнения программы. Иерархический дизайн GCD позволяет рабочим потокам обмениваться сообщениями не только с родительским процессом, но и между собой. Из соображений совместимости с предыдущими версиями Mac OS X диспетчер вынесен в отдельный модуль ядра.

Тем не менее, необходимо заметить, что Grand Central Dispatch сам по себе никак не решает проблему параллельных вычислений, оставляя выбор за разработчиком, какие участки кода и когда могут выполняться одновременно.

  1. Главная ссылка к новости (http://www.osnews.com/story/22...)
Автор новости: blkdog
Тип: К сведению
Ключевые слова: lib, proccess, macosx, smp, threads, cpu
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Vital (??), 02:01, 12/09/2009 [ответить] [показать ветку] [···]    [к модератору]
  • –2 +/
    и в чем отличие от posix threads?
     
  • 1.5, ffsdmad (ok), 07:56, 12/09/2009 [ответить] [показать ветку] [···]    [к модератору]
  • –1 +/
    а у них не было чтоли fork?
    iCreateProcess ?
     
  • 1.7, Юниксоид (??), 10:38, 12/09/2009 [ответить] [показать ветку] [···]    [к модератору]
  • +1 +/
    Unix предполагает использование множества процессов для достижения цели, ибо создание процесса в Unix очень дёшево. Поэтому мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.
     
     
  • 2.8, аноним (?), 11:15, 12/09/2009 [^] [ответить]    [к модератору]
  • +/
    >Поэтому муд... программеры в случаях когда возможны описанные
    >side effects юзают процессы, а не потоки.

    потом всё это весело портировать

     
  • 2.10, const86 (ok), 11:34, 12/09/2009 [^] [ответить]     [к модератору]
  • +2 +/
    К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться ... весь текст скрыт [показать]
     
     
  • 3.11, Аноним (-), 12:04, 12/09/2009 [^] [ответить]    [к модератору]  
  • –1 +/
    > глядя на потерянную производительность свысока.

    у Apple настолько медленное межпроцессное взаимодействие ?

     
     
  • 4.12, letsmac (?), 13:44, 12/09/2009 [^] [ответить]    [к модератору]  
  • –1 +/
    Дело не в Apple - в мак оси fork работает. Просто используют поэффективнее.
     
  • 2.13, xxx (??), 13:57, 12/09/2009 [^] [ответить]     [к модератору]  
  • +1 +/
    Я далеко не гуру в вопросах многозадачности и т п Поэтому возможно мудрый прог... весь текст скрыт [показать]
     
     
  • 3.14, Вова (?), 16:14, 12/09/2009 [^] [ответить]     [к модератору]  
  • +1 +/
    никакая из концепций юникс не отменяет использования многопоточности По теме ... весь текст скрыт [показать]
     
  • 3.24, pro100master (ok), 22:44, 12/09/2009 [^] [ответить]     [к модератору]  
  • +/
    в концепции TBB процессы не нужны И грош цена им Вообще имхо пора бы уже пер... весь текст скрыт [показать]
     
  • 3.29, Юниксоид (??), 08:58, 13/09/2009 [^] [ответить]     [к модератору]  
  • –2 +/
    I m the first to admit that I ll probably never be able to create a correct thr... весь текст скрыт [показать]
     
     
  • 4.30, Вова (?), 10:20, 13/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь произ... весь текст скрыт [показать]
     
     
  • 5.33, Юниксоид (??), 19:51, 13/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Некультурный вы наш Если цена fork имеет значение, то ваш сервер либо гифы 1х1... весь текст скрыт [показать]
     
     
  • 6.35, Вова (?), 22:57, 13/09/2009 [^] [ответить]     [к модератору]  
  • +/
    говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка ... весь текст скрыт [показать]
     
     
  • 7.36, vitek (??), 09:06, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    значит у моего сервера достаточный пул процессов и их балансировка и хватит у... весь текст скрыт [показать]
     
  • 7.37, vitek (??), 09:10, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    и ещё забавные ограничения можно подумать, что реализовать нормальный серв... весь текст скрыт [показать]
     
     
  • 8.40, Вова (?), 11:21, 14/09/2009 [^] [ответить]     [к модератору]  
  • –1 +/
    В вашем сервере, который существует только в вашем воображении, ассемблерные в... весь текст скрыт [показать]
     
     
  • 9.43, vitek (??), 19:25, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    верно но проверенных временем и разработанных лучшими специалистами по всему ми... весь текст скрыт [показать]
     
  • 7.48, User294 (ok), 22:12, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Именно форк на каждое соединение клиента - на мое имхо по итогам смотрения как ... весь текст скрыт [показать]
     
  • 6.47, User294 (ok), 21:54, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжин... весь текст скрыт [показать]
     
  • 5.49, User294 (ok), 22:27, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    А потом прикрути машины состояний и пойми что и процессы и треды запускаемые зан... весь текст скрыт [показать]
     
     
  • 6.59, Вова (?), 14:11, 15/09/2009 [^] [ответить]     [к модератору]  
  • +/
    это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной п... весь текст скрыт [показать]
     
  • 4.41, Еще один аноним (?), 12:33, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальн... весь текст скрыт [показать]
     
  • 1.9, anonymous (??), 11:18, 12/09/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • –3 +/
    "дизайн GCD позволяет рабочим потокам обмениваться сообщениями не только с родительским процессом, но и между собой"

    Хо-хо, они придумали erlang!

     
  • 1.18, pavlinux (ok), 19:32, 12/09/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    > Связано это с тем, что различные «нити» требуют
    > доступа к одним и тем же ресурсам, причем,
    > зачастую одновременно.

    А зачем тогда распараллеливать?!

     
     
  • 2.19, аноним (?), 19:42, 12/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >А зачем тогда распараллеливать?!

    как иначе ускорять обработку? время безумного наращивания частот и усложнения инструкций прошло

     
     
  • 3.20, pavlinux (ok), 20:12, 12/09/2009 [^] [ответить]     [к модератору]  
  • –1 +/
    Какая разница как добираться до ресурса, через очередь или через очередь очере... весь текст скрыт [показать]
     
     
  • 4.21, агоним (?), 20:38, 12/09/2009 [^] [ответить]    [к модератору]  
  • +/
    разве irl не будет иначе?
    A - B - ... - A(o) - ... - A(R) - ... - N - ... - B(o) - ... - A(z) - B(R) - ...
    вплоть до N-1 потоков выполняются без ожидания, полностью утилизируя мощностя
     
     
  • 5.28, pavlinux (ok), 04:11, 13/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Выполняются да, без базара Но разговор-то был про очерёдность доступа к блокир... весь текст скрыт [показать]
     
  • 2.42, Еще один аноним (?), 12:44, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Не, просто не все же время работы нитей - это долбежка к одному и тому же ресурс... весь текст скрыт [показать]
     
     
  • 3.46, letsmac (?), 21:04, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Естесвенно не всё Но данные например надо кому-нибудь таки отдать, или забрать ... весь текст скрыт [показать]
     
     
  • 4.50, User294 (ok), 22:30, 14/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД".

    МиФи хороший институт, но одно все-таки не понятно: так где же отечественные файловые системы? oO

     
     
  • 5.51, letsmac (?), 22:38, 14/09/2009 [^] [ответить]     [к модератору]  
  • +/
    В отечественных компах Ну мы же знаем, что за всем стоит user294 который даже ... весь текст скрыт [показать]
     
  • 1.22, Erley (ok), 21:20, 12/09/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +2 +/
    Похоже что скоро пингвины будут вынуждены портировать идеи заложенные в этом диспетчере.
    Многие кто тут высказывается о бесполезности такого диспетчера не совсем понимают как на практике пишутся и работают многопоточные программы. Почитайте про lock-free контейнеры, tls и попробуйте написать простенький тест чтобы убедиться, что создание процесса занимает много времени.
    Дальше всех в "утончении" execution path ушли микрософтовцы - у них есть сущность ещё тоньше и легче, чем поток - fiber. Правда виндовый планировщик криво ими управляет, там много вручную делать надо. Ну это как всегда у микрософта, что поделаешь... Не знаю, может в AIX и последних солярах что получше есть, не смотрел.
    Увеличение производительности давно связывают с более эффективным использованием нескольких процессоров. Эппл уже сейчас закладывает для этого хорошую базу (OpenCL), а не примитивные эксперименты с 1:n, n:m и прочими потоковыми библиотеками.
    Многое изменится в этой области в ближайшее время. И кстати не только эппловцы делают инновации в ней, что есть очень хорошо для всех нас.
     
  • 1.26, kost BebiX (?), 01:45, 13/09/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Ага. Типа "я сожру 10 минут на просчитывание нитей, зато сэкономлю тебе 10 секунд", что, впрочем, для работающих по 24 часа в сутки программ не так уж и плохо)
     
  • 1.27, seyko (ok), 03:40, 13/09/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Народ не прочитал новость... Смысл в получении параллельности для обычной программы. Для этого программа должна быть разбита компилятором на блоки. Поддержка всего этого включена в LLVM и clang от того же Apple. Эти блоки могут выполняться параллельно. При сборке программы компилятор делает вызовы на постановку блоков в очередь на асинхронное выполнение, из коей очереди этот самый диспетчер их и выбирает. Перед этим создав какое-то число threads для выполнения этих блоков.

    PS: вроде Интел тоже работает над внедрением в компиляторы автоматической разбивки программы на куски, которые могут выполняться параллеьно...

     
     
  • 2.31, tesseract (ok), 10:23, 13/09/2009 [^] [ответить]     [к модератору]  
  • +/
    Ну суперскалярность в процах и них есть и без хитрых компиляторов Я так понимаю... весь текст скрыт [показать]
     
     
  • 3.32, frey (ok), 16:00, 13/09/2009 [^] [ответить]    [к модератору]  
  • +/
    При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем написано в посте на который вы отвечаете.
     
     
  • 4.34, pro100master (ok), 20:52, 13/09/2009 [^] [ответить]     [к модератору]  
  • +/
    при том Вся современная компьютерная тормозня из-за непонятного нежелания инжен... весь текст скрыт [показать]
     
     
  • 5.44, pppp (?), 20:08, 14/09/2009 [^] [ответить]    [к модератору]  
  • +/
    Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко маячит дедушка Эйнштейн.
    300 * 10^6 / 133 * 10^6 ~ 2.5 метра. Именно на такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц; причём, в вакууме. Для металлических проводников эту цифрц надо делить на 2.
    Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности "столкновения" сигналов -- получаем те же самые 133-200МГц. В последовательном интерфейсе (при условии расположения памяти не далее 10см от контроллера) можно достичь частот выше 1ГГц.
     
     
  • 6.52, letsmac (?), 22:46, 14/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц;
    >причём, в вакууме. Для металлических проводников эту цифрц надо делить на
    >2.
    >Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности
    >"столкновения" сигналов -- получаем те же самые 133-200МГц.

    "Барьер" Это строб в виду имеется? Ну даже без Энштейна повторителей никто не отменял. А ещё наводки немерянным тепловым шумом + квадратность сигнала и время на не очень полезный для здоровья транзисторов шаг накачки поля. Не от хорошей жизни это - факт. Повышение параллельности - Cell внезапно помер. А OpenCL пока рождается. Не факт что выживет.

     
  • 6.53, pro100master (ok), 22:54, 14/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко
    >маячит дедушка Эйнштейн.
    >300 * 10^6 / 133 * 10^6 ~ 2.5 метра. Именно на
    >такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц;
    >причём, в вакууме. Для металлических проводников эту цифрц надо делить на
    >2.
    >Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности
    >"столкновения" сигналов -- получаем те же самые 133-200МГц. В последовательном интерфейсе
    >(при условии расположения памяти не далее 10см от контроллера) можно достичь
    >частот выше 1ГГц.

    да, да, еще и наводки, материалы с примесями и т.д. Уже давно это один из первых аргументов. Я по первому диплому радиоинженер :))) Только вот сдаётся мне, что главная причина сугубо маржовая - никто не рискнёт сказать на рынке "баста, теперь надо скинуться в котёл и собрать 10^1.5...2 млрд и забацать прогресс". Как вы уже в курсе, народ 450Ггц преодолел. И вообще, современные сигналы вещь забавная - под калькуляцию, которую вы привели, лет 50 уже как не вмещаются :)))

     
     
  • 7.54, letsmac (?), 23:05, 14/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >да, да, еще и наводки, материалы с примесями и т.д. Уже давно
    >это один из первых аргументов. Я по первому диплому радиоинженер :)))

    Я типо тоже - но это было 10 лет назад. И как помню - 133 Мгц вроде как предел для традиционной электроники. 450 - это что-то уже эмпирическое. DDR само по себе интересное решение. Дальше выход в спинтронику и оптику. А про "кто-то вышел" это хрень всё - 64 килобита так никто в модемах и не преодолел - та старая теорема из учебника Баскакова непреодолима эт факт :-)

     
     
  • 8.55, pro100master (ok), 00:15, 15/09/2009 [^] [ответить]    [к модератору]  
  • +/
    > А про "кто-то вышел" это
    >хрень всё - 64 килобита так никто в модемах и не
    >преодолел - та старая теорема из учебника Баскакова непреодолима эт факт

    дсл. По началу даже сопли не меняли.

    Что до пределов, спутниковые да и мобильники принимают себе спокойно на гигагерцовых частотах и башню им от этого не сносит :))) Предел, это когда не знаешь как и бьёшься головой об стенку ;)


     
  • 7.56, User294 (ok), 00:46, 15/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >  Как вы уже в курсе, народ 450Ггц преодолел

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

    А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в них - много. И они там не для украшения а чтобы переключаться. И чем больше транзюков и чем чаще они переключаются - тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление схем снижая частоту или отключая клок совсем). А теперь угадайте, что будет на 450ГГц? Правильно - примитивная схема сможет на них работать (правда потребует дорогих компонентов, не тех которые в обычных кремниевых чипах).Но вот мало-мальски сложная схема, как то процессор тупо умрет от своего же тепла. Они и так то жрут некисло. И врядли емкости и т.п. сущности можно снизить *кардинально*. Поэтому на 450ГГц схемы делают. Тупые. Из небольшого количества элементов. А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла.

     
     
  • 8.57, аноним (?), 02:24, 15/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >неминуемо сдохнет от своего же тепла

    смотря как охлаждать
    реально проложить внутри пластины или криотрубки

     
     
  • 9.60, User294 (ok), 01:15, 17/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >смотря как охлаждать
    >реально проложить внутри пластины или криотрубки

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

     
  • 8.58, pro100master (ok), 09:15, 15/09/2009 [^] [ответить]    [к модератору]  
  • +/
    >А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц
    >вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в
    >них - много. И они там не для украшения а чтобы
    >переключаться. И чем больше транзюков и чем чаще они переключаются -
    >тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление
    >схем снижая частоту или отключая клок совсем). А теперь угадайте, что
    >будет на 450ГГц? Правильно - примитивная схема сможет на них работать

    ну вот, опять Интел. К ним претензий нет. У них и кеш на сравнимой частоте работает. Кеш это память? Память. И вопрос я поднял о памяти.

    >А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла.

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

    Вы забываете, что не PC единым. Я как раз согласен, что PC сам себя губит - постоянно тянуть писиай, дма и прочее дорого обходится.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor