Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вот про такие ситуации, когда надо "не в принципе, а конкретно", 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, "жесткая" диаграмма обеспечена.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

А говорил при ответе на вопрос, почему транзисторная 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 такой сделала для серверов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

ладони....

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

 

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...