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

S>Приветствую, A13x, вы писали:
...
S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?

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

Приветствую, A13x, вы писали:

A> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A> да. И, соответственно, используется код, написанный с учетом расширений этого процессора.

Можно и так, но это более трудоемкий процесс, хотя и результатов имхо принесет больше.

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

A>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>> объясни разницу применительно к "в 21 веке компилируют в код i386"?
S>Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?
нет, я хочу знать, каким образом это убережёт бинарик от наличия кода более соврененных cpu чем i386
кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?

A>> все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.
S>Постой ка, назови остальные "болееменее серьезные".
да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.

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

A>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>> да. И, соответственно, используется код, написанный с учетом расширений этого процессора.
S>Можно и так, но это более трудоемкий процесс, хотя и результатов имхо принесет больше.
чем это он трудоёмкий?
добавить

if (cpuid(1).edx & (1<<26)) {
  idct_sse2(...);
} else {
  idct_i386(...);
}

сложно?

Приветствую, Antikrot, вы писали:


A> чем это он трудоёмкий?
A> добавить
A>

A> if (cpuid(1).edx & (1<<26)) {
A>   idct_sse2(...);
A> } else {
A>   idct_i386(...);
A> }
A>

A> сложно?

Сложнее, чем просто idct(...);

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

S>Приветствую, Antikrot, вы писали:


A>> чем это он трудоёмкий?
A>> добавить
A>>

A>> if (cpuid(1).edx & (1<<26)) {
A>>   idct_sse2(...);
A>> } else {
A>>   idct_i386(...);
A>> }
A>>

A>> сложно?

S>Сложнее, чем просто idct(...);

Шеридан, побойся Сираусирупа! Это же C++! Это все легко, реализуемо и легко реализуемо!

Приветствую, Mamut, вы писали:

M> Шеридан, побойся Сираусирупа! Это же C++! Это все легко, реализуемо и легко реализуемо!
Мамут, я поражаюсь твоей способности выдергивать из контекста только то, что тебе полезно...

M>> Шеридан, побойся Сираусирупа! Это же C++! Это все легко, реализуемо и легко реализуемо!
S>Мамут, я поражаюсь твоей способности выдергивать из контекста только то, что тебе полезно...

Я специально отметил это злостным оффтопом и смайликом.

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

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

A>>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>>> объясни разницу применительно к "в 21 веке компилируют в код i386"?
S>>Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?
A>нет, я хочу знать, каким образом это убережёт бинарик от наличия кода более соврененных cpu чем i386
A>кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?

Я уверен. У него можно просмотреть исходники и увидеть, что cpuid проверяется только для детекта, что же такое на самом деле -march=native или -mtune=native. В результирующий код cpuid не поступает в принципе.

A>>> все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.
S>>Постой ка, назови остальные "болееменее серьезные".
A>да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.

Назови свой кодек, будет понятнее.

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

A>>>> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A>>>> объясни разницу применительно к "в 21 веке компилируют в код i386"?
S>>>Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?
A>>нет, я хочу знать, каким образом это убережёт бинарик от наличия кода более соврененных cpu чем i386
A>>кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?
N>Я уверен. У него можно просмотреть исходники и увидеть, что cpuid проверяется только для детекта, что же такое на самом деле -march=native или -mtune=native. В результирующий код cpuid не поступает в принципе.
это ж не к тебе вопрос был это мягкий намёк на то, что 95% фанатов source-based в эти сорцы не полезут вообще, а из оставшихся — 95% всё равно не будут знать во что их превратил компилятор.

S>>>Постой ка, назови остальные "болееменее серьезные".
A>>да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.
N>Назови свой кодек, будет понятнее.
да я хз. но если в media player classic убрать галочку h264/avc(dxva), жрёт в 7 раз больше cpu.

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

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

A>>>кроме того — а ты вот уверен, что у тебя gcc при -march=... не генерит кода с рантайм-проверкой наличия расширений?
N>>Я уверен. У него можно просмотреть исходники и увидеть, что cpuid проверяется только для детекта, что же такое на самом деле -march=native или -mtune=native. В результирующий код cpuid не поступает в принципе.
A>это ж не к тебе вопрос был :) это мягкий намёк на то, что 95% фанатов source-based в эти сорцы не полезут вообще, а из оставшихся — 95% всё равно не будут знать во что их превратил компилятор.

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

С другой стороны, обычно для тех же ~95% фанатов source-based оказывается, что ускорение от пересборки — это чистое плацебо. Потому что собирают не то, что нужно.
Шеридан, кажется, этому тоже частично подвластен, но он хоть наполовину честен:)

