Pull to refresh
35
0
Тимур Сафин @tsafin

Пользователь

Send message

Да, Луа мог быть тут хорошим и сильно более экономным движком. IIRC, Vanilla Lua по тестам выигрывал на холодном старте у больших и маленьких скриптов. LuaJIT был не хуже на прогретом кеше, всё еще отъедая в десятки-сотни раз меньше чем изолят V8. Но, когда аналитики знают JS, и не знают Lua у вас по сути не остаётся другого выбора...

Вставляли double или int'ы? Правильно ли мы понимаем, что каждая вставка — это сортировка массива из 100 элементов?

Народ спрашивает: а какое количество вставок/сек в итоге вывозит summary коллектор?

внимание вопрос: чем отличается скрайбить от протоколировать?

Пока непонятно к чему вы ведете, вступление затянулось. Правильно ли я понимаю, что Simics таки умеет в режиме lockstep гонять с каким-нибудь coho/keiko трассы?


Еще вопрос, правильно ли я понял, что у вас так и не появился многопоточный режим исполнения, так как вы не знаете как сохранить детерминизм в этом случае? (Ну и кажется я припоминаю, что виртуализацию вы умели использовать для разгона симуляции, а если есть виртуализация, то и нет точного детерминизма, тогда непонятно почему также не сделать и с многопоточкой?)


И пока далеко не ушли — таки придумали правильный формат многопроцессорных трасс, или по-прежнему гоняем однопроцессорные LIT-ы?

худший был у М[umps]

Ну что вы начинаете то? Хорошо же общались :)


P.S.
Как я Вас понимаю — односимвольный вариант синтаксиса МАМПСа, пожалуй, иногда хуже APL может показаться


P.P.S.
Хотя, нет, APL придумали инопланетяне и его реально не понять.

(Раз пошла такая пьянка, то)


Вот старые Microsoft SAL аннотации для описания ограничений у параметров библиотеки были вполне читабельными, без введения нового языка ("закорючек") https://docs.microsoft.com/en-us/cpp/code-quality/understanding-sal


Но как-то дальше prefast чекера у драйверов эксперимент не пошел. А зря. IMVHO.

???


Тут такое дело. Ада — паскалеподобный язык, в нем такие же "кривые" begin-end блоки

А что конкретно вам из него нужно чего нет в существующих крейтах на чистом Расте?

Тут есть маленькая проблема — Раст. Мне не нужен чистый Раст, я не религиозен, если есть решение на Си, Си++ или даже Фортране, я их принесу в билд систему и слинкуюсь.


И, вообще, я Си/Си++ программист (ну или ментально остаюсь таковым, несмотря на обстоятельства). Мне Раст никак пока не релевантен. Хотя вот Cranelift, конечно, очень интересный проект и хотелось бы поиграться, ну или вон ripgrep можно было бы прилинковать. Хотелось бы, если бы принесение Раст кода в Си++ проект не было бы такой болью (я так и не понял всего объема отжимания в Firefox).


С другой стороны, в Расте есть одно важное преимущество — Cargo. И было бы замечательно, если бы при помощи Cargo можно было бы легко замешивать C/C++ и Раст код. Чтобы он хидера в обе стороны генерировал, чтобы слинковать в один проект без боли можно было бы (путь и для простого проекта). Это стало бы реально инструментом, объединившем оба (3) сообщества.

интересно, а много таких Си++ библиотек уже в крейты сконвертировано? А Boost можно? ;)


чтобы


cargo install boost-cxx

И, чтобы два раза не вставать, давайте я проговорю мою точку зрения, за которую я топил в Си++-сообществе?


Раст-сообщество не конкуренты, а дополнение Си/Си++ сообщества. Они не изобретают тулинг на пустом месте (как делают гошники), binutils те же, отладочная информация та же, линкер и LTO тот же самый, отладчики те же. Нет ни одной причины (ну разве кроме агрессивности RESF) относится к ним как к чему-то чужеродному.


Раст надо считать третьим компонентом в "C/C++-community". Со временем, если он научится жить в мире (и переключит внимание RESF на что-то более полезное) мы будем писать "C/C++/Rust — community".


P.S.
И раз у нас есть уже LTO межязыковое, давайте уже к Cargo чисто C++ модули приделайте?

extern "C" на отдельной функции в Си++ ничего не меняет — calling convention тот же самый (только имя символа поменяется)

И раз уж тут собрался цвет Си++/Раст сообщества давайте разберем тот давнишний пример из рассказа Антона на Си++Раша — https://godbolt.org/z/keDEZG


Я бы ожидал видеть идентичный код, сгенерированным одинаковым LLVM бекэндом, и код почти идентичен, но не совсем. В Расте зачем-то RAX спилят в стек и в конце вытаскивают в RCX. Причем этого не делается, если убрать цикл. Кажется, что тут какой-то Rust-специфик баг в годогенераторе LLVM, но не понимаю, чего вообще тут хотят добиться этим спиллингом регистра? (Так как ABI Си-шных функций одно, на одной платформе, и делать чего-то дополнительного, относительно Си++ не надо)


Что я упускаю?

Сначала маленькая заметка


Так откуда взялись эти "лишние" инструкции, которые трогают память? Соглашение о вызове функции x86-64 требует, чтобы стек был выравнен до 16 байт, инструкция call кладёт 8-байтовый адрес возврата на стек, что ломает выравнивание.

x64 API не требует выравнивания стека на 16, это 64-битная платформа, стек 64-битный. Здесь мы видим пару push/pop не для выравнивания стека (для этого была бы арифметика с rsp), а для сохранения регистра rbx, который вызываемая функция может менять.

А chaals продолжает взаимодействовать с Яндексом?

Очень, очень странно — похоже на проблему с базой(ами) intellisense. А что будет, если после выхода из VSCode удалить подкаталоги .vs* в корне проекта, и перезапустить VSCode?

Хороший вопрос — я еще не экспериментировал с тем, насколько динамическая диспетчеризация свойств будет прозрачно экспортироваться в SQL (и будет ли вообще, без экспорта метаданных в SQL компилятор). Надо поиграться.


Но есть подозрение, что ничего не получится.


@eduard93, adaptun, DAiMor, что думаете?

Хмм. Имеешь ли ты в виду случай с закавыченными именами? (О котором я сказал) Или именно без кавычек с пробелами и знаками препинания?

Information

Rating
Does not participate
Date of birth
Registered
Activity