С одной стороны - да, это важно, если кол-во пикселей одинаково.
Но с другой - при одном и том же размере сенсора наличие на нем 200М пикселей вместо 8М будет преимуществом. Да, пиксели будут меньше (для случая 200М), соответственно сильно шумнее, но все равно (даже с учётом шумности) информации для обработки будет больше. Можно просто усреднить световые интенсивности для групп пикселей - и уже сровняемся по качеству с сенсором на 8М пикселей. А можем применить алгоритм поумнее - тогда и качество будет сильно выше. Алгоритмы решают )
При этом разница в расходе памяти была колоссальной. Всего 61 Мб при включенном HugePages, вместо 25 Гб без него.
Это было бы верно, если бы сервер показал эти освободившиеся 25Гб как free (или buff/cache, неважно), но так не бывает. Память по прежнему занята, она выделена в пул HugePages и используется процессами PostgreSQL, просто не отображается в статистике используемой процессом памяти. Поэтому может показаться, что процесс использует всего 61МБ, а по факту он работает со всеми 25Гб, как и до этого.
1) Нет никакой субъективности в том, что сумма яркостей полностью черного и белого пикселей должна равняться сумме яркостей двух пикселей c яркостью каждого в 50% (в sRGB это цвет [188,188,188]) - это можно определить и на глаз по соотв калибровочной картинке. И это только один из примеров.
2) может и подмешивает, для компенсации неточности преобразования "цифра-цвет" в мониторе, если активирован соотв профиль. Если бы преобразование "цифра-цвет" было идеальным, то во всех этих калибровках не было бы необходимости. А так приходится подавать на вход монитору "неправильную" цифру, чтобы получить "правильный" цвет.
Может быть и так (хотя мне такие цены озвучил наш отдел закупки), но тогда, получается, не оптовым покупателям все-равно нет смысла даже пробовать эту технологию, раз финансовой выгоды нет вообще, а производительность в разы меньше чем RAM.
Если проблема именно в нагрузке при асинхронной записи многих файлов - можно попробовать ммапить файлы для записи, делать, собственно, запись данных в заммапленную память, а дальше пусть ОС разгребает dirty pages самостоятельно. Правда, все может упереться в задержки на page faults, я лично не тестил. Впрочем, для sparse файлов проблемы с пейжфолтами быть не должно. И придется ещё позаниматься тюнингом sysctl vm.dirty* и подобных, а то ОС может и не справиться самостоятельно, если прилетит большая пачка апдейтов. На фре есть возможность сделать ммап с флагом MAP_NOSYNC - тогда можно отдельно синкать измененные файлы на диск (ОС это делать уже не будет), контролируя загрузку дисков..
Я бы не сказал, что прямо сильно реалистичный рендер.
Полигоны на моделях вполне бросаются в глаза, спецэффекты (дым, искры..) как в играх 10-ти летней давности, движения агентов жесткие и неестественные...
Если бы такой рендер был, скажем, в фильме, то все плевались бы.
Мне кажется, что если Вы видите пиксельную сетку (даже на FHD), то Вы сидите слишком близко к монитору.
Я сознательно поставил себе два 27" FHD монитора и работаю за ними с расстояния 100см (увеличив шрифт так что межстрочное расстояние составляет 7..11 мм) - и никаких проблем с четкостью шрифтов ))
Простота (как антоним к сложности) системы - это своего рода ресурс, им надо управлять, в частности - экономить (при проектировании), или восполнять (рефакторингом) - потраченные на это время и деньги окупаются при разумном планировании. Недостаток простоты увеличивает цену разработки и поддержки - при критически низком значении это может сыграть фатальную роль.
Не учитывается тот факт, что зимой светлое время суток существенно меньше чем летом. Небольшим ухудшением зимнего угла падения (и соответствующим улучшением летнего) можно увеличить общую выработку энергии, за счёт большего увеличения выработки летом, чем её уменьшения зимой.
Спасибо, но речь не о том, чтобы процесс получил свой стэктрейс, с этим проблем нет.
Вопрос в том, как снаружи узнать, в каком месте кода сейчас выполняется php-fpm процесс (возможна соотв модификация кода). Ну, ждет ответ от базы, например, или вычисляет что-то в какой-то функции.. С точностью до строки - вообще идеально, с точностью до функции - тоже годится. Есть ли какой-то модуль для этого?
Может кто-то знает способ получить стэктрейс для работающего в текущий момент php-fpm процесса? Чтобы понять в каком месте он выполняется в текущий момент.
Имхо, было бы правильнее сделать так, чтобы -Werror активировался не глобально, а для определённых подсистем, драйверов и т.д. Тогда можно было бы потихоньку подчищать актуальные подсистемы и драйвера от предупреждений, активировать для них -Werror и требовать чтобы последующие патчи для них компилировались чисто.
Исследования, конечно, интересные, но было бы сильно лучше, если бы подавалась и информация о результатах всех этих исследований (а не только некоторых избранных, как сейчас)
С одной стороны - да, это важно, если кол-во пикселей одинаково.
Но с другой - при одном и том же размере сенсора наличие на нем 200М пикселей вместо 8М будет преимуществом. Да, пиксели будут меньше (для случая 200М), соответственно сильно шумнее, но все равно (даже с учётом шумности) информации для обработки будет больше. Можно просто усреднить световые интенсивности для групп пикселей - и уже сровняемся по качеству с сенсором на 8М пикселей. А можем применить алгоритм поумнее - тогда и качество будет сильно выше. Алгоритмы решают )
Да, можно.
Любой инстанс постгреса можно настроить публиковать изменения, слейв в том числе.
Интересно, как там с накладными расходами на все это счастье..
Сколько дополнительных аллокаций, сколько процессора...
Это было бы верно, если бы сервер показал эти освободившиеся 25Гб как free (или buff/cache, неважно), но так не бывает. Память по прежнему занята, она выделена в пул HugePages и используется процессами PostgreSQL, просто не отображается в статистике используемой процессом памяти. Поэтому может показаться, что процесс использует всего 61МБ, а по факту он работает со всеми 25Гб, как и до этого.
1) Нет никакой субъективности в том, что сумма яркостей полностью черного и белого пикселей должна равняться сумме яркостей двух пикселей c яркостью каждого в 50% (в sRGB это цвет [188,188,188]) - это можно определить и на глаз по соотв калибровочной картинке. И это только один из примеров.
2) может и подмешивает, для компенсации неточности преобразования "цифра-цвет" в мониторе, если активирован соотв профиль. Если бы преобразование "цифра-цвет" было идеальным, то во всех этих калибровках не было бы необходимости. А так приходится подавать на вход монитору "неправильную" цифру, чтобы получить "правильный" цвет.
Может быть и так (хотя мне такие цены озвучил наш отдел закупки), но тогда, получается, не оптовым покупателям все-равно нет смысла даже пробовать эту технологию, раз финансовой выгоды нет вообще, а производительность в разы меньше чем RAM.
Штука, конечно, интересная, но цена...
64GB ECC DDR4 стоит меньше 350$, а Optane 128G дешевле 700$ не найти - ну никак не получается "огромный объем за гораздо меньшие деньги, чем ДДР"
Если проблема именно в нагрузке при асинхронной записи многих файлов - можно попробовать ммапить файлы для записи, делать, собственно, запись данных в заммапленную память, а дальше пусть ОС разгребает dirty pages самостоятельно. Правда, все может упереться в задержки на page faults, я лично не тестил. Впрочем, для sparse файлов проблемы с пейжфолтами быть не должно. И придется ещё позаниматься тюнингом sysctl vm.dirty* и подобных, а то ОС может и не справиться самостоятельно, если прилетит большая пачка апдейтов.
На фре есть возможность сделать ммап с флагом MAP_NOSYNC - тогда можно отдельно синкать измененные файлы на диск (ОС это делать уже не будет), контролируя загрузку дисков..
Я бы не сказал, что прямо сильно реалистичный рендер.
Полигоны на моделях вполне бросаются в глаза, спецэффекты (дым, искры..) как в играх 10-ти летней давности, движения агентов жесткие и неестественные...
Если бы такой рендер был, скажем, в фильме, то все плевались бы.
Мне кажется, что если Вы видите пиксельную сетку (даже на FHD), то Вы сидите слишком близко к монитору.
Я сознательно поставил себе два 27" FHD монитора и работаю за ними с расстояния 100см (увеличив шрифт так что межстрочное расстояние составляет 7..11 мм) - и никаких проблем с четкостью шрифтов ))
Простота (как антоним к сложности) системы - это своего рода ресурс, им надо управлять, в частности - экономить (при проектировании), или восполнять (рефакторингом) - потраченные на это время и деньги окупаются при разумном планировании. Недостаток простоты увеличивает цену разработки и поддержки - при критически низком значении это может сыграть фатальную роль.
Спасибо за статью.
Но непонятно два момента ;)
Во первых, почему решений только 4, если их значительно больше - BACD, BADC, BCAD, BDAC, CABD, CADB, CBAD, CDAB, DABC, DACB, DBAC, DCAB?
Во вторых - почему алгоритм нашел два решения с первой вершиной "C", но только по одному для "B" и "D", хотя граф симметричный относительно B, C и D?
Могу предположить, что второй поток завис потому что первый не освободил мьютекс до того как завершился по SIGALRM.
Не учитывается тот факт, что зимой светлое время суток существенно меньше чем летом. Небольшим ухудшением зимнего угла падения (и соответствующим улучшением летнего) можно увеличить общую выработку энергии, за счёт большего увеличения выработки летом, чем её уменьшения зимой.
ядро 5.10, с
и всеми возможными шифрами
Что-то не работает KTLS на этом патченом nginx со свежерелизнутым openssl-3.0.0 (и с патченым тоже) ;(
в конфиге есть и sendfile on; и ssl_ktls on; все остальное по дефолту, ничего специфического нет.
$ssl_ktls_status в лог пишет прочерк (
Спасибо, но речь не о том, чтобы процесс получил свой стэктрейс, с этим проблем нет.
Вопрос в том, как снаружи узнать, в каком месте кода сейчас выполняется php-fpm процесс (возможна соотв модификация кода). Ну, ждет ответ от базы, например, или вычисляет что-то в какой-то функции.. С точностью до строки - вообще идеально, с точностью до функции - тоже годится. Есть ли какой-то модуль для этого?
Может кто-то знает способ получить стэктрейс для работающего в текущий момент php-fpm процесса? Чтобы понять в каком месте он выполняется в текущий момент.
Имхо, было бы правильнее сделать так, чтобы -Werror активировался не глобально, а для определённых подсистем, драйверов и т.д. Тогда можно было бы потихоньку подчищать актуальные подсистемы и драйвера от предупреждений, активировать для них -Werror и требовать чтобы последующие патчи для них компилировались чисто.
Исследования, конечно, интересные, но было бы сильно лучше, если бы подавалась и информация о результатах всех этих исследований (а не только некоторых избранных, как сейчас)