Конференция работает на сервере Netberg

Radeon.ru

Конференция Radeon.ru

Страница 1 из 5 [ Сообщений: 191 ]  Версия для печати [+] На страницу 1, 2, 3, 4, 5  След.
Показать сообщения за  Поле сортировки  
Все ж таки создам новую тему дабы не засорять 90нм...
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik:
Ну не думаешь же ты, что разработка чипа уровня i386 и чипа уровня Pentium стоит одинаково?</SPAN><HR size=22></SPAN></BLOCKQUOTE>
Нет конечно.
Но стоимость разработки i386 в то время, когда его разрабатывали, и стоимость разработки Pentium в то время, когда разрабатывали его, были примерно одинаковы.
Да и вообще, корректнее оценивать стоимость не в деньгах, а во времени разработки, а по этому параметру Pentium, может, и "дешевле" вышел.

Сложность чипа отличается на порядок, стоимость разработки — тоже примерно на порядок.
Так и новые методы борьбы с этой сложностью появились за это время. Моделирование, библиотеки элементов, опыт в конце концов.

Нынешние ядра, что К7, что Р6, проходят несколько инкарнаций именно потому, что сразу выложить все возможности ядра, думаю, просто не под силу даже Интел. Не зря постоянно выходят новые ревизии ядра...
новые ревизии лишь исправляют ошибки старых.
а раскрывают возможности --- новые ядра (старой архитектуры).
и разрабатывать их примерно столь же трудно (в смысле --- долго), как и ядра новой архитектуры.

<I>Единственный вопрос — думаешь, их много?
В конце концов, талантливый разработчик ничуть не меньшая редкость, чем талантливый композитор, например. Тех вроде не так уж много, и простой учебой в консерватории композитором не стать.</I>
Почему не стать? Там вроде есть такие группы, если не факультет целый (не знаю как там в консерватории это называется).
А что касается архитекторов (не чипов, правда, а зданий --- но склад ума у них тот же), то и целый институт в Москве есть --- МАРХИ. Изображение
В общем, я уверен, людей таких масса.
Только не у всех опыт есть и соответствующая подготовка...
Ну так Intel и IBM могут позволить себе содержать и десятикратный штат архитекторов IMHO.
VLev
Но стоимость разработки i386 в то время, когда его разрабатывали, и стоимость разработки Pentium в то время, когда разрабатывали его, были примерно одинаковы.
Если ты говоришь о той доле доходов, которая на это уходила — то, возможно, что да. Если об абсолютной стоимости — то нет, Пентиум дороже.

Так и новые методы борьбы с этой сложностью появились за это время. Моделирование, библиотеки элементов, опыт в конце концов.
Это да, это в плюс. Правда, вырастает ли от этого производительность на порядок? Не знаю.

<I>новые ревизии лишь исправляют ошибки старых.
а раскрывают возможности --- новые ядра (старой архитектуры).
и разрабатывать их примерно столь же трудно (в смысле --- долго), как и ядра новой архитектуры.</I>
ОК, согласен с поправкой. Только все же новые ядра НОВОЙ архитектуры разрабатывать явно дольше. Поскольку в новых ядрах старой архитектуры надо решить только технологические проблемы, а для новой архитектуры еще и архитектурные.

Почему не стать?
Потому что легко выпекать "творцов" уровня группы "Стрелки". Но сложно уровня Плачидо Доминго Изображение Еще и талант нужен.
Так и здесь, думаю: процессоры уже давно перешли с уровня "чичас мы засунем усе шо нужно в одну микруху" на уровень инженерных шедевров. Соответственно, и людей, способных генерировать идеи подходящего масштаба, и решать их — явно немного. Просто посмотри на ВИА — уже четвертое поколение процессоров, а они еще не догнали Р6 по производительности на такт. И в ближайшее время надежды на это нет.
Если бы было так просто, как ты говоришь, ВИА уже давно бы всех зарулилиа. Ан нет...
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>matik:
Если ты говоришь о той доле доходов, которая на это уходила — то, возможно, что да. Если об абсолютной стоимости — то нет, Пентиум дороже.</SPAN><HR size=22></SPAN></BLOCKQUOTE>
На самом деле я говорю о том, что стоимость разработки новой архитектуры (в денежном выражении) исчезающе мала по сравнению с другими затратами, например, на разработку новых техпроцессов, или на физдизайн новой инкарнации старого процессора, или на строительство новых производственных линий.
Проблема лишь в том, что новую хорошую архитектуру процессора обычно нельзя "купить" за эти небольшие деньги, если "вдруг" приспичит. (Иногда, правда, покупали вместе с разработавшими ее фирмами)
Новая хорошая архитектура --- это продукт творческой работы опытного слаженного коллектива разработчиков (не обязательно большого), вдохновленных какой-то продуктивной идеей.
Intel содержит две или три таких команды (а может, и больше). Так вот мне интересно: где результат их работы?

Это да, это в плюс. Правда, вырастает ли от этого производительность на порядок? Не знаю.
Почему нет? Если считать, что бОльшая часть проблем заключена в вылавливании блох, то, думаю, вырастет.

