Обновить
297

Пользователь

136
Подписчики
Отправить сообщение

Что? Современный телефон чем‑то менее точен компьютера?

Потому что оледы растят в полимерных ванночках, проецируя на поверхность все пиксели за раз по слоям (как в 3д принтерах), а микроледы, грубо говоря, роботы паяют по одному пикселю.

Как устроены дисплеи. Подробный разбор
Осторожно, трафик! Опасайтесь ложных суппикселей В этой части разберем аппаратное устройство, виды и...
habr.com

OLED, QD‑OLED — светодиодная органика, весь экран — единое целое.

MicroLED — светодиодная неорганика, модульный. Ярче (OLED с трудом добрался до 1000 кд/м², MicroLED начинался с 5000 кд/м²), долговечнее, контрастнее, выше предельная плотность пикселей, выше энергоэффективность, лучше цветопередача.

Есть ещё QDEL — это не светодиоды и не ЖК, а квантовые точки, к которым подводится ток. Пока экзотика.

Все остальное — LED, QLED, MiniLED, NanoCell, NeoQLED и прочее — разновидности ЖК‑экранов с разными улучшалками. Это не светодиодные дисплеи.

По яркости — улица в солнечный день генерирует эквивалент до 10 000 кд/м², пока до этого никто толком не добрался. Таким образом, чтобы телик на стене был неотличим от окна, он, помимо безупречной цветопередачи, должен уметь в эти самые 10 килокандел. Ну и ещё быть голографическим с 1000×1000 ракурсами :)

Стало любопытно, накидал дичь, генерирующую 100 млн строк иероглифов. Работает от 4 до 8 секунд у меня.

Результат 10 прогонов, время в миллисекундах

8479
7745
4509
6194
8847
6047
5469
5101
5097
4818

Примеры строк

