Визуализация оперативной памяти

А что ты в данном контексте сверткой называешь? С чем сворачивать будешь и зачем, оно ж вроде бинарный оператор?

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

Возможно тебе поможет /proc/<pid>/mem и /proc/<pid>/maps

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

Логируй в файл такие события. Визуализировать «дёшево» можно скармливая данные gplot или, для эстетов, gource.

Кое-какие мысли по-поводу визуализации:

1. Не стоит брать выходной диапазон цветов как 000000 до FFFFFF. Для человеческого глаза всё будет выглядеть как одно и тоже, разница не будет считываться. Гораздо лучше выбрать небольшой набор чётко различимых цветов (скажем 20 или около того).

Для того чтобы оптимально подобрать набор цветов, чтобы выразить наибольшее количество информации стоит почитать про HCL: https://www.vis4.net/blog/2011/12/avoid-equidistant-hsv-colors/

2. Не стоит брать пиксель за единицу отображения, взять хотя бы 2х2 или даже 3х3. Одиночные пиксели глазу очень трудно воспринимать.

3. Наверное имеет смысл делать сразу несколько разных свёрток.

Например считать отклонение от математического ожидания для кусочка (1, 4, 8 байт?), и раскидать его в три категории: близко к нулю, сильно ниже нуля, сильно выше нуля. Тогда можно для каждого цвета определить оттенки: нормальный, светлый, тёмный, которые будут кодировать отклонение от мат. ожидания.

Что взять за вторую свёртку честно говоря не знаю. Чексумма поможет видеть идентичные кусочки, но не более.

Возможно будет интересным способом отобразить 4 байта, будет вычислить отношения каждого отдельного байта к остальным. Такой способ позволит замечать последовательно увеличивающиеся значения. Например так:

work = byte1, byte2, byte3, byte4

color1: byte1 > byte2 > byte3 > byte4
color2: byte2 > byte1 > byte3 > byte4
color3: byte3 > byte2 > byte1 > byte4
...

colorN1: byte1 == byte2 && byte3 > byte4
colorN2: byte1 == byte2 && byte3 < byte4

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

Память может быть как несколько байт, так и много гигабайт.

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

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

Как можно представить физический регион оперативной памяти в виде изображения?

Есть альтернативное мнение по графическому представлению памяти. Называется lavaps:

https://sourceforge.net/projects/debiannoofficial/files/wheezy-update/utils/lavaps_2.7-wheezy_i386.deb

Это сильно отличается от заявленного в «теме», но обладает гораздо более «сильным» визуальным эффектом.

Спасибо, пока визуализирую в ЧБ. Сверток и представлений надо иметь множество видимо.

По поводу МБ масштаба не соглашусь, тут все зависит от природы приложения. В моем, в зависимости от конфигурации и в определенный момент времени, возникают структуры которые заметны уже на мегабайтных и прочих масштабах (код копирует сам себя). В конечном итоге та версия программы которая работает сейчас предположительно должна выродиться или начать стагнировать, те последовательность представлений примет статичный или осциллирующий вид (хотя период может оказаться сколь угодно большим).

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

В моем случае самой важной метрикой скорей всего является нахождение самого популярного слова определенной длины (и число вхождений) на всем отрезке памяти.

В моем случае самой важной метрикой скорей всего является нахождение самого популярного слова определенной длины (и число вхождений) на всем отрезке памяти.

Может тогда действительно тупо считать чексуммы?