Яркость всегда контролируется символом. Как следствие полоски и HDR эффект на 24битной версии. Даже 48 цветная могла бы получше выглядеть, если учитывать яркость в цвете.
Деление целого на целое "bright / 255" меня напрягает тем, что работает у автора.
Пиковая производительность это плохой критерий для разделения, не удивлюсь если SS отыгрывает у 1X все свои TFOPS, ГБ/с, пиксели и тексели за счёт новой архитектуры.
Важнее, что у SS всего 9ГБ памяти доступно для приложений, когда у 1X — 10ГБ. И если игра была настроена на все 100%, то этот 1ГБ разницы будет камнем преткновения.
За много лет пользования кувшинами приметил одинаковые для всех неудобства.
1. Внутренняя форма ёмкостей имеет острые углы и рёбра. Когда (не если, это случается всегда) вода зацветёт, то вытирать зелень из углов будет крайне сложно. Да, и просто мыть неудобно. Могли бы все внутренние углы сделать круглыми, радиусом >0.3см, было бы удобнее.
2. Нельзя нормально сливать фильтрованную воду, если есть нефильтрованная. Миллионы различных ситуаций сводятся к этому состоянию. Бесит. А ведь могли бы сделать карман в верхней ёмкости.
1. Охотно верю, только там приписка «estimated». Тест SPEC2006 был не сертифицирован, то бишь не был куплен и правильно проведён. И фиг бы с этим, база для тестов на ПК: WSL+llvm.
Зато весь интернет ссылается на это как на SPEC2006 для Zen3/TGL.
2. M1 имеет чуть-чуть большую частоту одного ядра, вот на эту и меньшую разницу будет прирост от A14.
По тестам производительности на одном ядре Apple M1 обошёл Ryzen 9 5950X и Core i9-10900K.
Это не M1 обошёл, это MacOS обошла. Geekbench обожает (+20%) операционки эпл.
И так уж получилось, сейчас королём рейтинга Geekbench Single-Core является Ryzen 9 5900X под MacOS.
Логично было бы сделать поведение std::make_shared зависимым от величины sizeof(T). Например, у менеджера памяти есть пул для объектов размером от 1 до 512 байт и блок управления имеет размер 24 байта, то для объектов размером до 488 байт производит слияние объекта и блока управления, а если больше 488 байт, то делать две аллокации.
Я честно пытался, но быстрее не получилось, ни по диагонали, ни блоками по диагонали. Может быть на размерах превышающих L2 или L3 мог бы быть выигрыш.
Никто биологический фактор не упомянул, ну только как «глаза меньше устают».
1. Свет запускает химические процессы в светочувствительных клетках, и они тратят силы на своё восстановление и нервный импульс.
2. Нервные клетки сетчатки и зрительных нервов тоже тратят силы на передачу и обработку сигнала, пока он не будет перекодирован в более энергоэффективное представление.
Держать светящийся (не светлый) объект (монитор) в центре зрения — тяжело. А в тёмном помещении, когда зрачок расширяется из-за снижения общей освещенности, клеткам в центре сетчатки (привет, зайчики) приходятся ещё тяжелее.
В Питере еле доставало, часто сбоило и сдвигало время на час-два, потом исправлялось.
В Челябинске, кхе-кхе, никакой синхронизации и примерно раз в месяц случайное время. Вскрыл и отрезал антенну.
TDP это termal design power, параметр для разработчиков систем охлаждения. Он конечно был как-то логически связан с потреблением процессора в момент его разработки/тестирования/маркировки, но уж точно не в момент установки патча на винду.
Это слишком неопределённое гадание. Но, раз уж это чистый си, то возможно что у них практикуется выделять память под максимальный размер без завершающего нуля. Если значение короче, то ноль на месте, если максимальное, то неявно. Тогда надо указывать некую константу, максимальный размер пароля.
не длину передаваемого авторизующимся юзером, а установленного пароля.
Правильнее:
1. длину не передаваемого авторизующимся юзером, а установленного пароля плюс один.
2. длину передаваемого авторизующимся юзером пароля плюс один.
Так из соображений безопасности ввели или отключили? Можно подумать, что ввели, а на самом деле, отключили.
Яркость всегда контролируется символом. Как следствие полоски и HDR эффект на 24битной версии. Даже 48 цветная могла бы получше выглядеть, если учитывать яркость в цвете.
Деление целого на целое "bright / 255" меня напрягает тем, что работает у автора.
Важнее, что у SS всего 9ГБ памяти доступно для приложений, когда у 1X — 10ГБ. И если игра была настроена на все 100%, то этот 1ГБ разницы будет камнем преткновения.
1. Внутренняя форма ёмкостей имеет острые углы и рёбра. Когда (не если, это случается всегда) вода зацветёт, то вытирать зелень из углов будет крайне сложно. Да, и просто мыть неудобно. Могли бы все внутренние углы сделать круглыми, радиусом >0.3см, было бы удобнее.
2. Нельзя нормально сливать фильтрованную воду, если есть нефильтрованная. Миллионы различных ситуаций сводятся к этому состоянию. Бесит. А ведь могли бы сделать карман в верхней ёмкости.
Зато весь интернет ссылается на это как на SPEC2006 для Zen3/TGL.
2. M1 имеет чуть-чуть большую частоту одного ядра, вот на эту и меньшую разницу будет прирост от A14.
Это не M1 обошёл, это MacOS обошла. Geekbench обожает (+20%) операционки эпл.
И так уж получилось, сейчас королём рейтинга Geekbench Single-Core является Ryzen 9 5900X под MacOS.
1. Свет запускает химические процессы в светочувствительных клетках, и они тратят силы на своё восстановление и нервный импульс.
2. Нервные клетки сетчатки и зрительных нервов тоже тратят силы на передачу и обработку сигнала, пока он не будет перекодирован в более энергоэффективное представление.
Держать светящийся (не светлый) объект (монитор) в центре зрения — тяжело. А в тёмном помещении, когда зрачок расширяется из-за снижения общей освещенности, клеткам в центре сетчатки (привет, зайчики) приходятся ещё тяжелее.
В Челябинске, кхе-кхе, никакой синхронизации и примерно раз в месяц случайное время. Вскрыл и отрезал антенну.
Порядок вычисления операндов оператора не определён. Изменение переменной и её использование в одном выражении.
2. Писать inline при реализации метода внутри объявления класса не обязательно.
int64 и наносекунды отлично подходят друг к другу. Во многих реализациях c++11 классы std::steady_clock и std::system_clock реализованы именно так.
1. длину не передаваемого авторизующимся юзером, а установленного пароля плюс один.
2. длину передаваемого авторизующимся юзером пароля плюс один.
Автор попытался исправить ошибку и сделал свою.