В моём примере речь не идёт об одной и той же переменной. В первом случае - это указатель на переменную, на которую выделяет память конструктор, который не является локальной функций по отношению к той функции из которой он вызывается.
А во втором случае - сама переменная. Иногда Го оптимизирует и выделяет на стеке. А иногда нет.
В версиях 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).
Интересное замечание. Есть что-то типа каналов в современном Фортране, чтобы писать многопоточный код? Вообще многопоточность гибкая или нужно на каждый поток одинаковый блок выделять, а потом с геморроем собирать конечный результат?
Из-за спекулятивной и частично параллельной природы вычислений на конкретном ядре некоторые инструкции обрабатываются параллельно. ЛОгично предположить, что частота CPU - это и есть частота конвеера. Маркетологи врядди бы такое упустили.
А не может ли быть такое, что 4.3ГГц - это частота конвеера CPU. А тактов как раз в 2 раза меньше? ТОгда всё верно. Хотя я слышал, что есть команды, которые до 7 тактов конвеера выполняются.
В первом случае типовой конструктор отдаст указатель, на который будет выделена память из кучи. А выделяется она в конструкторе, который, совершенно не факт, что будет инлайниться. Поэтому 99%, что это будет именно память из кучи.
Про второй случай в статье оговорено, что указатель не должен утекать
Сначала внимательно научись читать фразы оппонентов: "Ну не досмотрел Линус, одного с русским емейлом пропустил."
Из твоей троицы ни у кого нет емейла в зоне .ru.
И это не статистика.
Статистика: В 2021 году было патчей от адресатов в зоне .ru - 368 В 2025 - 1.
Цифры я взял с потолка. Но если хочешь победить в споре, то без статистики не получится.
А я считаю, что ты хам, аноним, тролль и примитивный манипулятор. Пытаешься вложить в мои уста то, чего я не говорил.
А раз на вопросы про эмиграцию и про отношение к санкциям против России не ответил, то, скорее всего, ты - враг нашей страны, которая считает, что она во всём всегда виновата. И должна "платить и каяться".
В моём примере речь не идёт об одной и той же переменной. В первом случае - это указатель на переменную, на которую выделяет память конструктор, который не является локальной функций по отношению к той функции из которой он вызывается.
А во втором случае - сама переменная. Иногда Го оптимизирует и выделяет на стеке. А иногда нет.
В версиях 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++ версии. Об этом есть в конце статьи.
По сути, если избежать аллокаций, то Го такой же компилируемый язык как и Си или Си++.
Из-за спекулятивной и частично параллельной природы вычислений на конкретном ядре некоторые инструкции обрабатываются параллельно. ЛОгично предположить, что частота CPU - это и есть частота конвеера. Маркетологи врядди бы такое упустили.
А не может ли быть такое, что 4.3ГГц - это частота конвеера CPU. А тактов как раз в 2 раза меньше? ТОгда всё верно. Хотя я слышал, что есть команды, которые до 7 тактов конвеера выполняются.
return с булевой функцией?
https://en.wikipedia.org/wiki/Time_Stamp_Counter
The Time Stamp Counter (TSC) is a 64-bit register present on all x86 processors since the Pentium. It counts the number of CPU cycles since its reset.
Можешь доказать?
В первом случае типовой конструктор отдаст указатель, на который будет выделена память из кучи. А выделяется она в конструкторе, который, совершенно не факт, что будет инлайниться. Поэтому 99%, что это будет именно память из кучи.
Про второй случай в статье оговорено, что указатель не должен утекать
Не проводят они никаких расследований. Это "розовые очки". Пишут отписки и по запросу включают в БД из которой хрен выберешься
вы хотите сказать что банки исполняя 161-ФЗ чтото выдумывают от себя?
Банки выдумывают. И об этом есть в статье. Вводят ограничения о которых ни сном, ни духом нет в законе. Запрещают использовать кредитные средства.
Запрет на приём переводов, например. Или на размер внесения наличных. У Тбанка ещё и наличные снять нельзя.
Сначала внимательно научись читать фразы оппонентов: "Ну не досмотрел Линус, одного с русским емейлом пропустил."
Из твоей троицы ни у кого нет емейла в зоне .ru.
И это не статистика.
Статистика:
В 2021 году было патчей от адресатов в зоне .ru - 368
В 2025 - 1.
Цифры я взял с потолка. Но если хочешь победить в споре, то без статистики не получится.
А я считаю, что ты хам, аноним, тролль и примитивный манипулятор. Пытаешься вложить в мои уста то, чего я не говорил.
А раз на вопросы про эмиграцию и про отношение к санкциям против России не ответил, то, скорее всего, ты - враг нашей страны, которая считает, что она во всём всегда виновата. И должна "платить и каяться".
Ну не досмотрел Линус, одного с русским емейлом пропустил. Занятой человек.
Сравни сколько раньше с русскими почтами коммитов было и сейчас.
Ты, наверное, эмигрант или поддерживаешь санкции против России?
И считаешь, что СССР был неправ с финнами? И что коммунизм также плох, как и фашизм?
Линус морально очень упал в том, что впустил западную русофобскую политическую повестку в разработку ядра.