Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать)
Интересно, почему сейчас эта идея никем не используется?
Здравствуйте, Andrei F., Вы писали:
AF>Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать) AF>Интересно, почему сейчас эта идея никем не используется?
Лучше день потерять, а потом за 5 минут долететь?
Имхо накладные расходы по времени/месту вполне очевидны. Теоретически в системах критичных по скорости имхо проще купить дополнительную планку памяти, чем усложнять механизмы её (пере)распределения. В цифрах конкретных выкладок не приведу, но думаю, врядли этот вопрос совсем не рассматривался осеписателями.
Здравствуйте, Курилка, Вы писали:
К>Лучше день потерять, а потом за 5 минут долететь? К>Имхо накладные расходы по времени/месту вполне очевидны. Теоретически в системах критичных по скорости имхо проще купить дополнительную планку памяти, чем усложнять механизмы её (пере)распределения. В цифрах конкретных выкладок не приведу, но думаю, врядли этот вопрос совсем не рассматривался осеписателями.
Накладные расходы на сжатие очевидны, но они точно меньше чем расходы на выгрузку страницы на винчестер. Особенно в условиях, когда приложения и так активно работают с винчестером.
К тому же дополнительные ядра на процессоре все равно обычно простаивают без дела
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, Курилка, Вы писали:
К>>Лучше день потерять, а потом за 5 минут долететь? К>>Имхо накладные расходы по времени/месту вполне очевидны. Теоретически в системах критичных по скорости имхо проще купить дополнительную планку памяти, чем усложнять механизмы её (пере)распределения. В цифрах конкретных выкладок не приведу, но думаю, врядли этот вопрос совсем не рассматривался осеписателями.
AF>Накладные расходы на сжатие очевидны, но они точно меньше чем расходы на выгрузку страницы на винчестер. Особенно в условиях, когда приложения и так активно работают с винчестером.
И расходы на память будут меньше? У меня вот есть ощущение, что X + Y > X (где Y ненулевое).
И ещё может я, конечно, гоню, но вроде в линухе были какие-то финты ушами, которые позволяют своп в памяти держать. Вполне возможно, что туда можно прикрутить ФС, поддерживающую сжатие.
Правда всё равно в большинстве случаев это экономия на спичках, поэтому рассматривать абстрактно общий случай не очень интересно. А в конкретных системах с хитрыми условиями может приминяться и предложенный тобой вариант. Надо только смотреть что дешевле — купить планку или иметь сношения с нестандартной конфигурацией системы
Здравствуйте, Курилка, Вы писали:
К>И расходы на память будут меньше? У меня вот есть ощущение, что X + Y > X (где Y ненулевое).
Если данные сжать, то они точно станут меньше по объему.
К>Правда всё равно в большинстве случаев это экономия на спичках, поэтому рассматривать абстрактно общий случай не очень интересно. А в конкретных системах с хитрыми условиями может приминяться и предложенный тобой вариант.
Чтобы рассматривать конкретные случаи, надо иметь какие-то тесты, которые эмулируют работу в условиях нехватки оперативки. Интересно, такие существуют в природе?
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, Курилка, Вы писали:
К>>И расходы на память будут меньше? У меня вот есть ощущение, что X + Y > X (где Y ненулевое).
AF>Если данные сжать, то они точно станут меньше по объему.
Т.е. в момент распаковки/запаковки у тебя магическим образом мгновенно испарится сжатая/оригинальная версия участка памяти?
В итоге получим, что нам в любом случае надо иметь "страховочный" объём памяти, равный максимальному размеру сжимаемой области памяти. Или делаем "сжатие по месту" надеясь на то, что в ходе паковки/распаковки ничего не произойдёт? Типа "кто не рискует, тот не пьёт"?
AF>Чтобы рассматривать конкретные случаи, надо иметь какие-то тесты, которые эмулируют работу в условиях нехватки оперативки. Интересно, такие существуют в природе?
Здравствуйте, Курилка, Вы писали:
К>Т.е. в момент распаковки/запаковки у тебя магическим образом мгновенно испарится сжатая/оригинальная версия участка памяти? К>В итоге получим, что нам в любом случае надо иметь "страховочный" объём памяти, равный максимальному размеру сжимаемой области памяти. Или делаем "сжатие по месту" надеясь на то, что в ходе паковки/распаковки ничего не произойдёт? Типа "кто не рискует, тот не пьёт"?
Зачем — максимальному? По минимуму достаточно иметь место для сжатия одной страницы памяти, плюс управляющие данные.
Вот кстати исследование на эту тему: http://www.usenix.org/events/usenix99/full_papers/cervera/cervera.pdf. Результаты вполне положительные.
Всё-таки непонятно, почему сейчас эту идею совсем забросили.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, Курилка, Вы писали:
К>>Т.е. в момент распаковки/запаковки у тебя магическим образом мгновенно испарится сжатая/оригинальная версия участка памяти? К>>В итоге получим, что нам в любом случае надо иметь "страховочный" объём памяти, равный максимальному размеру сжимаемой области памяти. Или делаем "сжатие по месту" надеясь на то, что в ходе паковки/распаковки ничего не произойдёт? Типа "кто не рискует, тот не пьёт"?
AF>Зачем — максимальному? По минимуму достаточно иметь место для сжатия одной страницы памяти, плюс управляющие данные.
Ну да, про страницы мысль вертелась, тока недоформулировалась AF>Вот кстати исследование на эту тему: http://www.usenix.org/events/usenix99/full_papers/cervera/cervera.pdf. Результаты вполне положительные. AF>Всё-таки непонятно, почему сейчас эту идею совсем забросили.
Здравствуйте, Andrei F., Вы писали:
AF>Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать) AF>Интересно, почему сейчас эта идея никем не используется?
Пользуются там, где памяти мало. Сжатие страниц кэша диска помогает (так как увеличивается вероятность cache hit), сжимать всю память не имеет смысла.
Здравствуйте, Cyberax, Вы писали:
C>Пользуются там, где памяти мало. Сжатие страниц кэша диска помогает (так как увеличивается вероятность cache hit), сжимать всю память не имеет смысла. C>Вот проект: http://code.google.com/p/compcache/
Там речь идет именно о сжатии своп-файла (+хранение его части в RAM), а не кэша диска. А сжимать всю память никто и не предлагал
Интересно, под windows что-то подобное есть?
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, Cyberax, Вы писали:
C>>Пользуются там, где памяти мало. Сжатие страниц кэша диска помогает (так как увеличивается вероятность cache hit), сжимать всю память не имеет смысла. C>>Вот проект: http://code.google.com/p/compcache/
AF>Там речь идет именно о сжатии своп-файла (+хранение его части в RAM), а не кэша диска. А сжимать всю память никто и не предлагал AF>Интересно, под windows что-то подобное есть?
Здравствуйте, IIY, Вы писали:
IIY>Поместить своп в RAMDrive (второе сообщение)?
Тогда своп-файл надо сделать сжатым, а здесь будут проблемы. После перезагрузки содержимое диска пропадет (значит, пропадут и все свойства файла). Да и вообще я не уверен, что своп-файл можно сделать сжатым и после этого ничего не упадет
Здравствуйте, Andrei F., Вы писали:
AF>Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать) AF>Интересно, почему сейчас эта идея никем не используется?
Вероятно, память подешевела, и никто уже не хочет заниматься изготовлением такой приблуды для XP.
Здравствуйте, Andrei F., Вы писали:
C>>Пользуются там, где памяти мало. Сжатие страниц кэша диска помогает (так как увеличивается вероятность cache hit), сжимать всю память не имеет смысла. C>>Вот проект: http://code.google.com/p/compcache/ AF>Там речь идет именно о сжатии своп-файла (+хранение его части в RAM), а не кэша диска. А сжимать всю память никто и не предлагал
Да, точно. Видимо, сжатие памяти так и не допилили.
Здравствуйте, IIY, Вы писали:
IIY>Здравствуйте, Andrei F., Вы писали:
AF>>Здравствуйте, Cyberax, Вы писали:
C>>>Пользуются там, где памяти мало. Сжатие страниц кэша диска помогает (так как увеличивается вероятность cache hit), сжимать всю память не имеет смысла. C>>>Вот проект: http://code.google.com/p/compcache/
AF>>Там речь идет именно о сжатии своп-файла (+хранение его части в RAM), а не кэша диска. А сжимать всю память никто и не предлагал AF>>Интересно, под windows что-то подобное есть?
IIY>Поместить своп в RAMDrive (второе сообщение)?
Помещение SWAP на RAM-диск — этот нонсенс. За это надо убивать сразу.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, IIY, Вы писали:
IIY>>Поместить своп в RAMDrive (второе сообщение)?
AF>Тогда своп-файл надо сделать сжатым, а здесь будут проблемы. После перезагрузки содержимое диска пропадет (значит, пропадут и все свойства файла). Да и вообще я не уверен, что своп-файл можно сделать сжатым и после этого ничего не упадет
Я тоже не уверен, но, как вариант для тех, у кого память некуда девать (:
Здравствуйте, Andrei F., Вы писали:
AF>Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать) AF>Интересно, почему сейчас эта идея никем не используется?
блин, память и так медленная: ее частота, как правило, в пять-десять раз ниже частоты процессора.
а вы тут предлагаете еще замедлить доступ к ней раза в два!
в курсе, вообще, что основная проблема при работе программ — это не нехватка памяти, а скорость доступа к ней?
вон, товарищи правильно говорят — она ж дешевая сейчас, как комбикорм!
планка на гигабайт — пятьсот рублей.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, waveable, Вы писали:
W>>а вы тут предлагаете еще замедлить доступ к ней раза в два!
AF>бред. кто предлагает ее замедлить?
не станете же вы утверждать, что компрессия-декомпрессия данных, которые будут храниться сжатыми в памяти — бесплатная операция. на нее, так или иначе, потребуются ресурсы процессора.
через это, как мне думается, и возникнет неминуемая дополнительная задержка при обращении.
тут ведь какая штука: когда мы храним сжатыми данные на винте — там время компресии-декомпресии сильно меньше, чем время доступа к этим данным. поэтому эта операция выглядит более-менее прозрачно для пользователя. в случае же оперативной памяти — все наоборот.
W>>извините.
AF>не извиню
Здравствуйте, waveable, Вы писали:
W>не станете же вы утверждать, что компрессия-декомпрессия данных, которые будут храниться сжатыми в памяти — бесплатная операция. на нее, так или иначе, потребуются ресурсы процессора. W>через это, как мне думается, и возникнет неминуемая дополнительная задержка при обращении.
я ведь вроде вполне ясно написал — сжимать данные вместо записи в своп-файл
Здравствуйте, Andrei F., Вы писали:
AF>Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать) AF>Интересно, почему сейчас эта идея никем не используется?
9x не поддерживали флаг PAGE_WRITECOPY, поэтому каждый процесс имеет свою копию памяти под dll, а в NT системах получается некоторая бесплатная экономия и без компрессии. 2е, что можно выгружать на диск — данные — по своей природе требуют постоянного нахождение в ОЗУ, если его не хватает, то тут хоть сжимай, хоть не сжимай — его не хватает, и потрерь в скорости как и свопа на диск не избежать. Думаю, если бы был смысл — встроили бы в ОС, как ReadyBoost.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Andrei F., Вы писали:
AF>Накладные расходы на сжатие очевидны, но они точно меньше чем расходы на выгрузку страницы на винчестер.
Не факт. Запись на диск выполняется асинхронно и может ничего не стоить для пользовательского кода.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Не факт. Запись на диск выполняется асинхронно и может ничего не стоить для пользовательского кода.
Запись на диск не может ничего не стоить. Даже если нагрузка на процессор действительно абсолютно нулевая (во что я не верю), будут косвенные затраты — замедление работы с диском для других приложений.
Здравствуйте, Andrei F., Вы писали:
AF>Во времена win95 были распространены программы, которые позволяли уменьшать свопинг с помощью сжатия отдельных фрагментов памяти (т.е. вместо того чтобы сбрасывать страницу в своп-файл — оставить ее в оперативной памяти, но сжать) AF>Интересно, почему сейчас эта идея никем не используется?
Сейчас проще докупить памяти и отключить своп вообще.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, gear nuke, Вы писали:
GN>>Не факт. Запись на диск выполняется асинхронно и может ничего не стоить для пользовательского кода.
AF>Запись на диск не может ничего не стоить. Даже если нагрузка на процессор действительно абсолютно нулевая (во что я не верю), будут косвенные затраты — замедление работы с диском для других приложений.
Особенно, если другие приложения работают с другим физическим диском
В частности, вот краткое сравнение прогресса скоростей HDD и CPU (с выводом, что идея имеет право на жизнь):
I'm honestly surprised that RAM compression hasn't made a comeback. Lots of people use computers that don't have enough RAM for whatever reason. When RAM compression was popular the last time around, typical clock speeds were 50mhz, and the average access time on a hard drive was around 18ms. Now, typical clock speeds are 3Ghz, and access times are about 9ms. In fact, since processors do so much more work per clock these days, your processor probably does about 150-500x as much work per second as it did back then, and yet hard drives are only about 2x faster in access time, which is generally the limiting factor for paging. To some extent, DMA hard drives help, because one program can be running while the other one is paging in. However, we still have the situation where the processor can execute over 20 million instructions in the time it takes to load in a single 4k page. You should be able to compress and decompress data in less than 5% of the time it takes to pull it from disk. Thus, if you're really swapping much at all, it would seem to make sense to have a portion of your RAM kept in compressed form.
А вот ещё интересный момент:
We only must convince the Operating System of the fact, that permanent PageFiles must have the "compressed" Attribute set — that's all.
Здравствуйте, Andrei F., Вы писали:
AF>Запись на диск не может ничего не стоить. Даже если нагрузка на процессор действительно абсолютно нулевая (во что я не верю),
Я конечно утрировал, если сказал, что она 0 Нужно сформировать и отправить IRP по стеку драйверов. Но эта операция явно дешевле сжатия.
Суть в том, что если приложению нужно 256Мб памяти для работы, то оно просто физически не сможет нормально работать на меньшем объеме памяти, и хочешь-не хочешь, а память купишь. Или разработчик, узрев, что на типичной конфигурации проблемы, будет использовать другие механизмы, тот же MMF... Как раз когда нужна скорость — память не ресурс, от того и 32х битный цвет например.
AF> будут косвенные затраты — замедление работы с диском для других приложений.
Дык измерить как-то надо наверное, что бы такое утверждать? MS однозначно делает профилирование системы, и думаю устраняют в первую очередь узкие места.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, gear nuke, Вы писали:
GN>>Дык измерить как-то надо наверное, что бы такое утверждать?
AF>http://www.usenix.org/events/usenix99/full_papers/cervera/cervera.pdf
GN>> MS однозначно делает профилирование системы, и думаю устраняют в первую очередь узкие места.
AF>Я бы не стал так уж сильно полагаться на мудрый майкрософт.
Дак кто заставляет, берём и как Танненбаум пишем свою ось...
У меня вот есть ощущение, что X + Y > X (где Y ненулевое).