Только все же новые ядра НОВОЙ архитектуры разрабатывать явно дольше. Поскольку в новых ядрах старой архитектуры надо решить только технологические проблемы, а для новой архитектуры еще и архитектурные.
Дело в том, что часть технологических проблем можно и нужно решать именно на архитектурном уровне. Тогда при физдизайне их просто не будет.

Потому что легко выпекать "творцов" уровня группы "Стрелки". Но сложно уровня Плачидо Доминго Изображение
К сожалению Изображение (или к счастью Изображение ), современные процессоры x86 есть результат победы "попсы" в мире IT. Изображение
Правда, высококачественной "попсы".

Если бы было так просто, как ты говоришь, ВИА уже давно бы всех зарулилиа. Ан нет...
Ну, думаю, у них цели несколько другие...
Хотя об этом стоит подумать Изображение
VLev
А что касается архитекторов (не чипов, правда, а зданий --- но склад ума у них тот же), то и целый институт в Москве есть --- МАРХИ.

Имхо, очень неудачное сравнение. Склад ума отличается как небо и земля Изображение Несмотря на внешнюю похожесть проектирования. Объяединяет только одно — креатив. Но на udaff тоже "креатифф" Изображение Хотя параллель между промышленными строительными объектами и процессорами на удивление хорошо смотрится.

Intel содержит две или три таких команды (а может, и больше). Так вот мне интересно: где результат их работы?

Я уже выссказывался в другом месте на эту тему Изображение И результатов, кстати, много, даже слишком много. А проблема, имхо, только в одном — Интел перестал быть саморегулиемой технократичной фирмой. Ей руководят "маркетологи" от IT бизнеса, которые направляют и ... ошибаются, направляют и ... снова ошибаются. Как это не парадоксально, но сегодняшние флагманы Интела — P4 и Itanium — СТРАТЕГИЧЕСКИЕ ошибки (только не бейте сильно Изображение). Не забей Интел на развитие PIII — кто знает в какой ж. мы бы сейчас видели АМД, не потрать столько сил и денег на в целом не оправдывающий ожиданий проект Itanium, вложи эти мегамозги в продукт, изначально не уступающий по производительности на родном коде х86...

Дело в том, что часть технологических проблем можно и нужно решать именно на архитектурном уровне. Тогда при физдизайне их просто не будет.

Имхо, так УЖЕ не получается. Сложность современной архитектуры такова, что ошибки неизбежны из-за времени, которое отведено на разработку. Используя твое (ничего, что на ты?) сравнение со строителями, 386 похож на кирпичный заводик по сравнению с атомной станцией (Р4/Opteron). И любой строительный проект (кроме совсем уж простых или типовых) содержит огромное количество ошибок. САПР и всевозможные библиотеки позволяют минимизировать их, но не избежать в принципе. Документацию всегда можно разделить на "как спроектировано" и "как построено" Изображение

>McZag: ничего, что на ты?\

давно пора Изображение

Имхо, очень неудачное сравнение. Склад ума отличается как небо и земля Изображение
Тут можно поспорить. Вообще, у меня сестра архитектор, по одному из проектов даже главный (гап)
Я все же думаю, что склад ума как раз тот же, только обычные архитекторы "гуманитарии", а чиповые --- "технари", отсюда и видимая разница.

Ну да ладно, есть куда более удачные сравнения --- например, архитектор проекта при разработке софта.

И результатов, кстати, много, даже слишком много.
Да вот у меня есть сомнения по этому поводу. Примеры приведешь чего-нибудь свеженького?

Не забей Интел на развитие PIII...
А вот это уже повод для серьезного спора Изображение.
Есть мнение, что PIII в микроархитектурном плане старье, не способное конкурировать ни с кем, более того, это наследие досталось и iP4, что и не позволило последнему "похоронить" AMD.

Имхо, так УЖЕ не получается. Сложность современной архитектуры такова, что ошибки неизбежны из-за времени, которое отведено на разработку.
Так все-таки причина в лавинообразном нарастании ошибок?
Возможно. Тогда хорошо бы как-то классифицировать самые тяжелые...
Я, например, тоже вижу ошибки стратегического планирования --- это когда перед разработчиками ставится невыполнимая или неактуальная задача, причем эта невыполнимость/неактуальность выясняется только тогда, когда проект близок к окончанию. Но этот класс ошибок вряд ли возник только сейчас --- они были, есть и будут всегда, и касаются не только чиповых компаний.
см. законы Паркинсона

[Исправлено: VLev : 26-09-2004 21:08]
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>McZag:
А проблема, имхо, только в одном — Интел перестал быть саморегулиемой технократичной фирмой. Ей руководят "маркетологи" от IT бизнеса, которые направляют и ... ошибаются, направляют и ... снова ошибаются...</SPAN><HR size=22></SPAN></BLOCKQUOTE>
Так проблема отсутствия новых архитектур на только Intel касается. AMD, в частности, еще в бОльшей степени.
Intel --- лишь удобный [для меня] пример, так как я неплохо представляю себе ее историю.
VLev
На самом деле я говорю о том, что стоимость разработки новой архитектуры (в денежном выражении) исчезающе мала по сравнению с другими затратами, например, на разработку новых техпроцессов, или на физдизайн новой инкарнации старого процессора, или на строительство новых производственных линий.
Не знаю, не знаю.... Что считать затратами на новую архитектуру? Если только зарплату инженеров-разработчиков, то да, невелики.
Но, вообще говоря, любой бизнес проект начинается намного раньше. И перед разработкой непосредственно архитектуры маркетинговый отдел пытается угадать направление потребительского спроса (или скорректировать его), аналитики проводят финансовое планирование, производственники закладывают некие технологические возможности. Смежные группы делают свое планирование: платформа, периферия поддержки, соответствующие запросы ОЕМ.
И только потом группе разработчиков выдается план: имеем возможность запустить ядро следующей площади, в таком-то количестве, на такой-то платформе, потенциально потребители готовы оплачивать то-то и то-то.

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

