Тут как и с счётным кодом важно, является ли код latency bound (скажем, проход по связному списку, случайно разбросанному по адресам) или throughput bound (когда предсказуемо читаем память подряд, как в примере в статье). В первом случае ускорение будет.
Просто некий unsigned long, который в разных устройствах может означать разные вещи. Параметры операции - так и вовсе список из переменного числа произвольных аргументов.
Во первых, свои модели - скажем, БК 0010 или Микроша - были разработаны и производились в классических советских учреждениях, кооперативы эти не занимались. Во вторых, к производству элементной базы кооперативы никакого отношения не имели - соотвественно, полноценной рыночной цепочки, когда спрос на компьютеры формирует спрос на производство и развитие микропроцессоров, не было. Рынка компьютерных игр и вообще софта для домашних компьютеров тоже не было - всё просто копировали друг у друга - отсюда и явное превосходство Спектрума в плане софтварной экосистемы.
А нужен ли вообще C сферическому новичку в вакууме? Всё таки это в первую очередь язык для тех, кому интересно, как реально код бежит на процессоре, и кто может конвертировать этот интерес в разработку софта (embedded, OS, компиляторы, прочие инструменты) - и обычно у таких людей какой то бэкграунд в программировании накапливается в школьные годы до знакомства с C.
вряд ли инлайн-асм в C/C++-коде обрабатывается компилятором так
Инлайн асм в 64битном cl.exe вообще вырубили, как раз из за невозможности нормально генерировать SEH правила.
Ради того, чтобы сэкономить восемь шестнадцать байт на стеке?
Скорее ради нескольких тактов процессора при каждом заходе в try блок, в каких то ситуациях может быть критично. Идея в том, что при отсутствии исключений try должен быть вообще бесплатным - то есть использовать его можно сколько угодно, лишь бы сами исключения не падали. Генерация правил в компиляторе дело наживное (в Юниксах .eh_frame секция давно использовалась), об усложнениях пишущих на ассемблере, видимо, не особо думали - директивы дали и ладно.
И SEH тоже испортили, убрав цепочку фреймов с стека. Чем руководствовались — загадка.
Тут то всё понятно - убрали дополнительный оверхед в прологе/эпилоге на работу с этой цепочкой. Раскрутка стека при исключениях стала заметно дороже - но предполагается, что исключения - это действительно исключения и случаются крайне редко.
все нововведения нужны только, если ваш код вызывает код из посторонних библиотек (банальный пример — WinAPI) или наоборот, посторонний код вызывает ваш
В этих случаях ещё неплохо правила для SEH прописать(см. здесь, "Unwind helpers for MASM").
Это соответствует варианту "мы знаем, что старший ребёнок девочка". Эквивалент оригинальной задачи - монетку подбрасывали два раза, и мы знаем что как минимум один раз (не факт, что при первом подбросе) выпадал орёл. Соответственно, вероятности второго орла/девочки в разных вариантах разные.
А если говорить о классических профилировщиках (perf, VTune), данным на небольшой кусок кода можно доверять только если это внутренний цикл с большим числом итераций - иначе статистические ошибки сильно испортят картину.
IACA и его "потомки" (OSACA, llvm-mca, uica) не профилировщики, а статические анализаторы - с одной стороны, они дают полную картину с точностью до работы отдельных инструкций и не подвержены погрешностям измерения, с другой - точность ограничена заложенной моделью и параметрами процессора, на железе они анализируемый код не запускают.
В смысле с Altair 8800? Да, результат сравнения очевиден. Больше известного западного на 8080 не припомню, как то больше на 6502 и Z80, причём ещё c 70х
так это претензии не к тем, кто делал, а к партии и правительству.
Статья же именно об этом - отсутствие рынка и т.д. Конструкторский талант разработчиков Микроши или Суры не обсуждается.
Я на подручном Haswell вижу полтора (и это логично, когда независимые операции раскладываются на два порта).
Тут как и с счётным кодом важно, является ли код latency bound (скажем, проход по связному списку, случайно разбросанному по адресам) или throughput bound (когда предсказуемо читаем память подряд, как в примере в статье). В первом случае ускорение будет.
Просто некий unsigned long, который в разных устройствах может означать разные вещи. Параметры операции - так и вовсе список из переменного числа произвольных аргументов.
Включая авторов Unix, выкинувших его в Plan 9.
Не упомянули ioctl(), с которым юниксовый файл является по сути объектом с произвольным интерфейсом.
Во первых, свои модели - скажем, БК 0010 или Микроша - были разработаны и производились в классических советских учреждениях, кооперативы эти не занимались. Во вторых, к производству элементной базы кооперативы никакого отношения не имели - соотвественно, полноценной рыночной цепочки, когда спрос на компьютеры формирует спрос на производство и развитие микропроцессоров, не было. Рынка компьютерных игр и вообще софта для домашних компьютеров тоже не было - всё просто копировали друг у друга - отсюда и явное превосходство Спектрума в плане софтварной экосистемы.
Навскидку (x ^ (x >> (sizeof(x)*8-1))) - (x >> (sizeof(x)*8-1))
А нужен ли вообще C сферическому новичку в вакууме? Всё таки это в первую очередь язык для тех, кому интересно, как реально код бежит на процессоре, и кто может конвертировать этот интерес в разработку софта (embedded, OS, компиляторы, прочие инструменты) - и обычно у таких людей какой то бэкграунд в программировании накапливается в школьные годы до знакомства с C.
Я это и имел в виду, неточно выразился.
Инлайн асм в 64битном cl.exe вообще вырубили, как раз из за невозможности нормально генерировать SEH правила.
Скорее ради нескольких тактов процессора при каждом заходе в try блок, в каких то ситуациях может быть критично. Идея в том, что при отсутствии исключений try должен быть вообще бесплатным - то есть использовать его можно сколько угодно, лишь бы сами исключения не падали. Генерация правил в компиляторе дело наживное (в Юниксах .eh_frame секция давно использовалась), об усложнениях пишущих на ассемблере, видимо, не особо думали - директивы дали и ладно.
Не раскрыта тема проверки корректности адресов возврата/перехода в железе (Intel CET, ARM PAC/BTI).
Практика программирования (Керниган/Пайк) - не только про C, но большая часть кода на нём.
Тут то всё понятно - убрали дополнительный оверхед в прологе/эпилоге на работу с этой цепочкой. Раскрутка стека при исключениях стала заметно дороже - но предполагается, что исключения - это действительно исключения и случаются крайне редко.
В этих случаях ещё неплохо правила для SEH прописать(см. здесь, "Unwind helpers for MASM").
Это соответствует варианту "мы знаем, что старший ребёнок девочка". Эквивалент оригинальной задачи - монетку подбрасывали два раза, и мы знаем что как минимум один раз (не факт, что при первом подбросе) выпадал орёл. Соответственно, вероятности второго орла/девочки в разных вариантах разные.
А если говорить о классических профилировщиках (perf, VTune), данным на небольшой кусок кода можно доверять только если это внутренний цикл с большим числом итераций - иначе статистические ошибки сильно испортят картину.
IACA и его "потомки" (OSACA, llvm-mca, uica) не профилировщики, а статические анализаторы - с одной стороны, они дают полную картину с точностью до работы отдельных инструкций и не подвержены погрешностям измерения, с другой - точность ограничена заложенной моделью и параметрами процессора, на железе они анализируемый код не запускают.
В смысле с Altair 8800? Да, результат сравнения очевиден. Больше известного западного на 8080 не припомню, как то больше на 6502 и Z80, причём ещё c 70х
Статья же именно об этом - отсутствие рынка и т.д. Конструкторский талант разработчиков Микроши или Суры не обсуждается.
А на других счётных кодах проблема не воспроизводится?
Альтернатива - пилить такой же код самим с нуля.
Вопрос в ресурсах на эту работу. В американском минобороны должны найтись.