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

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

Посмотри внимательно на мои слова, на которые ты отвечал — там именно 64 бит было. Ветку про 32 бита ты куда-то срезал.

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

Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?

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

Вот это и будет препятствовать умению компилятора впихнуть туда SSE.

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

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

К каким? Штриху Шеффера?;))

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

V>Мда... терпение и еще раз терпение... Нет, все-таки надо отослать. Гуглить по микропрограммный автомат.

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

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

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

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

Опаньки — и что поменялось? И при чём тут именно пентиум, когда он как раз очень мало изменений принёс? Конвейер появился ещё в 8086. Внутренний язык, переупорядочение команд, etc. — в PPro. Чем тебя так это несчастное разделение конвейеров заинтересовало, что ты считаешь его революцией, а остальное — нет?

V> Понимаешь, микропрограмма — она разработана человеком и зашита в ПЗУ, либо в еще какие регистры памяти, и представляет из себя просто список ответов на все вопросы цифровой ф-ии f(x), где x — мн-во всех допустимых входных сигналов + кодированного состояния самого автомата, составляющих адресное пространство этого ПЗУ.

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

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

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

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

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

Где реальный результат? Пошуметь любой может.

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

потому что у них "микрокод", а не firmware.

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

Чииво? Ты вообще на календарь смотрел? На момент выхода трансметы Sun фактически владел рынком больших серверов (с лёгкой поправкой на Tandem, S/390, AS/400 и прочие маргинальные для нас сущности). Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?;))

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

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

Да-да. И терять при этом в эффективности за счёт того, что данные вечно бегают из памяти в этот единственный аккумулятор и обратно. Спасибо, я под 6502 уже писал. Больше не хочу такого кошмара. Ты его имел в виду или ещё что-то более ужасное? Ностальгия по нулевой странице замучила? Почему-то сейчас идут другим путём — лучше больше регистров сделать, тогда легче выделять зависимости между явно разными данными и заодно дать помочь с этим программисту.

V> Пусть один из регистров называется указателем стека или как угодно — не суть. Во-первых, очень мало опкодов (упрощается дешифратор),

Дешифратор в цене современного процессора — это даже не копейки, это меньше.

V> во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения.

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

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

Ну да, в синтетических тестах. Мы тут сейчас запускаем кластер с Cell'ами. Так вот — никакому психу не приходит в голову на Cell'ах собирать программы для них же — собираются на x86 кросс-сборкой, потому что это работает в ~5 раз быстрее, чем сборка на месте. Вот потому их воз и ныне там.

V> Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

AMD смогла "подставить подножку" именно потому, что IA64 получился редким тормозом со своего начала. Несмотря на все свои спецмеры типа "снимем с процессора задачу умничать в исполнении команд".
Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

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

Ещё раз — какой из них позволяет запомнить несколько последних моментов фронта?
На один — я и так знаю, где это найти.

V>Конкретно у тебя, насчет помнить последние 4 значения — это зависит от соотношения частот. Если процессор будет успевать по прерываниям забирать данные

Нет, он не будет даже пытаться "успевать" забирать их — это не его задача.
Ты всё время стараешься мне подсовывать какие-то левые решения вместо прямого ответа. Я описал задачу. Она специфическая для нас, но реальная. Она не решается существующими средствами (вариант накоммутировать в FPGA я не рассматриваю). Её тривиально решить, сделав конвейер из 4-х регистров и счётчик вначале, но это надо спроектировать. Что тут непонятного и зачем ты вместо того, чтобы просто понять и осознать проблему, подсовываешь мне тысячу способов как извратиться, но не решить её?

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

Во-первых, в PC — i8254, а не i8253. Отличия мелкие, но существенные. Во-вторых, мне это нужно не ломая основной таймер (от которого ничего не осталось, кроме наследства в виде одного канала). Остальное я сказал выше. Перестань юлить.

V>Заканчивай уже на весь интернет-то...

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

V>>>Я ведь и сам не в курсе, нахрена вам DSP, когда нужен таймер.
N>>Мне??? ;) Я и не претендую на потребность в DSP.
V>Ну ты так вопрос поставил в пред. сообщении. DSP для таймера не нужен,

Не ставил я такого, читай заново.

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

"Кто бы спорил, я не буду". Для такой частной задачи — да.

V>О да, я забыл по PPro, а так же про 8088/186/188. :)

186 и близкие — неважны. А PPro — самая большая революция во всём ряду. Это не "забыл", это незнание.

V>Все равно не согласен, самая кардинальная революция — это 286-е, и отшлифованное оно же в 386-м.

Это что? Виртуальная память и слои защиты? Это не революция собственно внутренней архитектуры — и в 286 и в 386 они были пришлёпками сверху. Только в 486 они вошли нормально в структуру. А ты что, воспринимаешь именно такие революции внешнего облика? Ну так их скорее всего и не будет ещё лет 10. И что, это значит, развития нет?

V> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".

Ничего себе "частности", всё нутро поменялось до неузнаваемости.

V>Тот факт, что я не разбил на абзацы, не говорит, что я смешал в кучу. :)

Дело не в абзацах.

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

Нет.

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

Это ничего, что у меня с 96-го года дома только AMD? "тяготеешь к Интелу"... ещё одно высосанное даже не из пальца, а вообще не знаю из чего, слов нет.

V> подробнее на тот же IA64, на топовые процы от Sun, с большим кол-вом ядер и 4-хпотоковостью на ядро, и т.д. и т.п., и тогда иначе как косметическими изменения за последние 7 лет (!!!) назвать уже не получится.

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

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

За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.

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

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

Ну тогда стоит тебе пройтись еще раз тщательнее, ибо говоришь полную чушь.


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

N>У меня такого не было ни на каком курсе. Но дело не в этом (я знаю, что такое микропрограммный автомат, из других источников), а в том, что ты смешиваешь разные вещи в одно только из-за сходства названий.

Угу. Подробней, плиз.


V>> Понимаешь, микропрограмма — она разработана человеком и зашита в ПЗУ, либо в еще какие регистры памяти, и представляет из себя просто список ответов на все вопросы цифровой ф-ии f(x), где x — мн-во всех допустимых входных сигналов + кодированного состояния самого автомата, составляющих адресное пространство этого ПЗУ.

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

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

N>И даже если процессор является тем самым "микропрограммным автоматом" в целом (нонсенс), если у него этого нет — то и про микропрограммы не говорят.

Знаешь, можно на пальцах объяснить что к чему, но даже на пальцах это будет довольно длинный пост.



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

N>Да, мне действительно теперь понятно — что цепляясь за нелепый устарелый термин ты теряешь суть.

Я не цепляюсь, я разъясняю, что он означает.
Если ты сутью называешь свои абстракции, то я их теряю, разумеется, когда мы говорим о значении терминов. Чтобы не было разночтений. Ты понимаешь, чем отличается конвеер команд 8086 и современный конвеер? И интереса ради, какова разрядность современного внутреннего конвеера? И что именно в нем содержится? По сути, этот вопрос содержит ответ, и если найдешь ответ — вопросы отпадут.


N>Где реальный результат? Пошуметь любой может.

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

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

N>потому что у них "микрокод", а не firmware.

Ну а в ветке, куда ты подключился, было именно firware.
Понимаешь, в русской терминологии "микропрограмма" либо синоним термина "прошивка", либо применяется к содержимому ПЗУ в миропрограммных автоматах, даже если вместо ячеек памяти ПЗУ есть просто перемычки в кристалле к 0 или 1. По-сути, это одно и то же. Когда изобрели преобразование последовательности команд во внутренний RISC, эти RISC инструкции стали называть микрокодом. В нашей терминологии — это управляющие сигналы, т.е. те, которые непосредственно подаются на исполняющие блоки и не требуют дешифрации. Т.е. вот идет там, например, сотня разрядов, и эти разряды — просто "составленные рядом" коды команд управляющих устройств. Это именно то, что сейчас содержится в конвейере, в отличие от 8086. А вот порождаться этот код может микропрограммой, автоматом с микропрограммным управлением, как и было в 8086.

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


N>Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?)

Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.


V>>Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор? ).

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

Ниче не понял... Мы по RISC говорим, или CISC, с переупорядочиванием, переименованием и прочим одновременным исполнением независимых операций?

N>Спасибо, я под 6502 уже писал. Больше не хочу такого кошмара. Ты его имел в виду или ещё что-то более ужасное? Ностальгия по нулевой странице замучила? Почему-то сейчас идут другим путём — лучше больше регистров сделать, тогда легче выделять зависимости между явно разными данными и заодно дать помочь с этим программисту.

Именно что больше регистров. А сколько конкретно надо? Много сделаешь — много сохранять при переключении задач, и вот тут недавно воевали насчет использования файлов SSE в ядре ОС, вернее неиспользовании, чтобы не сохранять его. А сделаешь регистров мало — ты не доволен. Посмотрел бы на байт-код дотнета, хотя бы. Локальная стековая память, которая заведомо относится к одному текущему потоку — чем не файл регистров произвольно требуемого размера? Понимаешь, технология кэш-памяти постепенно стирает различия м/у файлом регистров и страницей памяти, отображенной в кэш.


V>> во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения.

N>Ну да, просто убивая возможность анализа на корню. Пусть компилятор думает, у него голова большая.

