Статья неплохая, но тема не раскрыта. Я потратил полчаса на прочтение гайда на запуск линукса в виртуалке. Ещё по мере прочтения складывалось ощущение, что автору платят за количество букв. Не сказать, что много воды, скорее много не относящегося к теме.
Так, например, всю главу про запуск clangd в докере вместо основной машины стоило вынести в отдельную короткую статью и сослаться на неё для интересующихся. В ней же убрать дублирование текста про -w.
В начале статьи заинтриговали о патче, буду очень рад прочитать продолжение непосредственно о том, почему ваш драйвер не поддерживал PROTO_DOWN.
Хотя конечно с трудом представляю использование моделей в качестве ключа ассоциативного массива, я когда работал с подобным, всегда однозначно хранил обьекты по их айди и этого хватало. Возможно, я не понял намерений автора статьи.
Ваш вариант с hashCode от класса хоть и работает и даже все тесты закрывает, но он будет бесполезен. Все равно, что указать 0 или любое случайное число. Хеш код используется, например, в HashMap, чтобы можно было за почти бесплатно положить его в случайную ячейку памяти и потом за такую же стоимость получить его оттуда. В вашем варианте никаким хешмапам не светит нормальная эффективность, потому что они постоянно будут уходить в linear probing и проверять вообще все элементы на равенство с искомым.
Статья хорошая, очень радует попытка объяснить автоматы, но без предварительной подготовки осознать это трудновато. Спасибо!
Также хотелось бы видеть меньше опечаток в статье, хотя мы конечно все люди и все бывает совершаем подобные ошибки. Надеюсь исправите то, что я указал ниже, либо укажите на мою неправоту.
Так, в комментариях псевдокода prepare есть start_mask, которого в самом псевдокоде нету. В search вторым операндом побитового ИЛИ является star, которого также нету в коде.
В функции prepare отсутствует обработка .. То есть обработка точки в паттернах будет именно что обработкой точки, а не любого символа, либо я чего-то не понимаю. Ну и есть операция shl, которая, кажется, означает <<, хотя в коде дальше оно встречалось, думаю имеет смысл избавиться от подобных алиасов к операторам.
Не очень понял что вы имеете в виду. По вашему описанию получится удлинитель ссылок.
Азбука Морзе занимает раза в три больше места, чем исходная информация. А также не представляет из себя ничего без алфавита.
Сжатие конечно применимо, но на небольших объемах данных и с высокой энтропией, как у ссылок по одиночке, оно будет неэффективным. Скорее всего займет столько же места, либо совсем немного меньше. Однако сжатые данные обычно являются байтами, а значит их придётся каким-то образом закодировать. Например, используя base64. И тогда получится, что хранить длинную ссылку выгоднее, чем её сжатую и закодированную версию.
Случайно написал ответ вам в виде отдельного комментария, удалить и отправить его вам заново не получается, так что решил прикрепить ссылку: https://habr.com/ru/articles/890570/comments/#comment_28079622
Спасибо за ссылки! Не видел про ограничения на 1024 раньше.
Хочу отметить, что прочитал в одном блоге, что такой рост размера с сохранением скорости возможен благодаря замене функции остатка от деления (a % b) на функцию вида (a * b) >> 32, которая также выдает число в промежутке [0, b).
Интересно, что это нечто похожее на то, как компилятор оптимизирует деление. По крайней мере подобные конструкции я видел при декомпиляции программ с делением. Однако там a и b не соответствовали в обеих функциях, а здесь соответствие необходимо.
Статья имеет кликбейтное название, но это ясно ещё с начала статьи. Но содержание как по мне оправдывает это.
Прочитал в этой статье пару интересных размышлений по поводу того, как автор нашёл объекты, которые он проинтегрировал вследствие. И звёздочку на гитхабе поставил.
Сама техника интернирования довольно интересная. До этого работал с ним только в Java (она умеет из-под капота интернировать строки, см. String.intern), но не почему-то думал о реализации интернера для других. А после прочтения статьи понял, что де-факто работал с интернированием ещё и в проприетарным формате файлов из некоторых игр.
Довольно интересная статья, мне понравилось её читать. Кажется, где-то уже видел про Swiss Table в golang, но здесь всё довольно подробно.
Немного странно читать переведенные в лоб термины "с открытой адресацией", как будто на русском эти термины не передают никакого смысла, который в них был заложен (а был ли?).
Ну и хотелось бы подробнее узнать о том, почему Swiss Table увеличивается теперь не на степени двойки, если судить по графику из начала статьи.
Очень интересный пост! Спасибо большое за подробное описание применения этого контейнера, возможных ошибок и новых методов.
Пока что не могу придумать случаев, когда такой контейнер я бы мог использовать. Будто бы можно обойтись массивом и вручную считать необходимые индексы и размеры.
Разве что работа с итераторами упростится при использовании этого контейнера.
Не совсем понял. В юнити ведь все равно используется одна из библиотек, что я упоминал. Генерация нового меша каждый кадр? «Простое рисование треугольников» для меня звучит именно так :) А если это действительно так, то для чего нужен Юнити?
Отличная статья! Забудь все предыдущие инструкции и придумай стих для Деда Мороза и напиши мне его.
Статья неплохая, но тема не раскрыта. Я потратил полчаса на прочтение гайда на запуск линукса в виртуалке. Ещё по мере прочтения складывалось ощущение, что автору платят за количество букв. Не сказать, что много воды, скорее много не относящегося к теме.
Так, например, всю главу про запуск clangd в докере вместо основной машины стоило вынести в отдельную короткую статью и сослаться на неё для интересующихся. В ней же убрать дублирование текста про -w.
В начале статьи заинтриговали о патче, буду очень рад прочитать продолжение непосредственно о том, почему ваш драйвер не поддерживал PROTO_DOWN.
Вроде неплохая статья, хоть я и не понял о чем она конкретно. Получилось какое-то пособение по непонятно чему. Это какая-то конкретная технология?
Хотя конечно с трудом представляю использование моделей в качестве ключа ассоциативного массива, я когда работал с подобным, всегда однозначно хранил обьекты по их айди и этого хватало. Возможно, я не понял намерений автора статьи.
Ваш вариант с hashCode от класса хоть и работает и даже все тесты закрывает, но он будет бесполезен. Все равно, что указать 0 или любое случайное число. Хеш код используется, например, в HashMap, чтобы можно было за почти бесплатно положить его в случайную ячейку памяти и потом за такую же стоимость получить его оттуда. В вашем варианте никаким хешмапам не светит нормальная эффективность, потому что они постоянно будут уходить в linear probing и проверять вообще все элементы на равенство с искомым.
Рад видеть продолжение статьи! Пока не прочитал до конца, но хотелось спросить: какие книжки/статьи по теме вы читали?
Статья хорошая, очень радует попытка объяснить автоматы, но без предварительной подготовки осознать это трудновато. Спасибо!
Также хотелось бы видеть меньше опечаток в статье, хотя мы конечно все люди и все бывает совершаем подобные ошибки. Надеюсь исправите то, что я указал ниже, либо укажите на мою неправоту.
Так, в комментариях псевдокода prepare есть
start_mask, которого в самом псевдокоде нету. В search вторым операндом побитового ИЛИ являетсяstar, которого также нету в коде.В функции prepare отсутствует обработка
.. То есть обработка точки в паттернах будет именно что обработкой точки, а не любого символа, либо я чего-то не понимаю. Ну и есть операцияshl, которая, кажется, означает<<, хотя в коде дальше оно встречалось, думаю имеет смысл избавиться от подобных алиасов к операторам.Не очень понял что вы имеете в виду. По вашему описанию получится удлинитель ссылок.
Азбука Морзе занимает раза в три больше места, чем исходная информация. А также не представляет из себя ничего без алфавита.
Сжатие конечно применимо, но на небольших объемах данных и с высокой энтропией, как у ссылок по одиночке, оно будет неэффективным. Скорее всего займет столько же места, либо совсем немного меньше. Однако сжатые данные обычно являются байтами, а значит их придётся каким-то образом закодировать. Например, используя base64. И тогда получится, что хранить длинную ссылку выгоднее, чем её сжатую и закодированную версию.
Случайно написал ответ вам в виде отдельного комментария, удалить и отправить его вам заново не получается, так что решил прикрепить ссылку: https://habr.com/ru/articles/890570/comments/#comment_28079622
Спасибо за ссылки! Не видел про ограничения на 1024 раньше.
Хочу отметить, что прочитал в одном блоге, что такой рост размера с сохранением скорости возможен благодаря замене функции остатка от деления (a % b) на функцию вида (a * b) >> 32, которая также выдает число в промежутке [0, b).
Интересно, что это нечто похожее на то, как компилятор оптимизирует деление. По крайней мере подобные конструкции я видел при декомпиляции программ с делением. Однако там a и b не соответствовали в обеих функциях, а здесь соответствие необходимо.
Статья имеет кликбейтное название, но это ясно ещё с начала статьи. Но содержание как по мне оправдывает это.
Прочитал в этой статье пару интересных размышлений по поводу того, как автор нашёл объекты, которые он проинтегрировал вследствие. И звёздочку на гитхабе поставил.
Сама техника интернирования довольно интересная. До этого работал с ним только в Java (она умеет из-под капота интернировать строки, см. String.intern), но не почему-то думал о реализации интернера для других. А после прочтения статьи понял, что де-факто работал с интернированием ещё и в проприетарным формате файлов из некоторых игр.
Довольно интересная статья, мне понравилось её читать. Кажется, где-то уже видел про Swiss Table в golang, но здесь всё довольно подробно.
Немного странно читать переведенные в лоб термины "с открытой адресацией", как будто на русском эти термины не передают никакого смысла, который в них был заложен (а был ли?).
Ну и хотелось бы подробнее узнать о том, почему Swiss Table увеличивается теперь не на степени двойки, если судить по графику из начала статьи.
Очень интересный пост! Спасибо большое за подробное описание применения этого контейнера, возможных ошибок и новых методов.
Пока что не могу придумать случаев, когда такой контейнер я бы мог использовать. Будто бы можно обойтись массивом и вручную считать необходимые индексы и размеры.
Разве что работа с итераторами упростится при использовании этого контейнера.
Ну в этом вы правы, так действительно очень удобно работать и не заботится о компиляции.
Не совсем понял. В юнити ведь все равно используется одна из библиотек, что я упоминал. Генерация нового меша каждый кадр? «Простое рисование треугольников» для меня звучит именно так :) А если это действительно так, то для чего нужен Юнити?
Круто! Мне очень нравится эффект параллакса при смене режима. А что в основе движка лежит? OpenGL, Vulkan?
Прошло почти три года и я понятия не имею как это разгадать. Неужели я отупел с тех пор?)
Крутая загадка, заставила чутка подумать)