"姿龯왑䈘㵌馃⨡⎟"
"趯挸偽௸뎢뻏"
"끇\uddb9刺ੁ᭘蠽㭥竲⪻끐腿鮠爼䴏\u245f永ꦦ"
"\ud9d3伣駒뀹\ude38㸓⬀瘞忍䥨"
"\u124f罱䩽偻媘뭴肊梗⟑牘骣믇ጝ\uddf8侧旯馐燳螩ᅺ艇金낦"
"쑻듺曡堈\u0e78呝깘耥㵣⏗ﲮ쭓꾺䒮河♼"
"눗⁋鰆焏俘땔㤼\udcc9漉ꃭ敶尿ﴱ\udf1e᪡麯ꖙ奞꠵쨡怽ខ爺찎熬困샚D"
"뿣㐞㣿豷Ⲹ⋢飏瞽쓜闦嗎짻䔶䠫졛긌꒑컊邵龃밶玦"
"놟䀕鉎쬘鹯맨庁侷㛿"
"阋ﳆ뎿懌䣸"
"ꋧ섥᱘쬥巬◞\u2439붦듷滗"
"䃳싄斫쵾紵鰴⼕钭잦㑞呺圃열"
"߯峍ﳼẝ᎘絬涭劳︱\uddaf쑨ʧ\ufe67삶캥Ἕه鍖㭘༉솭᳙炵泊溞ྦ"
"檛좿㪑诀㭸땋㔻阅㞹♞蔋쉳ᔂ䅻쪞嫊虧鞽蘔첩"
"튷"
"叻䀦놸瓊▾淏⚝ƭ䰊\udb15耛廰䟅廝\ua8c5\ud940<岕탊縝ᛶ쾂쑨ݯ/"
"㊓핶"
"别奌"
"醇恽蕛颛絘奛ᮦペ鷽\u2fd8頃겿"
"吓원屈攪袧㰦㫷鶍\u0c53퀫恦"
"ᦏ惭蜶Ⲙ牱꺏ꩺ㢑î確訂㴇숽\udaef洿㣧ْ䤶舫"
"岻टൻ䊤䡸胒ᣡ鹠\udfe5뿚\udc6a髲斓떛߉\udd8e軳搔ᡬ햵"
"⽗莋"
"أൿ腜㵒ᚸⓨ訤⮸楽ﭪ磺㓋舻Ỵ㓞瓁좛㛥뤵ৈ鱵ؐ阚뭶灂㉙"
"瓟얂ᠤ쏲ﴘ"
"驋췅皆놗拸콞"
"ﰧ暟窗鮹㹘幞槡悲ꋹ㭋촕痪\u0c5fᵎ"
"錳█Ꭶ⽲봸ᅝ蛶㕜舘"
"윯ᔾⰫ߀ꖘ亇︈姩囱奙話㱫ᴏ符枇敒國"
"\u1adbଷ꿂㕸歆巬薍\uddc5䬚▱ꄋ㒳뀖년纉"
"䟷ӕ᪳"

 //Осторожно, турбоконвейер по отстреливанию ног
 public string[] GenerateRandomStrings(int count, int threadCount = -1)
 {
     if (threadCount == -1)
         threadCount = Environment.ProcessorCount;

     var result = new string[count];
     int stringsPerCore = count / threadCount;

     Parallel.For(0, threadCount, coreIndex =>
     {
         int from = coreIndex * stringsPerCore;
         int to = coreIndex < threadCount - 1 ? from + stringsPerCore : count;

         var maxCharCount = Vector512<byte>.Count / sizeof(char);
         var maxCharCount_minus_1 = maxCharCount - 1;
         unsafe
         {
             //Генерируем начальную "строку", её байты интерпретируются как байты вектора ulongов
             Vector512<ulong> vectorValue;
             {
                 char* firstStr = stackalloc char[maxCharCount];
                 var rnd = new Random();
                 for (int i = 0; i < maxCharCount; i++)
                     firstStr[i] = (char)rnd.Next(1, char.MaxValue + 1);
                 vectorValue = Vector512.Load<ulong>((ulong*)firstStr);
             }

             //Магическая константа Кнута, 8 штук в одном векторе
             Vector512<ulong> knythConstant = Vector512.Create<ulong>(0x9E3779B97F4A7C15UL);

             char* charBuffer = stackalloc char[1024];
             {
                 //Вбиваем последний гвозь в безопасность
                 //Эта дичь нужна чтобы выравнять адрес charBuffer под кратность 64 байтам
                 //Чтобы из векторного регистра быстрее копировать в него
                 while ((nuint)charBuffer % (nuint)Vector512<byte>.Count != 0)
                     charBuffer++;

             }
             ulong* charBufferAsUlongs = (ulong*)charBuffer;

             //Каждый раз интерпретируем байты вектора как строку
             //Затем умножаем на константу - получаем следующий набор байт
             for (int i = from; i < to; i++)
             {
                 var strLen = ((byte*)&vectorValue)[0] % maxCharCount_minus_1 + 1; //Увеличенный на 1 остаток от деления первого байта предыдущей строки на (maxCharCount-1) - это длина новой строки
                 vectorValue *= knythConstant; //Умножаем - получаем байты для новой строки

                 //Используем байты как строку, откусывая кусочек нужной длины
                 Vector512.StoreAligned(vectorValue, charBufferAsUlongs);
                 result[i] = new string(charBuffer, 0, strLen);
             }
         }

     });
     return result;
 }

Берёт 512-битный вектор, заполняет рандомами. Далее:

  1. Берём остаток от деления первого байта вектора на 32 — это будет длина строки N

  2. Интерпретируя вектор как 8 числе ulong, умножает каждое на 0×9E3779B97F4A7C15UL

  3. Интерпретируя вектор как набор char берёт первые N символов и делает из этого строку

  4. Генерит так следующую строку

Смысл такой: мы считаем хэш Кнута на AVX512 сразу для 8 чисел за раз, и интерпретируем байты этих чисел как байты строки. Если AVX512 нет, можно на 256-битные переделать, или вообще вымазать проверками на IsHardwareAccelerated — тоже будет быстро.

У меня один вопрос: а нельзя ли просто на лету генерировать рандомные строки? Зачем их в массив‑то пихать? Да ещё такой огроменный. Может проще сразу как‑то в базу заливать, или куда там это предназначено.

интересная задача

This.

Вообще π может быть нужно с точностью больше 2 знаков, если мы делаем какую‑нибудь прецензионную втулку из рубина, у которой должна быть точность 1 атом. Да даже в пластины жестких дисков делаются с такой точностью, что двух знаков π явно мало, чтобы, например, рассчитать положение головки в полярных координатах.

