zip RAM

 
+
-
edit
 

valture

опытный

можно-ли заставить RAM использовать только сжатые данные,тогда его емкость увеличится в 1,5-2 раза?
 
RU Павел Кузьмин #17.04.2004 12:48
+
-
edit
 

Павел Кузьмин

координатор


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

Никогда подобной утилиты не встречал — сомневаюсь, что она есть в природе :) .
[font color="green"]Good Old Fashioned Lover Boy[/font]
 
+
-
edit
 

varban

администратор
★★★
http://www.yandex.ru/yandsearch?rpt=rad&text=magnaRAM

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

Заметь, о полезности я ничего не сказал, хотя есть случаи, где применение такого компрессора оправдано.
 
Это сообщение редактировалось 17.04.2004 в 13:42
RU Сын советского программиста #17.04.2004 21:04
+
-
edit
 
Дело не в памяти а в алгоритмах обработки данных.
Сын советского программиста  
RU Сын советского программиста #17.04.2004 21:06
+
-
edit
 
varban, 17.04.2004 12:34:52 :
В старых Mac OS штатно было такое средство.
 


Какое? Что именно оно делало?
Сын советского программиста  
RU Сын советского программиста #17.04.2004 21:37
+
-
edit
 
MagnaRAM пытается уменьшеть кол-во операций со своп файлом, для увеличения быстродействия системы. Она забивает для себя в памяти некий буфер и пытается, по возможности, не скидывать неиспользуемые страницы памяти в своп, а упавковывать их и помещать в упомянутый выше буфер. Очевидно, что полезный объем памяти не увеличится, а наоборот уменьшится :P А увеличение полезного объема ОЗУ таким способом - это сказки для чайников :)
Сын советского программиста  
RU Сын советского программиста #17.04.2004 21:39
+
-
edit
 
Вопрос на засыпку :)
Почему при работе с графикой MagnaRAM приводила к замедлению скорости системы?
Сын советского программиста  
+
-
edit
 

Balancer

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

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


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

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

varban

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

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

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

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

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

varban

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

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

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

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

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

Quaterdeck, сэр!

:D :lol: :F
 

Zeus

Динамик

А у меня под Вин95 она стояла какое-то время даже :) И вообще всяческие менеджеры памяти были популярны.
И животноводство!  
?? [Сергей] #18.04.2004 09:41
+
-
edit
 
Но тогда ко времени собственно реакции памяти на запросы (а и быстродействия памяти бывает недостаточно для сложных приложений) добавится время на запаковку/распаковку данных. Это неприемлемо. Да и смог бы архиватор работать с такой скоростью?
 


Это, надо думать, сильно зависит от реализации. Скажем, коли программа аккуратно делает локи памяти - то можно рассчитывать на существенный выигрыш. Хотя сейчас все очень любят залочить нафиг офигенный буфер(ы) и не разлочивать до конца работы программы. Тем более, что для Win32 особой разницы между GlobalAlloc и LocalAlloc нам, крестьянам, не различить. Хотя последнее обстоятельство ишшо неизвестно к добру или худу в zip-memory аспекте. А насчет времени на запаковку - опять же, сильно зависит. Если взять, скажем, запаковку методом битовых последовательностей - так скорость паковки/распаковки не будет слишком уж отличаться от простого копирования памяти. Правда и сжатие не будет офигительным.
 
RU Сын советского программиста #18.04.2004 12:27
+
-
edit
 
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

старожил
★☆
Зависит от задачи. Но в целом не факт что выигрыш будет. Единственно - если сделать такую фичу в процессоре. То есть чтобы все обмены через шину с физической памятью происходили сжатыми блоками. Этак килобайт по 64 ;-). Тогда да - может быть и в обьеме выигрыш, и в скорости. Но если процессор будет работать работать и на сжатие, и на запись, и так далее, при этом каждый раз обмениваясь с памятью - то выигрыша не будет. Разве что если памяти катастрофически не хватает и ее заменяет своп. Но тут уж... памяти можно и побольше поставить.
Убей в себе зомби!  
Это сообщение редактировалось 18.04.2004 в 17:38
+
-
edit
 

varban

администратор
★★★
Дык все течет, все меняется :)

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

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

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

hcube

старожил
★☆
А она сейчас без пользы. Попробуй-ка сожми MPEG-видео или аудио ;-) А помянутое составляет львиную долю хранимой информации. И кстати - в NTFS есть опция сжатия диска. Ежели нужно ;-)
Убей в себе зомби!  
RU Сын советского программиста #19.04.2004 07:46
+
-
edit
 
hcube, 18.04.2004 15:50:09 :
Единственно - если сделать такую фичу в процессоре. То есть чтобы все обмены через шину с физической памятью происходили сжатыми блоками. Этак килобайт по 64 ;-). Тогда да - может быть и в обьеме выигрыш, и в скорости.
 


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

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

hcube

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

Зато с архивами такой процессор будет работать с нечеловеческой скоростью, если этот блок архивирования сделать снаружи доступным ;-)
Убей в себе зомби!  
?? Stranger_NN #23.04.2004 14:14
+
-
edit
 

Stranger_NN

втянувшийся

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

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

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru