Открыть список
Как стать автором
Обновить

Комментарии 14

А c++ так нельзя? Куча примеров как из go вызвать спп. А наоборот? Задача: из библиотеки спп вызвать метод библиотеки go. Так можно?

С этим сложнее.


В последний раз у меня такая задача была года 3 назад и вроде бы отчасти решалось через компиляцию Go в c-archive.


Но гораздо надёжнее (если это возможно) инверсировать поток управления и сделать runtime Go основным, а C++ код уже оттуда использовать. Именно поэтому примеров такого подхожа и больше, сделать это корректно попроще, чем встроить Go в другое приложение. :)

Если бы. Это 1С со своими правилами. Под спп писать тяжко. А под го проще. Похоже моя идея обернуть го сервис в http. И из спп дёргать его обретает все больше смысла. Много видел меж поточного взаимодействия. Здесь это тоже не поможет?

лучше в grpc, если go умеет

Все аргументы передаются на стеке? Но зачем? Это же супермедленно!
Это же супермедленно!

Это действительно не самое оптимальное решение, но регистровая CC пока не дала прироста больше 5-10% на (синтетических) тестах, что неплохо для более-менее зрелого компилятора, но не так супер много, чтобы бить тревогу. :)


Ознакомьтесь, пожалуйста, с register-based CC for Go и internal calling convention. Эти ссылки затрагивают как историю, так и потенциальное будущее.


Go's calling convention as of Go 1.11 is simple and nearly universal across platforms, but also inefficient and inflexible. It is rife with opportunities for improving performance. For example, experiments with passing arguments and results in registers suggest a 5% performance win.

(Ниже только субъективные догадки.)


Видимо, простота для реализации и универсальность на большом количестве платформ. была достаточно хорошей причиной. Там не только даже в компиляторе дело, у Go есть GC и ему надо уметь работать с "локальными" данными (регистры и стек), чем сложнее логика CC и чем более она разная между платформами, тем сложнее будет реализация (или придётся больше платформозависимого кода писать). Рантайму, возможно, тоже проще с трейсами работать.

Если передавать аргументы через стек, то переключаться между горутинами будет проще.

Переключение горутин. Сохранение и восстановление регистров то же не бесплатное.

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


Регистровые аргументы намного быстрее только для очень маленьких функциях и в очень частных случаях, когда можно отдельным регистрам присвоить предназначение и не менять его на протяжение длинного участка кода (одного или несколько вложенных циклов) и при этом сама функция нельзя просто заинлайнить.

Ну, пока рассматривается amd64, бесспорно, все эти игры с регистрами особого смысла не имеют.

Я бы сказал – пока регистры ограниченное количество. А это так для всех процессоров и архитектур.

Большое спасибо за статью. Было полезно и саму статью прочитать и по ссылкам пройти.

Правильно ли я понимаю что старый ABI оставят только для ассемблерных функций?
Правильно ли я понимаю что старый ABI оставят только для ассемблерных функций?

По обсуждениям похоже на то, что как минимум планируется дать возможность указать у Go функции её ABI через магический комментарий (//go: прагму). Но я могу что-то упустить, там многовато сообщений. :)


Но для ассемблерных функций точно будет по умолчанию старый. Когда появится ABI1, видимо, его можно будет проставить через флаги ассемблерной функции.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.