Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 26.05.17 05:35
Оценка: 1 (1) -1 :))) :))
В Иннополисе: http://tehnoomsk.ru/node/2726
Неужели доживу — куплю НАШ компьютер ?!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Подскажите как сейчас принято искать работу
От: Privalov  
Дата: 29.05.17 05:14
Оценка: +3 :)))
Здравствуйте, LaptevVV, Вы писали:

LVV>Нафига он мне в мобильнике-то?


Как это зачем? 4 ядра — для позвонить, еще 4 — для всего остального.
Re: Эльбрус - 8 ядер
От: elmal  
Дата: 27.05.17 07:33
Оценка: 3 (1) +1 :)))
Здравствуйте, LaptevVV, Вы писали:

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

Что такое наш? Даже если предположить, что корпус, материнка, процессор, память, видеокарта, блок питания и т.д изготавливаются в России. То один черт, все разъемы неправославные, а стандартные. Оборудование скорее всего будет покупное у буржуев. Операционка основана будет на буржуйских исходниках, которые максимум перекомпилят. Языки программирования тоже не наши, все программироваться будет не на русском. Даже самый русский из языков программирования (то есть паскаль) — и то в буржундиях придумали. А что у нас придумали — там все на английском, да и головной офис в Праге.

Вот когда программироваться будет все на церковнославянском с божьей помощью, на троичной логике, на лампах, со своими собственными нигде в мире больше не использующимися разъемами, все, начиная от разработчиков и кончая уборщиками будут с фамилиями только вроде Иванов, Петров Сидоров, и не дай боже на ий фамилия заканчиваться будет, все будут воцерквленными — вот тогда будет наш . Если все условия выполняться не будут, допустим окажется там уборщик Иванов, который причислит себя к атеистам — все, это будет не наш компьютер, ибо Иванов там будет распространять чужеродное влияние запада!

Если же степень нашести определять так же, как и определяется во всем мире, то этих наших компьютеров до черта и более. По крайней мере у меня наш ноут (которому лет 15 уже и я его не включаю практически) и наш планшет. И больше я наш планшет хрен когда куплю, ибо из за недостаточной массовости потом фиг кто выпустит более современную прошивку.
Re[6]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 30.05.17 17:57
Оценка: 1 (1) +2 -1 :)
Здравствуйте, Kernighan, Вы писали:

D>>>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?

C>>Совершенно непонятная фиксация на VLIW?
K>Чем тебе не нравится VLIW и как она связана с частотой?
VLIW требует героических подвигов со стороны компиляторов. Проблема оказывается в том, что среди компиляторов героев не наблюдается. И исправить это на уровне железа очень сложно, так как стандартные методы ускорения (автоматическое out-of-order планирование, хитрое предсказание переходов) становятся слишком дорогими из-за сложности инструкций. Скорее всего, они героически это преодолели, истратив транзисторный бюджет.

Дополнительно, VLIW существенно затрудняет создание глубоких pipeline'ов (по тем же причинам), которые являются простейшим способом увеличить частоту.

В итоге, VLIW для CPU в индустрии умер совсем везде. Он неплохо сейчас живёт разве что только в области GPU, где примерно половина встроенных GPU построена на VLIW-подобной архитектуре.
Sapienti sat!
Re[3]: Подскажите как сейчас принято искать работу
От: CreatorCray  
Дата: 28.05.17 23:46
Оценка: +1 :))) :)
Здравствуйте, LaptevVV, Вы писали:

K>>Сейчас даже в мобильниках 8 ядер. Из-за чего шум то?

LVV>Нафига он мне в мобильнике-то?
LVV>Мне на столе надо...
Положи мобильник на стол
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[7]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 31.05.17 10:00
Оценка: 2 (1) +1 -1 :)
Здравствуйте, Cyberax, Вы писали:

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


D>>>>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?

C>>>Совершенно непонятная фиксация на VLIW?
K>>Чем тебе не нравится VLIW и как она связана с частотой?
C>VLIW требует героических подвигов со стороны компиляторов. Проблема оказывается в том, что среди компиляторов героев не наблюдается. И исправить это на уровне железа очень сложно, так как стандартные методы ускорения (автоматическое out-of-order планирование, хитрое предсказание переходов) становятся слишком дорогими из-за сложности инструкций. Скорее всего, они героически это преодолели, истратив транзисторный бюджет.

Вот очень характерный пример, как можно знать слова и не понимать их смысл.
Зачем нужен out-of-order? Ну вот просто подумать? Да потому что команды стоят в неправильном порядке.
Почему бы их не поставить сразу в правильном? Да, для этого нужен компилятор. Ну так он есть.
При этом из процессора исключаются блоки, которые занимаются этим самым out-of-order.
Всё ровно наоборот по сравнению с тем, что ты написал.

CISC (с его разной длинной команд) почему-то частоте не мешает, а VLIW видите ли мешает.
Тебе самому не смешно?

C>Дополнительно, VLIW существенно затрудняет создание глубоких pipeline'ов (по тем же причинам), которые являются простейшим способом увеличить частоту.


Каким образом VLIW "существенно затрудняет создание глубоких pipeline'ов"?
Ааа! Я знаю. Исчезает несколько стадий конвейера, которые делают из команд разной длинны
команды одной длинны, которым можно манипулировать при загрузке АЛУ.
Конвейер при этом становится короче. Ну так это же хорошо.

C>В итоге, VLIW для CPU в индустрии умер совсем везде. Он неплохо сейчас живёт разве что только в области GPU, где примерно половина встроенных GPU построена на VLIW-подобной архитектуре.


Мне одному видится здесь прямое противоречие?

В процессорах сейчас умерло всё, кроме Интела и ARM.
Вот только к качествам процессоров и уж тем более системе команд это не имеет никакого отношения.
Re: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.05.17 12:56
Оценка: 1 (1) +2 :)
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

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

На профессорскую зарплату? Вряд ли.
Re[3]: Эльбрус - 8 ядер
От: alexsmirnoff  
Дата: 26.05.17 11:19
Оценка: 6 (3)
Здравствуйте, LaptevVV, Вы писали:

LVV>Если поискать про 4С — наверное, можно будет составить представление.


Вот тут немного:
https://www.youtube.com/watch?v=gCqb65_Sz_I
Re[15]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 03.06.17 15:25
Оценка: 6 (3)
Здравствуйте, 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/
Re[2]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.05.17 12:59
Оценка: +3
Здравствуйте, Privalov, Вы писали:

P>ОС Эльбрус, судя по описанию, это Linux.


Линух — вполне адекватный выбор операционки для такого компьютера. Вместо того, чтобы строить целую экосистему, становится достаточным спортировать компилятор.
Re[7]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.05.17 20:30
Оценка: +1 :))
Здравствуйте, LaptevVV, Вы писали:

LVV>

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

LVV>Ржач после предложения видищь?
LVV>Специально для тебя поясняю: это — ИРОНИЯ...

Прям каминг-аут какой-то. Все думают, что ты нахваливаешь успехи страны, а ты, оказывается, над ними тихо посмеиваешься...
Re[2]: Эльбрус - 8 ядер
От: uncommon Ниоткуда  
Дата: 30.05.17 03:53
Оценка: +1 :))
Здравствуйте, Gattaka, Вы писали:

G>А как бы прикинуть сколько это по мощности? Сопоставить с i7 каким-нибудь?


Не богохульствуй! Православный Эльбрус ни с чем сравнивать нельзя.
Re[8]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 30.05.17 10:09
Оценка: +2 :)
Здравствуйте, Cyberax, Вы писали:

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


C>>>2ГГц без особых проблем делаются с помощью соответствующего тех. процесса.

K>>Ты это кому рассказываешь? Ты вообще знаешь, что такое техпроцесс?
C>Да, так как плотно работаю с созданием ASIC'ов.

Ну так и что такое "техпроцесс"? Вот например "техпроцесс 0.13" — это что?

C>>>Это уже даже Intel забросил для последнего поколения.

K>>Пруф?
C>С личных слов инженеров от Intel'а. Вообще, Intel в индустрии как раз известен тем, что они упорно руками разводку процессора делали до последнего.

Ну у меня регалии повыше. Я их потом скажу, когда ты более акцентированно облажаешься.
Ну так что такое техпроцесс и как он влияет на частоту?

K>>>>2) подгонять под конкретную технологию.

C>>>Всё давно делается.
K>>Глупостей не говори.
C>Что конкретно под кого подгоняется? Если не заниматься экстримом с последними поколениями тех. процессов, то производители чипов почти полностью взаимозаменяемы.

Вот и узнай, что и под кого подгоняется. Ты многих вещей просто не знаешь.
Re: Эльбрус - 8 ядер
От: novitk США  
Дата: 31.05.17 20:11
Оценка: :)))
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

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

Интел испугался сумрачного русского гения и выпустил i9.
https://www.theverge.com/circuitbreaker/2017/5/30/15710476/intel-core-x-processors-i9-chips-i5-i9-skylake-kaby-lake-computex
Re[2]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 02.06.17 07:13
Оценка: +1 :))
Здравствуйте, Kesular, Вы писали:

K>Сейчас даже в мобильниках 8 ядер. Из-за чего шум то?


Из них одно совсем дохлое-низкочастотное и три среднечастотных тоже дохлых по характеристикам. Эти первые 4 ядра не тянут даже на одно нормальное ядро по эффективности. Поэтому, нифига там не 8 ядер. ))
Отредактировано 02.06.2017 9:17 vdimas . Предыдущая версия .
Re[6]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 03.06.17 14:31
Оценка: +1 -1 :)
Здравствуйте, 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 ГГц (потому что идентичные показатели в гигафлопсах) и результаты на многих классах задач (в основном вычислительных/математических и мультимедиа) получались в среднем не хуже, а иногда даже серьёзно лучше — вот как раз неожиданно "выстрелил" алгоритм сборки мусора. Забавно, как по мне.

А у тебя какие будут доказательства всей твоей голословности в этом топике? Ты откуда инфу черпаешь, поделись, ы?
Re[13]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 06:26
Оценка: 2 (1) +1
Здравствуйте, Sharov, Вы писали:

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


C>>Основные проблемы будут с задержками памяти — 8086 не спроектирован на такую разницу в производительности CPU и памяти, какая существует сейчас.


S>И как это будет проявляться?


С реальной DRAM ты его не разгонишь быстрее 20 МГц. (Насколько я помню, у 8086 на одном такте выставлялся запрос в память, а на следующем забирались или писались данные.) 20 МГц — это с расчётом на то, что 50 нс на цикл закрытия предыдущей строки и открытия следующей, у самых быстрых современных моделей. У обычных бюджетных около 70.
Всё быстрее — требует хотя бы перехода работы с памятью на асинхронный режим, то есть переделки контроллера памяти, а по цепочке — и кучи других блоков внутри.
Ну а с уровня 33-50 МГц (поздние 386, ранние 486), как известно из истории, началось активное построение кэшей памяти. (Или ещё раньше?)

Зато на статической (как тот же кэш) проблем с этим не будет. Ну подумаешь, она в 10 раз дороже...
The God is real, unless declared integer.
Re[24]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 07.06.17 16:30
Оценка: 2 (1) +1
Здравствуйте, vdimas, Вы писали:

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


Напомнило детство...

Смотреть с 2:37

Суть:
Кадр имеет разрешение 48*24 блока (4*8 пикселей блок), но отрисовка синхронизирована с лучом развёртки, и ровно каждые 4 скан линии (224 такта в каждой) перерисовывается 24 байта атрибутов, и монитор начинает отображать новую информацию. Что увеличивает разрешение по вертикали вдвое. При этом успеваем выбирать повёрнутые пиксели из текстуры. Внутренний цикл выглядит примерно так: выбор из регистровой пары, инкремент/декремент/nop каждой половинки регистра (а-ля фиксед-поинт), запись в экран, приращение экранного адреса. Код сгенерирован с учётом вектора движения по текстуре. Никаких циклов, ветвлений и проверок — на них нет времени. Никакого разделения поворота и отрисовки уже повёрнутого — не успеешь.

Просто для понимания тормознутости процессора: типичное время исполнение одной команды 4/7/10/12 тактов. Частота 3.5мгц. За один кадр (1/50сек) инструкция блочного копирования LDIR успевает обработать только ~4кб данных. Для ротатора надо успеть обработать 24*48=1152 байт, примерно за 60% кадра. Т.е. быть всего вдвое медленнее чем команда блочного копирования! И не забываем про выравнивание отрисовки до такта, иначе рассинхримся с лучом и ничего не получится.

В нижней части экрана видим бегущую строку. Она бежит вне пиксельной области, т.н. "бордюр", 3 битный порт-регистр, задающий цвет рамки вокруг экрана. Бегушка формируется серией последовательных OUT-ов (и никак иначе, ибо OUT занимает 12 тактов за которые развёртка успевает пробежать 24 пикселя). Серия команд генерится на каждый кадр. И самое весёлое — количество тактов в кадре при любом раскладе должно давать один и тот же остаток от деления на 4, иначе будет рандомный сдвиг на 1-3 двухпиксельных шага по горизонтали. Генератор машкода тоже выровнен по тактам.

Обязательно досмотреть до 3:11, с учётом объяснений про "бордюр" станет ясно, как это устроено. Мы в 1997 реально со стульев попадали, когда увидели.

https://www.youtube.com/watch?v=dl3wWxJmIZw
kalsarikännit
Re[2]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 26.05.17 14:56
Оценка: :))
S>А пока вы можете прикупить
S>https://tjournal.ru/39451-rossiiskie-komputeri-elbrus-podesheveli-do-199-tisyach-rublei
S>Фотку с эльбрусом сюда, пожалуйста.
S>Вот и увидим цену вашего патриотизма и восторгов.
Читаем по ссылке:

В комплект компьютера входят системный блок, 23-дюймовый монитор, клавиатура и мышь. На ПК предустановлена операционная система «Эльбрус», разработанная на базе Linux.

Четырёхядерный процессор «Эльбрус-401» модификации Б имеет частоту 750 МГц, объём оперативной памяти в ПК — 24 ГБ, дисковой памяти — 1,2 ТБ (жёсткий диск на 1000 ГБ плюс SSD на 120 ГБ). В такой комплектации компьютер стоит 199 тысяч рублей.

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

1. Мне в такой мощной комплектации комп не нужен.
Я и западные такие не покупаю. И всякие измы здесь ни при чем.
Для работы мне нужно 6-8 гигов памяти, Corei5 вполне подойдет.
SSD тут маловат, диск — ну, ладно, хрен с таким объемом, хотя много лишнего.
23-дюймовый монитор комплекте — нафиг не нужен.

2. Где серийный компьютер? Он уже выпущен, куда можно прийти и прицениться?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Эльбрус - 8 ядер
От: Kolesiki  
Дата: 26.05.17 18:10
Оценка: +1 -1
Здравствуйте, LaptevVV, Вы писали:

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


Ты так спрашиваешь, будто в 1917-ом изобрёл электричество, транзисторы и вот теперь дожил до дня, когда "новая власть" смогла сделать свой, пролетарский компьютер!
Тебе лично не всё равно, стоит там герб или "made in China"?
Re[5]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.05.17 09:33
Оценка: :))
Здравствуйте, LaptevVV, Вы писали:

LVV>1. Вы единственный, кто увидел восторженность...

LVV>Остальные увидели иронию.

Я не увидел иронию. Наверное, она была очень тонкая. Тоньше длинны волны видимого света.
Re[5]: Эльбрус - 8 ядер
От: pagid Россия  
Дата: 28.05.17 17:36
Оценка: +1 :)
Здравствуйте, LaptevVV, Вы писали:

LVV>Американцы тож — не могут воспроизвести наши двигатели.

Американцы и не пытались.
Re[7]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 30.05.17 16:10
Оценка: +2
Здравствуйте, Kernighan, Вы писали:

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


K>Ну и как ты думаешь, насколько это всё сложно?

K>Иногда это всё упихивается в один кристалл. Вообще в один.
K>На плате всего два кристалла сам — процессор и память. И это всё.

Видеокарта — штука довольно нетривиальная. Умный сетевой контроллер (тот, который берет на себя часть работы процессора. Такую, как подсчет контрольных сумм TCP/IP, TCP сегментацию и т.п.) — тоже. Нормальные wifi чипы вообще мало кто производит. И т.д., и т.п.

В современном мире очень трудно построить полностью независимую от внешних поставщиков экосистему. Да и непонятно, зачем.

Pzz>>У нас не такая уж и большая доля на мировом рынке потребителей этого барахла.


K>А какая доля должна быть? Достаточно, что это доля выражается цифрами с девятью-десятью нулями?


Доля выражается в процентах. В процентах столько нулей не бывает. Разве что, после запятой.

K>>>Вот у тебя сейчас есть во что воткнуть SCSI-контроллер?


Pzz>>Да, есть.


K>Продолжаем разговор — а дискетку есть куда воткнуть? А пятидюймовую?


Насчет пятидюймовой не уверен, надо на полках рыться, а мне лень. Восьмидюймовую точно некуда
Re[8]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 31.05.17 17:46
Оценка: -1 :)
Здравствуйте, Kernighan, Вы писали:

C>>VLIW требует героических подвигов со стороны компиляторов. Проблема оказывается в том, что среди компиляторов героев не наблюдается. И исправить это на уровне железа очень сложно, так как стандартные методы ускорения (автоматическое out-of-order планирование, хитрое предсказание переходов) становятся слишком дорогими из-за сложности инструкций. Скорее всего, они героически это преодолели, истратив транзисторный бюджет.

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

K>Почему бы их не поставить сразу в правильном? Да, для этого нужен компилятор. Ну так он есть.

Потому, что статически это не всегда возможно.

K>При этом из процессора исключаются блоки, которые занимаются этим самым out-of-order.

Не исключают. В Itanic'е они тоже невозбранно появились, после того, как первая модель потонула.

Ещё более показательный пример — это delay slots в Sparc'ах.

K>CISC (с его разной длинной команд) почему-то частоте не мешает, а VLIW видите ли мешает.

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

C>>Дополнительно, VLIW существенно затрудняет создание глубоких pipeline'ов (по тем же причинам), которые являются простейшим способом увеличить частоту.

K>Каким образом VLIW "существенно затрудняет создание глубоких pipeline'ов"?
Для глубокого конвейера нужно знать зависимости по данным между командами, с VLIW это делать трудно из-за сложности инструкций. Дополнительно, нужен предсказатель переходов, чтобы минимизировать срывы конвейера — см. выше про сложность инструкций.

K>В процессорах сейчас умерло всё, кроме Интела и ARM.

Бредим. RISC-и разного рода рулят везде: POWER прекрасно существует на суперкомпьютерах, MIPS живёт в сетевых устройствах (и местами в суперкомпьютерах в Китае). VLIW, ЧСХ, в CPU помер совсем везде.
Sapienti sat!
Re[10]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 04.06.17 12:44
Оценка: -1 :)
Здравствуйте, Kesular, Вы писали:

V>>Не справляется.

K>И что это за алгоритмы такие? Давай конкретику.

Любые, где требуется low-latency и вообще hard realtime.


V>>Ты много чего тут успел понаписать, эдак тебя понесло-то.

V>>Я лишь хочу поинтересоваться источником твоего вдохновения.
K>Конкретику давай, твой треп меня уже утомил.

До этого меня утомил твой трёп:

Судя по реальным бенчмаркам, они таки тянут очень неплохо, и далеко не факт, что ядра эльбруса чем-то лучше.


Пруфы таких громкий заявлений будут?
Re: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 05.06.17 07:36
Оценка: -1 :)
Здравствуйте, Kesular, Вы писали:

V>>Любые, где требуется low-latency и вообще hard realtime.

K>А, то есть где нормальные люди используют FPGA или ASIC. Это во первых.

Ты спрашивал про GPU — я ответил.


K>А во вторых, насколько я понимаю, на Ельбрусе используется обычный линух — со всеми плюшками типа многозадачности, виртуальной памяти и так далее. И кэш там, насколько я понимаю, тоже есть. Так что откуда там вообще мог взяться hard realtime?


Не факт, что в военных комплексах будет использоваться Linux, а не какая-нить реалтаймовая ось или даже вовсе без всякой ОС. В крайнем случае есть разновидности реалтаймового Linux.


V>>Пруфы таких громкий заявлений будут?

K>Они там были. Иди и читай.

Т.е. пруфов нет. Так и запишем.
Re[26]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 07.06.17 21:27
Оценка: 2 (1)
Здравствуйте, vdimas, Вы писали:

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


IID>>В нижней части экрана видим бегущую строку. Она бежит вне пиксельной области, т.н. "бордюр", 3 битный порт-регистр, задающий цвет рамки вокруг экрана. Бегушка формируется серией последовательных OUT-ов (и никак иначе, ибо OUT занимает 12 тактов за которые развёртка успевает пробежать 24 пикселя). Серия команд генерится на каждый кадр. И самое весёлое — количество тактов в кадре при любом раскладе должно давать один и тот же остаток от деления на 4, иначе будет рандомный сдвиг на 1-3 двухпиксельных шага по горизонтали. Генератор машкода тоже выровнен по тактам.


V>Фазовая автоподстройка? ))


Ага.
Т.к. команду посередине не прервёшь, а команда HALT (ожидания прерывания) внутри устроена как бесконечное исполнение NOP-ов (4 такта).

Ещё нужен трюк с первоначальной автоподстройкой, т.к. мы не знаем какое смещение тактов от фронта прерывания было в предыдущем, невыровненном коде.

V>Жаль, что частота развертки моего экрана не кратна исходной частоте развертки.


Включи HD. Иначе ютуб половину кадров выкидывает

V>Кстате, раздражает в современных 3D-играх отсутствие той самой плавности смещения картинки и вообще отсутствие плавности любой анимации, которая была когда-то. Сейчас в играх FPS само по себе (да еще и плавающее), а развертка сама по себе. Поэтому, эффект не тот, не тот. ))


Эффект не тот из-за технологии ЖК матриц, ИМХО. Даже если железо способно вытянуть жёсткий лок на FPS монитора, без просадок.

Есть неплохой сайт с кучей тестов прямо в браузере: https://www.testufo.com/

ЭЛТ их проходит наотлично.
А на ЖК наблюдаются всякие артефакты. Начиная от дрожания краёв (ghosting) и заканчивая искажением цветов в движущейся сетке (не у всех матриц, тест Inversion Artifacts).
Причём наблюдаются на всех типах матриц, что я пробовал: TN/TN+Film/IPS/AMVA+. Ни 4мс, ни 2мс отклик не помогает (для 60fps должно по-идее 16ms хватать). Даже на 100/400hz телике всё хуже, чем на хорошем ЭЛТ.

Товарищ SkyDance уверяет, что на 144hz всё будет плавно, хоть и путается в определении Tearing-а. Верится в это слабо. А до физического теста я пока не добрался (надо ноут в магазины тащить, открыть сайт сами они не могут, пробовал уже).
kalsarikännit
Re[2]: Эльбрус - 8 ядер
От: swame  
Дата: 27.05.17 05:23
Оценка: 1 (1)
Здравствуйте, Gattaka, Вы писали:

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


LVV>>В Иннополисе: http://tehnoomsk.ru/node/2726

LVV>>Неужели доживу — куплю НАШ компьютер ?!
G>А как бы прикинуть сколько это по мощности? Сопоставить с i7 каким-нибудь?

Предыдущий пытается догнать Атом

https://geektimes.ru/post/270390/
Re[7]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 03.06.17 21:56
Оценка: 1 (1)
Здравствуйте, Kernighan, Вы писали:

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

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

K>А если не угадал, то откатывает результаты.

K>Достаточно подумать пять минут, чтобы понять, почему это лучше.
Проблема тут в том, что при неправильном предсказании CPU должен будет переделать всю работу. В случае параллельного исполнения одна ветка просто будет отброшена.

Минус в том, что глубина предсказания ограничена (на практике одним уровнем) и требуется больше ALU на выполнение ненужных операций (которые можно было бы израсходовать на ещё одно ядро).
Sapienti sat!
Re: Эльбрус - 8 ядер
От: pestis  
Дата: 26.05.17 06:13
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

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

Отлично! VLIW на 8 ядер это мегакруто. Надеюсь его выпустят на открытый рынок.
Re: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 28.05.17 16:16
Оценка: :)
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

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

Сейчас даже в мобильниках 8 ядер. Из-за чего шум то?
Re[3]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.05.17 18:48
Оценка: +1
Здравствуйте, Kernighan, Вы писали:

K>Уметь разъёмиться с буржуйским барахлом может быть и полезно, но необязательно.


Чтобы не разъёмиться с буржуйским барахлом, надо, кроме процессора, научиться делать полный набор периферии.
Re[4]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 28.05.17 19:04
Оценка: +1
Здравствуйте, Pzz, Вы писали:

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


K>>Уметь разъёмиться с буржуйским барахлом может быть и полезно, но необязательно.


Pzz>Чтобы не разъёмиться с буржуйским барахлом, надо, кроме процессора, научиться делать полный набор периферии.


Насколько полный набор?
В современном мире, если буржуйское барахло не работает, то это проблема буржуев.

Кроме того как-то непонятна истерика по поводу стандарта на разъёмы.
Стандарт общий, даже если его придумали не у нас.

Ну вот например есть USB.
1) Мы можем реализовать USB как есть.
2) Сделать его метрическим.
3) Перепаять эти 4 провода на разъём другой формы (кажется Эппл нечто подобное как раз сейчас и делает).
Это по прежнему будет тот же самый USB.

Eternet ещё есть.

Собственно и всё.

Конечно, какая-то экзотика работать перестанет.
Ну так она и у буржуев работать перестанет.
Вот у тебя сейчас есть во что воткнуть SCSI-контроллер?
Re[4]: Подскажите как сейчас принято искать работу
От: Kernighan СССР  
Дата: 28.05.17 21:32
Оценка: :)
Здравствуйте, Kesular, Вы писали:

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


K>>Мобильник иностранный, а Эльбрус — наш.


K>И что, их уже реально делают в РФ, а не на Тайване?


Делают в Зеленограде.
Самолично видел шайбу 30 см неразрезанных Эльбрусов.
Кристалл, кстати офигических размеров — больше квадратного сантиметра.
Не догадался сфотографировать. Мысли были про другое.

Правда они разные. Эльбрус — это собирательное название.
Кристаллы с самыми высокими параметрами наверняка пока делаются там а не тут.
Re: Подскажите как сейчас принято искать работу
От: Kernighan СССР  
Дата: 28.05.17 23:39
Оценка: :)
Здравствуйте, Kesular, Вы писали:

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


K>>Самолично видел шайбу 30 см неразрезанных Эльбрусов.


K>А всё остальное?


Весь остальной технологический процесс не видел.
Видел только готовый результат — компьютер, размером с ПиСишку..
Re[3]: Эльбрус - 8 ядер
От: pestis  
Дата: 29.05.17 05:40
Оценка: :)
Здравствуйте, Философ, Вы писали:

Ф>а что такого в VLIW на 8 ядер?


Детерменированный паралелизм. Для определенных задач позволяет добиться существенного прироста по сравнению с устарелой x86, так что я бы в него палочкой потыкал.
Re: Эльбрус - 8 ядер
От: Блудов Павел Россия  
Дата: 29.05.17 10:00
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

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


Для меня критерий НАШЕГО компьютера — наличие на клавиатуре отдельной кнопки, переключающей раскладку.
Re[6]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 30.05.17 10:24
Оценка: :)
Здравствуйте, Pzz, Вы писали:

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


K>>Насколько полный набор?


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


Ну и как ты думаешь, насколько это всё сложно?
Иногда это всё упихивается в один кристалл. Вообще в один.
На плате всего два кристалла сам — процессор и память. И это всё.

K>>В современном мире, если буржуйское барахло не работает, то это проблема буржуев.


Pzz>У нас не такая уж и большая доля на мировом рынке потребителей этого барахла.


А какая доля должна быть? Достаточно, что это доля выражается цифрами с девятью-десятью нулями?

K>>Вот у тебя сейчас есть во что воткнуть SCSI-контроллер?


Pzz>Да, есть.


Продолжаем разговор — а дискетку есть куда воткнуть? А пятидюймовую?
Re[5]: Подскажите как сейчас принято искать работу
От: Pzz Россия https://github.com/alexpevzner
Дата: 30.05.17 16:22
Оценка: +1
Здравствуйте, Kernighan, Вы писали:

K>Кристалл, кстати офигических размеров — больше квадратного сантиметра.

K>Не догадался сфотографировать. Мысли были про другое.

Хорошо, что не догадался. А то мы бы про тебя сейчас в новостях читали. Как про очередного бедолагу, которому шьют 20 лет за раскрытие государственной тайны. Многие бы писали об этом с одобрением. Дескать, нет оснований сомневаться в справедливости наших судов.
Re[3]: Эльбрус - 8 ядер
От: Ops Россия  
Дата: 30.05.17 18:38
Оценка: :)
Здравствуйте, Pzz, Вы писали:

Pzz>У жигулей пиписька мерится не в количестве ядер, а в количестве цилиндров. И в их совокупном объеме.


Не, в совокупном перекосе тормозных цилиндров.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[11]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 31.05.17 15:58
Оценка: +1
Здравствуйте, IID, Вы писали:

IID>Итого — никакого видимого прогресса, и i7 14нм 7го поколения греются так же охотно, как и 2го 32нм. (Базовая частота отличается всего на 0.8ггц, бустовая на 0.7ггц. Или на ~20%). TDP тоже схож, 91 / 95вт.


Это потому что нанометры уже довольно давно стали маркетинговыми, и фактически техпроцесс 14 нм мало чем отличается от 32. Пара элементов там размера 14 нм, а все остальные — куда как больше.
Re[6]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 31.05.17 18:42
Оценка: +1
Здравствуйте, pestis, Вы писали:

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


P>Непонятно как эти метрики привязать к тем абстракциям, с которыми работает компилятор. А так подход рабочий, ява машины чем-то подобным занимаются.


Ну процессор-то что-то с этими метриками делает. Значит, и софтварий может. Причем у него это лучше получится, ему не надо экономить транзисторы.
Re[10]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 01.06.17 09:00
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>>>Да, так как плотно работаю с созданием ASIC'ов.

K>>Ну так и что такое "техпроцесс"? Вот например "техпроцесс 0.13" — это что?
C>Обычно под этим понимается процесс создания маски и производство на её основе.

Ну вот на техпроцессе 14нм основная масса "деталей" выполнена по процессу, грубо, 32нм, еще немного по процессу 20нм и совсем чуть-чуть по 14нм. ))

Ручками делается именно такое распределение. Причем, процесс итеративный/многоразовый, т.е. много промежуточных образцов будет изготовлено перед конечным.

Это тебе не ASIC на 130 нм, которую достаточно один раз описать без ошибок на верилоге или чем-то подобном, типа систем от CMC.


K>>Ну так что такое техпроцесс и как он влияет на частоту?

C>Ну так объясняю очень просто — основной проблемой для поднятия частоты является тепловыделение. Оно примерно линейно падает с уменьшением размеров транзисторов. Дополнительно, падает время переключения транзисторов.

С уменьшением размеров растут так же токи утечки — происходит туннелирование через затвор. Так же мешает низкая подвижность зарядов, инжектирование ионов в окисел и больше всего — уменьшающаяся разница (в процентах) м/у пороговым напряжением и напряжением питания, т.е. надёжность (помехозащищённость) ключа падает.

Но это всё понятно. Самый главный побочный эффект — это снижение выходной нагрузки такого транзистора, что ведет к прямому вмешательству этого фактора в схемотехнику — у тебя есть ограничение на кол-во управляемых затворов и на их удалённость от управляющего транзистора. Всё что выше и/или дальше — оно требует буферрирования на дополнительном транзисторе (или двух, если без инвертирования), выполненных по более "толерантной" технологии, что влечет за собой лишнюю задержку по всей цепи.


C>Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA.


Можно, потому что это 22 нм, потому что это готовое изделие от производителя. Но коммерчески-доступна для небольших и средних сторонних партий ASIC лишь 0.13 мкм и выше. А кто заказывает бОльшие партии по процессу хотя бы 65нм — тех по пальцам рук пересчитать можно и там индивидуальные контракты.



C>>>Что конкретно под кого подгоняется? Если не заниматься экстримом с последними поколениями тех. процессов, то производители чипов почти полностью взаимозаменяемы.

K>>Вот и узнай, что и под кого подгоняется. Ты многих вещей просто не знаешь.
C>Наш ASIC делает TSMC.

По какому процессу и какая партия?


C>Следующее поколение делает GF. Угу, очень большая разница.


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

Не вводи коллег в заблуждение, кароч, — это как компилять, например, высокоуровневый С++ код под разную процессорную архитектуру. Если аналогичные низлежащие библиотечные ф-ии реализованы на обеих архитектурах и делают ровно одно и то же — то можно компилять, ОК. Но итоговый бинарник всё-равно будет сильно разный.
Re[7]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 01.06.17 09:04
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>В итоге, VLIW для CPU в индустрии умер совсем везде. Он неплохо сейчас живёт разве что только в области GPU, где примерно половина встроенных GPU построена на VLIW-подобной архитектуре.


И в сигнальных процессорах, где основная (и фактически единственная) операция, это вычисление многочленов вида:
sum += a0*b0+a1*b1+a2*b2+...

Да, процессор Эльбрус — это мультимедиа-процессор. Как раз подходит для распознавания целей и управления ракетами. ))
Ну и обработка видео-аудио тоже, ес-но, если речь о гражданском применении. Тут он просто бомба.
Re[5]: Эльбрус - 8 ядер
От: Osaka  
Дата: 01.06.17 21:36
Оценка: :)
LVV>>>>>Неужели доживу — куплю НАШ компьютер ?!
O>>>>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.

K>>>А почему не восьмиядерный Су-27?

O>>Возможно, что-то спасает военная приёмка. Но недавние Протоны сигнализируют, что недолго осталось и ей.

K>Ну, Протон, конечно крыть нечем. Деграданс технологической культуры силы видно невооружённым глазом.

K>Только не надо называть это традицией. Наша традиция как раз состоит в расстрельной ответственности.
Наша традиция — отсутствие культуры требования справедливости. Это приводит не только к "я начальник — ты дурак" / "тащи с завода каждый гвоздь", но и — через подавление такого качества как принципиальность — к научно-технической отсталости. http://economicsandwe.com/C95829DB2F00602D/

ампутировав человеку нравственные ориентиры, отучив его думать о Справедливости, американская масонерия повредила то, что изначально не хотела повреждать: связное и последовательное, продуктивное с точки зрения технического результата мышление.

Re[10]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 02.06.17 05:28
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>В твоём компе/ноуте (или с чего ты там пишешь) бОльшая часть процессоров выполнена как VLIW/RISC. В радиоблоке, на сетевухе, звуковой чип и т.д.

VLIW/RISK — LOL.
Sapienti sat!
Re[13]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 02.06.17 20:39
Оценка: +1
Здравствуйте, 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 — это немного отдельная песня.
Re[4]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 02.06.17 20:50
Оценка: :)
Здравствуйте, Kesular, Вы писали:

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

K>Так что, единственные процессоры, с которым он может хоть как-то потягаться — мобильные.

Тебя в гугле забанили?
На многих классах задач Эльбрус работает на уровне i7 при частоте в 4 раза меньшей.
А на некоторых классах задач даже быстрее, например, выполняя один из алгоритмов GC.
Re[9]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 03.06.17 10:10
Оценка: +1
Здравствуйте, Pzz, Вы писали:

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


K>>Вот очень характерный пример, как можно знать слова и не понимать их смысл.

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

Pzz>Причин минимум две:

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

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

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


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

Тебе слово Transmeta о чём-нибудь говорит?
Re[8]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 03.06.17 21:13
Оценка: :)
Здравствуйте, Kesular, Вы писали:

V>>в основном вычислительных/математических и мультимедиа) получались в среднем не хуже, а иногда даже серьёзно лучше

K>То есть тех, где прекрасно справляется GPGPU

Не справляется. У него архитектура не подходящая и большие задержки по передаче данных.


K>и исполнять их на обычном универсальном процессоре нет практически никакого смысла.


И вот опять сугубо умозрительные рассуждения.
Опять это фантазёрство...


V>>А у тебя какие будут доказательства всей твоей голословности в этом топике?

K>Не хами. Что конкретно я должен доказать?

Ты много чего тут успел понаписать, эдак тебя понесло-то.
Я лишь хочу поинтересоваться источником твоего вдохновения.
Re[17]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 03.06.17 23:00
Оценка: +1
Здравствуйте, m2l, Вы писали:

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

V>>Исходник на С:
m2l>Я не знаю к чему ты его привел.

Не удивительно.
Поэлементное умножение векторов с накоплением суммы — это основная операция при обработке информации и фактически единственная.

Это происходит в задачах ИИ, фильтрации, регрессии/корреляции, прямого и обратного преобразования Фурье, наложения оконных и вероятностных ф-ий, перемножения матриц, преобразования координат и т.д. до бесконечности. Поэтому и был взят именно этот код в ответ на просьбу привести пример. Любое кодирование/раскодирование аудио-видео, фазовое детектирование и автоподстройка WiFi/Bluetooth и т.д. выполняется именно так.

Или разложение тригонометрических ф-ий в ряд Тейлора — берётся x*x и ряд известных коэф разложения некоей конечной длины — тоже будет операция умножения со сложением, где каждый новый член ряда получается из предыдущего. Например, четные и нечетные члены ряда можно считать параллельно, потом сложить.


m2l>Скомпилится в любую архитектуту...


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


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

m2l>Отлично, ассемблер TMS. Какие их dsp на архитектуре VelociTY стоят в iPhone 5, на который ты ссылаешься?

Ядра TI занимают бОльшую долю рынка всех существующих DSP. Поэтому, разумеется, я привёл одну из архитектур TI. Разумеется, этих архитектур более одной, но приводить в кач-ве примера стоило современный мейнстрим, если речь о сегодняшнем положении дел.

А так-то можно было привести архитектуру AltiVec от Apple/IBM/Motoolla. Ядра с этой архитектурой включают, например, в PowerPC и Cell. Но там примерно то же самое:

Согласно документации Apple, AltiVec в реализации на процессорах G4 и G5 может выполнять восемь 32-битных FLOPS за цикл,


Или еще можно было привести пример CEVA-XC архитектуры (тоже VLIW):
http://www.ceva-dsp.com/product/ceva-xc4500/
которая используется в микросхемах потребительского уровня WiFi/Bluetooth от Broadcom. Про последнюю контору ты должен был как минимум слышать.


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

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


m2l>Если честно я вообще не слышал распрастраненных моделей TMS для "Bluetooth/WiFi/Звуковой чип/камера".


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

Ну и в плане эрудиции тоже вопросы, однако. Уже лет 15-20 DSP-микропроцессоры в "чистом виде" практически не применяются. Чаще в составе некоей SoC, где могут жить, в том числе, ядра того же ARM или MIPS. А даже если взять какой-нить "отдельный" современный DSP-процессор, то внутри него окажется чуть ли не весь южный и северный мост (в терминах архитектуры Интел).

Ну и гугл еще работает, если что. Вот первая строчка в поисковике по видеопроцессорам от TI:
http://www.ti.com/lsds/ti/processors/dsp/media_processors/davinci/products.page


V>>Но не суть, действительно интересующимся предлагаю погуглить, например, по "TMS320C6000 assembly optimizer".

m2l>Вот смотри, меняем один символ и получаем TMS320C5000. Который не разу не VLIW

Который на этапе т.н. "компоновки команд" делает VLIW.
Просто у него 2 операции за раз, а не 8.


m2l>но производится и используеться.


И уже лет 15 как не является мейнстримом.


m2l>И выходит, твоё:

m2l>

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

m2l>Ложно.

Ключевое выделил.


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

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

— Петька, приборы!
— 42!
— что "42"?
— а что "приборы"?

Ты бы хоть марку чипов назвал для начала разговора.


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

m2l>Не думаю, что там что-то менялось.

А подумай.


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

m2l>Ты понимаешь, что из утверждения VelociTY VLIW архитектура, не следует:
m2l>

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


Не согласен — опровергай, какие проблемы?
Я и так уже слишком много вводных дал для твоего простого несогласия.
А от тебя пока ровно ноль инфы.
Нечестно как-то...


m2l>Лично мне как-бы побоку CISC/RISC/VLIW


тогда зачем всё это тебе? скучно? ))


m2l>гранитцы между ними эфимерны. Но если ты хочешь делиться своими знаниями


Инфой обычно делятся перед любопытной/благодарной аудиторией или хотя бы в честном споре.
Увы, такое ощущение последние лет 10, что умение спрашивать и навыки честного спора более не в цене.
Re[10]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 03.06.17 23:04
Оценка: +1
Здравствуйте, netch80, Вы писали:

K>>Да, кстати, ты знаешь, что у Эльбруса есть специфичная фишка — тегированная память?

N>О да. Редкостно бесполезная реализация.

Можно аппаратно защититься от проходов по памяти.
Не так уж и бесполезно.
Re[22]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 06:22
Оценка: :)
Здравствуйте, vdimas, Вы писали:

N>>Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом)


V>Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.


V>RISC — это философия построения процессоров, хотя сама аббревиатура изначально появилась от философии формирования системы команд. Но сейчас хватает RISC-процессоров, у которых количество команд поспорит с оными из CISC-мира.


Я, извини, вцеплюсь в это "но". Если оно для тебя существенно, то тут недоразобрался явно ты, причём как раз на самой поверхности, раз такое заявляешь. Или уже всё забыл.
RISC — это не мало команд. Это _простые_ команды, которые легко поставить в конвейер, нарисовать зависимости, и так далее. Это когда у тебя нет mov @-(r2), @(r4)+, которую всё равно надо разложить на два доступа к памяти и один к регистрам, а всё надо писать отдельно.
При этом количество самих команд в ISA может быть больше любого равного по возможностям CISC (особенно это любят делать за счёт модификаторов — как в ARM изменение регистра или флажки во всяких CSINV).

А вторым уже выступает то, что есть стандартный метод упаковки команд в конвейер, который в классическом (Berkeley) исполнении — одна команда на такт, но 5 тактов на команду. Но как только начинается проблема торможения на памяти или на непредсказуемо долгих командах, там вводят полноценное OoO, ничуть не меняя общего подхода. Ни старшие ARM, ни старшие MIPS, ни Power, при всём различии их подхода, не перестают быть RISC от того, что у них OoO.

Если же "но" было несущественно, то к чему вообще этот кэпский пассаж про количество команд?

N>>или вообще что-то очень оригинальное (и слабо соответствующее действительности) думаешь про RISC. Оба варианта меня смущают.

V>Ну вот чтобы не смущало, надо отделять мух от котлет.

Вот и отделяю — и убедился, что ты опять что-то левое вспомнил.

V>>>Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях.

N>>Не во всех RISC.
V>Почти во всех с конвейером ненулевой длины.

В новых архитектурах от delay slots отказываются, ибо польза сомнительна, а диверсионность однозначна. Даже в Alpha его уже не сделали. Фактически, он остался в тех, что разработаны более 22 лет назад (то есть совсем старьё).

N>>И откуда тут взялась идея про побочные эффекты?

V>От конвейеризированности в отсутствии планировщика, вестимо.
V>Всё-таки философия RISC — это минимизация "побочных" устройств в процессоре (помимо целевых-исполнительных).

А даже если так — транслятор в RISC занимает по-любому больше в разы, чем даже продвинутый OoO. Разумеется, если хотим, чтобы он работал быстрее одного байта за такт

V>>> Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду".

N>>Если ты про Thumb в ARM, то это больше похоже на вариант
V>Не важно, на что это похоже. Это один из способов условного ветвления без сброса конвейера.
V>Ключевое выделено.

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

V> Безусловные ветвления отслеживаются еще на этапе предвыборки.


Не раньше декодирования, вообще-то. И безусловные переходы тоже имеют delay slots, там, где последние вообще применены.

V>>> Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.


N>>Delay slot на 5 команд? Оригинально ты же перед этим показывал, что это VLIW. Зачем это называть конвейером, когда это пакет одновременно исполняющихся команд?

V>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.

Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме). Во-вторых, разные версии могут иметь разные особенности (я не могу априорно полагать, как в x86, что код, однажды сделанный под проц 20-летней давности, будет работать).
Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд? Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?

V>>>Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))

N>>Видимо, конфликтует только в твоих представлениях, в которых RISC не может иметь суперскалярность.
V>Не может. Еще раз, медленно. В основе суперскалярности лежит абстракция исходного кода от кол-ва исполнительных устройств. Это принципиально.

Предположим, хотя это не самая важная часть.

V> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.


Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.

V>Помимо RISC и CISC есть еще гибридная технология со своим названием — MISC, может тебя это смущает?


"Minimal Instruction Set Computer"... как-то она не очень гибридная
Так как область очень туманная — давай ссылку на то, какой именно "MISC" ты имеешь в виду, или говорить не о чем.

N>>Или они для тебя уже не RISC? Тогда вводи свои термины специально для этой дискуссии.

V>Зачем? Есть вики, там вполне доступно и в этом вопросе правильно.

Вики — это полезно, да. Особенно когда ты на неё ссылаешься
"A common misunderstanding of the phrase "reduced instruction set computer" is the mistaken idea that instructions are simply eliminated, resulting in a smaller set of instructions." Против твоего проезда по количеству команд.
"Nowadays the branch delay slot is considered an unfortunate side effect of a particular strategy for implementing some RISC designs, and modern RISC designs generally do away with it." Против дифирамбов слотам задержек.
"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?

V>>>Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один такт (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))

N>>Спасибо, кэп. И что?
V>Дык, в этом состоит принципиальное отличие RISC от суперскаляра/СISC. Т.е. отличие не в системе команд, а в способе исполнения этих команд.

Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?
А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?
Они еретики и должны быть разрушены? Или им надо давать другое имя?

V>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.

N>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS

"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100 and the Texas Instruments ASC, which could operate on a "vector" of data with a single instruction. Vector processing was especially popularized by Cray in the 1970s and 1980s."

V> и имел собственную аббревиатуру. Затем в других архитектурах — DEC Alpha и PowerPC, где под векторные вычисления явным образом были введены дополнительные процессорные элементы, т.е. доступные для непосредственного их программирования. Их даже иногда называют "DSP-сопроцессоры".


А в MIPS, значит, они не были "доступные для непосредственного их программирования"?

> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.


То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?

> Т.е. как по мне — это просто стыренная из другой предметной области аббревиатура. Маркетинг, мать его так. ))


И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?

V>В терминологии оно как? Кто первый, того и тапки. Я просто показываю, откуда "оно" взялось.


N>>Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию


V>Да, я в курсе, что иногда умею разродиться постами, "режущими слух".

V>Зрите в корень, как грится, и да пребудет с вами сила. ))

Если бы ты ещё его резал иначе, чем кривым ржавым лобзиком по маршруту пьяной вороны...
The God is real, unless declared integer.
Отредактировано 06.06.2017 7:16 netch80 . Предыдущая версия .
Re[24]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 14:00
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Как же скучно опять...

V>Гуглить по "ARM is not RISC anymore".

А, ты опять в своём мире. OK.

V>Дальше не читал, сорри. Разбирай свою кашу сам.


The God is real, unless declared integer.
Re[24]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 16:05
Оценка: :)
Здравствуйте, vdimas, Вы писали:

N>>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?

V>PowerPC изначально был RISC, как и ARM.

Ага. Вот я и достучался до ответа — ты считаешь, что с суперскалярностью оно уже не RISC. В то же время как общераспространённая точка зрения, что суперскалярность не отменяет RISC. Хорошо, буду считать это ответом.

V>Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора.

V>Неужели после первого моего замечания не стало ясно:
V>

V>Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.


V>Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.


Это залёт только в твоих глазах, а я не собираюсь ставать твоим учеником (мне ещё моя психика дорога). OK, картина ясна.

N>>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100

V>Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))

Контекст исключительно микропроцессоров в этой ветке — твоё изобретение. Так что "всё ещё" не в тему.

>>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.

N>>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?
V>Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.

Именно! И это уже камень в огород VLIW, который ты агитируешь всюду, включая мир неизбежного OoO.

V>Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но.


А почему? Митра запретил сделать аппаратный накопитель тех же снятых импульсов?
Пусть готового нет, но можно FPGAʼшку запрограммировать, логика там примитивнейшая. А с таким подходом, как у тебя, можно потребовать и все шины от RS232 до ISA и USB побитно исполнять.

V> Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов).


Я такие циклы фиксированной длительности помню из более знаменитого источника — драйвер диска для Apple II. 32 или 40 тактов на байт, в зависимости от части дорожки, циклы с NOP-PHA-PLA-etc. для выдерживания ровно нужного количества тактов 6502. И что, это хорошо?
По-моему, это всё тупой закат солнца вручную.