S>>>>Постой ка, назови остальные "болееменее серьезные".
A>>>да любой видеокодек возьми. не знаю чем ты пользуешься, но у меня видео ускоряется на gpu. если недостаточно серьёзно, возьми что-нибудь адобовское.
N>>Назови свой кодек, будет понятнее.
A>да я хз. но если в media player classic убрать галочку h264/avc(dxva), жрёт в 7 раз больше cpu.

Понятно. Сраанил бы на чём-то вроде mplayer, которому можно внутрь заглянуть...

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


N>Когда процессор серии x86, исполняя код BIOS, переводит его во внутренний микрокод и только затем его исполняет — у тебя есть чёткое различие между firmware и микропрограммой.

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

N>Даже если тебе это несущественно, то остальных будешь систематически сбивать с толку.

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

N>Полностью аппаратных декодеров — да, не бывает.
N>Но поддержка под конкретные кодеки может быть настолько существенной, что без неё работы не будет. Сравни скорость обработки AES на сверхновых x86 с соответствующими командами и без них. И это всего лишь несколько команд. Железной структурой можно достичь большего.
N>И это как раз то, что не может быть взято из разработок позавчерашнего дня, ибо они совсем другие.

Ты реально смотрел состав обсуждаемого SoC, или мы на отвлеченные темы будем разговаривать? Я все равно не поверю, что под некий SoC для бытовой аппаратуры кто-то будет изобретать новые ядра. Ну нереально это — никогда не окупиться. И не смеши ты "железной структурой", пожалуйста, а посмотри бы устройство современных DSP, даже позавчерашнего дня. Уж чего-чего, а вычислительных блоков там хватает с головой.


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

Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.

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

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


N>>Когда процессор серии x86, исполняя код BIOS, переводит его во внутренний микрокод и только затем его исполняет — у тебя есть чёткое различие между firmware и микропрограммой.
V>Во-первых, эти два термина идентичны.

Своим "во-первых" ты тут же постановил "есть два мнения — одно моё, другое неправильное". Зачем тогда вообще о чём-то говорить? Нарисуй себе сайт и выкладывай на нём:)
А если хочешь хоть немного послушать других — попробуй ответить на вопросы:
* BIOS это firmware или нет? (если нет — прошу доказать)
* если firmware исполняется в процессоре как входной язык — как называется то, что внутри?
* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?

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

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

N>>Даже если тебе это несущественно, то остальных будешь систематически сбивать с толку.
V>Вот и не сбивай с толку упоминаниями об архитектурах процессоров 20-тилетней давности. :)
V>Тем более, что это "четкое различие" — полная ерунда с т.з. принципов исполнения,

Оно не ерунда. Оно отделяет входной язык процессора от внутреннего языка. Если это для тебя "ерунда" — то зачем вообще процессоры нужны?

N>>Полностью аппаратных декодеров — да, не бывает.
N>>Но поддержка под конкретные кодеки может быть настолько существенной, что без неё работы не будет. Сравни скорость обработки AES на сверхновых x86 с соответствующими командами и без них. И это всего лишь несколько команд. Железной структурой можно достичь большего.
N>>И это как раз то, что не может быть взято из разработок позавчерашнего дня, ибо они совсем другие.
V>Ты реально смотрел состав обсуждаемого SoC, или мы на отвлеченные темы будем разговаривать?

Тред давно ушёл от конкретного обсуждаемого SoC и успел проехаться по всем ним. А начался вообще с Itanium, который является SoC только в страшном сне AMD.

V> Я все равно не поверю, что под некий SoC для бытовой аппаратуры кто-то будет изобретать новые ядра. Ну нереально это — никогда не окупиться. И не смеши ты "железной структурой", пожалуйста, а посмотри бы устройство современных DSP, даже позавчерашнего дня. Уж чего-чего, а вычислительных блоков там хватает с головой.

То есть ситуацию развития DSP иначе как механическим склеиванием ты вообще не предполагаешь?;) Кстати, ограничение тематики именно DSP — опять же от тебя. Тред обсуждал проблему в общем, и DSP, криптография и векторная алгебра здесь частные случаи. Кстати, конкретно меня сейчас DSP вообще не интересует, а вот нужны таймеры типа "зафиксировать значения внутреннего счётчика времени в моменты прихода фронтов по внешней линии, помнить 4 последних значения". Каким DSP я это могу реализовать и накойхер так извращаться?

N>>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.
V>Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.

Если принять твою точку зрения и взглянуть на стоимость разработки, например, Core i7 линии — по твоей логике Intel давно должен был разогнать команду разработчиков, ибо не окупается.

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


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

