Хороший разбор и примеры. Интересно, что материал неявно затрагивает ещё одну важную тему: 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 (т.е. неаллоцирующий).
Всё уже украдено до нас Ваше решение очень напоминает идиому "Fast Pimpl" (презентации Антона Полухина: https://apolukhin.github.io/presentations/Taxi%20C++%20Tricks.pdf), механика и мотивация создания такого умного указателя практически совпадают с изложенными вами. Там же можно найти интересные решения по точкам кастомизации (помимо специализаций static_ptr_traits, последний раздел "Parse"). Оставлю пару заметок:
Интересный подход с сохранением специальных функций. Правда, раздувает размер указателя, и производительность может немного просесть из-за дополнительного уровня обращения, но такова плата за "полиморфизм".
max_align_t не сможет помочь для over-aligned типов (например, "кэш-линия" ~ 64). Можно попробовать использовать max(alignof(T), alignof(max_align_t)). Также, можно хранить внутри доп. указатель-смещение, полученный через std::align, и всегда выделять буффер немного больше и с немного более строгим выравниванием, но это уже звучит ещё большим додумыванием семантики.
Идейно действительно да, принципы похожи, главное добиться интерференционной картины. Например, можно было бы с помощью ЖК создать локальные области повёрнутой поляризации (в простом случае — тупо на 90°, и затенить их поляризационным фильтром, как на простых ЧБ-дисплеях) в толстой пластине (фактически схема голограммы Денисюка), но тут есть несколько проблем:
Нужна очень высокая разрешающая способность: характерный размер "пикселя" должен быть порядка длины волны (~600 нм) и меньше, т.е. фактически мы рисуем метаматериал.
Управление "дисплеем": если мы хотим создать, например, модные голографические очки/линзы с площадью стекла всего 1 см², нам потребуется (1см / 600нм)² = 280 Мп матрица + десяток видеокарт в рюкзаке за спиной для realtime-решения уравнений Максвелла, такой RTX на максималках, но это уже мелочи :)
Более чистый вариант в ассемблере без <iostream>. Хороший трюк — отправлять вывод в volatile-переменную, тогда и компилятор его и не выкинет, и не требуется I/O.
При включенной оптимизации результат вообще красиво слёг в статическую строку, а main векторизовался, лол. MSVC, моё почтение.
Кстати, к вопросу о: эта водяная аналоговая машина концептуально ведь очень схожа с квантовым компьютером. Вместо того, чтобы численно решать диффуры, ИГЛ фактически проводит физическую симуляцию задачи теплопроводности. Точно так же, вместо того, чтобы проводить матричные умножения и жонглировать операторами, квантовый компьютер тупо даёт некоторой системе кубитов эволюционировать, а люди потом собсно смотрят на "уровень воды в сосудах".
Ровно поэтому, имхо, заявления о "квантовом превосходстве" в задаче случайных квантовых цепочек (Google) звучат несколько читерски. Это как сказать, "мы полностью просчитали взрыв атомной бомбы за минуту, а классический компьютер так не может!"… взорвав настоящую атомную бомбу и сняв показания приборов ¯\_(ツ)_/¯
Кажется (в числе прочего, по комментариям), что на фотографиях очень не хватает референсных объектов для оценки масштаба: реальных людей, сидящих и лежащих в самих капсулах, типовых чемоданов-баулов, втиснутых в багажные карманы. Потому что, судя по линейным размерам, на самом деле-то эффективного пространства для размещения и манёвров довольно много, но по фото это не ощущается.
Тем не менее, с учётом вышесказанного, проект планировки выглядит как минимум небезынтересно и осторожно-оптимистично.
Френдлифаер круто, ещё и стратегию меняет: по функции, названной противником, можно сделать предположения, куда он не хочет попасть сам.
Хороший разбор и примеры. Интересно, что материал неявно затрагивает ещё одну важную тему: 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 (т.е. неаллоцирующий).Всё уже украдено до насВаше решение очень напоминает идиому "Fast Pimpl" (презентации Антона Полухина: https://apolukhin.github.io/presentations/Taxi%20C++%20Tricks.pdf), механика и мотивация создания такого умного указателя практически совпадают с изложенными вами. Там же можно найти интересные решения по точкам кастомизации (помимо специализацийstatic_ptr_traits, последний раздел "Parse"). Оставлю пару заметок:max_align_tне сможет помочь для over-aligned типов (например, "кэш-линия" ~ 64). Можно попробовать использоватьmax(alignof(T), alignof(max_align_t)). Также, можно хранить внутри доп. указатель-смещение, полученный черезstd::align, и всегда выделять буффер немного больше и с немного более строгим выравниванием, но это уже звучит ещё большим додумыванием семантики.Идейно действительно да, принципы похожи, главное добиться интерференционной картины. Например, можно было бы с помощью ЖК создать локальные области повёрнутой поляризации (в простом случае — тупо на 90°, и затенить их поляризационным фильтром, как на простых ЧБ-дисплеях) в толстой пластине (фактически схема голограммы Денисюка), но тут есть несколько проблем:
(1см / 600нм)² = 280 Мпматрица + десяток видеокарт в рюкзаке за спиной для realtime-решения уравнений Максвелла, такой RTX на максималках, но это уже мелочи :)https://godbolt.org/z/cq9sWqMhP
<iostream>. Хороший трюк — отправлять вывод в volatile-переменную, тогда и компилятор его и не выкинет, и не требуется I/O.mainвекторизовался, лол. MSVC, моё почтение.Кстати, к вопросу о: эта водяная аналоговая машина концептуально ведь очень схожа с квантовым компьютером. Вместо того, чтобы численно решать диффуры, ИГЛ фактически проводит физическую симуляцию задачи теплопроводности. Точно так же, вместо того, чтобы проводить матричные умножения и жонглировать операторами, квантовый компьютер тупо даёт некоторой системе кубитов эволюционировать, а люди потом собсно смотрят на "уровень воды в сосудах".
Ровно поэтому, имхо, заявления о "квантовом превосходстве" в задаче случайных квантовых цепочек (Google) звучат несколько читерски. Это как сказать, "мы полностью просчитали взрыв атомной бомбы за минуту, а классический компьютер так не может!"… взорвав настоящую атомную бомбу и сняв показания приборов
¯\_(ツ)_/¯Кажется (в числе прочего, по комментариям), что на фотографиях очень не хватает референсных объектов для оценки масштаба: реальных людей, сидящих и лежащих в самих капсулах, типовых чемоданов-баулов, втиснутых в багажные карманы. Потому что, судя по линейным размерам, на самом деле-то эффективного пространства для размещения и манёвров довольно много, но по фото это не ощущается.
Тем не менее, с учётом вышесказанного, проект планировки выглядит как минимум небезынтересно и осторожно-оптимистично.