Надеюсь, теперь ты так не считаешь. Если не понимаешь, посмотри как работает JIT-компилятор дотнета. Он проще, чем декомпилятор x86-го, вот в чем прикол.


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

N>Ну да, в синтетических тестах. Мы тут сейчас запускаем кластер с Cell'ами. Так вот — никакому психу не приходит в голову на Cell'ах собирать программы для них же — собираются на x86 кросс-сборкой, потому что это работает в ~5 раз быстрее, чем сборка на месте. Вот потому их воз и ныне там.

Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм?
Дело, как обычно, в софте.

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


V>> Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

N>AMD смогла "подставить подножку" именно потому, что IA64 получился редким тормозом со своего начала.

Первый VLIW комом, зато Эльбрус получился, который Интелл купил.

N>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

Ну и почему? Разве не понятно?


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

N>Ещё раз — какой из них позволяет запомнить несколько последних моментов фронта?
N>На один — я и так знаю, где это найти.

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


N>Нет, он не будет даже пытаться "успевать" забирать их — это не его задача.
N>Ты всё время стараешься мне подсовывать какие-то левые решения вместо прямого ответа. Я описал задачу. Она специфическая для нас, но реальная. Она не решается существующими средствами (вариант накоммутировать в FPGA я не рассматриваю). Её тривиально решить, сделав конвейер из 4-х регистров и счётчик вначале, но это надо спроектировать. Что тут непонятного и зачем ты вместо того, чтобы просто понять и осознать проблему, подсовываешь мне тысячу способов как извратиться, но не решить её?

Э-э-э... Это ты сам с собой или как? В чем проблема? Это вообще задача не того уровня, чтобы на форуме обсуждать, и я вообще не понял, из чего был напор-то. Дал бы как ТЗ, я бы тебе функциональную схему за 10 секунд накидал бы. На 3-м курсе в течении одной лабораторки по схемотехнике студенты на стендах такие схемы по вариантам собирают, лабы оформляют и еще сдавать/защищать успевают. В чем проблема-то?

N>Во-первых, в PC — i8254, а не i8253. Отличия мелкие, но существенные. Во-вторых, мне это нужно не ломая основной таймер (от которого ничего не осталось, кроме наследства в виде одного канала). Остальное я сказал выше. Перестань юлить.

Юлить? Ню-ню. Если проблема действительно есть (хоть я ее и не пойму), ты это, в личку ТЗ скинь, мне ведь не сложно. А то ведь выясняется, то эти 4 значения процессору не нужны. А кому нужны? А как именно нужны, т.е. интерфейс забора этих 4-х значений какой? А частоты и прочие характеристики? Как я тебе дам готовое решение, если описанное тобою даже на черновик ТЗ не тянуло? И я еще и юлю? Нахал...

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

Это ты, типа, разработку вот своей фигни на одном счетчике и 4-х регистрах с DSP пытаешься сравнивать? А 4-5 порядков разницы в сложности — это типа мелочи? Слушай, нафига ты спор в фарс превращаешь?


V>> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".

N>Ничего себе "частности", всё нутро поменялось до неузнаваемости.

Да плевать. Ничего Интеллом в PPro не было изобретено такого, чего бы не было до этого. K5, Nx686 (он же К6 позже) раньше всех использовали идею внутреннего RISC для x86, которую реализовала и Интелл. То, что есть революция для Интелл, не обязательно даже новость для остального мира.


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

N>Нет.

Хоть одно не косметическое, влияющее на архитектуру ядра?

N>За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.

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

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

N>Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?
ICC

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

V>>> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".
N>>Ничего себе "частности", всё нутро поменялось до неузнаваемости.
V>Да плевать. Ничего Интеллом в PPro не было изобретено такого, чего бы не было до этого. K5, Nx686 (он же К6 позже) раньше всех использовали идею внутреннего RISC для x86, которую реализовала и Интелл. То, что есть революция для Интелл, не обязательно даже новость для остального мира. :)

Мы обсуждали важность реформ внутри модельного ряда x86, а не по сравнению с остальными. Ты подменяешь тему разговора.

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

Устранение северного моста и прямое управление памятью.
Внос видеоконтроллера в процессор (в моделях, где он есть).

N>>За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.
V>Во-первых, как это сломана? Если 64-битные винды спокойно напрямую запускают 32-битные приложения, а не в окне эмулятора, то для пользователя никакая совместимость не сломана.

Для такого исполнения совершенно не нужно идентичности системы команд. Гибриды x86+IA64 (Intel), x86+Alpha (неудавшиеся планы AMD) — не требуют совместимости системы команд: они могут быть абсолютно разные. А вот те же команды с точностью до бита ты уже не исполнишь так, чтобы оно незаметно из 32 стало 64-битным (disclaimer: в традиционном стиле; можно сделать такую систему команд, чтобы битность не влияла — но это не было сделано). Поэтому я и говорю — совместимость сломана. А раз сломана — не было никакой неизбежности в самой архитектуре продолжать систему команд x86, в 64 битах могли взять Sparc, Alpha, IA64, MIPS... Решали же из соображений удобства.

V>Во-вторых, почему не Интелл первая пошла на такой же шаг? Как и в случае "революционного" PPro — выступила в роли догоняющего.

Чтобы ответить на этот вопрос, надо знать, что происходило внутри Intel в районе 1999-2000. Может, на них лопнувший пузырь доткомов повлиял, может, ещё что-то, но они тогда выпустили как минимум два ужасных решения: Pentium4 и Itanium. P4, к счастью, сдох очень быстро. Itanium — судьба непонятна.

N>>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

V>Ну и почему? Разве не понятно?

Не-а. Объясни, пожалуйста, если знаешь. Действительно интересно.

V>>> Дело все в том же софте. И все эти Java/Net — на самом деле суть движение в правильном направлении. Когда-нибудь (надеюсь доживу) кол-во перерастет в кач-во, и можно будет торжественно похоронить x86(x64). Само смешное, что Интелл собиралась это сделать, насколько я понял, еще в этом десятилении, продвигая свой полу-VLIW IA64, да вот АМД подножку подставила.

N>>AMD смогла "подставить подножку" именно потому, что IA64 получился редким тормозом со своего начала.

V>Первый VLIW комом, зато Эльбрус получился, который Интелл купил.

Купил — и где? В архивы слито? (Я молчу, что Эльбрус был задолго до IA-64 и даже до HPPA)

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

V>Это ты, типа, разработку вот своей фигни на одном счетчике и 4-х регистрах с DSP пытаешься сравнивать? А 4-5 порядков разницы в сложности — это типа мелочи? Слушай, нафига ты спор в фарс превращаешь?

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

V>Юлить? :) Ню-ню. Если проблема действительно есть (хоть я ее и не пойму), ты это, в личку ТЗ скинь, мне ведь не сложно. А то ведь выясняется, то эти 4 значения процессору не нужны.

Не вижу никаких оснований в моих словах для такого вывода.

V> А кому нужны? А как именно нужны, т.е. интерфейс забора этих 4-х значений какой? А частоты и прочие характеристики? Как я тебе дам готовое решение, если описанное тобою даже на черновик ТЗ не тянуло? И я еще и юлю? Нахал...

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

N>>Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?;))
V>Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.

Спасибо, что хоть не повторяешь, что MIPS вымер. Уже прогресс.:)

V>>>Forth/Java/Net — байткоды куда как более приспособлены для анализа исполнительных ветвей, чем код x86-го. Да вообще любые системы команд, которые оперируют лишь парой регистров и аккумулятором (помнишь такой популярный некогда процессор? ;) ).

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

V>Ниче не понял... Мы по RISC говорим, или CISC, с переупорядочиванием, переименованием и прочим одновременным исполнением независимых операций?

Про RISC, про RISC. Ты в курсе скорости работы RAM по сравнению с процессором? Да, по сравнению с архитектурой стиля 6502 мы имеем регистровый файл как кэш нулевого уровня. И что в этом плохого? Не зря большинство архитектур сейчас целятся на 16-32 регистра, если не больше — потому что такой кэш как раз оптимален. А ты предлагаешь не то нулевую страницу применить, не то вообще неведомую шлёпанную херню. И нафига?

N>>Спасибо, я под 6502 уже писал. Больше не хочу такого кошмара. Ты его имел в виду или ещё что-то более ужасное? Ностальгия по нулевой странице замучила? Почему-то сейчас идут другим путём — лучше больше регистров сделать, тогда легче выделять зависимости между явно разными данными и заодно дать помочь с этим программисту.

V>Именно что больше регистров. А сколько конкретно надо? Много сделаешь — много сохранять при переключении задач, и вот тут недавно воевали насчет использования файлов SSE в ядре ОС, вернее неиспользовании, чтобы не сохранять его. А сделаешь регистров мало — ты не доволен. :)

Да, недоволен. Потому что оптимум для современных задач — в районе тех же 16-32 регистров. Вроде ближе пока к 16, но твёрдо не уверен — давно не смотрел тематику.
Сохранять при переключении задач? Да, сохранять. Но посмотри, например, на Sparc. Там этот вопрос решается достаточно гибко — если задача много не хочет, можно много и не сохранять. Кажется, можно на ходу менять пределы сохранения, но твёрдо не уверен. в IA64 другой подход, но тоже гибкий.

