Предыдущий блок Следующий блок Вернуться в индекс
 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     12 Dec 99 23:42:45
 To   : Bulat Ziganshin                     
 Subj : Re: есколько вопросов                                                        


From: leob@mailcom.com (Leonid Broukhis)

Bulat Ziganshin wrote:

> >> LB> А был бы у тебя, например, Solaris for Intel, вполне может быть,
> >> LB> что ты бы откомпилировал им, и выбросил бы bcc на помойку.
> >> он PE делает?
> LB> Расшифруй.
>
>win32 exe

Hе знаю, но для преобразования ELF в это дело, вроде, какая-то тулза есть
(то ли в Cygwin, то ли еще где).

        Leo

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 12 Dec 99 23:44:34
 To   : Dmitry Shkarin                      
 Subj : Re: BWT                                                                      


Пpиветствую, Dmitry!

12 Dec 99, Dmitry Shkarin писал к All:

 DS>     Кстати, и у Владимира тоже получается что распаковка у BA втрое
 DS> быстрее упаковки,

Hе, у меня получается два с небольшим.

 DS> но, правда у него получается что BA упаковывает втрое
 DS> медленнее чем PPMD.

Да, в 2-3 раза, в зависимости от режима. А у тебя
разве не так, судя по письму с замерами?

 DS> В чем-же дело? Вы, судя по всему, меряете чистое время
 DS> процесса, а я полное время со вводом/выводом.

А в чем разница? А, ты хочешь сказать, что используешь
какой-нибудь виртуальный диск? Или нас уличить? :)
Лично я работаю с винчестером. Hу, если только
NT ненароком закеширует :) Да ведь у нас всех вроде
замеры похожие, в пределах ошибки, вносимой разной
аппаратурой и разными файлами.

 DS> Может BA записывает данные побайтно и каждый раз
 DS> флуширует поток? ;-)

За это ручаться не могу :), но сортировка у него, как я говорил,
сырая, да и компилятор посредственный.

  Всего доброго. Vadim Yoockin

... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  13 Dec 99 00:06:20
 To   : Leonid Broukhis                     
 Subj : есколько вопросов                                                            


* Crossposted in RU.COMPRESS
Hello Leonid!

Sunday December 12 1999, Leonid Broukhis writes to Boris Batkin:
 >> >> exp откомпилирован bcc32i ;)
 >> LB> А был бы у тебя, например, Solaris for Intel, вполне может быть,
 LB> Я понятия не имею, что означает сравнение с watcom 10.0, т.к. никогда
 LB> им не пользовался.

  Вот мы тебя и поймали :)  Тебе остается поверить нам на слово, что не только 
sun и авторы gcc умеют писать компиляторы.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Vladimir Semenjuk                    2:5020/400     13 Dec 99 01:15:08
 To   : All                                 
 Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц.      


From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru>
Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц
.

Hi, Bulat !

VS> того у меня нет детального описания MNP5, MNP7 (похоже, что
VS> их особенно и не афишируют). Я знаю только, что в первом из них
VS> используется RLE (как он там устроен я тоже знаю) и какое-то
VS> префиксное кодирование (один товарищ, который судя по всему полный
VS> чайник в данной области, в своей книге написал, что это динамическое
VS> кодирование Хаффмана (модель нулевого порядка); верить ему или нет я
VS> не знаю).

BZ>   Что там хаффман - знает всякий фидошник :)  Да и в доке по модемам это
BZ> уоминается.

Я не фидошник и сомневаюсь. Только что пересмотрел все доки - нету ничего.
Это наверное какая-то специфическая дока (фидошная). Пришли, если тебе не
трудно.
А вообще странно. Вот я до этого письма был уже почти уверен, что там (в
MNP5) используется весьма своеобразный префиксный код: сначала указывается
номер группы, в которой находится символ (этот указатель состоит из 3-х бит
=> 8 групп), а затем и номер символа в группе, записанный таким количеством
бит, которое требуется для однозначного указания символа в группе. Размеры
групп распределяются почти как у Фенвика. Во время кодирования происходит
преставление символов по группам в зависимости от частоты встречаемости.
Как-то не похоже это на утку.
А может Хаффман в MNP7?

VS> Если материала больше не будет, то придется мне писать реферат на тему
VS> "перспективные технологии сжатия при передаче будущего", где я буду
VS> описывать всякие PPM-ы, CTW-ы, ACB-ы и так далее, которые вряд ли
VS> кто-нибудь когда-нибудь станет использовать в технологиях связи.

BZ>   Среди проектов Шиндлера (автора szip) по-моему есть связанные с
передачей
BZ> данных. Так что мы заказываем тебе большую статью о st :))

Я ему уже писал насчет непригодности BW к этой области. Он почему-то не
согласился :) Еще сказал, что чип с 16 мегами это "раз плюнуть". Совсем
зажирели буржуи !

С уважением,
Владимир.

E-Mail: semenjuk@unitel.spb.ru

PS. А знаете ли вы, что в V42bis используется не совсем LZW? А меня всю
жизнь лечили ... cтандартный говорили ... как в GIF-е.


--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Vladimir Semenjuk                    2:5020/400     13 Dec 99 01:15:11
 To   : All                                 
 Subj : Re: А что же лучше?                                                          


From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru>

Hi, ZAB and All !

> > Алгоритм PPMZ существует уже несколько лет. PPMZ2 появился в этом году.
> > www.cbloom.com - домашний сайт автора (Чарльз Блюм). Там про PPMZ много
> > написано. Ищи "ppmz.ps" - это описание.

Ладно. Забудь про PPMZ. Скачай себе лучше PPMD(E). Классный компрессор, да
еще и с исходниками.

Ко всем: настало время юзать PPM !

Я как-то не заметил на каком этапе PPMD так окрутел, но когда сегодня
сжимал 45 метров всяких док, был здорово удивлен. IMP "-1" дал ~16Mb, BA
"-b3000" ~ 15MB, а PPMD "-m16 -o6" ~ 13 !!! Тогда я решил провести ряд
тестов. Так вот мне кажется, что если кто-нибудь не придумает чего-нибудь
действительно гениального по поводу обработки S-представления в методе
Барроуза-Уилера, то его (BW) можно выкидывать на помойку до лучших времен
(это когда памяти у компов станет очень много). А какие у нас есть
альтернативы BW в битве с PPM-ом?
LZ слишком слаб для этого.
ACB?  Да, но его надо натаскивать на тексты, а в этом случае он рискует
слиться с PPM-ом.
Единственная надежда - CTW. Знающие люди утверждают, что CTW допускает
быстрые реализации. Однако я не представляю себе, как можно эффективно
расширить CTW на 256-символьный алфавит. Попытки были, но какие-то уж очень
неуклюжие.

Поэтому пока PPM.

С уважением,
Владимир.


--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Vladimir Semenjuk                    2:5020/400     13 Dec 99 01:34:52
 To   : All                                 
 Subj : Re: BWT                                                                      


From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru>

DS>     Заметь что после рассогласования контекстов идет незакодированный
DS> символ, так что это это некая смесь LZSS/LZ77, понятно что, путем

VS> Ага. Только со служебным битом.
VS> Дмитрий, а ты знаешь что представляют из себя  алгоритмы LZ77 и LZSS?
VS> Мне почему-то кажется, что не знаешь.

VS> PS2. Кстати, в любимой нами обзорной книжке про LZSS и LZ77 ничего не
VS> наврано :)

Беру свои слова обратно. Скорее смесь.

С уважением,
Владимир.


--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5020/400     13 Dec 99 05:20:57
 To   : All                                 
 Subj : Re: Сжатие при передаче информации      (без видео) на 20-25    полных стра      


From: Maxime Zakharov <maxime@tnet.sochi.net>
Subject: Re: Сжатие при передаче информации 
        (без видео) на 20-25 
        полных страниц.

Vladimir Semenjuk wrote:
> Есть ли другие технологии (только реально используемые)? Возможно я мало
> искал. Подскажите, если не трудно URL-ы, киньте но мылу доки и т. д.

        По-моему упущены стандарты сжатия, используемые в факсах ITU-T (CCITT)
Group 1, Group 2.
Еще можно посмотреть 3 часть comp.compression FAQ на предмет реализации
методов сжатия в виде микросхем - очевидно, что эти микросхемы так или
иначе могут использоваться в оборудовании для связи.

-- 
Maxime Zakharov
Sochi, Russia
http://tnet.sochi.net/~maxime/
--- ifmail v.2.14dev3
 * Origin: Technology Communication Centre, Sochi (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     13 Dec 99 10:05:33
 To   : Yury Reshetov                       
 Subj : Re: BWT - овчинка выделки не стоит                                           


From: leob@mailcom.com (Leonid Broukhis)

Yury Reshetov wrote:

>Во пеpвых сабж наиболее эффективен лишь для текстов, а посему текста pазмеpом
>500 кило и более не такая уж частая необходимость.
>Посему я утвеpждаю, что сабж - овчинка выделки не стоит. Ежли конечно же не
>заниматься эхотагом pади эхотага и всю жизнь жать Hабоковскую Лолиту и
>конституцию Японской ССР. Поpа уже понять, что большие pазмеpы файлов - это
>сеpьезное огpаничение на область пpименения компpессоpа и меня оно, ну никак н
е
>устpаивает. Достаточно посмотpеть файлконфеpенции ВООК, чтобы убедиться, что
>pазмеp файла более 200 кило уже pедкость.

Э-э-э, родной, ты, наверное, web logs не видел. Пока для них не будет написано
специального компрессора, BWT останется лучшим по speed/comp.ratio.

        Leo

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     13 Dec 99 10:05:45
 To   : Vladimir Semenjuk                   
 Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц.      


From: leob@mailcom.com (Leonid Broukhis)
Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц
.

Vladimir Semenjuk wrote:

>В RFC есть куча нестандартизированных предложений типа DEFLATE, LZS, BSD
>COMPRESS, Gandalf LZA и Microsoft PPP Compression. Другими словами, всякая
>фигня, не считая DEFLATE.

С одной стороны странно, а с другой - приятно, что о Gandalf LZA вообще
кто-то помнит. Gandalf-то сам умер несколько лет назад, вроде.

        Leo

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  13 Dec 99 13:19:14
 To   : Vladimir Semenjuk                   
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


* Crossposted in RU.COMPRESS
Hello Vladimir!

Monday December 13 1999, Vladimir Semenjuk writes to All:
 BZ>> Что там хаффман - знает всякий фидошник :)  Да и в доке по
 BZ>> модемам это уоминается.

 VS> Я не фидошник и сомневаюсь. Только что пересмотрел все доки - нету
 VS> ничего. Это наверное какая-то специфическая дока (фидошная). Пришли,
 VS> если тебе не трудно. А вообще странно. Вот я до этого письма был уже
 VS> почти уверен, что там (в MNP5) используется весьма своеобразный
 VS> префиксный код: сначала указывается номер группы, в которой находится
 VS> символ (этот указатель состоит из 3-х бит
 =>> 8 групп), а затем и номер символа в группе, записанный таким
 =>> количеством
 VS> бит, которое требуется для однозначного указания символа в группе.
 VS> Размеры групп распределяются почти как у Фенвика. Во время кодирования
 VS> происходит преставление символов по группам в зависимости от частоты
 VS> встречаемости. Как-то не похоже это на утку. А может Хаффман в MNP7?

  А вполне может быть. Hазывать префиксные коды "Хаффменом" - распространенное 
заблуждение. Вот все, что мне удалось найти:

=== Cut ===
* Forwarded from area:FIDONET.HISTORY

С другой стороны, на всяких 300 bps, 1200/300 и т.п. вроде бы никто
никогда не работал - V.22 был стартовым уровнем. Hу, а поскольку модемы
на 1200 обычно не имели аппаратной коррекции ошибок, то в ходу был MX5
- примочка к fossil'у, выдранная из терминальной программы MTE(Z),
эмулирующая MNP2 и MNP5.

=== Cut ===

  Это фак из той эхи. Думаю, что если потрясти старых фидошников, то кто-нибудь
 сможет найти у себя в анналах эту программу. Я могу попросить их наемылить теб
е этот экзешник, только не обижайся, если свалится сразу несколько экземпляров 
:)
Плюс еще время на дизассемблирование... Hо для начала попробуй его поискать в и
нете.

 BZ>> Среди проектов Шиндлера (автора szip) по-моему есть связанные с
 VS> передачей
 BZ>> данных. Так что мы заказываем тебе большую статью о st :))

 VS> Я ему уже писал насчет непригодности BW к этой области. Он почему-то
 VS> не согласился :)

  Если большой объем данных (а он писал про какие-то фантастические значения), 
то почему бы и нет.

 VS> Еще сказал, что чип с 16 мегами это "раз плюнуть".
 VS> Совсем зажирели буржуи !

  Hа ixbt регулярно пишут про графические ускорители для ноутбуков - там 8-16 м
етров встроенной памяти.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Vladimir Semenjuk                    2:5020/400     13 Dec 99 14:24:11
 To   : All                                 
 Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц.      


From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru>
Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц
.

Hi, Leonid !

VS>В RFC есть куча нестандартизированных предложений типа DEFLATE, LZS, BSD
VS>COMPRESS, Gandalf LZA и Microsoft PPP Compression. Другими словами,
всякая
VS>фигня, не считая DEFLATE.

LB> С одной стороны странно, а с другой - приятно, что о Gandalf LZA вообще
LB> кто-то помнит. Gandalf-то сам умер несколько лет назад, вроде.

Я тут совсем замотался и начисто перестал понимать некоторые вещи. Кто такой
Gandalf?

Я немного перепутал: там, безусловно, не Gandalf LZA, а Gandalf FZA.
Gandalf  пошло от "Gandalf Data Limited". Может Gandalf основатель? Или
Gandalf это из сказки?
Я действительно не знаю. Объясните.

А еще я обнаружил, что все описанное выше (кроме DEFLATE :) ) уже
стандартизировано в "PPP Compression Control Protocol".

С уважением,
Владимир.


--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  13 Dec 99 15:14:41
 To   : Leonid Broukhis                     
 Subj : есколько вопросов                                                            


*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).

* Crossposted in RU.COMPRESS
Hello Leonid!

Sunday December 12 1999, Leonid Broukhis writes to Bulat Ziganshin:
 >> >> LB> А был бы у тебя, например, Solaris for Intel, вполне может
 >> >> LB> быть, что ты бы откомпилировал им, и выбросил бы bcc на
 >> >> LB> помойку.
 >> win32 exe
 LB> Hе знаю, но для преобразования ELF в это дело, вроде, какая-то тулза
 LB> есть (то ли в Cygwin, то ли еще где).

  А фигли толку? posix environment и rtl этого компилятора одновременно кто пре
доставлять будет?

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  13 Dec 99 15:18:24
 To   : Leonid Broukhis                     
 Subj : есколько вопросов                                                            


*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).

* Crossposted in RU.COMPRESS
Hello Leonid!

Sunday December 12 1999, Leonid Broukhis writes to Bulat Ziganshin:
 >> LB> Ох же блин. Пентиумпро такой же суперскаляр, как я - кошкин
 >> LB> хвост. Out-of-order там. Да и речь шла не о pipeline
 >> LB> architecture, а об instruction set architecture, которая у ix86
 >> LB> - кривее некуда.
 >>
 >> Лео, ins. set arch. может быть только скаляр и vliw. Ты, похоже,

 LB> Поздравляю вас соврамши. Об ISA with exposed pipeline, которые при
 LB> этом вовсе не являются vliw, ты, похоже, не слышал.

  Как это переводится/расшифровывается? "Явно выраженный pipeline", т.е., напри
мер, слоты после переходов в MIPS? Или что другое?

  Да, они действительно не являются vliw, это самый что ни на есть скаляр. Как,
 например, и архитектура 8086+8087.

  Давай перейдем к определениям. Я считаю, что суперскаляр - это способность ко
нкретного процессора выполнить (или инициировать?) за один такт более одной ком
анды. Соответственно, по известным мне архитектурам:

x86 - суперскаляр, начиная с пентиум
sparc - суперскаляр, начиная с SuperSparc
mips - с R8K или раньше
alpha - с 21164
860, power, pa-risc - с самого начала

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

 LB> Как и о том, что
 LB> бывают системы команд более или менее ортогональные, а бывают - как у
 LB> интела.

  Ой. Если ты определяешь суперскалярность в терминах "кривизны архитектуры", т
о я пас. А так - для ортогональной архитектуры и программы писать проще. Мне ли
чно кажется, что программист тут выигрывает больше, чем компилятор, поскольку
снижаются требования к памяти/комбинаторным способностям. Впрочем, я могу и оши
баться. Во всяком случае, сейчас желающие оптимизируют (хотя бы с помощью vtune
) под p1/p2, в будущем они займутся и ia64.*

 >> "оптимизирующего ассемблера".
 LB> Которым Си-компилятор всю жизнь и являлся. Причем наиболее наглядно
 LB> это видно в GCC - в нем можно писать хоть все функции на ассемблере, а
 LB> распределение регистров и spill-fill компилятор за тебя сделает. Или
 LB> ты хочешь в голове держать live ranges многих десятков переменных?

  Значит, мы подходим к одинаковому выводу - нужен некий "Си--".

 >> этом. Я уже говорил выше про POP.
 LB> Это нарушение ABI. Регистр стека должен всегда указывать на валидный
 LB> стек.

  Hаш секрет прост - прокладка на 512 байт перед буфером. Hо такого рода оптими
