Здравствуйте, vdimas, Вы писали:

C>>VLIW/RISK — LOL.
V>Да понятно, что ты не в курсе, как устроены сигнальные процессоры, иначе бы не писал столь махровую пургу в эту ветку...
Нет, про то что VLIW популярен в GPU (и прочей медиа) я и так знаю. Но какую связь он имеет с RISK?!?

Здравствуйте, vdimas, Вы писали:

C>>Обычно под этим понимается процесс создания маски и производство на её основе.
V>Ну вот на техпроцессе 14нм основная масса "деталей" выполнена по процессу, грубо, 32нм, еще немного по процессу 20нм и совсем чуть-чуть по 14нм. ))
Естественно, так как аналоговые проблемы никуда не делись.

C>>Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA.
V>Можно, потому что это 22 нм, потому что это готовое изделие от производителя. Но коммерчески-доступна для небольших и средних сторонних партий ASIC лишь 0.13 мкм и выше.
32нм доступен коммерчески в крупных масштабах уже несколько лет. 22нм — уже сложнее, но это уже не мега-экзотика.

Общее правило — процесс становится широко доступен через 5 лет после появления первых коммерческих образцов.

C>>Наш ASIC делает TSMC.
V>По какому процессу и какая партия?
28/32нм

C>>Следующее поколение делает GF. Угу, очень большая разница.
V>Разница большая. Заменяться могут базовые библиотеки, ес-но, т.е. на выходе будет разный итоговый дизайн.
Библиотеки IP-ядер от фабрики никто не заставляет использовать, если есть свои лицензии.

Для тех кто не знает: большинство (все?) фабрики имеют лицензии на разные полезные IP-cores (процессорные ядра, контроллеры памяти, медиа-компрессоры и т.д.), которые они сублицензируют бесплатно или очень дёшево своим клиентам.

Здравствуйте, Cyberax, Вы писали:

C>>>Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA.
V>>Можно, потому что это 22 нм, потому что это готовое изделие от производителя. Но коммерчески-доступна для небольших и средних сторонних партий ASIC лишь 0.13 мкм и выше.
C>32нм доступен коммерчески в крупных масштабах уже несколько лет.

Ну да. Только стоит уточнить для коллег, что под "крупными заказами" понимается от нескольких сотен тыс экземпляров.


C>Общее правило — процесс становится широко доступен через 5 лет после появления первых коммерческих образцов.
C>>>Наш ASIC делает TSMC.
V>>По какому процессу и какая партия?
C>28/32нм

И куда столько микросхем? ))


C>Для тех кто не знает: большинство (все?) фабрики имеют лицензии на разные полезные IP-cores (процессорные ядра, контроллеры памяти, медиа-компрессоры и т.д.), которые они сублицензируют бесплатно или очень дёшево своим клиентам.

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

Здравствуйте, Cyberax, Вы писали:

C>Нет, про то что VLIW популярен в GPU (и прочей медиа) я и так знаю. Но какую связь он имеет с RISK?!?

Э-э-э... не улавливаю суть возражения...

VLIW можно считать логическим продолжением идеологии RISC

Как только в одной RISC-команде содержатся инструкции для более, чем одного исполнительного блока (достаточно для 2-х), то это уже VLIW.

Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично. Звуковой чип? — разумеется тоже. Камера? — а как же, в ней живет "аппаратный кодек MP4", который представляет из себя банальный сигнальный процессор с фиксированной прошивкой. Про тач-скрин уже писал.

В общем, везде происходит засилье VLIW-процессоров, поэтому я аж икнул, прочитав твои высказывания, что, мол, VLIW подыхает. ))

Тут история ровно наоборот, VLIW — это вообще единственная архитектура, которая выжила в условиях, когда сверху не давит совместимость по бинарному коду. Т.е. в нашей реальности случилось наоборот — подохли суперскалярные процы (а было много попыток использовать суперскалярную архитектуру в сигнальных процах) во всех этих перечисленных применениях и аналогичных им, т.е. в ситуациях, когда прошивка изготавливается для конкретной железки. В суперскалярной архитектуре банально выхлоп эффективности в пересчёте на транзистор получается от ~4 до более 10 раз хуже, в зависимости от задачи. Т.е. вот ты запихал миллиард транзисторов в суперскалярный проц, а от него пользы как VLIW-микросхемы с кол-вом транзисторов в 4-10 раз меньшим. Поэтому, собсно, альтернативы VLIW на сегодня банально нет и даже не предвидится.

