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

WH>А если я пишу на немерле то там на сотни строк кода может не быть ни одной переменной.
что пишешь, если не секрет?

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

C> Или его со временем полностью вытеснит верифицируемый промежуточный код?
C> Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C> Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

Надеюсь я до этого кошмара не доживу.

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

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

C>> Или его со временем полностью вытеснит верифицируемый промежуточный код?
C>> Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
C>> Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?

S>Надеюсь я до этого кошмара не доживу.

Мой минус прошу воспринимать как "нет, ты ДОЖИВЕШЬ до этого кошмара!"

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

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

Узкий специалист в тяжелой форме.

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

[]

PD>То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири".

ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.

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

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

kig>[]

PD>>То-то, по утверждению Нортона, того, кто исключил стек из архитектуры IBM-360, "сослали во внутрифирменный аналог Сибири".

kig>ИМХО: Не знаю, что там Нортон утверждал и когда, но в начале 60 годов за предложение резервировать часть такого дорогого ресурса (на тот момент), как память под стек при загрузке кода, сослали бы точно.

А объяснить -1?

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

S>Надеюсь я до этого кошмара не доживу.

Почему кошмар?
Это же розовые сны опенсорса! или нет?

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

T>>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40.
WH>Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400.
WH>Так и запишем.

Еще запиши, не забудь.
1) Упомянутое ядро MIPS без без кэшей и FPU, от которого отсчитан данный процент занимает примерно миллиметр площади на 130 нм. Пусть два. Миллиметр кристалла имеет себестоимость порядка 6 центов. И это для fabless компании — крупняку это стоит еще дешевле.
2) Промах в кэш TLB случается достаточно редко. Ты будешь экономить от 40 до 400 тактов на каждые несколько миллионов тактов, преведенные внутри циклов. Размер данного кэша специально выбирается так, чтобы промах не имел значения, прикинь, какая неожиданность?

Ага, прям так и запиши.

WH>>>Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86.
T>>А это-то здесь при чём?
WH>Ну при том что сейчас очень много процессоров с этой нашлепкой.
WH>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

И даже в этом ты ошибся . Мне из достоверных источников известно, что у thesz iMac на базе PowerPC G5.

WH>Управляемые системы позволят от этой нашлепки избавиться.

Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?

WH>Ибо в случае с управляемой ОС нужно будет просто описать модель нового процессора.

Как все невероятно просто у вас. "Просто" описать "модель нового процессора". Ты когда нибудь портабельную ОСь под новый проц и борду портировал? Попробуй, увлекательнейшее занятие. Про разработку процессоров я уж и не спрашиваю .

WH>И весь софт стразу на нем заработает.
WH>С нативными ОС такой фокус не пройдет.

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

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

T>Да, соглашусь.

Рановато, ИМХО .

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

WH>>>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

T>>Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).

IID>Гы, а у меня два x86 компа дома, два компа на Z-80, два на 6502, один на К1801ВМ1 и ещё один — двухпроцессорный на КМ1801ВМ2.

И что, это годные, хорошие компы — ты с этих компов можешь писать в RSDN?

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

WH>Ну при том что сейчас очень много процессоров с этой нашлепкой.
WH>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.

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

WH>>Ну при том что сейчас очень много процессоров с этой нашлепкой.
WH>>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.

G>Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.

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

Оверхэд по площади — смешной для суперскалярного проца на 6 каналов арифметики, а производительность, как ни парадоксально, при таком подходе выше. А знаешь, почему? CISC код более компактен, чем RISC, что снижает требования к пропускной способности памяти, размеру кэшей, итд. А именно это — узкое место в настоящее время.

Вот так вот жизнь необычно устроена.

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

G>А для чего может понадобиться ассемблер, кроме установки служебных регистров, работы с портами и прерываниями?

К примеру, в процессорах ARM есть специальные инструкции, предназначенные для сохранения 8 регистров сразу. Применются много где — и в коде переключения контекста, и в коде банального memcpy.

К примеру, в процессорах ARM есть специальное расширение системы инструкций NEON — применяется при сигнальной обработке и в мультимедийных кодеках. Библиотеки пишутся ручками на ассемблере.

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

G>В Singularity они необходимость ассемблера обошли таким образом: коду драйвера передается экземпляр класса, который отвечает за всю низкооуровневую работу (обращения к этому классу вполне могут компилиться в нужный нативный код).

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

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

G>Почему нельзя будет для других архитектур процессоров сделать другие классы, наследники какого-либо базового?

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

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

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

WH>>Управляемые системы позволят от этой нашлепки избавиться.
G>Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?
А ты что не знал?
Доказательство простое и совершенно не опровержимое: Если бы они были достаточно портабельны то эта нашлепка бы не появилась.