V> Посмотрел бы на байт-код дотнета, хотя бы. Локальная стековая память, которая заведомо относится к одному текущему потоку — чем не файл регистров произвольно требуемого размера? :xz: Понимаешь, технология кэш-памяти постепенно стирает различия м/у файлом регистров и страницей памяти, отображенной в кэш.

Плохой, негодный пример. Во-первых, компьютер — не среда дотнета: иногда стека вообще нет, иногда кэш может быть не включён. Во-вторых, ты не пробовал взять ручку и подсчитать регистры в минимальном варианте?
* два аккумулятора (ой только не надо 6502 вспоминать. два нужны хотя бы для операций умножения и деления)
* два индексных регистра (ты сам сказал про два)
* указатель стека
* указатель TLS (извините, такое на стеке не хранят)
* счётчик команд

Это жёсткий минимум. Ничего не напоминает? С минимальными поправками — мы получили 8086 (и вплоть до P4-не-64бит без FP/MMX/SSE).
Теперь расширим аккумулятор до хранения полного вектора данных в стиле SSE... ой, и что это у нас получилось? да x86 и получился.

А извратиться без регистров — можно даже вообще без единого: всё на стеке (ну, останутся IP, SP, FS). Только мы, кажется, про RISC говорили? Где ты вообще видел RISC с тремя операндами в памяти?

Так что не надо прожектёрства и воздушных замков. Производители железа не такие тупые, как тебе кажется (да, ты этого не говорил, я домысливаю, но не вижу, почему этот домысел может быть неправилен). Они умеют считать и умеют оценивать проблемы и от чрезмерной толщины регистров, и от их недостатка, и выбирать RISC/CISC/стековая_модель/etc.

V>>> Но проблема, как обычно, не в железе. Не зря Power PC на той же частоте показывает гораздо большую вычислительную мощь, но их воз и ныне там.
N>>Ну да, в синтетических тестах. Мы тут сейчас запускаем кластер с Cell'ами. Так вот — никакому психу не приходит в голову на Cell'ах собирать программы для них же — собираются на x86 кросс-сборкой, потому что это работает в ~5 раз быстрее, чем сборка на месте. Вот потому их воз и ныне там.
V>Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм? :xz:
V>Дело, как обычно, в софте.

Это как он должен был реализовать? Собирать в несколько программных тредов? Не понимаю твоего утверждения.

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

Ну предложи что-то реальное. Пока же имеем или проблемный IA64, или тормозной PPC, или дорогой в работе x86. Наверно, есть какие-то реальные проблемы, мешающие твоему идеалу?

V>>> во вторых, малое кол-во регистров позволяет на порядок легче анализировать поток исполнения.
N>>Ну да, просто убивая возможность анализа на корню. Пусть компилятор думает, у него голова большая.
V>Надеюсь, теперь ты так не считаешь. Если не понимаешь, посмотри как работает JIT-компилятор дотнета. Он проще, чем декомпилятор x86-го, вот в чем прикол.

Где посмотреть? И у меня нет пары дней закопаться в детали.

N>>>>>>* почему Intel говорит именно про микрокод и избегает термина firmware по отношению к тому, что в процессоре?
V>>>>>А вот Трансмета не избегает. Мало ли чего избегает конкретно Интел. :xz: У Интела "прошивка" однократная, у тех настраиваемая.
N>>>>У Intel вообще-то можно настраивать (правда, что именно строится — знают только их инженеры)
V>>>Тогда с чего ты решил, что избегают этого термина?
N>>потому что у них "микрокод", а не firmware.
V>Ну а в ветке, куда ты подключился, было именно firware. :)))

Угу, и при этом никто не мог договориться, что именно имеется в виду.

N>>Да, мне действительно теперь понятно — что цепляясь за нелепый устарелый термин ты теряешь суть.
V>Я не цепляюсь, я разъясняю, что он означает. :)
V>Если ты сутью называешь свои абстракции, то я их теряю, разумеется, когда мы говорим о значении терминов. Чтобы не было разночтений. Ты понимаешь, чем отличается конвеер команд 8086 и современный конвеер? И интереса ради, какова разрядность современного внутреннего конвеера? И что именно в нем содержится? По сути, этот вопрос содержит ответ, и если найдешь ответ — вопросы отпадут.

Ну так для себя у меня вопросов и не было. Это ты завёл разговор в такую область, что мы зачем-то не можем договориться.:)

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

У него много входных сигналов. В состоянии чтения кода он воспринимает их как код, чтения данных — как данные (неважно, шина объединяет их или нет). Этого уже достаточно, чтобы не предполагать простую схему "посмотрели на вход — дёрнулись внутри — дали выход".

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

Если в 086 был конвейер, то он и был этой очередью.

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

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

N>>Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?
CC>ICC

Интересно. Можно пример входного и выходного кода?

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

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

V>>>> А PPro — так себе, частности, если сравнивать с уже существующими на тот момент DEC Alpha или Sparc-ами. Просто Интелл наконец вступила в клуб "больших дядек".
N>>>Ничего себе "частности", всё нутро поменялось до неузнаваемости.
V>>Да плевать. Ничего Интеллом в PPro не было изобретено такого, чего бы не было до этого. K5, Nx686 (он же К6 позже) раньше всех использовали идею внутреннего RISC для x86, которую реализовала и Интелл. То, что есть революция для Интелл, не обязательно даже новость для остального мира.

N>Мы обсуждали важность реформ внутри модельного ряда x86, а не по сравнению с остальными. Ты подменяешь тему разговора.

Слушай, а чего ты вообще к PPro прицепился? Я вот его в глаза не видел и ни один из коллег, с кем знаком лично, тоже его не видел. Изменения в указанной последовательности Пентиум->Пентиум II практически идентичны изменениям Пентиум->Пентиум Про. Я же показывал смену поколений, т.е. если бы указал ППро, надо было бы не указывать П2. А это не справедливо, ибо популярность в те времена П2 и ППро абсолютно несравнима. Или ты типа нашел за что меня поймать? Ну это несерьезно. Если интересуют подробности, то да, когда-то давно, до того как к нас в город пришел нормальный интернет, я выписывал "компьютерное обозрение" и очень внимательно следил за соревнованием процов примерно до 2000-2001-го года, потом надоело.

V>>Хоть одно не косметическое, влияющее на архитектуру ядра?

N>Устранение северного моста и прямое управление памятью.

Мимо, шинный формирователь никуда не делся, просто теперь он в процессоре. Но не в ядре. Помнишь, я говорил о различиях микропроцессоров и микроконтроллеров. Так вот, микроконтроллер — это ядро микропроцессора + некоторая периферия прямо в проце. Для примера посмотри на AMD Alchemy, там ядро известной архитектуры, и куча периферии на кристалле. Есть много разновидностей Alchemy, отличающихся периферией, но ядро идентично для них всех. Поэтому извини, но мимо. Даже если вообще всю оперативку в процессор запихают, как на многих микроконтроллерах, это не будет относится к ядру, а будет классическим SoC.

N>Внос видеоконтроллера в процессор (в моделях, где он есть).

Из той же оперы. Я же задал вопрос не про микросхему, как таковую, а про ядро, т.е. про сам процессор.


N>>>За отмазку не канает (tm). AMD не сделала диверсию, выбор этого решения явно был по принципу "меньшее из всех зол". А почему меньшее — отнюдь не в совместимости, которая и так сломана.
V>>Во-первых, как это сломана? Если 64-битные винды спокойно напрямую запускают 32-битные приложения, а не в окне эмулятора, то для пользователя никакая совместимость не сломана.

N>Для такого исполнения совершенно не нужно идентичности системы команд. Гибриды x86+IA64 (Intel), x86+Alpha (неудавшиеся планы AMD) — не требуют совместимости системы команд: они могут быть абсолютно разные. А вот те же команды с точностью до бита ты уже не исполнишь так, чтобы оно незаметно из 32 стало 64-битным (disclaimer: в традиционном стиле; можно сделать такую систему команд, чтобы битность не влияла — но это не было сделано). Поэтому я и говорю — совместимость сломана. А раз сломана — не было никакой неизбежности в самой архитектуре продолжать систему команд x86, в 64 битах могли взять Sparc, Alpha, IA64, MIPS... Решали же из соображений удобства.

Э нет, два несовместимых ядра в гибриде, или же одно ядро с доработанным дешифратором и удвоенной разрядностью АЛУ — это две большие разницы. И все равно из этого сумбура (выделил) я не понял, как amd-x64 ломает совместимость. Обратная совместимость не сломана, а "прямой" быть не может в случае любого расширения набора команд, необязательно в сторону расширения битности.

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

N>Чтобы ответить на этот вопрос, надо знать, что происходило внутри Intel в районе 1999-2000. Может, на них лопнувший пузырь доткомов повлиял, может, ещё что-то, но они тогда выпустили как минимум два ужасных решения: Pentium4 и Itanium. P4, к счастью, сдох очень быстро. Itanium — судьба непонятна.

Нет, они пошли правильно, доводя до абсолюта две идеи: сверхдлинный конвейер и сверхширокие команды. Сейчас длина конвейеров тоже довольно большая, просто первый блин комом, им надо было постепенно развивать отличный (самый удачный ИМХО, если позиционировать на технологии "своего времени") Пень-3. А сейчас технологически реально Интелл отстает, и значительно. Они держат лидерство исключительно за счет экстенсивных факторов: это кол-во ядер на кристалл + раньше всех переходят на более миниатюрный процесс.

