Bite the Byte

2021-04-28 20:21:21 За минулий тиждень написав аппку-приклад для твінспарку і навіть сюжет для відео — вирішив зробити начисту замість стріму. Не певен, що це було найкращім рішенням, бо шось гемору так багато, шо капець. ಠ_ಠ

Вчора зробив з десяток дублів. Повноцінних усього парочку, але все одно, задовбався в доску. Спочатку сам тупив критично, потім обс, яким я записував камеру, вимахувався, типу хвилинку записує, а потім кадр в пару секунд максимум. Все сіпається і ковбаситься. Думав може процесор тротлить, але навантаження не завелике, температура не росте, хз що воно таке.

Сьогодні подивився на то все і зрозумів, що я можу квіктаймом все записати! В ньому окремо можна запустити запис екрану, і окремо захват з камери, і він записує обидва відео без проблем взагалі і без навантаження на процесор. Супер!

Тож в доволі короткий час я записав все що треба. Ура, 80% праці зроблено! Лишилося тільки змонтувати і почистити звук, тобто ще 80% роботи.

Думаю чи не звернутися мені до професіоналів… бо я ж ще не вмію файнал кати всі та інше. :/ Але непокоїть що там треба фокус то на код наводити, то ще кудись, чи воно реально з кимось зконтактувати, щоб і нормально вийшло, і всі штани не зняли… Але загалом я прям дуже радий, що нарешті зробив та записав це. :) Відкрити / Коментувати

2021-04-27 23:12:04 В мене у Києві є улюблений ресторан. Насправді, назвати це місце рестораном важко… але вони готують їжу, і в них можна сісти у залі поїсти (хоча останній рік тільки на виніс), і це не фаст-фуд, тож мабуть таки ресторан?

Це Пекін на вулиці Васильківській, навпротив корпусів універститету Шевченка. Так, у Києві є ще інші ресторани з такою назвою, і є багато інших китайських ресторанів та доставок, але всі вони — не те.

Бао, наприклад, це надто висока кухня. Дорого, смачно, і не зовсім китайське. А ще я оселився неподалік від Хан Юуан у НАУ — гадав, що буду часто в них їжу брати. Але я там не був вже роки зо три, тому що це не смачно. Дак пліз кльовий і смачний, але трішечки воно європеїзоване. Може якістю підхода, не знаю, але Пекін це найближче до тих китайських генделів Малайзії та Сінгапуру, де я їв. Сєва, який три місяці провів у Китаї, підтверджує автентичність.

Але до одного місця та автентичність насправді! Смак — от за чим ми женемося. Воно смачнюще. Є блюда, з яких я не тащусь, але є…

Раніше там всередені взагалі був сюр і гнучкі алюмінієві виделки. Гнучки не у сенсі «гнучка компанія», а у сенсі «вирівняй перед тим, як їсти», як ото у совкових столовках. Але вони оновили інтер‘єр, поміняли посуд і тепер просто так собі. :)

Це не висока кухня, це смачна кухня. Обожнюю і свиню по-пекінськи, і курку по-сичуанськи, і яловичину з китайськими приправами, і смажені пельмені з бараниною, і купу купу всього іншого. Взагалі, якщо в темі і я не згадав ваше улюблене, пишіть в коментарях для тих, хто там не був, бо Пекін сяє наче Бетельгейзе у світі китайських ресторанів Києва. :) Відкрити / Коментувати

2021-04-26 16:03:52 Кеш — це спосіб уникнути штрафів повторення виконання один і тих самих операцій. Найпростіше, що можна собі уявити — це функція memoize, яка допоможе порахувати числа Фібоначчі швидко без того, щоб думати над алгоритмом. :)

У веб-сервісах є багато шарів, де можна закешувати результат. Перше, що приходить до голови — це кешування запитів до БД. Зазвичай че запит у інший процесс (власне, процес БД), або навіть через мережу у іншого сервера. Тож ми берему якусь кльову бібліотеку (або пишемо самі), якій кажемо: кешуй виклик оцієї функції в залежності від цих аргументів. І параметри до нашого запиту починають параметризувати і кеш. Це буває дуже ефективне місце, навіть якщо кешуємо результати ми у memcached, до якого теж ходимо по мережі. Особливо це ефективно, коли запит складний, а варіативність параметрів низька. У найбільш яскравих випадках взагалі є сенс підраховувати результати заздалегідь і класти їх в базу, отримуючи, так би мовити, нескінченне кешування.