N>Кажется, словосочетание "выделенный поток", которое ты тут опровергаешь, появилось именно в твоей реплике. Я такого не называл и даже не подразумевал. Как я могу это воспринять иначе, чем дискуссионный приём выдвинуть возражение и тут же его разгромить с блеском?

Давай мы не будем на этом уровне обсуждать. Довольно подробно архитектура современного интелла расписана и источники открыты. Того единого потока исполнения микрокода, как некоей внутренней "подпрограммы" (чтобы ее именно можно было считать за полноценную микропрограмму, которая была там до пентиума), давно уже нет. Еще раз русским по белому: единый некогда автомат, построенный на микропрограммной технологии, исполняющий входные инструкции, был давно уже усложнен и разобран на составляющие автоматы, 90% которых выполнены именно в классическом железе, т.е. логикой этих автоматов управляет не микропрограмма, а функциональная схема из вентилей. И слово "единого" я добавил не зря, чтобы отсечь спекуляции. Даже если оставшиеся несколько этих частей работают под микропрограммным управлением, совершенно нельзя уже говорить, что входные инструкции выполняет микропрограмма, ибо доля микропрограммы в общем объеме работ исполнения очень мала. Единственно что правда — что в отличие от RISC входные инструкции не управляют блоками процессора напрямую, а предварительно транслируются. Но вот транслируются ли они исключительно микропрограммой — большой вопрос.

В общем, хочешь всерьез — будем всерьез, будешь на уровне "а вот у них я слышал" — ну так на уровне слухов и останемся.

N>Оно не ерунда. Оно отделяет входной язык процессора от внутреннего языка. Если это для тебя "ерунда" — то зачем вообще процессоры нужны?

Ерунда, и пример тому — Трансмета. И вопрос твой неудачен, процессоры нужны чтобы предоставлять вычислительные ресурсы, т.е. к обсуждаемому не относится. И на сегодня наилучшее соотношение в координатах потребление/кол-во_транзисторов/вычислительная_мощность дают многоядерные процы на "языках" довольно высокого уровня, типа Forth. И да, они микропрограммные. О чем и речь, собсно. Еще раз хочешь спросить, для чего процы нужны?


N>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?

А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. У Интела "прошивка" однократная, у тех настраиваемая. А мы вот для своих устройств брали микроконтроллеры с возможностью однократного программирования, ибо дешевле... Наверно нам тоже стоило избегать термина "firmware"?
Неудача трансметы лишь в том, что они эмулируют конкретно x86 — а это не самый удобный набор команд. И даже в этом случае они демонстрируют неплохие показатели по потреблению. Тем не менее, для трансметы существуют наборы команд, которые дают прирост производительности в 5-10 раз в сравнении с эмуляцией x86.

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


N>Тред давно ушёл от конкретного обсуждаемого SoC и успел проехаться по всем ним. А начался вообще с Itanium, который является SoC только в страшном сне AMD.

Так ты встрял, чтобы вернуть нас к первоначальной теме?


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

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

И при чем тут упомянутое тобой устройство ввода/вывода, когда обсуждение шло насчет того, насколько исполнение кодека H.264 является по своей природе "железячным" в конкретном плеере?

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


N>>>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.
V>>Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.

N>Если принять твою точку зрения и взглянуть на стоимость разработки, например, Core i7 линии — по твоей логике Intel давно должен был разогнать команду разработчиков, ибо не окупается.

Мде, приплызд...
Во-первых, Core i7 построено на выч. блоках от Core2 Duo, просто их теперь больше напихали. Во-вторых, сравнивать кол-во продаж процов Интелла и кол-во продаж этого медиадекодера даже не смешно. В третьих, tool-chain нужен для разработки ПО, для x86 эти tool chain копились 4 десятка лет, и они по факту уже есть. Ну и наконец, у Интелла фактический коллапс идей. Давно уже нет такого развития архитектуры ядер их процессоров, который они демонстрировали до этого. Начиная с 2003-го года все изменения в ядрах, за исключением внедрения гипертрединга, носили исключительно косметический характер. Никогда еще Интелл не задерживалась так долго с выпуском принципиально новых архитектур. Насколько мощные были переходы x86->x286->x386->x486->Pentium->P2->P3->P4, настолько же выпуск i7/i9 является пшиком и фактической росписью в беспомощности. И вот при своем уровне продаж Интелл не изобретает принципиально новые ядра, не поднимает частоту, а уплотняет на одном кристалле старые. И ты хочешь сказать, что некая noname будет разрабатывать свой SoC с совершенно уникальными ядрами собственной разработки? Окстись!

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

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