N>>>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.

V>>Ну и почему? Разве не понятно?

N>Не-а. Объясни, пожалуйста, если знаешь. Действительно интересно.

Из-за цены. Вторые пни пошли по реально низким ценам, Интеллу удалось взять реванш за K-5, которые практически полностью задавили первый пентиум. Твой любимый Пень-Про в массы не пошел, если помнишь. И я скажу почему — исключительно из-за цены, хотя этот проц, судя по публикуемым характеристикам, был не плох.


N>Купил — и где? В архивы слито? (Я молчу, что Эльбрус был задолго до IA-64 и даже до HPPA)

Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).

(остальное потом)

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

N>>Мы обсуждали важность реформ внутри модельного ряда x86, а не по сравнению с остальными. Ты подменяешь тему разговора.
V>Слушай, а чего ты вообще к PPro прицепился? Я вот его в глаза не видел и ни один из коллег, с кем знаком лично, тоже его не видел.

И что я на это должен ответить, кроме как "возьми с полки пирожок"? Ты не видел? Сочувствую. Я видел. У меня были системы на нём, я работал с ним, другие работали. Это была совершенно уникальная вещь. Как тебе нравится, например, 128-битная плавучка (против максимум 80 у других в ряду), расширяемая в SMP до 256? (Не ищи этого в официальной документации, там нет.)

V> Изменения в указанной последовательности Пентиум->Пентиум II практически идентичны изменениям Пентиум->Пентиум Про. Я же показывал смену поколений, т.е. если бы указал ППро, надо было бы не указывать П2.

Да, P2 — попсовый кастрат на базе PPro, зато быстрее. Полностью новшества PPro (кроме явно убитых) во внутренней структуре поступили только в P3, не в P2.

V> А это не справедливо, ибо популярность в те времена П2 и ППро абсолютно несравнима. Или ты типа нашел за что меня поймать? :)

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

V> Ну это несерьезно. Если интересуют подробности, то да, когда-то давно, до того как к нас в город пришел нормальный интернет, я выписывал "компьютерное обозрение" и очень внимательно следил за соревнованием процов примерно до 2000-2001-го года, потом надоело. :xz:

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

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

Не "мимо", а он теперь совсем другой.

V> Но не в ядре. Помнишь, я говорил о различиях микропроцессоров и микроконтроллеров. Так вот, микроконтроллер — это ядро микропроцессора + некоторая периферия прямо в проце. Для примера посмотри на AMD Alchemy, там ядро известной архитектуры, и куча периферии на кристалле. Есть много разновидностей Alchemy, отличающихся периферией, но ядро идентично для них всех. Поэтому извини, но мимо. Даже если вообще всю оперативку в процессор запихают, как на многих микроконтроллерах, это не будет относится к ядру, а будет классическим SoC.

Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?

N>>Внос видеоконтроллера в процессор (в моделях, где он есть).
V>Из той же оперы. Я же задал вопрос не про микросхему, как таковую, а про ядро, т.е. про сам процессор.

А это теперь ядро, представь себе. Этим шагом Intel сокращает путь до видеоконтроллера, чтобы он был не отдельным блоком. Знаешь, в чём на сейчас основная проблема производительности расчётов на NVidia + ATI? Чтобы данные подсчитались, их надо передать в видеоконтроллер (медленно), подсчитать (быстро) и вытащить (медленно). Пока ты делаешь картинку на экран, поток односторонний и эти тормоза несущественны. Когда считаешь — они убивают всё. Представь себе теперь то же самое, но в основном блоке процессора. У тебя появляется потоковый расчётный блок в несколько раз мощнее несчастных SSE и при этом на расстоянии половины кристалла. Если ты скажешь, что и это не процессор, мне останется считать, что ты аргументов не понимаешь в принципе.

N>>Для такого исполнения совершенно не нужно идентичности системы команд. Гибриды x86+IA64 (Intel), x86+Alpha (неудавшиеся планы AMD) — не требуют совместимости системы команд: они могут быть абсолютно разные. А вот те же команды с точностью до бита ты уже не исполнишь так, чтобы оно незаметно из 32 стало 64-битным (disclaimer: в традиционном стиле; можно сделать такую систему команд, чтобы битность не влияла — но это не было сделано). Поэтому я и говорю — совместимость сломана. А раз сломана — не было никакой неизбежности в самой архитектуре продолжать систему команд x86, в 64 битах могли взять Sparc, Alpha, IA64, MIPS... Решали же из соображений удобства.
V>Э нет, два несовместимых ядра в гибриде, или же одно ядро с доработанным дешифратором и удвоенной разрядностью АЛУ — это две большие разницы. И все равно из этого сумбура (выделил) я не понял, как amd-x64 ломает совместимость.
V> Обратная совместимость не сломана, а "прямой" быть не может в случае любого расширения набора команд, необязательно в сторону расширения битности.

Вот именно что прямой совместимости быть не может. Считай, что я неудачно (для тебя) выразился. Я говорю, что отсутствие прямой совместимости давало возможность выбрать расширение с тотальной сменой системы команд.
"Одно ядро с доработанным дешифратором" тут никак не получалось: дешифраторы режимов 32 и 64 практически несовместимы. А обшую регистровую базу и АЛУ получалось сделать независимо от того, какая целевая архитектура — в них всех есть регистры и АЛУ. Ну сказали бы, например, что EAX = low(R0), EBX = low(R1) и так далее, всё бы работало.

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

Ну и я о том же. Текущее решение выглядит очень странно.

N>>Чтобы ответить на этот вопрос, надо знать, что происходило внутри Intel в районе 1999-2000. Может, на них лопнувший пузырь доткомов повлиял, может, ещё что-то, но они тогда выпустили как минимум два ужасных решения: Pentium4 и Itanium. P4, к счастью, сдох очень быстро. Itanium — судьба непонятна.
V>Нет, они пошли правильно, доводя до абсолюта две идеи: сверхдлинный конвейер и сверхширокие команды. Сейчас длина конвейеров тоже довольно большая, просто первый блин комом, им надо было постепенно развивать отличный (самый удачный ИМХО, если позиционировать на технологии "своего времени") Пень-3.

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

V> А сейчас технологически реально Интелл отстает, и значительно. Они держат лидерство исключительно за счет экстенсивных факторов: это кол-во ядер на кристалл + раньше всех переходят на более миниатюрный процесс.

Они гонят "ядро на кристалл" потому что понимают, что иначе всем настанет, например, тотальный NUMA. К которому никто не готов по-настоящему (весь SMP уровня приложения сейчас реализует в лучшем случае заточку на однородную память; максимум что есть для NUMA это шедулер для малонитевых процессов). AMD слишком резко перешёл на эту структуру.

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

N>>>>Ты помнишь, что в 1999-2000 AMD заявляла "мы собираемся делать гибридный процессор — x86 в 32 битах и Alpha в 64 битах" и таким образом хотела сделать плавный переход? Ей ничего не мешало, но в реализацию пошёл почему-то гибрид бульдога с носорогом по фамилии amd64.
V>>>Ну и почему? Разве не понятно?
N>>Не-а. Объясни, пожалуйста, если знаешь. Действительно интересно.
V>Из-за цены. Вторые пни пошли по реально низким ценам, Интеллу удалось взять реванш за K-5, которые практически полностью задавили первый пентиум. Твой любимый Пень-Про в массы не пошел, если помнишь. И я скажу почему — исключительно из-за цены, хотя этот проц, судя по публикуемым характеристикам, был не плох.

Я и не спорю, что он в массы не должен был идти: это был чисто серверный вариант, к тому же с заточкой под военщину США. Но новшество было в нём. Если сравнить, например, с автомобилестроением — новые решения и технологии сначала поступают в дорогие изделия и затем только перебираются в дешёвые.

Кстати, где-то с 99-го его мог купить любой:) цены упали. И я знаю тех, кто покупал именно его — потому что под их задачи работал в разы лучше P2 и не сильно хуже P3.

N>>Купил — и где? В архивы слито? (Я молчу, что Эльбрус был задолго до IA-64 и даже до HPPA)

V>Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).

Не понял — чем тут три цикла лучше или хуже?

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

N>>>Какой компилятор способен вынести операции с double в SSE2 и чтобы это было эффективно?
CC>>ICC

N>Интересно. Можно пример входного и выходного кода?

Ну навскидку например вот:

void SerialCorrelation::Update (const void* buf, DWORD len)
{
    const BYTE* buffer = (const BYTE*)buf;

    while (len--)
    {
        double value = *buffer++;

        if (!m_total) 
            m_first = value;
        else m_sumLast += m_last * value;

        m_sum += value;
        m_sumSq += value * value;
        m_last = value;
        
        m_total++;
    }
}

    PUBLIC ?Update@SerialCorrelation@@QAEXPBXK@Z
?Update@SerialCorrelation@@QAEXPBXK@Z    PROC NEAR 
; parameter 1: ecx
; parameter 2(buf): 16 + esp
; parameter 3(len): 20 + esp
.B1.1:                          ; Preds .B1.0

