Накладные расходы на псевдоним типа в Go

Я пишу vector.go как часть своей программы. Он предоставляет трехмерную структуру vector и некоторые векторные операции.

Для симметрии с общим типом vector я хотел бы предоставить тип scalar:

type scalar float64

Мне это нравится, потому что нет причин, по которым я должен каждый раз указывать точность моих скаляров. Тот факт, что они 64-битные, — это деталь, которую я хотел бы уточнить только один раз.

Единственная проблема в том, что я знаю, что это не похоже на typedef в C. Кажется, за кулисами происходит нечто большее, чем это. Мой вопрос: повлечет ли это какие-либо накладные расходы? Если да, то когда и сколько? Могу ли я использовать это, когда производительность абсолютно критична? (Предположим, что я заменю каждое вхождение float64 на scalar и преобразую литералы, например, scalar(1.0).)


person mk12    schedule 09.07.2013    source источник


Ответы (1)


Во-первых, нет необходимости преобразовывать литералы. x = 1.0 совпадает с x = scalar(1.0) при условии, что x уже имеет скалярный тип.

В Go нет такой вещи, как пользовательский псевдоним типа. В Go byte и uint8 (которые являются встроенными типами) считаются псевдонимами друг друга. Это два названия одного и того же типа. Float64 и скаляр не являются одним и тем же типом. Значения float64 и scalar необходимо преобразовать друг в друга, используя что-то вроде s = scalar(f), а byte и uint8 — нет.

Однако такие преобразования не имеют накладных расходов. Типы применяются во время компиляции для корректности кода, но не влияют на производительность во время выполнения. Выполнение затрагивается только в том случае, если вы вводите утверждения или используете отражение. Однако эти различия влияют на логику, а не на производительность.

Могу ли я использовать это, когда производительность абсолютно критична?

Да

person Stephen Weinberg    schedule 09.07.2013
comment
Спасибо. В буквальном смысле я больше думал о x := scalar(1.0) (или, что то же самое, var x scalar = 1.0), чтобы предотвратить вывод 1.0 как числа с плавающей запятой64. - person mk12; 09.07.2013