N>>Кажется, словосочетание "выделенный поток", которое ты тут опровергаешь, появилось именно в твоей реплике. Я такого не называл и даже не подразумевал. Как я могу это воспринять иначе, чем дискуссионный приём выдвинуть возражение и тут же его разгромить с блеском?

V>Давай мы не будем на этом уровне обсуждать. Довольно подробно архитектура современного интелла расписана и источники открыты. Того единого потока исполнения микрокода, как некоей внутренней "подпрограммы" (чтобы ее именно можно было считать за полноценную микропрограмму, которая была там до пентиума), давно уже нет.

А меня и не интересует "единый поток". Понятно, что коренное отличие (как минимум одно из;)) нынешней архитектуры от этак PDP-11/60 — отказ от строго последовательного исполнения и замена этого на свободные связи и зависимости. Но если понять, что и там и тут внешний код переводится во внутренний и исполняется уже внутренний — фатальной разницы не возникает.

Кстати, ты опять ушёл от вопроса, при чём тут firmware. Даже если мы согласимся с тем, что эти микропрограммы — это не микропрограммы, а на самом деле это другие микропрограммы;)) — всё равно не видно смысла принудительно отождествлять разные термины.

V> Единственно что правда — что в отличие от RISC входные инструкции не управляют блоками процессора напрямую, а предварительно транслируются. Но вот транслируются ли они исключительно микропрограммой — большой вопрос.

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

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

Где слухи-то?

N>>Оно не ерунда. Оно отделяет входной язык процессора от внутреннего языка. Если это для тебя "ерунда" — то зачем вообще процессоры нужны?

V>Ерунда, и пример тому — Трансмета. И вопрос твой неудачен, процессоры нужны чтобы предоставлять вычислительные ресурсы, т.е. к обсуждаемому не относится. И на сегодня наилучшее соотношение в координатах потребление/кол-во_транзисторов/вычислительная_мощность дают многоядерные процы на "языках" довольно высокого уровня, типа Forth. И да, они микропрограммные. О чем и речь, собсно. Еще раз хочешь спросить, для чего процы нужны?

Forth — это крайне низкий уровень. Я бы понял, если бы ты Smalltalk вспомнил... но не этот портабельный ассемблер-переросток. (Disclaimer: я люблю Форт, но реальная ниша у него — именно такая)

А про Transmeta — а почему у них не было выхода на исполнение других архитектур?

N>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. :xz: У Интела "прошивка" однократная, у тех настраиваемая.

У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)

V> А мы вот для своих устройств брали микроконтроллеры с возможностью однократного программирования, ибо дешевле... Наверно нам тоже стоило избегать термина "firmware"? :)))
V>Неудача трансметы лишь в том, что они эмулируют конкретно x86 — а это не самый удобный набор команд. И даже в этом случае они демонстрируют неплохие показатели по потреблению. Тем не менее, для трансметы существуют наборы команд, которые дают прирост производительности в 5-10 раз в сравнении с эмуляцией x86.

Ну и где выход на рынок с каким-то реальным предложением? Ладно, x86 не любят — оно действительно слишком неровное. Ну а MIPS? S/390? Sparc?
Боюсь, что у Transmeta проблема где-то в консерватории.

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

Ну ты загнул (tm)

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

Хорошо, предложи альтернативу. Какие реально пути есть? VLIW не предлагать. Нужно что-то такое, чтобы и современные требования нормально обеспечивало (включая тотальный реордеринг), и при этом с ним работать было можно, и чтобы компиляторы были в состоянии для них код сделать не решая каждую секунду 500 NP-полных задач... А я посмотрю, в какие ловушки ты попадёшь.

N>>Тред давно ушёл от конкретного обсуждаемого SoC и успел проехаться по всем ним. А начался вообще с Itanium, который является SoC только в страшном сне AMD.
V>Так ты встрял, чтобы вернуть нас к первоначальной теме? :)

Да нет, поговорить захотелось.:))

N>>То есть ситуацию развития DSP иначе как механическим склеиванием ты вообще не предполагаешь?;) Кстати, ограничение тематики именно DSP — опять же от тебя. Тред обсуждал проблему в общем, и DSP, криптография и векторная алгебра здесь частные случаи. Кстати, конкретно меня сейчас DSP вообще не интересует, а вот нужны таймеры типа "зафиксировать значения внутреннего счётчика времени в моменты прихода фронтов по внешней линии, помнить 4 последних значения". Каким DSP я это могу реализовать и накойхер так извращаться?
V>То, что ты говоришь — это устройства ввода/вывода, и так умели еще самые первые таймеры.