Наступний шар — це рендерінг шаблонів. Йдуть роки, а генерація строк залишається однією з найбільш ємних частин веба. Навіть якщо цей шаблон — це JSON, і (на відміну від більшості ліб шаблонів) генерація написана на C, це займає доволі багато ресурсів. Тож ми можемо закешувати його. Тут треба дуже уважно слідкувати за варіативністю параметрів: якщо у результати попадає ім'я користувача, ми ризикуємо генерувати кеш для кожного користувача окремо і тоді ефективність такого кешування впаде до плінтуса. При цьому при розробці (та тестуванні) все буде виглядати нормально, тому що користувач-то один буде. Це те саме місце, де можна відчути, що кеш — одна з наскладніших проблем у програмуванні.

І з важливого є ще один шар, власне HTTP. У протокол HTTP вбудований механізм кешування, який імплементовано і в браузерах, і в різних балансувальниках нагрузки, як от в nginx чи у Cloudflare. Він нам дуже цікавий, тому що дозволяє навіть з доволі повільним бекендом (на Django чи то на Rails) мати сайт, який відносно нормально витримує навантаження. У будь-якій HTTP відповіді можна додати хедер Cache-Control: max-age=3600 (припустимо), і браузер, який отримав цю відповідь, ще годину не буде повторювати цей запит. Ще цікавіше: якщо перед нашим сервером сидить якийсь проксі, то він теж закешує ту відповідь і жоден запит з будь-яких браузерів з тим самим урлом вже не прилетить до бекенду.

Ми цим кешуванням дуже широко користуємося у Касті. Як API, так і усі публічні сторінки рендеряться так, наче їх дивиться анонім, а потім фронтенд біжить і довантажує кастомні елементи (насправді, у більшості випадків — хедер, де є ім'я користувача).

Правильно побудоване кешування — дуже ефективна штука, тому що найшвидший код — це той, який не потрібно виконувати. Відкрити / Коментувати

2021-04-24 16:21:01 Ми у коментах до попереднього посту трішки обговорили, чому M1 від Епла такий швидкий, що вони його всюди пхають. Вся історія в тому, що процесори зараз являють собою зовсім не те, що вони намагаються з себе зобразити, тому що їх архітектура вже дуже давно пішла уперед, а увесь софт у нас все ще пишеться, наче ми маємо чесний x86. Це значить, що x86 — це лише фасад, тобто декодер, який з інструкцій x86 робить інструкції для справжнього процесора.

А справжній процесор — це дуже швидке звірятко 10 розряду, ще й супер-скалярне: тобто воно може виконувати кілька операцій за один такт. Тобто декодер годує то звірятко інструкціями у внутрішньому форматі, і воно їх жере по кілька за раз.

Але ж виконати x = 1 + 2; y = x + 1 за один такт неможливо, бо y залежить від x. Через це процесори всередині змінюють порядок інструкцій, щоб мати змогу використовувати свої непересічні здібності. Тож ефективність процесору дуже залежить від ефективності декодеру, щоб він встигав декодувати достатньо інструкції, щоб було що пересортувати.

Це спільна риса і x86, і ARM процесорів, тому що кожна архітектура процесорів має свої властивості і заставляти світ перекомпілювати увесь софт під новий процесор при кожному релізі нереально. Отож і маємо товстезний шар сумісності.

Ось і наблизились ми до суті історіі. x86 мають довільну довжину інструкції, наразі від 1 до 15 байт. І це значить, що розпаралелити декодування дуже важко. Статті, які я читав, рапортують, що максимальна кількість декодерів у процах Інтела та АМД - 4 на кожне ядро проца.

На відміну від них, у ARM інструкції завжди по 4 байта, тобто бери нарізай бінарник як хочеш і пхай у декодери. І в M1 зараз 8 декодерів. І внутрішнє звірятко через те дуже-предуже ефективне.

Не тільки у цьому річ, авжеж, ще є дуже цікава архітектура пам'яті, плюс всі частини проца зроблені дуже ефективно — люди в обговореннях приводили у приклад якийсь тормозний самсунг на 6 декодерів. Але найголовніша причина — ось вона. Відкрити / Коментувати