Мне кажется, что именно в этом пункте и есть разногласия. Ты считаешь, что эта работа второстепенна. Тогда как, ИМХО, именно она и необходима для запуска новой архитектуры. Любой архитектуры.
VLev
обычные архитекторы "гуманитарии", а чиповые --- "технари", отсюда и видимая разница.

Где-то так. А где ваша сестра трудится?

Ну да ладно, есть куда более удачные сравнения --- например, архитектор проекта при разработке софта.

О. Это типа меня Изображение

Да вот у меня есть сомнения по этому поводу. Примеры приведешь чего-нибудь свеженького?

Так ведь пальцев на двух руках не хватит. Вон matik в летней статье сколько всего "навспоминал" Изображение Если серьезно, то я считаю, что Интел не только не ослабил поток "нового", но наоборот его кратно усилил. Только если раньше это были флагманские решения, сконцентрированные на одной линии фронта, то сейчас "время колокольчиков" ©. Чем занимался Интел во время разработки 386? А сейчас?

Да и оценивать мы все стали по другому. Сочуствуем мы (что ж тут поделать) их "маленькому" конкуренту, поэтому изначально занимаем жесткую позицию по отношению к гиганту. Мол, не стыдно тебе с такими ресурсами и баблом, воду в ступе толочь? Изображение А у Интела, имхо, проблемы роста. И опять же повторюсь, на мой взгляд, проблемы временные.

Извини, что так уклончиво отвечаю — домой уже хочется. Завтра выцарапаю время, по пунктам распишу, какие вещи, сделанные за последний год Интелом, мне нравятся и кажутся "новыми".


matik, VLev

Я бы не стал делить затраты на идеологию и разработку (физическое воплощение). Это непрерывный процесс превращения из свинца в золото. К тому же у меня есть личный опыт, что команда архитекторов современного проекта (серьезный софт, процессор) должна составлять примерно четверть (если не больше) от проектировщиков/программистов. С учетом несколько_более_высокой_зарплаты затраты на их содержание сопоставимы. Возможно, что у Интел просто не хватает архитекторов — их распылили тонким слоем на кучу направлений (или решили сэкономить Изображение).
McZag:
<font class="off">А где ваша сестра трудится?
Раньше --- в Моспроект2, теперь --- в частной проектной фирме.
</font>

И опять же повторюсь, на мой взгляд, проблемы временные.
Но почему тогда эти ошибки проявляются именно в архитектуре?
С внедрением новых техпроцессов, скажем, у Intel никаких проблем нет, даже опережение (кстати, недавно что-то 65нм запустили) --- а это, IMHO куда более сложно прогнозируемые разработки, тем более что глобальная проблема с оптической литографией до сих пор не решена.

Я бы не стал делить затраты на идеологию и разработку (физическое воплощение).
Ok, соглашусь.
VLev
Это понять можно, но в долгосрочном плане это может обернуться проигрышем в конкурентной борьбе.
Ну так развитие подобной ситуации вы разве не наблюдаете? Она же прям перед глазами Изображение

Примеры?
А что итаниум — не пример? Сколько было вложено в проект? Немало, уж точно. Во сколько оценивался рост на начальном этапе и главное какие продажи прогнозировались под которые задействовались определенные ресурсы? И что? С каждым годом те самые оценки/прогнозы продаж падали этак на 20-30% ...
Вообще-то я говорил об общих тенденциях, когда рост и отдача уже давно не те, что имели место быть на заре или на последнем пике с т.н. Y2K

Да и вообще, корректнее оценивать стоимость не в деньгах, а во времени разработки, а по этому параметру Pentium, может, и "дешевле" вышел.
Как раз лучше оценивать в деньгах, а не по времени, т.к . time is money

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

McZag
А у Интела, имхо, проблемы роста. И опять же повторюсь, на мой взгляд, проблемы временные.
Т.е они (проблемы) будут преодолены или усилены? Я таки все больше начинаю склоняться ко второму. ИМХО.

VLev
<I>Но почему тогда эти ошибки проявляются именно в архитектуре?
С внедрением новых техпроцессов, скажем, у Intel никаких проблем нет</I>
Наверно нехватка в дизгруппе пипла с др. специальностями. Вообще-то собрать воедино и оптимально коллектив — задача очень трудная
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>U2:
Ну так развитие подобной ситуации вы разве не наблюдаете? Она же прям перед глазами Изображение</SPAN><HR size=22></SPAN></BLOCKQUOTE>
По-моему, о проигрыше тут говорить рано.
Даже если будет 50/50 --- IMHO всем будет лучше, рынок оздоровится.