А весь этот современный CISC в центральных процах продиктован не техническими преимуществами суперскаляра, а особенностями сложившейся бизнес-модели распространения ПО, когда программы распространяются в виде готовых бинарников. Вот тут и появляется надобность в "абстракции" бинарного кода программ от исполнительных устройств конкретного проца. Поэтому-то и приходится переводить CISC-команды в тот же VLIW, но уже на лету внутри проца.

========
GPU — это немного отдельная песня.

Здравствуйте, vdimas, Вы писали:

V>Эти первые 4 ядра не тянут даже на одно нормальное ядро по эффективности.

Судя по реальным бенчмаркам, они таки тянут очень неплохо, и далеко не факт, что ядра эльбруса чем-то лучше. http://www.7-cpu.com/
Так что, единственные процессоры, с которым он может хоть как-то потягаться — мобильные.

Здравствуйте, vdimas, Вы писали:

C>>32нм доступен коммерчески в крупных масштабах уже несколько лет.
V>Ну да. Только стоит уточнить для коллег, что под "крупными заказами" понимается от нескольких сотен тыс экземпляров.
Необязательно. Можно и несколько экземпляров, но сравнительно дорогих. Сейчас маски для чипа на 28нм можно изготовить менее чем за $500k, если разделять пластину с другими заказчиками.

Недёшево, но уже не требует партий в миллионы устройств для окупаемости.

C>>28/32нм
V>И куда столько микросхем? ))
В IoT, например.

C>>Для тех кто не знает: большинство (все?) фабрики имеют лицензии на разные полезные IP-cores (процессорные ядра, контроллеры памяти, медиа-компрессоры и т.д.), которые они сублицензируют бесплатно или очень дёшево своим клиентам.
V>Имелись ввиду библиотеки совсем базового уровня — начиная от триггеров, при переводе того же верилога на железо. У Intel и TSMC слишком разные технологии, т.е., грубо, литографическая матрица с одной фабрики, предназначенная для их пластин не покатит для другой фабрики и тех пластин.
Естественно не прокатит. Для каждой фабрики делаются свои маски, однако для них не нужно переделывать весь чип.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Полностью полный. Видеокарты, сетевые контроллеры, контроллеры дисков — всего этого у нас пока не производится.

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

Здравствуйте, Kesular, Вы писали:

K>Судя по реальным бенчмаркам, они таки тянут очень неплохо, и далеко не факт, что ядра эльбруса чем-то лучше. http://www.7-cpu.com/
K>Так что, единственные процессоры, с которым он может хоть как-то потягаться — мобильные.

Тебя в гугле забанили?
На многих классах задач Эльбрус работает на уровне i7 при частоте в 4 раза меньшей.
А на некоторых классах задач даже быстрее, например, выполняя один из алгоритмов GC.

Здравствуйте, Cyberax, Вы писали:

C>>>32нм доступен коммерчески в крупных масштабах уже несколько лет.
V>>Ну да. Только стоит уточнить для коллег, что под "крупными заказами" понимается от нескольких сотен тыс экземпляров.
C>Необязательно. Можно и несколько экземпляров, но сравнительно дорогих.

Я рассуждал от рыночных цен готового изделия, разумеется.


C>Недёшево, но уже не требует партий в миллионы устройств для окупаемости.
...
C>В IoT, например.

Для IoT микросхема должна стоить доллар-полтора.
Возвращаемся к исходной задаче. ))


C>Естественно не прокатит. Для каждой фабрики делаются свои маски, однако для них не нужно переделывать весь чип.

Не нужно переделывать его высокоуровневое описание. Я уже приводил аналогию исходника на ЯП высокого уровня и его компиляцию под разные платформы. Тут фактически то же самое.

Здравствуйте, vdimas, Вы писали:

V>Тебя в гугле забанили?
V>На многих классах задач Эльбрус работает на уровне i7 при частоте в 4 раза меньшей.
V>А на некоторых классах задач даже быстрее, например, выполняя один из алгоритмов GC.

Доказательства?

Здравствуйте, vdimas, Вы писали:

V>Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично. Звуковой чип? — разумеется тоже. Камера? — а как же, в ней живет "аппаратный кодек MP4", который представляет из себя банальный сигнальный процессор с фиксированной прошивкой. Про тач-скрин уже писал.
Ты лучше покажи нам ассемблерный код Bluetooth/WiFi/Звуковой чип/камера в котором будет видно, что
V>Как только в одной RISC-команде содержатся инструкции для более, чем одного исполнительного блока (достаточно для 2-х), то это уже VLIW.

