Одним из основных нововведений (http://www.osnews.com/story/22152) очередного релиза операционной системы Mac OS X Snow Leopard от компании Apple стала технология центральной диспетчеризации (Grand Central Dispatch), исходные коды которой выпущены под открытой лицензией Apache License v2. Библиотека не зависит от фреймворка Cocoa, написана на языке Си и должна значительно облегчить разработку программ, использующих современную многоядерную процессорную архитектуру.Технология Grand Central Dispatch — это ответ Apple на проблему параллельного программирования. С развитием современных процессоров, содержащих на одном кристалле два и более ядра, обычный домашний компьютер технологически стал похож на многопроцессорный сервер. И чтобы использовать его вычислительный ресурс на все 100% требуется каким-то образом разделить монолитную программу на ряд параллельно исполняемых независимых «нитей» (threads). Кажущаяся простота реализации этой идеи на практике даже у самых опыт...
URL: http://www.osnews.com/story/22152
Новость: http://www.opennet.me/opennews/art.shtml?num=23382
и в чем отличие от posix threads?
а у них не было чтоли fork?
iCreateProcess ?
Unix предполагает использование множества процессов для достижения цели, ибо создание процесса в Unix очень дёшево. Поэтому мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.
>Поэтому муд... программеры в случаях когда возможны описанные
>side effects юзают процессы, а не потоки.потом всё это весело портировать
> мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться простотой и стройностью решения с форком, глядя на потерянную производительность свысока.
> глядя на потерянную производительность свысока.у Apple настолько медленное межпроцессное взаимодействие ?
Дело не в Apple - в мак оси fork работает. Просто используют поэффективнее.
Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь же дешёвое переключение между ними.
никакая из концепций юникс не отменяет использования многопоточности.По теме - интересно, реализованы ли у них посиксовские политики планировки, если да - то как, лучше чем в текущем линуксе или солярисе?
Для розжига любопытства добавлю, что сейчас в линуксе довольно коряво с этим, можно свободно блокировать выполнение всех процессов планирующих потоки с незаданной политикой, то есть на данный момент позволяется блокировать/деблокировать работу всех приложений, и это неверно, политики планировки потоков одного процесса не должны влиять на другие.
>Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер >Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race >condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну >и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь >же дешёвое переключение между ними.в концепции TBB процессы не нужны. И грош цена им.
Вообще (имхо) пора бы уже переключать логику людей с процесса на внутренности приложения. В условиях сильной конкуренции, вряд ли какой-то там конь в вакууме может лучше определить, что имели ввиду программисты приложения, и оперативно подсуетиться (опять накладные расходы), чтобы дать таблетку стероида. Тут Интел правильно мыслит.
"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", всем рекоммендую. Если не можете найти, где скачать - выложу.
>Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования
>для Unix", всем рекоммендую. Если не можете найти, где скачать -
>выложу.Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь производительность с потоками и с процессами, потом перди.
Некультурный вы наш !Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, либо hello world в сокет пишет. В таком случае потоки будут заметно быстрее, само собой. Если же рабочий код выполняется продолжительное время, то доля fork будет стремиться к 0.0%
Стивенс в каком месте сказал, что fork это зло ? Ткните, если не сложно.
Пища для размышлений: http://www.radwin.org/michael/blog/2004/01/threads_considere...
Да, писал. И с потоками в том числе. И тоже считаю, что потоки вносят чрезмерную сложность в программу.
говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик).Конкретнее: Стивенс, UNP, глава 23, введение и упр №1.
Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. Пищу для размышлений можете в факе фидо.ру.юникс.программинг "как писать сервера" черпать, а не в жж бездельников.
Мне пора, рефлексируйте.
>если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик).значит у моего сервера достаточный пул процессов и их балансировка... и хватит уже.
у потоков есть свои достоинства и недостатки.
допустим никто не скажет, что сервер оракл - хреновый или маленький (или что Вы там приводили?). и опять же подавляющее большинство (да все собстно!) админов скажут, что выделенный оракловый сервер (реализован через процессы) на юникс/линукс НАМНОГО лучше/быстрее/стабильнее, чем разделяемый (реализован через потоки) на винде (а там по другому и нельзя).
не говоря уже о ограничениях, связанных с единым вирт. пространством, ошибками, связанными с общими ресурсами и доступом к ним, а также сложностью с управлением (планировщики ос полюбому лучше и дольше отлажываются и выполняются, чем местечковые разработки или подобные библы... тем более на какой-нибудь другой ОС и/или оборудовании (AMD?... VIA?))
зы:
в результате - действительно нагруженный, сложный и мощьный сервер реализуется через процессы. что не мешает использовать потоки в некоторых, вспомогательных его частях.
и ещё:
>Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать.забавные ограничения!!!
можно подумать, что реализовать "нормальный" сервер можно только на С++!
и ни-ни!!!
а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?
>и ещё:
>>Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать.
>
>забавные ограничения!!!
>можно подумать, что реализовать "нормальный" сервер можно только на С++!
>и ни-ни!!!
>а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?В "вашем" сервере, который существует только в вашем воображении, ассемблерные вставки не спасут орд от необходимости организации межпроцессного взаимодействия, которое ничуть и ни разу не проще взаимодействия между потоками. Займитесь чем-то полезным, любезный.
верно.
но проверенных временем и разработанных лучшими специалистами по всему миру - навалом.
да и ipc преподаётся во всех учебниках... и диадлоков там точно нет... а если я всё-же (!!!) умудрюсь их накодить, то пользователь сможет всё-равно им управлять (т.к. управляется системой, т.е. ОС - теже утилиты ipcrm, ipcs - набор админа)зы:
>В "вашем" сервере, который существует только в вашем воображении,покажите ВАШ сервер... и мы оценим его гениальность.
>говорят, что если цена fork не имеет значения, значит у вашего сервера
>загрузка в два клиента/час (4ре в час пик).Именно форк на каждое соединение клиента - на мое имхо (по итогам смотрения как это работает на практике и как соотносится с другими варантами) - та еще дурь для многих случаев. Нет, конечно, можно обслужить больше клиентов, впихав машин помощнее и побольше, побольше :).Но почему-то нагруженные сайты в последнее время предпочитают (особенно для статики) серваки на основе машин состояний :).К слову вроде в именно упомянутом факе я видел внятное описание того какие бывают вообще модели построения серверов обслуживающих много клиентов одновременно. Хотя под рукой скорее болтается http://www.kegel.com/c10k.html (у которого тоже рассказано про разные варианты построения серверов).
> Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт,
> либо hello world в сокет пишет.Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжинкса, у которых вместо форков конечные автоматы, которые получаются сильно легче? :)
Тем не менее форк - довольно интересная штука. Все-таки точная копия процесса эффективными методами - это круто и внушает. И позволяет делать ряд вкусностей крайне простыми методами скостив блочащие операции до не-блочащих. Просто данный микроскоп тоже не для любых гвоздей хорошо подходит - иногда молоток типа state machines в серваках оказывается лучше.
> Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь
>производительность с потоками и с процессами, потом перди.А потом прикрути машины состояний и пойми что и процессы и треды запускаемые заново на каждого клиента - форменное зло? :)))
это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной под процессы операционной системы. Если вежливо выразить, то это просто намёк, что у Стивенса можно прочесть главу про многопоточные сетевые приложения, и там первое упражнение - вот код, сравните производительность на вашей системе.
Принимал участие в разработке двух серверов, на текущем и прошлом месте занятости, использованный шаблон у обоих был один, хоть я и не был автором ни там и не здесь - на каждого клиента нитка, и на всю систему десяток - другой ниток обработки полученных от клиентов данных, клиентские нити живут время существования соединения, обработчики живут время жизни системы. Только что смотрел систему с 500ми клиентами -полёт нормальный, 2-5 %% в top, производительности более чем хватает. 500 процессов тупо бы не влезали в top))
> deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу....
> Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно.Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальный газ или идеальную жидкость. Ресурсы разделяются между процессами довольно часто и это отнюдь не "однозначно плохой дизайн". Несколько процессов (или потоков, в данном случае не важно) зачастую выполняют совершенно разную работу, но при этом в разные моменты своей работы должны взаимодействовать, не только короткими сообщениями. При этом перекачивать друг другу массивы необходимых данных - непроизводительно. Очень наглядный пример - работа серверов БД. Надо по-настоящему одновременно (на многопроцессорных-то системах) обрабатывать несколько запросов от нескольких клиентов. Самое реальное решение - несколько потоков или процессов, выполняющие эту работу (даже не обязательно схема "один запрос-один процесс", можно организовывать очередь запросов к рабочим процессам). Само собой оптимальнее всего кэшировать недавно запрошенную информацию - держать ее в оперативке. Опять же логично, что каждый процесс не будет держать свой собственный кэш - слишком накладно по памяти и страницы данных, ранее запрошенные одним процессом, могут понадобиться следующему. Следовательно кэш - общая, разделяемая между несколькими процессами область памяти, доступ к которой должен как-то регламентироваться и согласовываться. Это к вопросу о плохом дизайне параллельных систем, использующих общие ресурсы. Вот тут всплывают и понятия примитивов синхронизации - всяких семафоров, мутексов и т.п. А при ошибках программировании и процессы запросто вогнать в дедлок - процесс A заблокировал семафор №1 и хотел было заблокировать семафор №2. Но процесс B в этот промежуток времени успел блокировать семафор №2 и потом ему по логике надо было блокировать семафор №1, но он уже блокирован процессом A - вот и клин - каждый процесс до бесконечности ждет освобождения следующего, нужного ему семафора. Процессы и потоки абсолютно равнозначны с точки зрения опасности дедлоков, если они используют общие ресурсы. А отказаться от общих ресурсов зачастую просто невозможно - дело, как говорилось выше, не в плохом дизайне, наверное как раз наоборот - дизайн с отсутствием общих ресурсов в параллельных системах - более редкая ситуация, типа как обработка независимых кусков сцены графической картой или какой-нибудь брутфорс на тысяче компов каждый со своим проверочным диапазоном паролей :)
"дизайн GCD позволяет рабочим потокам обмениваться сообщениями не только с родительским процессом, но и между собой"Хо-хо, они придумали erlang!
> Связано это с тем, что различные «нити» требуют
> доступа к одним и тем же ресурсам, причем,
> зачастую одновременно.А зачем тогда распараллеливать?!
>А зачем тогда распараллеливать?!как иначе ускорять обработку? время безумного наращивания частот и усложнения инструкций прошло
>>А зачем тогда распараллеливать?!
>
>как иначе ускорять обработку? время безумного наращивания частот
> и усложнения инструкций прошлоКакая разница как добираться до ресурса, через очередь или через очередь + очередь блокировок.
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 + ...
разве irl не будет иначе?
A - B - ... - A(o) - ... - A(R) - ... - N - ... - B(o) - ... - A(z) - B(R) - ...
вплоть до N-1 потоков выполняются без ожидания, полностью утилизируя мощностя
>разве irl не будет иначе?
>A - B - ... - A(o) - ... - A(R) -
>... - N - ... - B(o) - ... - A(z)
>- B(R) - ...
>вплоть до N-1 потоков выполняются без ожидания, полностью утилизируя мощностяВыполняются да, без базара.
Но разговор-то был про очерёдность доступа к блокируемому ресурсу.
Живой пример: 1 проститутка и батальон гусар. (классика) :)
>> Связано это с тем, что различные «нити» требуют
>> доступа к одним и тем же ресурсам, причем,
>> зачастую одновременно.
>
>А зачем тогда распараллеливать?!
>Не, просто не все же время работы нитей - это долбежка к одному и тому же ресурсу. К ресурсу обращаемся только в отдельные моменты, причем стараемся, по возможности, чтобы на короткое время. В остальное время - обращение к другим ресурсам (часто только к своим, неразделенным) и вычисления. А всякие семафоры и мьютексы те нити в очередь и выстроят. А когда обращение к одному ресурсу тормозит всю систему из кучи нитей - вот тут уже надо что-то делать с системой или ее архитектурой - может, увеличивать кол-во ресурсов, если получится.
>Не, просто не все же время работы нитей - это долбежка к
>одному и тому же ресурсу.Естесвенно не всё. Но данные например надо кому-нибудь таки отдать, или забрать другие на обработку например - гемор с незавершёнными транзакциями, у которых надо выяснить собираются они завершаться, влияют ли на наши данные и тд ну и например как-то сам файл с данными в случае С БД придется делить с тонной процессов через диспетчер. Особо не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД".
>не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД".МиФи хороший институт, но одно все-таки не понятно: так где же отечественные файловые системы? oO
>>не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД".
>
>МиФи хороший институт, но одно все-таки не понятно: так где же отечественные
>файловые системы? oOВ отечественных компах. Ну мы же знаем, что за всем стоит user294 который даже тетрис не написал по жизни. Хотя с учетом с того что он и не читал нифига это его извиняет.
Похоже что скоро пингвины будут вынуждены портировать идеи заложенные в этом диспетчере.
Многие кто тут высказывается о бесполезности такого диспетчера не совсем понимают как на практике пишутся и работают многопоточные программы. Почитайте про lock-free контейнеры, tls и попробуйте написать простенький тест чтобы убедиться, что создание процесса занимает много времени.
Дальше всех в "утончении" execution path ушли микрософтовцы - у них есть сущность ещё тоньше и легче, чем поток - fiber. Правда виндовый планировщик криво ими управляет, там много вручную делать надо. Ну это как всегда у микрософта, что поделаешь... Не знаю, может в AIX и последних солярах что получше есть, не смотрел.
Увеличение производительности давно связывают с более эффективным использованием нескольких процессоров. Эппл уже сейчас закладывает для этого хорошую базу (OpenCL), а не примитивные эксперименты с 1:n, n:m и прочими потоковыми библиотеками.
Многое изменится в этой области в ближайшее время. И кстати не только эппловцы делают инновации в ней, что есть очень хорошо для всех нас.
Ага. Типа "я сожру 10 минут на просчитывание нитей, зато сэкономлю тебе 10 секунд", что, впрочем, для работающих по 24 часа в сутки программ не так уж и плохо)
Народ не прочитал новость... Смысл в получении параллельности для обычной программы. Для этого программа должна быть разбита компилятором на блоки. Поддержка всего этого включена в LLVM и clang от того же Apple. Эти блоки могут выполняться параллельно. При сборке программы компилятор делает вызовы на постановку блоков в очередь на асинхронное выполнение, из коей очереди этот самый диспетчер их и выбирает. Перед этим создав какое-то число threads для выполнения этих блоков.PS: вроде Интел тоже работает над внедрением в компиляторы автоматической разбивки программы на куски, которые могут выполняться параллеьно...
>
>PS: вроде Интел тоже работает над внедрением в компиляторы автоматической разбивки программы
>на куски, которые могут выполняться параллеьно...Ну суперскалярность в процах и них есть и без хитрых компиляторов. Я так понимаю основная задача как раз научить суперскалярности менеджер потоков.
При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем написано в посте на который вы отвечаете.
>При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем
>написано в посте на который вы отвечаете.при том. Вся современная компьютерная тормозня из-за непонятного нежелания инженеров делать тактовые генераторы выше 133Мгц. Тупо есть и 450Ггц проекты, а синхронизирующие генераторы даже гигагерца не осилили. Появилась суперскалярность - пока данные туда-сюда - мы выполним х-инструкций (скалярность), причем, можно невпопад (супер). Потому что продавать что-то надо. Но. Проблема в 1) дикие затраты на переключение внутри диспетчеров ОС, 2) еще более дикое усложнение программы для эффективного использования ядер (а сейчас ведь "делают ядра, а не гигагерцы"). Современные процы не утилизируют и 30% транзисторов (могу ошибаться, но за вычетом кеша, вероятно где-то так и есть).
Простой пример . Core и текущие ксенонки могут выполниться 4 инструкции за такт. Но вот беда, при чтении-записи-чтении из/в память ядро может 20 тактов (до 80 инструкций) просидеть в ожидании, кода память родит хоть что-то. Переключение между процессами (ту была статья не так давно по тому же линуху) стоит от 100к до 1м тактов. В виндах еще хуже.
И вот выше рассматривали потоки как они идут на более высоком уровне, где не всё так гладко, а ведь очевидно, что не учли еще и диспетчера ОС, диспетчера проца и существующий 4-6-8-12 мб кеши на проце.
Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко маячит дедушка Эйнштейн.
300 * 10^6 / 133 * 10^6 ~ 2.5 метра. Именно на такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц; причём, в вакууме. Для металлических проводников эту цифрц надо делить на 2.
Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности "столкновения" сигналов -- получаем те же самые 133-200МГц. В последовательном интерфейсе (при условии расположения памяти не далее 10см от контроллера) можно достичь частот выше 1ГГц.
>такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц;
>причём, в вакууме. Для металлических проводников эту цифрц надо делить на
>2.
>Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности
>"столкновения" сигналов -- получаем те же самые 133-200МГц."Барьер" Это строб в виду имеется? Ну даже без Энштейна повторителей никто не отменял. А ещё наводки немерянным тепловым шумом + квадратность сигнала и время на не очень полезный для здоровья транзисторов шаг накачки поля. Не от хорошей жизни это - факт. Повышение параллельности - Cell внезапно помер. А OpenCL пока рождается. Не факт что выживет.
>Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко
>маячит дедушка Эйнштейн.
>300 * 10^6 / 133 * 10^6 ~ 2.5 метра. Именно на
>такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц;
>причём, в вакууме. Для металлических проводников эту цифрц надо делить на
>2.
>Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности
>"столкновения" сигналов -- получаем те же самые 133-200МГц. В последовательном интерфейсе
>(при условии расположения памяти не далее 10см от контроллера) можно достичь
>частот выше 1ГГц.да, да, еще и наводки, материалы с примесями и т.д. Уже давно это один из первых аргументов. Я по первому диплому радиоинженер :))) Только вот сдаётся мне, что главная причина сугубо маржовая - никто не рискнёт сказать на рынке "баста, теперь надо скинуться в котёл и собрать 10^1.5...2 млрд и забацать прогресс". Как вы уже в курсе, народ 450Ггц преодолел. И вообще, современные сигналы вещь забавная - под калькуляцию, которую вы привели, лет 50 уже как не вмещаются :)))
>да, да, еще и наводки, материалы с примесями и т.д. Уже давно
>это один из первых аргументов. Я по первому диплому радиоинженер :)))Я типо тоже - но это было 10 лет назад. И как помню - 133 Мгц вроде как предел для традиционной электроники. 450 - это что-то уже эмпирическое. DDR само по себе интересное решение. Дальше выход в спинтронику и оптику. А про "кто-то вышел" это хрень всё - 64 килобита так никто в модемах и не преодолел - та старая теорема из учебника Баскакова непреодолима эт факт :-)
> А про "кто-то вышел" это
>хрень всё - 64 килобита так никто в модемах и не
>преодолел - та старая теорема из учебника Баскакова непреодолима эт фактдсл. По началу даже сопли не меняли.
Что до пределов, спутниковые да и мобильники принимают себе спокойно на гигагерцовых частотах и башню им от этого не сносит :))) Предел, это когда не знаешь как и бьёшься головой об стенку ;)
> Как вы уже в курсе, народ 450Ггц преодолелУгу, только вот у CMOS (одна из наиболее энергоэффективных схемотехник известных на сегодня) есть характерное свойство: потребление равно емкости элемента схемы помноженной на частоту переключения, что, как бы очень логично выглядит с точки зрения физики. Больше частота = больше кушает, стало быть.
А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в них - много. И они там не для украшения а чтобы переключаться. И чем больше транзюков и чем чаще они переключаются - тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление схем снижая частоту или отключая клок совсем). А теперь угадайте, что будет на 450ГГц? Правильно - примитивная схема сможет на них работать (правда потребует дорогих компонентов, не тех которые в обычных кремниевых чипах).Но вот мало-мальски сложная схема, как то процессор тупо умрет от своего же тепла. Они и так то жрут некисло. И врядли емкости и т.п. сущности можно снизить *кардинально*. Поэтому на 450ГГц схемы делают. Тупые. Из небольшого количества элементов. А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла.
>неминуемо сдохнет от своего же тепласмотря как охлаждать
реально проложить внутри пластины или криотрубки
>смотря как охлаждать
>реально проложить внутри пластины или криотрубкиПохрену, помрет от локального перегрева - теплопроводность у полупроводников обычно так себе. Или вообще все разрушится от диких перепадов температур при потугах отводить киловатты тепла (а вы сколько хотели увидеть на такой частоте, когда процы нынче жрут до сотен ватт на их несколько ГГц?).
>А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц
>вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в
>них - много. И они там не для украшения а чтобы
>переключаться. И чем больше транзюков и чем чаще они переключаются -
>тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление
>схем снижая частоту или отключая клок совсем). А теперь угадайте, что
>будет на 450ГГц? Правильно - примитивная схема сможет на них работатьну вот, опять Интел. К ним претензий нет. У них и кеш на сравнимой частоте работает. Кеш это память? Память. И вопрос я поднял о памяти.
>А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла.
а зачем столько? Из миллиарда транзисторов - 90% кеш, который как раз и сглаживает потери времени на операциях с памятью. Вычислительные блоки там не намного больше первых пней. Просто их количество существенно больше, опять же из-за суперскалярности.
Вы забываете, что не PC единым. Я как раз согласен, что PC сам себя губит - постоянно тянуть писиай, дма и прочее дорого обходится.