А что итаниум — не пример?
вообще-то неудачные проекты были и раньше:
i860 например, до того был еще какой-то i4xx, вообще не выпущенный.
Но это никогда не мешало Intel продолжать генеральную линию, скорее помогало, т.к. многие решения этих поисковых проектов потом использовались в mainstream (или, по крайней мере, становилось ясно, что так делать нельзя).

Сколько было вложено в проект? Немало, уж точно. Во сколько оценивался рост на начальном этапе и главное какие продажи прогнозировались под которые задействовались определенные ресурсы? И что? С каждым годом те самые оценки/прогнозы продаж падали этак на 20-30% ...
Ну, это все маркетинговые просчеты.
А в архитектурном плане Itanium смотрится очень неплохо.
Кстати говоря, в развитие его архитектуры тоже давно не вкладывают много сил IMHO.
VLev
Кстати говоря, в развитие его архитектуры тоже давно не вкладывают много сил IMHO.
скорее всего именно так. иначе почему начиная с и2 (который вообще-то был сделан НР, а первый интелом (по слухамИзображение)кончая еще не вышедшими в люди двухядерными решениями ничего не меняется, кроме задирания шины (и то в планах) и кэша. Даже чипсеты разрабатываются новые в основном сторонними игроками. Кстати как и для ксионов МП в свое время…

McZag
Если серьезно, то я считаю, что Интел не только не ослабил поток "нового", но наоборот его кратно усилил.
действительно похоже на то, что интел начал распыляться на слишком большое количество сегментов и разных (часто не связанных) решениях.

VLev
matik
кстати, а может стоимость разработки архитекторы смотреть не в абсолютных цифрах а в относительных, тогда для одной компании запросто может оказаться, что стоимость разработки 386 будет явно не выше чем скажем нетбурстов.
VLev
Сама по себе стоимость условной микроархитектуры м.б. и мала, даже ничтожно мала. Хотя тут зависит от аппетита разработчиков, скажем стороннего. Если губа -не дура, то они запросят соответственно. А если же свои, то тогда тут дело техники, профессионализма и рынка.

Что касается уже имплементации конкретного одного дизайна до воплощения в прототип, то стоимость может доходить до 25 лимонов (для 90 мкм) *поднятая тема подвинула на изучение финансовой стороны* Ну а далее, если все ОК, идут уже др. статьи расходов, не менее важные.

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

Ну а в будущем, вы же сами давече сказали, будет упор на SMT. Далее увидим у кого и когда это лучше получиться.

Тогда хорошо бы как-то классифицировать самые тяжелые...
Вот специально посмотрел на некоторые данные, связанные с дизайном IC (по всей индустрии)

10 наиболее критичных факторов, рассматриваемых компаниями (в порядке убывания):

— Utilizing installed base of EDA tools and databases
— Time-to-market
— IC design operating as expected
— Minimizing chip area
— Driving performance limits
— Meeting power budgets
— Integrating IP and IP interface efficiently
— Migrating to nextgeneration technology
— System-level design concepts
— Co-developing hardware and software

Кстати говоря, в развитие его архитектуры тоже давно не вкладывают много сил IMHO.
В архитектуру — да, а вот на кремнизацию/поддержку и пр. — ого-ого. И все это желательно рассматривать вместе. Чего стоит сама по себе архитектура!? Это же не яйца Фаберже, чтобы просто на них любоваться Изображение
U2
Что касается уже имплементации конкретного одного дизайна до воплощения в прототип, то стоимость может доходить до 25 лимонов (для 90 мкм)

По-моему, все же больше, а если еще вспомнить о покупке и амортизации оборудования... То есть, не "доходить до 25 лимонов", а превышать. Осмелюсь тут процитировать один свой старый материалец за 2003-01-03

<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>
Вице-президент и ведущий аналитик компании Gartner Dataquest Джереми Донован (Jeremey Donovan) представил некоторые расчеты, предметно представляющие сложности перехода на нормы 0,13 мкм техпроцесса и к выпуску 300 мм кремниевых пластин. Несмотря на то, что, как правило, аналитики упоминают их внедрение совместно друг с другом, освоение двух технологий одновременно совсем необязательно, а для некоторых компаний еще и не по карману.

Переход с норм 0,18 мкм техпроцесса к 0,13 мкм технологии (впрочем, как и все предыдущие технологические апгрейды норм производства) привнес два существенных вопроса: проблемы технологической реализации и стоимость фотомасок. Если с вопросами технической реализации техпроцесса компании рано или поздно справляются, то проблема стоимости масок остается и в конце концов выходит на первый план. Вот сравнительные данные: если ранее набор из 15 масок для норм 0,25 мкм техпроцесса обходился в $150 тысяч, а набор из 21 маски для 0,18 мкм норм — в $250 тысяч, то теперь, для 0,13 мкм техпроцесса набор масок стоит уже $600 тысяч.

Более чем двукратный рост стоимости набора масок делает гораздо более предпочтительным выпуск специализированной логики (ASIC, ASSP), чем матричных программируемых интегральных микросхем (FPGA). Впрочем, на фоне суммы в $20 млн., являющейся нынче минимумом затрат для выпуска первых FPGA чипов, разница между $600 тысячами и $250 тысячами не так заметна, но что будет твориться при переходе к следующему поколению технологического процесса? Дальше производителям FPGA-чипов остается лишь схватиться за голову, поскольку комплект масок для 90 нм техпроцесса обойдется уже примерно в $1,5 млн., для норм 65 нм – примерно в $4 млн.

Более впечатляюще выглядят затраты при переходе к выпуску 300 мм кремниевых пластин взамен 200 мм. При самой оптимистичной доходности одного квадратного дюйма пластины в $150, стоимость одной 300 мм кремниевой пластины составляет около $20 тысяч. Путем простых расчетов получается, что компания, решившая наладить производство 300 мм пластин с ежемесячным выходом порядка 25 тысяч, за год будет вынуждена продать полупроводников никак не меньше чем на $4,5 млрд., чтобы был смысл строить такую фабрику. Помимо того, что строительство такой фабрики подразумевает огромные капвложения, обязательным условием окупаемости такой затеи также является фактически 100% ежемесячная загруженность ее производственных линий.
</SPAN><HR size=22></SPAN></BLOCKQUOTE>

Все конечно лирика полуторагодовой давности, но мсье Донован тогда еще не был в курсе, сколько слоев металлизации будет у 300 мм пластины под 90 нм Прескотты, а под 65 нм Смитфилды — еще на один больше, то есть восемь. Плюс, по причине нерешенности вопросов с оптикой для 157 нм литографии, используется "старая" 193 нм литография, из-за чего маски со сдвигом фазы обладают, ИМХО, дурной ценой. Точных цифр у меня нет, но думаю, цены таких фотомасок очень высоки. И никто на самом деле сейчас даже не догадывается, сколько стоит новое оборудование для шлифовки слоев, чтобы получить хоть один рабочий прототип с более-менее разумным тепловыделением Изображение.

Потому все fabless-разработчики сейчас такие невеселые Изображение. Вспомнить NVIDIA, которая, по-моему, просто пожалела в свое время денюжков на дополнительный прогон промежуточного дизайна NV30. Или бедную Трансмету, которая со своей $100 млн. капитализацией, наверно, дьяволу душу продала, чтобы получить 90 нм прототип ТМ8800 у Fujitsu Изображение Вот где виртуозы! Потому как один лишний промежуточный комплект фотомасок их просто загонит в гроб Изображение
А вы про Интел или АМД, у которых и команд разработчиков по несколько, и денег как у дурака фантиков на промежуточные прототипы. Мне кажется, крайние тут все же маркетологи, которые уже вбухали в стратегиеское раскручивание того же Нетбурста свой... эээ... авторитет, так наверно? И отступать тяжело.
<font class="off">saigon
написано 28.09.2004 07:15
Ага, попался! Изображение</font>

А вы про Интел или АМД, у которых и команд разработчиков по несколько, и денег как у дурака фантиков на промежуточные прототипы. Мне кажется, крайние тут все же маркетологи, которые уже вбухали в стратегиеское раскручивание того же Нетбурста свой... эээ... авторитет, так наверно? И отступать тяжело.
Ну, и фантиков (тем более свободных) у них не так много (особенно у АМД), и дело даже не в авторитете, думаю. Думаю, Интел всерьез рассчитывала на рост частот у Прескотта до 5 — 6ГГц... Тогда года на два сражений его хватило бы, а там и новое ядро подоспело бы. А 90нм процесс подкинул каку — слишком горячий, слишком мала частота. Вот и приходится изворачиваться, запуская те козыри, которые должны были сыграть позже.
В самом деле, представим себе, что проблем с 90нм нет, и Прескотт легко и быстро набирает частоту. Тогда нынешним К8 противостоял бы Прескотт 4ГГц, к тому же еще и на новой платформе. И незачем было бы тогда поддерживать ЕМ64Т — кому бы она была нужна, если бы П4 был заметно быстрее в х86-32?
saigon
По-моему, все же больше, а если еще вспомнить о покупке и амортизации оборудования... То есть, не "доходить до 25 лимонов", а превышать.
Стоимость может как и доходить, так и превышать. Вполне допускаю. Это уж от конкретного случая зависит.
К тому же если разложить по цепочке весь путь — архи->верификация->физдиз->валидация->прототип, то львиную долю как по времени, так и по деньгам съедает верификация — порядка 50%. Так что можно как и уложиться, так и нет.
А быть фэблес не так уж плохо иногда, там и свои положительные стороны есть.

matik
В самом деле, представим себе, что проблем с 90нм нет
У интел, ИМХО, проблемы скорее с дизайном, а не с 90нм — совершенно новый дизайн наложенный на новый техпроцесс, ведь у АМД же плавный переход случился — по сути только внедрили 90нм.
Хм. Что-то разговор, кажется, зашел в область предположений...

Мы тут про архитектуры? Тогда выдвигаю идею в порядке бреда:

А что ЕСЛИ двухядерный процессор в стиле Transmet'овских? При этом code morphing крутится на одном ядре (со своей, предположим, небольшой памятью), а оттранслированный нативный код — на другом. Плюс, большой (мега 2-4) кэш для переработанного кода.

Плюсы — думаю, что на чистом родном коде VLIW ядро должно работать очень неплохо, если оно и при участии code morphing ухитряется какие-то значимые результаты выдавать. Энергопотребление — смешное, площадь кристалла (себестоимость) — сами знаете. И, вдобавок, никаких проблем с расширениями системы команд. Переписал версию code morphing и вперед.
Stranger_NN
Энергопотребление — смешное
Боюсь, что как раз эта характеристика в конечном итоге тесно связана со скоростью... То есть, быстрое ядро будет и нагреваться больше.
matik, хм. Давай прикинем. Сейчас, фактически, процессоры Transmeta выполняют двойную работу для каждого приложения. Сначала перерабатывают x86 код во внутреннее VLIW представление, и затем выполняют собственно логику приложения. Судя по моему опыту общения с кроссплатформенными эмуляторами — потеря производительности по ср. с нативными кодами как минимум 50-70%, т.е., есть основания предположить, что при использовании двухядерного процессора с вынесением задачи декодирования на отдельное ядро (при условии обеспечения максимальной производительности "декодера"*) производительность вырастет раза в два-три, как минимум, при сохранении потребления в несколько раз меньше существующих топовых процессоров.

Ну, и плюс, полнейшая гибкость в использовании программных расширений типа SSE<X>. И, разумеется, при желании можно использовать программу декодирования рассчитанную на "переработку" вообще не х86 кода.

Понятно, что задержка в тактах при подаче единичной команды будет довольно велика, но в установившемся режиме (на потоке, или после завершения декодирования цикла и размещения его в нативном виде в кэше команд "исполнительного" ядра)если удастся обеспечить максимально возможную загрузку 256(и почему бы не 512?)-разрядного "исполнительного" ядра — за один такт можно будет получать довольно много результатов х86 команд.

Кстати, еще один момент. "Декодирующее" ядро вовсе не обязано быть таким же, как исполнительное. Может быть, его будет иметь резон выполнить меньшей разрядности, но, например, большей частоты. Тут, конечно, нужно очень много считать — но теоретически такое возможно.

----------------------
* — Ну, например, так: ядро, загруженное задачей декодирования имеет собственную память фиксированного размера (по принципам Гарвардской архитектуры), для размещения декодирующего ПО (скажем, 2Mb 1T-SRAM)чтобы исполнение программы декодирования не загружала ни кэши, ни шину памяти системы. Кэш инструкций (декодированных) у второго ядра (исполнительного) д.б. максимально большим, чтобы в него уверенно помещались несколько областей локальности задач
Stranger_NN

<I> Кэш инструкций (декодированных) у второго ядра (исполнительного) д.б. максимально большим, чтобы в него уверенно помещались несколько областей локальности задач
</I>

Угу, это точно. У нынешних эффичеонов он составляет по слухам порядка 20 Мб, правда, размещается в оперативке.

Если перенести это счастье на кристалл, да выделить отдельное ядро для декодера команд (нахрен! Изображение), да сделать 512-битную внутреннюю разрядность VLIW — нафига там какие-то частоты поднимать, шапками их Изображение
saigon, ok. Пускай вместо привычного уже 2М кэша (пока не норма, но уже не ого-го) будет 12мег 1T-SRAM (так вроде по количеству транзисторов выходит? Ну, пускай, 10...).

Кроме того, если у нас декодированием будет заниматься отдельное ядро, то некоторое сокращение кэша декодированных инструкций (и возросшая нагрузка по их декодированию) — вполне будут скомпенсированы. Тем более, что выборка готового кода будет происходить несоизмеримо быстрее.

Если сумею выкружить дома машинное время (сына согнать с компа Изображение ) — завтра выложу идейку в графическом виде.

-----------------
я правильно идентифицировал человека за ником? Изображение Судя по почтовому адресу — да. Welcome!
Stranger_NN
я правильно идентифицировал человека за ником?Судя по почтовому адресу — да. Welcome!

Надеюсь, что правильно, но спасибо, что напомнил, что данные надо поменять, потому как они у меня с июня уже были недействительны Изображение
saigon, ну, собственно, и по этому адресу тот же человек. Изображение
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Stranger_NN:
процессоры Transmeta выполняют двойную работу для каждого приложения. Сначала перерабатывают x86 код во внутреннее VLIW представление, и затем выполняют собственно логику приложения.</SPAN><HR size=22></SPAN></BLOCKQUOTE>
Если это действительно так, то — идиотизм полный... Изображение
Преимущества VLIW теряются полностью... Изображение
U2:
Фундаментальный пост Изображение
Даже не знаю, стоит ли отвечать...
Ну, пока "по ведению":

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

не совсем это. Тем более что развитие-то как раз и не замедлялось IMHO (пока по крайней мере).
Другое дело, что развитие это идет по экстенсивному пути, а физические пределы этого пути уже очень близки. Мне же хочется дожить до производительности 10^23 (--- профессиональный интерес Ж)).
Freescale discloses high-performance dual core processor architecture

