The OpenNET Project / Index page

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

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

12.09.2009 01:04

Одним из основных нововведений очередного релиза операционной системы 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 обязательно
Обсуждение (48) Ajax | 1 уровень | Линейный | Раскрыть всё | 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 +/
    > мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.

    К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться простотой и стройностью решения с форком, глядя на потерянную производительность свысока.

     
     
  • 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 +/
    Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь же дешёвое переключение между ними.
     
     
  • 3.14, Вова (?), 16:14, 12/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    никакая из концепций юникс не отменяет использования многопоточности.  

    По теме - интересно, реализованы ли у них посиксовские политики планировки, если да - то как, лучше чем в текущем линуксе или солярисе?

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

     
  • 3.24, pro100master (ok), 22:44, 12/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер >Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race >condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну >и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь >же дешёвое переключение между ними.

    в концепции 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 threaded program in C++ or Java, despite years of study. It's just too hard." - Брюс Эккель, ни много ни мало.

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

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

    Про дешёвое создание процесса и переключение - архитектура Unix изначально под это заточена.

    Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования для Unix", всем рекоммендую. Если не можете найти, где скачать - выложу.

     
     
  • 4.30, Вова (?), 10:20, 13/09/2009 [^] [^^] [^^^] [ответить]  
  • +/

    >Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования
    >для Unix", всем рекоммендую. Если не можете найти, где скачать -
    >выложу.

      Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь производительность с потоками и с процессами, потом перди.


     
     
  • 5.33, Юниксоид (??), 19:51, 13/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Некультурный вы наш !

    Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, либо hello world в сокет пишет. В таком случае потоки будут заметно быстрее, само собой. Если же рабочий код выполняется продолжительное время, то доля fork будет стремиться к 0.0%

    Стивенс в каком месте сказал, что fork это зло ? Ткните, если не сложно.

    Пища для размышлений: http://www.radwin.org/michael/blog/2004/01/threads_considered_harmful.html

    Да, писал. И с потоками в том числе. И тоже считаю, что потоки вносят чрезмерную сложность в программу.

     
     
  • 6.35, Вова (?), 22:57, 13/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик).

    Конкретнее: Стивенс, UNP, глава 23, введение и упр №1.
    Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. Пищу для размышлений можете в факе фидо.ру.юникс.программинг "как писать сервера" черпать, а не в жж бездельников.
    Мне пора, рефлексируйте.

     
     
  • 7.36, vitek (??), 09:06, 14/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик).

    значит у моего сервера достаточный пул процессов и их балансировка... и хватит уже.

    у потоков есть свои достоинства и недостатки.
    допустим никто не скажет, что сервер оракл - хреновый или маленький (или что Вы там приводили?). и опять же подавляющее большинство (да все собстно!) админов скажут, что выделенный оракловый сервер (реализован через процессы) на юникс/линукс НАМНОГО лучше/быстрее/стабильнее, чем разделяемый (реализован через потоки) на винде (а там по другому и нельзя).
    не говоря уже о ограничениях, связанных с единым вирт. пространством, ошибками, связанными с общими ресурсами и доступом к ним, а также сложностью с управлением (планировщики ос полюбому лучше и дольше отлажываются и выполняются, чем местечковые разработки или подобные библы... тем более на какой-нибудь другой ОС и/или оборудовании (AMD?... VIA?))
    зы:
    в результате - действительно нагруженный, сложный и мощьный сервер реализуется через процессы. что не мешает использовать потоки в некоторых, вспомогательных его частях.

     
  • 7.37, vitek (??), 09:10, 14/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    и ещё:
    >Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать.

    забавные ограничения!!!
    можно подумать, что реализовать "нормальный" сервер можно только на С++!
    и ни-ни!!!
    а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >говорят, что если цена fork не имеет значения, значит у вашего сервера
    >загрузка в два клиента/час (4ре в час пик).

    Именно форк на каждое соединение клиента - на мое имхо (по итогам смотрения как это работает на практике и как соотносится с другими варантами) - та еще дурь для многих случаев. Нет, конечно, можно обслужить больше клиентов, впихав машин помощнее и побольше, побольше :).Но почему-то нагруженные сайты в последнее время предпочитают (особенно для статики) серваки на основе машин состояний :).К слову вроде в именно упомянутом факе я видел внятное описание того какие бывают вообще модели построения серверов обслуживающих много клиентов одновременно. Хотя под рукой скорее болтается http://www.kegel.com/c10k.html (у которого тоже рассказано про разные варианты построения серверов).

     
  • 6.47, User294 (ok), 21:54, 14/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт,
    > либо hello world в сокет пишет.

    Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжинкса, у которых вместо форков конечные автоматы, которые получаются сильно легче? :)

    Тем не менее форк - довольно интересная штука. Все-таки точная копия процесса эффективными методами - это круто и внушает. И позволяет делать ряд вкусностей крайне простыми методами скостив блочащие операции до не-блочащих. Просто данный микроскоп тоже не для любых гвоздей хорошо подходит - иногда молоток типа state machines в серваках оказывается лучше.

     
  • 5.49, User294 (ok), 22:27, 14/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >  Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь
    >производительность с потоками и с процессами, потом перди.

    А потом прикрути машины состояний и пойми что и процессы и треды запускаемые заново на каждого клиента - форменное зло? :)))

     
     
  • 6.59, Вова (?), 14:11, 15/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной под процессы операционной системы.  Если вежливо выразить, то это просто намёк, что у Стивенса можно прочесть главу про многопоточные сетевые приложения, и там  первое упражнение - вот код, сравните производительность на вашей системе.
    Принимал участие в разработке двух серверов, на текущем и прошлом месте занятости, использованный шаблон у обоих был один, хоть я и не был автором ни там и не здесь - на каждого клиента нитка, и на всю систему десяток - другой ниток обработки полученных от клиентов данных, клиентские нити живут время существования соединения, обработчики живут время жизни системы. Только что смотрел систему с 500ми клиентами -полёт нормальный, 2-5 %% в top, производительности более чем хватает.  500 процессов тупо бы не влезали в top))

     
  • 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 +/
    >>А зачем тогда распараллеливать?!
    >
    >как иначе ускорять обработку? время безумного наращивания частот
    > и усложнения инструкций прошло

    Какая разница как добираться до ресурса, через очередь или через очередь + очередь блокировок.

    A-поток, B-поток, ..., N-поток. R - ресурс. o - блокировка. z - разблокировка

    Линейно: A - o - R - z - B - o  - R - z - ... - N - o - R - z

    Праллел: A - B - ... N - A(o), B(o), ..., N(o), - A(R), B(R),..., N(R) - A(z), B(z),..., N(z)

    Причем каждый поток/процесc/задача... тусуется в очереди перед каждой блокировкой, ожидая её снятия.

    Так может, до 32 процессоров, выгоднее потусоваться в общей очереди?!

    Без блокировки: AR - BR ... - NR

    ------

    Другое дело это параллельные вычисления.

    например сумма ряда, когда члены ряда считаются на отдельных процах.

    Sum ( sin(x)/x, от 1 до 2^64 ) на 8-ядерном

    CPU(1) = sin(1)/1 + sin(9)/9 +  ...
    CPU(2) = sin(2)/2 + sin(10)/10 + ...
    CPU(3) = sin(3)/3 + sin(11)/11 + ...
    CPU(4) = sin(4)/4 + sin(12)/12 + ...
    CPU(5) = sin(5)/5 + sin(13)/13 + ...
    CPU(6) = sin(6)/6 + sin(14)/14 + ...
    CPU(7) = sin(7)/7 + sin(15)/15+ ...
    CPU(8) = sin(8)/8 + sin(16)/16 + ...

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >разве irl не будет иначе?
    >A - B - ... - A(o) - ... - A(R) -
    >... - N - ... - B(o) - ... - A(z)
    >- B(R) - ...
    >вплоть до N-1 потоков выполняются без ожидания, полностью утилизируя мощностя

    Выполняются да, без базара.

    Но разговор-то был про очерёдность доступа к блокируемому ресурсу.

    Живой пример: 1 проститутка и батальон гусар. (классика) :)

      

      

     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >>не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД".
    >
    >МиФи хороший институт, но одно все-таки не понятно: так где же отечественные
    >файловые системы? oO

    В отечественных компах. Ну мы же знаем,  что за всем стоит 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 [^] [^^] [^^^] [ответить]  
  • +/
    >
    >PS: вроде Интел тоже работает над внедрением в компиляторы автоматической разбивки программы
    >на куски, которые могут выполняться параллеьно...

    Ну суперскалярность в процах и них есть и без хитрых компиляторов. Я так понимаю основная задача как раз научить суперскалярности менеджер потоков.

     
     
  • 3.32, frey (ok), 16:00, 13/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем написано в посте на который вы отвечаете.
     
     
  • 4.34, pro100master (ok), 20:52, 13/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем
    >написано в посте на который вы отвечаете.

    при том. Вся современная компьютерная тормозня из-за непонятного нежелания инженеров делать тактовые генераторы выше 133Мгц. Тупо есть и 450Ггц проекты, а синхронизирующие генераторы даже гигагерца не осилили. Появилась суперскалярность - пока данные туда-сюда - мы выполним х-инструкций (скалярность), причем, можно невпопад (супер). Потому что продавать что-то надо. Но. Проблема в 1) дикие затраты на переключение внутри диспетчеров ОС, 2) еще более дикое усложнение программы для эффективного использования ядер (а сейчас ведь "делают ядра, а не гигагерцы"). Современные процы не утилизируют и 30% транзисторов (могу ошибаться, но за вычетом кеша, вероятно где-то так и есть).

    Простой пример . Core и текущие ксенонки могут выполниться 4 инструкции за такт. Но вот беда, при чтении-записи-чтении из/в память ядро может 20 тактов (до 80 инструкций) просидеть в ожидании, кода память родит хоть что-то. Переключение между процессами (ту была статья не так давно по тому же линуху) стоит от 100к до 1м тактов. В виндах еще хуже.

    И вот выше рассматривали потоки как они идут на более высоком уровне, где не всё так гладко, а ведь очевидно, что не учли еще и диспетчера ОС, диспетчера проца и существующий 4-6-8-12 мб кеши на проце.

     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    дсл По началу даже сопли не меняли Что до пределов, спутниковые да и мобильник... текст свёрнут, показать
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    ну вот, опять Интел К ним претензий нет У них и кеш на сравнимой частоте работ... текст свёрнут, показать
     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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