Калькулятор, который «абсолютно точный и не косячит, гарантия 100%» может быть действительно полезным, но далеко, далеко не всегда в этом есть необходимость. Но это не значит, что её вовсе нет.

Кроме того, сам факт изучения вопроса «как сделать это очень точным» генерирует полезные знания и разные приёмы, которые могут помочь в тех местах, где практически нужно повысить точность или оптимизировать вычисления.

Иными словами, польза от таких задач косвенная, а не прямая. Мы генерируем некоторый интеллектуальный капитал, который целиком или частями можно потом использовать в других, более практических задачах.

Технически можно впихнуть её не в виде данных, а в виде алгоритма, который бесконечно наращивает её точность. т. е. нажал равно — результат появился и начинает бесконечно уточняться, прямо на экране. Чем дольше ждёшь, тем точнее результат. И так можно не с π, а вообще со всеми числами — выражение сначала упрощается, а затем итеративно вычисляется, наращивая точность, до бесконечности.

Если добавить возможность ставить на паузу вычисления уточнения и сохранять промежуточный результат на носитель, то получится калькулятор бесконечной точности.

понимается

Кем? :) Получается, на математичность влияет субъективный фактор — если человек не в курсе, что это выражение можно интерпретировать хотя бы двумя разными способами, то для него оно математическое, а для того, кто знает — не математическое.

И тогда получается, что математики видят в нем не математическое выражение, а не математики — математическое. Свой среди чужих, чужой среди своих. Забавно.

Есть две разных нотации, ЕИНИП. В одной трактуется как простое 2×a, в другой эта операция трактуется как умножение с повышенным приоритетом. И, в зависимости от того, как человека выучили, он будет трактовать это так или иначе. Поэтому люди и спорили.

В принципе, могли и гуйню переписать под новый API

Спасибо, не надо. Хватает блокнота, тормозящего на шестнадцатиядерном процессоре 5 ГГц. И проводника. И меню пуск. Пусть сначала научатся оптимизировать код.

Retopology в помощь. Конечно, и с ней сетка будет тоже не ахти, но уже лучше. И кстати — ретопология на нейронках тоже должна появиться, по идее. И вот тогда будет вкусно.

Сущность — это калька с entity. По моим наблюдениям, оно употребляется в значении слова «понятие» из логики, с той поправкой, что понятиями оперирует логическое мышление человека, а вот эти самые «сущности» — концепция, совместимая и с описанием алгоритмов для машины, и с мышлением человека.

Когда человек логически мыслит в отношении чего то, ему для этого нужен понятийный аппарат, где понятия строго определены, имеют отношения род‑вид и вот это всё.

Так и тут — мы делаем некий софт, вырабатываем набор сущностей, их описание и взаимосвязи — то есть, в некотором смысле, «понятийный аппарат», которым будет «мыслить» машина, и далее уже описываем, как эти сущности должны между собой взаимодействовать.

Спасибо. Просто часто встречаю применение этого термина везде и всюду. И в вэбе, и в бд, а теперь в священном Си++. И от того, что им называют всё подряд, смысл подистерся.

Это нормально, т.к. это обобщение над классами, объектами, таблицами и прочими строительными блоками, из которых строится софт.

Можете пояснить, на смартфонах все субпиксели сразу цветные в отличии от мониторов или может быть я чего‑то неправильно понял и бояться выгорания не стоит?

Сразу скажу — дисплеи телефонов глубоко не изучал, но насколько мне известно, там как раз, чаще всего, используется просто цветные светодиоды безо всех этих бутербродов со светофильтрами, и белых субпикселей там нет — всё для экономии батареи.

У меня на Galaxy S7 тоже за 5 лет выгорела полоса сверху, подтверждаю. Телефоны фактически наследуют болячки первых OLED телевизоров. Но у них свои причины — им надо экономить энергию, но при этом уметь разгораться ОЧЕНЬ ярко, чтобы перебивать солнце, когда телефон смотрят на улице.

Светодиоды умирают не от того, что светятся, а от тепла (а когда они светятся — они греются). У телефона, помимо самоподогрева экрана, есть ещё процессор и АКБ, которые тоже часто греются и параллельно поджаривают матрицу. И даже если Вы не играете на нём в игры — современные приложения пишут настолько неоптимально, что они часто вполне себе формируют высокую нагрузку. Плюс каждая зарядка — это поджаривание матрицы. Особенно быстрая зарядка. У телевизора этих проблем нет.