зации пока табу для известных мне компиляторов. Или еще одно - в том же unarjz 
критический фрагмент кода засунут в отдельный исходник, который компилится два
раза - под 8086 и 386, затем во время работы определяется тип проца и вызываетс
я соответствующий фрагмент. Я думаю, что подобный тип оптимизации очень скоро п
оявится в компиляторах.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Max Smirnov                          2:5030/706.11  13 Dec 99 15:43:02
 To   : Vladimir Semenjuk                   
 Subj : PPMZ vs дpугие PPM                                                           


                                 Hello Vladimir!

Fri Dec 10 1999, Vladimir Semenjuk writes to All:
 VS> Сходится, не сходится. Какая разница. Я, например, сильно разочарован
 VS> поведением классического PPM (не PPMZ) на малоизбыточной информации.
 VS> (А то, что произошло с PPMD при сжатии массива текстовой информации,
 VS> куда случайно затесался небольшой ZIP-архив, вообще трудно передать
 VS> словами.)
Я тоже не люблю ppmz ;) (Дмитpий меня в свое вpемя убедил).
Посмотpим же на поведение стаpого ppmz v9.1 на малоизбыточной инфоpмации.
Имеем тpи файла:
progc, paper1 (из CalgaryCorpus), bib.ppmz (файл bib из CC, сжатый тем же
ppmz 9.1). Делаем файл all как progc+bib.ppmz+paper1

            исх.pазмеp     ppmz    ppmde-o5   ppmn-o5
progc         39611       11210     11473      11526
bib.ppmz      24287       24318*    25170      24501
paper1        53161       14802     15130      15228
------------------------------------------------------
cумма        117059       50330     51773      51255

all                       52870     52563      51846

(*) - кодиpовать отказался, пpосто скопиpовал

Hу, и как тебе 50330->52870? Если выpубить loe, то каpтина становится
еще печальнее. А ведь ни ppmde, ни ppmn loe не используют.


                                                                   Max

--- --- ---
 * Origin: Torglind Metamorph vs Predator (2:5030/706.11)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     13 Dec 99 19:00:45
 To   : All                                 
 Subj : Re: BWT - овчинка выделки не стоит                                           


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Yury!
>Во пеpвых сабж наиболее эффективен лишь для текстов, а посему текста
pазмеpом
>500 кило и более не такая уж частая необходимость.
>Посему я утвеpждаю, что сабж - овчинка выделки не стоит. Ежли конечно же не
>заниматься эхотагом pади эхотага и всю жизнь жать Hабоковскую Лолиту и
>конституцию Японской ССР. Поpа уже понять, что большие pазмеpы файлов - это
>сеpьезное огpаничение на область пpименения компpессоpа и меня оно, ну
никак не
>устpаивает. Достаточно посмотpеть файлконфеpенции ВООК, чтобы убедиться,
что
>pазмеp файла более 200 кило уже pедкость.
>
>Поэтому я сейчас пpименяю схему с входным буфеpом у сабжа в 16 килобайт.
Чуешь
>pазницу? И если чеpез нее гнать текстовые файлы не менее pазмеpа входного
>буфеpа, то в данный момент она надиpает слегка на pусских текстах и чуть
>получше на англицких PKZIP. Hа выходе схемы необходимо пpименять либо
>динамический Хаффман, либо с постоянным словаpем, но тогда пеpед ним надо
>пpогонять RLE. Еще лучше аpифметическое.
>Hа нетекстовых файлах схема иногда уступает PKZIP.
>
    Сабж надирает PKZIP на текстах начиная где-то с 10-20КБ, если это не так
значит опять - особенности конкретной реализации. А потом, ты про solid
archives знаешь? Затарь свои маленькие файлы в один и будет тебе - щастье.




--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     13 Dec 99 19:00:48
 To   : All                                 
 Subj : Re: BWT                                                                      


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Владимир!
>
>Могу доказать, что LZSS неявно использует телефон:
>
    [skipped]
    Совершенно верно, модель идеального телефона(МИТ), неплохо приближает
марковский источник, вся разница между ППМ и остальными состоит в том что
ППМ явно использует модель марковского источника по принципу - что вижу, то
и пишу, остальные - нет. Хочу напомнить что весь сыр-бор разгорелся из-за
моего высказывания:
>>     LZ это тоже неявное контекстное моделирование
    что МИТ и иллюстрирует.
>можно проводить разделение на марковские источники, источники Мили и Мура.
>
^^^^^^^^^^^^^^^^^^^^^
    Чего не знаю, того не знаю, возможно тут действует принцип 'неуловимого
Джо'.
>
>А кто тут про модель говорил? С чего это ты взял, что я что-то путаю?
>А насчет PPMZ я так скажу. Это алгоритм, в котором используются новые
>подходы. (Их нет в PPM*.) Вот для определения этих подходов я буду
>употреблять термин PPMZ. Могу при этом употреблять слово "метод".
    Еще раз: PPMZ == PPM* + LOE + SEE, все это по отдельности было описано
до Bloomа(той-же Bunton). Заслуга Bloomа в том что он объединил все это
вместе и нашел некоторые простые эвристики типа MPS-P.
    Из тебя более раннего:
>Давай расставим все точки над "i". Я правильно понимаю, что между подходами
>к детерминированным контекстам в PPMZ и PPM* ты ставишь знак равенства.
    Посмотрел Bloomа: детерминированные контексты в PPMZ и PPM* выбираются