;;; {

$LN1:
        push      esi                                           ;27.1
        sub       esp, 8                                        ;27.1
$LN3:

;;;     const BYTE* buffer = (const BYTE*)buf;
;;; 
;;;     while (len--)

        cmp       DWORD PTR [20+esp], 0                         ;30.2
        je        .B1.11        ; Prob 0%                       ;30.2
                                ; LOE ecx ebx ebp edi
.B1.2:                          ; Preds .B1.1
$LN5:

;;;     {
;;;         double value = *buffer++;
;;; 
;;;         if (!m_total) 

        mov       esi, DWORD PTR [ecx]                          ;34.3
        mov       eax, DWORD PTR [4+ecx]                        ;34.3
$LN7:

;;;             m_first = value;
;;;         else m_sumLast += m_last * value;
;;; 
;;;         m_sum += value;

        movsd     xmm0, QWORD PTR [32+ecx]                      ;38.3
$LN9:

;;;         m_sumSq += value * value;

        movsd     xmm1, QWORD PTR [40+ecx]                      ;39.3
                                ; LOE eax ecx ebx ebp esi edi xmm0 xmm1
.B1.3:                          ; Preds .B1.2
$LN11:
        je        .B1.10        ; Prob 10%                      ;30.2
                                ; LOE eax ecx ebx ebp esi edi xmm0 xmm1
.B1.4:                          ; Preds .B1.11 .B1.3
        xor       edx, edx                                      ;
        mov       DWORD PTR [4+esp], edi                        ;
        mov       DWORD PTR [esp], ebx                          ;
        mov       ebx, DWORD PTR [16+esp]                       ;
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1
.B1.5:                          ; Preds .B1.8 .B1.4
$LN13:
        movzx     edi, BYTE PTR [edx+ebx]                       ;32.16
        cvtsi2sd  xmm3, edi                                     ;32.16
$LN15:
        mov       edi, esi                                      ;34.3
        or        edi, eax                                      ;34.3
        jne       .B1.7         ; Prob 50%                      ;34.3
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1 xmm3
.B1.6:                          ; Preds .B1.5
$LN17:
        movsd     QWORD PTR [8+ecx], xmm3                       ;35.4
        jmp       .B1.8         ; Prob 100%                     ;35.4
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1 xmm3
.B1.7:                          ; Preds .B1.5
$LN19:
        movsd     xmm2, QWORD PTR [16+ecx]                      ;36.8
        mulsd     xmm2, xmm3                                    ;36.8
        addsd     xmm2, QWORD PTR [24+ecx]                      ;36.8
        movsd     QWORD PTR [24+ecx], xmm2                      ;36.8
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1 xmm3
.B1.8:                          ; Preds .B1.6 .B1.7
$LN21:
        addsd     xmm0, xmm3                                    ;38.3
        movsd     QWORD PTR [32+ecx], xmm0                      ;38.3
$LN23:
        movaps    xmm2, xmm3                                    ;39.3
        mulsd     xmm2, xmm3                                    ;39.3
$LN25:

;;;         m_last = value;
;;;         
;;;         m_total++;

        add       esi, 1                                        ;42.3
        adc       eax, 0                                        ;42.3
$LN27:
        inc       edx                                           ;30.2
        cmp       edx, DWORD PTR [20+esp]                       ;30.2
$LN29:
        addsd     xmm1, xmm2                                    ;39.3
        movsd     QWORD PTR [40+ecx], xmm1                      ;39.3
$LN31:
        movsd     QWORD PTR [16+ecx], xmm3                      ;40.3
$LN33:
        mov       DWORD PTR [ecx], esi                          ;42.3
        mov       DWORD PTR [4+ecx], eax                        ;42.3
$LN35:
        jb        .B1.5         ; Prob 82%                      ;30.2
                                ; LOE eax edx ecx ebx ebp esi xmm0 xmm1
.B1.9:                          ; Preds .B1.8
        mov       edi, DWORD PTR [4+esp]                        ;
        mov       ebx, DWORD PTR [esp]                          ;
                                ; LOE ebx ebp edi
.B1.10:                         ; Preds .B1.11 .B1.9 .B1.3

;;;     }
;;; }

$LN37:
        add       esp, 8                                        ;44.1
        pop       esi                                           ;44.1
        ret       8                                             ;44.1
                                ; LOE
.B1.11:                         ; Preds .B1.1                   ; Infreq
        xorps     xmm1, xmm1                                    ;
        movaps    xmm0, xmm1                                    ;
        mov       esi, 0                                        ;
        mov       eax, esi                                      ;
        jne       .B1.4         ; Prob 90%                      ;
        jmp       .B1.10        ; Prob 100%                     ;
        ALIGN     16
                                ; LOE eax ecx ebx ebp esi edi xmm0 xmm1
; mark_end;
?Update@SerialCorrelation@@QAEXPBXK@Z ENDP
.LN?Update@SerialCorrelation@@QAEXPBXK@Z:
;?Update@SerialCorrelation@@QAEXPBXK@Z    ENDS
_TEXT    ENDS

Касательно эффективности:
(первая цифра — время в тиках, вторая — в секундах, третья — результат выполнения)

E:\Temp\1>TestFPU.exe
781'364'936 0.354324 0.000107

E:\Temp\1>TestFPU.exe
782'137'356 0.354674 0.000107

E:\Temp\1>TestFPU.exe
781'556'457 0.354410 0.000107

E:\Temp\1>TestFPU.exe
781'267'476 0.354279 0.000107

E:\Temp\1>TestFPU.exe
781'008'800 0.354162 0.000107

E:\Temp\1>TestSSE.exe
659'993'378 0.299285 0.000107

E:\Temp\1>TestSSE.exe
659'511'996 0.299067 0.000107

E:\Temp\1>TestSSE.exe
660'818'675 0.299524 0.000107

E:\Temp\1>TestSSE.exe
659'963'150 0.299272 0.000107

E:\Temp\1>TestSSE.exe
660'893'662 0.299693 0.000107

Пример конечно мелкий, но всё равно разница составляет ~15% на полностью автоматической генерации.
Пример побольше займёт много страниц asm кода и пару страниц C++ кода. Даже не говоря о том, что я тот код публиковать не могу.

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

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

Угу, заклинило. Я уже понял, что тебе хотелось продемонстрировать некую причастность к ППро, молодец. Однако, для демонстрации смены архитектуры, привязанннойко времени, моя последовательность тоже не плоха, чтобы ты там не говорил. Ты все время путаешь архитектуру и частости, например, упоминая свои 128 бит float. Это не есть разница в архитектуре. Например, есть куча тех-же PIC-контроллеров с разной разрядностью, но абсолютно идентичной архитектурой ядра.

N>Я не слежу за микропоколениями, эта информация в случае чего легко находится (и я в упор не помню, чем там Sledgehammer был лучше Clawhammer). Но основные вехи надо помнить, если ты вообще взялся что-то говорить про историю.

Кому надо?

N>Не "мимо", а он теперь совсем другой.

Он для каждой новой памяти другой, ибо другие спецификации, и что с того?

N>Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?

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


N>А это теперь ядро, представь себе. Этим шагом Intel сокращает путь до видеоконтроллера, чтобы он был не отдельным блоком. Знаешь, в чём на сейчас основная проблема производительности расчётов на NVidia + ATI? Чтобы данные подсчитались, их надо передать в видеоконтроллер (медленно), подсчитать (быстро) и вытащить (медленно). Пока ты делаешь картинку на экран, поток односторонний и эти тормоза несущественны. Когда считаешь — они убивают всё. Представь себе теперь то же самое, но в основном блоке процессора. У тебя появляется потоковый расчётный блок в несколько раз мощнее несчастных SSE и при этом на расстоянии половины кристалла. Если ты скажешь, что и это не процессор, мне останется считать, что ты аргументов не понимаешь в принципе.

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

V>>Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).

N>Не понял — чем тут три цикла лучше или хуже?

Описка, предполагалось "цикл в три такта". Для x86 тот же исходник генерит около 50-ти команд, т.е. это будет порядка 30 тактов. Причем, задача плохо параллелится на потоковом параллелизме, ибо там вычислений по-сути никаких, только чтение-запись памяти, граф объектов — он один, и многократно зациклен взаимными ссылками. Т.е. выделить независимые данные для потокового паралелизма не получается, зато прекрасно получается оптимизировать код для явного.

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

V>>Это ты, типа, разработку вот своей фигни на одном счетчике и 4-х регистрах с DSP пытаешься сравнивать? А 4-5 порядков разницы в сложности — это типа мелочи? Слушай, нафига ты спор в фарс превращаешь?

N>Спор превращаешь в фарс ты. Это ж надо — упорно доказывать, что никто ничего нового в мире железа не разрабатывает... да, у меня примеры из моей области, и я намеренно беру простые (есть и сложные, но мне облом тратить три страницы на объяснение, нафига оно надо и почему такое). В процессорах тебе, видите ли, ничего нового. Я контрпример привёл — прими его.

Извини, но ты привел пример из области разработки периферии. Вот пройдись по фирмам, которые выпускают SoC. Они предлагают обычно на одном кристалле совместить какое-нить ядро проца общего назначения (обычно MIPS или ARM), добавить какое-нить ядро DSP, иногда с готовой прошивкой для популярных аудио и видео форматов, добавить какую-нить периферию, например контролер памяти, или даже некоторую память прямо на кристалл, добавить USB, I2C и т.д. А теперь представь, это они просто рядом расположили на кристалле и оно само работает?