А то какое-то шапкозакидательство прямо — везде VLIW, он лучший и "....VLIW — это вообще единственная архитектура....". Меньше, слов, больше кода.

Здравствуйте, Privalov, Вы писали:

P>Блин, сейчас посмотрел: оказывается, в моем компе есть трехдюймовый флопповод. А в ящике стола — несколько дискет. Правда, комп флопповод не видит: при замене железа его не подключили. Зато как смотрится!
Давно вытащил и выкинул этот пылесборник.
P>Вот 5-дюймовых дискет я с конца прошлого века не видел. Не говоря уже о 8-дюймовых.
У меня одна 8-дюймовая — единственное, что из дискет вообще сохранилось, так, на память. Даже CD/DVD все повыкидывал, только привод оставил в шкафу на всякий случай, думаю, и его уже пора на помоечку.

Здравствуйте, Cyberax, Вы писали:

C>Современные Intel'ы внутри так и работают — предсказатель переходов, по сути, и есть "перекомпиляция на лету". Туда ещё добавляется и спекулятивное исполнение, когда CPU одновременно исполняет обе ветки if'а до тех пор, пока точно не станет известен результат сравнения.

Неправильно!
CPU всегда исполняет ОДНУ ветку. Ту, которую он считает более вероятной.
А если не угадал, то откатывает результаты.

Достаточно подумать пять минут, чтобы понять, почему это лучше.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Kernighan, Вы писали:

K>>Вот очень характерный пример, как можно знать слова и не понимать их смысл.
K>>Зачем нужен out-of-order? Ну вот просто подумать? Да потому что команды стоят в неправильном порядке.

Pzz>Причин минимум две:
Pzz>1. У процессора теперь много штук ALU. И чтобы их загрузить, надо выполнять команды не в логической последовательности, а по мере освобождения ALU

И чё? Так почему нельзя поставить команды в правильном порядке?
Как ты думаешь, в каком порядке освобождаются АЛУ?
Как ты думаешь, что влияет на исполнение команд?

Pzz>2. Память стала асинхронным устройством, и как-то обидно, если целый процессор простаивает, пока память думает

Ну? И что тебе мешает поставить вперёд команду LOAD на этапе компиляции?
Или ты думаешь, что на этапе исполнения это лучше сделается?

Тебе слово Transmeta о чём-нибудь говорит?

Здравствуйте, Kesular, Вы писали:

V>>На многих классах задач Эльбрус работает на уровне i7 при частоте в 4 раза меньшей.
V>>А на некоторых классах задач даже быстрее, например, выполняя один из алгоритмов GC.
K>Доказательства?

Что, действительно забанили?
Паспортная производительность процессора Эльбрус 8С – 250 гигафлопс.
Intel Core i7 4930K – 130-140 гигафлопс.

Поищи на этом сайте обсуждения за 2016-й год процессора Эльбрус 4С — было бурное обсуждение с кучей ссылок.

Так вот, моё "работает на уровне i7 при частоте в 4 раза меньшей" относилось именно к этому процессору, т.е. 4С, у которого паспортная производительность 50 гигафлопс на 800 МГц. Его сравнивали с i7-880 на 3.2 ГГц (потому что идентичные показатели в гигафлопсах) и результаты на многих классах задач (в основном вычислительных/математических и мультимедиа) получались в среднем не хуже, а иногда даже серьёзно лучше — вот как раз неожиданно "выстрелил" алгоритм сборки мусора. Забавно, как по мне.

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

Здравствуйте, m2l, Вы писали:

V>>Звуковой чип? — разумеется тоже. Камера? — а как же, в ней живет "аппаратный кодек MP4", который представляет из себя банальный сигнальный процессор с фиксированной прошивкой. Про тач-скрин уже писал.
m2l>Ты лучше покажи нам ассемблерный код Bluetooth/WiFi/Звуковой чип/камера в котором будет видно, что

Когда просят, то делают это малость другим тоном.


V>>Как только в одной RISC-команде содержатся инструкции для более, чем одного исполнительного блока (достаточно для 2-х), то это уже VLIW.
m2l>А то какое-то шапкозакидательство прямо — везде VLIW, он лучший

А что поделать? Предлагаешь жить в выдуманном мире? ))

