|
| 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))
| | |
|
|
|
|
|
| 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 килобита так никто в модемах и не преодолел - та старая теорема из учебника Баскакова непреодолима эт факт :-)
| | |
| 7.56, User294 (ok), 00:46, 15/09/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Как вы уже в курсе, народ 450Ггц преодолел
Угу, только вот у CMOS (одна из наиболее энергоэффективных схемотехник известных на сегодня) есть характерное свойство: потребление равно емкости элемента схемы помноженной на частоту переключения, что, как бы очень логично выглядит с точки зрения физики. Больше частота = больше кушает, стало быть.
А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в них - много. И они там не для украшения а чтобы переключаться. И чем больше транзюков и чем чаще они переключаются - тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление схем снижая частоту или отключая клок совсем). А теперь угадайте, что будет на 450ГГц? Правильно - примитивная схема сможет на них работать (правда потребует дорогих компонентов, не тех которые в обычных кремниевых чипах).Но вот мало-мальски сложная схема, как то процессор тупо умрет от своего же тепла. Они и так то жрут некисло. И врядли емкости и т.п. сущности можно снизить *кардинально*. Поэтому на 450ГГц схемы делают. Тупые. Из небольшого количества элементов. А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла.
| | |
|
|
|
|
|
|
|
