Конечно могут, регистр это просто данные. Да, нет инструкций для переходов по данным из SSE/AVX регистров,но если вам нужно копировать / передавать кучу удвоенных указателей - это возможно через векторные регистры. Правда есть вопросы на сколько часто это приходится делать и вообще есть ли в этом смысл.
Мне кажется вы вообще как-то зациклены на одном конкретном ABI, хотя вроде как новый язык делаете и казалось бы что мешает вам завести свой собственный с преферансом и танцовщицами. Тот же раст так и делал, не знаю как сейчас, но раньше у него вообще стабильного ABI не было.
Да, я тут глянул в godbolt.org е на вопрос передачи объекта за интерфейсом в расте, и что то я двух указателей не вижу, у вас есть пример? Мне кажется что вы как-то смешали передачу указателя на объект с вызовом интерфейса объекта.
Вызов метода - это вообще всегда переход в другую часть кода.
Кстати, удвоение размера каждого указателя в программе - это рост размера данных и сделовательно рост количества кеш-промахов, который, в зависимости от связанности структур данных может доходить до 200%. Поэтому подход с двойными указателями с кешем не дружит.
У вас два перехода, так что накладные расходы удваиваются. Увеличение размера указателя на промахи данных не влияет, данные последовательные и или уже подняты в кеш линию, либо будут подняты предсказателем, это он умеет очень хорошо. Единственное на что размер указателя мог бы влиять это на исчерпание кеш линий, но это нужно столько указателей что то не практично
Код загружаемый из DLL должен следовать соглашениям ABI платформы. Я пока не видел ABI, стандартизирующий вызов виртуальных методов. Поэтому правильно написанная DLL/o не должна выставлять наружу ООП API, если не хочет зависимости от конкретной версии компилятора с конкретными настройками сборки.
Ну во первых это не так, код из длл не обязан следовать никаким соглашениям, это вопрос того как заранее договорятся библиотека и приложение. Ну и не секрет что да, многие программы особенно из под MSVC имеют проблемы с тем, что они собраны не той версией, однако внутри версии они не имеют проблемы что я могу загрузить полностью валидный код который положит мою программу.
P.S. В принципе это всё теоритезирования, что на самом деле быстрее показать может быть только замер, но разумеется сделать его корректно не просто.
Rust, Go и Swift выигрывают эти четыре инструкции в операции вызова, но проигрывают по две инструкции в каждой операции передачи, сохранения и загрузки ссылки из-за ее удвоенного размера. А эти операции выполняются чаще чем вызов.
тут не очевидный баланс, копирование двух указателей уже на SSE будет одной инструкцией, с другой стороны вызов у вас происходит через диспечеризатор, который не только несколько инструкций, но и переход в другую часть кода с потерей кеша инструкций
И не понятно что с кодом загружаемым из dll, какие там будут id ?
«Движение подвижных динамических объектов в виртуальном пространстве контролируется расчётами, а движение персонажа игрока — пользовательским вводом. Когда персонаж и объект соприкасаются в направлении вниз относительно персонажа (другими словами, когда персонаж находится поверх объекта), движение динамического объекта добавляется к движению персонажа».
Еще как удивительно, ведь уделать numpy по производительности на вашем примере задача тривиальная, попробуйте написать то же самое с использованием Blaze или на Julia и будете приятно удивлены
Важно сколько потребляют а не производят. Аккумуляторные станции весьма востребованы т.к. сглаживают пики и просадки потребления. Ну и это практически прототип, если покажет себя хорошо тогда его будут масштабировать.
что значит "фейлится"? кидает исключение? возвращает спец значение? вызывает спец функцию?
Ну тогда социальный рейтинг надо было назвать "Быдло"
лучше писать на баше чем трогать питона
Нет никаких проблем пробросить нужные устройства внутрь контейнера. В тяжелых случаях поможет баш скрипт.
действительно, ведь учить дельфи для гуя это именно то, что нужно новичку в питоне
Это называется алгебраические типы данных (algebraic data types) и есть несколько библиотек которые их реализуют
7нм делаются на DUV, зачем придумывать сказку о новом оборудовании? SMIC конечно молодцы, хорошо освоили купленное оборудование
нельзя, в франшизе McDonalds прописано использовать только Taylor, а менять старый на новый это деньги на ветер, и не маленькие
Конечно могут, регистр это просто данные. Да, нет инструкций для переходов по данным из SSE/AVX регистров,но если вам нужно копировать / передавать кучу удвоенных указателей - это возможно через векторные регистры. Правда есть вопросы на сколько часто это приходится делать и вообще есть ли в этом смысл.
Мне кажется вы вообще как-то зациклены на одном конкретном ABI, хотя вроде как новый язык делаете и казалось бы что мешает вам завести свой собственный с преферансом и танцовщицами. Тот же раст так и делал, не знаю как сейчас, но раньше у него вообще стабильного ABI не было.
Да, я тут глянул в godbolt.org е на вопрос передачи объекта за интерфейсом в расте, и что то я двух указателей не вижу, у вас есть пример? Мне кажется что вы как-то смешали передачу указателя на объект с вызовом интерфейса объекта.
У вас два перехода, так что накладные расходы удваиваются. Увеличение размера указателя на промахи данных не влияет, данные последовательные и или уже подняты в кеш линию, либо будут подняты предсказателем, это он умеет очень хорошо. Единственное на что размер указателя мог бы влиять это на исчерпание кеш линий, но это нужно столько указателей что то не практично
Ну во первых это не так, код из длл не обязан следовать никаким соглашениям, это вопрос того как заранее договорятся библиотека и приложение. Ну и не секрет что да, многие программы особенно из под MSVC имеют проблемы с тем, что они собраны не той версией, однако внутри версии они не имеют проблемы что я могу загрузить полностью валидный код который положит мою программу.
P.S.
В принципе это всё теоритезирования, что на самом деле быстрее показать может быть только замер, но разумеется сделать его корректно не просто.
тут не очевидный баланс, копирование двух указателей уже на SSE будет одной инструкцией, с другой стороны вызов у вас происходит через диспечеризатор, который не только несколько инструкций, но и переход в другую часть кода с потерей кеша инструкций
И не понятно что с кодом загружаемым из dll, какие там будут id ?
«Движение подвижных динамических объектов в виртуальном пространстве контролируется расчётами, а движение персонажа игрока — пользовательским вводом. Когда персонаж и объект соприкасаются в направлении вниз относительно персонажа (другими словами, когда персонаж находится поверх объекта), движение динамического объекта добавляется к движению персонажа».
это они лифт запатентовали что-ли?
Ну а специалисты возрастом от 27 до 30 могут сразу покупать путёвки в другие страны, если они не хотят бесплатную путёвку в один конец.
Еще как удивительно, ведь уделать numpy по производительности на вашем примере задача тривиальная, попробуйте написать то же самое с использованием Blaze или на Julia и будете приятно удивлены
У вас в статье опечатка, или рельно С++ версия сильно медленнее питона?
Претензии на AVX есть, но внутри для этого ничего нет, так что оптимизации там постольку-поскольку. numpy этим увы тоже страдает.
BlazeCpp гораздо быстрее и удобнее вашего np.
Вообщем импортозамещение в его классическом представлении.
На практике - берите Julia и забейте на плюсы, даже с крутейшим Blaze писать математику на плюсах все равно сложно и муторно.
F
А есть формальное доказательство что программа на rust переписанная и верифицированная в coq является верифицированной и на rust ?
Если бы было проще в глубину то все бы строили в глубину.
Важно сколько потребляют а не производят. Аккумуляторные станции весьма востребованы т.к. сглаживают пики и просадки потребления. Ну и это практически прототип, если покажет себя хорошо тогда его будут масштабировать.
Ну предположим код стал меньше, но как это сказалось на производительности?
Ничего себе "не критично"
Было холодно.