Даже в старинном iPhone 5 только для одного вшивого аудио был отдельный программируемый DSP core плюс аппаратный кодек к нему. "Аппаратный кодек" — это тоже DSP, просто с фиксированной прошивкой.


m2l>и "....VLIW — это вообще единственная архитектура....". Меньше, слов, больше кода.

Блин, меньше пафоса, больше вежливости. А то как ты себя из лужи сейчас доставать будешь?
Хотя обычно бесплатно не подаю, но это не для тебя лично.

=========================
Примерно так надо писать параллельный код для сигнальных процов:
Исходник на С:

float dotp(float a[], float b[])
{
  int i;
  float sum0, sum1, sum;
  sum0 = 0;
  sum1 = 0;
  for(i=0; i<100; i+=2){
    sum0 += a[i] * b[i];
    sum1 += a[i + 1] * b[i + 1];
  }
  sum = sum0 + sum1;
  return(sum);
}

Или аналогичный исходник на так называемом "последовательном ассемблере":

        .cproc a, b

        .reg sum, sum0, sum1, a, b
        .reg ai1:ai, bi1:bi, pi, pi1

        MVK 50,cntr         ; cntr = 100/2
        ZERO sum0           ; multiply result = 0
        ZERO sum1           ; multiply result = 0
LOOP:   .trip 50
        LDDW *a++,ai1:ai    ; load ai & ai+1 from memory
        LDDW *b++,bi1:bi    ; load bi & bi+1 from memory
        MPYSP ai,bi,pi      ; ai * bi
        MPYSP ai1,bi1,pi1   ; ai+1 * bi+1
        ADDSP pi,sum0,sum0  ; sum0 += (ai * bi)
        ADDSP pi1,sum1,sum1 ; sum1 += (ai+1 * bi+1)
 [cntr] SUB cntr,1,cntr     ; decrement loop counter
 [cntr] B LOOP              ; branch to loop
        ADDSP sum,sum1,sum0 ; compute final result
        .return sum
        .endproc

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

Но не суть, действительно интересующимся предлагаю погуглить, например, по "TMS320C6000 assembly optimizer".
Общая характеристика архитектуры:

All instructions executing in parallel constitute an execute packet. An execute packet can contain up to eight instructions.

Так вот, из любого из данных выше исходных вариантов в итоге получается такое:

        LDW   .D1   *A4++,A2 ; load ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ; load bi & bi+1 from memory
||      MVK   .S1   50,A1    ; set up loop counter
||      ZERO  .L1   A7       ; zero out sum0 accumulator
||      ZERO  .L2   B7       ; zero out sum1 accumulator
   [A1] SUB   .S1   A1,1,A1  ; decrement loop counter
||      LDW   .D1   *A4++,A2 ;* load ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ;* load bi & bi+1 from memory
   [A1] SUB   .S1   A1,1,A1  ;* decrement loop counter
|| [A1] B     .S2   LOOP     ; branch to loop
||      LDW   .D1   *A4++,A2 ;** load ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ;** load bi & bi+1 from memory

   [A1] SUB   .S1   A1,1,A1  ;** decrement loop counter
|| [A1] B     .S2   LOOP     ;* branch to loop
||      LDW   .D1   *A4++,A2 ;*** load ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ;*** load bi & bi+1 from memory
   [A1] SUB   .S1   A1,1,A1  ;*** decrement loop counter
|| [A1] B     .S2   LOOP     ;** branch to loop
||      LDW   .D1   *A4++,A2 ;**** load ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ;**** load bi & bi+1 from memory
        MPY   .M1X  A2,B2,A6 ; ai * bi
||      MPYH  .M2X  A2,B2,B6 ; ai+1 * bi+1
||[A1]  SUB   .S1   A1,1,A1  ;**** decrement loop counter
||[A1]  B     .S2   LOOP     ;*** branch to loop
||      LDW   .D1   *A4++,A2 ;***** ld ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ;***** ld bi & bi+1 from memory
        MPY   .M1X  A2,B2,A6 ;* ai * bi
||      MPYH  .M2X  A2,B2,B6 ;* ai+1 * bi+1
||[A1]  SUB   .S1   A1,1,A1  ;***** decrement loop counter
||[A1]  B     .S2   LOOP     ;**** branch to loop
||      LDW   .D1   *A4++,A2 ;****** ld ai & ai+1 from memory
||      LDW   .D2   *B4++,B2 ;****** ld bi & bi+1 from memory
LOOP:
        ADD   .L1   A6,A7,A7 ; sum0 += (ai * bi)