http://www .freescale.com/ ....
http://www.siliconstrategies.com/article/showArticle. jhtml?articleId=47903267
http://www.infoworld.com/article/04/09/28/HNfreescale_1.html
http://www.extremetech.com/article2/0,1558,1656159,00.asp

[Исправлено: [test] : 30-09-2004 15:03]

[Исправлено: [test] : 30-09-2004 15:05]
Warrax, отнюдь не идиотизм. Это хороший способ сэкономить транзисторы и, соответственно, цену и энергопотребление. Фактически, все современные процессоры так или иначе транслируют поступающий код во внутреннее представление, но "железные" декодеры очень "дороги" в плане транзисторов, сложности и потребления. Программное же декодирование на том же ядре, что используется для исполнения программы — увы, приводит к ощутимому падению производительности. Да и наличие буфера декодированных команд в ОЗУ позволяет не каждый раз проделывать двойную работу по преобразованию кода. Тем более, что, конкретно, в случае Transmeta — "транслятор" весьма оптимизирован, да и результирующий код, как я понимаю, весьма плотно ложится на ядро.

С другой стороны, опыт подсказывает, что каждая команда х86 обычно преобразуется в достаточно большое количество микрокоманд, что приводит к ОЧЕНЬ большой нагрузке на память при выборке из нее оттранслированного нативного кода.

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