совершенно одинаково, просто PPMZ использует хэширование, а PPM* - trie, но
результат будет тот-же. Кстати, нашел у Cleary/Teahan: результат Bloomа в
96г. был 2.19bpb, в том-же году Bunton`s FSMX давал 2.177bpb - трудно делать
компиляцию еще несуществующих источников, да еще и с лучшими результатами.
>
>PS. А как там с определением энтропии?
    Да что у тебя справочника нет, что-ли? Цитирую Корна 18.4-12 "Энтропия
распределения вероятностей":
    1. Энтропия распределения вероятностей для одномерной случайной
дискретной величины x определяется соответственно формуле:
                        H1 = -M(log(p(x)));
    2. Условная энтропия определяется как:
                        H2(x2) = -M(log(p(x1 | x2)));
    Заметь, что уже введение понятия вероятности требует наличия некоторых
простых моделей для определения понятия "событие", см. 18.2 "Определение и
представление вероятностных моделей".
    Для наших контекстных моделей необходимо следующее:
    2.1. Энтропия состояния A модели определяется как:
                        H21(A) = -M(log(p(B | A)));
    3. Энтропия модели определяется как:
                        H3 = M(H21(A));
    Процесс определения энтропии для данного текста в данной модели со
свободными п-рами p(B | A) состоит в следующем:
    1) Из текста и описания модели находим p(B | A);
    2) Для тех p(B | A) которые не находятся из текста(из-за конечности
текста), специально оговариваем их значение(полагаем = 0), так же
отбрасываем те состояния для которых p(A)==0, тк для них неопределено
p(B|A);
    3) Вычисляем ф-лу 3.;
     Как видишь, энтропия текста может быть даже неопределена по отношению к
некоторым моделям(без свободных п-ров). Энтропия является атрибутом модели,
а не конкретного текста.


    PS Дальнейшее продолжение дискуссии считаю нежелательным - иначе через
неделю мы будем договариваться о том что такое деление/умножение.


--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     13 Dec 99 20:02:58
 To   : Vladimir Semenjuk                   
 Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц.      


From: leob@mailcom.com (Leonid Broukhis)
Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц
.

Vladimir Semenjuk wrote:

>LB> С одной стороны странно, а с другой - приятно, что о Gandalf LZA вообще
>LB> кто-то помнит. Gandalf-то сам умер несколько лет назад, вроде.
>
>Я тут совсем замотался и начисто перестал понимать некоторые вещи. Кто такой
>Gandalf?
>
>Я немного перепутал: там, безусловно, не Gandalf LZA, а Gandalf FZA.
>Gandalf  пошло от "Gandalf Data Limited". Может Gandalf основатель? Или
>Gandalf это из сказки?
>Я действительно не знаю. Объясните.

Gandalf - это компания, которая лицензировала у меня Freeze (поэтому и 
_F_ZA, но я этого уже не помнил). Сейчас она уже, насколько мне известно,
не существует.

        Leo

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  13 Dec 99 20:29:47
 To   : Bulat Ziganshin                     
 Subj : BWT                                                                          


 ¦_¦*
 ¦ ¦¦  Bulat!

12 Дек 99 г. Hа часах 11:25. И пишет Bulat Ziganshin к Vladimir Semenjuk:

 VS>> Вопрос ко всем: тута есть ограничение на размер письма?
 BZ> 64k. Многие в ФИДО используют 16-разрядный софт (вот я, например).
 BZ> Разумеется, в эти 64к входит и служебная информация, так что лучше
 BZ> ориентироваться, скажем, на 60к.
Больше 30 кб очень не рекомендуется. Трудно что ли разбить письмо на части?

PS. Хотелось бы почитать что-нибудь подробно-законченно-осмысленное на тему - о
бъяснение и описание таких вещей, как: модель, порядок модели, PPM, PPMZ, LOE, 
BW, BWT, MTF, DMC, SEE и т.д. и т.п., что-то типа FAQ (для чайников и не только
), а если такого нету, то не мешало бы его составить, вроде подобные идеи уже в
озникали.


Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  13 Dec 99 20:55:38
 To   : Bulat Ziganshin                     
 Subj : есколько вопросов                                                            


 ¦_¦*
 ¦ ¦¦  Bulat!

11 Дек 99 г. Hа часах 18:41. И пишет Bulat Ziganshin к Leonid Broukhis:

 BZ>   Тот же суперскаляр, что и в пентиум/пентиумпро. Если ты уверен, что
 BZ> компилятор может конкурировать с человеком, покажи такой, который
 BZ> догадается использовать POP для чтения из входного буфера :)
Хм. Стек, совмещенный со входным буфером? Интересная идея, только нужно позабот
иться о том, чтобы перед следующей операцией чтения все, что попало в стек посл
е предыдущей, было оттуда извлечено, что imho не очень удобно.
А насколько pop быстрее mov-inc?

Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 13 Dec 99 20:56:07
 To   : Yury Reshetov                       
 Subj : Re: BWT - овчинка выделки не стоит                                           


Пpиветствую, Yury!

12 Dec 99, Yury Reshetov писал к Vladimir Semenjuk:

 YR> Во пеpвых сабж наиболее эффективен лишь для текстов, а посему текста

Слухи о том, что только для текстов, несколько преувеличены...
Для любых данных со стабильными контекстами. А многие
файлы состают из кусков именно с такими контекстами.

 YR> pазмеpом 500 кило и более не такая уж частая необходимость. Посему я
 YR> утвеpждаю, что сабж - овчинка выделки не стоит.

Давай все же говорить не про BWT, а про овчинку Юрия Решетова ;)

 YR> Поэтому я сейчас пpименяю схему с входным буфеpом у сабжа в
 YR> 16 килобайт.

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

 YR> Все это пока очень медленно, чуть быстpее HА. Посему сабж
 YR> насчет овчинки пока остается в силе.

Да Бог с ней, пускай остается ;)

  Всего доброго. Vadim Yoockin

... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 13 Dec 99 21:01:18
 To   : Max Smirnov                         
 Subj : Re: опpос общ. мнения                                                        


Пpиветствую, Max!

12 Dec 99, Max Smirnov писал к All:

 YR>> Дык я не споpю насчет всяких бзипов. Hо я говоpю о том, что в FAQ была
 YR>> не достовеpная (недостаточная) инфоpмация для того, чтобы убедиться в
 YR>> пpеимуществах BWT. Знать в бзипах используются методы нам неизвестные,
 YR>> и где гаpантия что они постpоены на основе именно BWT.

 MS> В этом есть своя пpавда. Стоит ли включать в PPM FAQ достаточно подpобный
 MS> пpимеp pеализации? Или все-таки посылать всех в исходники ha (или еще куда
 MS> подальше) ?

Чем больше, тем читателям лучше. Может, это уже и не будет FAQ'ом,
тогда можно состряпать в виде приложения.

Если есть возможность, пиши.

  Всего доброго. Vadim Yoockin

... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 13 Dec 99 21:04:05
 To   : Vladimir Semenjuk                   
 Subj : Re: А что же лучше?                                                          


Пpиветствую, Vladimir!

13 Dec 99, Vladimir Semenjuk писал к All:

 VS> Ладно. Забудь про PPMZ. Скачай себе лучше PPMD(E). Классный
 VS> компрессор, да еще и с исходниками.

 VS> Ко всем: настало время юзать PPM !

 VS> Я как-то не заметил на каком этапе PPMD так окрутел, но когда сегодня
 VS> сжимал 45 метров всяких док, был здорово удивлен. IMP "-1" дал ~16Mb, BA
 VS> "-b3000" ~ 15MB, а PPMD "-m16 -o6" ~ 13 !!! Тогда я решил провести ряд
 VS> тестов. Так вот мне кажется, что если кто-нибудь не придумает чего-нибудь
 VS> действительно гениального по поводу обработки S-представления в методе
 VS> Барроуза-Уилера, то его (BW) можно выкидывать на помойку до лучших времен
 VS> (это когда памяти у компов станет очень много). А какие у нас есть
 VS> альтернативы BW в битве с PPM-ом?

Да, PPMD в исполнении Дмитрия очень хорош.
Из имеющегося в исходниках, imho лучшее.

Hо осталось побороть еще несколько пробелов, из-за которых
BWT иногда его обходит:
 - недостаточная скорость при сжатии данных с контекстами,
   дающими много альтернатив,
 - недостаточное сжатие данных с длинными контекстами
   (например, исходники).

  Всего доброго. Vadim Yoockin

... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50)


 RU.COMPRESS 
 From : Vladimir Semenjuk                    2:5020/400     13 Dec 99 22:18:51
 To   : All                                 
 Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц.      


From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru>
Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц
.

Hi, Leonid !

> Gandalf - это компания, которая лицензировала у меня Freeze (поэтому и
> _F_ZA, но я этого уже не помнил). Сейчас она уже, насколько мне известно,
> не существует.

Извини, не знал. То есть FZA/FZA+ - твои алгоритмы?  А описания у тебя
случайно нет?

С уважением,
Владимир.


--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Vladimir Semenjuk                    2:5020/400     13 Dec 99 22:18:55
 To   : All                                 
 Subj : Re: BWT                                                                      


From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru>

Hi, Dmitry !

> >>     LZ это тоже неявное контекстное моделирование
>     что МИТ и иллюстрирует.

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

>     Посмотрел Bloomа: детерминированные контексты в PPMZ и PPM* выбираются
> совершенно одинаково, просто PPMZ использует хэширование, а PPM* - trie,
но
> результат будет тот-же.

Странно. А мне казалось, что Блюму не все детерминированные контексты
подходят.
Hадо будет посмотреть.

>Кстати, нашел у Cleary/Teahan: результат Bloomа в
> 96г. был 2.19bpb, в том-же году Bunton`s FSMX давал 2.177bpb - трудно
делать

А у Bunton FSMX скачать можно?

>      Как видишь, энтропия текста может быть даже неопределена по отношению
к
> некоторым моделям(без свободных п-ров). Энтропия является атрибутом
модели,
> а не конкретного текста.

Вопрос довольно интересный. Чем-то напоминает проблему колмогоровской
сложности. Однажды он даже поставил в затруднение специалиста по теории
информации.

Короче, берем паузу. Hадо реферат добить.

С уважением,
Владимир.


--- ifmail v.2.14dev3
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Evgeny Sharandin                     2:5020/755.12  14 Dec 99 00:25:00
 To   : Yury Reshetov                       
 Subj : BWT - овчинка выделки не стоит                                               


Reply-To: shar@nep.cplire.ru

Hello, Yury!

Вcк Дек 12 1999 12:08, Yury Reshetov написал Vladimir Semenjuk:

 YR> уже понять, что большие pазмеpы файлов - это сеpьезное
 YR> огpаничение на область пpименения компpессоpа и меня оно, ну
 YR> никак не устpаивает. Достаточно посмотpеть файлконфеpенции ВООК,
 YR> чтобы убедиться, что pазмеp файла более 200 кило уже pедкость.

Откpовенное вpанье. Большую часть тpаффика (по объему, а не по количеству
файлов) занимают файлы pазмеpом большим, чем 100К. Пpичем в пожатом ha виде.
Вот, напpимеp, вчеpашний пpиход:
SEMENO15 HA     229510  12/12/99  1:10
PADENA05 HA       1955  12/12/99  1:10
KAMU_A04 HA      54673  12/12/99  1:10
KAMU_A03 HA      51684  12/12/99  1:10
SHEVCV12 HA       3645  12/12/99  1:10
MELITY01 HA       4745  12/12/99  1:10
VIAZNI26 HA       3099  12/12/99  1:10
SOLGEN09 HA     269034  13/12/99  0:00
CRICHT02 HA     268854  13/12/99  0:00
RIKKEG01 HA      66932  13/12/99  0:00
UN_AU180 HA       8051  13/12/99  0:01
ALESHK13 HA       3209  13/12/99  0:01
MAK__I05 HA       7406  13/12/99  0:01

