[bzx 0]

Или они решили забить на линейку AVR32?

Ага, у Атмеля денег дофига, что ему стоить потратиться на разработку ядра avr32 и начать промышленный выпуск. Или по Вашему они удачно пыль в глаза пускают? Тут 32х-битники потихоньку съёдают 8 битники, поэтому и у avr32 будет, по моему, такой же пик популярности как и у avr8, скорее свего, это да же не 2008, а как минимум 2009.

[zltigo 2]

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

:) :) :) Атмел лихорадочно ищет крупных и очень крупных потребителей любой продукции, которую в состоянии произвести. Именно промышленный выпуск не будет начат без таких потребителей никогда. Только вот и другие без дела не сидят - явно многие потребители и производители софта клюнули на младшие Corteх и соответственно Atmel тоже анонсировал сие. Для лидеров этой отрасли сваять ядро приципив нему джентельменский набор периферии особых проблем не представляет, а вот найти стратегического (не нас с Ваим :) )покупателя - это уже тяжело :( и без удачи тут никак.

[proba 0]

все проблемы Атмел начинаются и кончаются здесь:

http://www.advfn.com/nasdaq/StockPrice.asp?stockprice=ATML

[defunct 0]

все проблемы Атмел начинаются и кончаются здесь:

http://www.advfn.com/nasdaq/StockPrice.asp?stockprice=ATML

Дела у них не столь плохи.

Это у всех американских компаний сейчас такая ситуация, связанная с падением USD...

[bzx 0]

Это у всех американских компаний сейчас такая ситуация, связанная с падением USD...

В рецессии Америка...

[SIA 0]

:) :) :) Атмел лихорадочно ищет крупных и очень крупных потребителей любой продукции, которую в состоянии произвести. Именно промышленный выпуск не будет начат без таких потребителей никогда. Только вот и другие без дела не сидят - явно многие потребители и производители софта клюнули на младшие Corteх и соответственно Atmel тоже анонсировал сие. Для лидеров этой отрасли сваять ядро приципив нему джентельменский набор периферии особых проблем не представляет, а вот найти стратегического (не нас с Ваим :) )покупателя - это уже тяжело :( и без удачи тут никак.

Именно так. Ключ к успеху - маркетинг, а не техническая рациональность или изощренность.

А дальше - закон снежного кома. Помним историю х86? Сама Intel, понимая ее кривость, еще "в те времена" дважды пыталась перейти на другую архитектуру - не вышло.

Motorola с реально хорошими 68К - по большому счету пролетела. Мало сбыта - высокая цена - мало сбыта - нет средств на совершенствование - закрытие темы....

Я и про MIPS (наступавший на те же грабли - неумение продавать реально хороший товар) вспомнил здесь только потому, что

а) люди в MIPS Technology похоже, таки маленько поумнели (занялись периферией, "голый" проц редко кому нужен, как бы ни был сам по себе хорош), и, главное (!)

Б) за маркетинг взялся Microchip, а у них это поставлено всегда было куда лучше, чем у Atmel :) Соответственно, и развитие темы будет, и MIPS поможет :)

[zltigo 2]

Именно так. Ключ к успеху - маркетинг, а не техническая рациональность или изощренность.

Только вот судя по лихорадке с маркетологами у Atmel просто никак :(. Ибо "-Девушка, что Вы делаете сегодня вечером? -Все" это не маркетинг :), это другое...

[SIA 0]

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

Вот про такие ситуации, когда надо "не в принципе, а конкретно", Saymor Cray и любил говорить "Машина, про которую нельзя точно сказать, что она будет делать в каждый машинный такт - в реальном мире неконкурентоспособна по определению. Даже если она и быстра в принципе, то на практике часто подобна сороконожке в припадке эпилепсии" ;).

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

 

A=aaa;

for (i=xxx;i>=0;i--)

{

B=C+D*E;

A+=B;

};

 

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