Вот грубое изложение моей идеи:

Изображение

Парочка пояснений:
1. Декодирующее ядро, естественно, не содержит устройств для работы с плавающей точкой.
2. При декодировании команды ее данные автоматически загружаются декодирующим ядром в кэш исполнительного ядра.
3. Разумеется, код транслятора может обрабатывать не только x86 код, дело только в размере памяти для транслятора. Поэтому проблему программной совместимости можно считать закрытой.

Разумеется, напрашивается интересная идея писать сразу в нативных кодах процессора, и, возможно, некоторые куски программ и имеет смысл так оформлять (как сейчас пишут на ассемблере критичные куски кода), но в целом программу выгоднее писать на относительно "высокоуровневом" языке, с целью экономии как размера памяти, так и ее пропускной способности.
saigon, неплохо, с одной стороны, но это просто-напросто экстенсивное развитие. Тоньше техпроцесс, больше ядер на кристалл, больше частота..
Stranger_NN
Согласен, ничего особенного нового, шина, контроллер памяти, Altivec — просто в другом замесе.

Это я просто так, подумал, что можно бы новую инфу по теме сюда складывать, мне ее все равно девать пока некуда, а профессиональный зуд по привычке каждое утро выгоняет на поиски Изображение
saigon, ах даже так? Тогда есть тема на поговорить......
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Stranger_NN:
Warrax, отнюдь не идиотизм. </SPAN><HR size=22></SPAN></BLOCKQUOTE>
Безусловно, в случае с любой архитектурой... Изображение но кроме VLIW... Изображение
Ведь основная идея VLIW — частичный перенос задач с планировщика ОС на компилятор.
То есть, еще при компиляции кода ПО заполняются соответствующие поля. Так как компиляция выполняется
не в риал-тайм (разработчики могут и подождать пару минут), то можна использовать высокий уровень
оптимизации кода (в контексте планирования выполнения).
В описанном же случае данную работу будет делать не компилятор (не ограниченный во времени), а некий блок процессора и будет он это делать неоптимально, т.к. должен использовать быстрые (неоптимальные с точки зрения дальнейшего выполнения) алгоритмы, иначе данный блок будет самым узким местом.
Warrax
Ведь основная идея VLIW — частичный перенос задач с планировщика ОС на компилятор.
а что вас с этой точки зрения не устраивает в вариантеStranger_NN? Как раз декодирующий процессор и будет в данном случае выполнять функцию компилятора для участков кода.
и будет он это делать неоптимально
вопрос насколько. если он будет в разы неоптимальнее чем статические компиляторы — да идея в плане быстродействия провалиться, а если на 10-15%?
Warrax, стоп. Вы путаете EPIC и VLIW. Использование сверхдлинного слова и использование явного паралеллизма — вещи совершенно независимые. Вполне можно использовать явный параллелизм и в рамках традиционных процессорных систем, естетственно, это имеет смысл только при способности процессора выполнять задачи параллельно (HTT-, SMP-, multicore — системы).

