Так аналитическое решение само по себе торт! Можно предельный переход сделать c → ∞ (спойлер: да, приходим к классическим формулам), можно g покрутить (чёрная дыра), или m занулить (нейтрино, фотон… ну тут конечно погорячился).
Прошу помощи зала: помнится, на Хабре было несколько похожих статей, где рассматривался вопрос поиска некоего алгоритма брутфорсом опкодов миниатюрной ВМ. Так вот, не могу найти статью, в которой рассказывалось, как искалась "программа", помещавшаяся в 64-битное число (внутри которого кодировались инструкции стековой машины в обратной польской нотации), собственно перебором всех 64-битных чисел. Может, кто-то помнит эту статью или хотя бы волшебные слова из неё?
Чиселка с деньгами — это чаще всего всё равно будет какой-нибудь uint64_t, хоть он внутри Integer внутри Object, хоть он внутри struct Wallet внутри struct MyCharacter. А значит, этот кусок памяти можно отыскать. Кроме того, состояние типа "money" обычно какое-то глобальное или по крайней мере не пересоздающееся постоянно, значит, сборщиком оно не разрушится (например, ссылка на "money" опосредованно должна быть у рендерера или у планировщика, пинающего рендерер).
Хороший разбор и примеры. Интересно, что материал неявно затрагивает ещё одну важную тему: SCEV Evaluation является прекрасным примером оптимизации, честно полагающейся на отсутствие UB (undefined behavior) в исходном коде. Мы применяем матаппарат на множестве целых чисел, чтобы вывести некоторые результирующие формулы, но они с большой вероятностью перестают работать, если допустить целочисленное переполнение на итерациях суммирования (однако, не исключено, что формулы справедливы в арифметике по модулю 2⁶⁴, например).
— не оторвётся ли случайно (или скорее наоборот останется) какой-нибудь слэш / в relative-пути, если передать path без завершающего слэша? Зависит, конечно, от того, как именно path доходит до сюда.
UPD: ну и в принципе смешивание std::string и fs::path для навигации звучит довольно взрывоопасно, вроде API fs должно хватать для всех GetRelative и т.д., но он ещё и нормализует пути.
Да, вот только не стоит забывать, что отсчёт у нас идёт от абсолютного нуля 0K (-273°C), поэтому радиатор 90°C излучает сильнее радиатора 20°C всего в ((273+90)÷(273+20))⁴ ~ 2.3 раза сильнее.
Не совсем так, для передачи энергии излучением достаточно просто разности температур и способности поглощать определённые длины волн. Все тела излучают (см. Закон Стефана — Больцмана), и примерно пропорционально ~T⁴, но другое дело, что входящие и исходящие потоки могут быть равны.
Но да, от проца до радиатора ПК больше тепла передаётся теплопроводностью, а от радиатора воздуху — конвекцией.
Справедливо. Звучит, правда, сложнее: раскрутить — затормозить — раскрутить обратно — повторить, новые потери энергии (и момента? — подъёмная сила же теперь в принципе не всегда по касательной к вращению будет), сложнее схема управления. В любом случае, считать надо.
3. А разве же ж тогда не придётся постоянно менять направление вращения цилиндров? Подъёмная сила сонаправлена векторному произведению угловой скорости цилиндра и потока воздуха.
Всё-таки не влезет. См. идею про "всё уже записано в числе пи" (Нормальное число). Проблема в том, что для кодирования смещения в таком бесконечном архиве нужно число с энтропией порядка самих закодированных данных.
Ну и вообще, для интересующихся советую познакомиться с понятием Колмогоровская сложность — очень расширяет сознание архиваторостроителям.
Странная анимация, что именно она иллюстрирует? Если это силовые линии электростатического поля точечного заряда в лабораторной системе отсчёта, почему после ускорения/рывка они остаются прямолинейными? (Хотя понаблюдал за конкретной точкой, может так и есть, после начала движения заряда градиент медленно поворачивается за зарядом с запозданием).
Если это силовые линии гравитационного поля, при движении по окружности возникали бы аналогичные искажения, градиент которых можно было бы уловить, но вроде как грав. волны рождаются только рывком массы, поэтому наверное иллюстрация всё-таки к электростатике.
UPD: увидел комментарий выше, таки это электрический заряд. Всё равно вопрос к форме поля, надо обдумать.
(This diagram assumes a charge moving at 0.5 times the speed of light, and includes a slight horizontal "squeezing" of the field lines due to relativistic length contraction. However, this squeezing is not essential to any of the subsequent discussion of electromagnetic radiation.)
Ну да, логично, искажения-то есть, но они очень малы даже для скорости заряда c/2.
Недавно залип здесь: https://jila.colorado.edu/~ajsh/insidebh/intro.html — разные рендеры с пояснениями. Правда, сам автор признаётся, что вращающиеся ЧД (Kerr) пока не запилены, но есть заряженные (Reissner-Nordström).
Заново изучил статью, преисполнился, соглашусь.
Про over-aligned типы такие идеи имеют место быть: помимо локальности и убирания косвенных обращений (что чаще всего хорошо из-за кэширований), иногда нам может быть полезно наоборот немного разнести данные в пространстве ("локальные, но чуть-чуть"), чтобы избежать false sharing. Например, это когда несколько потоков молотят один вектор, но каждый только свой элемент, но при этом постоянно инвалидируют ячейки соседей, просто потому что несколько ячеек попало в одну кэш-линию.
Во-первых, std::unique_ptr'у нельзя подсунуть аллокатор, а только deleter, поэтому не получится так просто его использовать, придётся действительно огородить свой operator new и связывать его с deleter'ом.
Как уже замечали выше, понятие "указатель на стеке" вводит в заблуждение, static_ptr о полиморфности со стиранием типа "на месте", т.е. как будто очень похож на std::[not_very_]any, хранящий только определённую иерархию классов, и с mandatory small-object-optimization (т.е. неаллоцирующий).
Почему-то прямо с порога некорректный ответ (
clang-trunk -O0):На
-O1и выше всё норм. UB таки стреляет?Для интересующихся — отличный перевод статьи 2018 года на Хабре про эту же технику:
Иллюзия пространства: как новый Spiderman рендерит помещения без геометрии
Так аналитическое решение само по себе торт! Можно предельный переход сделать c → ∞ (спойлер: да, приходим к классическим формулам), можно g покрутить (чёрная дыра), или m занулить (нейтрино,
фотон… ну тут конечно погорячился).Прошу помощи зала: помнится, на Хабре было несколько похожих статей, где рассматривался вопрос поиска некоего алгоритма брутфорсом опкодов миниатюрной ВМ. Так вот, не могу найти статью, в которой рассказывалось, как искалась "программа", помещавшаяся в 64-битное число (внутри которого кодировались инструкции стековой машины в обратной польской нотации), собственно перебором всех 64-битных чисел. Может, кто-то помнит эту статью или хотя бы волшебные слова из неё?
Чиселка с деньгами — это чаще всего всё равно будет какой-нибудь
uint64_t, хоть он внутриIntegerвнутриObject, хоть он внутриstruct Walletвнутриstruct MyCharacter. А значит, этот кусок памяти можно отыскать. Кроме того, состояние типа "money" обычно какое-то глобальное или по крайней мере не пересоздающееся постоянно, значит, сборщиком оно не разрушится (например, ссылка на "money" опосредованно должна быть у рендерера или у планировщика, пинающего рендерер).Френдлифаер круто, ещё и стратегию меняет: по функции, названной противником, можно сделать предположения, куда он не хочет попасть сам.
Хороший разбор и примеры. Интересно, что материал неявно затрагивает ещё одну важную тему: SCEV Evaluation является прекрасным примером оптимизации, честно полагающейся на отсутствие UB (undefined behavior) в исходном коде. Мы применяем матаппарат на множестве целых чисел, чтобы вывести некоторые результирующие формулы, но они с большой вероятностью перестают работать, если допустить целочисленное переполнение на итерациях суммирования (однако, не исключено, что формулы справедливы в арифметике по модулю 2⁶⁴, например).
— не оторвётся ли случайно (или скорее наоборот останется) какой-нибудь слэш
/в relative-пути, если передатьpathбез завершающего слэша? Зависит, конечно, от того, как именноpathдоходит до сюда.UPD: ну и в принципе смешивание
std::stringиfs::pathдля навигации звучит довольно взрывоопасно, вроде APIfsдолжно хватать для всехGetRelativeи т.д., но он ещё и нормализует пути.Да, вот только не стоит забывать, что отсчёт у нас идёт от абсолютного нуля 0K (-273°C), поэтому радиатор 90°C излучает сильнее радиатора 20°C всего в
((273+90)÷(273+20))⁴ ~ 2.3раза сильнее.Не совсем так, для передачи энергии излучением достаточно просто разности температур и способности поглощать определённые длины волн. Все тела излучают (см. Закон Стефана — Больцмана), и примерно пропорционально
~T⁴, но другое дело, что входящие и исходящие потоки могут быть равны.Но да, от проца до радиатора ПК больше тепла передаётся теплопроводностью, а от радиатора воздуху — конвекцией.
Хорошо б ещё ссылку приложить, на Хабре есть замечательная статья про это:
Сверхлёгкие частицы размером с галактику (https://habr.com/ru/company/ruvds/blog/696254/)
Справедливо. Звучит, правда, сложнее: раскрутить — затормозить — раскрутить обратно — повторить, новые потери энергии (и момента? — подъёмная сила же теперь в принципе не всегда по касательной к вращению будет), сложнее схема управления. В любом случае, считать надо.
Всё-таки не влезет. См. идею про "всё уже записано в числе пи" (Нормальное число). Проблема в том, что для кодирования смещения в таком бесконечном архиве нужно число с энтропией порядка самих закодированных данных.
Ну и вообще, для интересующихся советую познакомиться с понятием Колмогоровская сложность — очень расширяет сознание архиваторостроителям.
Странная анимация, что именно она иллюстрирует? Если это силовые линии электростатического поля точечного заряда в лабораторной системе отсчёта, почему после ускорения/рывка они остаются прямолинейными? (Хотя понаблюдал за конкретной точкой, может так и есть, после начала движения заряда градиент медленно поворачивается за зарядом с запозданием).
Если это силовые линии гравитационного поля, при движении по окружности возникали бы аналогичные искажения, градиент которых можно было бы уловить, но вроде как грав. волны рождаются только рывком массы, поэтому наверное иллюстрация всё-таки к электростатике.
UPD: увидел комментарий выше, таки это электрический заряд. Всё равно вопрос к форме поля, надо обдумать.
Хе-хе: http://www.tapir.caltech.edu/~teviet/Waves/emfield.html
Ну да, логично, искажения-то есть, но они очень малы даже для скорости заряда c/2.
На Хабре было много замечательных статей на тему гравитационных волн, в которых в том числе поднимался и этот вопрос. Если кратко:
https://habr.com/ru/post/426785/
https://habr.com/ru/post/407499/
Кажется, вращающиеся ЧД тоже умеют рендерить.
Да норм, там своя уличная магия, про это тоже была статья-перевод.
Заново изучил статью, преисполнился, соглашусь.
Про over-aligned типы такие идеи имеют место быть: помимо локальности и убирания косвенных обращений (что чаще всего хорошо из-за кэширований), иногда нам может быть полезно наоборот немного разнести данные в пространстве ("локальные, но чуть-чуть"), чтобы избежать false sharing. Например, это когда несколько потоков молотят один вектор, но каждый только свой элемент, но при этом постоянно инвалидируют ячейки соседей, просто потому что несколько ячеек попало в одну кэш-линию.
Только жеж:
std::unique_ptr'у нельзя подсунуть аллокатор, а толькоdeleter, поэтому не получится так просто его использовать, придётся действительно огородить свойoperator newи связывать его сdeleter'ом.static_ptrо полиморфности со стиранием типа "на месте", т.е. как будто очень похож наstd::[not_very_]any, хранящий только определённую иерархию классов, и с mandatory small-object-optimization (т.е. неаллоцирующий).