G>Как все невероятно просто у вас. "Просто" описать "модель нового процессора". Ты когда нибудь портабельную ОСь под новый проц и борду портировал? Попробуй, увлекательнейшее занятие. Про разработку процессоров я уж и не спрашиваю .
А давай ты сравнишь эти затраты хотя бы с простой перекомпиляцией всего софта в мире под новый процессор и доставкой бинарников пользователям, а если учесть что очень большое количество софта так просто под новый процессор не перекомпилировать (привет языкам "высокого" уровня типа С/С++) то
Даже переход на x86-64 был тем еще приключением.
Не смотря на то что винда64 появилась быстро пользоваться ей было невозможно очень долго ибо не было драйверов (вот скажи мне зачем драйверу устройства знать систему команд CPU?), эмуляторы CDROM'ов тоже не работали (этим тоже система команд CPU должна быть до лампочки),... даже не весь прикладной софт работал не смотря на то что винда запускала его в режиме совместимости.

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

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

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

WH>>>Управляемые системы позволят от этой нашлепки избавиться.
G>>Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?
WH>А ты что не знал?
WH>Доказательство простое и совершенно не опровержимое: Если бы они были достаточно портабельны то эта нашлепка бы не появилась.

Угу. Так же как и доказательство того, что ты инопланетянин.

Дано: 2+2=5.
Отсюда неопровержимо следует, что 2 = 1. Вы и инопланетянин — вас двое. 2 = 1 — вы одно и то же лицо.

G>>Как все невероятно просто у вас. "Просто" описать "модель нового процессора". Ты когда нибудь портабельную ОСь под новый проц и борду портировал? Попробуй, увлекательнейшее занятие. Про разработку процессоров я уж и не спрашиваю .
WH>А давай ты сравнишь эти затраты хотя бы с простой перекомпиляцией всего софта в мире под новый процессор и доставкой бинарников пользователям, а если учесть что очень большое количество софта так просто под новый процессор не перекомпилировать (привет языкам "высокого" уровня типа С/С++) то

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

WH>Даже переход на x86-64 был тем еще приключением.

WH>Не смотря на то что винда64 появилась быстро пользоваться ей было невозможно очень долго ибо не было драйверов (вот скажи мне зачем драйверу устройства знать систему команд CPU?), эмуляторы CDROM'ов тоже не работали (этим тоже система команд CPU должна быть до лампочки),... даже не весь прикладной софт работал не смотря на то что винда запускала его в режиме совместимости.

И почему это в макоси нет таких проблем, интересно? Наверное, они в Купертино что-то не так делают, и уж явно курят что-то менее забористое, чем в MS, раз обошлись без выдумок в духе Singularity.

И у IBM с их серверами на базе Power тоже проблема отсутствует, почему-то. WTF?

И у DEC с их Alpha почему-то все в порядке было с переходом. Ну не чудеса-ли?

WH>И это не вспоминая про такие вещи как надежность и безопасность управляемого софта.

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

Так скорее всего и сделают, как только данная проблема станет кого-либо по серьезному волновать — не будут производители микроэлектроники полагаться на изобретение единственной компании. Как в свое время оптимизировали исполнительный конвейр под С++, добавив, к примеру, предсказание косвенных переходов.

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

G>>Это да. Зато с несуществующей пока пригодной к "продакшну" осью, о которой ты говоришь — любой фокус пройдет . То, что еще не работает толком — всегда обладает чудесными свойствами, это ж всем известно.
WH>Ты можешь ехидничать сколько влезет но от фундаментальных проблем классического подхода твое ехидство не спасет.

Причина моей иронии в том, что "фундаментальные проблемы классического подхода" существуют по большей части в твоем воображении. Как и их воображаемое решение.

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

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

G>Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.
Отличный образец демагогии.
Ты сравниваешь работу разных людей. Единственный вывод который можно сделать из этого сравнения это то что у разработчиков Power руки кривее чем у ребят из интела.
А что будет если ребятам из интела дать возможность сделать такую систему команд которую они захотят?
1)Я конечно в разработки процессоров мало что понимаю но что-то мне подсказывает что уменьшение длинны конвейера (а именно это произойдет при выкидывании нашлепки) скажется на производительности в лучшую сторону.
2)Есть у меня такое чувство что и в основном процессоре тоже можно будет выкинуть какую ни будь фигню которая нужна только устаревшим командам.

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

WH>>>>Управляемые системы позволят от этой нашлепки избавиться.
G>>>Правда штоли . А язык С, и прочие языки высокого уровня, значит, принципиально недостаточно портабелены, чтобы "от этой нашлепки избавиться"?
WH>>А ты что не знал?
WH>>Доказательство простое и совершенно не опровержимое: Если бы они были достаточно портабельны то эта нашлепка бы не появилась.