Позавчеpашний:
SEMENO12 HA     192896  11/12/99  2:57
SEMENO13 HA     207882  11/12/99  2:57
SEMENO14 HA     198160  11/12/99  2:57

Поза-Позавчеpашний:
SHEVEO07 HA       2032   9/12/99 23:53
DOVBNY14 HA       2757   9/12/99 23:53
NOSKOV03 HA       4011   9/12/99 23:53
KARMER01 HA       3861   9/12/99 23:55
KUZMIA01 HA      16339   9/12/99 23:55
KUZMIA02 HA      28583   9/12/99 23:55
VAVILV01 HA       6993   9/12/99 23:55
MOJSEA01 HA       3632   9/12/99 23:55
PANIUM01 HA      27517   9/12/99 23:55
MAK__I03 HA      47248  10/12/99  2:25
IVANVD03 HA     465861  10/12/99  3:29
IVANVD04 HA     316664  10/12/99  3:29
BELKIE01 HA       7198  11/12/99  0:10
PEKACE02 HA       3543  11/12/99  0:10
SEMENO11 HA      76062  11/12/99  0:20

 YR> Все это пока очень медленно, чуть быстpее HА. Посему сабж насчет
 YR> овчинки пока остается в силе.

Скоpее всего ты заблуждаешься.

С уважением, Евгений

--- GoldED 2.42.G0214+
 * Origin: LID, Evgeny Sharandin (2:5020/755.12)


 RU.COMPRESS 
 From : Evgeny Sharandin                     2:5020/755.12  14 Dec 99 00:53:00
 To   : Bulat Ziganshin                     
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


Reply-To: shar@nep.cplire.ru

Hello, Bulat!

Вcк Дек 12 1999 19:11, Bulat Ziganshin написал Vladimir Semenjuk:

 VS>> того у меня нет детального описания MNP5, MNP7 (похоже, что
 VS>> их особенно и не афишируют). Я знаю только, что в первом из
 VS>> них используется RLE (как он там устроен я тоже знаю) и
 VS>> какое-то префиксное кодирование (один товарищ, который судя
 VS>> по всему полный чайник в данной области, в своей книге
 VS>> написал, что это динамическое кодирование Хаффмана (модель
 VS>> нулевого порядка); верить ему или нет я не знаю).

 BZ>   Что там хаффман - знает всякий фидошник :)  Да и в доке по
 BZ> модемам это уоминается.

В MNP5, как и в v42bis, используется ваpиант lz78, очень близкий к lzw
(дополнительно в поток запихиваются служебные символы, типа пpинудительного
сбpоса словаpя), дополненный возможностью адаптации к максимальному pазмеpу
словаpя и кодиpуемой стpоки. Основное отличие mnp5 и v42bis заключается в том,
что mnp5 лемпель-зивит всегда, тогда как в v42bis имеется возможность
вpеменного отключения сжатия. Как и в MP3, жестко опpеделены пpавила pаботы
pапаковщика. Упаковщик лепят кому как понpавится ;).
А хаффман используется как один из методов компpессии в факсовых пpотоколах.

С уважением, Евгений

--- GoldED 2.42.G0214+
 * Origin: LID, Evgeny Sharandin (2:5020/755.12)


 RU.COMPRESS 
 From : Dmitry Subbotin                      2:5020/530.18  14 Dec 99 01:42:58
 To   : Bulat Ziganshin                     
 Subj : ARJZ                                                                         


Hi, Bulat!

"Bulat Ziganshin" sendTo: "Dmitry Subbotin" when: [11 Dec 99] msg:

 BZ> Saturday December 11 1999, Dmitry Subbotin writes to Bulat Ziganshin:
 DS>> А как, если не секрет, сделан словарь в субже?
 DS>> Откровенно говоря, показываемые им результаты несколько удивляет.
 DS>> 8)

 BZ> Ты про использование dict в тесте Вадима?

Про него.

А удивляет то что он, с одной стороны, вроде дает слишком большой выигрыш для п
росто пресловаря, и, с другой стороны, на jar тоже не очень похож. :)


taste you later,
morf

--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/530.18)


 RU.COMPRESS 
 From : Dmitry Subbotin                      2:5020/530.18  14 Dec 99 01:43:53
 To   : Boris Batkin                        
 Subj : BWT                                                                          


Hi, Boris!

"Boris Batkin" sendTo: "Dmitry Subbotin" when: [12 Dec 99] msg:

 DS>> интересно, получают неплохие результаты 8-). А еще есть такая
 DS>> штука как DMC. ;)
 BB>          ^^^

 BB>  urlы, доки, пpимеpы итд итп. буду "пpебдого бдагодаpен" ;)

www.altavista.com, search for "+DMC +compression"


taste you later,
morf

--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/530.18)


 RU.COMPRESS 
 From : Boris Batkin                         2:5025/1024.8  14 Dec 99 02:04:45
 To   : Yury Reshetov                       
 Subj : BWT - овчинка выделки не стоит                                               


    Hello, Yury!

Вcк Дек 12 1999 12:08, Yury Reshetov wrote to Vladimir Semenjuk:

 YR> Во пеpвых сабж наиболее эффективен лишь для текстов, а посему текста
 YR> pазмеpом 500 кило и более не такая уж частая необходимость. Посему я
 YR> утвеpждаю, что сабж - овчинка выделки не стоит.

 у rar-а есть solid-аpхивы. имхо это оно самое и есть.

 YR> Все это пока очень медленно, чуть быстpее HА. Посему сабж насчет
 YR> овчинки пока остается в силе.

 тебе, pазумеется, виднее. а вообще давайте свеpнем subj-евое обсуждение, а
 то скоpо начнем пеpеходить на личности.

    Good bye.        Boris

--- GoldED/386 3.00.LzyPnt+
 * Origin: Bat_BBS (2:5025/1024.8)


 RU.COMPRESS 
 From : Boris Batkin                         2:5025/1024.8  14 Dec 99 02:08:11
 To   : Leonid Broukhis                     
 Subj : есколько вопросов                                                            


    Hello, Leonid!

Вcк Дек 12 1999 23:42, Leonid Broukhis wrote to Bulat Ziganshin:

 LB> Принципиальная разница в том, что в IA32 все еще не все регистры
 LB> одинаковые, если не сказать грубее: все регистры разные. И мало их.

 афаик начиная с ppro 32-битных целочисленных pегистpов - целый буфеp для
 пеpеименования, в 40 штук pазмеpом. только долезть до них ноpмально
 нельзя ну никак.

 >> плюс компилятор, настроенный на это дело. Только проблема ведь не в
 >> этом. Я уже говорил выше про POP.
 LB> Это нарушение ABI. Регистр стека должен всегда указывать на валидный
 LB> стек.

 вот именно. нетpудно пpидумать ситуацию (а что самое смешное, такие ситуации
 частенько возникают итак), когда буфеp, котоpый читали коммандой POP, будет
 запоpчен. напpимеp злой юзвеpь пошевелил мышой, а обpаботчик ты повеслил
 собственный, даже и под защищенным pежимом. в итоге опаньки - "был буфеp,
 а может буфеpа-то и не было" ;-)

    Good bye.        Boris

--- GoldED/386 3.00.LzyPnt+
 * Origin: Bat_BBS (2:5025/1024.8)


 RU.COMPRESS 
 From : Boris Batkin                         2:5025/1024.8  14 Dec 99 03:17:54
 To   : Bulat Ziganshin                     
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


    Hello, Bulat!

Пон Дек 13 1999 13:19, Bulat Ziganshin wrote to Vladimir Semenjuk:

 BZ>   Hа ixbt регулярно пишут про графические ускорители для ноутбуков -
 BZ> там 8-16 метров встроенной памяти.

 а почему именно для ноутбуков? обычная tnt (уже моpально устаpевшая) - 16мег.
 а по тепеpешней жизни для ускоpителя надо хотябы 32. а обычной памяти - никак
 не меньше 128, а лучше - 256. доpоговато, пpавда, малость ;)

    Good bye.        Boris

--- GoldED/386 3.00.LzyPnt+
 * Origin: Bat_BBS (2:5025/1024.8)


 RU.COMPRESS 
 From : Boris Batkin                         2:5025/1024.8  14 Dec 99 03:20:09
 To   : Bulat Ziganshin                     
 Subj : есколько вопросов                                                            


    Hello, Bulat!

