/newquiz@QuizBot

To create a new quiz, switch to your private chat with the bot.

Ой, не

Я хотел ещё раз пройти

Проблема в том, что хоть векторизатор и может преобразовывать большое число случаев в SSE/AVX, он может легко не видеть кучу других случаев из-за общей сложности кода. Кроме того в коде могут присутствовать вычисления, векторную форму которой довольно проблемно выразить на Си так, чтобы компилятор все понял.

Эвристики, конечно, дорабатываться, но я сомневаюсь, что для сложного какого-нибудь алгоритма вроде H.264 простой Си с gcc10 может обойти асм с AVX и прочим.

О чем @foxpy нам и поведал, на примере x264 и свежего gcc.

И к сожалению, Царь пока не с нами, чтобы поведать, чем тот код для x264 плох.

Поэтому примем за рабочую версию, что вставки бывают нужны.

Что конечно, не билет везде лепить асм - надо профайлить и убедиться, что у компилятора не получается родить.

Потому что с добавлением вставок ещё есть куча проблем, включая портабельность кода.

Кроме того, код на Си скован стандартом. Так то компилятор мб мог ещё больше, но он ограничен as if rule. Самым проблемным пунктом стандарта является memory model. В Си и крестах модель памяти довольно мягкая и позволяет много оптимизаций, но все же могут существовать случаи, когда желаемый код просто невозможно написать. Впрочем, возможно векторные интринсики GNU C могли бы тут помочь. Но тут уже проблемы портабельности - нужен рантайм диспатч ибо как мы уяснили, собирать код на системе пользователя - так себе идея. Кстати, тут выигрывают ЯП с JIT, что Роман "Царь" справедливо заметил.

а ЯП с JIT разве не создают indirect call?

После JIT-компиляции ничем не хуже нативного кода

ну единственная беда рантайм диспатча - indirect call

такая себе беда

Вспоминается раст и lli, кстати. Кто-нибудь знает, интерпретатор LLVM умеет в JIT?

только на некоторых архитектурах.

Было бы неплохо

Ну, если AOT - тоже норм

Главное, что интерпретатор на самом деле не интерпретатор)