G>Угу. Так же как и доказательство того, что ты инопланетянин.

G>Дано: 2+2=5.
G>Отсюда неопровержимо следует, что 2 = 1. Вы и инопланетянин — вас двое. 2 = 1 — вы одно и то же лицо.

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

Ничего личного, bro. Ты первый начал . Показать, где у тебя ложная посылка? Или сам найдешь?

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

G>>Кстати, по странному стечению обстоятельств процы с "этой нашлепкой" частенько стоят дешевле и работают быстрее, чем процы без нее. Представляешь, неувязочка какая получается. Вот, к примеру, компы Apple при переходе на Intel с Power стали внезапно быстрее раз в 5. Боюсь, данная нашлепка не мешает разработчикам процессоров из Intel и AMD. Они хорошие танцоры, видать.

WH>Отличный образец демагогии.

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

WH>Ты сравниваешь работу разных людей. Единственный вывод который можно сделать из этого сравнения это то что у разработчиков Power руки кривее чем у ребят из интела.

Нормальный человек не будет делать выводов касательно качеств разработчиков из IBM. Хотя бы потому, что кроме Intel и IBM есть SUN и AMD. А в недавнем прошлом — процы делали HP (PA-RISC), DEC (Alpha), Silicon Graphics (MIPS), короче, хренова туча народу, всех не упомнишь.

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

К сведению — чтобы еще немного усложнить картину, приблизив ее к реальной — система команд Power сложна, она скорее CISC, чем RISC. То же самое касается ARM — это далеко не чистый RISC, там достаточно сложных CISC инструкций и кажется есть какой-то кривой не RISC-овый метод адресации.

И он будет прав в этом выводе. Доминируют другие факторы.

WH>А что будет если ребятам из интела дать возможность сделать такую систему команд которую они захотят?

Они делают именно такую систему команд, которую хотят. Они даже в шейдерных процессорах перспективных 3D контроллеров хотят x86. Читай ниже.

WH>1)Я конечно в разработки процессоров мало что понимаю но что-то мне подсказывает что уменьшение длинны конвейера (а именно это произойдет при выкидывании нашлепки) скажется на производительности в лучшую сторону.

Глубина конвейера не сократится. Декодер команд ты никуда не выкинешь — единственная разница будет в том, что декодер будет выплевывать одну трехадресную микрокоманду в конвейер вместо группы, как это происходит сейчас, и станет чуть-чуть меньше площадью — от туда уйдут конечные автоматы, реализующие трансляцию x86 в трехадресный микрокод.

Учитывая возросший размер исполняемого кода, и, как следствие — требования к пропускной способности памяти и размеру кэшей, после твоей модификации для выполнения той же работы (CISC-код заметно компактнее, чем RISC — я наблюдал до 2-х раз, сравни размеры бинарей для SPARC и x86), эффект будет отрицательным, а не положительным.

WH>2)Есть у меня такое чувство что и в основном процессоре тоже можно будет выкинуть какую ни будь фигню которая нужна только устаревшим командам.

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

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

G>Угу. Так же как и доказательство того, что ты инопланетянин.
G>Дано: 2+2=5.
G>Отсюда неопровержимо следует, что 2 = 1. Вы и инопланетянин — вас двое. 2 = 1 — вы одно и то же лицо.
Просто отвергать то что тебе не нравится это так просто...

G>А давай ты сам займешься глупостями, которые выдумаваешь, вместо того, чтобы предлагать это мне? Это справедливо.
Ты сказал что портирование ядра ОС это охренеть как сложно. Я просто сказал что придется сделать при смене системы команд в случае с классическим подходом.
Кстати портирование ядра в случае с классическим подходом тоже нужно...

G>Как-никак никого кроме тебя в мире не волнует проблема перекомпиляции всего софта в мире под новый процессор.
А кто тебя назначил представителем всего мира?

G>Ведь новые процессора по большей части волшебным образом совместимы по системе команд со старыми.
1)Как ты верно заметил по большей части.
2)Вынужденны быть совместимы из-за мегатонн легаси кода.

G>И почему это в макоси нет таких проблем, интересно?
А ты сравни количество софта и железа под макось и под винду. Теперь сравни какой процент софта и железа контролируют мелкософт и яблочники.
Все еще не понимаешь?

G>И у IBM с их серверами на базе Power тоже проблема отсутствует, почему-то. WTF?
G>И у DEC с их Alpha почему-то все в порядке было с переходом. Ну не чудеса-ли?
Тут ситуация еще более тепличная чем у яблочников.

G>При чем тут ОСь-то, а?
Так безопасность она либо везде либо нигде.
Других вариантов нет.

G>Пускайте себе свой "супернадежный управляемый софт" как пользовательские процессы — руки прочь от процессоров и оперсистем
Процессоры управляемым ОС до лампочки.
А вот почему нельзя сделать управляемой саму ОС не понятно.
Вот скажи мне чем статически типизированный (я бы даже сказал жестоко типизированный ну там зависимые типы итп) эрланг хуже для разработки ядра ОС и драйверов чем С?

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

руки прочь от процессоров

Для управляемых ОС процессор трогать не надо

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

G>Причина моей иронии в том, что "фундаментальные проблемы классического подхода" существуют по большей части в твоем воображении. Как и их воображаемое решение.
Ага а то что виндой64 можно было начать пользоваться только через год после ее появления мне приснилось да?

G>Чтобы понимать "фундаментальность" проблем, и видеть пространство возможных решений вместо одного (что необходимо для осмысленного, а не фанбойского анализа альтернатив), надо знать элементарные принципы устройства аппаратуры и иметь опыт работы с железом. Уметь цитировать материалы по singularity из сети для этого недостаточно.
Ты пока что кроме откровенной демагогии не сказал ничего.

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

G>Демагогией является игнорирование фактов, и написание большого количества буков из желания поспорить. Отличным образцом чего, как мне кажется, является этот твой пост.
Объясни пожалуйста вот такой факт:

#include <windows.h>
#include <iostream>

struct Timer
{
    Timer()
    {
        QueryPerformanceFrequency((LARGE_INTEGER*)&freq_);
    }
    void Reset()
    {
        QueryPerformanceCounter((LARGE_INTEGER*)&begin_);
    }
    double GetTime()
    {
        QueryPerformanceCounter((LARGE_INTEGER*)&end_);
        return double(end_ - begin_) / freq_;
    }
private:
    __int64 begin_, end_, freq_;
};

int main()
{
    const int count = 1000000000;
    Timer t;
    t.Reset();
    __asm
    {
        push ecx
        mov ecx, count
l1:
        loop l1
        pop ecx
    }
    std::cout << t.GetTime() << std::endl;
    t.Reset();
    __asm
    {
        push ecx
        mov ecx, count
l2:
        dec ecx
        jnz l2
        pop ecx
    }
    std::cout << t.GetTime() << std::endl;
    t.Reset();
    return 0;
}

2.278
0.451337

Процессор Intel Core 2 Quad
Каким образом 2х байтовый loop оказался в 5 раз медленней чем 3х байтовая связка из dec и jnz?
Как это вяжется с твоей теорией что нашлепка не влияет на производительность?
Что мешало внутри процессора произвести трансляцию loop в dec и jnz?
Может тут не все так просто как ты пытаешься представить?

G>Нормальный человек
Можешь не стараться. Такими дешевыми трюками меня из себя не вывести.

G>не будет делать выводов касательно качеств разработчиков из IBM.
Почему?

G>Хотя бы потому, что кроме Intel и IBM есть SUN и AMD. А в недавнем прошлом — процы делали HP (PA-RISC), DEC (Alpha), Silicon Graphics (MIPS), короче, хренова туча народу, всех не упомнишь.
И что?

G>Нормальный человек сделает из этого сравнения вывод, что поддержка систем команд х86/CISC не оказывает никакого значимого отрицательного влияния на производительность процессоров, так же как система команд в стиле RISC — положительного. Все определяют в большей степени особенности микроархитектуры, а не ISA.
То что внутренняя архитектура влияет сильнее я не спорю.
А вот то что нашлепка не вносит значимого влияния не очевидно.

G>Они делают именно такую систему команд, которую хотят. Они даже в шейдерных процессорах перспективных 3D контроллеров хотят x86. Читай ниже.
А можно ссылку на то чем конкретно они мотивировали именно x86?

G>Учитывая возросший размер исполняемого кода, и, как следствие — требования к пропускной способности памяти и размеру кэшей, после твоей модификации для выполнения той же работы (CISC-код заметно компактнее, чем RISC — я наблюдал до 2-х раз, сравни размеры бинарей для SPARC и x86), эффект будет отрицательным, а не положительным.
Да ради байта. Я же не против того что коды команд будут разного размера. Проблема же не в наличии dec rx который сразу же транслируется в sub rx rx 1 проблема в наличии всякого тормозного хлама типа loop.

G>x86 сразу же транслируются в ту систему команд, которая удобна разработчикам ядра, дружище. Как только декодируется. Честно. На первых же стадиях конвейра. Практически нечего выкидывать.
Чтобы убедится в этом придется читать исходники.
У тебя случайно исходники свежих интеловских процессоров не завалялись?