> Переводчик у меня спрашивает оригинал. Ну такое )))
А, понял )
> Словарь делается РАЗ и НАВСЕГДА. Ага. А сам текст - это индексы словаря. Новые слова - новые индексы. Формально, он без ограничений (по логике, по архитектуре - по 2 миллиона на словарь, которых 16 на данный момент).
Опять понял. Ну, для архиватора это не очень подходяще, потому что на той стороне (на стороне раскодировщика) должен быть такой же словарь, а это не всегда возможно.
Для архиватора имеет смысл построить словарь перед кодированием, а сам словарь тоже запаковать и включить в архив. И, кстати, некоторые причудливые экспериментальные архиваторы так и делают, которые участвуют в бенчмарках state of art. Правда, их всех натянул на шишку nncp, который использует для сжатия нейросети. Более практичный вариант предполагает, что словарь строится и корректируется на лету, в процессе получения новых символов из буфера. Тогда его не нужно передавать в архиве, потому что он будет аналогичным образом строиться на лету при декодировании.
Твой алгоритм позволяет делать что-то из этих двух вещей? Типа, 1) хотим запаковать файл, строим для него словарь, кодируем файл с использованием словаря, включаем в архив словарь и закодированный файл. 2) Строим словарь на лету, перестраиваем его после каждого символа (или после каждых N символов, если операция долгая) и кодируем файл на лету с использованием текущей версии словаря.
Абсолютно верно. С другой стороны, ну архиватор у тебя будет 100 мегабайт. Мне вон, вчерась, Вестерн Диджитл, подкатил (заметив мой интерес к 15 терабайтным винтам) де, не хотите ли 22 террабайта приобрести, у нас тут и скидочка. А если совсем уж (ебобо на голову) плохо у нас вот - в 45 терабайт 3.5 формфакторе есть. Не интересует, не? ))) Падлы, убил бы. ))))
Ты всё правильно описал. Но ты не понял СМЫСЛА моего словаря. Он для хранения охуенно большого количества.... Книг. Библиотека грубо говоря. Что бы имея в среднем программу в 120 мегабайт на всё про всё, я имел почти всю Флибусту на смарте. Вот в чем цимес. Ничего иного там нет, и не ищи ))) Я ж говорил тебе, я с архиваторами не дружу, так как матан их для меня не неподьёмный, но напрягающий. А зачем мне напрягаться? ))))
А и да. Там я тебе могу сказать так, после первых 2000 книг, новых слов - единицы, а то и нету вовсе. В основном это "эээ-ээ" и "э-эээ-э" ну и такие каличи, их конечно можно привести к единообразию (что тоже та еще фигня, мало ли что там автор имел ввиду) но смысла нету, дополнительный словарь который идёт с книгой, решает эту пробему на ура.
В остальном - да, надо всегда иметь актуальную версию пакера, или есть риск, что новая книга тупо некорректно (открыться то она откроется, к слову, ты подкинул мне идею про защиту от такой ереси, за что тебе спасибо огромное, я как то ступил на примитивной фигне) откроется и не целиком отобразится. Но так как это не "мобайл", а "стационар", это и вовсе копеечное дело. И к слову, я уже даже знаю куда можно это пристроить ))) Додумался ))))
А и да. Ты то Пчёлку свою то обнови (и сырцы скинь мну). Очень хороша. Весьма и весьма. Именно для текста. С мултёй, ну... Ты понял. Но не то что бы пиздец как плохо.
Однажды я тебя снова об этом спрошу. Эта штука, которую ты там пишешь, может быть основой для словарного препроцессора перед универсальным алгоритмом сжатия. Если сейчас нет, то потом может быть да.
Ты слышал про LZP? Эта штука как раз используется как препроцессор текстов перед универсальным алгоритмом сжатия, много где. Посмотри описание, она чем-то похожа на то, что ты делаешь.
Что касается более новой версии Bee, но оно там внутри настолько кривое и некрасивое, что мне отвратительно выкладывать это в публичный доступ. Возможно, позже. Сейчас меня не устраивает то, что в текущей версии.
По поводу основы. Я конечно, не средняк, иногда у меня бывает и топовые накаты, но я очень не считаю, что кто то не додумался (да и ты сам в целом и общем подтвердил, с LZP что не я один такой умный) до того, что додумался я. Нет. У меня есть пару решений, которыми мы все пользуемся. Они небольшие, но, они есть. Что сие - пока молчу (там и так выгода, так себе, а вот если схлопочу штраф - то буду с голой дупой бегать, так что тупо сорри, не то что бы я тебе не доверял, но инфа имеет свойство утекать из того, чего даже не подозреваешь). Но в целом, я профи в изготовлении конфетки из имеющегося. Грубо говоря, я не могу придумать рецепт - но могу его улучшить настолько, что ты офигеешь. Но не более.
По поводу Бии (Би немного не о том намекает, поэтому намерено искажаю).... То что это написано ПЛОХО, я уже понял. То что это написано неэффективно - туда же, в ту же копилку. Вопрос в другом, если ты не имеешь левых ограничений как я, и доверяешь мне - я тупо могу переписать это все и с оптимизацией (читай выше), и на более шустром ланге.
Есть исходники старой версии, они там же, где и дистрибутив. Новая в два раза тормознее при увеличении степени сжатия на 2% от старой версии. Оно тебе надо?
Надо. Потому как прогер ты хуёвый. Именно прогер. К ПРИМЕРУ, вместо 20 * 0,1 ты пишешь 20 / 10.... И вот тут то у тебя начинается жопа. (нет, результат то будет 2... Только в раз 15 медленней во втором случае). Ты не учитываешь железо.
Увы
Апд. я всегда вначале вытягиваю сырцы, а потом уже компилянт. Так что сам понимаешь.
Наверняка где-то в моих исходниках такой косяк наблюдается, но вряд ли массово. Ну и понятно, что умножение в камне выполняется быстрее деления, но "в 15 раз медленнее" это ты загнул.
Оно даже если в чистом виде считать, то не в 15 раз медленнее, а вообще не медленнее, только задержка большая. Но задержка скрывается за счет Out-of-order выполнения, так что разница всё равно меньше, чем кажется. Гораздо хуже, что дельфийский говнокомпилятор накручивает говна вокруг вызовов функций, передачи параметров, а инлайнит так, что я рыдаю кровавыми слезами. За счёт вычёсывания блох иногда удаётся локально ускорить код в 2-3 раза, без всяких MUL/DIV.
Меня гораздо больше волнует, чтобы код был сначала красивый и читаемый, а потом уже быстрый. Иногда удаётся получить красивый и читаемый код, и при этом быстрый. Любопытно так же, что красивый исходник часто и компилится в эффективный код.
К чему я? Ситуация ужасная, но не ужасная-ужасная.
A RT ты решил проигнорить. Если латенси еще куда б не шло, то вот РТ - те самые 15 раз. И фиг ты там что сделаешь. Да и мисматч кэша тоже знаешь, никто не отменял. И теперь представь, у тебя сцена содержит порядка 300 тыс (сейчас норма порядка 3 миллионов) вершин. Это три флоата. (хотя конверт с флоата в инт и взад занимает меньше времени. Вообще то надо было x87 смотреть. Там не так всё плохо, всего лишь семикратно, но в таких массивах возникают пробемы с "загрузкой" в регистры (а то, то, что ты выложил, это чутка совсем другая сториз )))
OtO тут к слову ты опять немножко не туда. Но фишка в том, что это вылетает из кэша очень и очень часто. Поэтому у тебя проблема в Lat. и в RT. А это - пиздец проблема. Размером с хороший грузовик.
Впрочем, чего это я страдаю хернёй? Подожди ка. Сча я тут кое что сделаю. Черт, неудобно то таймер прицепливать будет к такой хернёвенке...
1) Я же не спорю, делений нужно избегать. 2) В старом исходнике большинство делений на степень двойки, их компилятор самостоятельно заменяет на shr практически везде, потому я их и оставил в явном виде. 3) x87 это рудимент в x32. SSE пизже, только из-за него одного уже имеет смысл компилить под x64.
Ты вытянул сырец Bee 0.78 и увидел там страшное? Смотреть надо на Bee_Modeller, Bee_Codec и Bee_Rangecoder, в них выполняется 99% времени кода.
Я сейчас выполню тесты старой / новой / новейшей версий Bee на упаковке 100Mб дампа википедии (файл enwik8), и выложу сравнительную таблицу. Станет видно, хороша ли новая / новейшая версия по сравнению со старой:
Опции не эквивалентны, потому что используется разная формула вычисления вероятностей. Новая версия даёт лучшее сжатие -m3, так как затачивалась на степень сжатия. Оно такое надо?
> Переводчик у меня спрашивает оригинал. Ну такое )))
А, понял )
> Словарь делается РАЗ и НАВСЕГДА. Ага. А сам текст - это индексы словаря. Новые слова - новые индексы. Формально, он без ограничений (по логике, по архитектуре - по 2 миллиона на словарь, которых 16 на данный момент).
Опять понял. Ну, для архиватора это не очень подходяще, потому что на той стороне (на стороне раскодировщика) должен быть такой же словарь, а это не всегда возможно.
Для архиватора имеет смысл построить словарь перед кодированием, а сам словарь тоже запаковать и включить в архив. И, кстати, некоторые причудливые экспериментальные архиваторы так и делают, которые участвуют в бенчмарках state of art. Правда, их всех натянул на шишку nncp, который использует для сжатия нейросети. Более практичный вариант предполагает, что словарь строится и корректируется на лету, в процессе получения новых символов из буфера. Тогда его не нужно передавать в архиве, потому что он будет аналогичным образом строиться на лету при декодировании.
Твой алгоритм позволяет делать что-то из этих двух вещей? Типа, 1) хотим запаковать файл, строим для него словарь, кодируем файл с использованием словаря, включаем в архив словарь и закодированный файл. 2) Строим словарь на лету, перестраиваем его после каждого символа (или после каждых N символов, если операция долгая) и кодируем файл на лету с использованием текущей версии словаря.
Reply
Абсолютно верно. С другой стороны, ну архиватор у тебя будет 100 мегабайт. Мне вон, вчерась, Вестерн Диджитл, подкатил (заметив мой интерес к 15 терабайтным винтам) де, не хотите ли 22 террабайта приобрести, у нас тут и скидочка. А если совсем уж (ебобо на голову) плохо у нас вот - в 45 терабайт 3.5 формфакторе есть. Не интересует, не? ))) Падлы, убил бы. ))))
Ты всё правильно описал. Но ты не понял СМЫСЛА моего словаря. Он для хранения охуенно большого количества.... Книг. Библиотека грубо говоря. Что бы имея в среднем программу в 120 мегабайт на всё про всё, я имел почти всю Флибусту на смарте. Вот в чем цимес. Ничего иного там нет, и не ищи ))) Я ж говорил тебе, я с архиваторами не дружу, так как матан их для меня не неподьёмный, но напрягающий. А зачем мне напрягаться? ))))
А и да. Там я тебе могу сказать так, после первых 2000 книг, новых слов - единицы, а то и нету вовсе. В основном это "эээ-ээ" и "э-эээ-э" ну и такие каличи, их конечно можно привести к единообразию (что тоже та еще фигня, мало ли что там автор имел ввиду) но смысла нету, дополнительный словарь который идёт с книгой, решает эту пробему на ура.
В остальном - да, надо всегда иметь актуальную версию пакера, или есть риск, что новая книга тупо некорректно (открыться то она откроется, к слову, ты подкинул мне идею про защиту от такой ереси, за что тебе спасибо огромное, я как то ступил на примитивной фигне) откроется и не целиком отобразится. Но так как это не "мобайл", а "стационар", это и вовсе копеечное дело. И к слову, я уже даже знаю куда можно это пристроить ))) Додумался ))))
А и да. Ты то Пчёлку свою то обнови (и сырцы скинь мну). Очень хороша. Весьма и весьма. Именно для текста. С мултёй, ну... Ты понял. Но не то что бы пиздец как плохо.
Reply
Однажды я тебя снова об этом спрошу. Эта штука, которую ты там пишешь, может быть основой для словарного препроцессора перед универсальным алгоритмом сжатия. Если сейчас нет, то потом может быть да.
Ты слышал про LZP? Эта штука как раз используется как препроцессор текстов перед универсальным алгоритмом сжатия, много где. Посмотри описание, она чем-то похожа на то, что ты делаешь.
Что касается более новой версии Bee, но оно там внутри настолько кривое и некрасивое, что мне отвратительно выкладывать это в публичный доступ. Возможно, позже. Сейчас меня не устраивает то, что в текущей версии.
Reply
По поводу основы. Я конечно, не средняк, иногда у меня бывает и топовые накаты, но я очень не считаю, что кто то не додумался (да и ты сам в целом и общем подтвердил, с LZP что не я один такой умный) до того, что додумался я. Нет. У меня есть пару решений, которыми мы все пользуемся. Они небольшие, но, они есть. Что сие - пока молчу (там и так выгода, так себе, а вот если схлопочу штраф - то буду с голой дупой бегать, так что тупо сорри, не то что бы я тебе не доверял, но инфа имеет свойство утекать из того, чего даже не подозреваешь). Но в целом, я профи в изготовлении конфетки из имеющегося. Грубо говоря, я не могу придумать рецепт - но могу его улучшить настолько, что ты офигеешь. Но не более.
По поводу Бии (Би немного не о том намекает, поэтому намерено искажаю).... То что это написано ПЛОХО, я уже понял. То что это написано неэффективно - туда же, в ту же копилку.
Вопрос в другом, если ты не имеешь левых ограничений как я, и доверяешь мне - я тупо могу переписать это все и с оптимизацией (читай выше), и на более шустром ланге.
Но как ты поступишь - это твое дело.
Reply
Есть исходники старой версии, они там же, где и дистрибутив.
Новая в два раза тормознее при увеличении степени сжатия на 2% от старой версии. Оно тебе надо?
Reply
Надо. Потому как прогер ты хуёвый. Именно прогер. К ПРИМЕРУ, вместо 20 * 0,1 ты пишешь 20 / 10.... И вот тут то у тебя начинается жопа. (нет, результат то будет 2... Только в раз 15 медленней во втором случае). Ты не учитываешь железо.
Увы
Апд. я всегда вначале вытягиваю сырцы, а потом уже компилянт. Так что сам понимаешь.
Reply
Наверняка где-то в моих исходниках такой косяк наблюдается, но вряд ли массово.
Ну и понятно, что умножение в камне выполняется быстрее деления, но "в 15 раз медленнее" это ты загнул.
Вот мануал от Агнера Фога:
https://www.agner.org/optimize/instruction_tables.pdf
MUL, IMUL r32/m32
Ops 2
Latency 3
DIV r32/m32
Ops 2
Latency 14-30
Оно даже если в чистом виде считать, то не в 15 раз медленнее, а вообще не медленнее, только задержка большая. Но задержка скрывается за счет Out-of-order выполнения, так что разница всё равно меньше, чем кажется. Гораздо хуже, что дельфийский говнокомпилятор накручивает говна вокруг вызовов функций, передачи параметров, а инлайнит так, что я рыдаю кровавыми слезами. За счёт вычёсывания блох иногда удаётся локально ускорить код в 2-3 раза, без всяких MUL/DIV.
Меня гораздо больше волнует, чтобы код был сначала красивый и читаемый, а потом уже быстрый. Иногда удаётся получить красивый и читаемый код, и при этом быстрый. Любопытно так же, что красивый исходник часто и компилится в эффективный код.
К чему я? Ситуация ужасная, но не ужасная-ужасная.
Reply
A RT ты решил проигнорить. Если латенси еще куда б не шло, то вот РТ - те самые 15 раз. И фиг ты там что сделаешь. Да и мисматч кэша тоже знаешь, никто не отменял. И теперь представь, у тебя сцена содержит порядка 300 тыс (сейчас норма порядка 3 миллионов) вершин. Это три флоата. (хотя конверт с флоата в инт и взад занимает меньше времени. Вообще то надо было x87 смотреть. Там не так всё плохо, всего лишь семикратно, но в таких массивах возникают пробемы с "загрузкой" в регистры (а то, то, что ты выложил, это чутка совсем другая сториз )))
OtO тут к слову ты опять немножко не туда. Но фишка в том, что это вылетает из кэша очень и очень часто. Поэтому у тебя проблема в Lat. и в RT. А это - пиздец проблема. Размером с хороший грузовик.
Впрочем, чего это я страдаю хернёй? Подожди ка. Сча я тут кое что сделаю. Черт, неудобно то таймер прицепливать будет к такой хернёвенке...
Reply
1) Я же не спорю, делений нужно избегать.
2) В старом исходнике большинство делений на степень двойки, их компилятор самостоятельно заменяет на shr практически везде, потому я их и оставил в явном виде.
3) x87 это рудимент в x32. SSE пизже, только из-за него одного уже имеет смысл компилить под x64.
Reply
Ты вытянул сырец Bee 0.78 и увидел там страшное?
Смотреть надо на Bee_Modeller, Bee_Codec и Bee_Rangecoder, в них выполняется 99% времени кода.
Я сейчас выполню тесты старой / новой / новейшей версий Bee на упаковке 100Mб дампа википедии (файл enwik8), и выложу сравнительную таблицу. Станет видно, хороша ли новая / новейшая версия по сравнению со старой:
0.78 enwik8
-m1 -d9 22144075 165 sec
-m2 -d9 20598091 360 sec
-m3 -d9 20554713 402 sec
1.0.38.f enwik8
-m1 -d9 24242249 126 sec
-m2 -d9 22354380 177 sec
-m3 -d9 20256844 737 sec
Опции не эквивалентны, потому что используется разная формула вычисления вероятностей. Новая версия даёт лучшее сжатие -m3, так как затачивалась на степень сжатия. Оно такое надо?
Reply
Leave a comment