||      ADD   .L2   B6,B7,B7 ; sum1 += (ai+1 * bi+1)
||      MPY   .M1X  A2,B2,A6 ;** ai * bi
||      MPYH  .M2X  A2,B2,B6 ;** ai+1 * bi+1
||[A1]  SUB   .S1   A1,1,A1  ;****** decrement loop counter
||[A1]  B     .S2   LOOP     ;***** branch to loop
||      LDW   .D1   *A4++,A2 ;******* ld ai & ai+1 fm memory
||      LDW   .D2   *B4++,B2 ;******* ld bi & bi+1 fm memory
; Branch occurs here
        ADD   .L1X  A7,B7,A4 ; sum = sum0 + sum1

Что означает признак "||" объяснять надо?

Чтобы происходящее было понятней — это код для одной из самых популярных DSP-архитектур последних 20 лет:

http://www.studfiles.ru/preview/4599904/page:82/

Здравствуйте, vdimas, Вы писали:

m2l>>Ты лучше покажи нам ассемблерный код Bluetooth/WiFi/Звуковой чип/камера в котором будет видно, что
V>Когда просят, то делают это малость другим тоном.
Хорошо, какой вариант этого предложения на твой взгляд будет иметь более нейтральный окрас?

V>А что поделать? Предлагаешь жить в выдуманном мире? ))
Предлагаю обращаться к первоисточнику.
V>Даже в старинном iPhone 5 только для одного вшивого аудио был отдельный программируемый DSP core плюс аппаратный кодек к нему. "Аппаратный кодек" — это тоже DSP, просто с фиксированной прошивкой.
Просто ты очень вольно ставишь знак равенства DSP == VLIW. Даже в этих двух предложениях выше. Если ты так считаешь, то обоснуй это чем-то, кроме своего мнения. К примеру листинг кода или спецификация производителя этого аудио в iPhone 5 на который ты ссылаешься.

m2l>>и "....VLIW — это вообще единственная архитектура....". Меньше, слов, больше кода.
V>Блин, меньше пафоса, больше вежливости. А то как ты себя из лужи сейчас доставать будешь?
Я не давал оценок какой-либо архитектуре, а написал что неплохо бы пруфы приводить. В какую лужу хочешь меня засадить?
V>Хотя обычно бесплатно не подаю, но это не для тебя лично.
Спасибо.

V>=========================
V>Примерно так надо писать параллельный код для сигнальных процов:
V>Исходник на С:
Я не знаю к чему ты его привел. Скомпилится в любую архитектуту...

V>Или аналогичный исходник на так называемом "последовательном ассемблере":
Отлично, ассемблер TMS. Какие их dsp на архитектуре VelociTY стоят в iPhone 5, на который ты ссылаешься?
Если честно я вообще не слышал распрастраненных моделей TMS для "Bluetooth/WiFi/Звуковой чип/камера". Есть что-то их в материнках, сетевых карточках, коммутаторах там?

V>Ты когда-нибудь слышал про оптимизирующий ассемблер? Похоже, что нет, судя по общему удивлённому тону твоего поста. Это не страшно... У многих "громкоговорящих" личностей с этого сайта наблюдается устойчивое заблуждение на счёт того, что ассемблер не может ничего оптимизировать. Так же как хватает других устойчивых заблуждений и веры в мифы...
Переходишь на личности, навешиваешь ярлыки, ишешь оттенки в 20-ти словах.

V>Но не суть, действительно интересующимся предлагаю погуглить, например, по "TMS320C6000 assembly optimizer".
Вот смотри, меняем один символ и получаем TMS320C5000. Который не разу не VLIW, но производится и используеться. И выходи, твоё:

Собсно, все современные сигнальные процы — VLIW

Ложно.

V>Так вот, из любого из данных выше исходных вариантов в итоге получается такое:
Отлично листинг VLIW ассембленра. Но из прошивки для какого "Bluetooth/WiFi/Звуковой чип/камера"? Как твой пример доказывает, что на моём "ноуте/планшете" есть Bluetooth с VLIW архитектурой?

V>Что означает признак "||" объяснять надо?
Не думаю, что там что-то менялось.

V>Чтобы происходящее было понятней — это код для одной из самых популярных DSP-архитектур последних 20 лет:
Ты понимаешь, что из утверждения VelociTY VLIW архитектура, не следует:

Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично. Звуковой чип? — разумеется тоже.

Ну или напиши, какие из популярных Bluetooth/WiFi чипов материнских плат построены на C6000. И каверзный вопрос, VelociTY одна из самых популярных среди разработчиков DSP или по числу чипов?


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

Хотя обычно бесплатно не подаю, но это не для тебя лично

не доказывает правильности этого обобщения. Лично мне как-бы побоку CISC/RISC/VLIW, гранитцы между ними эфимерны. Но если ты хочешь делиться своими знаниями, почему бы не приводить заодно ссылки на первоисточники? Или уточнять, что это твоё частное мнение/опыт?

Здравствуйте, Kernighan, Вы писали:

K>>>Вот очень характерный пример, как можно знать слова и не понимать их смысл.
K>>>Зачем нужен out-of-order? Ну вот просто подумать? Да потому что команды стоят в неправильном порядке.

Pzz>>Причин минимум две:
Pzz>>1. У процессора теперь много штук ALU. И чтобы их загрузить, надо выполнять команды не в логической последовательности, а по мере освобождения ALU

K>И чё? Так почему нельзя поставить команды в правильном порядке?
K>Как ты думаешь, в каком порядке освобождаются АЛУ?
K>Как ты думаешь, что влияет на исполнение команд?

Некая команда сегодня выполнилась (уже после получения всех данных) за 3 такта, завтра потребует 73. Потому что другие данные, а команда — например — деление (которое может ускориться до минимума, в лёгком случае, а может потребовать такта на бит делимого, плюс пролог, плюс эпилог).
Почему все должны ждать её завершения, если перед применением результата команды ещё много можно чего выполнить? Почему ждать именно этого АЛУ, которое занято ещё долго, а не сесть на второе, которое свободно?

Pzz>>2. Память стала асинхронным устройством, и как-то обидно, если целый процессор простаивает, пока память думает

K>Ну? И что тебе мешает поставить вперёд команду LOAD на этапе компиляции?
K>Или ты думаешь, что на этапе исполнения это лучше сделается?

Команда номер 1 требует данных по адресу P, а номер 4 — по адресу Q.
Сегодня P в кэше L1, а Q ни в каком. Завтра — наоборот. Фактически они исполнятся с колоссальным разносом по времени и в противоположном порядке.

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

Ты будешь все подобные загрузки предупреждать какими-то LOAD (PREFETCH в более традиционных названиях)? А сама эта загрузка куда идёт?
В регистр? Тогда реально эта загрузка будет происходить OoO (потому что началась тут, а закончится ХЗ когда).
В кэш? То же самое, плюс непредсказуемые задержки на то, чтобы убрать из кэша то, что должно уйти, чтобы освободить место.

K>Тебе слово Transmeta о чём-нибудь говорит?

Ну расскажи, что именно оно должно обозначать в данном случае.
А заодно, как это связано с тем, что попытки Transmeta обогнать обычный OoO образца товарища Tomasulo закончились пшиком.

Здравствуйте, Блудов Павел, Вы писали:

LVV>>Неужели доживу — куплю НАШ компьютер ?!

БП>Для меня критерий НАШЕГО компьютера — наличие на клавиатуре отдельной кнопки, переключающей раскладку.

Насколько отдельной?

Я вот переназначаю CapsLock на эту роль — этого достаточно?

Здравствуйте, Pzz, Вы писали:

Pzz>А вот интересно. В процессорах, типа Эльбруса, компилятор пытается, путем статического анализа текстов, угадать, как лучше. В процессорах, типа интеловских, это же пытается сделать процессор, наблюдая за ходом исполнения программы.

Для Intel & Co. пытаются оба. Код, в котором намеренно переставлены команды так, чтобы между парой с зависимостью было несколько других команд, не связанных с ними, я вижу регулярно. (Другой вопрос, что это хорошо получается только на вычислительных частях или манипуляциях мелкими порциями данных; остальной код, чуть менее чем полностью состоящий из вызова других функций с простым формированием данных для них, не получит тут выгоды, поэтому в таких местах таких разносов очень мало.)
Для архитектур с известным слабым умением OoO эти разносы делаются значительно сильнее.

Pzz>Компилятор умнее, а процессор видит, как жизнь устроена на самом деле. Поэтому оба они не дают оптимальных результатов.

Pzz>А никто не пробовал применять комбинированный подход, когда процессор собирает детальные метрики, а just in time recompiler перекомпилирует узкие места с их учетом?

Уже ответили.