Точно так же VLIW процессоры совершенно не обязаны работать параллельно. В конце-концов, это может быть т.н. векторная обработка, SIMD. Никакой ПРЕДВАРИТЕЛЬНОЙ параллельности там может и не быть.

Другое дело, что для оптимального использования VLIW-процессора требуется максимально высокое заполнение его ФУ полезными командами. Понятно, что сделать это на этапе компиляции проще. Но, при этом мы платим за "атоммарность" кода излишним количеством мегабайт памяти и повышенными требованиями к ПСП.

Предлагаемый вариант предусматривает, естественно, компиляцию до какого-то достаточно близкого к аппаратуре уровня (разумеется, с "расшивкой" всех возможных параллельностей и т.п.), типа x86 (так правильнее с т.з совместимости) но при сохранении приемлемого размера и читаемости кода. А вот сам процессор уже "докомпилирует" код в свое внутреннее представление. Естественно, эта задача проще, чем компиляция с ЯВУ, поэтому задержки будут (даже при программной реализации декодера) приемлемыми (обратите, кстати, внимание, что декодер — высокопараллельный процессор с идеально отлаженным и почти неизменяемым (т.е., предсказуемым) кодом, не нагружающий при работе системную шину) .

Кроме того, появляется возможность создания семейства совместимых процессоров совершенно разного уровня производительности (ширины и частот декодера и исполнительного ядра) — ведь мы не компилируем код до почти микрокоманд, как в IA64 (ну-ка, что будет с СУЩЕСТВУЮЩИМ под IA64 ПО при изменении длины слова??) , а позволяем и процессору "свое мнение иметь". Что добавляет структуре гибкости... Изображение
ISA_user, см. мой предыдущий пост.
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Stranger_NN:
Warrax, стоп. Вы путаете EPIC и VLIW. </SPAN><HR size=22></SPAN></BLOCKQUOTE>
По моему все, что есть в EPIC уже было придумано в рамках VLIW. Изображение
Интел только сделана первую массовую реализацию VLIW и придумала для нее новое название EPIC. Изображение
Stranger_NN
Тогда есть тема на поговорить......

