Evgeny_CD, Архитектор (18.11.2021 22:44 - 19.11.2021 12:29, просмотров: 5541)-
- Лет более 20 ти назад поспорили об эффективности архиваторов,
сгенерил бинарный массив псевдослучайных отсчетов, не сжимается ни
чем. - Visitor(19.11.2021 20:25)
- естественно же :) все алгоритмы архивации используют статистические
методы. Чем более случайны данные тем меньше коэффициент сжатия.
Если обращали внимание, Adept(548 знак., 20.11.2021 01:34)
- Ну мы то про энтропию спорили, пришлось доказать. - Visitor(20.11.2021 10:02)
- Неважно, какой алгоритм. Случайные биты принципиально не сжимаются, как завещал великий Шэннон. - SciFi(20.11.2021 09:06)
- чот я про зашумленные фото не понял - Mahagam(20.11.2021 01:38)
- попробуйте добавить к любой картинке шум и она станет практически
несжимаема (картинки с фотоаппаратов, а не рисованные конечно, и
так-то не сжимаются почти, без потери данных) - Adept(20.11.2021 01:57)
- жипег в первую очередь уберёт высокие частоты, то есть размажет
шум. а деталей с увеличением сжатия в любом случае убавится. - Mahagam(20.11.2021 02:01)
- жипег это сжатие с потерями. он годится только для картинок, в
случае, когда информация избыточна многократно (кто в здравом уме
будет разглядывать чуть заметные морщинки на лице или считать
реснички :)) в "жипегах" убивается большая часть информации.
Попробуйте поставить 100% качество и обнаружите, что от
эффективности сжатия не осталось и следа :) - Adept(20.11.2021 02:11)
- не избыточная информация, а "особенности восприятия человеком".
банальная цветовая субдискретизация запросто может уменьшить
количество данных в файле картинки в два раза, а человек с трудом
увидит разницу. а зашумив картинку ты туды добавил информации, чего
после этого удивляться, что размер "архива" стал больше? - Mahagam(20.11.2021 02:37)
- дык я о том и говорю, что жипег базируется на психофизиологических
особенностях зрения, поэтому для картинок вполне эффективен, но
подобные алгоритмы совершенно не годятся для сжатия без потерь. а
как бы топик о применении технологий компрессии ОЗУ, то бишь именно
без потерь. Вообще-то Adept(1326 знак., 20.11.2021 04:46)
- там где оно нужно, и реально может помочь - там давно есть аппаратная компрессия. я про видеокарты. - Mahagam(20.11.2021 13:48)
- дык я о том и говорю, что жипег базируется на психофизиологических
особенностях зрения, поэтому для картинок вполне эффективен, но
подобные алгоритмы совершенно не годятся для сжатия без потерь. а
как бы топик о применении технологий компрессии ОЗУ, то бишь именно
без потерь. Вообще-то Adept(1326 знак., 20.11.2021 04:46)
- не избыточная информация, а "особенности восприятия человеком".
банальная цветовая субдискретизация запросто может уменьшить
количество данных в файле картинки в два раза, а человек с трудом
увидит разницу. а зашумив картинку ты туды добавил информации, чего
после этого удивляться, что размер "архива" стал больше? - Mahagam(20.11.2021 02:37)
- жипег это сжатие с потерями. он годится только для картинок, в
случае, когда информация избыточна многократно (кто в здравом уме
будет разглядывать чуть заметные морщинки на лице или считать
реснички :)) в "жипегах" убивается большая часть информации.
Попробуйте поставить 100% качество и обнаружите, что от
эффективности сжатия не осталось и следа :) - Adept(20.11.2021 02:11)
- жипег в первую очередь уберёт высокие частоты, то есть размажет
шум. а деталей с увеличением сжатия в любом случае убавится. - Mahagam(20.11.2021 02:01)
- попробуйте добавить к любой картинке шум и она станет практически
несжимаема (картинки с фотоаппаратов, а не рисованные конечно, и
так-то не сжимаются почти, без потери данных) - Adept(20.11.2021 01:57)
- читер! - SciFi(19.11.2021 20:41)
- естественно же :) все алгоритмы архивации используют статистические
методы. Чем более случайны данные тем меньше коэффициент сжатия.
Если обращали внимание, Adept(548 знак., 20.11.2021 01:34)
- в видеокартах для текстур/фреймбуферов давно есть. но там данные
имеют весьма понятные особенности. кроме того, любой модуль сжатия
даст задержку. и на фоне 50ns у самой памяти, лишние сотня
наносекунд - это уже замедление в три раза. - Mahagam(19.11.2021 12:09)
- Ну текстуры жмут софтварно, а распаковывает да, видюха. Там кстати
довольно интересные алгоритмы используются, распаковка вполне годна
для эмбеддинга - LightElf(19.11.2021 15:02)
- не только. уже несколько лет жмут и буфера что летять обратно в память. - Mahagam(19.11.2021 15:31)
- Ну текстуры жмут софтварно, а распаковывает да, видюха. Там кстати
довольно интересные алгоритмы используются, распаковка вполне годна
для эмбеддинга - LightElf(19.11.2021 15:02)
- Стоп-стоп-стоп... фактически щас технология zram используется уже
штатно почти во всех линукс ядрах, в том числе и андроиде...
тв-приставка и иже с ними... роутерах... ВЕЗДЕ... sav6622(13 знак., 18.11.2021 22:50, ссылка, ссылка)
- Ну это разные вещи. Одно дело рамдиск, и совсем другое IP блок
перед контроллером памяти, который жмёт всё и вся налету. Почему
разница? Представьте вам нужно загрузить мегабайт в память.
Представьте, что этот блок сжатия может сжимать х2. Итого, у вас на
этом мегабайте виртуальное удвоение объема RAM, и удвоение скорости
доступа к этой виртуальной RAM. Не рамдиск, а именно RAM. - Ralex(19.11.2021 11:23)
- Есть один неочевидный момент: а как учитывать, сколько памяти
откушали данные от доступного объёма? С обычным механизмом вопросов
нет - положили 1Мб - заняли 1 Мб. А тут? Положили через сжатие
текстовые данные - заняли 0,5 Мб. Как об этом управляющая программа
узнает? Dingo(233 знак., 19.11.2021 12:15)
- Вы всегда знаете от контроллера физической памяти + MMU, сколько есть свободной. Просто MMU не знает, что конкретно лежит в той странице, он просто точно знает что она занята. С точки зрения ОС, у неё к примеру есть свободный гиг. Браузер попросил 300 мег, дали, а он там реально 400-500 мег нашел. Ну нашел и нашел! Занято то физики по-прежнему 300, и свободно 700. - Ralex(19.11.2021 12:28)
- ну так оно софтово делается, через MMU. есть несколько выделенных софту страниц памяти, к ним давно не обращались, значит сжимаем их и высвобождаем несколько страниц в свободный пул для других приложений. а если текущее приложение обратится к этим страницам, то произойдёт классическая подкачка из свопа, только вместо диска будет подкачка из сжатых страниц. видимо новинка в том, что этот трюк хотят провести хотя бы частично на аппаратном уровне. - Mahagam(19.11.2021 12:19)
- Ну как "удвоение"? Бывают же и несжимаемые данные. И что тогда? RAM
скажет тебе "прости, родной, нишмагла"? Дьявол в деталях, наверное. - SciFi(19.11.2021 11:56)
- я специально указал х2, среднее значение, хотя в статье говорится
до х3. Среднее! - Ralex(19.11.2021 12:16)
- Вот я положу в память RAR архив и посмотрю, как как из этого контроллера дым выйдет - LightElf(19.11.2021 15:04)
- Как я понял базар об скорости, а не объеме. Ну не шмогла быстре,
придется подождать. Правда тут возникает вопрос, не проще ли
поделить объем пополам и за счет этого получить гарантированное
удвоение скорости банальным
мультиплексированием/демультиплексированием. Но в этом ничего
нового нет. И эта, как я понимаю узкое место не скорость памяти, а
скорость с которой ее подгонять по шине поспевают. - Codavr(19.11.2021 12:14)
- вроде сегодня всё наоборот - выборка из ячеек ниже 40-50ns не
опускается, а мегаскорость через интерфейс DDR4/DDR5/GDDR6X
обеспечивается множествеными банками внутри чипа. - Mahagam(19.11.2021 12:16)
- Тогда мне ваще не понятно, что мешает мультиплексировать память.
Один хер данные блоками гонят. - Codavr(19.11.2021 12:21)
- на сегодня всё давно замультиплексировано. банки в памяти - это
считай оно. пропускную интерфейса забивают почти на 100%. беда в
задержках, такт проца 250 пикосекунд, а выборка из памяти 45000
этих самых пикосекунд. - Mahagam(19.11.2021 13:05)
- Ну так и каков смысл жать данные ради мифического удвоения? - Codavr(19.11.2021 19:52)
- что не нашлось в памяти - придётся искать на SSD, а туда щемится уже 45000000 пикосекунд. - Mahagam(19.11.2021 21:49)
- Ну так и каков смысл жать данные ради мифического удвоения? - Codavr(19.11.2021 19:52)
- на сегодня всё давно замультиплексировано. банки в памяти - это
считай оно. пропускную интерфейса забивают почти на 100%. беда в
задержках, такт проца 250 пикосекунд, а выборка из памяти 45000
этих самых пикосекунд. - Mahagam(19.11.2021 13:05)
- Тогда мне ваще не понятно, что мешает мультиплексировать память.
Один хер данные блоками гонят. - Codavr(19.11.2021 12:21)
- вроде сегодня всё наоборот - выборка из ячеек ниже 40-50ns не
опускается, а мегаскорость через интерфейс DDR4/DDR5/GDDR6X
обеспечивается множествеными банками внутри чипа. - Mahagam(19.11.2021 12:16)
- Наверняка что-то умалчивается. Я думаю следующим шагом может быть
установка двух таких IP-блоков друг за другом, для получения
эффекта х4 :) - AlexBi(19.11.2021 12:00)
- Надо проверить, а вдруг оно умеет биткоэн на 2 умножать! - SciFi(19.11.2021 12:03)
- Не подсказывай, а то потом ОЗУ ваще хуй купишь. - Codavr(19.11.2021 12:12)
- Надо проверить, а вдруг оно умеет биткоэн на 2 умножать! - SciFi(19.11.2021 12:03)
- я специально указал х2, среднее значение, хотя в статье говорится
до х3. Среднее! - Ralex(19.11.2021 12:16)
- Было такое еще для 286 компов... удвоение обьема винчестеров =))) ладно, умолкаю...по мне дак ничего нового - sav6622(19.11.2021 11:26)
- Есть один неочевидный момент: а как учитывать, сколько памяти
откушали данные от доступного объёма? С обычным механизмом вопросов
нет - положили 1Мб - заняли 1 Мб. А тут? Положили через сжатие
текстовые данные - заняли 0,5 Мб. Как об этом управляющая программа
узнает? Dingo(233 знак., 19.11.2021 12:15)
- Ну это разные вещи. Одно дело рамдиск, и совсем другое IP блок
перед контроллером памяти, который жмёт всё и вся налету. Почему
разница? Представьте вам нужно загрузить мегабайт в память.
Представьте, что этот блок сжатия может сжимать х2. Итого, у вас на
этом мегабайте виртуальное удвоение объема RAM, и удвоение скорости
доступа к этой виртуальной RAM. Не рамдиск, а именно RAM. - Ralex(19.11.2021 11:23)
- Лет более 20 ти назад поспорили об эффективности архиваторов,
сгенерил бинарный массив псевдослучайных отсчетов, не сжимается ни
чем. - Visitor(19.11.2021 20:25)