Понятное дело, что надо сопрягать и всякое такое, но эта задача примерно на порядок сложнее твоей с регистром, но не 4-5 порядков, как в случае разработки нового ядра процессора. Доработать обвеску и доработать ядро под конкретные нужды — это две большие разницы, ибо объем разработки и тестирования несопоставим.

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

Ответил рядом на первую половину.

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

Ты не возражаешь, ты дал мало инфы, а потом раскритиковал мое решение, да еще я так и не понял насчет "юлить". Я могу более четко повторить: разработка "своего" ядра — это крайне дорогое удовольствие, особенно оно дорогое, если будет разрабатываться своя система команд, потому как надо будет разработать эту непротиворечивую систему команд, и весь tool-chain к ней. Это я тебе просто напоминаю, в какое обсуждаение ты встрял. Так вот, в случае декодеров, т.е. DSP, система команд DSP обычно определяет архитектуру ядра, ибо это честный VLIW RISC, безовсяких переименований, out-of-order и т.д., ибо эти вещи делаются компилятором, но не процом. Поэтому я и был так уверен в той подветке, что никакое ядро специально никто для этого кодека не разрабатывал. Да хороший компилятор под DSP сегодня разработать дороже выйдет даже, чем спроектировать ядро, тут не о чем спорить.

N>>>Да и MIPS был к тому времени сложившейся и распространённой архитектурой. Ты вообще факты проверяешь или у тебя классовое чутьё?)
V>>Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.

N>Спасибо, что хоть не повторяешь, что MIPS вымер. Уже прогресс.

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

N>Плохой, негодный пример. Во-первых, компьютер — не среда дотнета: иногда стека вообще нет, иногда кэш может быть не включён. Во-вторых, ты не пробовал взять ручку и подсчитать регистры в минимальном варианте?
N>* два аккумулятора (ой только не надо 6502 вспоминать. два нужны хотя бы для операций умножения и деления)
N>* два индексных регистра (ты сам сказал про два)
N>* указатель стека
N>* указатель TLS (извините, такое на стеке не хранят)
N>* счётчик команд

N>Это жёсткий минимум. Ничего не напоминает? С минимальными поправками — мы получили 8086 (и вплоть до P4-не-64бит без FP/MMX/SSE).
N>Теперь расширим аккумулятор до хранения полного вектора данных в стиле SSE... ой, и что это у нас получилось? да x86 и получился.


Я многое поскипал, ибо ты одно и то же говоришь. Но тебе двойка за невнимательность. Я говорил о байт-коде, который подается CISC процу. Пусть процессор внутри имеет 16/32 реагистров, да сколько угодно, это его дело, ибо CISC все-равно полностью переделывает входной код под внутренние регистры. И пусть он сохраняет внутренние регистры, это же делается одной командой. Задача драйвера будет лишь выделить нужное кол-во памяти в данных потока для данной модели проца. Ты хорошо сказал про гибкость во время сохранения кол-ва регистров, только не довел эту мысль до конца. А повторяться о том, что байт-код уровня дотнета гораздо более поддается анализу, чем x86, смысла нет, ибо это более чем очевидно.

Понимаешь, после компиляции программ я вижу кучу пар push/pop, когда компилятор жонглирует временными результатами вычислений. Прикол в том, что сегодня проц не имеет права оптимизировать такие вещи, поэтому это все тормозит вычисления, ибо проц оперирует с реальной памятью, а не файлом регистров. Если же заведомо объявить архитектуру работающей по верифицированному коду, т.е. когда есть гарантии целостности стека, то для описания алгоритма достаточно будет пары индексных регистров и аккумулятора (пусть с твоими поправками насчет удвоенной его разрядности). И не надо путать эти регистры как абстракции входного байт-кода с реальными регистрами, требуемыми для исполнения этого кода, получаемыми после всех оптимизаций и переименований внутри проца. И оптимальное кол-во регистров, разумеется, разное для разных задач. Для некоторых задач и 32 мало, поэтому "гибкость" в плане сохранения регистров будет развиваться и далее.

N>А извратиться без регистров — можно даже вообще без единого: всё на стеке (ну, останутся IP, SP, FS). Только мы, кажется, про RISC говорили? Где ты вообще видел RISC с тремя операндами в памяти?

Ну ты нить разговора потерял, очевидно.

N>Так что не надо прожектёрства и воздушных замков. Производители железа не такие тупые, как тебе кажется (да, ты этого не говорил, я домысливаю, но не вижу, почему этот домысел может быть неправилен). Они умеют считать и умеют оценивать проблемы и от чрезмерной толщины регистров, и от их недостатка, и выбирать RISC/CISC/стековая_модель/etc.

Считать могут все, только тут нечего считать. Очень сложно в одном процессоре учесть все вооразимые алгоритмы, на нем прогоняяемые. Поэтому на разных задачах одни и те же процы могут как выигрывать друг у друга более 100% производительности, так и проигрывать столько же на других задачах. Поэтому мне нравится подход Sun, с их заведомо большим файлом регистров. Тут ведь чем больше, тем лучше, а ограничения пусть уже сама задача указывает, ибо она лучше процессора знает, как ей лучше.

V>>Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм?
V>>Дело, как обычно, в софте.

N>Это как он должен был реализовать? Собирать в несколько программных тредов? Не понимаю твоего утверждения.

Да, грузить архитектуру по полной. Я понимаю, что в gсс такого нет, о том и речь.


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

N>Ну предложи что-то реальное. Пока же имеем или проблемный IA64, или тормозной PPC, или дорогой в работе x86. Наверно, есть какие-то реальные проблемы, мешающие твоему идеалу?

К Эльбрусу уже отсылал. К современным процам от Sun тоже. Их архитектуры, будь у них такой же процесс изготовления в распоряжении, как у Интелл, надрали бы задницу легко.

N>Где посмотреть? И у меня нет пары дней закопаться в детали.

Я тебя огорчу, парой дней там не обойдешься. В кратце — очень сильно упрощает анализ кода некие гарантии, суть ограничения, которыми обложен байт-код по спецификации. Т.е. память у нас не совсем идет как фон-неймановская, для абстракции стека гарантируется во-первых его целостность, во-вторых — доступ лишь из текущего потока, т.е. стек не рассматривается как общая память. Ввиду этого, команды обращения к данным по смещению указателя стекового фрейма, не обязательно выполнять явно, т.е. писать/читать из внешней памяти, а можно распихивать на все регистры имеющегося файла у данной архитектуры процессора. Именно это я и имел ввиду, предлагая упрощенный байт-код, оперирующий минимум абстракций. Ведь в любом случае, архитектура x86 — это не более чем абстракция, которая переводится во внутреннее представление. Просто входная абстракция не очень, особенно вот эти push/pop, и спец. команды, которые могут быть выполнены лишь на некоторых регистрах.


N>Угу, и при этом никто не мог договориться, что именно имеется в виду.

Я лишь спорил против того, что H.264 декодируется "аппаратно", и утверждал, что там DSP+прошивка.

N>У него много входных сигналов. В состоянии чтения кода он воспринимает их как код, чтения данных — как данные (неважно, шина объединяет их или нет).

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

N>Этого уже достаточно, чтобы не предполагать простую схему "посмотрели на вход — дёрнулись внутри — дали выход".

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

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

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

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

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

Я его не разрабатывал — к чему причастность-то? Элементарная справедливость.

V> Однако, для демонстрации смены архитектуры, привязанннойко времени, моя последовательность тоже не плоха, чтобы ты там не говорил. Ты все время путаешь архитектуру и частости, например, упоминая свои 128 бит float.

А я и не говорил, что это свойство его архитектуры. Хотя подумать стоит — например, объединение FP соседних процессоров — уже архитектурное решение.

N>>Я не слежу за микропоколениями, эта информация в случае чего легко находится (и я в упор не помню, чем там Sledgehammer был лучше Clawhammer). Но основные вехи надо помнить, если ты вообще взялся что-то говорить про историю.
V>Кому надо?

Извини, я не знаю, как ответить на этот вопрос вежливо.

N>>Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?
V>Да, все кеши, кроме того, с которым работает непосредственно ядро — периферия. Это как инкапсуляция в ООП, при сохранении интерфейса не суть важно что за ним.

Тогда ты очень странно понимаешь слово "архитектура". Для тебя это — какие блоки есть и что они делают, причём на самом верхнем уровне?

N>>А это теперь ядро, представь себе. Этим шагом Intel сокращает путь до видеоконтроллера, чтобы он был не отдельным блоком. Знаешь, в чём на сейчас основная проблема производительности расчётов на NVidia + ATI? Чтобы данные подсчитались, их надо передать в видеоконтроллер (медленно), подсчитать (быстро) и вытащить (медленно). Пока ты делаешь картинку на экран, поток односторонний и эти тормоза несущественны. Когда считаешь — они убивают всё. Представь себе теперь то же самое, но в основном блоке процессора. У тебя появляется потоковый расчётный блок в несколько раз мощнее несчастных SSE и при этом на расстоянии половины кристалла. Если ты скажешь, что и это не процессор, мне останется считать, что ты аргументов не понимаешь в принципе.
V>Чтобы сказать более точно, мне надо взглянуть на архитектуру. Там одно от другого отделить в принципе очень просто, т.е. если доступ по внешней, по отношению к ядру шине, то оно вне ядра, хоть даже и на одном кристалле. Вот это и есть единственный аргумент, а остальное — банальный SoC.

Таким образом можно отделить что угодно. Например, FPU. И даже целочисленный АЛУ — он ведь не участвует в собственно исполнении команд... и что у тебя остаётся от процессора?

Нормальный метод деления — всё-таки логический по функциональности.

V>>>Я имел ввиду VLIW Эльбрус, а он один. В архивы не слито, команда Эльбруса показала, что эффективность VLIW неотделима от математического обеспечения, то бишь от хорошего, нет, очень хорошего компилятора для VLIW, поэтому эти разработчики были куплены, по-сути, для разработки компилятора под Итаниум, чем и занимаются успешно. Все равно, на очень многих классах задач VLIW на той же тактовой дрючит CISC раза в 3-5. Не на всех, это надо понимать, а там, где уместен явный параллелизм. Например, был очень неплохой пример для Эльбруса, когда цикл sweep сборки мусора компилятор скомпилил в 3 цикла (!!!).
N>>Не понял — чем тут три цикла лучше или хуже?
V>Описка, предполагалось "цикл в три такта". Для x86 тот же исходник генерит около 50-ти команд, т.е. это будет порядка 30 тактов. Причем, задача плохо параллелится на потоковом параллелизме, ибо там вычислений по-сути никаких, только чтение-запись памяти, граф объектов — он один, и многократно зациклен взаимными ссылками. Т.е. выделить независимые данные для потокового паралелизма не получается, зато прекрасно получается оптимизировать код для явного.

Ладно, sweep написали хорошо (хотя тот sweep сейчас разве что в учебных задачах нужен). И всё? Хотелось бы видеть несколько классов задач...

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

N>>>Я бы тебе поверил, если бы управление памятью в x86 было бы простым, как в мелких кристаллах. Но даже там сейчас есть вещи посложнее голого доступа к памяти. Изменение контроллера памяти меняет внутреннюю архитектуру исполнительных блоков и интерфейс кэшей. Или для тебя всё кроме АЛУ + УУ — это обвязка? И даже L1 кэш — обвязка?
V>>Да, все кеши, кроме того, с которым работает непосредственно ядро — периферия. Это как инкапсуляция в ООП, при сохранении интерфейса не суть важно что за ним.

N>Тогда ты очень странно понимаешь слово "архитектура". Для тебя это — какие блоки есть и что они делают, причём на самом верхнем уровне?

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

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

N>Таким образом можно отделить что угодно. Например, FPU. И даже целочисленный АЛУ — он ведь не участвует в собственно исполнении команд... и что у тебя остаётся от процессора?

Вот еще. Были добавлены 75 новых команд для работы с FPU, сами регистры FPU теперь адресовались непосредственно и это значит, что эти регистры были доступны из общей внутренней шины. А сколько инструкций было добавлено для работы с видеосопроцессором?

N>Нормальный метод деления — всё-таки логический по функциональности.

Да все методы нормальные, смотря с какой целью выполняется декомпозиция. Если тебе более понятно из ПО, то деплой и логическое деление — две большие разницы, порой существенно влияющие на издержки. Первое деление обычно более крупное, но бывает ровно наоборот.

В принципе, даже если они полностью интегрируют видеосопроцессор в ядро (хотя непонятно, почему бы просто не добавить обычных ядер с очередным расширением какого-нить SSE5), то пока это не будет означать серьезных изменений архитектуры ядра, это по прежнему будет экстенсивное наращивание вычислительных блоков. Или ты считаешь, что их ядро уже устоялось, и в принципе не нуждается в модернизации? Глядя на то, что AMD ядра на той же частоте работают практически в полтора раза быстрее, и AMD медленно, но верно догоняет Intel по частоте ядра, я так не считаю. На самом деле, когда они захотят поместить туда более 16-ти ядер, вот тут встанет вопрос о смене архитектуры. Дело в том, что сейчас ресурсы ядра простаивают в среднем на 70%, т.е. каждое ядро обладает таким набором исполнительных механизмов, которое редко задействуется одновременно. Гипертрединг спасает, но эту идею тоже надо доводить до ума, делая настоящие многопоточные ядра, т.е. размывая само понятие современного ядра, которое концентрируется вокруг дешифратора/шедуллера и очереди. Шедуллеров/очередей может быть несколько, исполнительных механизмов, расшаренных м/у шедуллерами тоже. В принципе, у современных ядер Интелл уклон в эту область, но опять же, Sun уже пошел в этом направлении гораздо дальше, показывая большую производительность в пересчете на вентиль (противоположное направление — это Cell, т.е. разнородные ядра на кристалле, и сложности с ПО к ним, как показал твой пример с компиляцией).

N>Ладно, sweep написали хорошо (хотя тот sweep сейчас разве что в учебных задачах нужен). И всё? Хотелось бы видеть несколько классов задач...

Любые числодробилки стабильно показывают до 400%-600% прироста производительности на ядро при той же тактовой, даже с учетом всех SSE, ибо последний в реальных приложениях более 2-х раз ускоряет редко (по своему опыту). Вот тут в сообщении ссылка: http://rsdn.ru/forum/education/3775434.1.aspx

Автор: vdimas
Дата: 15.04.10

, и вообще в той теме обсуждали достаточно. VLIW особенно интересен "многоэтажными" командами, типа за один такт вычислить следующее (a*b)+(c/d), да еще и разветвиться потом по результату.

Интересно в том документе, что в некоторых тестах показаны результаты Итаниума, который например в задачах умножения матриц на вдвое меньшей частоте показывает вдвое большую производительность, чем Xeon, поэтому обзывать Итаниум плохими словами преждевременно. Надо просто довести до ума, т.к. на многих классах задач VLIW однозначно рулит. (Кстати, "частотная" производительность Эльбрус в 2 раза выше Итаниума, т.е. если привести все к одной частоте). И еще интересный момент в том, что будучи и процессором общего назначения и VLIW, Эльбрус значительно "дрючит" популярные производительные DSP (которые тоже давно VLIW, просто малость упрощенные).

На самом деле многоядерный VLIW как раз и позволит полностью отказаться от каких-либо видеосопроцессоров и прочих DSP сопроцессоров, ибо те и есть VLIW, но выполненные по компромиссным схемам, дабы не стоить в 10 раз дороже центрального процессора. Это вкратце, почему я считаю, что Интелл пошла по верному пути со своими Итаниумами, просто остановилась на пол-пути. Выпустила бы 8-миядерный Итаниум хотя бы на 2.4 ГГЦ тактовой — конкурентов бы не было.

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

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

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

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

(BTW — я считал с 0, т.е. 0 — это реальное железо, 1 — обычная VM. Генерация нового CP в VM/SP — это стандартный режим запуска вновь сгенеренного CP под VM — т.е. 2 уровень. А так, просто загружая CP под CP до 5 уровней вложенности на 46 доходили).

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

Сам чистый VPC — вряд-ли. Он сам под собой ляжет.

Но в мире Intel/AMD в этом направлении тоже двигаются. Мотивация, правда, несколько другая. Защита или, наоборот, взлом. На эту тему здесь уже kochetkov.vladimir бросал ссылку (здесь

Автор: kochetkov.vladimir
Дата: 08.04.10

).

Ну и собственно по nested virtualization:
гугл
здесь Рудковска здесь пишет:

It's worth mentioning that the only other working example of nested hardware virtualization I'm aware of is the IBM z/VM hypervisor for the IBM z series mainframe. If anybody knows any other example, please send me a link.

здесь
здесь
здесь
здесь

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

V>Извини, но ты привел пример из области разработки периферии. Вот пройдись по фирмам, которые выпускают SoC. Они предлагают обычно на одном кристалле совместить какое-нить ядро проца общего назначения (обычно MIPS или ARM), добавить какое-нить ядро DSP, иногда с готовой прошивкой для популярных аудио и видео форматов, добавить какую-нить периферию, например контролер памяти, или даже некоторую память прямо на кристалл, добавить USB, I2C и т.д. А теперь представь, это они просто рядом расположили на кристалле и оно само работает? :)

V>Понятное дело, что надо сопрягать и всякое такое, но эта задача примерно на порядок сложнее твоей с регистром, но не 4-5 порядков, как в случае разработки нового ядра процессора. Доработать обвеску и доработать ядро под конкретные нужды — это две большие разницы, ибо объем разработки и тестирования несопоставим.

Верю. Только вот почему-то у одних это сопряжено качественно, а у других — совершенно на тяп-ляп, так, что оно вообще работать не может или работает через пень-колоду (блок X имеет рабочие частоты 5-50 МГц, Y — 45-200 МГц, в результате в единственном нужном тебе режиме остаётся 45-50). К чему это всё — к тому, что человеку свойственно лениться? Мне, как потребителю, это всё пофиг.