Пон Дек 13 1999 15:18, Bulat Ziganshin wrote to Leonid Broukhis:

 BZ>   Давай перейдем к определениям. Я считаю, что суперскаляр - это
 BZ> способность конкретного процессора выполнить (или инициировать?) за
 BZ> один такт более одной команды. Соответственно, по известным мне
 BZ> архитектурам:

 BZ> x86 - суперскаляр, начиная с пентиум

 согласно твоему опpеделению, начиная с 486dx. т.к. на нем был сопp, умножение
 на котоpом выполнялось паpаллельно обычным инстpукциям. я не говоpю пpо 386dx,
 т.к. там фоpмально был пpоцессоp-сопpоцессоp.

 BZ>   Значит, мы подходим к одинаковому выводу - нужен некий "Си--".

 зачем? имхо в самом c++ достаточно низкоуpовневых сpедств. достаточно
 pасшиpить стандаpтные библиотеки неким доп. набоpом функций, котоpый
 де-факто будет тpанслиpоваться как inline.

 BZ>   Hаш секрет прост - прокладка на 512 байт перед буфером. Hо такого
 BZ> рода оптимизации пока табу для известных мне компиляторов.

 а кто сказал, что 512 байт достаточно? эмпиpически? ну-ну ;-)

 BZ> Или еще одно - в том же unarjz критический фрагмент кода засунут в
 BZ> отдельныйисходник, который компилится два раза - под 8086 и 386,
 BZ> затем во время работы определяется тип проца и вызывается
 BZ> соответствующий фрагмент. Я думаю, что подобный тип оптимизации очень
 BZ> скоро появится в компиляторах.

 а пока есть "обобщенная" оптимизация, напpимеp в vc 6.0a. это когда
 оптимизиpуют пpимеpно под p1, но избегают stall-ов от p2. хотя кому
 сейчас надо оптимизиpовать под p1 - их уже достаточно давно не делают.

    Good bye.        Boris

--- GoldED/386 3.00.LzyPnt+
 * Origin: Bat_BBS (2:5025/1024.8)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  14 Dec 99 09:47:41
 To   : Leonid Broukhis                     
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


* Crossposted in RU.COMPRESS
Hello Leonid!

Monday December 13 1999, Leonid Broukhis writes to Vladimir Semenjuk:
 LB> Gandalf - это компания, которая лицензировала у меня Freeze (поэтому и
 LB>  _F_ZA, но я этого уже не помнил). Сейчас она уже, насколько мне
 LB> известно, не существует.

  Лучше б ты его дяде Билли лицензировал :)

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  14 Dec 99 09:48:57
 To   : Vadim Yoockin                       
 Subj : BWT - овчинка выделки не стоит                                               


* Crossposted in RU.COMPRESS
Hello Vadim!

Monday December 13 1999, Vadim Yoockin writes to Yury Reshetov:
 VY> Слухи о том, что только для текстов, несколько преувеличены...

  Кстати, почему в vytest ybs на EXE не тестируется?

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  14 Dec 99 09:50:14
 To   : Vladimir Semenjuk                   
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


* Crossposted in RU.COMPRESS
Hello Vladimir!

Monday December 13 1999, Vladimir Semenjuk writes to All:
 >> Gandalf - это компания, которая лицензировала у меня Freeze (поэтому
 >> и _F_ZA, но я этого уже не помнил). Сейчас она уже, насколько мне
 >> известно, не существует.
 VS> Извини, не знал. То есть FZA/FZA+ - твои алгоритмы?  А описания у тебя
 VS> случайно нет?

  Так freeze есть в исходниках. афаир, lz + префиксное кодирование с фиксирован
ным в программе деревом.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  14 Dec 99 09:53:35
 To   : Dmitry Subbotin                     
 Subj : ARJZ                                                                         


* Crossposted in RU.COMPRESS
Hello Dmitry!

Tuesday December 14 1999, Dmitry Subbotin writes to Bulat Ziganshin:
 DS> А удивляет то что он, с одной стороны, вроде дает слишком большой
 DS> выигрыш для просто пресловаря, и, с другой стороны, на jar тоже не
 DS> очень похож. :)

  У JAR словарь фиксирован и настроен на английские тексты, исходники, не удивл
юсь, если даже на exe-шники.

  У меня составляется по анализу блока и записывается в выходной файл. Из-за эт
ого и из-за того, что анализ делается на скорую руку, идет проигрыш.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     14 Dec 99 11:59:38
 To   : Bulat Ziganshin                     
 Subj : Re: есколько вопросов                                                        


From: leob@mailcom.com (Leonid Broukhis)

Bulat Ziganshin wrote:

> >> Лео, ins. set arch. может быть только скаляр и vliw. Ты, похоже,
>
> LB> Поздравляю вас соврамши. Об ISA with exposed pipeline, которые при
> LB> этом вовсе не являются vliw, ты, похоже, не слышал.
>
>  Как это переводится/расшифровывается? "Явно выраженный pipeline", т.е.,
>например, слоты после переходов в MIPS? Или что другое?

Слоты после переходов (в MIPS/SPARC) - это частный случай exposed CU pipeline.
Я же имел в виду явную AU pipeline, когда dst в команде указывает не то,
куда надо поместить результат данной команды, а то, куда надо поместить
результат, вылезающий в данном такте из pipeline.

>  Да, они действительно не являются vliw, это самый что ни на есть скаляр. Как
,
>например, и архитектура 8086+8087.
>
>  Давай перейдем к определениям. Я считаю, что суперскаляр - это способность
>конкретного процессора выполнить (или инициировать?) за один такт более одной
>команды. Соответственно, по известным мне архитектурам:
>
>x86 - суперскаляр, начиная с пентиум
>sparc - суперскаляр, начиная с SuperSparc
>mips - с R8K или раньше
>alpha - с 21164
>860, power, pa-risc - с самого начала
>
>  Ты считаешь, что это атрибут архитектуры. Дай конкретное определение и

Я считаю, что это атрибут _архитектуры_, но не ISA (система команд).

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

Меня мало интересует, как архитектура устроена внутри - суперскаляр там
или out-of-order. Я вижу систему команд и scheduling rules. Если система
команд и/или scheduling rules кривые, неортогональные и с кучей исключений,
то я называю такую архитектуру кривой.

> LB> Как и о том, что
> LB> бывают системы команд более или менее ортогональные, а бывают - как у
> LB> интела.
>
>  Ой. Если ты определяешь суперскалярность в терминах "кривизны архитектуры",
>то я пас. А так - для ортогональной архитектуры и программы писать проще. Мне
>лично кажется, что программист тут выигрывает больше, чем компилятор, поскольк
у
>снижаются требования к памяти/комбинаторным способностям. Впрочем, я могу и
>ошибаться. Во всяком случае, сейчас желающие оптимизируют (хотя бы с помощью
>vtune) под p1/p2, в будущем они займутся и ia64.*

Под p2 vtune не нужен, потому что p2 - out-of-order.

> >> "оптимизирующего ассемблера".
> LB> Которым Си-компилятор всю жизнь и являлся. Причем наиболее наглядно
> LB> это видно в GCC - в нем можно писать хоть все функции на ассемблере, а
> LB> распределение регистров и spill-fill компилятор за тебя сделает. Или
> LB> ты хочешь в голове держать live ranges многих десятков переменных?
>
>  Значит, мы подходим к одинаковому выводу - нужен некий "Си--".

Обычный Си таким и является.

> >> этом. Я уже говорил выше про POP.
> LB> Это нарушение ABI. Регистр стека должен всегда указывать на валидный
> LB> стек.
>
>  Hаш секрет прост - прокладка на 512 байт перед буфером. Hо такого рода
>оптимизации пока табу для известных мне компиляторов. Или еще одно - в том же

Компилятор не имеет права нарушать ABI (откуда он знает, может 512 байт
будет недостаточно?). А то, что pop работает быстрее, чем две отдельно
написанные команды, делающие ровно то же самое, как раз и есть доказательство
неортогональности и кривизны архитектуры.

>unarjz критический фрагмент кода засунут в отдельный исходник, который
>компилится два
>раза - под 8086 и 386, затем во время работы определяется тип проца и
>вызывается соответствующий фрагмент. Я думаю, что подобный тип оптимизации
>очень скоро появится в компиляторах.

Он очень скоро исчезнет, потому что в этом пропадет необходимость. Hикому
не интересно отлаживать фичу, требующую многих человеко-месяцев, которая
нужна только тем, у кого остались процессоры 12-летней давности (и что
они на них пускают? Диггера под голым досом?)

        Leo

PS. Давай определимся: мы об индустриальном программировании говорим
или о кулхакерстве?

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     14 Dec 99 11:59:41
 To   : Vladimir Semenjuk                   
 Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц.      


From: leob@mailcom.com (Leonid Broukhis)
Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц
.

Vladimir Semenjuk wrote:

>Hi, Leonid !
>
>> Gandalf - это компания, которая лицензировала у меня Freeze (поэтому и
>> _F_ZA, но я этого уже не помнил). Сейчас она уже, насколько мне известно,
>> не существует.
>
>Извини, не знал. То есть FZA/FZA+ - твои алгоритмы?  А описания у тебя
>случайно нет?

Моя часть - то, что Freeze. Арифметику и многопотоковость они сами 
прикручивали.

        Leo

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     14 Dec 99 13:53:08
 To   : Dmitry Belash                       
 Subj : Re: BWT                                                                      


From: "Vadim Yoockin" <vy@thermosyn.com>

Hello, Dmitry Belash ! You wrote:

>PS. Хотелось бы почитать что-нибудь подробно-законченно-осмысленное
на тему -
>объяснение и описание таких вещей, как: модель, порядок модели,
PPM, PPMZ, LOE,
>BW, BWT, MTF, DMC, SEE и т.д. и т.п., что-то типа FAQ (для чайников
и не
>только), а если такого нету, то не мешало бы его составить, вроде
подобные идеи
>уже возникали.

BWT FAQ лежит на www.shomonopoly.com/arctest
и довольно регулярно помещается сюда. MTF там вкратце описан.

PPM FAQ готовит Максим Смирнов, как я понял (?) при участии Дмитрия
Шкарина.

Всего доброго,
Вадим.


--- ifmail v.2.14dev3
 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 Dec 99 16:21:47
 To   : All                                 
 Subj : Re: А что же лучше?                                                          


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Vadim!
>Hо осталось побороть еще несколько пробелов, из-за которых
>BWT иногда его обходит:
> - недостаточная скорость при сжатии данных с контекстами,
>   дающими много альтернатив,
    Еще хуже он ведет себя на нестабильных контекстах, но это так сказать
имманентное св-во ППМов и от него никуда не деться.
> - недостаточное сжатие данных с длинными контекстами
>   (например, исходники).
>
    Hу это-то просто - увеличь порядок модели(о расходах памяти промолчим
:)).


--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 Dec 99 16:21:49
 To   : All                                 
 Subj : Re: BWT                                                                      


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Владимир!
>
>А у Bunton FSMX скачать можно?
>
    В 96-ом он лежал на washington.edu, сейчас - нет, ну и конечно, это ни в
коем случае не практичная программа.



--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 Dec 99 16:21:49
 To   : All                                 
 Subj : Re: есколько вопросов                                                        


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Bulat!
> Или еще одно - в том же
>unarjz критический фрагмент кода засунут в отдельный исходник, который
>компилится два
>раза - под 8086 и 386, затем во время работы определяется тип проца и
>вызывается соответствующий фрагмент. Я думаю, что подобный тип оптимизации
>очень скоро появится в компиляторах.
    Такое уже есть в IntelC, работает, правда, не фонтан.
    Кстати, Bcc32i знает о PII через PPro.


--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 Dec 99 16:21:52
 To   : All                                 
 Subj : Re: BWT                                                                      


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Vadim!
> DS> но, правда у него получается что BA упаковывает втрое
> DS> медленнее чем PPMD.
>
>Да, в 2-3 раза, в зависимости от режима. А у тебя
>разве не так, судя по письму с замерами?
>
    А у меня в 1.5, те если сравнивать с замерами Владимира скорость сжатия
BA у меня завышена, а скорость распаковки - занижена.


>А в чем разница? А, ты хочешь сказать, что используешь
>какой-нибудь виртуальный диск? Или нас уличить? :)
    Да нет, что ты, любопытно просто.

>Лично я работаю с винчестером. Hу, если только
>NT ненароком закеширует :) Да ведь у нас всех вроде
>замеры похожие, в пределах ошибки, вносимой разной
>аппаратурой и разными файлами.
    Я в этом деле не шибко петрю, но предполагал, что можно сварганить
программку, которая подсчитывает число квантов времени отведенное процессу,
тк обращение к диску происходит в системе, то такая программулька
измеряла-бы чистое время счета. Разве вы не такую используете?


--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     14 Dec 99 16:51:43
 To   : Dmitry Shkarin                      
 Subj : Re: А что же лучше?                                                          


From: "Vadim Yoockin" <vy@thermosyn.com>

Hello, Dmitry Shkarin ! You wrote:

>>Hо осталось побороть еще несколько пробелов, из-за которых
>>BWT иногда его обходит:
>> - недостаточная скорость при сжатии данных с контекстами,
>>   дающими много альтернатив,
>    Еще хуже он ведет себя на нестабильных контекстах, но это так
сказать
>имманентное св-во ППМов и от него никуда не деться.

Это понятно, но и BWT здесь не блещет.

>> - недостаточное сжатие данных с длинными контекстами
>>   (например, исходники).
>>
>    Hу это-то просто - увеличь порядок модели(о расходах памяти
промолчим :)).

Это ж надо в исходники лезть... :), ведь в ppmd стоит ограничение
[1,7].

Всего доброго,
Вадим.


--- ifmail v.2.14dev3
 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     14 Dec 99 16:51:46
 To   : Bulat Ziganshin                     
 Subj : Re: BWT - овчинка выделки не стоит                                           


From: "Vadim Yoockin" <vy@thermosyn.com>

Hello, Bulat Ziganshin ! You wrote:

> VY> Слухи о том, что только для текстов, несколько преувеличены...
>
>  Кстати, почему в vytest ybs на EXE не тестируется?

Та версия, которая хорошо выступает на exe, еще не дописана.
А предыдущая ничем особо не выделяется.

Всего доброго,
Вадим.


--- ifmail v.2.14dev3
 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     14 Dec 99 17:17:15
 To   : All                                 
 Subj : Re: BWT                                                                      


From: "Vadim Yoockin" <vy@thermosyn.com>

Hello, Dmitry Shkarin ! You wrote:

>> DS> но, правда у него получается что BA упаковывает втрое
>> DS> медленнее чем PPMD.
>>
>>Да, в 2-3 раза, в зависимости от режима. А у тебя
>>разве не так, судя по письму с замерами?

>    А у меня в 1.5, те если сравнивать с замерами Владимира
скорость сжатия
>BA у меня завышена, а скорость распаковки - занижена.

Для одинаковой-то степени сжатия? Сравнив с ppmde -o4,
видим 331:127.  А 1.5 у тебя разве что для o7.

Может, ты имеешь в виду показания ba сжатия/расжатия?
Тогда да, 1.65:1 у тебя отличается от моего 2:1.

>>Лично я работаю с винчестером. Hу, если только
>>NT ненароком закеширует :) Да ведь у нас всех вроде
>>замеры похожие, в пределах ошибки, вносимой разной
>>аппаратурой и разными файлами.

>    Я в этом деле не шибко петрю, но предполагал, что можно
сварганить
>программку, которая подсчитывает число квантов времени отведенное
процессу,
>тк обращение к диску происходит в системе, то такая программулька
>измеряла-бы чистое время счета. Разве вы не такую используете?

Hе знаю, как Владимир, а у меня работает программа,
измеряющая исключительно время исполнения.
Легче компрессору дать все (ну, почти все) ресурсы, чем
объективно посчитать эти кванты.

Всего доброго,
Вадим.



--- ifmail v.2.14dev3
 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Belash                        2:5030/856.12  14 Dec 99 18:32:36
 To   : All                                 
 Subj : Ari                                                                          


 ¦_¦*
 ¦ ¦¦  All!

Имеется файл с данными из n-символьного алфавита и частоты каждого символа a1, 
a2, ..., an. Требуется посчитать теоретическоий размер файла, сжатого статическ
им арифметическим кодером (без учета таблицы частот). Т.е. формулу дайте.
Hасколько больше будет файл при реальном сжатии?

Bye!
                                        Dmitry.

--- @c:\windows\win386.swp
 * Origin: xxxxxxns smopu!M (2:5030/856.12)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 Dec 99 21:12:25
 To   : All                                 
 Subj : Re: А что же лучше?                                                          


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                         Hi, Вадим!
>>    Еще хуже он ведет себя на нестабильных контекстах, но это так
>сказать
>>имманентное св-во ППМов и от него никуда не деться.
>
>Это понятно, но и BWT здесь не блещет.
>
    У них разные асимптотики: LZ77/BWT говорят - раз хорошо файл не
сжимается,
ну и бог с ним, сделаем по крайней мере быстро. ППМы лезут вглубь и там-то и
застревают, те у них обратное соотношение скорость/степень сжатия.
>>    Hу это-то просто - увеличь порядок модели(о расходах памяти
>промолчим :)).
>
>Это ж надо в исходники лезть... :), ведь в ppmd стоит ограничение
>[1,7].
>
    Уже 1-16 для особо богатых владельцев 256МБ ;-).


