DB
И кстати, тогда уж линковку нужно параллелить, а не компиляцию...
Size: a a a
2020 December 18
VS
наверное инкрементальная сборка больше для быстрой итерации, а полная мощь оптимизации для финальной сборки? они немного противоречат друг другу
Логично. Ну нам пожаловались на вариант, где сама по себе сборка нормальная, а в режиме "вся программа" слишком долгая.
h
Кстати. Тут вот ещё такое дело. А NaN-Boxing вообще возможно реализовать с дистрибутивным байт-кодом? Просто туда же указатели записывают...
BD
Логично. Ну нам пожаловались на вариант, где сама по себе сборка нормальная, а в режиме "вся программа" слишком долгая.
LTO очевидно медленнее, там вместо просто топологической сортировки символов надо делать и _всякое другое_
VS
LTO очевидно медленнее, там вместо просто топологической сортировки символов надо делать и _всякое другое_
Ага. Оптимизации. Которые обходят весь код. И не всегда с линейной сложностью.
AT
NaN-Boxing = всё—double
OK, NaN-boxing позволяет хранить (32-bit) integer в виде 2-complement последовательности бит прямо внутри "технически double" значения. Этот "скрытый int" мы "декодируем" методом
void *p = (void *)(&nan_boxed_int);Плюс-минус endianness. Ну или битовая арифметика по вкусу. Никакие инструкции для приведения double к int не нужны.
int32_t i = *(int *)(p + 4);
AT
ну. внутри то да. но разве перед этим не придется забокшеный double в int преобразовать?
^
AT
наверное инкрементальная сборка больше для быстрой итерации, а полная мощь оптимизации для финальной сборки? они немного противоречат друг другу
Performance engineering. 😞
PS
Инкрементальная сборка не в помощь?
На c++ это реально боль. Регистрируешь пасс в llvm и жди 2000 таргетов или pytorch где cmake вообще почти без библиотек, все собирается из огромного списка cpp-файлов, поменял один header и можешь идти обедать или даже ужинать.
BD
Performance engineering. 😞
ну это же область где по определению надо страдать, не?
h
OK, NaN-boxing позволяет хранить (32-bit) integer в виде 2-complement последовательности бит прямо внутри "технически double" значения. Этот "скрытый int" мы "декодируем" методом
void *p = (void *)(&nan_boxed_int);Плюс-минус endianness. Ну или битовая арифметика по вкусу. Никакие инструкции для приведения double к int не нужны.
int32_t i = *(int *)(p + 4);
А. Каст неправильно называть конверсией?)) Хмм
AT
Кстати. Тут вот ещё такое дело. А NaN-Boxing вообще возможно реализовать с дистрибутивным байт-кодом? Просто туда же указатели записывают...
NaN-boxing в VM, а не в бат-коде. 🤷♀️
PS
без модулей, без цмака, без нинзи - одними автотулсами и ужасным precompiled header-ом
Да даже со смаком и ниньзей. Ещё вопрос как этот смак написан
BD
А. Каст неправильно называть конверсией?)) Хмм
reinterpret cast ничего не конвертирует
DB
Pavel Samolysov
На c++ это реально боль. Регистрируешь пасс в llvm и жди 2000 таргетов или pytorch где cmake вообще почти без библиотек, все собирается из огромного списка cpp-файлов, поменял один header и можешь идти обедать или даже ужинать.
-DBUILD_SHARED_LIBS=On -DLLVM_ENABLE_TARGETS="...", etc. и покушать не получится.
BD
Pavel Samolysov
Да даже со смаком и ниньзей. Ещё вопрос как этот смак написан
для плюсовых проектов самая большая боль это зависимости между хедерами - можно поменяв одну букву заставить пересобираться вообще весь проект полностью
AT
А. Каст неправильно называть конверсией?)) Хмм
Я не понял, что Вы называете кастом, а что — конверсией?
h
NaN-boxing в VM, а не в бат-коде. 🤷♀️
Но я пока видел только боксинг при записи в констант пуле
PS
-DBUILD_SHARED_LIBS=On -DLLVM_ENABLE_TARGETS="...", etc. и покушать не получится.
А если весь проект одна огромная шареная либа собирается из obj list или как оно там в смаке?
AT
Но я пока видел только боксинг при записи в констант пуле
И откуда у Вас там указатели берутся, если Вы его на этапе компиляции формируете?