> Все листинги есть в GitHub Issues, и их довольно много. "Навскидку" я
> их не приведу, они мне попадались случайно.И даже ссылки на гитхаб не дадите? А так - алгоритмов и процовых архитектур много и вот так огульно утверждать что X быстрее Y и это цель - ну, так себе затея. Разве что чисто статистически в совсем явных случаях, типа сказав что "си быстрее питона" вы врядли особо соврете. И то ярый питонист в пику накопает краевые случаи, они ничего не доказывают, но все же так бывает.
> Одна из заявленных главных целей - быть быстрее С. Поэтому performance на втором месте.
Быстрее чем си - ну, очень абстрактно. Особенно когда кодеген у обоих на одном и том же LLVM, а если параллельность хотелось и проч, сишники нынче могут OpenMP поюзать одной pragma-ой, например.
> Например, все значения по умолчанию константы - это позволяет производить дополнительные
> оптимизации.
В принципе да, но у хорошего сишника тоже все что может быть констифицировано - константа, для борьбы с багами. При том это в компилтайме достаточно неплохо энфорсится и _может_ быть оптимизировано.
> Параметры функции могут быть значениями или ссылками - это выбирает оптимизирующий
> компилятор компилятор.
Он также может заинлайнить все нахрен, если явно не запрошено экспортировать вон то наружу для других под стандарнтым ABI. И там вообще не будет ни параметров, ни функции, лишь несколько команд делающих
> @Vector для SIMD, а если SIMD не поддерживаются то будет fallback на
> обычный вектор, т.е. поэлементное сравнение.
Да так то на самом деле неплохо, но у simd есть не совсем очевидные но отличные от ноля требования и side effects. И чем больше таких грабель тем хуже оно как именно системный тул.
> inline for, calling conventions можно выбирать для каждой функции.
Инлайн и в сях можно выбирать для каждой функции есчо.
> Там куча всего есть, что делает его именно системным низкоуровневым, чего С
> и в помине не может.
Например, чего?
> Про то что SIMD что-то там увеличивает...это конечно требует серьезных пруфов. Жду.
Чем больше регистров используется тем больше регистров сохранять. Особенно при полном переключении контекста, типа переключения задачи/сохранения состояния потока и проч. А, представляете, си достаточно низкоуровневый для того чтобы на нем например корутины самому сделать было?!
> Но никто не заставляет их использовать. Не хочешь - не используй.
Вопрос не в том - а в количестве грабель которые вылезут. И в реюзабельности кода, особенно, вот именно в системных вещах. У сей очень удобно что многий код можно оттестить на писюке а потом в какой мелкий мк запихнуть. Где с инструментацией все же хуже и кривее (супротив perf/gdb/asan/ubsan/etc). Хотя, знаете, по минимуму сделать ubsan можно даже на мк. Только ваши любимые проверки индексов и математики не халявные. А в ubsan таки сделали ультралайт версию, когда при завале проверки случается всего лишь bad opcode например. Дешево, сердито, и вот именно системный обработчик исключения в мелочи таки заметит что шит произошел. А в этом зигхайле так вообще можно в системные вещи вклиниться?
> И нет, конструкции языка переводятся в инструкции процессору. Если у процессора есть
> SIMD, который может делать до 8х ускорения, а язык программирования не
> знает об этом без хаков, для конкретного компилятора... скажем мягко...нет, это
> не преимущество.
Он может дать до 8x ускорения. А может дать до нескольких раз торможения. Характерный пример будет glibc'шный memcpy. Да, он на вот этом вот выезжает в разы - если условия подошли. А если caller его абы как на куче мелочи дернет с абы какими указателями, копируя по 10 байтов за вызов, оно там будет в рантайме дольше одуплять - можно ли с данным адресом SIMD вообще, или это нарушает constraints. Единственный вариант как-то это гарантировать - прибить форсированый align все и вся на гвозди, но будет другая проблема: RAM и стэка больше жрать будет. Чисто на округление адресации.
> Архитектур которые поддерживает Zig куча. Спасибо LLVM. И нет, это не делает
> язык более "системным", как вы сказали.
Вообще-то LLVM поддерживает не так уж и много архитектур. По сравнению с тем же GCC например. И оптимизация у него хороша только под 1-2, на остальные они просто положили.
> Может для какого-то embedded, и плат нужны отдельные подархитектуры и компиляторы, которых
> нет в LLVM. Возможно, не знаю. Я не железячник.
Если вы не это - тогда какого фига про системность рассказывать? Системность языка все эти вещи подразумевает. Ну ладно, может там хоть стандартный способ положить "эту функцию в вон ту секцию" сделали? Если уж более системное? А то в си вот это подбешивает, нестандартно и в разных компилерах по разному. И без этого фиг фирмвару или бутлоадер какой сделаешь.
> Но это либо совсем никому не нужно, либо вопросы к вендору. Архитектуру
> в LLVM можно добавить, и это делали не раз.
Да как-то не особо эффективно делали. Реально живое там x86-64. Ну ARM'ы еще слегка. Остальное постольку-поскольку, спущено на тормозах. Да даже с ARM оно прикалываться умеет если тематически форумы именно системной направленности почитать.
> Про то что Rust не имеет якобы костов в runtime из-за якобы
> крутых проверок - я хотел бы увидеть доказательства.
Я так понимаю что он с своим borrow checker ухитряется часть проверок доказать в компил тайме и тогда выкинуть их все из кода с чистой совестью. Да что там, оптимизеры типа LTO и сами этим грешат, только уровнем пониже и наружу интерфейс в случае си не вывешивают. Но выпилить к черту проверки, доказав "always true" может на раз. Торвальдс очень ругался - в кернеле компилятор некоторые использования не видит :). И если кто заикается про системность - ему потом эти оптимизации с другого бока очень жестко вылезут так то.
> Например, как он делает проверки выхода за границы массива? Вы опять это пишите, а
> доказательства где?
Как я понимаю - таки в compile time просчитывает большую часть этого. Хотя рантайм panic() у него таки тоже есть. И можете зазырить в рассялке ядра что Торвальдс про такие вещи в СИСТЕМНЫХ вещах думает.
> Rust проверяет корректность некоторых конструкций, довольно ограниченную. Просто из "у
> Rust такая крутая система типов, что он теоретически МОЖЕТ делать более
> продвинутые оптимизации" это превратилось на просторах интернета в факт, бездоказательный.
И как я понял - это заодно и делает синтаксис довольно закорючным.
> Или Rust умеет проверять переполнение float?
Да без понятия, я не растаман так то. Но float вообще большая проблема с точки зрения надежности и предсказуемости всего этого. Более того - чтобы все это было, надо хотя-бы какие-то жесткие стандарты определить, для всех краевых случаев, гарантированной точности и проч. Что начинает клещиться с умениями разнообразного железа. С точки зрения системщины и надежности плавучка проблемный топик. Ряд стандартов безопасности типа MISRA прямым текстом запрещает использование таковой по этим причиным.