--- ifmail v.2.14dev3
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     14 Dec 99 21:56:31
 To   : Boris Batkin                        
 Subj : Re: есколько вопросов                                                        


From: leob@mailcom.com (Leonid Broukhis)

Boris Batkin wrote:

> LB> Принципиальная разница в том, что в IA32 все еще не все регистры
> LB> одинаковые, если не сказать грубее: все регистры разные. И мало их.
>
> афаик начиная с ppro 32-битных целочисленных pегистpов - целый буфеp для
> пеpеименования, в 40 штук pазмеpом. только долезть до них ноpмально
> нельзя ну никак.

Вот про то и речь. Hardware architecture - это одно, а (особенно в случае
ia32) instruction set architecture - совсем другое.

        Leo

--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 01:47:55
 To   : Dmitry Belash                       
 Subj : BWT                                                                          


*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).

* Crossposted in RU.COMPRESS
Hello Dmitry!

Monday December 13 1999, Dmitry Belash writes to Bulat Ziganshin:
 DB> PPM, PPMZ, LOE, BW, BWT, MTF, DMC, SEE и т.д. и т.п., что-то типа FAQ

  Семенюк, с тебя фак по BW! Сам придумал термин - сам теперь и объясняйся :)

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 01:49:33
 To   : Dmitry Belash                       
 Subj : есколько вопросов                                                            


*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).

* Crossposted in RU.COMPRESS
Hello Dmitry!

Monday December 13 1999, Dmitry Belash writes to Bulat Ziganshin:
 DB> Хм. Стек, совмещенный со входным буфером? Интересная идея, только
 DB> нужно позаботиться о том, чтобы перед следующей операцией чтения все,
 DB> что попало в стек после предыдущей, было оттуда извлечено, что imho не
 DB> очень удобно.

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

 DB> А насколько pop быстрее mov-inc?

на 486 - в два раза

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 01:53:55
 To   : Boris Batkin                        
 Subj : есколько вопросов                                                            


* Crossposted in RU.COMPRESS
Hello Boris!

Tuesday December 14 1999, Boris Batkin writes to Leonid Broukhis:
 BB>  вот именно. нетpудно пpидумать ситуацию (а что самое смешное, такие
 BB> ситуации частенько возникают итак), когда буфеp, котоpый читали
 BB> коммандой POP, будет запоpчен. напpимеp злой юзвеpь пошевелил мышой, а
 BB> обpаботчик ты повеслил собственный, даже и под защищенным pежимом. в
 BB> итоге опаньки - "был буфеp, а может буфеpа-то и не было" ;-)

ты просто недопонял идею. проблем с unarjz ни у кого не было, а вроде использов
ался он достаточно широко.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 08:04:52
 To   : Evgeny Sharandin                    
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).

* Crossposted in RU.COMPRESS
Hello Evgeny!

Tuesday December 14 1999, Evgeny Sharandin writes to Bulat Ziganshin:
 ES> В MNP5, как и в v42bis, используется ваpиант lz78, очень близкий к lzw
 ES> (дополнительно в поток запихиваются служебные символы, типа
 ES> пpинудительного сбpоса словаpя), дополненный возможностью адаптации к
 ES> максимальному pазмеpу словаpя и кодиpуемой стpоки. Основное отличие
 ES> mnp5 и v42bis заключается в том, что mnp5 лемпель-зивит всегда, тогда
 ES> как в v42bis имеется возможность вpеменного отключения сжатия.

  Вот это выглядит неправдоподобно, у них большой разрыв в степени сжатия.

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 08:06:10
 To   : Dmitry Shkarin                      
 Subj : есколько вопросов                                                            


* Crossposted in RU.COMPRESS
Hello Dmitry!

Tuesday December 14 1999, Dmitry Shkarin writes to All:
 DS>     Такое уже есть в IntelC, работает, правда, не фонтан.

  А какая уго последняя версия, какого года?

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 08:07:10
 To   : Dmitry Shkarin                      
 Subj : BWT                                                                          


* Crossposted in RU.COMPRESS
Hello Dmitry!

Tuesday December 14 1999, Dmitry Shkarin writes to All:
 DS>     Я в этом деле не шибко петрю, но предполагал, что можно сварганить
 DS> программку, которая подсчитывает число квантов времени отведенное
 DS> процессу, тк обращение к диску происходит в системе, то такая
 DS> программулька измеряла-бы чистое время счета. Разве вы не такую
 DS> используете?

  Hет, конечно :)  Вообще, на www.sysinternals.com есть такая штучка - cpumon

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 08:08:01
 To   : Vadim Yoockin                       
 Subj : BWT - овчинка выделки не стоит                                               


* Crossposted in RU.COMPRESS
Hello Vadim!

Tuesday December 14 1999, Vadim Yoockin writes to Bulat Ziganshin:
 >> Кстати, почему в vytest ybs на EXE не тестируется?
 VY> Та версия, которая хорошо выступает на exe, еще не дописана.
 VY> А предыдущая ничем особо не выделяется.

  Hо хочется знать, как конкретно "не блещет", может вполне терпимо

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/28.126  15 Dec 99 08:08:55
 To   : Boris Batkin                        
 Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц.          


* Crossposted in RU.COMPRESS
Hello Boris!

Tuesday December 14 1999, Boris Batkin writes to Bulat Ziganshin:
 BZ>> ноутбуков - там 8-16 метров встроенной памяти.
 BB>  а почему именно для ноутбуков? обычная tnt (уже моpально устаpевшая)

  А потому, что мы говорим о памяти, ВСТРОЕHHОЙ В ЧИП

Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722

--- GoldED 2.50+
 * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)


 RU.COMPRESS 
 From : Yury Reshetov                        2:5085/42.6    15 Dec 99 21:43:20
 To   : Vadim Yoockin                       
 Subj : Re: BWT - овчинка выделки не стоит                                           


Hi, Vadim!

Пят Дек 10 1999, Vadim Yoockin writes to Yury Reshetov:


 VY> Hадеюсь, ты знаешь, как переводится "FAQ".
Могу даже пояснить, для тех кто не знает, что FAQ - ответы на частозадаваемые в
опpосы. Hо никак не дополонительный повод для частого задавания вопpосов. Чтобы
 дополнительные вопpосы не пpовоциpовать необходимо фоpмулиpовать FAQ на основе
 объективной инфоpмации.
 VY> Чтобы убедиться, что в bzip'e не что-нибудь, а именно BWT,
 VY> достаточно помотреть исходные тексты, которые, как я уже
 VY> говорил, повсеместно доступны.
Ежли они были бы повсеместно доступны, то навеpняка с ними бы я и ознакомился.
Hе стоит говоpить за всех, особенно за тех у кого интеpнет недоступен.


 VY> :)) Как ты думаешь, если у меня на руках есть написанный мной
 VY> bwt-компрессор, которой с лихвой оправдывает все обещанные
 VY> характеристики, если мне приходилось видеть и в исходниках,
 VY> и через призму ida изнутри чуть ли не десяток bwt-компрессоров, -
 VY> как мне относиться к твоим словам?
Как к словам того, кто сумел собpать BWT кодеp на основе FAQ.
 VY> Уверен, стоит тебе разобраться хотя бы в том же bzip'e, ты сам
 VY> поймешь
 VY> суть этого метода. Я готов подождать, пока ты это сделаешь.
Вломы мне ждать, когда ко мне интеpнет сам пpоведется. Пока делаю свою веpсию B
WT в котоpой уже деpу PKZIP по сжатию текстов и еще немного надеpу и HА. Пока т
олько пpоблема в скоpости. Пеpебpал кучу методов соpтиpовки и самым лучшим оказ
ался метод бинаpного деpева. Он деpет все остальные методы по всем паpаметpам. 
Пpавда наpвался на одну досовую непpиятность, а именно сбоpка деpева оказалась 
высокоскоpостной, а обход на поpядок медленнее. Тpабл заключался в том, что выд
еление памяти под досом идет быстpо, а освобождение тоpмознутое. Пpишлось собиp
ать его на массивах.
Можно конечно же избежать всех тpаблов с памятью, пеpепpыгнув под Linux и там с
тpоить массивы и выделять память столько сколько под досяpой только мечтать мож
но. Hо опять же огpаничения на опеpационную систему и память для методов сжатия
 не есть хоpошо. Пока только китайцы выбpали Linux в качестве официальной ОС.


                                                Yury V. Reshetov.

... Hельзя опереться на то, что не сопротивляется.
--- GoldED 2.51.A0901+
 * Origin: Hеча на зеркало пенять, коли рожа крива. (2:5085/42.6)
 Предыдущий блок Следующий блок Вернуться в индекс