В результате проц не покажет и 1/5 скорости от той, что мог бы в теории при параллельном запуске ветвей в конвейер и совмещению суммирований.

В процах Intel/AMD это пытается разгребать аппаратура. С переменным успехом и жутким (по сравнению с собственно АЛУ) энергопотреблением.

Плюс непредсказуемость точного времени выполнения вообще. Оно в рилтайме надо ?

 

p.s. в ядрах MIPS, как и во многих других, особенно DSP, но почему-то далеко не во всех ARM, "жесткая" диаграмма обеспечена.

[Rst7 5]

Saymor Cray и любил говорить "Машина, про которую нельзя точно сказать, что она будет делать в каждый машинный такт - в реальном мире неконкурентоспособна по определению. Даже если она и быстра в принципе, то на практике подобна сороконожке в припадке эпилепсии".

 

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

[zltigo 2]

Saymor Cray и любил говорить...

Да семидесятые годы прошлого века. Лобовое решение за государственные денюжки - 80Mhz 64Bit очень круто. Но давно мир переменился. Переменился даже спустя 10 лет - Cray2 был многопроцессорный и судя по цитате страдал не только эпилепсией, но и шизофренией с размножением личности :).

[SIA 0]

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

Времена безумно давние, нас тогда на свете не было.

А говорил при ответе на вопрос, почему транзисторная CDC6600 1964 года работает быстрее микросхемной IBM360/91 68-го :)

IBM по указанию своего президента купила экземпляр CDC6600 для исследований. Но это не помогло - следующее детище CDC - CDC7600 - оставило всех "с носом" и держало "голубую ленту" 8 лет. Тоже чисто транзисторная была машина (10...30 Мфлопс в зависимости от задачи). Дальше были уже Cray.

 

Да семидесятые годы прошлого века. Лобовое решение за государственные денюжки - 80Mhz 64Bit очень круто. Но давно мир переменился. Переменился даже спустя 10 лет - Cray2 был многопроцессорный и судя по всему страдал не только эпилепсией, но и шизофренией с размножением личности :).

Нет, как раз не лобовое. Лобовое - это ILLIAC. И не на государственные денюжки (госзаказ из Ливермора пришел потом, после успешной демонстрации - более 100 Мфлопс на реальной задаче, при том что в описании обещалось "up to 80"). До этого Крэю пришлось все делать "на свои" (для чего пришлось продать свою долю в СDC). Все делали сами - и микросхемы (топологию ИС) рисовали, и схемы, и платы, и документацию. Весь коллектив создателей Cray1, при том, что это была разработка с нуля - от элементной базы включительно - меньше 20 человек, и денег было в обрез, экономили даже на рубилите (15 баксов лист - в 1975 году это были ДЕНЬГИ).

Зато продавались Cray как горячие пирожки именно потому, что цена выполненной полезной операции у машин Cray до начала 90-тых была наименьшей на рынке.

Плюс отличный компилятор, мало проигрывавший в циклах "ручному" коду, а местами и обставлявший его на распараллеливании.

До 90 года даже массовый ПК давал много меньше 1К флопс на доллар при несравнимых прочих характеристиках (у Cray Y-MP в те годы было ~ 800 флопс на доллар).

Сейчас самый дешевый полноценный (64-битный) флопс получается на MIPS64 и некоторых Power PC (IBM750СL ~$25 за Гфлопс).

 

p.s. Жесткая (предсказуемая) временная диаграмма - необходимое условие нормальной работы любого WLIW/EPIC процессора. Даже Intel такой сделала для серверов.

[zltigo 2]

Времена безумно давние, нас тогда на свете не было.

Посему не стоит серьезно относится к мемуарной литературе.

[SapegoAL 0]

Жесткая (предсказуемая) временная диаграмма - необходимое условие нормальной работы любого WLIW процессора. Даже Intel такой сделала для серверов.

 

