ПАК ФА (Т-50)
4,700,504
6,042
ОТВЕТЫ (74)
|
GeorgV ( Слушатель ) |
| 18 авг 2013 19:16:36 |
Цитата: bca от 18.08.2013 14:27:07
А что тогда считалось 'большим об'емом памяти и высоким быстродействием'? Относительно обсчета информации с картографа в реальном времени.
|
bca ( Слушатель ) |
| 18 авг 2013 21:57:51 |
Цитата: GeorgV от 18.08.2013 19:16:36
Приведу Вам данные на память...
Управление комплексом М-100 на Су-24МР осуществлялось БЦВМ (Изд М-104).Состав: процессор,ОЗУ,ПЗУ,блок питания.Вес ОЗУ,ПЗУ и процессора - где-то около 5 кг,блок питания - около трехи кг .Рама, на которой все это монтировалось еще пару кг.Емкость ОЗУ - около 70 кбайт,ПЗУ - 130кбайт.Скорость процессора не помню.Можно на пАльцах прикинуть сколько весила бы БЦВМ для формирования "картинки" весом так 1 Мбайт...Камрады,все приведено по моей памяти,но если ошибся,то не сильно.
|
|
GeorgV ( Слушатель ) |
| 19 авг 2013 04:24:18 |
Цитата: bca от 18.08.2013 21:57:51
Спасибо. Ну, теперь в те же массо-габариты влезает вычислительный комплек с характеристиками 'из другой галактики'.
|
|
mse ( Специалист ) |
| 18 авг 2013 23:32:02 |
Какой-нить клон 486, сотню-две Мгц. Щас-то ДСПшники полугиговые, 32р, однотактные, суперскалярные да многоядерные...Цитата: GeorgV от 18.08.2013 19:16:36
|
|
mse ( Специалист ) |
| 19 авг 2013 00:21:17 |
А! Не уловил временнОй масштаб. Я тут о начале-середине 2000-х... Там то-ли перепиленые были, то-лиЦитата: rororo от 18.08.2013 23:59:20
|
|
mse ( Специалист ) |
| 19 авг 2013 10:56:02 |
При чём здесь СССР? Вот, например., вот... Есть ещё всякая экзотика, типа "мультиклета", но те без специсполнения, ИМХО.Цитата: marrakesh от 19.08.2013 00:07:18
|
marrakesh ( Специалист ) |
| 19 авг 2013 13:45:25 |
Цитата: mse от 19.08.2013 10:56:02
Про "сейчас" я как-бы в курсе
Но речь то шла про Су-24МР. Лётные испытания начались в сентябре 1980 года, а на вооружение самолёт принят в 1984 году. С 1985 года начались поставки в ВВС. Тогда вообще были только аналоги 8086 и 8088
|
dc93 ( Слушатель ) |
| 19 авг 2013 14:28:56 |
Цитата: marrakesh от 19.08.2013 13:45:25
А сейчас бы я вообще какойнибудь ARM многоядерный ставил, на таком картинки обсчитывать -- просто прелесть какая-то.
|
|
Удаленный пользователь |
| 19 авг 2013 15:49:43 |
Цитата: dc93 от 19.08.2013 14:28:56
Картинки- это поиграться в игрушки ...там будет прелесть.(представляю Лётчика со смартфоном- сразу К36 нужно использовать...да его врачи не допустят просто )
PS 8086 (согласен на 486) круче любого Фенома , хоть с со 100500 ядрами (ARM-тем паче....игрулька)
|
|
dc93 ( Слушатель ) |
| 19 авг 2013 16:44:35 |
Цитата: OlegNZH_ от 19.08.2013 15:49:43
ARM -- это прежде всего RISC,
RISC -- это прежде всего одна команда за один такт (грубо), это фиксированная длина команды.
поиграться в игрушки и обработать картинку -- противоположные понятия.
Смартфоны применяют RISC (ARM) прежде всего из-за малого потребления.
Цитата: OlegNZH_ от 19.08.2013 15:49:43
это когда же CISCи для специализированных задач стали круче RISCов? и почему AMD Phenom приводится в качестве RISC процессора?
или я чего-то не понял?
любой современный ARM, даже работающей на той-же частоте, что и 486, в задачах числодробилки порвет последнего как тузик грелку
|
|
GeorgV ( Слушатель ) |
| 19 авг 2013 17:07:40 |
Цитата: dc93 от 19.08.2013 16:44:35
Насколько я помню, разница между Risc и Vliw (c точки зрения производительности) практически исчезла. Нет?
|
slavae ( Слушатель ) |
| 19 авг 2013 17:26:24 |
У меня телефон Lenovo K900 на Интеловском Атоме. У него 2 ядра, производительность в Андроиде на уровне 4хядерных топов АРМ.Цитата: GeorgV от 19.08.2013 17:07:40
|
|
dc93 ( Слушатель ) |
| 19 авг 2013 18:10:10 |
Цитата: GeorgV от 19.08.2013 17:07:40
я не считаю себя спецом, но в данном случаем, имхо, Вы сравниваете "теплое с мягким".
Это просто распараллеливание, причем, почему-то, только для RISC, в языке есть команды явно указывающие какому "ядру" что делать, разумеется такой "многоядерный" RISC будет пахать быстрее, но програмить под него сложнее в силу того, что надо не ошибиться с "маршрутизацие трафика".
но это всеравно RISC, кстати, в VLIW инструкция всеравно всегда одной длины
Всё, я заканчиваю, мы совсем в офф-топ скатились
|
|
Maxzz. ( Слушатель ) |
| 19 авг 2013 17:14:14 |
Цитата: dc93 от 19.08.2013 16:44:35
Я бы не стал утверждать столь категорично. ARMы, они, разные бывают.
В задачах же обработки видеоизображений кастомный спецпроцессор, даже на базе FPGA, как бы не на порядки быстрее.
|
|
dc93 ( Слушатель ) |
| 19 авг 2013 17:48:06 |
Цитата: Maxzz. от 19.08.2013 17:14:14
на сколько я понял задачу, необходимо обрабатывать не видеоизображение, а совсем даже стоячую картинку.
специализированные "видеопроцессоры" занимаются совсем другой задачей, а именно "искажают" уже полученную картинку в соответствии с замыслом режиссера, что на порядки сложнее.
в данном случае необходимо оцифровать картинку и найти на ней интересующие нас флуктуации, возможно, что даже в соответствии с шаблоном. Т.е. никакой арифметики с плавающей точкой, даже никакого деления, а тупо поразрядное И.
Возможно, что кастомный спецпроцессор и будет лучше, но в результате получится все тот же RISC с совсем усеченным набором команд, а вот на много ли он будет быстрее -- это уже вопрос, если толлько хза счет бешенной разрядности. Может в данном случае этого и не понадобится, м.б. уже готовые решения дадут приемлемый результат, тем более, что в данных задачах количество ядер работающих параллельно играет очень большую роль.
ЗЫ убрать прыщик в фотошопе, по сравнению с данной задачей -- на пару порядков сложнее
|
|
Maxzz. ( Слушатель ) |
| 19 авг 2013 18:16:09 |
Цитата: dc93 от 19.08.2013 17:48:06
Нет, Вы слабо представляете принцип работы подобных спецпроцессоров. В отличие от процессоров общего назначения, у которых есть, в зависимости от архитектуры, шины адреса/команд/данных и проч., и который выполняет обработку данных в соответствии с программой, алгоритм обработки данных в спецпроцессоре может быть задан жестко, на уровне логики, в результате чего на обработку каждого нового значения с АЦП можно тратить вообще один такт конвейера (в идеальном случае) в отличие от десятков/сотен на процессоре общего назначения.
|
ivan2 ( Слушатель ) |
| 19 авг 2013 18:21:13 |
Цитата: dc93 от 19.08.2013 17:48:06
Заблуждаетесь. Нейти наиболее похожие на эталон (шаблон), это вычислить коэффициенты корреляции каждого из участков изображения с шаблоном, а потом отранжировать их. Самый тупой способ. Есть более затратные в вычислительном смысле. Правильнее сказать в алгоритмическом смысле.
Вычисление коэффициента корреляции, это операции умножения со сложением с учётом знака. Можно делать целочисленно, возникают проблемы с переполнением аккумулятора. Можно в формате с плавающей точкой, летит к чертям производительность. По старому - заполняете входные регистры операндами и операцией, указываете куда положить результат. По программному прерыванию ждёте, когда сопроцессор плавающей точки закончит и вызовет это самое прерывание. По получении управления после прерывания продолжите...
Конвейеры, параллелизм - задачи для алгоритмистов и математиков. Аппаратно реализуется очень узкий класс алгоритмов. Это очень сложно и это ВЫСОКИЙ КЛАСС.
|
|
mse ( Специалист ) |
| 19 авг 2013 18:40:52 |
Это вы со зла сказали. ;О) Базовая операция ЦОС, это МАС(multiplication-accumulate). Что характерно, достаточно часто бывает нужно работать с плывучкой. И двумерная обработка, это трэшевый угар из МАСов. Деления, да, нет. В таких кол-вах.Цитата: dc93 от 19.08.2013 17:48:06
|
Harsky ( Слушатель ) |
| 19 авг 2013 19:48:41 |
Цитата: dc93 от 19.08.2013 17:48:06
Будет быстрее и очень существенно. И дело даже не в разрядности и числе ядер - это вторично.
DSP для обработки видео имеет возможность содержать тысячи (обработка видео почти всегда отлично распараллеливается) однотипных вычислительных устройств, заточенных на выполнение нескольких примитивных операций, чего процессор общего назначения позволить себе не может.
В принципе, любая современная видеокарта имеет всё что нужно не только для отрисовки картинки, но и для всяческих преобразований. И видеопроцессоры у нее с тысячами вычислительных устройств. Даже ничего изобретать не требуется, вопрос в выпуске в военном исполнении
|
|
ivan2 ( Слушатель ) |
| 19 авг 2013 20:08:25 |
Цитата: Harsky от 19.08.2013 19:48:41
Мне кажется Вы смешиваете задачи формирования/ужимания - разжимания/отрисовки изображения и путаете их с задачами формирования и отрисовки обстановке не просто на экране РЛС, а в каком-нибудь боевом комплексе.
Видеокарта безусловно мощнейший инструмент, но мощнейший в смысле "разжимания" на миллионах экранов того, что "сжато" совершенно другими, на много порядков более мощными единичными средствами.
Тем не менее бортовая РЛС бокового обзора с синтезтрованной апертурой с обработкой на борту на истребитель вполне реальна. И, если доставить на пару взаимодействующих бортов единую фазу, можно будет ещё чего наворотить. Это не будет бистатика в наземном понимании. Но, что-то квази... получится.
Работать надо. ПЫТАТЬСЯ.
|
|
Harsky ( Слушатель ) |
| 19 авг 2013 20:23:51 |
Цитата: ivan2 от 19.08.2013 20:08:25
Все уже давно не так. На современных GPU считают сложные молекулы, ищут инопланетные сигналы (@SETI), перебирают шифры и много чего еще. Поищите в сети на тему Kepler, Tesla, CUDA. Фактически современные GPU превратились из DSP в простые системы с массовым параллелизмом. На каждом из тысяч узлов можно и умножение со сдвигом сделать и цикл покрутить.
|
|
ivan2 ( Слушатель ) |
| 19 авг 2013 20:29:34 |
Цитата: Harsky от 19.08.2013 20:23:51
Да не сомневаюсь я в этом. Вы забыли про простое (
). Через сколько часов удаётся свести воедино и предоставить пользователю/потребителю сигналы от систем с массовым параллелизмом?
|
|
Harsky ( Слушатель ) |
| 19 авг 2013 20:35:23 |
Цитата: ivan2 от 19.08.2013 20:29:34
Чего там сводить-то? все в общей памяти живет.
Не хотите почитать - ради бога, людям это не мешает терафлопсы на столе иметь.
|
|
ivan2 ( Слушатель ) |
| 19 авг 2013 21:18:40 |
Цитата: Harsky от 19.08.2013 20:35:23
Ух как!
Есть такой анекдот.
Приходит Мехлис к Сталину в августе 1941 года и говорит:"Товарищ Сталин, я знаю, как победить Фашистскую Германию."
Сталин, ходит по кабинету в мягких сапожках, достаёт из пачки папиросу Герцеговина Флор, ломает её, утрамбовывает табак в трубку, закуривает.
- И как же, товарищ Мехлис?
- Надо Вам на стол установить большую красную кнопку. Вы на неё нажмёте, ставка Гитлера взорвётся, ... Фашизм будет побеждён!
Сталин раскуривает трубку, похаживает по кабинету в мягких сапожках, думает...
- Товарищ Мехлис, эту кнопку надо через провода подключить к фугасу, который необходимо заложить под Рейхсканцелярию...?
- Товарищ Сталин, этой х...нёй пусть инженеры занимаются!
Есть другой анекдот, - чем больше "информации", тем лучше, всё в общей памяти живёт. А разбираться с ней - х...ня, которой пусть инженеры и математики занимаются.
|
|
Harsky ( Слушатель ) |
| 19 авг 2013 22:40:44 |
Цитата: ivan2 от 19.08.2013 21:18:40
Вы сегодня явно не в духе, раз пытаетесь шутить на не смешные темы.
Что смешного в том, что вычислительные блоки работают на общем поле памяти, если скорость обмена с этой памятью несколько сотен Гб/с (без учета кэша)? нет, я конечно понимаю - блокировки, то, сё... Все это давно решено. Если мучают фантомные боли арбитража общей шины на частоте 1.3МГц и ограничения в 56Кб для основного процессора, то пора в реальный мир, пора
|
|
ivan2 ( Слушатель ) |
| 19 авг 2013 23:13:45 |
Возможно я Вас не понял. Вы сказали:
Я ответил:
"Да не сомневаюсь я в этом. Вы забыли про простое (). Через сколько часов удаётся свести воедино и предоставить пользователю/потребителю сигналы от систем с массовым параллелизмом?"
Вы парировали:
Парировали неудачно. Потому, что сумма вычислительных возможностей тех систем, на которые Вы ссылаетесь является силой ТОЛЬКО В АСИНХРОННОЙ ОБРАБОТКЕ.
Цифровая обработка сигналов в системах реального времени, если они реализуются многопоточным способом, требуют синхронности потоков.
Если синхронности нет, Вы должны реализовать систему поиска и удержания синхронизма в том несинхронном, а соответственно непонятном и НЕСКЛАДЫВАЕМОМ байтовом бреде, который валится в общую память.
С этого момента Вы уже перестали понимать то, о чём я говорю. На что я и обратил Ваше внимание анекдотом.
Цитата: Harsky от 19.08.2013 20:23:51
Я ответил:
"Да не сомневаюсь я в этом. Вы забыли про простое (
). Через сколько часов удаётся свести воедино и предоставить пользователю/потребителю сигналы от систем с массовым параллелизмом?"Вы парировали:
Цитата: Harsky от 19.08.2013 20:35:23
Парировали неудачно. Потому, что сумма вычислительных возможностей тех систем, на которые Вы ссылаетесь является силой ТОЛЬКО В АСИНХРОННОЙ ОБРАБОТКЕ.
Цифровая обработка сигналов в системах реального времени, если они реализуются многопоточным способом, требуют синхронности потоков.
Если синхронности нет, Вы должны реализовать систему поиска и удержания синхронизма в том несинхронном, а соответственно непонятном и НЕСКЛАДЫВАЕМОМ байтовом бреде, который валится в общую память.
С этого момента Вы уже перестали понимать то, о чём я говорю. На что я и обратил Ваше внимание анекдотом.
|
|
Harsky ( Слушатель ) |
| 19 авг 2013 23:43:26 |
Цитата: ivan2 от 19.08.2013 23:13:45
Ну так поясните, в чем проблема?
Матрицу мгновенного снимка побили на участки, каждый участок отдали одному узлу. Все узлы отработали по одной программе и отчитались. По получению сигнала от последнего узла - переходим к следующему этапу обработки или вообще отдаем кадр на другой чип, а "по месту" повторяем для следующего кадра. Какие тут особые проблемы с синхронизацией?
Цитата: ivan2 от 19.08.2013 23:13:45
Буфер для кадра религия не позволяет организовать?
Ну сформировали вы один полноценный кадр - так отдайте его на обработку и формируйте следующий в это время.
Не надо решения, принятые вынуждено из-за слабости вычислительных средств, почитать за добродетель.
30 лет назад не было возможности запоминать ежесекундно по 1Гб, к примеру, и обрабатывать его на следующей ступени конвейера. Сейчас это не проблема и даже не повод поговорить. При желании хоть сотню последних кадров можно держать в быстрой памяти для анализа динамики процессов во времени.
[/quote]
Цитата: ivan2 от 19.08.2013 23:13:45
Я и до этого местами не понимал о каких трудностях вы тут пишите. Трудности - это когда решил алгоритм реализовать так, чтобы все переменные были только в 6 регистрах, а требуется, как на грех, 7. А когда регистров у тебя под сотню, тогда на многие вещи смотришь проще
|
|
ivan2 ( Слушатель ) |
| 20 авг 2013 00:33:10 |
Цитата: Harsky от 19.08.2013 23:43:26
Аааа, таки понимаете!
Тогда следующий вопрос. Все узлы отчитались по любому алгоритму (например тупо перемножали на синус и отфильтровывали НЧ полосу). Имеем нуе...е количество кадров в общей памяти (одномерных индексированных массивов). Каждый кадр содержит нечто примерно общее, но неизвестно с какой позиции в массиве. Это примерно общее и есть цель, которую по Вашему легко обнаружить сложением вычислительных мощностей вычислительных модулей.
Остался сущий пустяк - параллельно выполнить корреляционную обработку каждого кадра с эталоном (излучённым сигналом), чтобы найти это общее. Сколько там элементов в решётке РЛС бокового обзора 380+-?
Параллельте уже на следующих 380 ядрах. Прошу помнить, что к одной ячейке памяти в каждый момент может получить доступ только одно ядро. Аааа, Вы хитрый. Вы заранее сдублируете все 380 пакетов каждому ядру в отдельную память (назовёте это кешами данных, заполнение которых займёт 380 раз по 380), тогда это уже не совсем то, с чего Вы начинали. Согласны? Ладно, получили параллельно 380 максимумов взаимных корреляционных функций. Теперь надо их подвигать друг относительно друга, пофильтровать и найти таки сдвиги друг относительно друга -> вычислить угол, с которого пришёл сигнал от цели.
Как-то так с точки зрения общей теории связи. Радиолокационщики конечно расширят и углубят проблему. Она решаема. Но только не с помощью пула видяшек и прочей лабуды террафлопной производительности.
|
|
Harsky ( Слушатель ) |
| 20 авг 2013 01:07:03 |
Цитата: ivan2 от 20.08.2013 00:33:10
Забавно, но это мне напомнило задачу по считыванию штрих-кодов. Причем, не то чтоб напомнило, а почти один в один. Если анализировать растр с камеры, а не пользоваться лазерным сканером. Вот уж никогда не думал, что решал задачи по радиолокации в качестве хобби
Так что я хотел сказать-то? Эта задача решалась на процессоре телефона, одним ядром в один поток, без привлечения тысяч вычислительных блоков, за секунду (меньше) примерно. Такие дела. Всего-то 30 лет развития ВТ и из серьезной проблемы задача превратилась в хобби.
|
l-mik ( Слушатель ) |
| 20 авг 2013 01:20:17 |
Цитата: ivan2 от 20.08.2013 00:33:10
Вы просто мыслите категориями старой аппаратуры. Если бы пощупали современное железо в GPU, то изменили бы свое мнение. Пиковая производительность ДОСТИЖИМА, только затраты на проектирование кода велики. Задача ? Да, ЗАДАЧА ! Но РЕШАЕМА !
Современные видяхи трассировку лучей делают на ура, а там уж ветвлений и скачков по памяти поболе, чем в вашем примере.
Вот мой пример: дан двумерный массив высот 4096*4096. Для каждой высоты надо найти максимальный угол раскрытия конуса, вершина которого лежит на этой высоте, такого, что его стенки не заденут остальные вершины.
Обработка данных на 4х потоковом 3х гигагерцовом компе занимает сутки. На 200 долларовой видеокарте - 500 миллисекунд.
А ваш пример займет на порядок-два меньше
|
|
Harsky ( Слушатель ) |
| 20 авг 2013 01:27:01 |
Цитата: ivan2 от 20.08.2013 00:33:10
Опять же, вот это ваше утверждение говорит о том что вы в плену собственного опыта. Не надо ничего дублировать для каждого ядра.
Вас устроит частота обработки 100 Гц? В таком случае ОЗУ должно выдавать 380 байт для 380 ядер по 100 раз в секунду. Скорость работы ОЗУ - что-то около 16 Мб/с (байт - одно значение - одна ячейка). Такие показатели характерны как раз для компов времен 286-386, начало 90-х.
|
rommel.lst ( Практикант ) |
| 20 авг 2013 11:10:21 |
Цитата: bca от 20.08.2013 10:09:36
Пусть у вас ФАР с тысячей элементов. Пусть они сканят пространство и строят картинку с частотой, например, 100Гц (что вообще говоря дохера, но мне не жалко).
Пусть для синтеза аппертуры запоминаются данные за последние 10 сек (тоже очень дохера, но и пофиг).
ИТОГО:
миллион точек данных. Пусть каждая хранится в виде 6 байт (круче уж вроде некуда), в итоге имеем 6 мегабайт на хранение текущей инфы.
Пусть еще 26 мег на обработку и вполне себе укладываемся в 32Мб, доступные еще на 486
Реально нужно будет намного меньше.
А быстродействие.. спецпроцессор все 100к точек текущего массива прохавает в один проход, ИМХО.
Проблема не в быстродействии давно уже. А в алгоритмах обработки картинки - цели нуна выделять из потока данных уже на борту и в квази-реалтайм, иначе нафиг весь сыр-бор с таким бортовым комплексом разводить?
|
|
Павел_23a7a9 ( Слушатель ) |
| 20 авг 2013 00:21:02 |
Цитата: dc93 от 19.08.2013 17:48:06
Нет никаких специализированных видеопроцессоров. Есть числодробилки, которые в ущерб ветвлению (у г-форса, при ветвлении набор блоков стопорится (16 шутк вроде), и ветвятся они все вместе), дают бешенную производительность, т.к. дохрена ядер и очень малый набор команд. Писать алгоритм под ГПУ (в прочем как под любой ДСП) тот еще изврат, на фоне кода для ЦПУ. Но зато бешеная производительность на ватт.
Но не все задачи ГПУ выполнет быстрее ЦПУ. Только те что параллелятся. Это как правило графика, обработка звука, архивирование и т.д.
|
|
Удаленный пользователь |
| 19 авг 2013 17:43:46 |
Цитата: dc93 от 19.08.2013 16:44:35
Чистых CISC нет уже лет 10, если не больше. Кажется 486 и был одним из последних более-менее CISC процессоров. Про декодер команд слышали?
И что значит специализированные задачи? RISC ARM порвет "CISC" процессор ворочающий SSE/SSE2/AVX? Рвалка не надорвется супротив конвейера жующего до 8 операндов в весьма нелегких для ARM операциях?
Ну и сравнение ARM с древним 486, конечно, доставляет.
Не срача ради. Высокую производительность в конкретных задачах дают специализированные решения. Вспомните тот же подсчет биткойнов, который является очень вычислительной задачей. Где там ARM со своей "рвалкой"? Правильно, вообще нигде. Рулят там видеокарты и появившиеся недавно специализированные чипы (кажется, Avalon зовутся). ARM - ровно такой же универсальный процессор со своими сильными и слабыми сторонами. И производительность - это не его сильная сторона. Сильная сторона - удельное потребление.
|
|
dc93 ( Слушатель ) |
| 19 авг 2013 17:59:39 |
Цитата: Stitch от 19.08.2013 17:43:46
Я не очень понимаю термин "чистый CISC". Про декодер команд слышал, также слышал, что как раз пень внутри и был сделан в виде декодер + RISC (очень, очень грубо)
Цитата: Stitch от 19.08.2013 17:43:46
и чего же это в центринах то конвейер сократили, а скорость то как выросла? : ) помнится сравнивал скорость своего t40 с каким-то пнем с HT на 2.4GHz, практически вровень шли
и где Вы собираетесь использовать все эти SSE и пр. при обработке картинки? Я себе в задаче распознования не представляю места этих команд.
Цитата: Stitch от 19.08.2013 17:43:46
это не ко мне претензии, не я начал.
Цитата: Stitch от 19.08.2013 17:43:46
согласен, но специализированнные решения дороги, в данном случае не вижу необходимости "паять плату на дискретной логике".
по производимости -- ничего быстрее рисков не может быть в принципе, поскольку не бывает скорости кодирования выше, чем R=1 : )))
|
|
Sewer Endemic ( Слушатель ) |
| 19 авг 2013 18:22:14 |
Цитата: dc93 от 19.08.2013 17:59:39
Пень - ещё нет. Суперскаляр - да. Спекулятив - да. Но без явной разбивки CISC-команды на микрооперации и конвейеризации оных. Точнее, конвейер (2 шт) там был, но всё тех же самых CISC-команд. RISC-ядро - начиная с Intel NetBurst и AMD K8, ЕМИНС...
|
|
marrakesh ( Специалист ) |
| 19 авг 2013 18:05:06 |
Цитата: Stitch от 19.08.2013 17:43:46
RISC ARM конечно надорвётся, а вот RISC POWER7 схомячит все эти операнды и ещё попросит
|
|
Павел_23a7a9 ( Слушатель ) |
| 20 авг 2013 00:13:01 |
Цитата: OlegNZH_ от 19.08.2013 15:49:43
Не круче. Если раньше у меня был 386/Пенек100/Пенек233 и это был камушек размером 20х20мм (сильно примерно), то щас у меня в телефоне проц на 2 ядра, по 1ГГц, при этом жрет меньше, заткнет за пояс любого и 486/586 влет. Времена изменились, сейчас производительность просто бешенная на фоне того что было еще 15-20 лет назад.
Не ошибусь если скажу что алгоритм по картографированию местности легко параллелится, и под него даже не надо всякие АРМы да Коры искать, копеечный чип на ГФорсе220 уделает по производительности ай5. При это жрет мало и компактный.
Зря вы так "игрулька", эту игрульку Интел с Атомом все никак не переиграет.