Самые первые умели тень от солнца показать. "Что сказать-то хотел?", повторяя твой же вопрос. И сейчас для таймеров именно такая функциональность — без помощи процессора зафиксировать моменты фронта — ой нетипична и требует целевой разработки (да, на уровне переместить пару блоков мышкой и сказать export to VHDL).

V> Что сказать-то хотел? В некоторых DSP тоже есть таймеры, только регистры ввода-вывода не совсем к DSP относятся, если не сказать больше. Да, практически в каждом уважающем себя микроконтроллере есть таймер (чем микроконтроллер от микропроцессора отличается, надеюсь понимаешь?)

Понимаю. А ты понимаешь, чем отличается описанный мной таймер от тупого счётчика, который в лучшем случае умеет выдавать чего-то на внутреннюю линию при переходе через 0?

V>И при чем тут упомянутое тобой устройство ввода/вывода, когда обсуждение шло насчет того, насколько исполнение кодека H.264 является по своей природе "железячным" в конкретном плеере? :xz:

Тред в целом не был посвящён исполнению H.264 и данная частная тема мне неинтересна. Если же ты имеешь в виду то письмо, на которое я отвечал в начале своего "вмешательства", то у меня просто нет готовых примеров под рукой. Но не надо быть колючим млекопитающим, чтобы понять, что 1) работа с видео уже настолько не-DSP'шная задача, что нехорошо называть его реализацию словом DSP, 2) оптимизации именно под конкретный алгоритм могут быть важнее, чем количество странных функций ЦАП.

V>Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер.

Мне??? ;) Я и не претендую на потребность в DSP.

N>>>>А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.
V>>>Именно что склеивать можно дешево, а разрабатывать эти блоки и tool chain к ним — на многие порядки дороже.
N>>Если принять твою точку зрения и взглянуть на стоимость разработки, например, Core i7 линии — по твоей логике Intel давно должен был разогнать команду разработчиков, ибо не окупается.
V>Мде, приплызд...
V>Во-первых, Core i7 построено на выч. блоках от Core2 Duo, просто их теперь больше напихали. Во-вторых, сравнивать кол-во продаж процов Интелла и кол-во продаж этого медиадекодера даже не смешно. В третьих, tool-chain нужен для разработки ПО, для x86 эти tool chain копились 4 десятка лет, и они по факту уже есть. Ну и наконец, у Интелла фактический коллапс идей. Давно уже нет такого развития архитектуры ядер их процессоров, который они демонстрировали до этого. Начиная с 2003-го года все изменения в ядрах, за исключением внедрения гипертрединга, носили исключительно косметический характер. Никогда еще Интелл не задерживалась так долго с выпуском принципиально новых архитектур. Насколько мощные были переходы x86->x286->x386->x486->Pentium->P2->P3->P4, настолько же выпуск i7/i9 является пшиком и фактической росписью в беспомощности. И вот при своем уровне продаж Интелл не изобретает принципиально новые ядра, не поднимает частоту, а уплотняет на одном кристалле старые. И ты хочешь сказать, что некая noname будет разрабатывать свой SoC с совершенно уникальными ядрами собственной разработки? Окстись! :)

По-моему, кститься надо кому-то другому. Потому что против такой чудовищной смеси правды с бредом и смешения совершенно разноуровневых вещей в одной каше, кажется, действительно поможет только божественное вмешательство.
По деталям.
1. Я не отделял разработку того же Corei7 от предыдущих этапов. Извини, если это не видно чётко из текста. На сейчас он последний из активно видного, именно поэтому взят как пример.
2. Развитие безусловно есть: появляются новые общие принципы (такие, как прямое управление шиной, размещение ядра видеоадаптера в центральном процессоре), новые группы команд, происходят реформы внутренней структуры.
3. Про коллапс идей — вот тут, считаю, тебе полностью отказало критическое мышление и мы имеем в лучшем случае приступ брюзжания. Идеи не обязаны проявляться в виде "весь мир насилья мы разроем, а затем...", как это было в случае ходячего кошмара под названием P4. Даже при "простом" увеличении количества ядер есть чего решать (а особенности i7 & etc. далеко не только в этом). Далее, даже в последовательности шагов ты ошибся: называя Pentium, а затем P2, ты почему-то забыл про PPro, в котором произошла самая кардинальная революция всей линии и по сравнению с которым P2 — попсовый кастрат.

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

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