Даже самые продвинутые ошибаются (я про Saymor Cray). Не жёсткая и непредсказуемая временная диаграмма уже победила. Оглянитесь вокруг. Но это только начало долгого пути.

 

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

 

Так что к чёрту ностальжи - двигаем вперёд! Я, например, хотел бы поработать с многопроцессорными системами и побороться с непредсказуемостью. :)

[singlskv 0]

Так что к чёрту ностальжи - двигаем вперёд! Я, например, хотел бы поработать с многопроцессорными системами и побороться с непредсказуемостью. :)

Дык кто Вам мешает ?

ИМХО, ну начните с многопоточных приложений под windows, там все проблеммы как на

ладони....

Те если хочеш рабочую прогу то разобраться с многопоточностью придется....

 

 

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

Ну если не видите причин...

Предлагаю Вам проект вывода графики на телик(телеметрия например...)

Какой АРМ выберем ? Как будем выводить ?

[SIA 0]

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

Вроде обсуждение было про контроллеры, я и говорю за рилтайм. В остальных приложениях это не так важно (есть способы обхода).

 

А насчет "сложности компиляторов" - к сожалению, дело не в "программных технологиях" как таковых (кстати, компилятор для практически любой машины уже давно научились писать за разумные сроки, особенно после работ Гриса, Ахо/Ульмана и появления Lex/Yacc). Компилятор чистого С на них делается не больше, чем за месяц, дальше - "раскрутка" (трансляция написанного на С С++), и пошло-поехало. Задачу оптимальной раскладки регистров решил еще Ершов :) И "параллельных" языков довольно много (см. по ссылке в конце).

 

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

 

Для справки, "железо" параллельным было практически с самого начала компьютерной эпохи, к примеру, многопоточным (10 аппаратных тредов) был уже более 40 лет назад фронт-енд процессор для CDC6600 (которая была, таким образом, "несимметричной мультипроцессорной системой с общей памятью"). Так что "все украдено и придумано до нас", остается только правильно воспользоваться :)

 

А прорыв, кстати, уже есть, и именно для WLIW/EPIC, где есть жесткая диаграмма, которую компилятор может учесть при планировании трасс. Началось все с проекта Multiflow в 1980-х, затем доведено до живого продукта Дитцелом и компанией в Transmeta.

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

 

Идея именно в том, чтобы убрать из процессора дающую большие задержки логику планирования команд/загрузок/отслеживания конфликтов и фактически оставить только набор АЛУ/память, все планирование выполняет компилятор, генерирующий "длинные" команды для прямого управления аппаратурой. Кстати, примерно так (и по тем же самым причинам) и были сделаны крэевские машины, особенно последние, разработанные при его непосредственном участии.

Так что идея не устарела и вполне здравая. Похожим образом делаются как самые мощные DSP TMS, так и "бытовые" зверушки PNX1300/1500/1700.

 

На рынок ПК эта технология в полной мере вряд ли придет скоро. Проблема и в маркетинге, и в технике. Первое, при таком подходе нет 100% бинарной совместимости. Нужна перекомпиляция (пусть даже и "невидимая" для пользователя). Но желательно, с анализом исходника. Техническая проблема - для реализации достигаемого выигрыша в быстродействии для больших объемов данных предъявляются более высокие требования к пропускным способностям подсистем памяти. Т.е. нужна куча DIMM, чтобы был эффект - кеши не всесильны, их грузить откуда-то надо и быстро. А если всего этого нет и хочется оставить х86 бинарную совместимость, без анализа исходников - то получится Crusoe со всеми его недостатками (экономичный, но более-менее быстрый только на "родном" коде).

Для мощных же контроллеров с большими вычислительными возможностями - вполне то, что надо. Собственно, упомянутые PNX - и есть такие контроллеры.

 

За чисто параллельные и многопроцессорные вещи - это скорее в www.parallel.ru ;)