<font class="off">Угу. Тока асю пока не включаю, несмотря на нагоняи от тов. Матика Изображение. Пока угнетает ася, осень в душе Изображение По крайней мере, до MPF 2004. Изображение

Мож, в мыл, если что?</font>
saigon, ну хотя бы на 5 минут в аську, потому что там уже кое-что лежит... И не от меня, поэтому даже продублировать мылом не смогу... Изображение Потом, конечно, можно мылом.

Warrax, нет разумеется. IA64 это всего лишь "один из" вариантов реализации VLIW концепций. Такие процессоры были и ДО IA64 (и одно время были очень популярны) и будут после (обратите внимание, что-то как-то заглохло с Итаниум, его классические процессоры уже уверенно догоняют при несравнимо меньших ценах).
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Stranger_NN:
Такие процессоры были и ДО IA64 (и одно время были очень популярны)
</SPAN><HR size=22></SPAN></BLOCKQUOTE>
Даже так? Не знал. И ЧТО ЭТО было?

<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Stranger_NN:
что-то как-то заглохло с Итаниум, его классические процессоры уже уверенно догоняют при несравнимо меньших ценах.</SPAN><HR size=22></SPAN></BLOCKQUOTE>
Так такая картина не только с Итаниумом.
Умерла Альфа, за ней явно пойдет PA-RISC и еще несколько. Остальных начинают теснить AMD&Intel (по бенчмаркам они уже многих догнали, а некоторых и перегнали Изображение ).
Просто остальные(Power,Sparc,...), в отличие от Итаниумов, уже ранее занимали какую-то приличную часть рынка серверов и им в этом отношении проще, к ним "привыкли" кое-кто из них все еще "на коне".
Но, наверно, массовые процессоры в ближайшем будущем от таких компаний как AMD и Intel, смогут потеснить "мэтров" не только в сегменте Entry Level серверов.
При чем в основном за счет стоимости.
Warrax:
1. См.:
http://www.ixbt.com/cpu/vliw.shtml
http://www.ixbt.com/cpu/crusoe.html
http://www.ixbt.com/cpu/ia64.html
— краткая, так сказать "вводная"..

2. На самом деле "играет" только параметр "цена/производительность". Я абсолютно ничего не имею против "старых" процессоров, но их разработчки по тем или иным причинам "потеряли темп", в то время как Intel AMD и, отчасти, другие игроки на рынке х86-совместимых систем времени не теряли. Ну и в результате имеем то, что имеем (не забывая, разумеется, про IBM с ее Power4/5 и множеством вариантов). Однако, Итаниум — детище Intel, и, если развития архитектуры как-то не видно, то есть резон предполагать, что "не все в порядке в Датском королевстве", и IA64 далеко не так гениальна.. Впрочем, как не странно, это было сказано еще несколько лет назад..
<BLOCKQUOTE><SPAN class=hquote>цитата:</SPAN><HR size=22><SPAN class=quote>Stranger_NN:
Однако, Итаниум — детище Intel, и, если развития архитектуры как-то не видно, то есть резон предполагать, что "не все в порядке в Датском королевстве", и IA64 далеко не так гениальна.. </SPAN><HR size=22></SPAN></BLOCKQUOTE>
Да не... Процессор хороший, а вот то, что вокруг него... "Я его слепила из того что было..." Изображение
Сами же говорили, что VLIW потребует большей ПСП, а у Итаниума всего 400МГц, и то в QP.
Да и "Вообще, быстродействие VLIW-процессора в большей степени зависит от компилятора, нежели от аппаратуры, поскольку здесь эффект от оптимизации последовательности операций превышает результат, возникающий от повышения частоты."
А вот с хорошими компиляторами сейчас туго явно не только в IA-64 Изображение
Смещение приоритетов в сторону ЯВУ (вполне логичное) явно этому способствует.

Все как в бородатом анекдоте:
"— Я не понимаю одного — почему не сыграл мой козырный туз?
— Раскладец, батенька! Раскладец!" Изображение
Новая тема    Ответить  [ Сообщений: 191 ]  На страницу 1, 2, 3, 4, 5  След.


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Удалить cookies конференции

Пишите нам | Radeon.ru