N>А меня и не интересует "единый поток". Понятно, что коренное отличие (как минимум одно из) нынешней архитектуры от этак PDP-11/60 — отказ от строго последовательного исполнения и замена этого на свободные связи и зависимости. Но если понять, что и там и тут внешний код переводится во внутренний и исполняется уже внутренний — фатальной разницы не возникает.

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


V>> Единственно что правда — что в отличие от RISC входные инструкции не управляют блоками процессора напрямую, а предварительно транслируются. Но вот транслируются ли они исключительно микропрограммой — большой вопрос.

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

Мда... терпение и еще раз терпение... Нет, все-таки надо отослать. Гуглить по микропрограммный автомат. Все-таки, когда общался с коллегой, предполагал что мне нет нужды тут подробностями за 4-й курс обучения засорять пост. Конечно эмуляция — это тормоза, но с чего ты решил, что я это имелл виду. Я же ссылался на классику уже.

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

N>Где слухи-то?

Ну, всегда считалось, что процессоры интелл построены по классической микропрограммной технологии, и до пентиума это так и было. Понимаешь, микропрограмма — она разработана человеком и зашита в ПЗУ, либо в еще какие регистры памяти, и представляет из себя просто список ответов на все вопросы цифровой ф-ии f(x), где x — мн-во всех допустимых входных сигналов + кодированного состояния самого автомата, составляющих адресное пространство этого ПЗУ. О какой нафиг эмуляции тут вообще можно было говорить? Это или нубство, или попытка приписать оное оппоненту. Выходом ф-ии является след. состояние автомата + выходные целевые сигналы, управляющие исполнительными устройствами (другими автоматами/схемами). Ну как можно было выделить лишь эти выходные сигналы, управляющие исполнительными блоками (т.е. то, во что именно транслируются входные опкоды), и обозвать их микропрограммой?!! Это — лишь часть пространства выходных сигналов автомата с микропрограммным управлением. Или же, из клиссического определения функционального преобразователя с памятью — просто мн-во выходных сигналов. Но это, блин, никакая не микропрограмма.

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

N>Forth — это крайне низкий уровень. Я бы понял, если бы ты Smalltalk вспомнил... но не этот портабельный ассемблер-переросток. (Disclaimer: я люблю Форт, но реальная ниша у него — именно такая)

Forth, вернее та его часть, которая делается "в железе" — это язык уровня байткодов Java/Net. Очень неплохой уровень в сравнении с x86. И я плохо представляю себе реализацию small talk процессора, так же как и любого другого языка действительно выского уровня, ввиду того, что размеры данных (объектов) могут быть произвольны, и для них банально может не хватить места в памяти проца. Т.е. поин в том, что такая микропрограмма должна выходиь за рамки ресурсов процессора и работать как обычная прогамма, общаясь с окружающей системой. Для сравенения, все данные, которыми оперирует Forth-процессор, являются для него примитивами, которые он может прочитать или записать за раз.

N>А про Transmeta — а почему у них не было выхода на исполнение других архитектур?

Как это не было?

N>>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. У Интела "прошивка" однократная, у тех настраиваемая.

N>У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)

Тогда с чего ты решил, что избегают этого термина?

V>> А мы вот для своих устройств брали микроконтроллеры с возможностью однократного программирования, ибо дешевле... Наверно нам тоже стоило избегать термина "firmware"?
V>>Неудача трансметы лишь в том, что они эмулируют конкретно x86 — а это не самый удобный набор команд. И даже в этом случае они демонстрируют неплохие показатели по потреблению. Тем не менее, для трансметы существуют наборы команд, которые дают прирост производительности в 5-10 раз в сравнении с эмуляцией x86.

N>Ну и где выход на рынок с каким-то реальным предложением? Ладно, x86 не любят — оно действительно слишком неровное. Ну а MIPS? S/390? Sparc?
N>Боюсь, что у Transmeta проблема где-то в консерватории.

На момент выхода трансметы рынок MIPS был смешон, Sparc — тем более, а инвестиции были нехилые и амбиции соответствующие. Это сейчас, когда поперло все мобильное, возможно попытаются что-то сделать в другом направлении. К тому же за эти годы тот же Линукс распространился на невероятное кол-во платформ, что можно даже предположить сценарий, когда впору сделать уникальный набор команд, выжимающий всю мощь из этого кристалла, и это решение не будет выглядеть как утопия. Посмотрим.


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

