Comments 22
Сжатие данных обозначает декомпрессию на чтениях
Может я совсем старый, но это точно по русски?
Самым практичным типом является int32, потому что в него помещаются
большинство значений, которыми оперируют программы. При этом часто 32
бита гораздо больше, чем необходимо для хранения информации.
ChatGPT - он такой. Бред несет Загадочный.
Уверен, что не на английском! :)
Кажется, это разговорный стиль иностранных R&D :)
Сжатие данных обозначает декомпрессию на чтениях - это потеря времени. В настоящие дни имплементации алгоритмов стараются утилизировать векторные операции процессора для ускорения. Бенчмарки методов сжатия обычно сравниваются по гигабайтам в секунду, которые обрабатывает имплементация.
Это на эльфийском?
В статье не столько алгоритмы сжатия, сколько алгоритмы трансформации данных.
Все это говорит о том, что эти алгоритмы заточены под
пакетнуюпотоковую обработку данных. Но, что если после сжатия массива целых чисел, все еще нужен доступ по индексу? Об этом в следующей статье.
Скорее всего речь тут о том, что для получения какого-то значения из упакованного потока нужно распаковать весь поток перед этим. Но написано тоже на эльфийском диалекте
Скорее всего речь тут о том, что для получения какого-то значения из
упакованного потока нужно распаковать весь поток перед этим.
Не всегда есть необходимость распаковывать весь поток, можно указать смещения и распаковать часть данных.
О потоках речь не идет, потому что поток - это байты, которые поступают. Здесь это не важно, эти же алгоритмы применяются для архивации иммутабельных данных.
Это значит что данные пакуют блоками. Как раз чтобы не распаковывать с самого начала из-за пары байт в конце.
Сам так делал когда писал читалку для мобильного. Чтобы можно было произвольно перемещаться по тексту разбивал весь текст на блоки по 4096 байт и каждый блок упаковывал отдельно + в начале индекс на начало каждого блока.
Статья похожа на беглый обзор методов, ну ок, а почему ни слова о префиксных кодах? Это целый класс алгоритмов именно для компактного представления целых чисел.
При каких условиях long long имеет 128 бит (язык, компилятор, cpu)? Ну и в целом ощущение что статья написана chat gpt (но зачем?)
При каких условиях long long имеет 128 бит (язык, компилятор, cpu)?
Спасибо, что заметили. Такие компиляторы похоже необщеприняты.
При этом long long в плюсах может быть >= 64 бит: https://stackoverflow.com/questions/2143157/is-the-type-long-long-always-64-bits?rq=3.
Пожалуй, лучше было упомянуть long double, тут есть известные 128битные реализации: https://www.ibm.com/docs/ru/aix/7.1?topic=sepl-128-bit-long-double-floating-point-data-type
При каких условиях long long имеет 128 бит (язык, компилятор, cpu)?
В фортране вместо всяких "long long" обычно пишут числом (1, 2, 4, 8, 16...). Это полезно
для переносимости программ
число байт - оно ведь на всех архитектурах число, причем можно быть уверенным, что почти всегда то же самое ;-)
На фоне современных языков такой стиль может показаться архаичным, зато можно быть почти уверенным, что если программа компилируется под какую-то архитектуру без грязных ругательств, то скорее всего, она будет под ней работать так, как задумано. То есть 4-байтовый real/integer не превратится прозрачно для программиста в 8-байтовый, и наоборот ;-)
Однако, насколько я знаю, поддержка типа integer(kind=16) все еще зависит от компилятора. В частности, GNU фортран вроде бы поддерживает, начиная с G95. А вот мой Intel фортран 2013г - не поддерживает. Хотя real(kind=16) у меня есть и вполне себе работает.
Что интересно,
несмотря на заявления о полной совместимости компилятора со Студией 2008 (в которую Intel Fortran XE 13 действительно интегрируется), встроенный в VS2008 отладчик на моих real(16) конкретно глючит. Я сперва не мог понять, что происходит: открываю в отладчике переменную, а там бред какой-то. Но если не смотреть под отладчиком, а просто напечатать значение или присвоить его куда-то, то все Ок. Т.е. глюк именно в VS..
В фортране вместо всяких "long long" обычно пишут числом (1, 2, 4, 8, 16...). Это полезно
Ну да, в C для этого придумали всякие uint32_t (https://en.cppreference.com/w/c/types/integer ), конечно стало удобнее чем до этого когда каждый разработчик кросс-платформенных приложений изобретал свои костыли чтобы получить целое числа фиксированного количества бит
Сжатие данных обозначает декомпрессию на чтениях - это потеря времени.
Вселенная не заканчивается на процессорах общего назначения. В проектах FPGA и микроконтроллерах, где ОЗУ измеряется в мегабитах (а то и в килобитах) есть место рационального использования ресурсов.
Вариантный метод довольно интересен, необязательно именно в виде, представленным в статье. Например, одним сервисным битом переключать 7 или 31 бит на полезную нагрузку.
Вселенная не заканчивается на процессорах общего назначения. В проектах
FPGA и микроконтроллерах, где ОЗУ измеряется в мегабитах (а то и в
килобитах) есть место рационального использования ресурсов.
Имел ввиду, время процессора. Конечно, для этого бывают свои причины.
Вариантный метод довольно интересен, необязательно именно в виде,
представленным в статье. Например, одним сервисным битом переключать 7
или 31 бит на полезную нагрузку.
Далек от микроконтроллеров, но рад, что навело на какие-то мысли!
ZIgZag забыли
protobuf что-то такое умел, только кому оно на самом деле надо?
А вы чем мегабайты структур гоняете между сервисами? Джысоном?
Всякое бывает. Структуры в реальности не только из целых состоят, там ещё строки бывают и плавающая точка и всё прочее.
Так что ради только целых заморачиваться не приходилось. В любом случае, если для канала мегабайты уже проблема, а время нет, так сериализируйте как умеете, а дальше b/g/lzip куда проще будет, чем свой велосипед изобретать
Сжатие целых чисел