V> 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично.


Шаговый двигатель там тоже управлялся, было. Аж ностальгия скоро пробьёт. Зато как сейчас хорошо всей этой дурью не маяться.

V> Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.


Наоборот, дополнительные блоки это прогресс, а не каменный век.

N>>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?

V>Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.

Чем же это лучше? Если нельзя развивать архитектуру с тем, чтобы не переписывать код?

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

V>Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.

В случае RISC, мне не лень (пока что; станет лень — просто перестану отвечать). Мне очень не лень, потому что ищу сказанные совершенно побочные, но ценные для будущих раскопок слова.
В случае VLIW, мне интересно содержимое, но пока что очень абстрактно (не думаю, что придётся этим заняться в ближайшие годы — ни в виде IA64, ни в виде этих DSP). Потому я его сильно не касаюсь, только в пределах предыдущих зацепленных в споре вопросов. Формат позволяет понять, в какую сторону уже серьёзно гуглить.

V>Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.


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

V>Хотя, когда-то давно, помнится, ты этими навыками обладал.

V>Обленился ты, кароч, по самое нимогу. ))

Я ли изменился, или кто-то другой?
The God is real, unless declared integer.
Re: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 06.06.17 22:09
Оценка: :)
Здравствуйте, Kesular, Вы писали:

N>>Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым"

K>А, ну-ну. Тогда и на винде можно делать очень даже Hard realtime

Можно запросто на уровне ядра и ядерных дров.
Только не факт, что вообще имеет смысл вводить разделение на уровни исполнения в специализированной железке. Бред же...


K>если записать в спеке, что любая операция должна выполняться не более секунды.


1. у прерываний есть приоритеты
2. код с нужными привилегиями может запретить некие прерывания на некоем участке.

Хотя, этот спор заведомо ни о чем. ))

Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...
Re[26]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 07.06.17 05:24
Оценка: -1
Здравствуйте, vdimas, Вы писали:

N>>Я такие циклы фиксированной длительности помню из более знаменитого источника — драйвер диска для Apple II. 32 или 40 тактов на байт, в зависимости от части дорожки, циклы с NOP-PHA-PLA-etc. для выдерживания ровно нужного количества тактов 6502. И что, это хорошо?

N>>По-моему, это всё тупой закат солнца вручную.
V>Дык, ничего не изменилось с тех пор. Просто сейчас аналогичная программа перенесена из ЦПУ в контроллер, расположенный прямо прямо на диске.

А с другой стороны с ним хочет общаться ЦП через SATA/USB/etc... опс, а чего это у нас устройство не отвечает? О, два контроллера. Вместо одного. И у каждого по процессору. Привет, синхронизация.

N>>Шаговый двигатель там тоже управлялся, было. Аж ностальгия скоро пробьёт. Зато как сейчас хорошо всей этой дурью не маяться.

V>Кому хорошо, тебе лично?
V>Значит тебе интересней другой род программирования, только и всего.

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

V>>> Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.

N>>Наоборот, дополнительные блоки это прогресс, а не каменный век.
V>Прогресс — это удешевление конечного устройства и ускорение цикла разработка->продажа.
V>Всё остальное называется "программист ниасилил". ))

Нет, это называется — китайский дерьмогон.
Всё на процессор! Урежем спеки, купим самое дешевое *овно, вобьём стандартный основной план работы в код. На полдоллара дешевле конкурентов, уря!
А потом и начинается — то вдруг errata "ой, мы поспешили сказать, что поддерживаем 8 параллельных запросов, урежьте до 4", или "хотите туннель? лимиты разделить на 3. шифрование? ещё на 5. да, мы этого в основной спеке не скажем, только в дополнительной и под NDA."
Зато быстро, хе-хе.
Я теперь понял, на кого ты работаешь, и почему такую идеологию продвигаешь.

N>>>>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?

V>>>Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>>Чем же это лучше? Если нельзя развивать архитектуру с тем, чтобы не переписывать код?
V>Для конкретного озвучиваемого железа это не важно.
V>Всё-равно под каждую конкретную железку будет свой "драйвер".

Агащазз. Перенесут готовое и не задумаются. Даже если без тебя. Arian и Therac-25 на поверхности, а сколько таких не попало в газеты?

N>>Ты же делаешь вид, что всё всегда знаешь

V>По темам, по которым высказываюсь и в тех объемах, в которых высказываюсь?
V>ИМХО, это единственно адекватная стратегия.

Спасибо, занёс в протокол

V>Остальное должно быть или прямо поставленными вопросами (без ужимок, прыжков, подъ-бок, желания "поймать" и т.д.) или read-only.


Ну да, только можно самого себя по 2 раза на день опровергать Зато прямо и честно
The God is real, unless declared integer.
Re[27]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 09:42
Оценка: -1
Здравствуйте, netch80, Вы писали:

N>И сидят три процессора и рулят каждый своим шаговым двигателем, отсчитывая nopʼами задержку... ой, нет трёх процессоров? Какой облом. Значит, таймеры в софте, очередь ближайших срабатывающих (ну, сделана массивом или вообще явным тестом


Каким "тестом"?
Что тестировать-то?
Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.

Причем, в одном слове можно располагать несколько счетчиков обычно.


N>на каждой итерации — неважно)? А как же пункт 1?


Это ты слишком сложные для себя вопросы пока задаешь. ))


V>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).

N>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?

Любой, с длиной конвейера больше 2-х, вестимо.
В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?


N>Там должны быть кэш DRAM, OoO исполнение команд... ой, а откуда это он у нас такой? Кто его сюда поставил?


Ну вот опять. В неприличной форме напрашиваешься на грубый ликбез.
Скучно...
Re[3]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 07.06.17 16:11
Оценка: :)
Здравствуйте, Kesular, Вы писали:

V>>Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...

K>Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.

Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))
Спасибо, ты сделал мой день.
Re[30]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 07.06.17 19:54
Оценка: +1
Здравствуйте, vdimas, Вы писали:

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


V>>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.

N>>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.

V>Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.


Метод реализации тут действительно не сильно важен. Просто код вида

  while (do1 || do2 || do3) {
    if (do1) { if (++cnt1 == lim1) { do1 = work1(); } else { delay_some(); } }
    if (do2) { if (++cnt2 == lim2) { do2 = work2(); } else { delay_some(); } }
    if (do3) { if (++cnt3 == lim3) { do3 = work3(); } else { delay_some(); } }
  }


(ты ведь такое имел в виду?) Так это, конечно, реализуемо, но не отвечает ни на один из поднятых мной вопросов о качестве синхронизации внешних акций в таком исполнении.

V>Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.


Ну вот я даже код навёл. Теперь скажи, что в нём не так, по твоему мнению. Он писался максимально близко к тому, как ты объясняешь. (Я-то могу сказать, что по-моему в нём не то, но важно именно то, куда ты пойдёшь исправлять.)

V>>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).

N>>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>>Любой, с длиной конвейера больше 2-х, вестимо.
N>>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.
V>Ага, но ты же коммунист, Петька! — и пулемёт застрочил вновь.
V>Удивляют порой коллеги верой в мифы и вообще вот этот подход — "оно там как-то само всё образуется".
V>Да никогда еще ни разу "само собой" ничего не образовалось. Всегда надо включать моск.

Ну вот я и включаю. Поведение подобных процессоров определено для такта, не так ли? Если на такте t поднялось прерывание таймера, то, например, на t+2 его заметил блок прерываний процессора, на t+3 уже пошла грузиться команда с нового адреса. (Предполагаю, что если думают о скорости, то отработка прерываний это сохранение PC+PSW в служебные регистры процессора и загрузка новых из таких же служебных, оперативная память тут не используется.) Декодиться и исполняться она будет, например, от t+4 до t+7. И что, эта поправка не может быть заложена в задание таймера?

N>>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний


V>Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.

V>Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.
V>>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?
N>>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.

V>Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.


Да видел я их. Я не запоминаю, за отсутствием прямой необходимости, в какой из современных рахитектур какое именно убожество применено и выдано за новейшие достижения нейтринной мегалоплазмы, но общие тенденции отслеживаю. Конкретно по таймерам, единственная нормальная реализация это счётчик времени (в нормальном режиме вообще не корректируемый) плюс декременторы (один или больше), как в PowerPC, или компараторы (на малость беззнаковой разницы, а не просто на больше-либо-равно). Почти нормальная — это с компаратором на больше-либо-равно (как в HPET). Если же счётчик времени одновременно и декрементор, как было в i8254 и как сейчас делают во многих встраиваемых — он кроме как на подтирку и не годится.

V>Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).


Ну тогда это порочный круг. Одни "спецы" вместо нормальных таймеров подсовывают тошнотворные пародии. Другие не просто соглашаются с этим работать (вместо того, чтобы вывалять первых в дёгте и перьях), но и хвалят свои решения, которые обходят проблемы этих пародий.
И это не только в таймерах, просто мы сейчас говорим о них.

N>>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".

V>Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.

Отлично. А теперь скажи, что получится, если у тебя будет необходимость выполнить воздействие двум разным двигателям с интервалом меньше, чем эта длительность отработки одного двигателя. Например, work1() и delay() в коде выше — по 2 мкс, а тебе надо что-то сделать для 1 и 2 с разницей в 1 мкс. Будешь специально писать отработку подобного варианта? Ну так она в итоге ничем не будет отличаться от решения типа "выбрать ближайшее время из трёх и подождать до него".

N>>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.


V>Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.

V>В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.

Я и прикинул несколько вариантов. И все они кривые. Видимо, объяснять у тебя таки проблемы. А самому показать псевдокод ты тоже не хочешь — корона свалится.

V>Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))


С чего идеи про игнор? И что зависит от качества программистов для этих вспомогательных, кроме очевидного фактора корректности результата?

V>Такие программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.


Я уже так давно не работал с SIP, что не могу понять, это в мой огород камень или нет. Но длинных цепочек ifʼов в своём коде я что-то не помню.
The God is real, unless declared integer.
Re[27]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 21:55
Оценка: +1
Здравствуйте, IID, Вы писали:

IID>Ага.

IID>Т.к. команду посередине не прервёшь, а команда HALT (ожидания прерывания) внутри устроена как бесконечное исполнение NOP-ов (4 такта).

Ну да, ну да, там же NOP 4 такта. Ну, тут достаточно иметь возможность получить разницу в 1 такт м/у какими-нить двумя командами.
Спасает конечно то, что развертка работает от той же исходной тактовой, что и процессор.


V>>Жаль, что частота развертки моего экрана не кратна исходной частоте развертки.

IID>Включи HD. Иначе ютуб половину кадров выкидывает

HD 1080 ))
Всё-равно не то.
Даже на любом из эмуляторов — не то.
Надо саму железку к честному PAL-телеку подключать. ))
Просто, кто не видел подобные вещи вживую — они по ролику ничего не поймут.


V>>Кстате, раздражает в современных 3D-играх отсутствие той самой плавности смещения картинки и вообще отсутствие плавности любой анимации, которая была когда-то. Сейчас в играх FPS само по себе (да еще и плавающее), а развертка сама по себе. Поэтому, эффект не тот, не тот. ))

IID>Эффект не тот из-за технологии ЖК матриц, ИМХО. Даже если железо способно вытянуть жёсткий лок на FPS монитора, без просадок.
IID>Есть неплохой сайт с кучей тестов прямо в браузере: https://www.testufo.com/

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


IID>ЭЛТ их проходит наотлично.

IID>А на ЖК наблюдаются всякие артефакты. Начиная от дрожания краёв (ghosting) и заканчивая искажением цветов в движущейся сетке (не у всех матриц, тест Inversion Artifacts).

По-идее, если ЖК-монитор вносит строго фиксированную задержку, то от ghosting можно было бы избавиться — он же является индикатором неравномерной скорости движения.


IID>Причём наблюдаются на всех типах матриц, что я пробовал: TN/TN+Film/IPS/AMVA+. Ни 4мс, ни 2мс отклик не помогает (для 60fps должно по-идее 16ms хватать). Даже на 100/400hz телике всё хуже, чем на хорошем ЭЛТ.


Т.е. откуда-то берется неравномерность частоты развертки?
(с инверсиями и пост-свечениями всё понятно, но хотя бы дрожание надо как-то уметь побороть?)
Re[31]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 23:00
Оценка: :)
Здравствуйте, netch80, Вы писали:

V>>Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.

N>Метод реализации тут действительно не сильно важен. Просто код вида
N>
N>  while (do1 || do2 || do3) {
N>    if (do1) { if (++cnt1 == lim1) { do1 = work1(); } else { delay_some(); } }
N>    if (do2) { if (++cnt2 == lim2) { do2 = work2(); } else { delay_some(); } }
N>    if (do3) { if (++cnt3 == lim3) { do3 = work3(); } else { delay_some(); } }
N>  }
N>

N>(ты ведь такое имел в виду?)

Конечно нет.
Условного ветвления не требуется в таких алгоритмах, по крайней мере в коде оперирования софтовыми таймерами.
Достаточны манипуляции с битами и простые арифметические операции:
unsigned step1;
unsigned step2;

unsigned acc1=0;
unsigned acc2=0;

while(true) {  
    acc1 += step1;
    acc2 += step2;
    byte result = ((acc1 & 0x80000000) >> 30) | ((acc2 & 0x80000000) >> 31);
    outp(some_port, result);

    calc_next_values_of_step1_and_step2();
}

Заметь, что пара управляющих сигналов выводится синхронно.

Ну а для быстродейдствующей обработки какой-нить детали сначала высчитывается некий "батч" (как раз можно использовать время на обратный ход инструмента), а потом этот батч прогоняется, т.е. остальная часть может выглядеть примерно так:
unsigned steps1[];
unsigned index1 = 0;
unsigned steps2[];
unsigned index2 = 0;

void calc_next_values_of_step1_and_step2() {
    index1 += ((acc1 & 0x80000000) >> 31);
    step1 = steps1[index1];

    index2 += ((acc2 & 0x80000000) >> 31);
    step2 = steps2[index2];
}


Понятно, что операция навроде ((acc1 & 0x80000000) >> 31) вычисляется в реальности лишь однажды или вообще заменяется условным исполнением/пропуском (и всё-равно лишь однажды). Т.е. на асме это всё еще выразительней получается, бо в C++ слишком многословно и не верно. Там надо признак переполнения прибавить к индексу. Просто для выражения этого в С потребуется заводить переменную двойной ширины только ради опроса младшего бита старшего слова.


N>Так это, конечно, реализуемо, но не отвечает ни на один из поднятых мной вопросов о качестве синхронизации внешних акций в таком исполнении.


Согласен, твой код не отвечает ни на один из вопросов.
Более того, он позволяет делить тактовую частоту (пусть нам требуется в некоей задаче генерировать некую частоту) лишь на целые числа.


N>Ну вот я даже код навёл. Теперь скажи, что в нём не так, по твоему мнению.


В нём не так то, что ты хоть и работал со звуковой областью когда-то, но конкретно темы обработки звука не касался, похоже. Потому что если бы касался, то ты хотя бы раз в жизни писал генератор синусоиды, который пишется примерно так:
unsigned phase = 0;
const unsigned delta = ulong64_t(MAX_UINT32)*freq/sample_rate;

unsigned sin_gen_next() {
    return fixed_point_sin(phase+=delta);
}

Заметь, не надо сравнивать на каждом шаге и по результату отнимать 2*PI.
Классика вычислений с фиксированной точкой — это масштабирование любых данных. В данном случае диапазон 0..2*PI отмасштабирован на диапазон 0..MAX_UINT. Причем, получили честную точность 32 разряда, в отличие от точности 24 разряда в случае использования float.


N>Он писался максимально близко к тому, как ты объясняешь.


Я вижу максимально далёкий код.


N>Ну вот я и включаю. Поведение подобных процессоров определено для такта, не так ли? Если на такте t поднялось прерывание таймера, то, например, на t+2 его заметил блок прерываний процессора, на t+3 уже пошла грузиться команда с нового адреса.


А еще надо запихать текущую инструкцию в стек.
А еще конвейер у нас может быть больше, чем 2 стадии, например 4 стадии. Итого, t+3+4. И запрет прерываний, пока один из таймеров обрабатываем.


N>(Предполагаю, что если думают о скорости, то отработка прерываний это сохранение PC+PSW в служебные регистры процессора и загрузка новых из таких же служебных, оперативная память тут не используется.)


В контроллерах его внутреннюю оперативную память можно рассматривать как продолжение файла регистров, там точно такая же скорость обращения, бо это регистровая память, как L0.


N>Декодиться и исполняться она будет, например, от t+4 до t+7. И что, эта поправка не может быть заложена в задание таймера?


А как ты думаешь, почему у "самоделкиных" их фрезерные и токарные станки работают примерно в 10-100 раз медленней, чем промышленные экземпляры?
Может от того, что при выдаваемой ими ужасной временнОй точности управления приходится в 10-100 раз снижать скорость перемещения резака относительно детали? ))

Разумеется, любую погрешность можно учесть и компенсировать, но я ж сходу упомянул, каким именно образом.


N>Да видел я их. Я не запоминаю, за отсутствием прямой необходимости, в какой из современных рахитектур какое именно убожество применено и выдано за новейшие достижения нейтринной мегалоплазмы


Дык, в архитектуре Intel с таймерами еще на пару порядков всё печальнее. Там вообще полная ж-па. У тебя на сегодня нет никакой возможности узнать текущее точное время. У тебя на выбор только правильно идущие часы с точностью ~1/64 сек или еще есть часы с хорошей точностью, но всегда идущие неправильно (query performance counter).


N>это счётчик времени


Ага. Тактовая этого счётчика какова? А разрядность? А время доступа к нему?


N>Ну тогда это порочный круг. Одни "спецы" вместо нормальных таймеров подсовывают тошнотворные пародии. Другие не просто соглашаются с этим работать (вместо того, чтобы вывалять первых в дёгте и перьях), но и хвалят свои решения, которые обходят проблемы этих пародий.

N>И это не только в таймерах, просто мы сейчас говорим о них.

Это дело привычки к определённому классу задач. Когда занимаешься этим постоянно, то подобные задачки решаются уже мозжечком, фактически не потребляя квантов внимания.

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

Ты же взял некие абстрактные критерии, где ни один из них не является важным для обсуждаемой предметной области.
Да тут не то, что в области низкоуровневых микроконтроллеров... тут даже в деле написания банальнейших дров под высокоуровневый ЦПУ на твоей машине — и уже твои критерии не работают. Ты слишком прикладной программист.


N>Отлично. А теперь скажи, что получится, если у тебя будет необходимость выполнить воздействие двум разным двигателям с интервалом меньше, чем эта длительность отработки одного двигателя. Например, work1() и delay() в коде выше — по 2 мкс, а тебе надо что-то сделать для 1 и 2 с разницей в 1 мкс.


Выделил ошибку.
Не у меня, а у тебя.
У тебя там не получится ничего, ес-но, как ты сам абсолютно правильно сейчас подметил.
Только зачем тогда было приводить заведомо неработающий код?
А потом ты обижаешься, когда я недвусмысленно намекаю, что ты ведешь обсуждение более чем странно, где странностью является добровольная бестолковость какая-то... ХЗ... никогда этого не пойму...


N>И что зависит от качества программистов для этих вспомогательных, кроме очевидного фактора корректности результата?


Тут тоже ХЗ. Но есть наблюдения — примерно половине программистов этот род деятельности не даётся вообще никак ни под каким видом. Хоть кол на голове им теши или даже под страхом расстрела. Казалось бы — там всё СЛИШКОМ элементарно... человек запросто пишет довольно-таки большие проги, использует сложные библиотеки и т.д... А вот просто пару бит туда-сюда погонять — полный ступор.


N>Я уже так давно не работал с SIP, что не могу понять, это в мой огород камень или нет. Но длинных цепочек ifʼов в своём коде я что-то не помню.


Если "раскрыть все скобки" (сделать все ф-ии инлайными в том коде), то будет просто масса ветвлений и всё.
Собсно, я еще тогда подробно объяснял этот фатальный недостаток SIP — это отсутствие встроенных ср-в комбинирования сценариев. Любая комбинация сценариев должна быть прописана в очередном расширении стандарта. Вот что я называю каменным веком. Протокол SIP был разработан, очевидно, потребителями технологий, а не производителями. Они взяли RTP, который был до них, они взяли TCP и сделали самую большую каку в истории VoIP. Более непоследовательного, непродуманного, ограниченного в развитии и т.д. до бесконечности протокола — просто не существует.

Мне SIP напоминает творчество тех самых админов Linux, где половина программы у них живет в конфиге, ы-ы-ы.
Одно плохо — придумать правильный формат конфига тоже моск нужен, а его при разработке SIP-а ни у кого не оказалось. ))
В общем, SIP был разработан админами, а не программистами, сие слишком очевидно.
Причем, очень и очень узкоспециализированным админами.
Поэтому, имеем что имеем.
Отредактировано 08.06.2017 6:02 vdimas . Предыдущая версия . Еще …
Отредактировано 08.06.2017 5:53 vdimas . Предыдущая версия .
Отредактировано 08.06.2017 0:29 vdimas . Предыдущая версия .
Re[6]: Подскажите как сейчас принято искать работу
От: Cyberax Марс  
Дата: 08.06.17 02:51
Оценка: -1
Здравствуйте, vdimas, Вы писали:

V>>>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))

C>>SpaceX использует RT Линукс в системах управления.
V>RT Линукс — это не Linux. ))
Это Линукс. Именно Линукс. Набор CONFIG_PREEMPT_RT добавляет поддержку жёсткого real-time с верхним ограничением времени реакции.

См.: https://rt.wiki.kernel.org/index.php/Main_Page
Sapienti sat!
Re[4]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 08.06.17 16:40
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))


Хорошо, если еще не винда.
Re: Эльбрус - 8 ядер
От: Privalov  
Дата: 26.05.17 08:27
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

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

Ой не знаю. На сайте Эльбруса про это ничего нет. ОС Эльбрус, судя по описанию, это Linux. Про вещи типа двоичной компиляции Бабаян лет 20, наверное, рассказывает.
Re: Эльбрус - 8 ядер
От: Gattaka Россия  
Дата: 26.05.17 09:23
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

LVV>Неужели доживу — куплю НАШ компьютер ?!
А как бы прикинуть сколько это по мощности? Сопоставить с i7 каким-нибудь?
Re[2]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 26.05.17 09:24
Оценка:
P>Ой не знаю. На сайте Эльбруса про это ничего нет.
Ну дык это ж Иннополис сообщает — там могли и сами сделать.
1 экземпляр...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Эльбрус - 8 ядер
От: CreatorCray  
Дата: 26.05.17 09:29
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>А как бы прикинуть сколько это по мощности? Сопоставить с i7 каким-нибудь?

Да уже сравнивали. Точно не помню сколько этих эльбрусов поместится в одном интеле, но проц слабенькмй.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[2]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 26.05.17 09:29
Оценка:
LVV>>В Иннополисе: http://tehnoomsk.ru/node/2726
LVV>>Неужели доживу — куплю НАШ компьютер ?!
G>А как бы прикинуть сколько это по мощности? Сопоставить с i7 каким-нибудь?
Ну вот они пишут такое:

По данным государственной корпорации Ростех, "8-ядерный русский процессор производится по технологии 28 нм.
По сравнению с «Эльбрус-4С», пиковая производительность нового процессора выше в 3-5 раз,
пропускная способность каналов ввода-вывода — в 8 раз

Если поискать про 4С — наверное, можно будет составить представление.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Эльбрус - 8 ядер
От: Privalov  
Дата: 26.05.17 10:32
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>1 экземпляр...


Типа сигнальный экземпляр.

Я в конце 90-х повелся на их рекламу и решил подождать выхода E2K. Дождался выхода K7 и статьи про E2K, по сравнению с которым означенный K7 — это так, игрушка. Этот K7 проработал 7 лет.
Если в 70-е — 80-е они делали что-то реальное, то сейчас я сильно в этом сомневаюсь.
Re[2]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.05.17 12:57
Оценка:
Здравствуйте, pestis, Вы писали:

P>Отлично! VLIW на 8 ядер это мегакруто.


Почему?
Re: Эльбрус - 8 ядер
От: swame  
Дата: 26.05.17 13:23
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>В Иннополисе: http://tehnoomsk.ru/node/2726

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

Подозреваю когда будет объявлена цена вопроса — жаба задушит и будет выбран как всегда китайский.
А пока вы можете прикупить

https://tjournal.ru/39451-rossiiskie-komputeri-elbrus-podesheveli-do-199-tisyach-rublei

Фотку с эльбрусом сюда, пожалуйста.
Вот и увидим цену вашего патриотизма и восторгов.
Отредактировано 26.05.2017 13:28 swame . Предыдущая версия .
Re[2]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 26.05.17 14:47
Оценка:
LVV>>В Иннополисе: http://tehnoomsk.ru/node/2726
LVV>>Неужели доживу — куплю НАШ компьютер ?!
Pzz>На профессорскую зарплату? Вряд ли.
Ну, не поллимона ж он стоить будет...
А все, что меньше я потяну без кредита...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[2]: Эльбрус - 8 ядер
От: Философ Ад http://vk.com/id10256428
Дата: 26.05.17 14:50
Оценка:
Здравствуйте, pestis, Вы писали:

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


LVV>>В Иннополисе: http://tehnoomsk.ru/node/2726

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

P>Отлично! VLIW на 8 ядер это мегакруто. Надеюсь его выпустят на открытый рынок.


а что такого в VLIW на 8 ядер?
Всё сказанное выше — личное мнение, если не указано обратное.
Re[3]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 26.05.17 19:51
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>

LVV>В комплект компьютера входят системный блок, 23-дюймовый монитор, клавиатура и мышь. На ПК предустановлена операционная система «Эльбрус», разработанная на базе Linux.


Интересно, а они патчи к gcc опубликовали, как того GPL велит? Или русскому военному человеку GPL не указ?

LVV>1. Мне в такой мощной комплектации комп не нужен.

LVV>Я и западные такие не покупаю. И всякие измы здесь ни при чем.
LVV>Для работы мне нужно 6-8 гигов памяти, Corei5 вполне подойдет.

Ну этот процессор, я думаю, потормознее Corei5 будет.

LVV>23-дюймовый монитор комплекте — нафиг не нужен.


У меня два 24-дюймовых. Я бы и третий прикупил, но ставить некуда. Мысли не помещаются на маленьком экране
Re[3]: Эльбрус - 8 ядер
От: swame  
Дата: 27.05.17 02:52
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>1. Мне в такой мощной комплектации комп не нужен.


Эта "Мощная комплектация" на порядок медленнее вашего i5 и пытается догнать Атом.


https://geektimes.ru/post/270390/

Сравниваемый тут старый i7 2600 находится на уровне современного i5.
Первый раз вижу графики производительности, проградуированные не линейно, а логарифмически

На линейной шкале это выглядело бы примерно так
http://cpuboss.com/cpus/Intel-Core-i5-6600-vs-Intel-Atom-D2500

LVV>2. Где серийный компьютер? Он уже выпущен, куда можно прийти и прицениться?


Так и пишите восторженные топики когда можно будет придти и прицениться, а не на очередные анонсы.
Я про эти импортозамещающие эльбрусы уже точно 20 лет сдыщу.
Отредактировано 27.05.2017 3:11 swame . Предыдущая версия . Еще …
Отредактировано 27.05.2017 2:54 swame . Предыдущая версия .
Re[4]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 27.05.17 04:00
Оценка:
LVV>>1. Мне в такой мощной комплектации комп не нужен.
S>Эта "Мощная комплектация" на порядок медленнее вашего i5 и пытается догнать Атом.
Да я и i5 еще не покупал — хватало i3

LVV>>2. Где серийный компьютер? Он уже выпущен, куда можно прийти и прицениться?

S>Так и пишите восторженные топики когда можно будет придти и прицениться, а не на очередные анонсы.
1. Вы единственный, кто увидел восторженность...
Остальные увидели иронию.
2. А чего тогда писать-то.
Пошел и купил.
Про интел — никто не пишет жеж.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Отредактировано 27.05.2017 4:00 LaptevVV . Предыдущая версия .
Re[4]: Эльбрус - 8 ядер
От: Блудов Павел Россия  
Дата: 28.05.17 02:06
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Интересно, а они патчи к gcc опубликовали, как того GPL велит? Или русскому военному человеку GPL не указ?


Они не патчили gcc, они свой помпилятор написали. У Intel есть свой собственный icc, у МЦСТ свой lcc.
Re[3]: Эльбрус - 8 ядер
От: denisko http://sdeniskos.blogspot.com/
Дата: 28.05.17 07:34
Оценка:
Здравствуйте, LaptevVV, Вы писали:

S>>А пока вы можете прикупить

S>>https://tjournal.ru/39451-rossiiskie-komputeri-elbrus-podesheveli-do-199-tisyach-rublei
S>>Фотку с эльбрусом сюда, пожалуйста.
S>>Вот и увидим цену вашего патриотизма и восторгов.
LVV>Читаем по ссылке:
LVV>

LVV>Четырёхядерный процессор «Эльбрус-401» модификации Б имеет частоту 750 МГц,

Интересно, что мешает сделать нормальную частоту на таком техпроцессе?
<Подпись удалена модератором>
Re[4]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 28.05.17 08:08
Оценка:
LVV>>

LVV>>Четырёхядерный процессор «Эльбрус-401» модификации Б имеет частоту 750 МГц,

D>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?
Ну, видимо, недомыслие, как говорил один известный киноперсонаж.
Невозможно перепрыгнуть через стадии изучения и освоения.
Этот путь изучения можно только пройти весь по шагам.
Если идти, а не покупать готовые решения у тех, кто уже прошел.
Китайцы вон до сих пор не могут воспроизвести двигательно нашего самолета, который мы им весь целиком уже несколько лет назад продали...
Американцы тож — не могут воспроизвести наши двигатели.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.05.17 09:27
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

Pzz>>Интересно, а они патчи к gcc опубликовали, как того GPL велит? Или русскому военному человеку GPL не указ?


БП>Они не патчили gcc, они свой помпилятор написали. У Intel есть свой собственный icc, у МЦСТ свой lcc.


Угу. Аха.
Re[6]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 28.05.17 09:58
Оценка:
LVV>>Остальные увидели иронию.
Pzz>Я не увидел иронию. Наверное, она была очень тонкая. Тоньше длинны волны видимого света.
Она толще бревна в моем глазу...
Смотри:

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

Ржач после предложения видищь?
Специально для тебя поясняю: это — ИРОНИЯ...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[6]: Эльбрус - 8 ядер
От: denisko http://sdeniskos.blogspot.com/
Дата: 28.05.17 10:36
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Pzz>>>Интересно, а они патчи к gcc опубликовали, как того GPL велит? Или русскому военному человеку GPL не указ?


БП>>Они не патчили gcc, они свой помпилятор написали. У Intel есть свой собственный icc, у МЦСТ свой lcc.


Pzz>Угу. Аха.

У них вроде архитектура сильно разная, так что gcc по большому счету малополезен. Да и их патчи мало кому нужны, т.к. таких архитектур сейчас кроме них нет. Другое дело, интересно, почему они брали gcc а не clang.
<Подпись удалена модератором>
Re[7]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.05.17 11:29
Оценка:
Здравствуйте, denisko, Вы писали:

Pzz>>Угу. Аха.

D>У них вроде архитектура сильно разная, так что gcc по большому счету малополезен. Да и их патчи мало кому нужны, т.к. таких архитектур сейчас кроме них нет. Другое дело, интересно, почему они брали gcc а не clang.

У меня есть приятель, он лет 10 (или 15?) назад на них работал, пилил gcc. clang (llvm) тогда если и был, никто про него не слышал и всерьез не воспринимал.

Но сейчас я из любопытства глянул в интернете, вроде как говорят, что у них свой компилятор, не gcc.

Решение это для меня довольно странное. Да, конечно, backend придется свой написать, сильно не такой, как для обычного процессора. Но зачем делать свой forntend, и промежуточные слои, которые пережевывают программу на процессорно-независимом уровне?

Чтобы скомпилировать линух со всеми его многочисленными запчастями, им надо не просто хороший компилятор иметь, им надо поддерживать, для совместимости, многие нестандартные плюшки gcc. Которые не слишком-то хорошо задокументированы. Это — титанический труд. Не невозможный, но очень объемный.
Re[4]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 28.05.17 11:38
Оценка:
Здравствуйте, denisko, Вы писали:

LVV>>Читаем по ссылке:

LVV>>Четырёхядерный процессор «Эльбрус-401» модификации Б имеет частоту 750 МГц,

D>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?


"Нормальная частота" — это 1 (Один) Гигагерц.
Всё что выше делается нереальными ухищрениями.

Нужно делать
1) ручную разводку проводников.
2) подгонять под конкретную технологию.

А конкретные параметры технологии производитель как правило просто не даёт.
Re[2]: Подскажите как сейчас принято искать работу
От: LaptevVV Россия  
Дата: 28.05.17 17:29
Оценка:
K>Сейчас даже в мобильниках 8 ядер. Из-за чего шум то?
Нафига он мне в мобильнике-то?
Мне на столе надо...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Эльбрус - 8 ядер
От: pagid Россия  
Дата: 28.05.17 17:33
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Интересно, а они патчи к gcc опубликовали, как того GPL велит?

GPL опубликовать велит? А разве не предоставить исходники сразу или по первому требованию тому, кому передал/продал свои "патчи", и не более того.
Re[2]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 28.05.17 18:10
Оценка:
Здравствуйте, elmal, Вы писали:

E>Что такое наш? Даже если предположить, что корпус, материнка, процессор, память, видеокарта, блок питания и т.д изготавливаются в России. То один черт, все разъемы неправославные...


1) Не смущает, что цифры арабские?
2) Я сильно подозреваю, что в нашем компьютере будут наши разъёмы.

Ты преувеличиваешь значимость IBM PC в современном мире.
Современный компьютер имеет размер со спичечный коробок, и делает всё, что надо.
Уметь разъёмиться с буржуйским барахлом может быть и полезно, но необязательно.
Re[2]: Подскажите как сейчас принято искать работу
От: Kernighan СССР  
Дата: 28.05.17 18:12
Оценка:
Здравствуйте, Kesular, Вы писали:

K>Сейчас даже в мобильниках 8 ядер. Из-за чего шум то?


Мобильник иностранный, а Эльбрус — наш.
Для тебя может и нет разницы, а для государства есть.
Re[2]: Эльбрус - 8 ядер
От: _ilya_  
Дата: 28.05.17 18:31
Оценка:
Здравствуйте, Gattaka, Вы писали:

G>А как бы прикинуть сколько это по мощности? Сопоставить с i7 каким-нибудь?


Заявлено 250GFlops но 32 бит, есть ли на деле — непонятно. Собственно это очень неплохо, типа производительность обычных 4 — ядерников. Создавать многоядерные процы с высокой производительностью на определенных задачах, но ущербной в остальном, это может быть ниша. Типа между обычными процами и видеокартами, но сейчас обычный проц + видеокарта более производительны везде.
Re[5]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 28.05.17 20:29
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Насколько полный набор?


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

K>В современном мире, если буржуйское барахло не работает, то это проблема буржуев.


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

K>Вот у тебя сейчас есть во что воткнуть SCSI-контроллер?


Да, есть.
Re[3]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 28.05.17 20:51
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Мобильник иностранный, а Эльбрус — наш.


И что, их уже реально делают в РФ, а не на Тайване?
Re[2]: Подскажите как сейчас принято искать работу
От: Kernighan СССР  
Дата: 28.05.17 21:36
Оценка:
Здравствуйте, Kesular, Вы писали:

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


LVV>>В Иннополисе: http://tehnoomsk.ru/node/2726

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

K>Сейчас даже в мобильниках 8 ядер. Из-за чего шум то?


На мобильниках не 8 ядер.
Одновременно работают четыре.
Кстати, могли бы не городить лишние 4 ядра,
а просто три ядра отключать, оставлять одно.
Но маркетинг, маркетинг.
Re: Эльбрус - 8 ядер
От: Osaka  
Дата: 28.05.17 23:05
Оценка:
LVV>Неужели доживу — куплю НАШ компьютер ?!
Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.
Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 28.05.17 23:19
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Самолично видел шайбу 30 см неразрезанных Эльбрусов.


А всё остальное?

K>Кристаллы с самыми высокими параметрами наверняка пока делаются там а не тут.


А, я так и думал.
Отредактировано 28.05.2017 23:20 Kesular . Предыдущая версия .
Re[5]: Эльбрус - 8 ядер
От: CreatorCray  
Дата: 28.05.17 23:46
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>В современном мире, если буржуйское барахло не работает, то это проблема буржуев.

Это проблема того, кому надо чтоб оно работало.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[5]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 29.05.17 02:27
Оценка:
Здравствуйте, Kernighan, Вы писали:

D>>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?

K>"Нормальная частота" — это 1 (Один) Гигагерц.
K>Всё что выше делается нереальными ухищрениями.
2ГГц без особых проблем делаются с помощью соответствующего тех. процесса.

K>Нужно делать

K>1) ручную разводку проводников.
Это уже даже Intel забросил для последнего поколения.

K>2) подгонять под конкретную технологию.

Всё давно делается.
Sapienti sat!
Re[4]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 29.05.17 02:29
Оценка:
Здравствуйте, denisko, Вы писали:

LVV>>Четырёхядерный процессор «Эльбрус-401» модификации Б имеет частоту 750 МГц,

D>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?
Совершенно непонятная фиксация на VLIW?
Sapienti sat!
Re[8]: Эльбрус - 8 ядер
От: LaptevVV Россия  
Дата: 29.05.17 03:31
Оценка:
LVV>>Ржач после предложения видищь?
LVV>>Специально для тебя поясняю: это — ИРОНИЯ...
Pzz>Прям каминг-аут какой-то. Все думают, что ты нахваливаешь успехи страны, а ты, оказывается, над ними тихо посмеиваешься...
А не надо думать за других...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Эльбрус - 8 ядер
От: Gattaka Россия  
Дата: 29.05.17 05:06
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Ну, не поллимона ж он стоить будет...

LVV>А все, что меньше я потяну без кредита...
Последний раз когда я смотрел цены — они были ого-го. Так что полмиллиона запросто.
Re[9]: Эльбрус - 8 ядер
От: swame  
Дата: 29.05.17 09:51
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Ржач после предложения видищь?

LVV>>>Специально для тебя поясняю: это — ИРОНИЯ...
Pzz>>Прям каминг-аут какой-то. Все думают, что ты нахваливаешь успехи страны, а ты, оказывается, над ними тихо посмеиваешься...
LVV>А не надо думать за других...

Сделайте голосование — удивитесь
Re[2]: Эльбрус - 8 ядер
От: Stanislaw K СССР  
Дата: 29.05.17 11:47
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


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


и лампочки отображающей состояние...

Годная идея для стартапа, если бы не требовалась поддержка со стороны ОС.
Все проблемы от жадности и глупости
Re[6]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 29.05.17 11:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


D>>>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?

K>>"Нормальная частота" — это 1 (Один) Гигагерц.
K>>Всё что выше делается нереальными ухищрениями.
C>2ГГц без особых проблем делаются с помощью соответствующего тех. процесса.

Ты это кому рассказываешь? Ты вообще знаешь, что такое техпроцесс?

K>>Нужно делать

K>>1) ручную разводку проводников.
C>Это уже даже Intel забросил для последнего поколения.

Пруф?

K>>2) подгонять под конкретную технологию.

C>Всё давно делается.

Глупостей не говори.
Re[2]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 29.05.17 12:02
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


Нуу... были такие клавиатуры:
http://www.phantom.sannata.ru/articles/sun_ultra_enterprise_2.shtml

Re[7]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 30.05.17 05:35
Оценка:
Здравствуйте, Kernighan, Вы писали:

C>>2ГГц без особых проблем делаются с помощью соответствующего тех. процесса.

K>Ты это кому рассказываешь? Ты вообще знаешь, что такое техпроцесс?
Да, так как плотно работаю с созданием ASIC'ов.

K>>>Нужно делать

K>>>1) ручную разводку проводников.
C>>Это уже даже Intel забросил для последнего поколения.
K>Пруф?
С личных слов инженеров от Intel'а. Вообще, Intel в индустрии как раз известен тем, что они упорно руками разводку процессора делали до последнего.

AMD забросил ещё раньше, а Apple даже и не начинал.

K>>>2) подгонять под конкретную технологию.

C>>Всё давно делается.
K>Глупостей не говори.
Что конкретно под кого подгоняется? Если не заниматься экстримом с последними поколениями тех. процессов, то производители чипов почти полностью взаимозаменяемы.
Sapienti sat!
Re[5]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 30.05.17 10:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


LVV>>>Четырёхядерный процессор «Эльбрус-401» модификации Б имеет частоту 750 МГц,

D>>Интересно, что мешает сделать нормальную частоту на таком техпроцессе?
C>Совершенно непонятная фиксация на VLIW?

Чем тебе не нравится VLIW и как она связана с частотой?
Re[6]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 30.05.17 10:17
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


K>>В современном мире, если буржуйское барахло не работает, то это проблема буржуев.

CC>Это проблема того, кому надо чтоб оно работало.

Азы рыночной экономики состоят в том, что всё покупается за деньги.
Потому что продать гораздо труднее, чем купить.(с)
Не веришь мне — спроси у qwerty.
Re[4]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 30.05.17 16:14
Оценка:
Здравствуйте, pestis, Вы писали:

P>Детерменированный паралелизм. Для определенных задач позволяет добиться существенного прироста по сравнению с устарелой x86, так что я бы в него палочкой потыкал.


Слпрее, получить сравнимые скорости, потратив на порядок меньше транзисторов.

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

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

А никто не пробовал применять комбинированный подход, когда процессор собирает детальные метрики, а just in time recompiler перекомпилирует узкие места с их учетом?
Re[7]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 30.05.17 16:19
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Азы рыночной экономики состоят в том, что всё покупается за деньги.

K>Потому что продать гораздо труднее, чем купить.(с)
K>Не веришь мне — спроси у qwerty.

Правда заключается в том, что за деньги можно купить то же, что всем прочим массово впаривают. А когда хочется купуть что-нибудь необычное с преподвыпердом, поди попробуй найди того, кто тебе такое сделает и продаст.
Re[2]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 30.05.17 16:24
Оценка:
Здравствуйте, Osaka, Вы писали:

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

O>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.

У жигулей пиписька мерится не в количестве ядер, а в количестве цилиндров. И в их совокупном объеме.
Re[9]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 30.05.17 17:37
Оценка:
Здравствуйте, Kernighan, Вы писали:

C>>Да, так как плотно работаю с созданием ASIC'ов.

K>Ну так и что такое "техпроцесс"? Вот например "техпроцесс 0.13" — это что?
Обычно под этим понимается процесс создания маски и производство на её основе.

C>>С личных слов инженеров от Intel'а. Вообще, Intel в индустрии как раз известен тем, что они упорно руками разводку процессора делали до последнего.

K>Ну у меня регалии повыше. Я их потом скажу, когда ты более акцентированно облажаешься.
Да, пожалуйста, лучше прямо сейчас.

K>Ну так что такое техпроцесс и как он влияет на частоту?

Ну так объясняю очень просто — основной проблемой для поднятия частоты является тепловыделение. Оно примерно линейно падает с уменьшением размеров транзисторов. Дополнительно, падает время переключения транзисторов.

Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA.

C>>Что конкретно под кого подгоняется? Если не заниматься экстримом с последними поколениями тех. процессов, то производители чипов почти полностью взаимозаменяемы.

K>Вот и узнай, что и под кого подгоняется. Ты многих вещей просто не знаешь.
Наш ASIC делает TSMC. Следующее поколение делает GF. Угу, очень большая разница.
Sapienti sat!
Re[2]: Эльбрус - 8 ядер
От: Osaka  
Дата: 30.05.17 21:54
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


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


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


И для знаков препинания, пожалуйста. http://www.rsdn.org/forum/hardware/6702507
Re[5]: Эльбрус - 8 ядер
От: pestis  
Дата: 31.05.17 07:24
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Слпрее, получить сравнимые скорости, потратив на порядок меньше транзисторов.


Как следствие меньшее тепловыделение. Но это все не про перформанс.

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


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


Какой подход оптимальние зависит от задачи. Для кода общего назначения компилятор не знает какие там ветвления и куда будут, так что интеловский подход лучше, но интеловский подход сосет в случае реально многопоточного кода. Но есть примерно дофига вычислительных задач, где компилятор может легко предсказывывать ветвления и раскладывать многопоточный код на VLIW инструкции.

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


Непонятно как эти метрики привязать к тем абстракциям, с которыми работает компилятор. А так подход рабочий, ява машины чем-то подобным занимаются.
Re[5]: Эльбрус - 8 ядер
От: Sharov Россия  
Дата: 31.05.17 09:43
Оценка:
Здравствуйте, Pzz, Вы писали:

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


https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation
Кодом людям нужно помогать!
Re[6]: Эльбрус - 8 ядер
От: Sharov Россия  
Дата: 31.05.17 09:44
Оценка:
Здравствуйте, pestis, Вы писали:

P>Какой подход оптимальние зависит от задачи. Для кода общего назначения компилятор не знает какие там ветвления и куда будут, так что интеловский подход лучше, но интеловский подход сосет в случае реально многопоточного кода. Но есть примерно дофига вычислительных задач, где компилятор может легко предсказывывать ветвления и раскладывать многопоточный код на VLIW инструкции.


Выше уже отмечалось: кому все это надо (все вот эти вот усложнения) в эпоху GPU?
Кодом людям нужно помогать!
Re[5]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 31.05.17 09:57
Оценка:
Здравствуйте, Pzz, Вы писали:

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

Современные Intel'ы внутри так и работают — предсказатель переходов, по сути, и есть "перекомпиляция на лету". Туда ещё добавляется и спекулятивное исполнение, когда CPU одновременно исполняет обе ветки if'а до тех пор, пока точно не станет известен результат сравнения.
Sapienti sat!
Re[8]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 31.05.17 10:23
Оценка:
Здравствуйте, Pzz, Вы писали:

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


K>>Азы рыночной экономики состоят в том, что всё покупается за деньги.

K>>Потому что продать гораздо труднее, чем купить.(с)
K>>Не веришь мне — спроси у qwerty.

Pzz>Правда заключается в том, что за деньги можно купить то же, что всем прочим массово впаривают. А когда хочется купуть что-нибудь необычное с преподвыпердом, поди попробуй найди того, кто тебе такое сделает и продаст.


Ну правильно. Именно поэтому и нужно делать своё.
Чтобы не попадать в технологический тупик.
Весь смысл Эльбруса именно в этом.

Да, кстати, ты знаешь, что у Эльбруса есть специфичная фишка — тегированная память?
Re[2]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 31.05.17 12:06
Оценка:
Здравствуйте, Osaka, Вы писали:

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

O>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.

А почему не восьмиядерный Су-27?
Re[10]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 31.05.17 13:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну так объясняю очень просто — основной проблемой для поднятия частоты является тепловыделение. Оно примерно линейно падает с уменьшением размеров транзисторов.


И, одновременно, усложняется отвод тепла с маленького кристалла
Итого — никакого видимого прогресса, и i7 14нм 7го поколения греются так же охотно, как и 2го 32нм. (Базовая частота отличается всего на 0.8ггц, бустовая на 0.7ггц. Или на ~20%). TDP тоже схож, 91 / 95вт.

Где выгода от техпроцесса ? Из одной пластины можно больше кристаллов нарезать, разве что.
kalsarikännit
Re[9]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 31.05.17 13:01
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Ну у меня регалии повыше. Я их потом скажу, когда ты более акцентированно облажаешься.


Раз ты в теме — можешь прокомментировать мнение оверклокера
Автор: IID
Дата: 20.05.17
о припое и жвачке ?

Спасибо.
kalsarikännit
Re[11]: Эльбрус - 8 ядер
От: Klikujiskaaan КНДР  
Дата: 31.05.17 13:26
Оценка:
Здравствуйте, IID, Вы писали:

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


C>>Ну так объясняю очень просто — основной проблемой для поднятия частоты является тепловыделение. Оно примерно линейно падает с уменьшением размеров транзисторов.


IID>И, одновременно, усложняется отвод тепла с маленького кристалла

IID>Итого — никакого видимого прогресса, и i7 14нм 7го поколения греются так же охотно, как и 2го 32нм. (Базовая частота отличается всего на 0.8ггц, бустовая на 0.7ггц. Или на ~20%). TDP тоже схож, 91 / 95вт.

IID>Где выгода от техпроцесса ? Из одной пластины можно больше кристаллов нарезать, разве что.


Ну, в топовый i9 запихали аж 18 ядер.
Re[11]: Эльбрус - 8 ядер
От: Sharov Россия  
Дата: 31.05.17 13:59
Оценка:
Здравствуйте, IID, Вы писали:

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


C>>Ну так объясняю очень просто — основной проблемой для поднятия частоты является тепловыделение. Оно примерно линейно падает с уменьшением размеров транзисторов.


IID>И, одновременно, усложняется отвод тепла с маленького кристалла

IID>Итого — никакого видимого прогресса, и i7 14нм 7го поколения греются так же охотно, как и 2го 32нм. (Базовая частота отличается всего на 0.8ггц, бустовая на 0.7ггц. Или на ~20%). TDP тоже схож, 91 / 95вт.

Ну как бэ при прочих равных в 14нм можно больше всякого продвинутого функционала запихать + ядер может быть больше за тот же "мощностной" бюджет.
Кодом людям нужно помогать!
Re[12]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 31.05.17 14:23
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Ну как бэ при прочих равных в 14нм можно больше всякого продвинутого функционала запихать + ядер может быть больше за тот же "мощностной" бюджет.


В теории. А на практике надо их ещё как-то остудить, прокачав такое же количество тепла, но через значительно меньший объём кремния. Для i9 анонсировали водянку от интела, видимо воздух уже не справляется.
kalsarikännit
Re[12]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 31.05.17 14:27
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

K>Ну, в топовый i9 запихали аж 18 ядер.


Которые официально предлагают остужать водянкой

ИМХуется мне, что и с водянкой нагрев будет оооочень неслабым, т.к. боксовая AIO водянка врядли будет лучше топового воздуха. Не исключаю мгновенный уход в троттлинг, при 100% загрузке синтетикой. И снижение базовых частот до кучи, в сравнении с менее ядерными собратьями.
kalsarikännit
Re[4]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 31.05.17 15:56
Оценка:
Здравствуйте, pestis, Вы писали:

P>Детерменированный паралелизм. Для определенных задач позволяет добиться существенного прироста по сравнению с устарелой x86, так что я бы в него палочкой потыкал.


FPGA. А VLIW пусть закапывают обратно.
Re[6]: Эльбрус - 8 ядер
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 31.05.17 17:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Вычислительные блоки GPU так работали — по крайней мере раньше, во времена SM 2/3.
[КУ] оккупировала армия.
Re[11]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 31.05.17 17:31
Оценка:
Здравствуйте, IID, Вы писали:

IID>Итого — никакого видимого прогресса, и i7 14нм 7го поколения греются так же охотно, как и 2го 32нм. (Базовая частота отличается всего на 0.8ггц, бустовая на 0.7ггц. Или на ~20%). TDP тоже схож, 91 / 95вт.

Это намеренно — процессор делают из расчёта на определённый термальный бюджет. На мобильных устройствах по-другому — там часть выигрыша пустят на уменьшение энергопотребления, и часть на улучшение производительности.

IID>Где выгода от техпроцесса ? Из одной пластины можно больше кристаллов нарезать, разве что.

Можно больше транзисторов запихать — больше ядер, кэша, фич и т.д.
Sapienti sat!
Re[3]: Эльбрус - 8 ядер
От: Stanislaw K СССР  
Дата: 31.05.17 17:46
Оценка:
Здравствуйте, Kernighan, Вы писали:

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

O>>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.

K>А почему не восьмиядерный Су-27?


потому что су 27 — специальная техника, а жигули гражданская техника общего назначения.
Все проблемы от жадности и глупости
Re[6]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 31.05.17 18:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

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

Это я в курсе. Но достижимая сложность процессора ограничена в гораздо большей степени, чем достижимая сложность софтвария.
Re[9]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 31.05.17 18:45
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Ну правильно. Именно поэтому и нужно делать своё.

K>Чтобы не попадать в технологический тупик.
K>Весь смысл Эльбруса именно в этом.

Я что, против делать свое?

K>Да, кстати, ты знаешь, что у Эльбруса есть специфичная фишка — тегированная память?


Слышал краем уха. А из Си это в каком виде доступно?
Re[12]: Подскажите как сейчас принято искать работу
От: Kernighan СССР  
Дата: 31.05.17 18:57
Оценка:
Здравствуйте, Kesular, Вы писали:

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


IID>>Итого — никакого видимого прогресса, и i7 14нм 7го поколения греются так же охотно, как и 2го 32нм. (Базовая частота отличается всего на 0.8ггц, бустовая на 0.7ггц. Или на ~20%). TDP тоже схож, 91 / 95вт.


K>Это потому что нанометры уже довольно давно стали маркетинговыми, и фактически техпроцесс 14 нм мало чем отличается от 32. Пара элементов там размера 14 нм, а все остальные — куда как больше.


Ыменно. Особенно проводники. Особенно верхних слоёв.
И не потому, что нельзя сделать более мелкий фотошаблон.
А потому что тонкий проводник рвётся на неровном основании.
Re[10]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 31.05.17 19:02
Оценка:
Здравствуйте, IID, Вы писали:

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


K>>Ну у меня регалии повыше. Я их потом скажу, когда ты более акцентированно облажаешься.


IID>Раз ты в теме — можешь прокомментировать мнение оверклокера
Автор: IID
Дата: 20.05.17
о припое и жвачке ?


Не прокомментирую. Корпусировка — это другая часть техпроцесса. К проектированию кристалла отношение имеет слабое.
Re[11]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 31.05.17 19:16
Оценка:
Здравствуйте, IID, Вы писали:

IID>Где выгода от техпроцесса ? Из одной пластины можно больше кристаллов нарезать, разве что.


В него запихали примерно столько же новых команд, сколько было старых.
Re[8]: Эльбрус - 8 ядер
От: Pzz Россия https://github.com/alexpevzner
Дата: 31.05.17 19:22
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Вот очень характерный пример, как можно знать слова и не понимать их смысл.

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

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

Первая причина, теоретически, должна лечиться VLIWом, но со второй непонятно. К памяти может не только текущее ядро обращаться, и даже вообще не только процессор. Да и завязывать в процессор/программу знание о том, как конкретно данная память себя ведет, как-то не очень разумно, память же можно и другую воткнуть.
Re[12]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 31.05.17 19:29
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>В него запихали примерно столько же новых команд, сколько было старых.


Сомнительное достижение. Для AVX даже отрицательные оффсеты пришлось выдумывать, чтобы процессор плату не прожёг. И всё равно старому софту пофиг, а видеокарты быстрее.

ЗЫ: В десктопные версии ещё бесполезное видеоядро запихали, которое полкристалла занимает. Бесполезное — потому что для вывода офисной графики хватило бы и малой его доли, а для игр наоборот, надо на порядок больше мощности. Ни рыба, ни мясо.
kalsarikännit
Re[9]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 31.05.17 19:30
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Pzz>Первая причина, теоретически, должна лечиться VLIWом, но со второй непонятно. К памяти может не только текущее ядро обращаться, и даже вообще не только процессор.


Кеши.
kalsarikännit
Re[3]: Эльбрус - 8 ядер
От: Osaka  
Дата: 31.05.17 21:05
Оценка:
Здравствуйте, Kernighan, Вы писали:

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


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

O>>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.

K>А почему не восьмиядерный Су-27?

Возможно, что-то спасает военная приёмка. Но недавние Протоны сигнализируют, что недолго осталось и ей.
Re[7]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 31.05.17 22:38
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Это я в курсе. Но достижимая сложность процессора ограничена в гораздо большей степени, чем достижимая сложность софтвария.

Что-то типа JavaScript'ового V8 JIT'а, который отслеживает выполнение? Не думаю, что это имеет добавлять в процессор.
Sapienti sat!
Re[7]: Эльбрус - 8 ядер
От: Privalov  
Дата: 01.06.17 06:04
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Продолжаем разговор — а дискетку есть куда воткнуть? А пятидюймовую?


Блин, сейчас посмотрел: оказывается, в моем компе есть трехдюймовый флопповод. А в ящике стола — несколько дискет. Правда, комп флопповод не видит: при замене железа его не подключили. Зато как смотрится!
Вот 5-дюймовых дискет я с конца прошлого века не видел. Не говоря уже о 8-дюймовых.
Re[9]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 01.06.17 09:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

K>>В процессорах сейчас умерло всё, кроме Интела и ARM.

C>Бредим. RISC-и разного рода рулят везде: POWER прекрасно существует на суперкомпьютерах, MIPS живёт в сетевых устройствах (и местами в суперкомпьютерах в Китае). VLIW, ЧСХ, в CPU помер совсем везде.

Да уж ))

В твоём компе/ноуте (или с чего ты там пишешь) бОльшая часть процессоров выполнена как VLIW/RISC. В радиоблоке, на сетевухе, звуковой чип и т.д. Если пишешь с айфона или айпада, то контроллер тач-скрина тоже выполнен на ядре сигнального проца от TI.

И против этого засилья WLIW будет всего пара CISC — это центральный проц и проц на клавиатуре. Ну еще может на мышке какой-нить на основе ядра AVR, если мышой пользуешься.

Upd. А не, гоню, AVR — он RISC, хоть и не VLIW ))
Отредактировано 01.06.2017 9:24 vdimas . Предыдущая версия .
Re[9]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 01.06.17 09:19
Оценка:
Здравствуйте, Pzz, Вы писали:

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


WLIV-архитектура управляет ALU явно, никакой "меры" не возникает.


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


Я вас умоляю ))
Последний раз это было проблемой 15 лет назад:
http://www.ixbt.com/news/hard/index.shtml?01/78/83


Pzz>Первая причина, теоретически, должна лечиться VLIWом, но со второй непонятно. К памяти может не только текущее ядро обращаться, и даже вообще не только процессор. Да и завязывать в процессор/программу знание о том, как конкретно данная память себя ведет, как-то не очень разумно, память же можно и другую воткнуть.


Основная причина "выживаемости" CISC в другом — это ведь абстракция кода от исполнительных блоков процессора. И напротив, VLIW прибит гвоздями к конкретной железке.
Re[4]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 01.06.17 11:20
Оценка:
Здравствуйте, Stanislaw K, Вы писали:

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


O>>>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.


K>>А почему не восьмиядерный Су-27?


SK>потому что су 27 — специальная техника, а жигули гражданская техника общего назначения.


Ну так и почему не Су-27?
Особенно если учесть, что основным потребителем Эльбруса будут военные?
Re[4]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 01.06.17 11:23
Оценка:
Здравствуйте, Osaka, Вы писали:

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


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


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

O>>>Наши культурные традиции взаимоотношений на предприятиях породят 8-ядерное жигули.

K>>А почему не восьмиядерный Су-27?

O>Возможно, что-то спасает военная приёмка. Но недавние Протоны сигнализируют, что недолго осталось и ей.

Ну, Протон, конечно крыть нечем. Деграданс технологической культуры видно невооружённым глазом.
Только не надо называть это традицией. Наша традиция как раз состоит в расстрельной ответственности.
Отредактировано 02.06.2017 9:04 Kernighan . Предыдущая версия .
Re[5]: Эльбрус - 8 ядер
От: Stanislaw K СССР  
Дата: 01.06.17 14:54
Оценка:
Здравствуйте, Kernighan, Вы писали:


K>Ну так и почему не Су-27?

K>Особенно если учесть, что основным потребителем Эльбруса будут военные?

вообще вопросов нет. но тогда не стоит требовать от него, сравнивать его с широко распространенными гражданскими моделями общего назначения.
Все проблемы от жадности и глупости
Re[6]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 01.06.17 15:03
Оценка:
Здравствуйте, Stanislaw K, Вы писали:

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



K>>Ну так и почему не Су-27?

K>>Особенно если учесть, что основным потребителем Эльбруса будут военные?

SK>вообще вопросов нет. но тогда не стоит требовать от него, сравнивать его с широко распространенными гражданскими моделями общего назначения.


Ну да. Как говорится, привет Капитан Очевидность.
Re[11]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 02.06.17 06:52
Оценка:
Здравствуйте, Cyberax, Вы писали:

V>>В твоём компе/ноуте (или с чего ты там пишешь) бОльшая часть процессоров выполнена как VLIW/RISC. В радиоблоке, на сетевухе, звуковой чип и т.д.

C>VLIW/RISK — LOL.

Да понятно, что ты не в курсе, как устроены сигнальные процессоры, иначе бы не писал столь махровую пургу в эту ветку...

http://www.vision-systems.com/articles/print/volume-6/issue-3/technology-trends/input-devices/ti-extends-vliw-architecture-targets-image-processing.html
http://www.ecs.umass.edu/ece/koren/architecture/VLIW/2/ti1.html
http://ieeexplore.ieee.org/document/856291/
http://www.ti.com/product/tms320dm8147?HQS=TI-null-null-EDS-df-pf-null-eu — популярен в камерах, фотоаппаратах, телеках с камерой и т.д.
Re[12]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 02.06.17 19:24
Оценка:
Здравствуйте, vdimas, Вы писали:

C>>VLIW/RISK — LOL.

V>Да понятно, что ты не в курсе, как устроены сигнальные процессоры, иначе бы не писал столь махровую пургу в эту ветку...
Нет, про то что VLIW популярен в GPU (и прочей медиа) я и так знаю. Но какую связь он имеет с RISK?!?
Sapienti sat!
Re[11]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 02.06.17 19:34
Оценка:
Здравствуйте, 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 (процессорные ядра, контроллеры памяти, медиа-компрессоры и т.д.), которые они сублицензируют бесплатно или очень дёшево своим клиентам.
Sapienti sat!
Re[12]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 02.06.17 20:17
Оценка:
Здравствуйте, 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 слишком разные технологии, т.е., грубо, литографическая матрица с одной фабрики, предназначенная для их пластин не покатит для другой фабрики и тех пластин.
Re[3]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 02.06.17 20:39
Оценка:
Здравствуйте, vdimas, Вы писали:

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


Судя по реальным бенчмаркам, они таки тянут очень неплохо, и далеко не факт, что ядра эльбруса чем-то лучше. http://www.7-cpu.com/
Так что, единственные процессоры, с которым он может хоть как-то потягаться — мобильные.
Re[13]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 02.06.17 20:41
Оценка:
Здравствуйте, vdimas, Вы писали:

C>>32нм доступен коммерчески в крупных масштабах уже несколько лет.

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

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

C>>28/32нм

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

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

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

Есть небольшое исключение — аналоговые компоненты (типа DAC'ов или радиомодуляторов) имеет смысл брать у конкретной фабрики. Но это обычно обособленные блоки, которые сравнительно легко заменяются.
Sapienti sat!
Re[6]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 02.06.17 20:45
Оценка:
Здравствуйте, Pzz, Вы писали:

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


Дык, АМД тоже у себя не производит. Делают китайцы-тайванцы. И ничего, никто не переживает.
Re[14]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 02.06.17 20:59
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>32нм доступен коммерчески в крупных масштабах уже несколько лет.

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

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


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

...
C>В IoT, например.

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


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


Не нужно переделывать его высокоуровневое описание. Я уже приводил аналогию исходника на ЯП высокого уровня и его компиляцию под разные платформы. Тут фактически то же самое.
Re[5]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 02.06.17 22:14
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Тебя в гугле забанили?

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

Доказательства?
Re[14]: Эльбрус - 8 ядер
От: m2l  
Дата: 03.06.17 08:12
Оценка:
Здравствуйте, vdimas, Вы писали:

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

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

А то какое-то шапкозакидательство прямо — везде VLIW, он лучший и "....VLIW — это вообще единственная архитектура....". Меньше, слов, больше кода.
Re[8]: Эльбрус - 8 ядер
От: Ops Россия  
Дата: 03.06.17 09:05
Оценка:
Здравствуйте, Privalov, Вы писали:

P>Блин, сейчас посмотрел: оказывается, в моем компе есть трехдюймовый флопповод. А в ящике стола — несколько дискет. Правда, комп флопповод не видит: при замене железа его не подключили. Зато как смотрится!

Давно вытащил и выкинул этот пылесборник.
P>Вот 5-дюймовых дискет я с конца прошлого века не видел. Не говоря уже о 8-дюймовых.
У меня одна 8-дюймовая — единственное, что из дискет вообще сохранилось, так, на память. Даже CD/DVD все повыкидывал, только привод оставил в шкафу на всякий случай, думаю, и его уже пора на помоечку.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[6]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 03.06.17 09:58
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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

Достаточно подумать пять минут, чтобы понять, почему это лучше.
Re[16]: Эльбрус - 8 ядер
От: m2l  
Дата: 03.06.17 18:17
Оценка:
Здравствуйте, 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, гранитцы между ними эфимерны. Но если ты хочешь делиться своими знаниями, почему бы не приводить заодно ссылки на первоисточники? Или уточнять, что это твоё частное мнение/опыт?
Re[10]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.06.17 19:00
Оценка:
Здравствуйте, 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 закончились пшиком.
The God is real, unless declared integer.
Re[2]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.06.17 19:03
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


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


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

Я вот переназначаю CapsLock на эту роль — этого достаточно?
The God is real, unless declared integer.
Отредактировано 03.06.2017 19:04 netch80 . Предыдущая версия .
Re[5]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.06.17 19:20
Оценка:
Здравствуйте, Pzz, Вы писали:

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


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

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


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


Уже ответили.
The God is real, unless declared integer.
Re[9]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.06.17 19:40
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Ну правильно. Именно поэтому и нужно делать своё.

K>Чтобы не попадать в технологический тупик.
K>Весь смысл Эльбруса именно в этом.

K>Да, кстати, ты знаешь, что у Эльбруса есть специфичная фишка — тегированная память?


О да. Редкостно бесполезная реализация.
The God is real, unless declared integer.
Re[7]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 03.06.17 20:27
Оценка:
Здравствуйте, vdimas, Вы писали:

V>в основном вычислительных/математических и мультимедиа) получались в среднем не хуже, а иногда даже серьёзно лучше


То есть тех, где прекрасно справляется GPGPU и исполнять их на обычном универсальном процессоре нет практически никакого смысла.

V>А у тебя какие будут доказательства всей твоей голословности в этом топике?


Не хами. Что конкретно я должен доказать?
Re[9]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 04.06.17 00:10
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Не справляется.


И что это за алгоритмы такие? Давай конкретику.

V>Ты много чего тут успел понаписать, эдак тебя понесло-то.

V>Я лишь хочу поинтересоваться источником твоего вдохновения.

Конкретику давай, твой треп меня уже утомил.
Re[9]: Эльбрус - 8 ядер
От: Privalov  
Дата: 04.06.17 06:10
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Давно вытащил и выкинул этот пылесборник.


Это рабочий комп. Я его не разбираю. Дома другое дело: нигде ничего не осталось.

Ops>У меня одна 8-дюймовая — единственное, что из дискет вообще сохранилось, так, на память.


Я дома внезапно обнаружил пачку 3-дюймовых дискет. 5-, а тем более 8-дюймовых не осталось. Не сохранились.

Даже CD/DVD все повыкидывал, только привод оставил в шкафу на всякий случай, думаю, и его уже пора на помоечку.

DVD лежит в сторонке. На всякий случай. За последние 5 лет таких случаев было не более двух.
Re[18]: Эльбрус - 8 ядер
От: m2l  
Дата: 04.06.17 06:59
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>А так-то можно было привести архитектуру AltiVec от Apple/IBM/Motoolla. Ядра с этой архитектурой включают, например, в PowerPC и Cell. Но там примерно то же самое:

"архитектуру AltiVec" --> "набор инструкций AltiVec". Apple Power PC ушел лет 15 назад. И это не DSP из iPhone 5, на который ты ссылаешься. И G4/G5 это не DSP для Bluetooth/WiFi даже...

V>Или еще можно было привести пример CEVA-XC архитектуры (тоже VLIW):

V>http://www.ceva-dsp.com/product/ceva-xc4500/
На этом сайте внизу примеры, где используется. С твоим утверждением "Собсно, все современные сигнальные процы — VLIW" не стыкуется.

Подтверждений твоих слов нет. Только читаешь лекции про использование умножения в ИИ и расказываешь, от чего я далек, с чем несогласен.
Re[18]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.06.17 08:06
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ядра TI занимают бОльшую долю рынка всех существующих DSP. Поэтому, разумеется, я привёл одну из архитектур TI. Разумеется, этих архитектур более одной, но приводить в кач-ве примера стоило современный мейнстрим, если речь о сегодняшнем положении дел.


V>А так-то можно было привести архитектуру AltiVec от Apple/IBM/Motoolla. Ядра с этой архитектурой включают, например, в PowerPC и Cell. Но там примерно то же самое:

V>

V>Согласно документации Apple, AltiVec в реализации на процессорах G4 и G5 может выполнять восемь 32-битных FLOPS за цикл,


Приводить SIMD в качестве аргумента за VLIW — это пять. Косяков.
Я уже не удивляюсь, просто замечу для окружающих, что в таком смысле и x86 нынешний — VLIW. А на самом деле, естественно, нет.

V>Погуглив еще (при желании) ты увидишь достаточно альтернатив, в том числе суперскалярные, где практически все суперскалярные успешно сдохли во второй половине 2000-х. Потому что настала мобильная эра и опять энергоэффективность стала в цене. Вот поэтому имеем засилье RISC и VLIW, как ни крути.


RISC ничуть не противоречит суперскалярности, а все топовые RISC реализации как раз суперскалярны.

V>Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы.


Это как раз не "всей разницы", а критично для данного обсуждения. Потому что SIMD мало того, что не составляет никакой специфики VLIW — он цеплялся даже поверх неконвейеризованных процессоров 70-х — он и не конфликтует с суперскалярностью, скорее даже наоборот — например, SIMD регистры типа XMM в x86 точно так же переименовываются, а операции переставляются.

Не комментирую остальное (про VLIW в сигнальных процессорах и т.п.), но тут тебя явно не туда понесло.
Или в сигнальных на самом деле такой же VLIW, который на самом деле не VLIW?
The God is real, unless declared integer.
Re[19]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 04.06.17 12:28
Оценка:
Здравствуйте, netch80, Вы писали:

V>>Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы.


N>Это как раз не "всей разницы", а критично для данного обсуждения.


Критично, это когда SIMD не на RISC.


N>он цеплялся даже поверх неконвейеризованных процессоров 70-х


При чем тут конвейеризированость?
Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях. Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду". Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.


N>он и не конфликтует с суперскалярностью


Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))


N>скорее даже наоборот — например, SIMD регистры типа XMM в x86 точно так же переименовываются, а операции переставляются.



Сам же себе возразил.

Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один так (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))

В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.


N>Не комментирую остальное (про VLIW в сигнальных процессорах и т.п.), но тут тебя явно не туда понесло.

N>Или в сигнальных на самом деле такой же VLIW, который на самом деле не VLIW?

Тебя тоже в Гугле забанили?
Re[19]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 04.06.17 12:50
Оценка:
Здравствуйте, m2l, Вы писали:

V>>Или еще можно было привести пример CEVA-XC архитектуры (тоже VLIW):

V>>http://www.ceva-dsp.com/product/ceva-xc4500/
m2l>На этом сайте внизу примеры, где используется. С твоим утверждением "Собсно, все современные сигнальные процы — VLIW" не стыкуется.

Мде...
По ссылке:

The CEVA-XC4500 DSP core is the fourth generation of the widely licensed CEVA-XC architecture. Optimized for advanced communication applications, especially high-performance wireless infrastructure equipment, it features a combination of VLIW (Very Long Instruction Word) and vector engines that enhance typical DSP capabilities with advanced scalar and floating-point vector processing.


Более того, спеки архитектуры CEVA-XC лежат в свободном доступе, какие у тебя проблемы-то?


m2l>Подтверждений твоих слов нет.


Это сразу в сад.
Кто не умеет проглотить даже разжёванное — молча на выход.
Re[8]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 04.06.17 14:15
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


K>>Неправильно!

K>>CPU всегда исполняет ОДНУ ветку. Ту, которую он считает более вероятной.
C>Это так обычный предсказатель переходов работает. А современные Intel именно что исполняют обе ветки, хотя предсказанная ветка пойдёт дальше.

Современный Интел делает именно так, как я сказал.
Тебе надо было пять минут подумать. А ты не подумал.
За то, что не подумал, будешь порот.

K>>А если не угадал, то откатывает результаты.

K>>Достаточно подумать пять минут, чтобы понять, почему это лучше.
C>Проблема тут в том, что при неправильном предсказании CPU должен будет переделать всю работу. В случае параллельного исполнения одна ветка просто будет отброшена.

По словам "переделать всю работу" сразу видно, что ты не понимаешь, о чём говоришь.

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


Ну разумеется. И поэтому ВСЕГДА предпочитают сделать ещё одно ядро, а не то, что ты тут нафантазировал.

Итак, что происходит на самом деле.

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

Есть хорошая эвристика — переходы назад всегда исполняются (потому что это цикл),
А переходы вперёд никогда не исполняются (потому что большинство условий — это обработка нереальных ошибок).
Эта эвристика позволяет угадать 90% случаев.
Остальные случаи угадываются за счёт того, что помнится направление перехода в этом месте в прошлый раз.
Но мы это рассматривать не будем. Просто поверим в то, что предсказатель в 90% (или больше) предсказывает правильно.

Теперь мы стоим перед выбором — что делать: выполнять одну ветку или обе?
Пусть процессор имеет 4 АЛУ, которые можно загрузить операциями.
И пусть направление перехода мы узнаем через три такта.
В случае, если мы все 4 АЛУ отдали под главную ветку, мы выполним 12 операций и с 90% вероятностью угадаем.
В случае, если мы 2 АЛУ отдали под одну ветку, а 2 под другую, то мы выполним только 6 операций нужной ветки.
Да, при втором варианте мы никогда не ошибёмся, но в первом варианте мы в 90% выполняем в два раза больше операций.

Поэтому всегда выбирается первая схема. Она и более простая и более эффективная.
Причём, чем лучше предсказывает предсказатель, тем меньше нужна вторая ветка.

В случае,если мы не угадали направление перехода ничего переделывать не надо.
Запущенные операции идут через АЛУ как шли.
Просто результаты выполненных операций не пишутся в регистры.
Поскольку конвейер у нас выполняет все операции за одно число тактов,
то к моменту записи мы уже знаем, произошёл переход или нет.

Так работает любой нормальный суперскалярный RISC (и с перестановкой и без перестановки команд).
VLIV-ы я не разрабатывал, но наверное и там всё так же.

Могу рассказать, что произойдёт, если в этих 12 командах тоже встретится условный переход
Отредактировано 04.06.2017 15:40 Kernighan . Предыдущая версия .
Re[20]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.06.17 14:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Есть еще SIMD — та же хрень, вид сбоку. Тоже одна инструкция задаёт работу сразу нескольким исполнительным устройствам. Всей разницы, что эти устройства выполняют одинаковую операцию над своими аргументами, а не уникальную для каждого исполнительного устройства, как в случае VLIW, что даёт экономию в размере бинарника программы.

N>>Это как раз не "всей разницы", а критично для данного обсуждения.
V>Критично, это когда SIMD не на RISC.

Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом), или вообще что-то очень оригинальное (и слабо соответствующее действительности) думаешь про RISC. Оба варианта меня смущают.

N>>он цеплялся даже поверх неконвейеризованных процессоров 70-х

V>При чем тут конвейеризированость?
V>Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях.

Не во всех RISC. И откуда тут взялась идея про побочные эффекты?

V> Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду".


Если ты про Thumb в ARM, то это больше похоже на вариант "нам же надо как-то сэмулировать условное выполнение от полного режима, не ломая компиляторы, сделаем хоть как-то".

V> Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.


Delay slot на 5 команд? Оригинально ты же перед этим показывал, что это VLIW. Зачем это называть конвейером, когда это пакет одновременно исполняющихся команд?

N>>он и не конфликтует с суперскалярностью

V>Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))

Видимо, конфликтует только в твоих представлениях, в которых RISC не может иметь суперскалярность.
Или они для тебя уже не RISC? Тогда вводи свои термины специально для этой дискуссии.

N>>скорее даже наоборот — например, SIMD регистры типа XMM в x86 точно так же переименовываются, а операции переставляются.

V>
V>Сам же себе возразил.

Нет.

V>Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один так (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))


Спасибо, кэп. И что?

V>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.


Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?

N>>Не комментирую остальное (про VLIW в сигнальных процессорах и т.п.), но тут тебя явно не туда понесло.

N>>Или в сигнальных на самом деле такой же VLIW, который на самом деле не VLIW?

V>Тебя тоже в Гугле забанили?


Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию
The God is real, unless declared integer.
Re[9]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 04.06.17 19:18
Оценка:
Здравствуйте, Kernighan, Вы писали:

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

K>Ну разумеется. И поэтому ВСЕГДА предпочитают сделать ещё одно ядро, а не то, что ты тут нафантазировал.
Ну почитай про Silvermont.

K>Остальные случаи угадываются за счёт того, что помнится направление перехода в этом месте в прошлый раз.

K>Но мы это рассматривать не будем. Просто поверим в то, что предсказатель в 90% (или больше) предсказывает правильно.
K>Теперь мы стоим перед выбором — что делать: выполнять одну ветку или обе?
Отойдём на шаг назад. CPU при прохождении ветки переименовывает регистры, так что у него получается две копии их. Одна для прохождения ветки, другая для отката назад.

K>Пусть процессор имеет 4 АЛУ, которые можно загрузить операциями.

K>И пусть направление перехода мы узнаем через три такта.
K>В случае, если мы все 4 АЛУ отдали под главную ветку, мы выполним 12 операций и с 90% вероятностью угадаем.
K>В случае, если мы 2 АЛУ отдали под одну ветку, а 2 под другую, то мы выполним только 6 операций нужной ветки.
Пока всё так.

Но 3 такта на результат операции — это очень часто сверхоптимистичная оценка, очень часто вычисление условия требует взятия данных из дальних областей памяти. И в этих случаях получаем классический pipeline stall, что позволяет нам безболезненно использовать свободные ALU для вычисления второй ветки.

K>Так работает любой нормальный суперскалярный RISC (и с перестановкой и без перестановки команд).

Не совсем любой. Некоторые предпочитают вместо предсказания перехода делать, например, переключение на другой поток.
Sapienti sat!
Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 05.06.17 00:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Любые, где требуется low-latency и вообще hard realtime.


А, то есть где нормальные люди используют FPGA или ASIC. Это во первых.
А во вторых, насколько я понимаю, на Ельбрусе используется обычный линух — со всеми плюшками типа многозадачности, виртуальной памяти и так далее. И кэш там, насколько я понимаю, тоже есть. Так что откуда там вообще мог взяться hard realtime?

V>Пруфы таких громкий заявлений будут?


Они там были. Иди и читай.
Отредактировано 05.06.2017 0:51 Kesular . Предыдущая версия .
Re[21]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 05.06.17 07:09
Оценка:
Здравствуйте, netch80, Вы писали:

N>Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом)


Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.

RISC — это философия построения процессоров, хотя сама аббревиатура изначально появилась от философии формирования системы команд. Но сейчас хватает RISC-процессоров, у которых количество команд поспорит с оными из CISC-мира.


N>или вообще что-то очень оригинальное (и слабо соответствующее действительности) думаешь про RISC. Оба варианта меня смущают.


Ну вот чтобы не смущало, надо отделять мух от котлет.


V>>Побочные эффекты от конвейеризированности в RISC происходят чуть в других местах — на условных ветвлениях.

N>Не во всех RISC.

Почти во всех с конвейером ненулевой длины.


N>И откуда тут взялась идея про побочные эффекты?


От конвейеризированности в отсутствии планировщика, вестимо.

Всё-таки философия RISC — это минимизация "побочных" устройств в процессоре (помимо целевых-исполнительных).


V>> Поэтому-то там бывают такие прикольные виды ветвлений, как "пропустить следующую команду".

N>Если ты про Thumb в ARM, то это больше похоже на вариант

Не важно, на что это похоже. Это один из способов условного ветвления без сброса конвейера.
Ключевое выделено. Безусловные ветвления отслеживаются еще на этапе предвыборки.


V>> Или, например, в той же архитектуре TI C6000 после команды ветвления будет выполнено еще +5 команд, которые уже находятся в конвейере. Т.е. эти следующие 5 команд можно забить NOP-ами, а можно заставить продолжать делать что-то полезное, что и делает оптимизирующий компилятор при компиляции тела цикла. Вот как раз в моём примере видно, что после первого ветвления еще 5 команд приносят некоторую пользу.


N>Delay slot на 5 команд? Оригинально ты же перед этим показывал, что это VLIW. Зачем это называть конвейером, когда это пакет одновременно исполняющихся команд?


Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.


V>>Увы, конфликтует, когда речь о RISC, потому что ты понятия не имеешь, как он там устроено "унутре". ))

N>Видимо, конфликтует только в твоих представлениях, в которых RISC не может иметь суперскалярность.

Не может. Еще раз, медленно. В основе суперскалярности лежит абстракция исходного кода от кол-ва исполнительных устройств. Это принципиально. И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.

Помимо RISC и CISC есть еще гибридная технология со своим названием — MISC, может тебя это смущает?


N>Или они для тебя уже не RISC? Тогда вводи свои термины специально для этой дискуссии.


Зачем? Есть вики, там вполне доступно и в этом вопросе правильно.


V>>Суперскаляр динамически распределяет свои ресурсы, поэтому, от исходного SIMD там может ничего не остаться после отображения вот этого "абстрактного" входного бинарного кода программы на конкретный внутренний VLIW-микрокод. Ты даже не можешь гарантировать — выполнится ли эта групповая операция над данными за один такт (одновременно) или последовательно/произвольно/как получится, на доступных в данный момент вычислительных блоках. ))

N>Спасибо, кэп. И что?

Дык, в этом состоит принципиальное отличие RISC от суперскаляра/СISC. Т.е. отличие не в системе команд, а в способе исполнения этих команд.


V>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.

N>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?

Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS и имел собственную аббревиатуру. Затем в других архитектурах — DEC Alpha и PowerPC, где под векторные вычисления явным образом были введены дополнительные процессорные элементы, т.е. доступные для непосредственного их программирования. Их даже иногда называют "DSP-сопроцессоры". А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике. Т.е. как по мне — это просто стыренная из другой предметной области аббревиатура. Маркетинг, мать его так. ))

В терминологии оно как? Кто первый, того и тапки. Я просто показываю, откуда "оно" взялось.


N>Меня интересовали не данные гугла, а твоя оценка ситуации. Ещё надеюсь на более-менее вменяемый ответ без тонн собственных терминов, совпадающих с общепринятыми по названию, но не по содержанию


Да, я в курсе, что иногда умею разродиться постами, "режущими слух".
Зрите в корень, как грится, и да пребудет с вами сила. ))
Re[10]: Эльбрус - 8 ядер
От: Ночной Смотрящий Россия  
Дата: 05.06.17 20:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA.


На FPGA то можно логическую модель запустить, а вот если ты просто смасштабируешь готовую топологию, то вряд ли это заработает.
Re[12]: Эльбрус - 8 ядер
От: Ночной Смотрящий Россия  
Дата: 05.06.17 20:55
Оценка:
Здравствуйте, Klikujiskaaan, Вы писали:

K>Ну, в топовый i9 запихали аж 18 ядер.


Не факт что там один кристалл.
Re[11]: Эльбрус - 8 ядер
От: Cyberax Марс  
Дата: 05.06.17 21:10
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Потому можно взять даже что-то древнее типа Intel 8086 и запустить его на приличной частоте даже на FPGA.

НС>На FPGA то можно логическую модель запустить, а вот если ты просто смасштабируешь готовую топологию, то вряд ли это заработает.
Основные проблемы будут с задержками памяти — 8086 не спроектирован на такую разницу в производительности CPU и памяти, какая существует сейчас. Если же сэмулировать память (кэшем на кристалле), то всё будет ОК.
Sapienti sat!
Re[13]: Эльбрус - 8 ядер
От: Klikujiskaaan КНДР  
Дата: 05.06.17 21:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Klikujiskaaan, Вы писали:


K>>Ну, в топовый i9 запихали аж 18 ядер.


НС>Не факт что там один кристалл.


Возможно, меня, кстати повеселил новый Ryzen 16 ядерный:
  Фоточки тут

Re[12]: Эльбрус - 8 ядер
От: Sharov Россия  
Дата: 05.06.17 23:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Основные проблемы будут с задержками памяти — 8086 не спроектирован на такую разницу в производительности CPU и памяти, какая существует сейчас.


И как это будет проявляться?
Кодом людям нужно помогать!
Re: Подскажите как сейчас принято искать работу
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 06:29
Оценка:
Здравствуйте, Kesular, Вы писали:

K>А, то есть где нормальные люди используют FPGA или ASIC. Это во первых.

K>А во вторых, насколько я понимаю, на Ельбрусе используется обычный линух — со всеми плюшками типа многозадачности, виртуальной памяти и так далее. И кэш там, насколько я понимаю, тоже есть. Так что откуда там вообще мог взяться hard realtime?

Hard realtime есть в виде нашлёпок на Linux. Но можно и отдельно. Имея Linux, использовать его как трамплин для построения целевой специальной ОС — банально. Лишь бы эта ОС выполняла все непрямые функции.
Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым", это легко организуется в тестах.
The God is real, unless declared integer.
Re[7]: Эльбрус - 8 ядер
От: Ночной Смотрящий Россия  
Дата: 06.06.17 10:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

K>>Чем тебе не нравится VLIW и как она связана с частотой?

C>VLIW требует героических подвигов со стороны компиляторов.

Дело не в компиляторах. Ситуация очень похожа на векторные инструкции. Получить от них хороший выхлоп на готовом коде редко когда удается, и используется в основном по мелочам типа зачистки памяти. Чтобы раскрыть их потенциал нужно писать специально под них код.
С VLIW все примерно так же. Обычный код вряд ли получится уложить в VLIW сильно эффективнее, чем это делают современные процессоры. Но вот если код написать специально для VLIW, то расклад будет иным.
Re[23]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 06.06.17 13:33
Оценка:
Здравствуйте, netch80, Вы писали:

N>>>Или ты не признаёшь за RISC возможность OoO (хотя это сплошь и рядом)

V>>Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.

V>>RISC — это философия построения процессоров, хотя сама аббревиатура изначально появилась от философии формирования системы команд. Но сейчас хватает RISC-процессоров, у которых количество команд поспорит с оными из CISC-мира.


N>Я, извини, вцеплюсь в это "но". Если оно для тебя существенно, то тут недоразобрался явно ты


Пукнул в лужу и завилял (выделил процитированный твой кусок). ))
Мы это с тобой проходили уже.
Скучно.


N>А вторым уже выступает то, что есть стандартный метод упаковки команд в конвейер, который в классическом (Berkeley) исполнении — одна команда на такт, но 5 тактов на команду.



N>Но как только начинается проблема торможения на памяти


Не начинается. Корни RISC растут от архитектуры с фиксированным временем обращения к памяти. Т.е. время, необходимое для чтения или записи внутреннего регистра в память — фиксировано и известно. Поэтому, команды работы с памятью в RISC изначально были выделены в отдельную группу. Делается это так: выполняется команда загрузки регистра значением из памяти, потом необходимо несколько тактов выполнять NOP или другие, более полезные команды, но не касающиеся этого регистра. Вот и всё кино. Вот тебе и классика OoO, но только на уровне софта-компилятора, увы, но не железа. А уж если речь о засилье RISC в микроконтрллерах и прочих специализированных SoC, где память программ и память данных независимы и живут внутри чипа — то там совсем никаких задержек по пробращению к данным быть не может, ес-но.


N>или на непредсказуемо долгих командах


"непредсказуемо долгих" на RISC...
Я так думаю, что ты на асме всерьёз и не писал никогда. Ни под CISC ни под RISC.
Это ж мега-залёт... ))
Открой хоть раз в жизни один даташит хоть на один контроллер...


N>там вводят полноценное OoO, ничуть не меняя общего подхода. Ни старшие ARM, ни старшие MIPS, ни Power, при всём различии их подхода, не перестают быть RISC от того, что у них OoO.


Как же скучно опять...
Гуглить по "ARM is not RISC anymore".
Дальше не читал, сорри. Разбирай свою кашу сам.
Re[25]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 06.06.17 14:09
Оценка:
Здравствуйте, netch80, Вы писали:

V>>Гуглить по "ARM is not RISC anymore".

N>А, ты опять в своём мире. OK.

Т.е. в гугле, таки, забанили.
Так и запишем...
Re[26]: Эльбрус - 8 ядер
От: Kernighan СССР  
Дата: 06.06.17 14:53
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>>>Гуглить по "ARM is not RISC anymore".

N>>А, ты опять в своём мире. OK.

V>Т.е. в гугле, таки, забанили.

V>Так и запишем...

Подожди, что ты сейчас утверждаешь?
Что ARM — не [чистый] RISC, или что у RISC-ов не бывает out-of-order?
Первое может быть правильно, второе — скорее всего нет.
Re[27]: Эльбрус - 8 ядер
От: Sharov Россия  
Дата: 06.06.17 14:57
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Подожди, что ты сейчас утверждаешь?

K>Что ARM — не [чистый] RISC, или что у RISC-ов не бывает out-of-order?
K>Первое может быть правильно, второе — скорее всего нет.

Не скорее всего, а точно нет.
Кодом людям нужно помогать!
Re[9]: Эльбрус - 8 ядер
От: IID Россия  
Дата: 06.06.17 15:03
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Могу рассказать, что произойдёт, если в этих 12 командах тоже встретится условный переход


процессор будет исполнять уже 4 ветки одновременно. Потом 8, 16, 32 ... 65536

расскажи.
kalsarikännit
Re[23]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 06.06.17 15:39
Оценка:
Здравствуйте, netch80, Вы писали:

Почитал далее — везде аналогичные заблуждения.


N>Верно. Неверно другое, невыделенное. Это не ветвление. Это неприменение результата команды.


Да какой "неприменение"? Команда тупо не исполняется и всё.


N>Ты же не считаешь, надеюсь, условное выполнение в полноразмерном ARM32 ветвлением?


1. В ARM32 есть не только условное выполнение.

2. Инструкция вида ITxxx делает от одной до 4х последующих инструкций условными, избавляя от необходимости в условных переходах, которые выполняются дольше.

3. Можно условно пропустить безусловный переход — это уже полноценное ветвление или еще нет?


N>При этом команда может частично исполниться — не в смысле видимых результатов, а в смысле подготовительных действий (например, для доступа к памяти процессор может выполнить сложение базы со смещением).


Да. Стадия fetching — одна из стадий RISC-конвейера, хотя далеко не все инструкции нуждаются в этой стадии. Но уж таковы законы жанра — в RISC длительности команд всегда фиксированы. Именно поэтому, зная, на какую тактовую частоту разрабатывается программа, можно получать тот самый true realtime, т.е. заменять RISC-процессорами железо. Мы как-то сделали возможность "допрошивки" 4-х байт в памяти программ в зависимости от точной измеренной частоты кварца конкретного экземпляра (последние кучу цифр после запятой), получая большую временнУю точность алгоритма.


V>> Безусловные ветвления отслеживаются еще на этапе предвыборки.

N>Не раньше декодирования, вообще-то.

Обсуждать подобным образом можно только конкретные процы, а не "вообще". )


V>>Вот, опять ты недоразобрался. Речь о конвейере этих VLIW-команд, а не о нескольких командах в составе пакета. Я же написал выше — почти во всех современных RISC присутствует конвейер команд. Собсно, эта инфа даётся на первых страницах даташита процессоров, т.е. найти её легко.

N>Во-первых, там "даташиты" очень плотные (в смысле, языком, понятным только тем, кто уже в теме).

Ерунда. Просто некоторые люди терпеть не могут любую документацию.


N>Во-вторых, разные версии могут иметь разные особенности


Даташит всегда идёт на конкретную микросхему, а не на "абстрактную архитектуру".


N>Поэтому я не буду гуглить настолько вглубь (всё равно бесполезно без практического опыта), а буду таки задавать вопросы тому, кто утверждает, что он уже съел собаку на них и потоптался по граблям (так ведь?) Вопрос, собственно — что ты называешь конвейером VLIW команд?


Ну хотя бы на картинки можно было самому взглянуть? ))



N>Конвейер пакетов команд, или отдельных команд в пакете? Если второе, то означает ли это, что последующий за пакетом, в котором команда перехода, пакет может выполниться _частично_?


Нет, пакет исполняется целиком.
Другое дело, что пакет может быть не полным, т.е. в одном пакете могут быть инструкции не на все исполнительные блоки.
Собсно, задача оптимизатора в том и состоит, чтобы "поплотнее" напихать каждый пакет.



V>> И это противоречит философии RISC, когда код напрямую оперирует реально-существующими исполнительными устройствами.

N>Это в VLIW он так фигурирует. Но откуда такие выводы для RISC? Там никогда не было такой привязки.

Вот опять та же ошибка, на которую я указал пару сообщений назад — ты путаешь т.н. "архитектуру" как спецификацию системы команд и конкретную реализацию проца, совместимую с этой архитектурой.


N>"A common misunderstanding of the phrase "reduced instruction set computer" is the mistaken idea that instructions are simply eliminated, resulting in a smaller set of instructions." Против твоего проезда по количеству команд.


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


N>"Этот вопрос" это какой? RISC целиком или только утверждение, что RISC несовместим с суперскалярностью? Так последнее не утверждается никак — этот вопрос обойдён. Зато в статье "Superscalar processor" явно упомянут PowerPC. Он, по-твоему, RISC, или нет?


PowerPC изначально был RISC, как и ARM.


N>Повторю вопрос выше. PowerPC — не RISC, или не суперскалярный?


Дык, назови конкретную марку микросхемы и я дам тебе точный ответ.


N>А что насчёт ARM, например, в диапазоне от Cortex-A7 (суперскалярный на 2 исполнителя) до Cortex-A17 (полный OoO)?

N>Они еретики и должны быть разрушены? Или им надо давать другое имя?

Лучше перестать, наконец, путать систему команд и реализацию совместимого с этой системой команд процессора.
Неужели после первого моего замечания не стало ясно:

Наверно ты видел где-то реализацию OoO-процессора, совместимого с системой команд некоей RISC-архитектуры и малость недоразобрался в происходящем. Хотя, казалось бы, всё на поверхности.


Это же не бог весть как сложно... Студент 2-го курса и то уже давно был понял свой залёт.


V>>>>В общем, применение термина SIMD к суперскаляру — оно не корректно, если быть строгим. Даром внешне, т.е. сугубо для программиста, эта техника выглядит почти одинаково в обеих случаях.

N>>>Это ортогональные друг другу сущности. И "внешне для программиста" они никак не могут одинаково выглядеть. Или ты уже и SIMD переопределил по-своему?
V>>Зачем по-своему? Изначально SIMD появился в процессорах архитектуры MIPS

N>"The first use of SIMD instructions was in the vector supercomputers of the early 1970s such as the CDC Star-100


Мы еще про микропроцессоры говорим? Или уже перешли на рассыпуху и арифмометры, размером с пол-комнаты? ))


N>А в MIPS, значит, они не были "доступные для непосредственного их программирования"?


Вот там как раз были, бо RISC.


>> А в архитектуре x86 эти SIMD-команды исполняются "непонятно на чём" — на некоем черном ящике.

N>То есть если бы ставился отдельный сопроцессор в гнездо, ты бы понимал, на чём оно исполняется, а если в составе процессора, то уже нет?

Да пофик на гнёзда, я а другом говорил. В мире CISC и OoO я понятия не имею о длительности каждой команды и не могу включать эту информацию в свою программу.

Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.


N>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?


Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.


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


Никогда не понимал вот этого настроя... Тебе вроде и поспорить охота, но и копаться в предмете спора лень.
Остаются тупые провокации в надежде, что принесут инфу на блюдечке с голубой каёмочкой. Когд я писал про "скучно" — имел ввиду именно это. Ты даже не пытаешься заинтересовать собеседника новой инфой или неожиданным взглядом на старую.
Хотя, когда-то давно, помнится, ты этими навыками обладал.
Обленился ты, кароч, по самое нимогу. ))
Отредактировано 07.06.2017 3:17 vdimas . Предыдущая версия .
Re[2]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 06.06.17 16:07
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Не факт, что в военных комплексах будет использоваться Linux, а не какая-нить реалтаймовая ось или даже вовсе без всякой ОС. В крайнем случае есть разновидности реалтаймового Linux.


Когда перепрыгнут, тогда и будешь говорить гоп. А пока это всего лишь фантазии.

V>Т.е. пруфов нет. Так и запишем.


Читать не умеет, так и запишем.
Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 06.06.17 16:13
Оценка:
Здравствуйте, netch80, Вы писали:

N>Hard realtime есть в виде нашлёпок на Linux. Но можно и отдельно. Имея Linux, использовать его как трамплин для построения целевой специальной ОС — банально. Лишь бы эта ОС выполняла все непрямые функции.


Hard realtime вообще невозможен, когда исполнение может замерзнуть на сотню-тысячу тактов в произвольный момент времени из-за планировщика задач, промаха кэша или memory barrier.

N>Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым"


А, ну-ну. Тогда и на винде можно делать очень даже Hard realtime, если записать в спеке, что любая операция должна выполняться не более секунды.
Отредактировано 06.06.2017 16:15 Kesular . Предыдущая версия .
Re: Подскажите как сейчас принято искать работу
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 16:29
Оценка:
Здравствуйте, Kesular, Вы писали:

N>>Hard realtime есть в виде нашлёпок на Linux. Но можно и отдельно. Имея Linux, использовать его как трамплин для построения целевой специальной ОС — банально. Лишь бы эта ОС выполняла все непрямые функции.

K>Hard realtime вообще невозможен, когда исполнение может замерзнуть на сотню-тысячу тактов в произвольный момент времени из-за планировщика задач, промаха кэша или memory barrier.

Hard realtime всего лишь говорит, что изделие ни при каких условиях не должно отработать реакцию на событие дольше, чем установленное время, иначе оно неработоспособно и не подлежит эксплуатации. Хоть десять тысяч тактов, хоть миллиард.
Есть ещё firm realtime (не успели => выкинули один результат, качество открыто ухудшилось, но система считается рабочей) и soft (обеспечиваем в среднем по больнице). Бывают комбинированные (soft для среднего, но firm или hard для максимума).

С другой стороны, само построение системы так, что в ней есть проблемы подобного рода, заставляет думать в духе "ну мы вроде гарантировали, что оно не более 21 раза замёрзнет на 200 тактов, но где гарантия, что их вдруг не будет не 21, а 42?" — и тогда начинают таки думать про системы, где SRAM, а не DRAM+кэш, барьеры памяти не нужны, а планировщик занят только background-задачами, а всем остальным немедленно уступает место (и ещё пачка вкусностей, например, автосвитчинг банка регистров).

N>>Кэшу он не противоречит, если в закладках по времени рассчитать вариант "кэш полностью заполнен чужим содержимым"


K>А, ну-ну. Тогда и на винде можно делать очень даже Hard realtime, если записать в спеке, что любая операция должна выполняться не более секунды.


Первая часть — про то, что hard realtime может быть при условии "не более секунды" — абсолютно верна. Это всего лишь hard realtime с необычно высоким временем реакции.
Вторая — что на винде можно его делать — очень сомнительна, учитывая, например, пачку недавних историй с Windows 10 с неплановыми перезагрузками. Впрочем, я и на более ранних видел ситуации типа "задумалась на несколько секунд ХЗ почему".
The God is real, unless declared integer.
Re[24]: Эльбрус - 8 ядер
От: Иван Дубров США  
Дата: 06.06.17 16:49
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Типичный цикл контроллера, который сейчас делает то, что раньше делало железо — он фиксирован. Как по-твоему, происходит фазовое детектирование того же WiFi? Ни о каких таймерах там не может быть и речи, ес-но. Там прямо в теле цикла фиксированной длительности считывается со входного порта 0/1 и происходит суммирование с отсчётами синуса и косинуса (90 градусов). 0 — отнять, 1 — прибавить. Вот тебе операция умножения входного сигнала (-1/1) на эталон. Или прецизионный контроллер управления шаговым двигателем — аналогично. Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.


А можно чуть по-подробнее, что не так с таймерами, в случае с шаговым двигателем?
Re[27]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 06.06.17 18:29
Оценка:
Здравствуйте, Kernighan, Вы писали:

K>Что ARM — не [чистый] RISC


Давно.
Например, Cortex-A — это не RISC ни в каком из мест, а Cortex-R — практически чистый RISC, предназначен для того самого hard realtime.

Система команд у этих веток практически идентичная (за исключением нескольких расширений).


K>или что у RISC-ов не бывает out-of-order?


Бывает OoO реализации процов на некую систему команд, которая появилась изначально для некоего RISC-процессора.

Строгое разделение архитектур на RISC и CISC осталось в 90-х. Сейчас уже понятно, что "выжили" единицы архитектур, но выжили сугубо в терминах абстракций их системы команд/регистров, т.е. ISA. Сегодня на эти "абстракции" натягиваются различные подходы в реализации.
Re[28]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.06.17 21:33
Оценка:
Здравствуйте, vdimas, Вы писали:

K>>или что у RISC-ов не бывает out-of-order?

V>Бывает OoO реализации процов на некую систему команд, которая появилась изначально для некоего RISC-процессора.

Power, Alpha, RISC-V изначально создавались под идею "от самых мелких с минимумом конвейера до старших с out-of-order".

V>Строгое разделение архитектур на RISC и CISC осталось в 90-х. Сейчас уже понятно, что "выжили" единицы архитектур, но выжили сугубо в терминах абстракций их системы команд/регистров, т.е. ISA. Сегодня на эти "абстракции" натягиваются различные подходы в реализации.


Мощно задвинул (tm)
The God is real, unless declared integer.
Re[25]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 00:54
Оценка:
Здравствуйте, netch80, Вы писали:

N>Я такие циклы фиксированной длительности помню из более знаменитого источника — драйвер диска для Apple II. 32 или 40 тактов на байт, в зависимости от части дорожки, циклы с NOP-PHA-PLA-etc. для выдерживания ровно нужного количества тактов 6502. И что, это хорошо?

N>По-моему, это всё тупой закат солнца вручную.

Дык, ничего не изменилось с тех пор. Просто сейчас аналогичная программа перенесена из ЦПУ в контроллер, расположенный прямо прямо на диске.


N>Шаговый двигатель там тоже управлялся, было. Аж ностальгия скоро пробьёт. Зато как сейчас хорошо всей этой дурью не маяться.


Кому хорошо, тебе лично?
Значит тебе интересней другой род программирования, только и всего.


V>> Без принципиальной возможности обеспечить требуемую длительность каждой ветки алгоритма все эти вещи невозможно будет делать в софте, придётся опять возвращаться в каменный век — колхозить доп. аппаратные исполнительные блоки.

N>Наоборот, дополнительные блоки это прогресс, а не каменный век.

Прогресс — это удешевление конечного устройства и ускорение цикла разработка->продажа.
Всё остальное называется "программист ниасилил". ))


N>>>И в чём тогда разница этих предметных областей? Чем, по-твоему, так принципиально отличается то, что в MIPS, от SSE образца x86?

V>>Тем, что не происходило переименования регистров, вестимо. И что программист достоверно знает, сколько там АЛУ и что там происходит.
N>Чем же это лучше? Если нельзя развивать архитектуру с тем, чтобы не переписывать код?

Для конкретного озвучиваемого железа это не важно.
Всё-равно под каждую конкретную железку будет свой "драйвер".


N>Ты же делаешь вид, что всё всегда знаешь


По темам, по которым высказываюсь и в тех объемах, в которых высказываюсь?
ИМХО, это единственно адекватная стратегия.
Остальное должно быть или прямо поставленными вопросами (без ужимок, прыжков, подъ-бок, желания "поймать" и т.д.) или read-only.
Re[25]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 01:07
Оценка:
Здравствуйте, Иван Дубров, Вы писали:

ИД>А можно чуть по-подробнее, что не так с таймерами, в случае с шаговым двигателем?


Зависит от.

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

По собственному опыту, на "толерантое буферирование" лучше отводить ввод-вывод, как популярный пример — по I2C, т.е. удобней иметь асинхронность лишь по линиям передачи информации. Всё остальное можно с относительно большой точностью делать в софте на самых дешевых RISC-контроллерах, а запас по цене лучше "тратить" на более высокую тактовую — это немного развязывает руки.
Отредактировано 07.06.2017 1:08 vdimas . Предыдущая версия .
Re[26]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 07.06.17 05:45
Оценка:
Здравствуйте, vdimas, Вы писали:

ИД>>А можно чуть по-подробнее, что не так с таймерами, в случае с шаговым двигателем?


V>Зависит от.


V>1. Таймеров конечное кол-во.

V>4. В задачах управления более чем одним шаговым двигателем всё еще печальнее.

И сидят три процессора и рулят каждый своим шаговым двигателем, отсчитывая nopʼами задержку... ой, нет трёх процессоров? Какой облом. Значит, таймеры в софте, очередь ближайших срабатывающих (ну, сделана массивом или вообще явным тестом на каждой итерации — неважно)? А как же пункт 1?

V>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).


Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды? Впрочем, знаю. Там должны быть кэш DRAM, OoO исполнение команд... ой, а откуда это он у нас такой? Кто его сюда поставил?

V>3. Выделяя отдельный аппаратный блок под каждую элементарную операцию можно получить не самое оптимальное по цене решение.


А кто сказал "под каждую"?
The God is real, unless declared integer.
Re[14]: Эльбрус - 8 ядер
От: gardener  
Дата: 07.06.17 06:08
Оценка:
V>Собсно, все современные сигнальные процы — VLIW. Есть на ноуте/планшете Bluetooth? — там живет сигнальный процессор. Есть WiFi — аналогично.

В WiFi VLIW нет (из опыта с одним очень распространенным производителем вайфай чипов, и одним не очень). В Bluetooth похоже тоже нет.
Re[15]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 09:43
Оценка:
Здравствуйте, gardener, Вы писали:

G>В WiFi VLIW нет (из опыта с одним очень распространенным производителем вайфай чипов, и одним не очень). В Bluetooth похоже тоже нет.


В Broadcom есть. А по другим производителям инфа совсем скупая.
Re[28]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 07.06.17 10:37
Оценка:
Здравствуйте, vdimas, Вы писали:

N>>И сидят три процессора и рулят каждый своим шаговым двигателем, отсчитывая nopʼами задержку... ой, нет трёх процессоров? Какой облом. Значит, таймеры в софте, очередь ближайших срабатывающих (ну, сделана массивом или вообще явным тестом


V>Каким "тестом"?

V>Что тестировать-то?
V>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.

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

V>Причем, в одном слове можно располагать несколько счетчиков обычно.

N>>на каждой итерации — неважно)? А как же пункт 1?
V>Это ты слишком сложные для себя вопросы пока задаешь. ))

Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).

V>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).

N>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>Любой, с длиной конвейера больше 2-х, вестимо.

Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно. Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний

V>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?


Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время. Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".

N>>Там должны быть кэш DRAM, OoO исполнение команд... ой, а откуда это он у нас такой? Кто его сюда поставил?

V>Ну вот опять. В неприличной форме напрашиваешься на грубый ликбез.
V>Скучно...

Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.
The God is real, unless declared integer.
Re[2]: Подскажите как сейчас принято искать работу
От: Kesular  
Дата: 07.06.17 16:06
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...


Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.
Re[29]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 16:10
Оценка:
Здравствуйте, netch80, Вы писали:

V>>Просто в цикле крутишь несколько счетчиков параллельно, при обнулении счетчика выдаёшь сигнал.

N>А некоторые не крутишь, ибо закончились. А код, по твоему варианту, крутит их всех.

Верно, просто где-то слагаемое будет равно 0-лю или соотв. бит будет нулевой, если несколько счетчиков упакованы в одном слове.


V>>Причем, в одном слове можно располагать несколько счетчиков обычно.

N>>>на каждой итерации — неважно)? А как же пункт 1?
V>>Это ты слишком сложные для себя вопросы пока задаешь. ))
N>Это ты не можешь простейший алгоритм в голове уложить, чтобы не ляпнуть по-тупому такое, что смеются не только лишь все (tm).

Тут наоборот — похоже, что я не могу простейший алгоритм объяснить.

V>>>>2. Точность таймера с учётом времени реакции на прерывание может не удовлетворять требуемым скоростям (скоростям обработки детали, например).

N>>>Это же какой контроллер надо подобрать, чтобы он на прерывание реагировал дольше, чем длится 2-3 команды?
V>>Любой, с длиной конвейера больше 2-х, вестимо.

N>Воистину фейспалм — писали контроллеры такие же "спецы", если у них прерывание не может врезаться в конвейер, когда это действительно нужно.


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


N>Хотя им это не нужно — они же поллят и получают ту же проблему с конвейером и без прерываний


Не получают. Фронт может немного "дрожать", но не более, чем получили бы такое дрожание при реакции на самое первое аппаратное прерывание.
Главное, что ошибка такого дрожания задержки затем не накапливается от слова совсем. А если еще задействовать механизм фазовой автоподстройки для этого цикла, так вообще сколь угодно точно можно импульсы выдавать — с точностью фазы до одного nop, т.е. одного такта.


V>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?


N>Двойной фейспалм — вместо таймеров использовать туалетную бумагу, которая не в состоянии показать даже текущее время.


Увы, именно так. Зря ты отказался хотя бы одним глазом взглянуть на даташиты.
Чтобы "показать текущее время" при наличии только 16-тиразрядных таймеров в той же архитектуре STM32 — это надо еще прилично кода вокруг такого таймера городить на ровном месте. И так будешь всё глубже и глубже закапываться в преодоление на каждом шаге очередных граблей, которые сам же решил и разложить перед собой. А ведь можно взять самый простой чип и обойтись программкой в пол-сотни строчек на асме основного цикла (не берем строчки на инициализацию режимов контроллера).


N>Ну и "спец", который рассказал про событие от одного таймера во время прерывания другого, но точно так же забыл про событие от одного таймера во время поллинга группы таймеров, по рецепту этого же "спеца".


Это ты забыл, что циклы у нас имеют фиксированную длительность, т.е. сработал некий софтовый таймер или нет — ничего не изменится, по-сути.


N>Твой образ на RSDN никакого ликбеза провести не в состоянии — ему самому в школу идти надо, с нуля.


Вот поэтому и скучно, что объяснять совсем уж с 0-ля — это надо в школе, а не на этом сайте.
В принципе, тут достаточно было включить воображение или накатать несколько строчек, чтобы прикинуть — как такие циклы могут выглядеть.

Мне вообще странен подобный игнор некоторыми коллегами того факта, что на один современный центральный проц приходится чуть ли не десяток вспомогательных процов в остальных подсистемах их компов. На них программы по-твоему боги пишут? ))

Такие же программисты и пишут. Ну разве что у них обязательно наблюдается такая особенность как внимательность к мелочам, в отличие от разработчиков цепочек if-ов для обслуживания протокола SIP, например.
Отредактировано 07.06.2017 19:48 vdimas . Предыдущая версия .
Re[4]: Подскажите как сейчас принято искать работу
От: Cyberax Марс  
Дата: 07.06.17 18:16
Оценка:
Здравствуйте, vdimas, Вы писали:

K>>Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.

V>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))
SpaceX использует RT Линукс в системах управления.
Sapienti sat!
Re[25]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 07.06.17 19:45
Оценка:
Здравствуйте, IID, Вы писали:

IID>В нижней части экрана видим бегущую строку. Она бежит вне пиксельной области, т.н. "бордюр", 3 битный порт-регистр, задающий цвет рамки вокруг экрана. Бегушка формируется серией последовательных OUT-ов (и никак иначе, ибо OUT занимает 12 тактов за которые развёртка успевает пробежать 24 пикселя). Серия команд генерится на каждый кадр. И самое весёлое — количество тактов в кадре при любом раскладе должно давать один и тот же остаток от деления на 4, иначе будет рандомный сдвиг на 1-3 двухпиксельных шага по горизонтали. Генератор машкода тоже выровнен по тактам.


Фазовая автоподстройка? ))


IID>Обязательно досмотреть до 3:11, с учётом объяснений про "бордюр" станет ясно, как это устроено. Мы в 1997 реально со стульев попадали, когда увидели.


Не досмотрел. Жаль, что частота развертки моего экрана не кратна исходной частоте развертки.
Такие вещи наблюдал и баловался ими вживую в 90-92-х годах, там когда вживую смотришь, то плавность идеальная, прямо как на Атари тех же времён. ))
По видео этот момент немного теряется, увы.

============
Кстате, раздражает в современных 3D-играх отсутствие той самой плавности смещения картинки и вообще отсутствие плавности любой анимации, которая была когда-то. Сейчас в играх FPS само по себе (да еще и плавающее), а развертка сама по себе. Поэтому, эффект не тот, не тот. ))
Re[5]: Подскажите как сейчас принято искать работу
От: vdimas Россия  
Дата: 07.06.17 20:28
Оценка:
Здравствуйте, Cyberax, Вы писали:

K>>>Достаточно просто представлять уровень бардака в российской военке. Не знаю каких махровым эльфом надо быть, чтобы этого не знать.

V>>Т.е., всё-таки, ракетными системами будет управлять юзверское приложение поверх Linux? ))
C>SpaceX использует RT Линукс в системах управления.

RT Линукс — это не Linux. ))
Это микроядерная ОС, в которой можно запустить специальный слой совместимости Linux. А можно и не запускать...
Для отладки удобно, например, т.е. на этапе разработки.
Re[16]: Эльбрус - 8 ядер
От: gardener  
Дата: 08.06.17 01:32
Оценка:
V>В Broadcom есть. А по другим производителям инфа совсем скупая.

Какой именно чип?
Почему спрашиваю, потому как удивлен. Потому что как раз уверен что в броадком такого нет, именно в wifi, и практически уверен насчет Bluetooth. Я как раз работал у них до недавнего времени, и хорошо знаю архитектуру и какие фирмвари там.
Re[30]: Эльбрус - 8 ядер
От: Иван Дубров США  
Дата: 08.06.17 02:10
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>В любом случае, для сценари использования таймера "выдай мне прерывание через столько-то времени" (а там именно такой сценарий) — это будет накопление ошибки, бо обычно у тебя нет никакой информации о том, сколько действительно времени потребовалось на реакцию на таймер. А когда таймеров более одного, ты находишься в обработке прерывания одного из них, прерывания от других запрещены... Дальше продолжать или уже догадался?


У STM32 можно настроить таймер так, чтобы прерывание только патроны подносило (через теневые регистры). Никакой ошибки, всё аппаратно. Я так в своём коде делаю. Потому и спрашивал, что не так с таймерами. Всё гарантировано по времени.

С циклом мне непонятно, а что с другими прерываниями-то делать? Как раз с прерыванием я бы делал как-то так: один таймер на все шаговики, самый высокий приоритет (чтобы оно гарантированно перебивало все другие прерывания). Запрет прерываний запрещён, только через BASEPRI и без запрета этого самого прерывания от таймера. В таком варианте, время реакции, по идее, будет всегда одно и то же.

Непонятно только, как очень близкие шаги по разным выходам делать (выдали 1 по одному выводу и через 1 такт -- по другому). Можно, наверное, немного смещать шаги, с учётом макрошагов, по идее, ошибка будет маленькая.

Может быть, можно через DMA как-то (чё-нить типа копировать из памяти в регистр GPIO по таймеру и в теневые регистры таймера по этому же таймеру).
Re[31]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 08.06.17 05:15
Оценка:
Здравствуйте, Иван Дубров, Вы писали:

ИД>У STM32 можно настроить таймер так, чтобы прерывание только патроны подносило (через теневые регистры). Никакой ошибки, всё аппаратно.


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

Я "не дожил" в ассемблере до появления теневых регистров в армах, но правильно ли я понял сию тонкость?


ИД>Я так в своём коде делаю. Потому и спрашивал, что не так с таймерами. Всё гарантировано по времени.


А как получить частоту, скажем, ровно 2/255 от тактовой?
Что вообще можно сделать с обычным 16-тиразрядным счётчиком, кроме как использовать его для чего-то малокритичного?


ИД>С циклом мне непонятно, а что с другими прерываниями-то делать?


Их нет во время рабочего хода инструмента.


ИД>Как раз с прерыванием я бы делал как-то так: один таймер на все шаговики


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


ИД>Непонятно только, как очень близкие шаги по разным выходам делать


Именно что. А надо независимо обслуживать задержки. И даже выводить сигналы на разные порты в один и тот же момент времени, т.е. в рамках одной и той же команды записи в порт — это же просто запись в некий адресуемый регистр некоей битовой маски (пусть три младших разряда соответствуют 3-м шаговикам).


ИД>Можно, наверное, немного смещать шаги, с учётом макрошагов, по идее, ошибка будет маленькая.


Ошибка будет просто чудовищная, как по мне — в несколько десятков тактов. Более того, непонятно, как подстраивать фазу в такой конфигурации.


ИД>Может быть, можно через DMA как-то (чё-нить типа копировать из памяти в регистр GPIO по таймеру и в теневые регистры таймера по этому же таймеру).


Или не париться, а взять самую простую конфигурацию чипа и закодить таймеры в софте.
Я так делал. Играет двухголосную музыку, подаёт звонки, ведет отсчёт точного времени дня.
Тупо фиксированный цикл и зашита точная частота кварца конкретного экземпляра — годами часы можно не корректировать.
А частоты нот, знаешь ли, бывают очень дробными, а фальшь режет слух. ))
Отредактировано 08.06.2017 5:49 vdimas . Предыдущая версия .
Re[28]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 08.06.17 05:49
Оценка:
Здравствуйте, vdimas, Вы писали:

V>По-идее, если ЖК-монитор вносит строго фиксированную задержку, то от ghosting можно было бы избавиться — он же является индикатором неравномерной скорости движения.


А не, гоню.
Скорее всего ghosting — это признак длительного равномерного свечения картинки, при том что взгляд двигается синхронно со средней скоростью фигуры. Да, для избавления от этого эффекта длительность показа картинки (каждой её части) должна быть менее ~1/25 от полного цикла.

А ЖК-монитор "показывает" всё время.
Re[32]: Эльбрус - 8 ядер
От: Иван Дубров США  
Дата: 08.06.17 06:37
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ну вот самая распространённая задачка вокруг таймеров (остальное не есть "задачка") — это установка после каждого срабатывания таймера новой для него длительности. Насколько я понимаю, через теневые регистры это можно сделать, ОК. Прямо в теле прерывания.


V>Я "не дожил" в ассемблере до появления теневых регистров в армах, но правильно ли я понял сию тонкость?


Да, как-то так.

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


Если программа заранее известна, то почему нет? Все длительности будут строго в соответствии с программой. Обработается ли прерывание чуть раньше или чуть позже -- не важно, оно же только на следующий цикл грузит (т.е при окончании цикла N прерывание будет обрабатывать длительности для цикла N+2). Главное, чтобы минимальная длительность была гарантированно больше самого пессимистичного сценария обработки прерывания.

V>А как получить частоту, скажем, ровно 2/255 от тактовой?


Таймер же (опосредованно) от того же генератора тактовой частоты работает. Если задержка в целых тиках не выражается, значит не выражается, надо переменные длительности делать. Можно чередовать длительности 127 и 128, в среднем будет 127.5.

V>Что вообще можно сделать с обычным 16-тиразрядным счётчиком, кроме как использовать его для чего-то малокритичного?


Можно сцепить два таймера и получить один 32-разрядный (старший щёлкает по переполнению младшего).
Отредактировано 08.06.2017 6:51 Иван Дубров . Предыдущая версия .
Re[17]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 08.06.17 06:59
Оценка:
Здравствуйте, gardener, Вы писали:

G>Какой именно чип?


А какой достоверно не?
В открытом доступе есть только инфа о том, какие архитектуры ядер они лицензировали (я указывал выше) или на основе чего сделано ядро управляющего модуля в чипе (сейчас ARM, когда-то давно MIPS), но никогда не указывается, как они делают микропрограммируемую цифровую логику на чипе, которая, собсно, делает полезную работу. Остаётся делать выводы на основе того, какие архитектуры они лицензируют.


G>Почему спрашиваю, потому как удивлен. Потому что как раз уверен что в броадком такого нет, именно в wifi, и практически уверен насчет Bluetooth. Я как раз работал у них до недавнего времени, и хорошо знаю архитектуру и какие фирмвари там.


О какой фирмваре ты говоришь? Которая предназначена для управляющего ядра на основе ARM?
Серьёзно? ))

Или ты про VLIW-микрокод модуля протокола, что он не VLIW? ))
Или речь шла о блоке шифрования?
Или о блоках FFT/iFFT, кодирования/декодирования, разделения поднесущих в цифре и т.д.?
(а у последних вообще бывает обновляемая фирмварь? — скорее всего нет, бо незачем)
Re[18]: Эльбрус - 8 ядер
От: gardener  
Дата: 08.06.17 07:21
Оценка:
V>Или ты про VLIW-микрокод модуля протокола, что он не VLIW? ))
V>Или речь шла о блоке шифрования?
V>Или о блоках FFT/iFFT, кодирования/декодирования, разделения поднесущих в цифре и т.д.?
V>(а у последних вообще бывает обновляемая фирмварь? — скорее всего нет, бо незачем)

Понятно. Т.е. ты не знаешь о чем говоришь. Там не то что VLIW, а и процессоров никаких нет.
Re[19]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 08.06.17 07:54
Оценка:
Здравствуйте, gardener, Вы писали:

G>Понятно. Т.е. ты не знаешь о чем говоришь. Там не то что VLIW, а и процессоров никаких нет.


Ясно.
Открываю даташит и вижу микропрограммируемое устройство, помимо ядра ARM.

Вот так ты "работал". ))
Не поделишься, чем именно ты там занимался?
Re[33]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 08.06.17 08:06
Оценка:
Здравствуйте, Иван Дубров, Вы писали:

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

ИД>Если программа заранее известна

Вот. ))

А если у нас токарный станок, у которого скорость вращения детали может зависеть банально от давления резака на материал, то у тебя "известная заранее программа" представлена в таком виде, что её еще надо отображать на мгновенную угловую скорость вращения детали.


ИД>Таймер же (опосредованно) от того же генератора тактовой частоты работает. Если задержка в целых тиках не выражается, значит не выражается, надо переменные длительности делать. Можно чередовать длительности 127 и 128, в среднем будет 127.5.


А если 127.3333? ))
Это я просто намекаю, что ты всё делаешь верно, но в итоге получишь такой алгоритм, что таймер станет уже фактически не нужным — у тебя и так получится "ручной" генератор произвольной частоты, примерно как в посте по ссылке, где дан сниппет про генератор синусоиды:
http://www.rsdn.org/forum/flame.comp/6803924.1
Там можно взять только старший бит — и будет меандр нужной дробной частоты.


V>>Что вообще можно сделать с обычным 16-тиразрядным счётчиком, кроме как использовать его для чего-то малокритичного?

ИД>Можно сцепить два таймера и получить один 32-разрядный (старший щёлкает по переполнению младшего).

А в базовой конфигурации есть 6 таймеров, которые можно подобным образом сцепить?
Re[20]: Эльбрус - 8 ядер
От: gardener  
Дата: 08.06.17 08:09
Оценка:
V>Ясно.
V>Открываю даташит и вижу микропрограммируемое устройство, помимо ядра ARM.

Даташит на что? Название чипа пожалуйста.
Я разве говорил что там один процессор? Будь внимательнее. Повторяю — VLIW нигде нет. А те функции, которые ты перечислял — там и процессора нет.

V>Вот так ты "работал". ))


Опа, вот это поворот.

V>Не поделишься, чем именно ты там занимался?


Software engineering. Вот как раз фирмвары которые там.
Re[2]: Подскажите как сейчас принято искать работу
От: Kernighan СССР  
Дата: 08.06.17 09:09
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Я не знаю, каким махровым нубом надо быть, чтобы предполагать, что система обнаружения и управления радаром (для примера) будет управляться юзверским приложением на какой-нить обычной Linux. Это просто пробитие дна какое-то...


Система управления радаром, которую я видел управлялась Линуксом (МСВС).
Насколько это "обычный Линукс" — не знаю. Насколько непосредственно управлялась — тоже.
Визуально это выглядит как стойка размером с холодильник,
к которой присоединён компьютер на Эльбрус под МСВС.
Ты конечно можешь сказать, что весь реалтайм в этой стойке,
а на Линуксе только ГУИ, и наверное это действительно так.
Re[3]: Эльбрус - 8 ядер
От: Sheridan Россия  
Дата: 08.06.17 16:48
Оценка:
Здравствуйте, netch80, Вы писали:

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

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

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

Ты про лампочку scroll lock забыл сказать...
Matrix has you...
Re[21]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 08.06.17 17:56
Оценка:
Здравствуйте, gardener, Вы писали:

G>Даташит на что? Название чипа пожалуйста.


Пусть будет BCM4360.
Или этот: http://www.cypress.com/file/298076/download
Или: http://www.cypress.com/file/298016/download
Для нашего обсуждения там, считай, идентичная архитектура.

В даташитах есть некий микропрограммируемый модуль PSM.

The programmable state machine (PSM) is a microcoded engine, which provides most of the low-level control
to the hardware, to implement the IEEE 802.11 specification. It is a microcontroller that is highly optimized for
flow control operations, which are predominant in implementations of communication protocols.

Твои комментарии?


V>>Не поделишься, чем именно ты там занимался?

G>Software engineering. Вот как раз фирмвары которые там.

На управляющий ARM или на упомянутый процессорный модуль?

Еще вопрос — зачем они лицензировали CEVA-XC архитектуру?
Неужели лицензировали, но не используют?
Re[22]: Эльбрус - 8 ядер
От: gardener  
Дата: 09.06.17 00:11
Оценка:
V>Пусть будет BCM4360.
V>Или этот: http://www.cypress.com/file/298076/download
V>Или: http://www.cypress.com/file/298016/download
V>Для нашего обсуждения там, считай, идентичная архитектура.

Они прилично внутри отличаются. C 4360 я как раз работал до того как уйти в тим, который как раз вот разрабатывал эти IoT чипы (и который был продан Cypress).

V>В даташитах есть некий микропрограммируемый модуль PSM.

V>

V>The programmable state machine (PSM) is a microcoded engine, which provides most of the low-level control
V>to the hardware, to implement the IEEE 802.11 specification. It is a microcontroller that is highly optimized for
V>flow control operations, which are predominant in implementations of communication protocols.

V>Твои комментарии?

Там никаких VLIW в помине нет. Доморощенный контроллер. Своя простая система команд.
Собрать AMPDU из набора подготовленных буферов и параметров, отослать в MAC, обработать BACK, сделать retry, etc.
Они его используют насколько я понимаю по историческим причинам. Например где я сейчас работаю маппинг функций на железо не абсолютно такой же, но похож, и мы это делаем обычным RISC небольшим процессором.


V>>>Не поделишься, чем именно ты там занимался?

G>>Software engineering. Вот как раз фирмвары которые там.

V>На управляющий ARM или на упомянутый процессорный модуль?


Для АРМа. Но при этом доступ к исходникам этого PSM у меня был, и я туда периодически заглядывал, хотя и не коммитил. Туда вообще мало кто коммитит, там небольшая группа. Не то чтобы что-то сложное, просто там небольшой набор функциональности.


V>Еще вопрос — зачем они лицензировали CEVA-XC архитектуру?

V>Неужели лицензировали, но не используют?

Без понятия. Это именно WiFi business unit? Потому как Broadcom здоровый и реально много чего делает.
В WiFi этого не было.
Re[4]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 09.06.17 05:45
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


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

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

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

S>Ты про лампочку scroll lock забыл сказать...

И это тоже, безусловно, но я хотел сказать это уже в ответ на реплику коллеги БП. Но он молчит...
The God is real, unless declared integer.
Re[32]: Эльбрус - 8 ядер
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 09.06.17 07:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>while(true) {

V> acc1 += step1;
V> acc2 += step2;
V> byte result = ((acc1 & 0x80000000) >> 30) | ((acc2 & 0x80000000) >> 31);
V> outp(some_port, result);

V> calc_next_values_of_step1_and_step2();

V>}
V>[/ccode]
V>Заметь, что пара управляющих сигналов выводится синхронно.

V>Ну а для быстродейдствующей обработки какой-нить детали сначала высчитывается некий "батч" (как раз можно использовать время на обратный ход инструмента), а потом этот батч прогоняется, т.е. остальная часть может выглядеть примерно так:


Ага, вот с этих точек уже понятно. Предрасчёт разметки под управление.
step1, step2 вычисляются делением. Это дорогая операция; возможно, у тебя аналогично она делается в свободное время, или используется готовая таблица обратных чисел.
Особой ценности в выводе двух сигналов одновременно я не вижу, но предположим, что для какой-то аппаратуры это важно.

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

V>Понятно, что операция навроде ((acc1 & 0x80000000) >> 31) вычисляется в реальности лишь однажды или вообще заменяется условным исполнением/пропуском (и всё-равно лишь однажды). Т.е. на асме это всё еще выразительней получается, бо в C++ слишком многословно и не верно. Там надо признак переполнения прибавить к индексу. Просто для выражения этого в С потребуется заводить переменную двойной ширины только ради опроса младшего бита старшего слова.


Это уже не так важно для общей концепции.

N>>Так это, конечно, реализуемо, но не отвечает ни на один из поднятых мной вопросов о качестве синхронизации внешних акций в таком исполнении.


V>Согласен, твой код не отвечает ни на один из вопросов.

V>Более того, он позволяет делить тактовую частоту (пусть нам требуется в некоей задаче генерировать некую частоту) лишь на целые числа.

С чего это? В моём построении за это отвечает установка следующего лимита. В твоём — шага.

N>>Ну вот я даже код навёл. Теперь скажи, что в нём не так, по твоему мнению.


V>В нём не так то, что ты хоть и работал со звуковой областью когда-то, но конкретно темы обработки звука не касался, похоже.


Да. У нас фирма уходила от этого по максимуму (я даже местами удивлялся). Вся трансформация кодеков и т.п. — на внешние чужие изделия, в крайнем случае (для всяких MOH) — на астериск/аналог.

V> Потому что если бы касался, то ты хотя бы раз в жизни писал генератор синусоиды, который пишется примерно так:


Генератор синусоиды писал. Не на заказ. Таки на явных синусах, потому что не было причины тут экономить.
Дальше — по таблице готовых значений. Для того железа скорость и затраты по памяти устраивали с головой.

V>
V>unsigned phase = 0;
V>const unsigned delta = ulong64_t(MAX_UINT32)*freq/sample_rate;

V>unsigned sin_gen_next() {
V>    return fixed_point_sin(phase+=delta);
V>}
V>

V>Заметь, не надо сравнивать на каждом шаге и по результату отнимать 2*PI.
V>Классика вычислений с фиксированной точкой — это масштабирование любых данных. В данном случае диапазон 0..2*PI отмасштабирован на диапазон 0..MAX_UINT. Причем, получили честную точность 32 разряда, в отличие от точности 24 разряда в случае использования float.

Только ты самое вкусное и важное тут не показал — как этот fixed_point_sin() устроен. В таблицу 2**32 значений я не верю. Таблица значений с фиксированным шагом, и аппроксимация промежуточных точек? Тогда на аппроксимации тоже нужно применить арифметику без плавучки и делений на неконстанты.
Я предположу, что есть таблица, например, на 1024 значения. Может, ещё меньше. Дальше — интерполяция через сдвиг и сложение.
И, кстати, "честные 32 разряда" тут по большей части просто шум.

А ещё у тебя может оказаться, что истинное freq/sample_rate нецелое. Тогда ты одной простой delta не обойдёшься.

N>>Ну вот я и включаю. Поведение подобных процессоров определено для такта, не так ли? Если на такте t поднялось прерывание таймера, то, например, на t+2 его заметил блок прерываний процессора, на t+3 уже пошла грузиться команда с нового адреса.

V>А еще надо запихать текущую инструкцию в стек.

Мнэээ... стек чего? Или ты про сохранение старого PC в стек? Это обсуждаем ниже.

N>>(Предполагаю, что если думают о скорости, то отработка прерываний это сохранение PC+PSW в служебные регистры процессора и загрузка новых из таких же служебных, оперативная память тут не используется.)

V>В контроллерах его внутреннюю оперативную память можно рассматривать как продолжение файла регистров, там точно такая же скорость обращения, бо это регистровая память, как L0.

Значит, пусть пишет по фиксированному адресу.

N>>Декодиться и исполняться она будет, например, от t+4 до t+7. И что, эта поправка не может быть заложена в задание таймера?

V>А как ты думаешь, почему у "самоделкиных" их фрезерные и токарные станки работают примерно в 10-100 раз медленней, чем промышленные экземпляры?

Я вообще не в курсе обстановки у станков

V>Может от того, что при выдаваемой ими ужасной временнОй точности управления приходится в 10-100 раз снижать скорость перемещения резака относительно детали? ))

V>Разумеется, любую погрешность можно учесть и компенсировать, но я ж сходу упомянул, каким именно образом.

Не очень. Обратной связи в твоей схеме как-то не видно. А мне как-то стрёмно видеть на своём выходе изделия, которые способны на такое, как тот автопогрузчик, что завалил целый склад от того, что что-то вдруг оказалось на пути.
Потеря заготовки от того, что шаг не выполнился, тоже неприятна.

N>>Да видел я их. Я не запоминаю, за отсутствием прямой необходимости, в какой из современных рахитектур какое именно убожество применено и выдано за новейшие достижения нейтринной мегалоплазмы


V>Дык, в архитектуре Intel с таймерами еще на пару порядков всё печальнее. Там вообще полная ж-па. У тебя на сегодня нет никакой возможности узнать текущее точное время. У тебя на выбор только правильно идущие часы с точностью ~1/64 сек или еще есть часы с хорошей точностью, но всегда идущие неправильно (query performance counter).


Мнэээ? Как минимум есть ещё PIIX/ACPI timer, APIC timer, HPET main counter. Тут уже ты явно отстал от нынешних реалий. И что ты назвал "неправильно идущие"? Если постоянный темп, то один раз зафиксировать смещение от внешнего времени (если оно вообще нужно) и потом его прибавлять — задача тривиальная даже для embedded
И откуда цифра 1/64? Ни один из известных мне таймеров системы Wintel не знает такой точности. Ты, наверно, вспомнил 1/18 — это то, что получится, если i8254 запрограммировать на максимальный период (65536) и считать только его прерывания, без чтения текущего значения счётчика.

N>>это счётчик времени

V>Ага. Тактовая этого счётчика какова? А разрядность? А время доступа к нему?

Тактовая — для embedded, должна совпадать с тактовой процессора, ну в крайнем случае в 2-4 раза ниже. Для обычного компа — годится сейчас от ~10 МГц.
Разрядность — такая, чтобы было минимум с 2-3-кратным запасом от максимального времени, на сколько можно позволить себе выключать прерывания. Например, 32-разрядный (копейки, по нынешним временам) и при 1ГГц тактовой (фантастически высокое для embedded, да?) это более 4 секунд => хватит с головой.
Время доступа — как к обычной ячейке памяти (SRAM), кэша.

N>>Ну тогда это порочный круг. Одни "спецы" вместо нормальных таймеров подсовывают тошнотворные пародии. Другие не просто соглашаются с этим работать (вместо того, чтобы вывалять первых в дёгте и перьях), но и хвалят свои решения, которые обходят проблемы этих пародий.

N>>И это не только в таймерах, просто мы сейчас говорим о них.
V>Это дело привычки к определённому классу задач. Когда занимаешься этим постоянно, то подобные задачки решаются уже мозжечком, фактически не потребляя квантов внимания.

Да понятно, что можно обойти (для большинства случаев) подобные грабли. Вопрос, насколько это грязно и совместимо с некоторыми другими требованиями.
Например, перепрограммирование i8254 всегда теряет точность на самом этом процессе. А это сейчас достаточно типичное требование — менять темп прерываний или даже заказывать на конкретные моменты. Если использовать другой clocksource, проблемы с точностью счёта времени уже нет. Хотя в HPET, например, компараторы глупые, иногда и там можно потерять кусочек.

V>Просто ты заведомо неверно судишь о происходящем. Судить технические подходы можно лишь по некоторым критериям, где критерии обязательно зависят от самих же технических подробностей. ))


От _других_ технических подробностей. А так — да, embedded чудовищно широк, и мой опыт с твоим, похоже, пересекается минимально. Потому я на те твои подробности, которые создают твои критерии, смотрю временами, как баран на новые ворота.

V>Ты же взял некие абстрактные критерии, где ни один из них не является важным для обсуждаемой предметной области.

V>Да тут не то, что в области низкоуровневых микроконтроллеров... тут даже в деле написания банальнейших дров под высокоуровневый ЦПУ на твоей машине — и уже твои критерии не работают. Ты слишком прикладной программист.

См. выше про области. Но можно сказать и так, я полуприкладник-полусистемщик, но с embedded мало общался, и не сильно горю идти туда.

N>>Отлично. А теперь скажи, что получится, если у тебя будет необходимость выполнить воздействие двум разным двигателям с интервалом меньше, чем эта длительность отработки одного двигателя. Например, work1() и delay() в коде выше — по 2 мкс, а тебе надо что-то сделать для 1 и 2 с разницей в 1 мкс.


V>Выделил ошибку.

V>Не у меня, а у тебя.
V>У тебя там не получится ничего, ес-но, как ты сам абсолютно правильно сейчас подметил.
V>Только зачем тогда было приводить заведомо неработающий код?

Например, потому что ты не объяснил, как у тебя выглядит само воздействие. Установка/снятие одного бита в регистре — действие банальное, но могут быть и в разы более сложные по конструкции, включая опрос текущего состояния, коммутацию банков в схеме доступа и т.п.
А так как не объясняешь, приходится общаться, как дизайнеру с заказчиком — показывать образцы и получать ответы типа "вот этот где-то похож, но зелёного подбавить, а из вот того рамочку перенести и пузырьки на фоне".

V>А потом ты обижаешься, когда я недвусмысленно намекаю, что ты ведешь обсуждение более чем странно, где странностью является добровольная бестолковость какая-то... ХЗ... никогда этого не пойму...


Ну когда ты, претендуя на звание инженера, ведёшь себя как гуманитарий — заказчик дизайна, естественно, что обижаюсь

N>>И что зависит от качества программистов для этих вспомогательных, кроме очевидного фактора корректности результата?

V>Тут тоже ХЗ. Но есть наблюдения — примерно половине программистов этот род деятельности не даётся вообще никак ни под каким видом. Хоть кол на голове им теши или даже под страхом расстрела. Казалось бы — там всё СЛИШКОМ элементарно... человек запросто пишет довольно-таки большие проги, использует сложные библиотеки и т.д... А вот просто пару бит туда-сюда погонять — полный ступор.

В теме обучения высокому программированию я, извини, не копенгаген, хоть и стараюсь собирать данные по этому поводу (и персональные ученики в виде собственных детей и племянников хоть какие-то основы, но поняли). Но вопрос задам — может, у них таки проблемы с основами, и надо было погонять начиная с систем счисления и булевых операций?
Или ты опять имел в виду одно, а выразился про другое? Например, фокусы с предрассчитанными таблицами это приём, который надо не просто знать — надо тренироваться или в ТРИЗ/etc., или в практике именно такого кодинга.

N>>Я уже так давно не работал с SIP, что не могу понять, это в мой огород камень или нет. Но длинных цепочек ifʼов в своём коде я что-то не помню.


V>Если "раскрыть все скобки" (сделать все ф-ии инлайными в том коде), то будет просто масса ветвлений и всё.


Вот опять — какой "тот" код?

V>Собсно, я еще тогда подробно объяснял этот фатальный недостаток SIP — это отсутствие встроенных ср-в комбинирования сценариев. Любая комбинация сценариев должна быть прописана в очередном расширении стандарта. Вот что я называю каменным веком. Протокол SIP был разработан, очевидно, потребителями технологий, а не производителями. Они взяли RTP, который был до них, они взяли TCP и сделали самую большую каку в истории VoIP. Более непоследовательного, непродуманного, ограниченного в развитии и т.д. до бесконечности протокола — просто не существует.


SIP придуман несколькими фирмами — производителями VoIP. Или ты думаешь, что внутри этих фирм им занялись совершенно не те люди?
Протокол местами чудовищно сложен, это факт. Я, пока работал вокруг него, так и не довёл до ума некоторые вроде бы базовые вещи. Банально не хватило времени и терпения, хотя планы были. Мне больше всего не нравится именно взаимовлияние FSM диалога и сессии. А что со сценариями, хоть один пример?

V>Мне SIP напоминает творчество тех самых админов Linux, где половина программы у них живет в конфиге, ы-ы-ы.


Вроде на sendmail не похоже

V>Одно плохо — придумать правильный формат конфига тоже моск нужен, а его при разработке SIP-а ни у кого не оказалось. ))

V>В общем, SIP был разработан админами, а не программистами, сие слишком очевидно.
V>Причем, очень и очень узкоспециализированным админами.
V>Поэтому, имеем что имеем.

SIP был разработан под эгидой IETF. Это видно, например, по чрезмерной грамматичности. Но признаков участия именно админов я там не вижу.
The God is real, unless declared integer.
Re[33]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 09.06.17 09:38
Оценка:
Здравствуйте, netch80, Вы писали:

N>Это дорогая операция; возможно, у тебя аналогично она делается в свободное время, или используется готовая таблица обратных чисел.


Чем медленнее вращается деталь, тем меньший step нужен, т.е. наоборот — надо умножать step на мгновенную угловую скорость.
Сама мгновенная скорость отслеживается через фазовую автоподстройку — а там только операции прибавить/отнять.


N>Особой ценности в выводе двух сигналов одновременно я не вижу, но предположим, что для какой-то аппаратуры это важно.


Ценность в том, что ты обслуживаешь процессы не последовательно, а параллельно. Пусть будет не 2, пусть будет 3 счётчика или больше.
В любом случае, доступ к ногам микросхемы осуществляется "за раз" — байтом, полусловом, словом. Т.е. у тебя есть принципиальная возможность в одной команде поменять состояние сразу нескольких выходных ног микросхемы.


N>В этой схеме нет возможности подстроиться под внешние влияния на ходу.


Конечно, есть. Более того, только в этой схеме и есть, потому что смотри рядом обсуждение:
http://www.rsdn.org/forum/flame.comp/6804012.1

Если ты работаешь по прерываниям, то у тебя будет запаздывание аж на целый раунд, т.е. не так-то просто будет оперативно осуществлять фазовую автоподстройку.

Просто, если у нас идёт управление, например, фрезерным станком, то там вообще ничего обсуждаемого не надо, бо по координатам Х и Y можно вычислять сигналы независимо и не торопясь, а потом подавать их одновременно, а потом вообще можно пойти чайку попить (по процессорному масштабу времени).

А если у нас происходит что-то вроде этого:
https://www.youtube.com/watch?v=h5KrxyyTKdw

То я показываю, как это надо примерно делать, чтобы получать нужную точность обработки на приемлемой скорости вращения детали.

=======
(на остальное позже)
Re[23]: Эльбрус - 8 ядер
От: vdimas Россия  
Дата: 09.06.17 11:07
Оценка:
Здравствуйте, gardener, Вы писали:

V>>Пусть будет BCM4360.

V>>Или этот: http://www.cypress.com/file/298076/download
V>>Или: http://www.cypress.com/file/298016/download
V>>Для нашего обсуждения там, считай, идентичная архитектура.
G>Они прилично внутри отличаются.

Даташиты зато почти слово-в-слово.
И вообще, у Broadcom на удивление поганые даташиты с минимум инфы.
Прям, трясучка какая-то за свою интеллектуал проперти. ))
Аж неприятно читать...


V>>В даташитах есть некий микропрограммируемый модуль PSM.

V>>Твои комментарии?
G>Там никаких VLIW в помине нет.

VLIW — это по определению когда в одной команде управляют более чем одним устройством. Достаточно двумя.
Там даже из скудного описания складывается впечатление, что оно так и есть.


G>Они его используют насколько я понимаю по историческим причинам. Например где я сейчас работаю маппинг функций на железо не абсолютно такой же, но похож, и мы это делаем обычным RISC небольшим процессором.


Каким именно?


V>>На управляющий ARM или на упомянутый процессорный модуль?

G>Для АРМа.

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


G>Но при этом доступ к исходникам этого PSM у меня был, и я туда периодически заглядывал, хотя и не коммитил. Туда вообще мало кто коммитит, там небольшая группа. Не то чтобы что-то сложное, просто там небольшой набор функциональности.


Для VLIW и не нужен большой.



V>>Еще вопрос — зачем они лицензировали CEVA-XC архитектуру?

V>>Неужели лицензировали, но не используют?
G>Без понятия. Это именно WiFi business unit?

Ну да. Они же не только полудохлые чипы для ноутов/смартфонов делают, но и вполне производительные точки доступа "enterprise-level".
Re[3]: Эльбрус - 8 ядер
От: Dair Россия https://dair.spb.ru
Дата: 09.06.17 19:54
Оценка:
Здравствуйте, Stanislaw K, Вы писали:

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

SK>и лампочки отображающей состояние...

SK>Годная идея для стартапа, если бы не требовалась поддержка со стороны ОС.


Написать драйвер такой кнопки не так уж сложно.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.