N>Хорошо, предложи альтернативу. Какие реально пути есть? VLIW не предлагать. Нужно что-то такое, чтобы и современные требования нормально обеспечивало (включая тотальный реордеринг), и при этом с ним работать было можно, и чтобы компиляторы были в состоянии для них код сделать не решая каждую секунду 500 NP-полных задач... А я посмотрю, в какие ловушки ты попадёшь.

Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор? ). Пусть один из регистров называется указателем стека или как угодно — не суть. Во-первых, очень мало опкодов (упрощается дешифратор), во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения. Но проблема, как обычно, не в железе. Не зря Power PC на той же частоте показывает гораздо большую вычислительную мощь, но их воз и ныне там. Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

N>Самые первые умели тень от солнца показать. "Что сказать-то хотел?", повторяя твой же вопрос. И сейчас для таймеров именно такая функциональность — без помощи процессора зафиксировать моменты фронта — ой нетипична и требует целевой разработки (да, на уровне переместить пару блоков мышкой и сказать export to VHDL).

Я не знаю, чего ты там двигаешь мышкой, но термином "таймер" называют целый класс цифровых схем со счетчиком, работу самой популярной из которых ты вполне четко описал. (не путать цифроаналоговым таймером, напр. 555)
Перефразирую твое: нужна схема со счетчиком, на которую подаются такты и сигналы stop/reset. Да, это именно одна из популярных схем таймера, широко использовалась для АЦП. Другая схема — обратная, есть счетчик, такты, ты выставляешь начальное значение, говоришь start, а счетчик считает до 0-ля. Небольшое усовершествование этой схемы, когда она сама себя перезапускает по достижению 0-ля — это классический делитель частоты на таймере. Программируемый таймер

Конкретно у тебя, насчет помнить последние 4 значения — это зависит от соотношения частот. Если процессор будет успевать по прерываниям забирать данные — пусть эти 4 значения хранятся программно. Если нет — сделай память на 4-х регистрах. Уж по 4 значения за раз процессор должен успевать забирать? Иначе схема не имеет смысла.

Вот наш аналог программируемого таймера, который всю жисть был в IBM PC и сейчас в чипсетах материнок его функциональность есть: http://elancev.narod.ru/texno/bi53/bi53.htm
Второй его режим — это твоя задача. К сожалению, конкретно в IBM PC он подключен не совсем удобно, но в свою схему можешь включить как пожелаешь.

V>> Что сказать-то хотел? В некоторых DSP тоже есть таймеры, только регистры ввода-вывода не совсем к DSP относятся, если не сказать больше. Да, практически в каждом уважающем себя микроконтроллере есть таймер (чем микроконтроллер от микропроцессора отличается, надеюсь понимаешь?)

N>Понимаю. А ты понимаешь, чем отличается описанный мной таймер от тупого счётчика, который в лучшем случае умеет выдавать чего-то на внутреннюю линию при переходе через 0?

Да, тем же, чем просто счетчик отличается от таймера.
Заканчивай уже на весь интернет-то...

N>Но не надо быть колючим млекопитающим, чтобы понять, что 1) работа с видео уже настолько не-DSP'шная задача, что нехорошо называть его реализацию словом DSP, 2) оптимизации именно под конкретный алгоритм могут быть важнее, чем количество странных функций ЦАП.

Ниче не понял.

V>>Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер.

N>Мне??? Я и не претендую на потребность в DSP.

Ну ты так вопрос поставил в пред. сообщении. DSP для таймера не нужен, зато дешево и эффективно на нем обсчитывать многочлены с плавающей запятой. Практически все популярные DSP имеют ф-ию суммировани многочлена, т.е. однотактную операцию вида sum = sum + a * b, а некоторые могут за этот же такт обсчитывать более одного sum, a и b. Т.е. вид параллельности в DSP обычно явный и жесткий, когда в одном опкоде зашито управление сразу несколькими вычислительными блоками, как в VLIW. Использовать же современные процы для этого — из пушки по воробьям, как по потреблению, так и по невостребованности всех их наворотов для однообразных вычислений в процессе работы кодека.


N>1. Я не отделял разработку того же Corei7 от предыдущих этапов. Извини, если это не видно чётко из текста. На сейчас он последний из активно видного, именно поэтому взят как пример.
N>2. Развитие безусловно есть: появляются новые общие принципы (такие, как прямое управление шиной, размещение ядра видеоадаптера в центральном процессоре), новые группы команд, происходят реформы внутренней структуры.
N>3. Про коллапс идей — вот тут, считаю, тебе полностью отказало критическое мышление и мы имеем в лучшем случае приступ брюзжания. Идеи не обязаны проявляться в виде "весь мир насилья мы разроем, а затем...", как это было в случае ходячего кошмара под названием P4. Даже при "простом" увеличении количества ядер есть чего решать (а особенности i7 & etc. далеко не только в этом). Далее, даже в последовательности шагов ты ошибся: называя Pentium, а затем P2, ты почему-то забыл про PPro, в котором произошла самая кардинальная революция всей линии и по сравнению с которым P2 — попсовый кастрат.