Когда телефону надо показывать белый, он активирует все три субпикселя, и все три греются. Телевизор WRGB для белого включает один субпиксель, остальные три отдыхают.

Таким образом, я думаю, что здесь сразу два фактора: а) дисплей телефона подвержен более высоким нагрузкам из‑за конструкции и фактора эксплуатации на улице б) по определённым причинам он построен по упрощённой технологии цветных светодиодов, которая подвержена выгоранию

И во вторых мне не очень хочется ставить темную тему, отключать панель задач, без этого выгорание случится быстро?

Тут куча факторов:

  1. Логично, что если оно светится больше — оно будет изнашиваться быстрее

  2. Сколько часов в день используется экран и как? Это важно.

  3. А на какой яркости? Высоковероятно, что если Вы поставите светлую тему на телевизоре, Вам очень‑очень быстро захочется уменьшить яркость экрана:) А матрица, заточенная под 1000+ кд, которая светится на 250 кд (стандартная яркость типового монитора), будет работать очень долго (при условии отсутствия брака). С другой стороны, если у Вас огромные окна выходящие на солнечную сторону, то придётся выкручивать яркость на максимум. Впрочем, глянцевость теликов исключает возможность удобной эксплуатации в таких условиях

  4. Наличие/отсутствие кондиционеров, теплых полов и батарей рядом тоже играет роль. Именно поэтому я подсветку клеил на рамы на расстоянии, а не на сами телики

  5. Я тоже весь путь, пока использовал мониторы, использовал светлые темы и был абсолютно против тёмных, но когда пересел на большие OLED экраны, мои глаза быстро стали намекать что пора менять свои привычки :) Так что тут тоже — высока вероятность того, что Вам захочется включить тёмную тему. Тёмная тема на OLED — это совсем‑совсем не то, что на ЖК ;)

Так надо сделать не 1 сложный ключ, а 1024 ключа попроще. Тогда процесс будет более детерминированным по времени.

Если неточно — можно примерно рассчитать увеличение вычислительных способностей компьютеров, зашифровать инфу и уничтожить ключ. Высоковероятно, что подобрать его за осмысленное время можно будет только через N десятков лет — что нам и нужно.

Да, но в большинстве случаев придётся допиливать. Впрочем, это тоже может делать, по крайней мере, в теории, нейросеть.

Соглашусь, вездесущие гирлянды в вентиляторах, клавиатурах и ковриках раздражают. Однажды эта мода закончится. По подобным клавиатурам отмечу пару плюсов:

  1. Чаще всего подсветка тонко настраивается, и её можно полностью отключить

  2. Качество сборки, отсутствие люфтов и большой ресурс работы

Аналоговые клавиатуры это хорошо
Аналоговые клавиатуры это хорошо

Сам использую Razer Huntsman Analog v2 — в ней клавиши понимают силу нажатия, и в играх она может симулировать аналоговый джойстик, позволяя степенью нажатия управлять скоростью перемещения. Вплане программирования тоже ок, причём использую без подставки под запястья (кот стремится её сожрать, без неё оказалось тоже удобно).

До неё была Logitech Craft, которая хорошо себя показала, особенно в скорости печати — руки буквально скользят по клавишам. Однако, через два года некоторые клавиши окончательно сдались:( Особенно пострадали клавиши WASD, из чего я делаю предположение, что мембранные клавиатуры не очень хорошо переваривают долгое и сильное зажатие клавиш.

Ms делали концепт смартфона из 2х половинок - потребителю такое не зашло. Но зашли складные экраны, делаем выводы.

Потому что концепцию нельзя апробировать наполовину, только полностью, доделанную до конца. В данном случае нужно было сделать толщину рамок, где сходятся экраны, околонулевой, или закрыть третим узким дисплеем, или какой‑нибудь маскирующей перемычкой, и второе — поставить качественные камеры.

Концептуально новое устройство не может быть дешёвым, оно всегда дорогое. А от дорогого ждут отсутствия компромиссов. Новое нужно шлифовать до конца, а не выбрасывать на рынок недоделанное. У нового и так высокий риск из‑за той самой новизны, и добавление к нему недоделанности превращает риск в почти 100% провал.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность