Да доводи-не доводи, но одновременное использование с виртуальной памятью на основе страниц себя не оправдывает... Проверенно электроникой! Вот если без виртуалки или с виртуалкой на основе сегментов, тогда да - есть смысл...

аргументы,плз

Если-бы организовать компресию/декомпресию аппаратно на мат.плате- никакая 266/RDRAM не нужна

Ирся, опять гадаешь, да? Ты конечно написал сам алгоритм комрессии именно для ядра линуха 2.4, соптимизировал, получил результаты, и не удовлетворившись, выкинул их, да? Если нет - заткнись, имбецил.
Скорость линейного чтения с ide винтов не более 40 мегов/сек (то есть при беспорядочном - раз в пять-десять меньше), а скорость декомрессии на современных продвинутых камнях, тем более с быстрой системной шиной - метров 80 в секунду будет imho (попробуй что-нить сжать большое, и замерить скорость расжатия).

я согласен с Irsi в плане того, что компрессия 4х килобайтных страниц даст большой оверхеад практически без эффекта. Расммотрим один гипотетический пример - у нас есть 4 страницы которые мы сжимаем и ложим рядышком в "compressed cache" (ну или compressed swap, кому как нравится), теперь нам вдруг понадобилась 3я страница - которую при этом еще и модифицируют. После модификации нова версия, если ее скомпрессировать на свое старое место уже не влазит и ее ложат в другое место. в нашем пуле сжатых страниц образуется дырка в которую (по несчастливому стечению обстоятельств) ничего всунуть пока что не представляется возможным. Зато из оверхеда мы имеем - поддерживание какого-то оглавления для сжатого пула страниц как минимум. Для борьбы с описанным мной фрагментированием еще можно применить дефрагментацию - еще оверхед. Для тех кто собирается убедить меня в том, что страница раз попав в этот пул больше не меняется и эффект не возникает - бинари мапятся с диска и в своп не идут (да и не надо это). В итоге никогда неизменяемых страниц остается не так много. Да и сжатие на данных кусками по 4к не очень оптимально. (ну я понимаю что не везде 4к страницы, но все же)

Гораздо интереснее была бы воплотить механизм восстановления страниц по известному алгоритму. (ни для кого не секрет, что когда мы запускаем динамический бинарь, динамический линкер генерит разного рода ссылочные таблицы которые во время жизни процесса не меняются, есть и другие подобные процессы). Имея одним из таких алгоритмов так же и компрессию страницы, наверное можно было бы добиться чего-то. Тем не менее с нынешними ценами на память - я не вижу в этом особого смысла. Разве-что для каких-то embedded платформ где иногда можно пожертвовать cpu и полуить больше памяти, но и то далеко не всегда.

небудет линейного чтения, будет жуткая фрагментация.

2 Green: Если все задумано для скорости, а не для экономии дискового пространства, можно не скупиться и полагать для каждой страницы по 4К, тогда проблем с дырками и сборкой мусора не возникает...

правда и выигрыша в скорости тогда не будет, потому как все равно винт будет читать последовательный кусок. Правда передавать будет не все, что прочитал, но это маловажно. К тому же все равно блочный layer позволяет читать кусками по blocksize, то есть даже если 4к сжались в 3 байта (супер оптимизация для страниц заполненных одинаковым однобайтовым значением), то прочитать все равно прийдется как минимум 512 байт

Всеравно остается проблема не очень эффективной компресии страниц меленького размера

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

Увы, я бы на месте доктора сказал - в морг.

А вот хранить данные В ПАМЯТИ в подпакованном виде - это возможно и вариант. И обращений к свопу может потребываться поменее. Особенно всвязи с развитием типографского искусства за границей :) То есть, ежели CPU быстрый, то почему бы и не?

ЗЫ: 2anonymous (2001-09-19 10:46:11.0) - Ирся, конечно, достает, но переходить на личности - это как-то неприлично, что ли. Оффтопик.

2 Green: ... а если страница упаковалась в полуинтервале ((n-1)*512,n*512], то для ее чтения прочтется n из 8 блоков (n = 1,...,8), т.ч. экономия все-таки есть, кроме того можно развить мысль, сделав 8 разных банков (от 512 до 4К) и тогда - экономить и место тоже.

Маленькое дополнение относительно апаратной реализации.
Такая штука давно существует и даже цена известна 100-150$
вот и ссылка
http://www.research.ibm.com/journal/rd/452/smith.html

нету экономии. Винт все равно читает чуть ли не треками (или что там счас у свременных винтов вместо этого?).

Несколько банков => фрагментация => огромные потери на дерганье головками

Если хранить компрессированные данные в памяти - ничего не изменится! Все та же фрагментация...

На сколько я понимаю скорость работы компа на прямую зависит от скорости работы памяти, поэтому получаем что наиболее выгодно, чтоб вся память имела скорость работы как у регистров процессора. Но цена такой памяти будет ну очень большой. Сейчас для уменьшения стоимости применяется несколько типов памяти (регистры процессора)-(кеш)-(RAM)-(диск). Такая организация памяти позволяет существенно уменьшить стоимость при приличной скорости работы компа. Применение сжатия памяти в этом случае не просто безполезно, а является преступлением, т.к. в этом случае получаеи (RAM)=(диск). Если раньше комп тормозил только тогда когда читал данные с диска, то теперь он перманентно будет тормозить.

Кстати насчет быстрого CPU - памать сейчас дешевле будет чем дополнительные мегагерцы.

Эту проблему можно обойти выделив часть памяти под пул сжатых страниц, таким образом доступ к ним все-же быстрее чем к HDD (при быстром проце), Да и выкидывать данные в своп можно иименно из этого пула, экономя bandwidth, если решить все перечисленные выше проблемы. Впрочем возможно эти проблемы и были уже однажды решены (вспоминаются RAM Doubler'ы разного рода под винду). Но сырцов и алгоритмов я пока не видел толковых.

Есть уже давно процессоры PowerPC 405 имеющие контроллер памяти с функцией сжатия:

http://www.chips.ibm.com/micronews/vol5_no1/codepack.html http://www-3.ibm.com/chips/techlib/techlib.nsf/products/CodePack

Alexander Trush

2Alximik
этом случае получается (RAM)=(диск).
Ну енто ты загнул.
Вот интересная картинка
http://www.surriel.com/lectures/hierarchy.gif

Ничего я не загнул. Конечно при чтении из памяти с сжатием скорость будет больше чем с диска, но не намного.

У меня на PIII-600 скорость чтения из памяти 112Mb/s. Если применять сжатие то она упадет не меньше чем в 10 раз и того имеем 11Mb/s. А скорость копирования громандного файла с партиции находяцийся в начале диска на партицию в конце диска составляет 2Mb/s, hdparm даёт 18Mb/s и можно ожидать среднюю скорость на уровне 5-10 Mb/s. Вот мы и получили максимальнй вигрыш в скорости 1.5-2 раза. И ещё пока одна програма ждет данных с диска, другая программа спокойно работает и ~1000000 реально надо заменить на ~50000.

Ничего я не загнул. Конечно при чтении из памяти с сжатием скорость будет больше чем с диска, но не намного.

У меня на PIII-600 скорость чтения из памяти 112Mb/s. Если применять сжатие то она упадет не меньше чем в 10 раз и того имеем 11Mb/s. А скорость копирования громандного файла с партиции находяцийся в начале диска на партицию в конце диска составляет 2Mb/s, hdparm даёт 18Mb/s и можно ожидать среднюю скорость на уровне 5-10 Mb/s. Вот мы и получили максимальнй вигрыш в скорости 1.5-2 раза. И ещё пока одна програма ждет данных с диска, другая программа спокойно работает и ~1000000 реально надо заменить на ~50000.

При работе с памятью нет потерь времени на перемещения головок. Ожидать скорость на уровне 10 Mbps от диска на нагруженной системе (если она на него еще и свопится) - нелогично. Даже 5 Mb/s вряд ли. Насчет занятого CPU - с этим как раз никто не спорит. Правда бывает так, что RUNNABLe задача всего одна, но в свопе, потому CPU никто не пользует. Кстати, интересно каким образом проводилась оценка скорости чтения из памяти, а так же оценка порядка уменьшения этой скорости при компресии.

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

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

2Alximik
>>У меня на PIII-600 скорость чтения из памяти 112Mb/s
я не знаю как у тебя но у PII-450 276mb/s,
я уже не говорю более быструю память!

2 green

Помнится я использовал ext2compression и при разборе глюков возникших всвязи с этим выяснил алгоритм его работы. Этот же алгоритм может быть использован в данном случае.

Сжатие происходит при накопление пула из 32 страниц памяти. После сжатия мы получим n = 1 - 32 страницы сжатых данных которые могут быть вместе сброшены на диск. Соответственно востановление происходит одновременно этих n страниц. Есть некоторые накладные расходы на процессорное время распаковки/ запаковки (полезной/лишней). Фрагметация свопа не увеличивается.

112Mb показал memtest86 (http://www.teresaudio.com/memtest86/), оценка производительности чтения/записи в сжатую память поризводилась по работе программ сжатия (gzip, графические форматы pcx, gif), полученные данные были увеличены в несколько раз.

При использовании QEMM97 в Windows сжатие реально помогало. Т.е.
компьютер не начинал 'летать', но диск практически переставал
работать. А до этого трудился как бешенный! И суб'ективно компьютер
начинал работать быстрее. Но в любом случае - покой диска тоже что-то
значит!

Насколько я помню вся работа там проходила на уровне кэша. Т.е.
паковались страницы кэша, а своп работал как обычно. И в том же кэше
выделялась область для буфера упаковки.

sergey

2Alximik берем твои 112MB/s я в зглянул в исходники memtest86 вот чего там написанно /* Find Memory speed, we average the times using using block sizes */ /* of 32k, 64k, 128k and 256k */ memspeed(0, .... 0 означает выключение кеша, енто первое. А на второе, если ты думаешь что для сжатия памяти будут пременяться алгоритмы яля ( gzip, ...., bzip2) если так то я стобой соглашусь енто полный абзац:) Но про них и не кто и не думает, есть алгоритмы которые сжимают не так сильно , но очень быстро.

2sergey: Извини, но на каком объеме ОЗУ сжатие с помощью MagnaRAM (QEMM'97) реально помогало в 95х? По моим тестам она была весьма эффективна на 8Мб, на 16Мб эфффект был уже не так заметен, а на 32Мб он становился соизмерим с погрешностью измерения...
Ребята, я еще лет пять назад очень интересовался подобными вещями... К слову - все в курсе откуда пришла эта идея? Правильно - первая популярная реализация была сделана на маках, для тех версий макоси, которая еще не поддерживала виртуальную память... Там она была очень эффективна... Потом была реализация для зх виндов, у которох как известно была не страничная организация виртуальной памяти, а сегментная... Тоже была достаточно эфеективна... А вот на всех ОС со страничной организацией виртуальной памяти - эффективна только при очень маленьких объемах ОЗУ, практически на минимальных, требуемых для загрузки этой ОС...
Но если подумать и вспомнить маки... то возможно такая штука и может быть полезной... Но использовать ее совместно с виртуальной памятью на основе страничной организации - неверно, для ее эффективного использования необходимо вообще отключать виртуальную память... Идея не такая глупая как кажется к слову - кто делает свап больше 128Мб? Правильно - мало кто... А между прочим 256Мб ОЗУ+ сжатие дает эээ больший, или как минимум не меньший объем ОЗУ для программ, чем 256Мб ОЗУ +128Мб свопа... А работать сжатие я думаю будет быстрей... Правда для этого придется полностью переделать диспетчер памяти...

To Irsi:
Я точно не помню - по моему - 16 или 32 Мб. И я тесты не делал,
по крайней мере с секундомером. Но очень неплохо работало, когда я
загружал на редактирование какой-нибудь звуковой файл где-то на 40Мб.
Диск при этом во время обработки фактиюески молчал, а вообще-то - да,
разницы в скорости я особенно не заметил, но своп зато оставался в
разумных пределах - раньше он рос при таких задачах где-то до 100 -
140 Мб и о-о-очень медленно возвращался обратно. А так как рабочее
пространство было на этом же диске, то мне иногда просто не хватало
памяти. А с QEMM своп редко превышал 30 Мб. :-)

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

anonymous (*) (2001-09-24 18:04:13.0): хммм... Воообщем возможно выйгрышь и будет... Впрочем под w2k можно проверить - там можно заставлять сжимать файлы на лету... поставить битик compressed на файло pagefile.sys и посмотреть что выйдет... Я если честно не пробовал... Но имхо выйгрышь будет весьма небольшим...