zip RAM [Форумы Balancer.Ru]

valture #17.04.2004 12:24

valture

опытный

можно-ли заставить RAM использовать только сжатые данные,тогда его емкость увеличится в 1,5-2 раза?

Павел Кузьмин #17.04.2004 12:48

Но тогда ко времени собственно реакции памяти на запросы (а и быстродействия памяти бывает недостаточно для сложных приложений) добавится время на запаковку/распаковку данных. Это неприемлемо. Да и смог бы архиватор работать с такой скоростью?

Никогда подобной утилиты не встречал — сомневаюсь, что она есть в природе

.

varban #17.04.2004 13:34

varban

администратор

★★★☆

http://www.yandex.ru/yandsearch?rpt=rad&text=magnaRAM

В старых Mac OS штатно было такое средство.

Заметь, о полезности я ничего не сказал, хотя есть случаи, где применение такого компрессора оправдано.

Это сообщение редактировалось 17.04.2004 в 13:42

Сын советского программиста #17.04.2004 21:04

Сын советского программиста

втянувшийся

Дело не в памяти а в алгоритмах обработки данных.

Сын советского программиста #17.04.2004 21:06

Сын советского программиста

втянувшийся

varban, 17.04.2004 12:34:52 :
В старых Mac OS штатно было такое средство.

Какое? Что именно оно делало?

Сын советского программиста #17.04.2004 21:37

Сын советского программиста

втянувшийся

MagnaRAM пытается уменьшеть кол-во операций со своп файлом, для увеличения быстродействия системы. Она забивает для себя в памяти некий буфер и пытается, по возможности, не скидывать неиспользуемые страницы памяти в своп, а упавковывать их и помещать в упомянутый выше буфер. Очевидно, что полезный объем памяти не увеличится, а наоборот уменьшится

А увеличение полезного объема ОЗУ таким способом - это сказки для чайников

Сын советского программиста #17.04.2004 21:39

Сын советского программиста

втянувшийся

Вопрос на засыпку

Почему при работе с графикой MagnaRAM приводила к замедлению скорости системы?

Balancer #17.04.2004 22:21

Balancer

администратор

★★★★★

Сын советского программиста, 17.04.2004 21:37:40 :
Она забивает для себя в памяти некий буфер и пытается, по возможности, не скидывать неиспользуемые страницы памяти в своп, а упавковывать их и помещать в упомянутый выше буфер.

Так и представлю - создать рамдиск, сделать его с NTFS-компрессией и положить туда своп...

Бизнесс по-русски (из известного анекдота)

varban #17.04.2004 23:57

varban

администратор

★★★☆

Что делает более-менее современная magnaRAM, я не знаю, ибо не юзаю.
Не юзаю, потому как испытываю стойкое предубеждение к данному продукту.

А знаю первую еще magnaRAM, для DOS/Windows 3.1*, в эпохе Stacker'a.

В ее документации было написано, что софтина жмет содержимое RAM подобно достославному Стацкер'у, используя алгоритм компрессии lha.
Были замечены два полезных эффекта:
1. Windows 3.1 стал лучше работать с памятью, больше, чем 16 MB.
2. Можно было запустить программу, которая тербует больше RAM, чем была доступна в XMS.

Объем памяти в рапортах становился в два раза больше как в DOS, так и в Windows.

Впрочем, софтина известная и в сети должны быть описания.

varban #18.04.2004 00:06

varban

администратор

★★★☆

Рома> Так и представлю - создать рамдиск, сделать его с NTFS-компрессией и положить туда своп...

Примерно так и есть:

MagnaRAM разработана для повышения общей производительности вашего компьютера при работе с Windows. Для того чтобы получить высокие показатели производительности, система использует характерные для дисковых накопителей и памяти различия в скорости, предотвращая попадание в файл подкачки. MagnaRAM резервирует блок памяти для использования в качестве буфера сжатия, который конфигурируется подобно псевдодиску со специальной файловой системой. В MagnaRAM любая попавшая в файл подкачка, которая обычно идет на диск, вместо этого оказывается в буфере.

На втором этапе данные в буфере сжимаются. Когда буфер заполнен, его содержимое копируется в сжатом формате на диск. Представьте себе создание псевдодиска, превращение его в файл подкачки и запуск системы Stacker компании Stac Electronics. Вот что, по сути, делает MagnaRAM.

// "МЯГКАЯ" ПАМЯТЬ. ПО для увеличения объема ОЗУ - № 21, 1996 | Международный компьютерный еженедельник | Computerworld Россия | Издательство «Открытые системы»

Рома> Бизнесс по-русски (из известного анекдота)

Quaterdeck, сэр!

Zeus #18.04.2004 08:24

Zeus

Динамик

☆

А у меня под Вин95 она стояла какое-то время даже

И вообще всяческие менеджеры памяти были популярны.

[Сергей] #18.04.2004 09:41

