_Loader_

Hello Ilia.

07 Oct 03 01:01, you wrote to me:

RK>>>> Может, но не стековый суперскаляр будет гораздо проще, а RK>>>> преимуществ у стекового процессора перед не стековым (в плане RK>>>> производительности) нет.

IT>>> ASIC - проще. Софт-ядро в ПЛИС - такое же.

RK>> За счет чего оно проще? Пока был упомянут только дешифратор RK>> команды - это не настолько сложная часть процессора, что бы его RK>> упрощение сделало процессор в целом ощутимо проще.

IT> За счет того, что это ASIC - Application-Specific Integral Circuit.

Ты не понял - за счет чего стековый процессор будет проще не стекового?

RK>> Аппаратура в принципе не может распределить поток команд на 2 RK>> независимых параллельно работающих процессора. IT> Разве что в потоке команд будут указаны действия для двух ядер сразу.

Это не есть 'распараллелить', это есть 'распараллелил компилятор'.

IT>>> Вот только недавно ушла разработка со счетверенным вычислителем. IT>>> Самый настоящий SIMD - стековое ядро формирует команду для IT>>> счетверенного арифметического блока... RK>> Заметь: счетверенный арифметический блок!=4м отдельным RK>> арифметическим блокам каждый со своими потоками команд (то есть RK>> 4м процессорам) IT> А какая мне в данном случае разница? :))

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

RK>> Вообще то речь шла о неэффективности стековых архитектур для RK>> исполнения _одного_ потока комманд в свете технологии SiperScalar

IT> Кстати, могу сослаться на TIGRE - это такая система редукции графов IT> (GRE = Graph REduction), которая дает вполне хорошие результаты для IT> стековых машин.

И что, она позволит на ходу свести 1 поток команд к 4м независимым потокам, да еще будет исполненна в железе? Что то не верится.

Roman

Hi Roman,

Sun Oct 05 2003 21:23, Roman Khvatov wrote to Alex Kouznetsov:

AK>> Предположим, на определенном кол-ве вентилей можно сделать проц, AK>> реализующий тот или иной подход. Одна реализация - ПикоЖаба, другая - AK>> суперскалярный RISC. Померяли производительность, оказалось что AK>> ПикоЖаба отстает. Возникает законный вопрос - а лучше суперскалярного AK>> РИСКа ничего нельзя сделать на этих же вентилях?

RK> Можно - VLIW. До сих пор все развитие процессоров шло по пути их RK> упрощения. RK> Сначала сделали CISC. Упор был сделан на компактный код, так как RK> экономили память (ее тогда было мало). Затем, когда памяти стало много и RK> понадобилась скорость был задан резонный вопрос - а зачем нужен микрокод? RK> Процессор реально исполняет интерпретатор (микрокод), который читает RK> байткод (входной бинарный код процессора) и интерпретирует каждую RK> инструкцию. Таким образом имеется интерпретатор (в железе), который RK> ничего, кроме замедления процессора не дает (память уже не экономили :). RK> Естественный шаг - оторвать интерпретатор и исполнять напрямую команды RK> уровня инструкций микрокода. Так появился RISC. RK> Затем (в процессе естественной эволюции RISC'а), для дальнейшего RK> увеличения производительности в процессор добавили параллельно работающих RK> исполнительных устройств и хитрый дешифратор, который читал поток команд RK> (по нескольку штук зараз) и пытался загрузить все эти добавленные RK> устройства. Так появились суперскалярные разновидности RISC'а (заметь, RK> что с точки зрения архитектуры процессора для прикладных программ этот RK> суперскаляр ничем от обычного RISC'а не отличается). Следующий очевидный RK> шаг - оторвать этот 'хитрый дешифратор' и загружать все исполнительные RK> устройства явно, так появился VLIW.

Перечитывая материалы с веб-сайта Купмана, наткнулся на его статью примерно

92-го года. Где сравнивается производительность Форт-процессора RTX2000, CISC 68020 (использовался в Sun 3) и RISC Sun 4 Sparс. Форт - процессор 16-битный, остальные два 32-битные. RTX2000 работал на 10 МГц (сделан по устаревшей 2-микронной технологии), 68020 на 16.67 МГц, Спарк на 14.28 МГц. Набор тестов

- Stanford Integer Benchmark, причем для RTX тесты компилировались каким-то сырым С компилятором, а не транслировались вручную в Форт, что было бы эффективнее. Так вот, при указанных тактовых время выполнения тестов соотносилось так: 1 - для Спарка, 1.61 - для RTX, и 3.4 для 68020. При одинаковой тактовой RTX отставал от Спарка на 13%. В чем RTX уделывал всех - так это во времени реакции на прерывания. По количеству циклов, нужных для входа в прерывание, ему надо в 50-100 раз меньше, чем для Спарк, и в примерно в 300-400 раз меньше чем 68020.

Жаль, нигде не сказано - сколько вентилей в Спарке, и сколько в RTX.

Пока, Алексей