О да, я забыл по PPro, а так же про 8088/186/188.
Все равно не согласен, самая кардинальная революция — это 286-е, и отшлифованное оно же в 386-м. А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".


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

Тот факт, что я не разбил на абзацы, не говорит, что я смешал в кучу. По крайней мере отделил через "во-первых, во-вторых" и т.д., ибо ты очень много накидал чего до этого, на что можно было ответить. В любом случае, принципиально я прав, с 2003-го все улучшения лишь косметические, в сравнении с предыдущими поколениями. Я понимаю, что лично тебе эти улучшения интересны, я уже заметил за несколько лет, что ты тяготеешь почему-то именно к Интеллу. Но, чтобы не провозносить их выше некуда, можно было бы посмотреть на процессоры от AMD, подробнее на тот же IA64, на топовые процы от Sun, с большим кол-вом ядер и 4-хпотоковостью на ядро, и т.д. и т.п., и тогда иначе как косметическими изменения за последние 7 лет (!!!) назвать уже не получится.

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

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

N>На практике не сходится. Мы имеем или платформу x86-64, у которого пока что различия между платформами минимальны (и базовый объём того же SSE есть достаточный для большинства нынешних задач),

Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг.

N>У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся.

Для ядра — не будет. Но линух же не для самого себя нужен, правильно? Если ты, например, VoIP свитч поднимаешь на этом линухе, то разница скомпилированного свитча по эффективности раза в 2 будет, т.е. на одной и той же железке сможешь обслужить в 2 раза больше абонентов, если кодеки будут использовать SSE2 и выше, и свич выполняет согласование кодеков, то бишь банально раскодирует один и кодирует в другой.


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

Просто задачи разные бывают.

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

N>>На практике не сходится. Мы имеем или платформу x86-64, у которого пока что различия между платформами минимальны (и базовый объём того же SSE есть достаточный для большинства нынешних задач),
V>Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг.

Это про 64-битку? Я сейчас не могу найти, но мне казалось, что в ней SSE2 обязателен с рождения.

N>>У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся.
V>Для ядра — не будет. Но линух же не для самого себя нужен, правильно? Если ты, например, VoIP свитч поднимаешь на этом линухе, то разница скомпилированного свитча по эффективности раза в 2 будет, т.е. на одной и той же железке сможешь обслужить в 2 раза больше абонентов, если кодеки будут использовать SSE2 и выше, и свич выполняет согласование кодеков, то бишь банально раскодирует один и кодирует в другой.

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

N>>Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.
V>Просто задачи разные бывают.

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

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

V>>Недостаточен. Принципиальное отличие SSE2 от SSE в том, что 2-й может делать все те же операции что и первый, но уже с double. Ввиду этого, у нас все клиентское идет под SSE, ибо полно еще на ходу всяких Athlon 1.7-3.2ГГц, имеющих лишь SSE на борту, а серверное мы компилим под SSE3, ибо нефиг.

N>Это про 64-битку? Я сейчас не могу найти, но мне казалось, что в ней SSE2 обязателен с рождения.

В 64 бит да, но я не говорил именно про 64 бит.

N>>>У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся.
V>>Для ядра — не будет. Но линух же не для самого себя нужен, правильно? Если ты, например, VoIP свитч поднимаешь на этом линухе, то разница скомпилированного свитча по эффективности раза в 2 будет, т.е. на одной и той же железке сможешь обслужить в 2 раза больше абонентов, если кодеки будут использовать SSE2 и выше, и свич выполняет согласование кодеков, то бишь банально раскодирует один и кодирует в другой.

N>Вообще-то крайне мало случаев, когда компилятор способен получить такую эффективность из кода, написанного "вообще". Практически значимый случай — когда ускоренные версии пишутся на целевом ассемблере. А такое делать лучше с детектом в рантайме.

Я конкретно про SSE2 и выше, которые с double работают. Просто много кодеков используют double для приличной части вычислений.

N>>>Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.
V>>Просто задачи разные бывают.

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

Без коментариев... кодеки и так обычно вылизаны по самое нехочу. Речь, повторюсь, исключительно о бенефитах от SSE.

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

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

kig>Теоретически — да. Но на практике, например, на ЕС-1046 с 8 мгб, третий уровень работал сносно, четвертый изрядно тормозил, а пятый — еле двигался.

Вот мне интересно посмотреть на пятый уровень вложенности какого-нить VirtualPC.