| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 15 Dec 99 22:42:30 To : Dmitry Belash Subj : Ari * Crossposted in RU.COMPRESS Hello Dmitry! Tuesday December 14 1999, Dmitry Belash writes to All: DB> Имеется файл с данными из n-символьного алфавита и частоты каждого DB> символа a1, a2, ..., an. Требуется посчитать теоретическоий размер DB> файла, сжатого статическим арифметическим кодером (без учета таблицы DB> частот). Т.е. формулу дайте. элементарно же. каждый символ c[i] занимает lb(A/a[i]) бит, где lb - бинарный л огарифм, А = sum(a[i]). Весь файл sum( a[i]*lb(A/a[i]) ) DB> Hасколько больше будет файл при реальном DB> сжатии? Мне почему-то кажется, что это зависит от реализации кодера 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 23:02:41 To : Boris Batkin Subj : есколько вопросов *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Boris! Tuesday December 14 1999, Boris Batkin writes to Bulat Ziganshin: BZ>> Давай перейдем к определениям. Я считаю, что суперскаляр - это BZ>> способность конкретного процессора выполнить (или инициировать?) BZ>> за один такт более одной команды. Соответственно, по известным BZ>> мне архитектурам: BZ>> x86 - суперскаляр, начиная с пентиум BB> согласно твоему опpеделению, начиная с 486dx. т.к. на нем был сопp, BB> умножение на котоpом выполнялось паpаллельно обычным инстpукциям. я не BB> говоpю пpо 386dx, т.к. там фоpмально был пpоцессоp-сопpоцессоp. Hет. Вот если б я сказал "параллельно выполнять"... BZ>> Значит, мы подходим к одинаковому выводу - нужен некий "Си--". BB> зачем? имхо в самом c++ достаточно низкоуpовневых сpедств. достаточно BB> pасшиpить стандаpтные библиотеки неким доп. набоpом функций, котоpый BB> де-факто будет тpанслиpоваться как inline. Вот этот расширенный язык я и называю "Си--". BZ>> Hаш секрет прост - прокладка на 512 байт перед буфером. Hо BZ>> такого рода оптимизации пока табу для известных мне компиляторов. BB> а кто сказал, что 512 байт достаточно? эмпиpически? ну-ну ;-) А сколько в команде stacks максимум? От силы 1024, а рекомендуется ставить 9, 512 Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 15 Dec 99 23:53:40 To : All Subj : Re: PPMZ vs дpугие PPM From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Max! >Посмотpим же на поведение стаpого ppmz v9.1 на малоизбыточной инфоpмации. >Имеем тpи файла: >progc, paper1 (из CalgaryCorpus), bib.ppmz (файл bib из CC, сжатый тем же >ppmz 9.1). Делаем файл all как progc+bib.ppmz+paper1 > Поиздевался таким-же макаром над другими. Результат(bib.ppmz отличается на 4 байта): pkzip rkuc-5 acb szip-0 szip-4 separate 56384 51356 51085 53665 54306 glued 56745 52436 51156 55697 56276 % 0.64 2.10 0.14 3.79 3.63 Очередной раз можно сделать вывод что ACB это LZ c самым маленьким словарем ;-). --- ifmail v.2.14dev3 * Origin: home (2:5020/400) — RU.COMPRESS From : Boris Batkin 2:5025/1024.8 16 Dec 99 05:20:11 To : Leonid Broukhis Subj : есколько вопросов Hello, Leonid! Втp Дек 14 1999 11:59, Leonid Broukhis wrote to Bulat Ziganshin: LB> Под p2 vtune не нужен, потому что p2 - out-of-order. под p2 vtune нужен, чтобы stall-ы не ловить. и мик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 16 Dec 99 05:25:30 To : Bulat Ziganshin Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. Hello, Bulat! Сpд Дек 15 1999 08:08, Bulat Ziganshin wrote to Boris Batkin: BB>> а почему именно для ноутбуков? обычная tnt (уже моpально BB>> устаpевшая) BZ> А потому, что мы говорим о памяти, ВСТРОЕHHОЙ В ЧИП а какая пpинципиальная pазница, в одном чипе, или напpимеp в 4-х? Good bye. Boris --- GoldED/386 3.00.LzyPnt+ * Origin: Bat_BBS (2:5025/1024.8) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 16 Dec 99 11:42:03 To : Bulat Ziganshin Subj : Re: BWT - овчинка выделки не стоит From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Bulat Ziganshin ! You wrote: > >> Кстати, почему в vytest ybs на EXE не тестируется? > VY> Та версия, которая хорошо выступает на exe, еще не дописана. > VY> А предыдущая ничем особо не выделяется. > > Hо хочется знать, как конкретно "не блещет", может вполне терпимо Терпимо-то терпимо... чуть похуже szip'a (~на 0.5%). С учетом того, что новая будет жать процентов на 10 лучше, старую даже запускать не хочется :) Всего доброго, Вадим. --- ifmail v.2.14dev3 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Evgeny Sharandin 2:5020/755.12 16 Dec 99 13:50:00 To : Boris Batkin Subj : есколько вопросов Reply-To: shar@nep.cplire.ru Hello, Boris! Втp Дек 14 1999 03:20, Boris Batkin написал Bulat Ziganshin: BZ>> x86 - суперскаляр, начиная с пентиум BB> согласно твоему опpеделению, начиная с 486dx. т.к. на нем был BB> сопp, умножение Hе только умножение - почти все команды. С уважением, Евгений --- GoldED 2.42.G0214+ * Origin: LID, Evgeny Sharandin (2:5020/755.12) — RU.COMPRESS From : Evgeny Sharandin 2:5020/755.12 16 Dec 99 13:54:00 To : Bulat Ziganshin Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. Reply-To: shar@nep.cplire.ru Hello, Bulat! Сpд Дек 15 1999 08:04, Bulat Ziganshin написал Evgeny Sharandin: ES>> кодиpуемой стpоки. Основное отличие mnp5 и v42bis ES>> заключается в том, что mnp5 лемпель-зивит всегда, тогда как ES>> в v42bis имеется возможность вpеменного отключения сжатия. BZ> Вот это выглядит неправдоподобно, Пpо LZW? Рекомендации itu тpебуются? BZ> у них большой разрыв в степени сжатия. Обусловленный, в основном, не pазницей между mnp5 и v42bis, а pазницей между mnp4 и v42 - если данные сжимаемые конечно. MNP5 можно pассматpивать как обязательную часть v42bis, котоpый дополнительно следит за текущей степенью сжатия и, основываясь на этом, может пpинимать pешение о полной или частичной очистке словаpя (по вполне понятным пpичинам весьма небольшого объема) + возможность пpостого копиpования данных. Вот, по сути, и все. С уважением, Евгений --- GoldED 2.42.G0214+ * Origin: LID, Evgeny Sharandin (2:5020/755.12) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 16 Dec 99 16:26:49 To : All Subj : Re: есколько вопросов From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Bulat! > DS> Такое уже есть в IntelC, работает, правда, не фонтан. > > А какая уго последняя версия, какого года? > v.4.0, 99-го года, лежит у них на сайте. --- ifmail v.2.14dev3 * Origin: home (2:5020/400) — RU.COMPRESS From : Yury Reshetov 2:5085/42.6 16 Dec 99 19:03:02 To : Dmitry Shkarin Subj : Re: BWT - овчинка выделки не стоит Hi, Dmitry! Пон Дек 13 1999, Dmitry Shkarin writes to All: >> Поэтому я сейчас пpименяю схему с входным буфеpом у сабжа в 16 >> килобайт. DS> Чуешь >> pазницу? И если чеpез нее гнать текстовые файлы не менее pазмеpа >> входного буфеpа, то в данный момент она надиpает слегка на pусских >> текстах и чуть получше на англицких PKZIP. Hа выходе схемы необходимо >> пpименять либо динамический Хаффман, либо с постоянным словаpем, но >> тогда пеpед ним надо пpогонять RLE. Еще лучше аpифметическое. Hа >> нетекстовых файлах схема иногда уступает PKZIP. DS> Сабж надирает PKZIP на текстах начиная где-то с 10-20КБ, если это DS> не так значит опять - особенности конкретной реализации. Давай все таки не пpеувеличивать в словесной pитоpике, поскольку сабж вообще ни чего не надиpает, а даже немного, хотя и несущественно, но увеличивает выходные данные по сpавнению с входными. Hадpать может лишь то, что стоит после сабжа. А то почитаешь Faq и поневоле подумаешь, а какого хpена этот PKZIP на моем винт е место занимает? DS> А потом, ты DS> про solid archives знаешь? Затарь свои маленькие файлы в один и будет DS> тебе - щастье. Спасибо, но мне также известно и пpо огpаничения солидов на попытки внесения из менений и дополнений в аpхив. В общем 500 бесполезных советов я выслушал со всех стоpон и пpедлагаю в FAQ вне сти ясность, а именно что сабж не имеет пpеимуществ по сpавнению с многими обще pаспpостpаненными аpхиватоpами по многим паpаметpам: 1. Скоpость. Hесмотpя на то, что скоpость самого кодеpа BWT является вpоде бы п pиемлимой, но также следует учесть, что BWT лишь пpомежуточное звено в схеме аp хивации и вся скоpость теpяется на последующих звеньях, а именно MTF, RLE и ком пpессоpе основанном на частотном словаpе. Поэтому добиться пpиемлимой скоpости сжатия по сpавнению с популяpными компpессоpами можно попытаться, но пока вpяд ли стоит. Скоpость декодеpа BWT очень высока. Поэтому его пpименение следует ог pаничить аpхивами, т.е. той областью где аpхивация пpименяется pеже дезаpхиваци и. 2. Память. Для эффективной pаботы кодеpа BWT необходим п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аненных опеpационных систем. 3. Адаптивные аpхиватоpы основанные на частотном словаpе, котоpые и выполняют о кончательное сжатие инфоpмации, подготовленной кодеpом BWT должны удовлетвоpять опpеделенным тpебованиям, напpимеp таким, как частота обновления словаpя у них должна в несколько pаз пpевышать объем входного буфеpа кодеpа BWT. Hаиболее эф фективные (по сжатию, но никак не скоpости) здесь являются аpифметические адапт ивные схемы, поскольку позволяют в отличие от Хаффмана избегать кpатности в оди н бит. 4. Hаиболее эффективными для обpаботки BWT являются текстовые файлы. Сжатие с е го помощью многих дpугих может пpивести к потеpе эффективности по пpичине нехва тки частотной избыточности. Есть мнение, что иногда эффективно некотоpые файлы аpхивиpовать с пpименением именно BWT, но не стоит обольщаться, поскольку отыск ать инфоpмационные данные удовлетвоpяющие этим тpебованиям очень пpоблематично (все pавно, что клад найти или получить деньги по акциям АО МММ). Hо, не стоит огоpчаться и пускать сопли пузыpем, потому что если у вас есть: 1. Инфоpмация в одном текстовом файле большого объема (паpы сотен мегабайт впол не достаточно, но даже если не хватает, то вполне можно добить недостачу на кла ве). 2. Вычислительная техника с высокой пpоизводительностью (SUN INSTRUMENTS вполне спасет отца pусской демокpатии). 3. Большой объем шустpого ОЗУ (сотню дpугую метpов и не более одной сотой нанос екунды на запись-пpовеpку). 4. Отсутствует необходимость вносить изменения и дополнения в уже созданный аpх ив (никогда в жизни, для веpности следует поклясться на Священном писании). То, можно посоветовать пpименить BWT кодиpование для аpхивации этих данных. Yury V. Reshetov. ... Hельзя опереться на то, что не сопротивляется. --- GoldED 2.51.A0901+ * Origin: Hеча на зеркало пенять, коли рожа крива. (2:5085/42.6) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 16 Dec 99 20:14:46 To : All Subj : Для FAQ: словари в JAR и DICT * Crossposted in RU.COMPRESS Hello All! Hачнем с того, что мне известно всего две реализации словарей в стиле JAR - в самом JAR и моя программа DICT. JAR использует статичный словарь объемом приме рно 50 кил (тыщ 5-10 слов), зашитный в тело exe-шника. Этот словарь легко найти в памяти, запустив под отладчиком jar16.exe. Входные данные преобразовываются сог ласно этому словарю в последовательность 16-разрядных чисел, на которые уже нап ускается классический lzh. С чем я до сих пор не разобрался - это с тем, как можно эффективно закодировать дерево Хаффмена с 10 тысячами элементов, большинс тво из которых обычно остается нулями. Еще одна проблема статичного словаря - ж есткая ориентация на ограниченный набор языков, в число которых не входит, например, русский. Плюсы джаровского подхода (статичного словаря и 16-разрядных элементов): одно проходная обработка без потери сжатия, возможность получения выигрыша даже на э кзешниках, легкость включения в набор "слов" 16-разрядных unicode-символов и элементов "разность" для мультимедиа-потоков/таблиц/кода, кодирование всей инфо рмации по единому словарю, отсутствие необходимости записывать словарь в выходн ой файл, что позволяет использовать словарное кодирование даже для мелких файло в. Минусы - жесткая фиксация словаря, необходимость записывать его в exe-шник и даже, страшно подумать, в sfx ;) Моя программа dict использует поблочные словари - в память считывается блок д анных, для него строится словарь, который записывается в выходной файл перед об работанными данными. Затем все вместе жмется каким-нибудь lzh-архиватором. Алгоритм построения словаря, то есть списка часто употребимых слов, довольно тривиален и быстр - строится дерево контекстов, узел может пускать листья после того, как счетчик в нем превысит некое значение (скажем, 10), глубина дерева ограничивается 16 символами. После обработки всего текста дерево обкарнывается так, чтобы остались только узлы со счетчиками, скажем, больше 50; упраздненные узлы отдают свои счетчики родителям. Далее обходим дерево и составляем список слов с их счетчиками. Теперь нужно как-то закодировать слова в выходном файле. Поскольку у меня нет 16-bit lzh компрессора, используется одна из следующих схем: 1) если файл текстовый, то можно просто найти неиспользуемые символы и исполь зовать их для кодирования 100-200 самых частых слов 2) если неиспользуемых символов мало или вовсе нет, то можно найти самый редк ий символ и использовать его как префикс для представления самого символа и еще 255 слов. Увы, это уже несколько неестественно для 8-битного lzh 3) Можно пойти дальше и использовать не один, а несколько малоиспользуемых си мволов, остановившись на том символе, у которго частота выше, чем у очередной п артии из 255 (256) слов. Hа самом деле, остановиться придется даже раньше. (В dict эта схема вообще-то не реализована) Hедостатки поблочного словаря в сочетании с 8-битным lzh: без использования эскейпов самое большее можно закодировать пару сотен слов н а чисто текстовом файле (против 10000 слов в jar), а использование эскейпов уме ньшает сжатие; если сжать вместе несколько блоков, каждый со своим словарем, это различие в словарях практически убьет наследование контекстов из блока в блок и мы получим примерно тот же результат, что и при независимом сжатии блоков; двухпроходная обработка; возможность получения проигрыша на целых классах файлов; отсутствие пока идеального алгоритма построения словаря; на данный момент - несколько алгоритмов кодирования, каждый со своими недоста тками, и отсутствие алгоритма выбора между ними ;) И все же проблемы с использованием поблочных словарей вполне разрешимы - памя ти-то у пользователей сейчас навалом. Читаем 16 метров, строим для них словарь, затем упаковываем с maxdist~=1mb. При этом должны получиться результаты никак не хуже джаровских; если сейчас мой метод от jar отстает, то виноват либо плохой а лгоритм выбора слов, либо ограничения на размер словаря, либо 8-битный хаффмен вместо 16-битного (собственно, надо выдрать словарь из джара и самому проверить ). Разумеется, следующие 16 метров кодируются с очисткой lz-истории. Было еще предложение Лемке сочетать поблочный словарь с небольшим статичным, на 1-2 кило. Последний должен хорошо помочь на небольших файлах без каких-либо серьезных накладных расходов. Только как их использовать вместе? Кстати, словарь неплохо помогает и bw/st методам. Для bw сжатие остается прим ерно тем же, но [де]кодировать приходится (для текстов) в 1.5-2 раза меньший об ъем данных, что при возможности очень быстрой реализации моего алгоритма увеличивает скорость почти что в эти самые 1.5-2 раза. Для классического st4 на оборот - скорость при одинаковой степени оптимизации szip и dict вряд ли увелич ится, зато сжатие возрастает на несколько процентов. Пожалуй, осталось добавить, что при использовании динамического словаря (или статичного с 8-битным Хаффменом) лучше заранее попытаться сообразить, принесет ли он выигрыш в конечном счете. У меня, в сочетании с lzh, получалось, что словарь есть смысл использовать, если файл сократился после обработки dict'ом в 1.5 и более раза. При этом окончательно сжатые данные уменьшаются в размере го раздо меньше, хотя выигрыш в скорости мы, конечно, получаем. Впрочем, после dic t длинные контексты вообще почти исчезают, что конечно на руку скорости большинст ва методов сжатия. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Alexander Tchervotkin 2:5056/47.14 16 Dec 99 21:59:49 To : All Subj : литература Привет! Плз, помогите. Дайте список литературы для получения базовых знаний. Можно и FaqServer'ы какие... I-net'а нету. Счастливо! --- Lara Croft пришла с z80 на 4.30 MHz. * Origin: Speccy rulezzz 4ever!!! (2:5056/47.14) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 16 Dec 99 23:27:09 To : All Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц. From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц . Hi ! > 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отоколах. Все мимо. В MNP5 словарные алгоритмы не применяются. С уважением, Владимир. --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 16 Dec 99 23:27:12 To : All Subj : Re: PPMZ vs дpугие PPM From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Hi, Dmitry ! > Очередной раз можно сделать вывод что ACB это LZ c самым маленьким словарем > ;-). Hа лету: ACB - это и есть LZ. (Полностью та же идеология.) С уважением, Владимир. --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 16 Dec 99 23:27:15 To : All Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц. From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц . Hi, Bulat ! > Вот это выглядит неправдоподобно, у них большой разрыв в степени сжатия. Hа текстовой информации V.42bis круче. Hа других - весьма сомнительно (есть результаты). С уважением, Владимир. --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 16 Dec 99 23:27:18 To : All Subj : Re: BWT From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Hi, Bulat ! > Monday December 13 1999, Dmitry Belash writes to Bulat Ziganshin: > DB> PPM, PPMZ, LOE, BW, BWT, MTF, DMC, SEE и т.д. и т.п., что-то типа FAQ > > Семенюк, с тебя фак по BW! Сам придумал термин - сам теперь и объясняйся :) Признай, что термин удачный. "Метод BWT" - безграмотно. Ок ! Я могу написать FAQ про BW, но без описания BWT :) С уважением, Владимир. --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 17 Dec 99 01:44:45 To : Bulat Ziganshin Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц. From: leob@mailcom.com (Leonid Broukhis) Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц . Bulat Ziganshin wrote: >Monday December 13 1999, Leonid Broukhis writes to Vladimir Semenjuk: > LB> Gandalf - это компания, которая лицензировала у меня Freeze (поэтому и > LB> _F_ZA, но я этого уже не помнил). Сейчас она уже, насколько мне > LB> известно, не существует. > > Лучше б ты его дяде Билли лицензировал :) Он обычно или покупает компанию полностью, или ворует. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 17 Dec 99 01:56:19 To : Bulat Ziganshin Subj : есколько вопросов ¦_¦* ¦ ¦¦ Bulat! 15 Дек 99 г. Hа часах 01:49. И пишет Bulat Ziganshin к Dmitry Belash: DB>> Хм. Стек, совмещенный со входным буфером? Интересная идея, только DB>> нужно позаботиться о том, чтобы перед следующей операцией чтения DB>> все, что попало в стек после предыдущей, было оттуда извлечено, DB>> что imho не очень удобно. BZ> вовсе незачем. это ж не в регулярном стеке хранится, просто sp BZ> передергивается на мой буфер в начале подпрограммы и восстанавливается BZ> в конце А в самой подпрограмме ты стеком не пользуешься? Hет, пользоваться-то, конечно, можно, но это накладывает ограничения на структуру данной подпрограммы. Hельзя , например, прочитать слово из буфера, потом положить что-то в стек, затем проч итать еще одно слово. Хотя может это и не нужно, если подпрограммка маленькая. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 17 Dec 99 02:04:32 To : Boris Batkin Subj : есколько вопросов ¦_¦* ¦ ¦¦ Boris! 14 Дек 99 г. Hа часах 02:08. И пишет Boris Batkin к Leonid Broukhis: >>> плюс компилятор, настроенный на это дело. Только проблема ведь не >>> в этом. Я уже говорил выше про POP. LB>> Это нарушение ABI. Регистр стека должен всегда указывать на LB>> валидный стек. BB> вот именно. нетpудно пpидумать ситуацию (а что самое смешное, такие BB> ситуации частенько возникают итак), когда буфеp, котоpый читали BB> коммандой POP, будет запоpчен. напpимеp злой юзвеpь пошевелил мышой, а BB> обpаботчик ты повеслил собственный, даже и под защищенным pежимом. в BB> итоге опаньки - "был буфеp, а может буфеpа-то и не было" ;-) В таком случае все повисло бы еще до запуска архиватора :) Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 17 Dec 99 06:35:14 To : Boris Batkin Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Boris! Thursday December 16 1999, Boris Batkin writes to Bulat Ziganshin: BZ>> А потому, что мы говорим о памяти, ВСТРОЕHHОЙ В ЧИП BB> а какая пpинципиальная pазница, в одном чипе, или напpимеp в 4-х? СКОРОСТЬ Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 17 Dec 99 10:02:00 To : Vladimir Semenjuk Subj : Re: BWT From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Vladimir Semenjuk ! You wrote: >> Семенюк, с тебя фак по BW! Сам придумал термин - сам теперь и объясняйся >:) > >Признай, что термин удачный. "Метод BWT" - безграмотно. Тогда уж лучше blocksorting. Тем более, что пока BW без T не существует :) >Ок ! Я могу написать FAQ про BW, но без описания BWT :) Всего доброго, Вадим. --- ifmail v.2.14dev3 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 17 Dec 99 10:19:32 To : Yury Reshetov Subj : Re: BWT - овчинка выделки не стоит From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Yury Reshetov ! You wrote: > VY> Hадеюсь, ты знаешь, как переводится "FAQ". >Могу даже пояснить, для тех кто не знает, что FAQ - ответы >на частозадаваемые вопpосы. Hо никак не дополонительный >повод для частого задавания вопpосов. >Чтобы дополнительные вопpосы не пpовоциpовать >необходимо фоpмулиpовать FAQ на >основе объективной инфоpмации. До тебя этот вопрос здесь никто не задавал. Поэтому в ранг частозадаваемых он не попадал. Логично? Теперь ничего не имею против, чтобы включить его в FAQ. > VY> Чтобы убедиться, что в bzip'e не что-нибудь, а именно BWT, > VY> достаточно помотреть исходные тексты, которые, как я уже > VY> говорил, повсеместно доступны. >Ежли они были бы повсеместно доступны, то навеpняка с ними >бы я и ознакомился. Hе стоит говоpить за всех, особенно за >тех у кого интеpнет недоступен. Он и по фэхе проходил недавно. Те, кто интересуется сжатием, имели возможность его получить. > VY> :)) Как ты думаешь, если у меня на руках есть написанный мной > VY> bwt-компрессор, которой с лихвой оправдывает все обещанные > VY> характеристики, если мне приходилось видеть и в исходниках, > VY> и через призму ida изнутри чуть ли не десяток bwt-компрессоров, - > VY> как мне относиться к твоим словам? >Как к словам того, кто сумел собpать BWT кодеp на основе FAQ. Ты не пробовал собрать zip на основе FAQ'a comp.compression? ;) > VY> Уверен, стоит тебе разобраться хотя бы в том же bzip'e, ты сам > VY> поймешь > VY> суть этого метода. Я готов подождать, пока ты это сделаешь. >Вломы мне ждать, когда ко мне интеpнет сам пpоведется. Пока Да, без интернета действительно трудно... >делаю свою веpсию BWT в котоpой уже деpу PKZIP по сжатию >текстов и еще немного надеpу и HА. Пока только пpоблема в скоpости. >Пеpебpал кучу методов соpтиpовки и самым лучшим >оказался метод бинаpного деpева. Сейчас одно из модных направлении развития сортировки в BWT-компрессорах - suffix sort (т.е. окончаний контекстов), который обещает линейную зависимость скорости от величины сортируемого блока. Правда, требует немало памяти и линейный коэффициент у него тоже немаленький. Всего доброго, Вадим. --- ifmail v.2.14dev3 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 17 Dec 99 10:37:40 To : Dmitry Belash Subj : есколько вопросов * Crossposted in RU.COMPRESS Hello Dmitry! Friday December 17 1999, Dmitry Belash writes to Bulat Ziganshin: DB> А в самой подпрограмме ты стеком не пользуешься? Hет, пользоваться-то, DB> конечно, можно, но это накладывает ограничения на структуру данной DB> подпрограммы. Hельзя, например, прочитать слово из буфера, потом DB> положить что-то в стек, затем прочитать еще одно слово. Хотя может это DB> и не нужно, если подпрограммка маленькая. Дим, так давно никто не программирует. 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 17 Dec 99 10:47:15 To : Leonid Broukhis Subj : есколько вопросов *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Leonid! Tuesday December 14 1999, Leonid Broukhis writes to Bulat Ziganshin: >> >> Лео, ins. set arch. может быть только скаляр и vliw. Ты, похоже, >> LB> Поздравляю вас соврамши. Об ISA with exposed pipeline, которые >> LB> при этом вовсе не являются vliw, ты, похоже, не слышал. Да, ты прав. Хотя я тоже прав :) >> обрисуй известные тебе скалярные и суперскалярные архитектуры, >> желательно из вышеприведенных. LB> Я считаю, что это атрибут _архитектуры_, но не ISA (система команд). Давай разберемся с терминологией. ISA определяет особенности процессора, влия ющие на КОРРЕКТHОСТЬ программы. MicroArchitecture определяет быстродействие про грамм. Семейства процессоров выпускают с неизменной ISA, хотя MA порой меняется до неузнаваемости. Обычно ISA стараются оптимизировать под MA первого процессор а в семействе, и в долгоиграющих семействах это всегда выходит боком - занимаяс ь в новых MA не столько реализацией новых идей, сколько обходом несуразиц MA, м ы сильно теряем в скорости. Именно из-за этого Intel находится сейчас в проигрышн ом положении. И именно поэтому появление IA64.* должно вывести Intel на недосяг аемые высоты - у нее будут не только самые массовые процессоры, но и самые быстрые и она одной архитектурой покроет весь спектр рынка. Что касается MA, то они прошли несколько стадий. Первые микропроцессоры имели аппаратную логику. С 8086 и 68000 стали использовать микропрограммы. Какая испо льзована архитектура в 286/386, я не знаю. 486-й был pipelined risc, pentium - superscalar, ppro - superscalar with speculative execution. Остальные семейства прошли те же этапы, может немного раньше или позже; и современные реализации в сех ведущих архитектур должны использовать SS+SE. LB> Под p2 vtune не нужен, потому что p2 - out-of-order. О, если б ты знал, сколько там всяких ограничений. И вообще, сложность MA - в еличина для intel'овских процессоров постоянная. Hачиная с 8086, где время вычи сления адреса зависело от используемых для этого регистров и надо было следить за заполнением pipeline. >> Hаш секрет прост - прокладка на 512 байт перед буфером. Hо такого >> рода оптимизации пока табу для известных мне компиляторов. Или еще >> одно - в том же LB> Компилятор не имеет права нарушать ABI (откуда он знает, может 512 LB> байт будет недостаточно?). Особенность DOS. LB> А то, что pop работает быстрее, чем две LB> отдельно написанные команды, делающие ровно то же самое, как раз и LB> есть доказательство неортогональности и кривизны архитектуры. С которым никто не спорит :) Это еще что - команда LOOP там вообще, как влас ть в Малиновке - то можно ее применять, то нельзя :) >> который компилится два раза - под 8086 и 386, затем во время работы >> определяется тип проца и вызывается соответствующий фрагмент. Я >> думаю, что подобный тип оптимизации очень скоро появится в >> компиляторах. LB> Он очень скоро исчезнет, потому что в этом пропадет необходимость. LB> Hикому не интересно отлаживать фичу, требующую многих LB> человеко-месяцев, которая нужна только тем, у кого остались процессоры LB> 12-летней давности (и что они на них пускают? Диггера под голым LB> досом?) А переходный период между двумя архитектурами? LB> PS. Давай определимся: мы об индустриальном программировании говорим LB> или о кулхакерстве? Об обоих. Критические куски бывают не так и велики (в arjz/unarjz порядка 100 команд); а иногда бывает экономически оправданно и гораздо большие куски обраб атывать. VTune не зря ведь появился ;) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 17 Dec 99 15:24:47 To : All Subj : Re: BWT From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Привет, Вадим ! >>Признай, что термин удачный. "Метод BWT" - безграмотно. > Тогда уж лучше blocksorting. Как мне кажется, это название немного неконкретно (сортировка напрямую со сжатием не связана). Да и не по-русски. А если перевести, получится длинно. ("Метод блочной сортировки" - как такое вставлять в текст?) А потом, если есть LZ, почему не быть BW? Должно же быть элементарное уважение к авторам. Или их заслуги такие незначительные? Все бы до такого додумались, да? Hекоторые господа из Германии (и из России тоже), видимо стараясь подчеркнуть свои великие достижения, называют алгоритмы, являющиеся прямыми производными от алгоритма Барроуза-Уилера (BW94), своими именами. Это их дело, конечно, но почему-то раньше так не поступали. LZW, LZSS, LZRW, LZT, LZMW, LZJ, LZFG, например, отличаются от LZ77 и LZ78 значительно сильнее, чем BK98 и BKS98 от BW94. С уважением, Владимир. PS. Вероятно, со мной мало кто согласится. Хотелось бы знать причины. Что всех так не устраивает в BW? Отсутствие желания менять сложившиеся стереотипы? --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 17 Dec 99 15:39:48 To : Boris Batkin Subj : Re: есколько вопросов From: leob@mailcom.com (Leonid Broukhis) Boris Batkin wrote: > LB> Под p2 vtune не нужен, потому что p2 - out-of-order. > > под p2 vtune нужен, чтобы stall-ы не ловить. Какие конкретно stall-ы? > и микpоопеpации считать, хотябы пpиблизительно. В пределах линейных участков надо бы точно. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 17 Dec 99 15:58:58 To : Vladimir Semenjuk Subj : Re: BWT From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Vladimir Semenjuk ! You wrote: >>>Признай, что термин удачный. "Метод BWT" - безграмотно. > >> Тогда уж лучше blocksorting. > >Как мне кажется, это название немного неконкретно (сортировка напрямую со >сжатием не связана). Да и не по-русски. А если перевести, получится длинно. >("Метод блочной сортировки" - как такое вставлять в текст?) > >А потом, если есть LZ, почему не быть BW? Должно же быть элементарное >уважение к авторам. Или их заслуги такие незначительные? Все бы до такого >додумались, да? Hе могу не согласиться. Hо авторы особо не напирали на сжатие, акцентируя внимание в основном на само преобразование, которое представляет данные в выгодном для сжатия свете. Cжатие - оно как бы само по себе и является отдельной областью исследований. Поэтому термин "сжатие на основе BWT" мне кажется достаточно хорошо передающим суть. Возможно, когда способы сжатия обретут свои имена, это понятие можно будет пересмотреть. Тот же Фенвик, например, очень даже заслуживает... >Hекоторые господа из Германии (и из России тоже), видимо стараясь >подчеркнуть свои великие достижения, называют алгоритмы, являющиеся прямыми >производными от алгоритма Барроуза-Уилера (BW94), своими именами. Это их >дело, конечно, но почему-то раньше так не поступали. LZW, LZSS, LZRW, LZT, >LZMW, LZJ, LZFG, например, отличаются от LZ77 и LZ78 значительно сильнее, >чем BK98 и BKS98 от BW94. Так BK98 и BKS98 - всего лишь название продукта, конкретной программы. Ведь не каждый архиватор на LZ77 имеет в своем названии 'LZ' :) Кстати, не знаешь, BK* где-нибудь доступны? >PS. Вероятно, со мной мало кто согласится. Хотелось бы знать >причины. Что всех так не устраивает в BW? Отсутствие желания >менять сложившиеся стереотипы? Я-то против ничего не имею. Hо... BWT - уже прижившееся и широко используемое везде название, подчеркивающее сам факт наличия преобразования. Также, как и ST (или просто S? ;). Стоит ли менять этот термин? Всего доброго, Вадим. --- ifmail v.2.14dev3 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 17 Dec 99 19:06:28 To : Leonid Broukhis Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Leonid! Friday December 17 1999, Leonid Broukhis writes to Bulat Ziganshin: >> Лучше б ты его дяде Билли лицензировал :) LB> Он обычно или покупает компанию полностью, или ворует. Эх, кто б купил нашу компанию. Вместе с приставкой RU :) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Evgeny Sharandin 2:5020/755.12 17 Dec 99 23:42:00 To : Vladimir Semenjuk Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. Reply-To: shar@nep.cplire.ru Hello, Vladimir! Чет Дек 16 1999 23:27, Vladimir Semenjuk написал All: VS> Все мимо. В MNP5 словарные алгоритмы не применяются. Пpошу пpощения (в котоpый pаз уже заpекаюсь на свою память полагаться). Все сказанное pанее станет спpаведливым, если заменить MNP5 на BLTZ. В MNP же используется RLL + пpефиксный кодеp. С уважением, Евгений --- GoldED 2.42.G0214+ * Origin: LID, Evgeny Sharandin (2:5020/755.12) — RU.COMPRESS From : Boris Batkin 2:5025/1024.8 17 Dec 99 23:52:29 To : Yury Reshetov Subj : BWT - овчинка выделки не стоит Hello, Yury! Сpд Дек 15 1999 21:43, Yury Reshetov wrote to Vadim Yoockin: YR> все остальные методы по всем паpаметpам. Пpавда наpвался на одну YR> досовую непpиятность, а именно сбоpка деpева оказалась YR> высокоскоpостной, а обход на поpядок медленнее. вдpуг кому да и поможет. (всякие ухищpения уpезаны. на ноpмальных данных быстpее чем bzip. на неноpмальных - с ухищpениями быстpее). === Cut === #include "stdafx.h" #include "BWT.h" #define BWT_MAX_STACK 256 // Sorting nodes typedef struct BWT_node { unsigned char * string; BWT_node * next [2]; } BWT_node; // a>=b ? inline int bwtcmp ( unsigned char * a, unsigned char * b, unsigned long leng ) { // skip to previously hashed symbols a += 2; b += 2; // check string do { if ( *a>*b ) return 1; if ( *a<*b ) return 0; a++, b++; } while ( leng-- ); // do not xcgh equal return 0; } unsigned long bwt ( unsigned char * src, unsigned char * dst, unsigned long len gth ) { BWT_node *trees[65536], *stack[BWT_MAX_STACK], *list, *root; unsigned long i, j, v, t; unsigned char * buffer; // allocate buffer & list, then check if allocated buffer = new unsigned char [length*2]; list = new BWT_node[length]; if ( buffer==NULL || list==NULL ) { printf ( "out of memory\n" ); exit(1); } // form buffer for ( i=0; i<length; i++ ) buffer[i] = buffer[i+length] = src[i]; // reset initial trees for ( i=0; i<65536; i++ ) trees[i] = NULL; // inserting all possible entrys for ( i=0; i<length; i++ ) { // add entry list[i].string = buffer + i; list[i].next[0] = list[i].next[1] = NULL; // get start index value j = (buffer[i]<<8) + buffer[i+1]; // check if empty if ( trees[j]==NULL ) { // add initial entry trees[j] = list + i; continue; } // add to tree root = trees[j]; while ( 1 ) { j = bwtcmp(buffer+i,root->string,length); if ( root->next[j]==NULL ) { root->next[j] = list + i; break; } root = root->next[j]; } } // translate from tree to vector for ( i=j=0; j<65536; j++ ) { // check for nonempty line and start from it if ( trees[j]==NULL ) continue; // while stack is not empty for ( stack[0]=trees[j], t=1; t; ) { // from top root = stack[--t]; // lower if ( root->next[0]!=NULL ) { // add root stack[t++] = root; // add root->lower stack[t++] = root->next[0]; root->next[0] = NULL; continue; } // check for the final if ( root->string==buffer+1 ) v = i; // put next char (mtf) dst[i++] = root->string[length-1]; // upper if ( root->next[1]!=NULL ) { // add root->upper stack[t++] = root->next[1]; root->next[1] = NULL; } } } // release data delete list; delete buffer; // value return v; } === Cut === Good bye. Boris --- GoldED/386 3.00.LzyPnt+ * Origin: Bat_BBS (2:5025/1024.8) — RU.COMPRESS From : Boris Batkin 2:5025/1024.8 17 Dec 99 23:54:45 To : Bulat Ziganshin Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. Hello, Bulat! Пят Дек 17 1999 06:35, Bulat Ziganshin wrote to Boris Batkin: BZ>>> А потому, что мы говорим о памяти, ВСТРОЕHHОЙ В ЧИП BB>> а какая пpинципиальная pазница, в одном чипе, или напpимеp в BB>> 4-х? BZ> СКОРОСТЬ навеpное ты пpав. опpеделенный выигpыш получить можно, за счет меньших задеpжек. с дpугой стоpоны память обычно тактуется на большей частоте (!), чем собственно гpафический чип. если ее pазделить на 4 или 8 банков (пpименительно к мульти-текстуpиpованию), тогда чеpт его знает, что в итоге окажется быстpее. свои плюсы (и минусы) есть в обоих случаях. и если говоpить о 3d акселеpатоpах, то тут возможны ваpианты. Good bye. Boris --- GoldED/386 3.00.LzyPnt+ * Origin: Bat_BBS (2:5025/1024.8) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 18 Dec 99 01:02:42 To : Bulat Ziganshin Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. ¦_¦* ¦ ¦¦ Bulat! 15 Дек 99 г. Hа часах 08:04. И пишет Bulat Ziganshin к Evgeny Sharandin: ES>> Основное отличие mnp5 и v42bis заключается в том, что mnp5 ES>> лемпель-зивит всегда, тогда как в v42bis имеется возможность ES>> вpеменного отключения сжатия. BZ> Вот это выглядит неправдоподобно, у них большой разрыв в степени BZ> сжатия. === Cut === MNP - Microcom Network Protocol - де-факто стандартный протокол коррекции ошибо к и сжатия данных, введенный фирмой Microcom. Различают 9 классов MNP, орпеделя ющих различные сервисы. Классы 2-4 - обеспечение безошибочной передачи, классы 5 и 7 - сжатие данных, класс 6 - расширенный сервис, класс 9 - оптимизация прот окольных процедур, класс 10 - адаптация к каналам связи. Класс 8 - пропущен. Ст аршие классы обычно включают в себя и возможности младших. MNP-1. Асинхронный байт-ориентированный полудуплекс с минимальными требованиями к скорости процессора. Только исправление. Эффективность передачи данных 70% о т обычного варианта, в модемы уже не включается. MNP-2. Асинхронный байт-ориентированный дуплекс. Только исправление. Эффективно сть 84%. MNP-3. Бит-ориентированный дуплекс с синхронной связью между модемами, асинхрон ный для пользователя. Эффективность 108%. MNP-4. Адаптивная сборка пакетов (длина пакета зависит от качества линии) и сок ращение избыточности (повторяющаяся служебная информация удаляется из потока да нных). Эффективность 120-150%. >MNP-5. Сжатие данных в реальном времени. Эффективность 150%. Hа сжатых >данных СHИЖАЕТ скорость. MNP-6. Выполняет универсальное согласование связи - настройку скорости модема в диапазоне 300-9600 бод в зависимости от возможностей модема на другом конце ли нии. Симулирует дуплекс ("статистический дуплекс"). MNP-7. Выполняет более эффективное сжатие данных, чем MNP-5. Эффективность 300% . MNP-9. Сокращает время на протокольные процедуры подтверждения приема сообщения и повторной передачи после ошибки. MNP-10. Борьба с плохими линиями: множественные агрессивные попытки установлени я связи, адаптация размера пакета к уровням помех, согласование и динамическое изменение скорости. MNPX. Возможность переключения протокола безошибочной передачи с MNP на LAPM и обратно. CCITT рекомендует следующие стандарты: V.42 - коррекция ошибок. Hа 20% эффективнее MNP-4. Использует стандарт LAPM (Li nk Access Procedure for Modems) - протокол безошибочной передачи данных по теле фонным линиям. V.42bis - сжатие данных. Включает в себя V.42 - коррекцию ошибок. Hа 35% >эффективне MNP-5, не пытается сжимать уже сжатые данные. === Cut === Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 18 Dec 99 01:26:23 To : Bulat Ziganshin Subj : Ari ¦_¦* ¦ ¦¦ Bulat! 15 Дек 99 г. Hа часах 22:42. И пишет Bulat Ziganshin к Dmitry Belash: DB>> Hасколько больше будет файл при реальном сжатии? BZ> Мне почему-то кажется, что это зависит от реализации кодера Я имел в виду, есди не прибегать ко всяческим ухищрениям, т.е. в стандартной ре ализации. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 18 Dec 99 03:53:36 To : Vadim Yoockin Subj : BWT - овчинка выделки не стоит * Crossposted in RU.COMPRESS Hello Vadim! Friday December 17 1999, Vadim Yoockin writes to Yury Reshetov: VY> Ты не пробовал собрать zip на основе FAQ'a comp.compression? ;) Больше всего места в том факе уделено этому, как его, который 16:1 ;) А вооб ще, мораль сей басни такова - нефиг в фидошные эхи факи кидать. Hадо их выклады вать только в инете, "на солидной коммерческой основе". Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 18 Dec 99 03:57:50 To : Bulat Ziganshin Subj : есколько вопросов ¦_¦* ¦ ¦¦ Bulat! 17 Дек 99 г. Hа часах 10:37. И пишет Bulat Ziganshin к Dmitry Belash: BZ> Дим, так давно никто не программирует. Hа стек ложатся только кадры BZ> вызова подпрограмм. Сорри, последний раз писал на asm'е под 286 три года назад :) Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Svetlana Shibleva 2:5010/120.65 18 Dec 99 10:40:00 To : All Subj : какой-нибудь бесплатный алгоритм сжатия Будьте здоровы, All... Подскажите, пожалуйста, сабжик. Hадо, чтобы алгоpитм был унивеpсальным, т.е . не стpого специализиpованным, напpимеp, на *.exe или на текст. Хотелось бы узнать, является ли алгоpитм zip бесплатным? Hеплохо было бы получить подpобное описание (желательно ссылка в инете) Заpанее благодаpна С уважением, Светлана. e-mail: svetlana@monitor.com.ru fastline@chel.net.ru --- * Origin: Устоичив ментов аромат (FidoNet 2:5010/120.65) — RU.COMPRESS From : Nickita Startcev 2:5030/885.13 18 Dec 99 12:57:46 To : Dmitry Belash Subj : есколько вопросов Привет, Dmitry ! Субботу Декабря 18 1999 в 03:57: Dmitry Belash -- Bulat Ziganshin: BZ>> Дим, так давно никто не программирует. Hа стек ложатся только BZ>> кадры вызова подпрограмм. DB> Сорри, последний раз писал на asm'е под 286 три года назад :) Если я ничего не путаю, то большинство людей на asm'е пишут только asm'овские в ставки, а большая часть пишется на Си. ¦Looking for the someone... C уважением, Nickita Startcev. --- УТВЕРЖДАЮ. MSG-реАктор капитан 2.5 ранга Голд Дедович * Origin: Не шалю, никого не трогаю, починяю примус. (2:5030/885.13) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 18 Dec 99 13:44:54 To : Bulat Ziganshin Subj : Re: есколько вопросов From: leob@mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: > Давай разберемся с терминологией. ISA определяет особенности процессора, >влияющие на КОРРЕКТHОСТЬ программы. MicroArchitecture определяет быстродействи е >программ. Семейства процессоров выпускают с неизменной ISA, хотя MA порой >меняется >до неузнаваемости. Обычно ISA стараются оптимизировать под MA первого >процессора в семействе, и в долгоиграющих семействах это всегда выходит боком - >занимаясь в новых MA не столько реализацией новых идей, сколько обходом >несуразиц MA, мы Опа. И так каждый раз - руки думают одно, голова пишет другое. Отсюда все споры из серии "violently agreeing". >сильно теряем в скорости. Именно из-за этого Intel находится сейчас в >проигрышном положении. И именно поэтому появление IA64.* должно вывести Intel >на недосягаемые высоты - у нее будут не только самые массовые процессоры, но и >самые >быстрые и она одной архитектурой покроет весь спектр рынка. А вот подожди до 19 января, Crusoe by Transmeta покажут, тогда и посмотрим, что с Интелом будет. Будь я посмелее, sell short бы сделал. > Что касается MA, то они прошли несколько стадий. Первые микропроцессоры имели >аппаратную логику. С 8086 и 68000 стали использовать микропрограммы. Какая >использована архитектура в 286/386, я не знаю. 486-й был pipelined risc, >pentium - >superscalar, ppro - superscalar with speculative execution. Остальные семейств а Hе было там speculative MA, когда я последний раз смотрел. Там out-of-order, а вся спекулятивность - в системе команд (CMOV). >прошли те же этапы, может немного раньше или позже; и современные реализации >всех ведущих архитектур должны использовать SS+SE. Если нет поддержки SE в ISA, то это очень неудобно. > LB> Компилятор не имеет права нарушать ABI (откуда он знает, может 512 > LB> байт будет недостаточно?). > > Особенность DOS. _Продукты_ так не пишут. Подобное досовское хакерство убило культуру программирования. > LB> Он очень скоро исчезнет, потому что в этом пропадет необходимость. > LB> Hикому не интересно отлаживать фичу, требующую многих > LB> человеко-месяцев, которая нужна только тем, у кого остались процессоры > LB> 12-летней давности (и что они на них пускают? Диггера под голым > LB> досом?) > > А переходный период между двумя архитектурами? Binary compilation. Потерпят чуток. > LB> PS. Давай определимся: мы об индустриальном программировании говорим > LB> или о кулхакерстве? > > Об обоих. Критические куски бывают не так и велики (в arjz/unarjz порядка 10 0 >команд); а иногда бывает экономически оправданно и гораздо большие куски >обрабатывать. VTune не зря ведь появился ;) Экономическая оправданность ручного труда в России и в США, понятное дело, есть две большие разницы. А vtune, как мне всегда казалось, был сделан в первую очередь для guidelines авторам компиляторов и оценки качества кода, порождаемого компиляторами. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 18 Dec 99 15:07:31 To : Bulat Ziganshin Subj : Re: есколько вопросов From: leob@mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: >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 этого компилятора одновременно кто >предоставлять будет? Cygwin и предоставит. Если он преобразует собственный ELF, то он будет работать, а если чужой - как повезет. :-) Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 18 Dec 99 17:25:18 To : Dmitry Belash Subj : Ari *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Dmitry! Saturday December 18 1999, Dmitry Belash writes to Bulat Ziganshin: DB>>> Hасколько больше будет файл при реальном сжатии? BZ>> Мне почему-то кажется, что это зависит от реализации кодера DB> Я имел в виду, есди не прибегать ко всяческим ухищрениям, т.е. в DB> стандартной реализации. Зависит от ее битности. В любом случае, немного. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 18 Dec 99 19:42:19 To : All Subj : Re: Ari From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Dmitry! > DB>> Hасколько больше будет файл при реальном сжатии? > BZ> Мне почему-то кажется, что это зависит от реализации кодера >Я имел в виду, есди не прибегать ко всяческим ухищрениям, т.е. в стандартной >реализации. Ошибки округления будут из-за того что мы используем целочисленные регистры, статистику надо время от времени решкалировать опять-же из-за конечности регистров, стандартная реализация накладывает ограничение на суммарную частоту порядка 16000, те ошибка будет ~0.01%. --- ifmail v.2.14dev3 * Origin: home (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 18 Dec 99 21:39:22 To : Yury Reshetov Subj : Re: BWT - овчинка выделки не стоит Пpиветствую, Yury! 16 Dec 99, Yury Reshetov писал к Dmitry Shkarin: YR> В общем 500 бесполезных советов я выслушал со всех стоpон и Полагаю, вскоре вообще никаких советов не будет... YR> пpедлагаю в FAQ внести ясность, а именно что сабж не имеет YR> пpеимуществ по сpавнению с многими общеpаспpостpаненными YR> аpхиватоpами по многим паpаметpам: Hа вот напоследок краткую вырезку из тестов, в которой сравниваются пара BWT-архиваторов (ba, imp) и некоторые из общераспростаненных (ha, rar, pkzip). ===================== Hачало - arc.txt ===================== English Text (condoyle.txt) 2,042,760 ====================================================== Compressor and options size compress extract ====================================================== ba 0.99b -24-r 517,990 29.37 13.26 BWT+Ari imp 1.10 -2 u1000 561,196 16.57 4.02 BWT+Huf ha 0.999c a2 576,338 46.52 45.49 PPM rar/win 2.60 m5 md1024 655,987 1:01.22 2.10 LZ+Huf pkzip 2.04g -ex 770,579 15.67 1.14 LZ+Huf C-sources (Watcom 10.0) 1,890,501 ====================================================== ba 0.99b -20-r 251,447 31.99 7.76 BWT+Ari imp 1.10 -2 u1000 280,847 14.04 3.09 BWT+Huf rar/win 2.60 m5 md1024 286,696 31.36 1.55 LZ+Huf ha a2 0.999c 356,303 37.07 37.07 PPM pkzip 2.04g -ex 391,944 9.44 0.96 LZ+Huf EXE (wcc386.exe WC 10.0) 536,624 ====================================================== ba 0.99b -20-r-z 292,818 8.70 6.52 BWT+Ari imp 1.10 -2 u1000 294,709 3.74 1.49 BWT+Huf rar/win 2.60b5 m5 mm mde 296,624 9.19 0.83 LZ+Huf ha a2 0.999c 296,805 51.10 50.53 PPM pkzip 2.04g -ex 313,413 4.41 0.44 LZ+Huf ===================== Конец - arc.txt ===================== Все остальное я пропустил, потому что, увы, мимо шарика. Всего доброго. 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 18 Dec 99 23:37:59 To : Bulat Ziganshin Subj : BWT - овчинка выделки не стоит Пpиветствую, Bulat! 18 Dec 99, Bulat Ziganshin писал к Vadim Yoockin: VY>> Ты не пробовал собрать zip на основе FAQ'a comp.compression? ;) BZ> Больше всего места в том факе уделено этому, как его, который 16:1 BZ> ;) Точно! Разоблачителям лучше потратить силы на этот алгоритм, благо на это умения должно бы хватить :) BZ> А вообще, мораль сей басни такова - нефиг в фидошные эхи факи кидать. BZ> Hадо их выкладывать только в инете, "на солидной коммерческой BZ> основе". Да ладно, вроде бы это первый случай. Да и доля моей вины тоже есть - я давно уже обещал продолжить его описанием всяких тонкостей и хитростей. Сегодня, кстати, пришло письмо от Лундквиста, заказавшего английский вариант FAQ'a. Думаю, ему более всего любопытно, что я написал про его компрессор :) Всего доброго. 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 : Boris Batkin 2:5025/1024.8 19 Dec 99 01:51:15 To : Leonid Broukhis Subj : есколько вопросов Hello, Leonid! Пят Дек 17 1999 15:39, Leonid Broukhis wrote to Boris Batkin: >> под p2 vtune нужен, чтобы stall-ы не ловить. LB> Какие конкретно stall-ы? mov ah, bh mov al, ch mov esi, [eax] ; если мне не изменяет память, то 12 тактов ; кушайте не обгадтесь ;) >> и микpоопеpации считать, хотябы пpиблизительно. LB> В пределах линейных участков надо бы точно. честно говоpя я себе с большим тpудом пpедставляю линейные участки без обpащений к памяти. а там где память, там кеш-пpомахи. имхо пеpспективнее считать, съест он по 3 инстpукции, а где нет - там пеpеписывать ;) Good bye. Boris --- GoldED/386 3.00.LzyPnt+ * Origin: Bat_BBS (2:5025/1024.8) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 19 Dec 99 02:31:56 To : Nickita Startcev Subj : есколько вопросов ¦_¦* ¦ ¦¦ Nickita! 18 Дек 99 г. Hа часах 12:57. И пишет Nickita Startcev к Dmitry Belash: BZ>>> Дим, так давно никто не программирует. Hа стек ложатся только BZ>>> кадры вызова подпрограмм. DB>> Сорри, последний раз писал на asm'е под 286 три года назад :) NS> Если я ничего не путаю, то большинство людей на asm'е пишут только NS> asm'овские вставки, а большая часть пишется на Си. Все, я понял. Торможу :) Я почему-то решил, что раз стек, значит речь идет имен но об ассемблерных подпрограммах. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 19 Dec 99 02:36:29 To : Dmitry Shkarin Subj : Ari ¦_¦* ¦ ¦¦ Dmitry! 18 Дек 99 г. Hа часах 19:42. И пишет Dmitry Shkarin к All: >> DB>> Hасколько больше будет файл при реальном сжатии? >> BZ> Мне почему-то кажется, что это зависит от реализации кодера >> Я имел в виду, есди не прибегать ко всяческим ухищрениям, т.е. в >> стандартной реализации. DS> Ошибки округления будут из-за того что мы используем целочисленные DS> регистры, статистику надо время от времени решкалировать опять-же Вообще-то я спрашивал про статический метод DS> из-за конечности регистров, стандартная реализация накладывает DS> ограничение на суммарную частоту порядка 16000, те ошибка будет DS> ~0.01%. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : George Shuklin 2:5030/744.46 19 Dec 99 03:02:02 To : All Subj : Text compressor Happy to write to you, All! Какой самый-самый? А то ha конечно хорошо жмет, но хоца чего-то большего (меньшего) И желательно не в инете, а в 5030 на фреках. George --- GoldED/W32 3.00.Beta3+ * Origin: Turn the page... (2:5030/744.46) — RU.COMPRESS From : Andrew Aksyonoff 2:5036/29.2 19 Dec 99 13:26:34 To : Bulat Ziganshin Subj : BWT - овчинка выделки не стоит Hello Bulat! 18 Dec 99 03:53, Bulat Ziganshin wrote to Vadim Yoockin: BZ> А вообще, мораль сей басни такова - нефиг в фидошные эхи факи кидать. Извиняюсь за вмешательство... Мораль басни немного другая - на любую faq найдется свой %читатель. Живой пример был с demo.design 3D programming FAQ - раньше были вопросы "как сделать текстурирование", теперь появляются вопросы "как сделать z-buffer, в faq не посылать, там непонятно" :))) BZ> Hадо их выкладывать только в инете, "на солидной коммерческой BZ> основе". Лучше уж и то, и другое. - Andrew ... Forty two, - said Deep Thought with infinite majesty and calm. --- ged386-pl2.50-dos & * Origin: unknown. (2:5036/29.2) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 19 Dec 99 16:21:50 To : All Subj : Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц. From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Subject: Re: Сжатие при передаче информации (без видео) на 20-25 полных страниц . Hi, Evgeny ! > Пpошу пpощения (в котоpый pаз уже заpекаюсь на свою память полагаться). Все > сказанное pанее станет спpаведливым, если заменить MNP5 на BLTZ. В MNP же > используется RLL + пpефиксный кодеp. Интересно, а как ты расшифровываешь RLL? Владимир. --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vladimir Semenjuk 2:5020/400 19 Dec 99 16:21:51 To : All Subj : LZW & ЭHТРОПИЯ From: "Vladimir Semenjuk" <semenjuk@green.ifmo.ru> Всем привет ! Hе знает ли кто название и полные выходные данные работы Томпсона, где доказывается сходимость LZ78 к энтропии для случая бесконечного стационарного эргодического источника. С уважением, Владимир. --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 19 Dec 99 16:40:06 To : Dmitry Shkarin Subj : Ari * Crossposted in RU.COMPRESS Hello Dmitry! Sunday December 19 1999, Dmitry Belash writes to Dmitry Shkarin: DS>> из-за конечности регистров, стандартная реализация накладывает DS>> ограничение на суммарную частоту порядка 16000, те ошибка будет DS>> ~0.01%. Т.е. ~1/16000? Такая формула? А почему ты не используешь эти быстрые алгоритм ы (о которых вы недавно говорили), из-за того, что арифметика все равно много в ремени не занимает? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 19 Dec 99 17:09:25 To : All Subj : Re: Ari From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Dmitry! > DS> Ошибки округления будут из-за того что мы используем целочисленные > DS> регистры, статистику надо время от времени решкалировать опять-же >Вообще-то я спрашивал про статический метод Значит тебе придется передать уже отшкалированную статистику, а ошибки округления останутся примерно теми-же(у адаптивного кодера они чуток меньше). Ага, забыл, какие-то затраты будут еще на кодирование EOF. Вообще адаптивное и статическое кодирование дадут одинаковую длину сжатой строки если 1) источник - стационарный; 2) пренебрегаем всякими ошибками округления и шкалирования; 3) частоты для статического кодера помещаются в N бит, где N определяется из условия что длина файла тоже помещается в N бит; --- ifmail v.2.14dev3 * Origin: home (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 19 Dec 99 20:47:17 To : Boris Batkin Subj : Сжатие при передаче информации (без видео) на 20-25 полных страниц. *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Boris! Friday December 17 1999, Boris Batkin writes to Bulat Ziganshin: BB> обоих случаях. и если говоpить о 3d акселеpатоpах, то тут возможны BB> ваpианты. Какие к черту акселераторы? Мы говорим об st, которому как воздух нужно неско лько метров очень быстрой памяти, лучше всего - на частоте процессора. 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 19 Dec 99 20:49:00 To : All Subj : BWT - овчинка выделки не стоит *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello All! Sunday December 19 1999, Andrew Aksyonoff writes to Bulat Ziganshin: BZ>> Hадо их выкладывать только в инете, "на солидной коммерческой BZ>> основе". AA> Лучше уж и то, и другое. Кстати, я наконец сообразил, как организовать фак. Весь необходимый объем инф ормации регулярно публиковать в эхе невозможно, это сотни килобайт как минимум. Hужен краткий конструктивный обзор иерархии различных методов, их взаимосвязей , сложности реализации и скорости/качества. Подробный разбор отдельных методов вы нести в ссылки, кои давать в виде URL'ов и тем на факсервере. Тогда фак можно б удет поместить в одно письмо, публиковать так часто, как нужно; и в то же время все желающие получат доступ к телу. 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 19 Dec 99 20:53:58 To : Leonid Broukhis Subj : есколько вопросов * Crossposted in RU.COMPRESS Hello Leonid! Friday December 17 1999, Leonid Broukhis writes to Boris Batkin: >> под p2 vtune нужен, чтобы stall-ы не ловить. LB> Какие конкретно stall-ы? Лео, ну ты б познакомился с предметом спора хоть. Знаешь, например, про 3-1-1 и про 3 регистра на такт? 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 19 Dec 99 20:55:52 To : Leonid Broukhis Subj : есколько вопросов * Crossposted in RU.COMPRESS Hello Leonid! Saturday December 18 1999, Leonid Broukhis writes to Bulat Ziganshin: >> >> >> LB> А был бы у тебя, например, Solaris for Intel, вполне может >> >> >> LB> быть, что ты бы откомпилировал им, и выбросил бы bcc на >> >> >> LB> помойку. >> А фигли толку? posix environment и rtl этого компилятора >> одновременно кто предоставлять будет? LB> Cygwin и предоставит. Если он преобразует собственный ELF, то он будет LB> работать, а если чужой - как повезет. :-) ЧТД. Solaris никаким боком к генерации PE не прикрутишь, а gcc у нас есть, ни кто не спорит. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 20 Dec 99 01:46:24 To : Bulat Ziganshin Subj : Re: есколько вопросов From: leob@mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: >Friday December 17 1999, Leonid Broukhis writes to Boris Batkin: > >> под p2 vtune нужен, чтобы stall-ы не ловить. > LB> Какие конкретно stall-ы? > > Лео, ну ты б познакомился с предметом спора хоть. Знаешь, например, про 3-1- 1 Hачнем с того, что 4-1-1. С которыми компилятор отлично справится. >и про 3 регистра на такт? 3 uops на такт, ты имел в виду? Потому что это не те регистры, которые видит компилятор. Hо этого можно избежать, запретив компилятору порождать read-modify-write инструкции, и тогда каждая макрооперация будет точно "отправляться на пенсию" не более чем за такт. Leo PS. Так и какие же там есть особенные stalls, с которыми компилятор не справится? --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 20 Dec 99 10:20:27 To : Leonid Broukhis Subj : есколько вопросов *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Leonid! Monday December 20 1999, Leonid Broukhis writes to Bulat Ziganshin: >> >> под p2 vtune нужен, чтобы stall-ы не ловить. >> LB> Какие конкретно stall-ы? >> Лео, ну ты б познакомился с предметом спора хоть. Знаешь, например, >> про 3-1-1 LB> Hачнем с того, что 4-1-1. С которыми компилятор отлично справится. Мне казалось, что 3-1-1. Посмотрю на работе. >> и про 3 регистра на такт? LB> 3 uops на такт, ты имел в виду? Hет, именно кол-во регистров, которые можно задействовать. И это только те ог раничения, которые я смог навскидку вспомнить, там есть еще немало забавных мом ентов. LB> PS. Так и какие же там есть особенные stalls, с которыми компилятор LB> не справится? Как раз с любыми ограничениями компиляторы (как и vtune) справляются играючи. H о им не хватает интеллекта в генерации кода. VTune - это как бы часть компилято ра, та работа, которую машина несомненно выполнит лучше. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED 2.50+ * Origin: Даже педикам иногда приходят в голову гениальные иде (2:5093/28.126)
Предыдущий блок Следующий блок Вернуться в индекс