Но тогда ко времени собственно реакции памяти на запросы (а и быстродействия памяти бывает недостаточно для сложных приложений) добавится время на запаковку/распаковку данных. Это неприемлемо. Да и смог бы архиватор работать с такой скоростью?

Это, надо думать, сильно зависит от реализации. Скажем, коли программа аккуратно делает локи памяти - то можно рассчитывать на существенный выигрыш. Хотя сейчас все очень любят залочить нафиг офигенный буфер(ы) и не разлочивать до конца работы программы. Тем более, что для Win32 особой разницы между GlobalAlloc и LocalAlloc нам, крестьянам, не различить. Хотя последнее обстоятельство ишшо неизвестно к добру или худу в zip-memory аспекте. А насчет времени на запаковку - опять же, сильно зависит. Если взять, скажем, запаковку методом битовых последовательностей - так скорость паковки/распаковки не будет слишком уж отличаться от простого копирования памяти. Правда и сжатие не будет офигительным.

Сын советского программиста #18.04.2004 12:27

Сын советского программиста

втянувшийся

varban, 17.04.2004 22:57:03 :
Что делает более-менее современная magnaRAM, я не знаю, ибо не юзаю.
Не юзаю, потому как испытываю стойкое предубеждение к данному продукту.

Я тоже не юзал и более того узнал о нем впервые от вас. А как он работает узнал отсюда http://www.yandex.ru/yandsearch?rpt=rad&text=magnaRAM

varban>2. Можно было запустить программу, которая тербует больше RAM, чем была доступна в XMS.

Это все пережитки прошлого, когда адресация была сегментная. Дуступ к XMS производился через окно в о бычной памяти. Память туда сюда копировалась, видно кто-то и подумал: "А почему бы не сжать данные перед отправкой в XMS...". А теперь представим падение быстродействия и геморой при программировании дже без сжатия. (Крон, как слоника вставить?

)

ЗЫ
Поправте меня если в чем не прав... давно енто было

Это сообщение редактировалось 18.04.2004 в 15:54

hcube #18.04.2004 16:50

hcube

старожил

★★

Зависит от задачи. Но в целом не факт что выигрыш будет. Единственно - если сделать такую фичу в процессоре. То есть чтобы все обмены через шину с физической памятью происходили сжатыми блоками. Этак килобайт по 64 ;-)

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

Это сообщение редактировалось 18.04.2004 в 17:38

varban #18.04.2004 17:22

varban

администратор

★★★☆

Дык все течет, все меняется

Я помню времена, когда готовые конфигурации продавали с предустановленным Stacker'ом и в спецификации писали объем винта ровно в два раза больше, чем физический. А внизу, самым мелким шрифтом писали, что объем по Стацкеру с коэффициентом сжатия 2

В свое время и я использовал и стацкер, и всякие манагеры памяти.
От DOS у меня были io.sys и msdos.sys, все остальное нортоновское, кватердековское и т.п. И в 3.1 у меня был нортон десктоп

А теперь - все-все стандартное, компрессия винтов забыта, как страшный сон

hcube #18.04.2004 17:37

hcube

старожил

★★

А она сейчас без пользы. Попробуй-ка сожми MPEG-видео или аудио ;-)

А помянутое составляет львиную долю хранимой информации. И кстати - в NTFS есть опция сжатия диска. Ежели нужно ;-)

Сын советского программиста #19.04.2004 07:46

Сын советского программиста

втянувшийся

hcube, 18.04.2004 15:50:09 :
Единственно - если сделать такую фичу в процессоре. То есть чтобы все обмены через шину с физической памятью происходили сжатыми блоками. Этак килобайт по 64 . Тогда да - может быть и в обьеме выигрыш, и в скорости.

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

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

hcube #19.04.2004 10:31

hcube

старожил

★★

Там слишком много менять придется в системе. Начать с того, что туда же в процессор надо будет засунуть менеджер памяти. Далее, при каждой модификации данных в блоке придется его перепаковывать (хотя тут можно сделать резерв по обьему и вобще память выделять дискретно - блоками этак по килобайту). В каждый блок понадобится класть словарь. Придется ввести что-то типа NTFS, да еще таблицу размещения блоков держать целиком в процессоре, чтоб не тормозило. Не, не буду патентовать ;-)

Зато с архивами такой процессор будет работать с нечеловеческой скоростью, если этот блок архивирования сделать снаружи доступным ;-)

Stranger_NN #23.04.2004 14:14

Stranger_NN

втянувшийся

У IBM проскакивала идея внедрить аппаратное сжатие в контроллер памяти. Обещали помимо экономии памяти еще и ускорение мало не вдвое. Но - двухканальные памятЯ, и резкое удешевление RAM вкупе с 64-разрядными процессорами сожрали идею на корню.

А работают современные процессоры строками кэша, вот их и предполагалось, как я понял, и обрабатывать.

zip RAM

опытный

координатор

администратор

втянувшийся

втянувшийся

втянувшийся

втянувшийся

администратор

администратор

администратор

Динамик

втянувшийся

старожил

администратор

старожил

втянувшийся

старожил

втянувшийся