> В некоторых сложных случаях оптимизирующий компилятор хоть с C, хоть с Rust, может быть быстрее ассемблера.Не совсем. Компиляторы ограничены в том, что они могут сделать, человек не имеет этих ограничений. Вплоть до того, что если поиск самого быстрого машинного кода, решающего данную задачу, окажется слишком сложным для ущербных человеческих мозгов, человек может создать специализированную программу, которая будет заниматься таким поиском. И с этой точки зрения, человек в любой конкретной ситуации может получить результат, как минимум, не хуже компилятора.
Люди предпочитают компиляторы, потому что писать код, дооптимизированный до уровня примеров программ в кнутовском TAOCP, очень долго. И время доведения кода до такого уровня оптимизированности растёт нелинейно с ростом размера программы. Написать в таком стиле electron людям не удалось бы, даже если бы они взяли все человекочасы всех живших или живущих людей, которые те потратили на чтобы то ни было, и все эти человекочасы вбухали бы в разработку максимально эффективного электрона. Всё равно их не хватило бы.
Если ты откроешь Брукса и почитаешь его "Мифический человекомесяц", ты увидишь пример тому, как программисты IBM когда-то впоролись в эту проблему, в процессе написания OS/360. Очень жёппно. Чтобы не впарываться так, программисты начинают упрощать себе жизнь, вводя всякие ABI, например. Но ведь как только ты выбрал какую-то конвенцию вызова, так сразу ты отказал себе в возможности микрооптимизировать код, подбирая конвенцию вызова, на основании того, как функция работает с аргументами, и того как эта функция чаще всего вызывается. Или не отказал, но усложнил -- легко потом забыть провести такую микрооптимизацию. А потом ты изменишь программу, и микрооптимизацию придётся проводить снова, меняя конвенцию вызова той или иной функции раз в месяц. Или ещё пример: современные API предполагают, что функция имеет ровно одну точку входа, что она блин _функция_. Но зачем? Можно же делать несколько точек входа. Или, допустим, разделение чисел на знаковые и беззнаковые -- процессору пофигу, какие там числа, какие операции будешь использовать, так он с ними и будет работать. Но людям было удобно, они создали абстракцию, которая потенциально может сделать код медленнее. Дейкстра пришёл и зачмырил goto, но goto позволяет создавать более быстрые программы, чем все эти ваши for/while/if. Отказ от goto сделал программы проще для человека, но ограничил их в возможности писать быстрые программы.
Всё это пытаются нивелировать оптимизирующими компиляторами, и в целом небезуспешно. То есть компилятор вполне может создать функцию с несколькими точками входа, если он достаточно прошарен в теме, хотя ты и не можешь сказать ему сделать именно это. В результате, как правило, довольно сложно написать код, который будет быстрее того, что сгенерировано компилятором. Но не факт, что невозможно. Я бы даже исходил из обратного постулата: любой компилятор можно обогнать.
По-хорошему, есть выбор: писать говнокод, который невозможно ни читать, ни, тем более, мейнтейнить, либо писать хорошо и красиво, но полагаться в оптимизациях на компилятор. Но тут мы подходим к тонкой грани между теоретической возможностью написать быстрее компилятора, практической возможностью, и к cost-benefit анализу. А это слишком сложная тема для уровня опеннета, в ней ты сольёшь без шансов, потому что, когда опеннетовец будет говорить о возможности, он будет говорить о теоретической возможности, а когда он будет говорить о невозможности, он будет говорить о практической невозможности, переключаясь с одного определения на другое так, как ему будет удобно для выстраивания его софизмов. И поделать с этим ты ничего не сможешь. Так что мой тебе совет: даже и не пытайся.
