То что компилятор, транспайлер, обфускатор и т.п. отработали как надо — это даже не обсуждается. Конечно, для разработчика обременённого корпоративными правилами с кругами тестировщиков может быть удобнее в каждую функцию насовать по 100 проверок, только в конечном итоге это приводит к раздутым и тормозящим приложениям. Которые, зачастую, и глючат в придачу.
Подход «Хрустальный код» можно пприменять только тогда, когда ему следуют все участники разработки. И при абсолютно идеентичной исполнимой среде. И когда при падении ничего критичного для бизнеса не происходит.
Смотрите, в скомпилированной программе код практически всегда исполняется предсказазуемо, а вот на клиенте, да ещё и в интерпретируемом языке, который на разных версиях интерпретаторов исполняется, конечно, нужно обрабатывать как можно большее число ошибок.
При компилированном коде уже один лишний if в «горячем цикле» портит производительность. А во фронте это не так важно.
Фронт — это вообще отдельное царство, где у каждого пользователя свой браузер, разных версий. Не говоря о том, что пользователи могут любой бред вводить.
Спасибо за найденную неточность!. Идея была в том, что какие-то проверки кроме самих проверок могут делать что-то с данными. Делать их «корректнее». Например nil преобразовать в 0. Потом куда-то ещё передать результат построенный на неверном входе. И поэтому потеряется изначальная ошибка. И найти её будет невероятно трудно.
Спасибо за найденную неточность. Важно чтобы только ПЕРВЫЕ 10 лет убывали по важности в 2 раза.
А дальше нужно более плавное стремление к нулю, чтобы "классика" обесценивалась очень медленно.
Функция выбрана таким образом, чтобы быстрее всего инфляция была вначале, а потом замедлялась. Аналогия — классика в литературе, значение которой падает, но настолько медленно, что это совершенно незаметно.
А для этого лучше подходит арктангенс, так как у него более тяжелые "хвосты".
"Колокол" производной логистической функции более "сосредоточен" и имеет более тяжелую верхнюю часть и легкие хвосты. "Колокол" производной арктангенса (распределение Коши) более "расплывчат", имеет более тяжелые хвосты, что соответствует его медленному стремлению к нулю.
Не помню, говорил я это или нет. Но если в Hyper-V есть поддержка Huge Pages, то это может здорово помочь. Но Huge Page исключает переподписку по памяти.
В моём примере речь не идёт об одной и той же переменной. В первом случае - это указатель на переменную, на которую выделяет память конструктор, который не является локальной функций по отношению к той функции из которой он вызывается.
А во втором случае - сама переменная. Иногда Го оптимизирует и выделяет на стеке. А иногда нет.
В версиях Go 1.24 и 1.25, когда мы подсказываем компилятору как правильно сделать, с большей вероятностью он сделает правильно.
Но если указатель был занят, то новую память компилятор точно выделит в куче. Хотя в теории мог бы и на стеке.
func NewFfModInt(v uint64) *FfMod {
z := FfMod{v}
return &z
}
func (r *FfMod) Inverse(x *FfMod) *FfMod {
r = NewFfModInt(0) // происходит аллокация
......
}
что проверок на выход за границу массива ГО не делает
К сожалению, при дизассемблировании я видел, что проверки делаются. Если обращение идёт по случайному индексу, не в рамках for.
Впрочем, ГО и тут продует и Фортрану и стеку С/С++ "на раз".
Возможно, мне стоит перенести свой оптимизирвоанный код Го на C++. Будет приколько, если я дооптимизировал до того, что переплюну супероптимизированную С++ версию (от JLP).
Интересное замечание. Есть что-то типа каналов в современном Фортране, чтобы писать многопоточный код? Вообще многопоточность гибкая или нужно на каждый поток одинаковый блок выделять, а потом с геморроем собирать конечный результат?
То что компилятор, транспайлер, обфускатор и т.п. отработали как надо — это даже не обсуждается. Конечно, для разработчика обременённого корпоративными правилами с кругами тестировщиков может быть удобнее в каждую функцию насовать по 100 проверок, только в конечном итоге это приводит к раздутым и тормозящим приложениям. Которые, зачастую, и глючат в придачу.
Подход «Хрустальный код» можно пприменять только тогда, когда ему следуют все участники разработки. И при абсолютно идеентичной исполнимой среде. И когда при падении ничего критичного для бизнеса не происходит.
Ссылку приведите, интересно
Браузер — это просто среда исполнения.
Смотрите, в скомпилированной программе код практически всегда исполняется предсказазуемо, а вот на клиенте, да ещё и в интерпретируемом языке, который на разных версиях интерпретаторов исполняется, конечно, нужно обрабатывать как можно большее число ошибок.
При компилированном коде уже один лишний if в «горячем цикле» портит производительность. А во фронте это не так важно.
Фронт — это вообще отдельное царство, где у каждого пользователя свой браузер, разных версий. Не говоря о том, что пользователи могут любой бред вводить.
Спасибо! Добавлено.
Спасибо за найденную неточность!. Идея была в том, что какие-то проверки кроме самих проверок могут делать что-то с данными. Делать их «корректнее». Например nil преобразовать в 0. Потом куда-то ещё передать результат построенный на неверном входе. И поэтому потеряется изначальная ошибка. И найти её будет невероятно трудно.
Спасибо за найденную неточность. Важно чтобы только ПЕРВЫЕ 10 лет убывали по важности в 2 раза.
А дальше нужно более плавное стремление к нулю, чтобы "классика" обесценивалась очень медленно.
Функция выбрана таким образом, чтобы быстрее всего инфляция была вначале, а потом замедлялась. Аналогия — классика в литературе, значение которой падает, но настолько медленно, что это совершенно незаметно.А для этого лучше подходит арктангенс, так как у него более тяжелые "хвосты".
"Колокол" производной логистической функции более "сосредоточен" и имеет более тяжелую верхнюю часть и легкие хвосты. "Колокол" производной арктангенса (распределение Коши) более "расплывчат", имеет более тяжелые хвосты, что соответствует его медленному стремлению к нулю.
Об этом и говорит автор поста. Что проблемы нпчинаются, когда число ядер у всех работающих вм больше, чем на хосте.
Не помню, говорил я это или нет. Но если в Hyper-V есть поддержка Huge Pages, то это может здорово помочь. Но Huge Page исключает переподписку по памяти.
Таблицы TLB должны быть нормальными у Эпик.
Я этот пример привёл потому, что исследовал его. Именно его. Аллокация происходит.
По логике её можно не делать. Указатель r и так аллоцирован. Можно его перезаписать. Но компилятор аллоцирует.
В моём примере речь не идёт об одной и той же переменной. В первом случае - это указатель на переменную, на которую выделяет память конструктор, который не является локальной функций по отношению к той функции из которой он вызывается.
А во втором случае - сама переменная. Иногда Го оптимизирует и выделяет на стеке. А иногда нет.
В версиях Go 1.24 и 1.25, когда мы подсказываем компилятору как правильно сделать, с большей вероятностью он сделает правильно.
Но если указатель был занят, то новую память компилятор точно выделит в куче. Хотя в теории мог бы и на стеке.
Я знаю, что не одно и тоже. Но у них скорости условно одинаковые.
Инверсия в конечном поле - это не просто "операция", это довольно тяжёлый алгоритм.
К сожалению, при дизассемблировании я видел, что проверки делаются. Если обращение идёт по случайному индексу, не в рамках for.
Возможно, мне стоит перенести свой оптимизирвоанный код Го на C++. Будет приколько, если я дооптимизировал до того, что переплюну супероптимизированную С++ версию (от JLP).
Насчёт инлайнов. Если в маленькой функции не используется ничего из модулей, то Го хорошо инлайнит
Грубо говоря, если вы пишете конвертатор png в jpg, то можно вытянуть хорошую скорость из Го, если заморочиться.
Спасибо за комментарий. Речь в статье шла о вычислительно сложной задаче, а не о каналах и сетевых технологиях. Конкретно об инверсии.
Чтобы избежать проверок границ использовались слайсы с чётко заданными границами типа [4]byte.
Естественно, никаких интерфейсов и defer - без которых вполне можно обойтись.
НУ и без мапов. Мапы же используют аллокации.
Возможно следует написать продолжение с разъяснениями этих моментов.
Если в очень горячих местах кода, то улучшения заметные. А эта функция сравнения она часто используется для приведения по модулю.
Я об этом статье не написал, но очень сильный выигрыш дало прямое логическое условие. В горячем IF. Буквально процентов 20.
Было
if !булева_функция
Стало
if булева_функция
Интересное замечание. Есть что-то типа каналов в современном Фортране, чтобы писать многопоточный код? Вообще многопоточность гибкая или нужно на каждый поток одинаковый блок выделять, а потом с геморроем собирать конечный результат?
Полностью убрать отладочную информацию
go build -ldflags="-w -s" main.go
Только без символов отладки
go build -ldflags="-s" main.go
Только без DWARF информации
go build -ldflags="-w" main.go
Я не писал код на С++. Я взял мегаоптимизированную версии от Jean Luk Pons. И сравнивал свои результаты с ней.
Я оптимизировал функцию инверсии и достиг 97% производительности от C++ версии. Об этом есть в конце статьи.
По сути, если избежать аллокаций, то Го такой же компилируемый язык как и Си или Си++.