Это я не к тому, что нет объективных оценок сложности. Они, конечно, есть. Но останавливать работу только из-за того, что "ах! сложно!" — плохая идея. Я ж не предлагаю всё делать заново с нуля: ни в софте, ни в железе так не делают. Берётся готовое и дорабатывается, развивается. В конце концов, даже в проекте толщиной с gcc или линуксовое ядро можно сделать свою небольшую доработку — на это даже студент способен. У тебя же получается "ах! только мегагуру знает, как это вообще работает, а трогать... да никто кроме бога".

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

Ты постоянно смешиваешь разработку и разработку с нуля.

V> особенно оно дорогое, если будет разрабатываться своя система команд, потому как надо будет разработать эту непротиворечивую систему команд, и весь tool-chain к ней. Это я тебе просто напоминаю, в какое обсуждаение ты встрял. Так вот, в случае декодеров, т.е. DSP, система команд DSP обычно определяет архитектуру ядра, ибо это честный VLIW RISC, безовсяких переименований, out-of-order и т.д., ибо эти вещи делаются компилятором, но не процом. Поэтому я и был так уверен в той подветке, что никакое ядро специально никто для этого кодека не разрабатывал.

Чуть хакнули готовое.

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

Ну я и не спорю. Разработка качественного компилятора для таких средств очень дорога. И то — обычно критичные участки всё равно дорабатывают вручную.

V>>>Известной, но цена MIPS чипов такова, что конкурировать с ними было нереально, имея столб сложный кристалл. Опять же, MIPS использовали во встраиваемой технике, там все эти мощщи, сравнимые с рабочей станцией, на тот момент были просто не нужны, да и платить за них никто бы не стал.
N>>Спасибо, что хоть не повторяешь, что MIPS вымер. Уже прогресс.:)
V>Речь шла о процесорах для компов общего назначения, на этом рынке MIPS не видно и под микроскопом, просто ты многое за меня додумываешь.

Cisco на MIPS знаю. Это уже очень дохрена. Другой вопрос, что они как раз не хотели оптимизацию в стиле Transmeta.

N>>Это жёсткий минимум. Ничего не напоминает? С минимальными поправками — мы получили 8086 (и вплоть до P4-не-64бит без FP/MMX/SSE).
N>>Теперь расширим аккумулятор до хранения полного вектора данных в стиле SSE... ой, и что это у нас получилось? да x86 и получился.
V>Я многое поскипал, ибо ты одно и то же говоришь. Но тебе двойка за невнимательность. Я говорил о байт-коде, который подается CISC процу. Пусть процессор внутри имеет 16/32 реагистров, да сколько угодно, это его дело, ибо CISC все-равно полностью переделывает входной код под внутренние регистры.

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

V> И пусть он сохраняет внутренние регистры, это же делается одной командой. Задача драйвера будет лишь выделить нужное кол-во памяти в данных потока для данной модели проца.

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

V> Ты хорошо сказал про гибкость во время сохранения кол-ва регистров, только не довел эту мысль до конца. А повторяться о том, что байт-код уровня дотнета гораздо более поддается анализу, чем x86, смысла нет, ибо это более чем очевидно.

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

А если ты будешь требовать от процессора понимания, что сделанный тобой K шагов назад push должен быть отработан парным pop — ты потребуешь нерабочую систему, и всё.

V>Понимаешь, после компиляции программ я вижу кучу пар push/pop, когда компилятор жонглирует временными результатами вычислений. Прикол в том, что сегодня проц не имеет права оптимизировать такие вещи, поэтому это все тормозит вычисления, ибо проц оперирует с реальной памятью, а не файлом регистров. Если же заведомо объявить архитектуру работающей по верифицированному коду, т.е. когда есть гарантии целостности стека, то для описания алгоритма достаточно будет пары индексных регистров и аккумулятора (пусть с твоими поправками насчет удвоенной его разрядности). И не надо путать эти регистры как абстракции входного байт-кода с реальными регистрами, требуемыми для исполнения этого кода, получаемыми после всех оптимизаций и переименований внутри проца. И оптимальное кол-во регистров, разумеется, разное для разных задач. Для некоторых задач и 32 мало, поэтому "гибкость" в плане сохранения регистров будет развиваться и далее.

Ну, во-первых, push/pop сейчас по крайней мере на x86 неэффективны. Грамотные компиляторы (вроде gcc) заранее сдвигают указатель стека, а затем используют смещение от %ebp или даже %esp. push/pop требуют слежения за изменениями позиции головы стека и поэтому крайне неэффективны. Лучше уж тогда возродить на новом уровне "нулевую страницу" (снова приходим к подходу имени IA64).

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

N>>А извратиться без регистров — можно даже вообще без единого: всё на стеке (ну, останутся IP, SP, FS). Только мы, кажется, про RISC говорили? Где ты вообще видел RISC с тремя операндами в памяти?
V>Ну ты нить разговора потерял, очевидно.

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

N>>Так что не надо прожектёрства и воздушных замков. Производители железа не такие тупые, как тебе кажется (да, ты этого не говорил, я домысливаю, но не вижу, почему этот домысел может быть неправилен). Они умеют считать и умеют оценивать проблемы и от чрезмерной толщины регистров, и от их недостатка, и выбирать RISC/CISC/стековая_модель/etc.
V>Считать могут все, только тут нечего считать. Очень сложно в одном процессоре учесть все вооразимые алгоритмы, на нем прогоняяемые. Поэтому на разных задачах одни и те же процы могут как выигрывать друг у друга более 100% производительности, так и проигрывать столько же на других задачах. Поэтому мне нравится подход Sun, с их заведомо большим файлом регистров. Тут ведь чем больше, тем лучше, а ограничения пусть уже сама задача указывает, ибо она лучше процессора знает, как ей лучше.

А мне нравится подход IA64. Да, тоже большой файл регистров, но заметь — во-первых, он разумно фиксированный, даже слишком большой (ну кому реально нужно более 96 регистров?), во-вторых, в пределах вертикальных переключений тривиально решается задача занять именно столько, сколько нужно, и не больше. У Сана же, во-первых, получаешь слишком много регистров, во-вторых, доступаться к ним через окно — извращение.

V>>>Потому что в компиляторе не реализован ни явный, ни многопоточный параллелизм? :xz:
V>>>Дело, как обычно, в софте.
N>>Это как он должен был реализовать? Собирать в несколько программных тредов? Не понимаю твоего утверждения.
V>Да, грузить архитектуру по полной. Я понимаю, что в gсс такого нет, о том и речь.

Дело не в gcc. Как ты собираешься описывать процессору исполнение этих тредов? Разнести их просто так по "тредам" в стиле HT — ничем не отличается от обычного распараллеливания в стиле OpenMP. Перед каждой командой ставить тег треда? Мало преимуществ перед автоматическим разбросом, особенно учитывая различие реальных архитектур; проблемы фальшстарта и сброса конвейера. В общем, проблем очень много.

V>>>Да, современные процы делают то, что могли бы делать компиляторы. Я уже высказывался, что не против этого, но эту концепцию надо использовать до конца, т.е. входной код должен быть более для этого приспособлен.
N>>Ну предложи что-то реальное. Пока же имеем или проблемный IA64, или тормозной PPC, или дорогой в работе x86. Наверно, есть какие-то реальные проблемы, мешающие твоему идеалу?
V>К Эльбрусу уже отсылал. К современным процам от Sun тоже. Их архитектуры, будь у них такой же процесс изготовления в распоряжении, как у Интелл, надрали бы задницу легко.

Не надо вспоминать Sun. Тем более что с заводами у него было неплохо, но дело не в этом. Возьмём один и тот же Intel, у которого заводы полностью свои. Почему x86 на коне, а IA64 — наоборот? Где IA64 на 5ГГц? Дай ответ на последний вопрос, и ты сам поймёшь половину ситуации.

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

А можно просто L1+writeback, и это общим и дешёвым образом покроет все проблемы.

V> Именно это я и имел ввиду, предлагая упрощенный байт-код, оперирующий минимум абстракций. Ведь в любом случае, архитектура x86 — это не более чем абстракция, которая переводится во внутреннее представление. Просто входная абстракция не очень, особенно вот эти push/pop, и спец. команды, которые могут быть выполнены лишь на некоторых регистрах.

что "не очень" я согласен, но использование push и pop — это к кривым компиляторам. А спецкоманды — их что, много? В общем пуле действий я кроме умножения и деления таких не вижу, всё остальное отлично распределяется на 5-6 общих.

N>>У него много входных сигналов. В состоянии чтения кода он воспринимает их как код, чтения данных — как данные (неважно, шина объединяет их или нет).
V>"Он" это кто? Если ядро проца — то у к нему данные и код по разным шинам подходят от кеша первого (в другой терминологии 0-го) уровня.

Представь себе, что кэша нет.

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

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

N>>Этого уже достаточно, чтобы не предполагать простую схему "посмотрели на вход — дёрнулись внутри — дали выход".
V>Ниче не понял. Ты про защиту памяти?

Нет.

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

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

S>>>Компы уже давно, лет десять как превышают потребности этак порядка на два-три.
DOO>>Смотря в каких задачах.
DOO>>Ну нельзя же так огульно заявлять сразу обо всем.

T>Попробуем с другой стороны Для каких задач обычного юзера не хватало процессоров 10-летней давности?

Вам минус за минус на мое сообщение без комментария. Оставляйте комментарии к минусам.