Показаны сообщения с ярлыком C#. Показать все сообщения
Показаны сообщения с ярлыком C#. Показать все сообщения

суббота, 16 июля 2011 г.

Вычисления на GPU в .NET приложениях

В 1991 году мне в руки попался журнал Scientific American [1] с красивыми фрактальными картинками. В 90-х фракталы были в моде, даже растровый редактор был назван Fractal Design Painter, а в журналах обсуждались фрактальные алгоритмы сжатия изображений с умопомрачительной эффективностью (не менее 1000:1). В итоге оказалось что алгоритмы показывают обещанные результаты только для изображений типа листа папоротника.
Что касается картинок. Я написал программу и запускал ее в учебном классе на PC 8088, а преподаватель дал погонять на 80486 (с встроенным сопроцессором) в лаборатории в институте. Сейчас трудно вспомнить результаты, приблизительно 320x200 за 5 минут, это на 8088 но с сопроцессором.
Пару лет назад, с появлением DirectX 10, GPU, CUDA, захотелось посмотреть что же дал прогресс за последние 20 лет, а тут еще попалась пара интересных статей про MS Accelerator. Так как во фракталах Ляпунова значение каждой точки вычисляется независимо, то есть вычисления идеально распараллеливаются - задача как раз для GPU.

Первые цифры

Метрику для обозначения производительности возьмем такую - "миллион точка-итераций в секунду" (mega iterations per second, mis). Это отражает особенность алгоритма - в большинстве случаев сходимость достигается после 500 итераций, на значительная часть областей требует 2-4 тыс. итераций.
Исходный код выглядит так:
protected static double CalculateExponent(double[] pattern, double initial, int warmup, int iterations)
{
 var x = initial;
 var patternSize = pattern.Length;

 for (var i = 0; i < warmup; i++)
 {
  var r = pattern[i % patternSize];
  x *= r * (1 - x);
 }

 double total = 0;
 for (var i = warmup; i < iterations; i++)
 {
  var r = pattern[i % patternSize];
  var d = Math.Log(Math.Abs(r - 2 * r * x));

  total += d;
  if (Double.IsNaN(d) || Double.IsNegativeInfinity(d) || Double.IsPositiveInfinity(d))
  {
   return d;
  }

  x *= r * (1 - x);
 }

 return total / Math.Log(2) / (iterations - warmup);
}


Многопоточная реализация для CPU без использования SSE показала 42 mis на двухядерном Core2 6400 @3.0GHz. Немного, с учетом примерно 12 операций выборки/вычисления на цикл, или ~500 млн на два ядра. Около 10 тактов на операцию, что слишком плохо. Вероятно Log() и арифметика в таком режиме плохо конвейеризируются. Это отдельная задача для исследований.

MS Accelerator

Следом была написана реализация под Accelerator v.2, очень простая библиотека в идеологии SIMD, где формула выражение строится над большой матрицей. Библиотека содержит аналоги практически всех функций System.Math и перегружает операторы. Адресация соседних ячеек возможна с помощью функций сдвига матрицы. Библиотека действительно очень проста, изучается за один вечер и позволяет писать наглядный код типа:
var dimensions = new[] { 1000, 1000 };
var x = new FPA((float)settings.InitialValue, dimensions);

// creating A,B arrays on the fly a few times faster!
var fr = new Func<int, FPA>(i => Math.Replicate(new FPA(
 settings.Pattern[i % settings.Pattern.Length] == 'a' ? aArray : bArray), w, h));

// warmup cycle, no limit calculation
for (var i = 0; i < settings.Warmup; i++)
{
 var r = fr(i);
 x *= r * (1.0f - x);
}

var total = new FPA(0, dimensions);
for (var i = settings.Warmup; i < settings.Iterations; i++)
{
 var r = fr(i);

 total += Math.Log2(Math.Abs(r - 2 * r * x));
 x *= r - r * x;
}
total *= 1f / (settings.Iterations - settings.Warmup);

return total;

Результат в среднем 250 mis, но на некоторых разрешениях получается до 400 mis, то есть быстрее почти в 10 раз.
На этом можно было бы остановиться, но от видеокарты со 192 процессорами, работающими на частоте 1 ГГЦ ожидаешь хотя бы 100-кратного преимущества. Также были замечены разные странности, частично отраженные в вышеприведенном коде, и в частности, чрезмерное использование памяти видеокарты.

В результате, проштудировав соответствующую статью на Хабре, я решил попробовать библиотеку Brahma (она же за деньги под названием Tidepowered).

Brahma

Собственно код я написал и он доступен в исходниках. Но мне не хотелось переезжать на тормозную VS 2010, а на компиляторе C# 3.5 из-под VS2008 выражения (expression) получались, как выяснилось, неразборчивыми для Brahma. После пары часов упражнений я решил что мне эта прослойка не нужна и я быстрее напишу нативный код для OpenCL.
Смысл использования Brahma/Tidepowerd мне непонятен - документации мало, денег стоит много, синтаксис странный, кроссплатформенность неважная (например, вышеупомянутые проблемы на .NET 3.5), диагностика в случае ошибок никакая. Хотя код, в общем-то, нагляден:
(ds, a, b, m, t) =>
 from pt in ds
 let i = pt.GlobalID0
 let j = pt.GlobalID1
 let x = initialX
 let r = default(float32)
 let bv = b[i]
 let av = a[j]
 let warmup = engine.Loop(0, warmupCount, idxs =>
  idxs.Select(idx =>
   new Set[]
    {
     r <= (m[idx%maskLen] == 0 ? av : bv),
     x <= r*x - r*x*x
    })
  )
 let total = default(float32)
 let calculate = engine.Loop(warmupCount, iterationsCount, idxs =>
  idxs.Select(idx =>
   new Set[]
    {
     r <= (m[idx%maskLen] == 0 ? av : bv),
     total <= total + Math.Log(Math.Fabs(r - 2*r*x)),
     x <= r*x - r*x*x
    })
  )
 select new Set[]
  {
   t[j*columns + i] <= total*divider
  }

OpenCL/Cloo

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

Ссылки

1. "Leaping into Lyapunov Space", by A. K. Dewdney, Scientific American, Sept. 1991, pp. 178-180
2. Tomas Petricek. Accelerator and F# (II.): The Game of Life on GPU
3. Последняя версия исходного кода к статье на bitbucket

понедельник, 6 июня 2011 г.

Производительность вычисления формул

У нас есть решение - обработчик OLAP-запросов, для которого критичная скорость преобразования и загрузки данных в хранилище и вычисление формул в MDX-запросах. Достоверно известно ("британские ученые доказали"), что в типовом сценарии на вычисления уходит 90% времени процессора. Это и есть проблема.

Итак, исходная реализация: предварительно разбираем выражение и строим синтаксическое дерево (AST, но в своей объектной модели). Далее при выполнении кода просто просим дерево посчитать значение выражения для текущего контекста выполнения (контекст включает текущую строку данных и область видимости блоков агрегации данных, например в матричной группировке).

Варианты решения

Первая попытка решения - вместо собственного AST формируем функцию вычисления значения, аргументом которой является контекст. Например есть выражение:
(GetRecordValue(ctx,2) * 1024 + GetRecordValue(ctx,3))/3600/(Max(1, GetRecordValue(ctx,4))

Код построения функции даже проще кода построения AST. К сожалению, на каждом этапе построения функции приходится формировать лямбда функцию с аргументом контекста, что приводит к следующей результирующей функции:

ctx5 => (ctx4 => (ctx3 => (ctx2 => (ctx => 
    GetRecordValue(ctx,2))(ctx2) * (ctx => 1024)(ctx2))(ctx3)
    + (ctx2 => (ctx => GetRecordValue(ctx,2))(ctx2))(ctx3))(ctx4) / (ctx4 => 3600))(ctx5)
  / (ctx2 => Max(ctx2 => 1, (ctx => GetRecordValue(ctx,4)(ctx2)))(ctx5)


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

Выражения, появившиеся в .NET 3.5 - это аналог исходного решения, но если метод Compile использует IL Emit, можно ожидать существенно лучший результат.

Для проверки решения на практике реализуем два парсера - первый возвращает лямбда-функцию вычисления, второй - Expression.

NParsec

Проще всего сделать парсер с помощью библиотеки NParsec (последовательный порт parsec => jparsec => nparsec).

Обобщенный код парсера занимает примерно 30 строк наглядного кода:
private static Parser<T> CreateParser<T>(Func<string, T> getVar,
 IDictionary<char,Map<T,T,T>> binaryOps, Map<string,T> parseValue, Map<T,T> unaryMinus)
{
 var patCharExt = Patterns.IsChar(Char.IsLetter).Or(Patterns.IsChar('_'));
 var patVar = patCharExt.Seq(Patterns.InRange('0', '9').Or(patCharExt).Many());
 var scannerVar = Scanners.IsPattern(patVar, "var");

 var lexerVal = Lexers.Lex(scannerVar, Tokenizers.ForString);

 var operators = Terms.GetOperatorsInstance("+", "-", "*", "/", "(", ")", "^");
 var ignored = Scanners.IsWhitespaces().Many_();
 var lexeme = Lexers.Lexeme(ignored, operators.Lexer | Lexers.LexDecimal() | lexerVal).FollowedBy(Parsers.Eof());

 var pPlus = GetOperator(operators, "+", binaryOps['+']);
 var pMinus = GetOperator(operators, "-", binaryOps['-']);
 var pMul = GetOperator(operators, "*", binaryOps['*']);
 var pDiv = GetOperator(operators, "/", binaryOps['/']);
 var pPower = GetOperator(operators, "^", binaryOps['^']);
 var pNeg = GetOperator(operators, "-", unaryMinus);
 var pVar = Terms.OnString((@from, len, data) => getVar(data));

 var pNumber = Terms.OnDecimal((_, __, s) => parseValue(s));
 var lazyExpr = new Parser<T>[1];
 var pLazyExpr = Parsers.Lazy(() => lazyExpr[0]);
 var pTerm = pLazyExpr.Between(operators.GetParser("("), operators.GetParser(")")) | pNumber | pVar;
 var optable = new OperatorTable<T>()
  .Infixl(pPlus, 10).Infixl(pMinus, 10)
  .Infixl(pMul, 20).Infixl(pDiv, 20)
  .Infixl(pPower, 25).Prefix(pNeg, 30);
 var pExpr = Expressions.BuildExpressionParser(pTerm, optable);
 lazyExpr[0] = pExpr;
 return Parsers.ParseTokens(lexeme, pExpr.FollowedBy(Parsers.Eof()), "calculator");
}

private static Parser<T> GetOperator<T>(Terms ops, string op, T v)
{
 return ops.GetParser(op).Seq(Parsers.Return(v));
}


Парсеры для лямбда-функций и Expressions на основе обобщенного парсера выглядят как:
private static Parser<Func<double>> CreateLambdaParser(Func<string, Func<double>> getVar)
{
 var binaryOps = new Dictionary<char, Map<Func<double>, Func<double>, Func<double>>>
  {
   {'+', (a, b) => () => a() + b()},
   {'/', (a, b) => () => a()/b()},
   {'-', (a, b) => () => a() - b()},
   {'*', (a, b) => () => a()*b()},
   {'^', (a, b) => () => Math.Pow(a(), b())}
  };
 Map<Func<double>, Func<double>> unaryMinus = v => () => -v();
 Map<string, Func<double>> parseDouble = s =>
  {
   var v = double.Parse(s);
   return () => v;
  };

 return CreateParser(getVar, binaryOps, parseDouble, unaryMinus);
}

private static Parser<Expression> CreateExpressionParser(Func<string, Expression> getVar)
{
 var binaryOps = new Dictionary<char, Map<Expression, Expression, Expression>>
  {
   {'+', Expression.Add},
   {'/', Expression.Divide},
   {'-', Expression.Subtract},
   {'*', Expression.Multiply},
   {'^', (a,b) => Expression.Call(typeof(Math).GetMethod("Pow"), a, b)}
  };
 Map<string, Expression> parseDouble = s => Expression.Constant(double.Parse(s));

 return CreateParser(getVar, binaryOps, parseDouble, Expression.Negate);
}

Ну и собственно:

Результаты замера производительности

Для замера скорости подойдет полином 20-й степени вида ((a1+1)*a2+1)*a3 + 1... Результат - примерно 200 кратное превосходство Expression - 120 секунд против 600 мс. Результат подозрительный, но причина в том что переменные a1..a20 - это по сути константы, так как компилятор выражений, обнаружив что в правой части выражения стоит константа, вероятно подставил значения в AST и произвел оптимизацию.

Для получения достоверного результата я заменил константу на вызов функции и получил вполне достоверный результат 5.58c для лямбда-функций против 1.17с для выражений. А при включенной оптимизации компилятора C# - 2.27с против 0.26с. В результате имеем 10-кратный выигрыш при соизмеримой сложности кода.

Исходный код и тесты доступны по в репозитарии на bitbucket

понедельник, 21 февраля 2011 г.

Решение на CLinq

Интересная библиотека - Continuous Linq. Позволяет сделать "наблюдаемую" выборку, используя Linq и соответствующие методы-расширения.

Я попробовал решить исходную задачу с помощью следующего кода (правда пришлось заменить самописные ObservableCollection и сопутствующие классы на те что включены в сборку WindowsBase от третьего фреймворка):
var coll = new ContinuousCollection<Page>();

var res = 
 coll.Select(p => new Rectangle(Point.Empty, p.Size))
 .Concat(coll.Select(p => p.PageHeader.Rect))
 .Concat(coll.SelectMany(p => p.Items).Select(block => block.Rect))
 .Concat(coll.SelectMany(p => p.Items).SelectMany(b => b.Items).Select(t => t.Rect))
 ;

NotifyCollectionChangedEventHandler h = (sender, args) =>
 {
  if (args.OldItems != null)
   foreach (var oldItem in args.OldItems)
   {
    invalidateHandler((Rectangle) oldItem);
   }
  if (args.NewItems != null)
   foreach (var newItem in args.NewItems)
   {
    invalidateHandler((Rectangle) newItem);
   }
 };

res.CollectionChanged += h;

coll.Add(page);
return new DisposeDelegate(() => res.CollectionChanged -= h);

Стандартный набор тестов проходит. Несколько тестов падает, но это непринципиально (проблема момента начала наблюдения).

Интересно, совпадают ли мощности у CLinq и моего решения в плане отслеживания изменений, то есть все ли задачи доступные CLinq решаются механизмом подписки. Если это так, то можно сделать билдер на тех же LINQ расширениях. Другая задача - это генерация последовательности, аналогичной CLinq.

воскресенье, 12 декабря 2010 г.

Проблема "глубокой" подписки (часть 3)

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

Компактная запись тривиального случая

Рассмотренный в самой первой статье пример решения для одного свойства может быть записан компактнее:
public IDisposable Observe(Page page, Action<Rectangle> invalidateHandler)
{
 var pageSizeHandler = new PropertyChanged((sender, args) =>
 {
  if (args.PropertyName == "Size")
  {
   invalidateHandler(new Rectangle(Point.Empty, (Size)args.OldValue));
   invalidateHandler(new Rectangle(Point.Empty, (Size)args.NewValue));
  }
 });
 page.PropertyChanged += pageSizeHandler;

 return new DisposeDelegate(() => page.PropertyChanged -= pageSizeHandler);
}

где DisposeDelegate - вспомогательный класс, реализующий IDisposable, цель которого состоит в выполнении указанного действия при удалении объекта вызовом Dispose.
Идея и смысл состоят в том, что если где-то мы подписались, то в другом месте надо будет отписаться. Полагаться на сборщик мусора не стоит, потому что нас интересует детерминированное поведение кода.

Обобщение для произвольного свойства и коллекции

Приведенный выше пример можно обобщить для произвольного класса, реализующего контракт INotifyPropertyChanged, а также позаботиться о будущем рефакторинге и устранить использование имени свойства:
public static IDisposable Observe<T, TI>(T obj, Expression<Func<T, TI>> getterExpr, Action<TI> action)
 where T : ObjectRoot
{
 var memberAssignment = (MemberExpression)getterExpr.Body;
 var propertyName = memberAssignment.Member.Name;
 var getter = getterExpr.Compile();

 var lastValue = getter(obj);

 var handler = new PropertyChanged((sender, args) =>
 {
  if (args.PropertyName == propertyName)
  {
   action(lastValue);
   action(lastValue = (TI)args.NewValue);
  }
 });
 obj.PropertyChanged += handler;

 return new DisposeDelegate(() => obj.PropertyChanged -= handler);
}

В случае коллекции нас интересует не само изменение коллекции, а возможность подписаться/отписаться на изменения элементов коллекции. Код очевиден:

public static IDisposable ObserveList<TI>(IObservableList<TI> list, Func<TI, IDisposable> subscribeItem)
{
 var subscribed = list.Select(subscribeItem).ToList();

 var handler = new CollectionChanged((sender, args) =>
 {
  switch (args.Action)
  {
   case ActionType.Clear:
    subscribed.All(d => { d.Dispose(); return true; });
    subscribed.Clear();
    break;
   case ActionType.Insert:
    subscribed.Insert(args.Index, subscribeItem(list[args.Index]));
    break;
   case ActionType.Remove:
    subscribed[args.Index].Dispose();
    subscribed.RemoveAt(args.Index);
    break;
   case ActionType.Set:
    subscribed[args.Index].Dispose();
    subscribed[args.Index] = subscribeItem(list[args.Index]);
    break;
  }
 });

 list.Changed += handler;

 return new DisposeDelegate(
  () => list.Changed -= handler,
  () => subscribed.All(d => { d.Dispose(); return true; })
  );
}

Переменная subscribed хранит список "подписок", код внутри switch заботится о синхронизации подписок и наблюдаемой коллекции. Функция отписывания просто отписывается от всех членов коллекции.

Собираем все вместе

Используя приведенные методы можно решить исходную задачу, а именно представить метод Observe в виде:
public IDisposable Observe(Page page, Action<Rectangle> invalidateHandler)
{
 return new DisposeDelegate(new[] {
  Observe(page, p => p.Size, value => invalidateHandler(new Rectangle(Point.Empty, value))),
  Observe(page, p => p.Items, list =>
   ObserveList(list, block => new DisposeDelegate(new[] {
    Observe(block, i => i.Rect, invalidateHandler),
    Observe(block, i => i.Items, items =>
     ObserveList(items, text => Observe(text, t => t.Rect, invalidateHandler)))
    })
   )
  )});
}

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

Эту неприятность можно обойти так: подписывание/отписывание будем считать изменением и будем вызывать "действие":
public static IDisposable Observe<T, TI>(T obj, Expression<Func<T, TI>> getterExpr, Action<TI> action)
 where T : ObjectRoot
{
...
 var lastValue = getter(obj);
 action(lastValue);

...

 return new DisposeDelegate(
  () => obj.PropertyChanged -= handler,
  () => action(lastValue));
}

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

Заключение

К полученному решению можно добавить "синтаксического сахара" (см. Step3 и класс ObserveExtensions), но и без этого код достаточно нагляден.
Таким образом, применение функциональной декомпозиции позволило найти простое и компактное решение не самой тривиальной задачи.

Приложение: исходный код

Для сборки проекта понадобятся библиотеки NUnit и Moq.

Исходный код: DeepSubscribe-step3.zip

Решение содержит три последовательные реализации в модулях Step1, Step2 и Step3. Тесты для всех трех решений содержатся в файле ObserverTests (набор тестов один, но применяется ко всем решениям).

суббота, 11 декабря 2010 г.

Проблема "глубокой" подписки (часть 2)

Коллекции всегда осложняют жизнь.

Определим следующее событие (с аргументами):
public delegate void CollectionChanged(object sender, CollectionChangedEventArgs args);

public class CollectionChangedEventArgs:EventArgs
{
 public CollectionChangedEventArgs(ActionType action, int itemIndex)
 {
  Action = action;
  Index = itemIndex;
 }

 public ActionType Action { get; private set; }
 public int Index { get; private set; }
}

public enum ActionType { Clear, Insert, Remove, Set }

Назначение свойств очевидно. Структура намеренно упрощена и не подразумевает одновременного изменения нескольких членов коллекции (не считая очистки всех).

Определим также следующий обобщенный класс коллекций, которые уведомляют о своих изменениях:
public interface IObservableCollection
{
 event CollectionChanged Changed;
}

public interface IObservableList<T>:IList<T>, IObservableCollection
{}

public class ObservableCollection<T> : Collection<T>, IObservableList<T>
{
 public event CollectionChanged Changed;

 public ObservableCollection()
 {}

 public ObservableCollection(IList<T> list):base(list)
 {}

 protected void OnChanged(CollectionChangedEventArgs args)
 {
  var handler = Changed;
  if (handler != null)
   handler(this, args);
 }

 #region change notification

 protected override void ClearItems()
 {
  base.ClearItems();
  OnChanged(new CollectionChangedEventArgs(ActionType.Clear, -1));
 }

 protected override void InsertItem(int index, T item)
 {
  base.InsertItem(index, item);
  OnChanged(new CollectionChangedEventArgs(ActionType.Insert, index));
 }

 protected override void SetItem(int index, T item)
 {
  base.SetItem(index, item);
  OnChanged(new CollectionChangedEventArgs(ActionType.Set, index));
 }

 protected override void RemoveItem(int index)
 {
  base.RemoveItem(index);
  OnChanged(new CollectionChangedEventArgs(ActionType.Remove, index));
 }

 #endregion
}

Соответственно изменим определение объектной модели в классах Page.cs и Block.cs:
// Page.cs
private IObservableList _items = new ObservableCollection();
public IObservableList Items...

// Block.cs
private IObservableList _items = new ObservableCollection();
public IObservableList Items...

Еще одно упрощение состоит в отсутствии проверки на null для коллекций _items. Я стараюсь избегать использования null, если есть возможность использовать пустой массив или шаблон Null object.

Как мы убедимся что решение работает

Мы напишем много тестов следующего вида:
[TestFixture]
public class ObserverTests
{
 [Test]
 public void WatchTextItems()
 {
  var testee = new Page { Size = new Size(10, 10) };
  var observer = new Mock<IRelocateObserver>();

  testee.Items.Add(new Block());
  testee.Items[0].Items.Add(new TextItem { Rect = new Rectangle(1, 2, 3, 4) });

  Observe(testee, observer.Object.Invalidate);

  // act
  testee.Items[0].Items[0].Rect = new Rectangle(3, 4, 5, 6);

  // verify
  observer.Verify(o => o.Invalidate(new Rectangle(1, 2, 3, 4)));
  observer.Verify(o => o.Invalidate(new Rectangle(3, 4, 5, 6)));
 }
}
Здесь Observe - функция которую мы собираемся тестировать. Вторым аргументом функции является Action, в качестве которого мы передадим мок-объект.

В следующей (последней) статье я рассмотрю проблему еще раз и решение.

четверг, 9 декабря 2010 г.

Проблема "глубокой" подписки (часть 1)

Итак, проблема в упрощенной формулировке: есть объектная модель страницы с текстом, есть метод отрисовки страницы на экране. Модель уведомляет об изменении своих свойств через событие PropertyChanged.
Задача состоит в перерисовке только той части части страницы, которую затронули изменения модели. Проблема же состоит в том, что мы не можем изменить код модели и внедрить в нее механизм уведомления, структура модели является иерархической, а коллекции могут быть изменены или заменены целиком.
Например мы подписаны на изменение размера всех элементов первого параграфа, а параграф затем заменяется другим. Нам необходимо отписаться от всех элементов "старого" параграфа, и подписаться на все элементы "нового" параграфа, а также инвалидировать области всех элементов как старого, так и нового параграфа.

Итак модель:
class Page:ObjectRoot
{
 private Size _pageSize;
 private IList<Block> _items;

 public Size Size
 {
  get { return _pageSize; }
  set { UpdateProperty("Size", ref _pageSize, value); }
 }

 public IList<Block> Items
 {
  get { return _items; }
  set { UpdateProperty("Items", ref _items, value); }
 }
}

class Block:ObjectRoot
{
 private Rectangle _rect;
 private IList<TextItem> _items;

 public Rectangle Rect
 {
  get { return _rect; }
  set { UpdateProperty("Rect", ref _rect, value); }
 }

 public IList<TextItem> Items
 {
  get { return _items; }
  set { UpdateProperty("Items", ref _items, value); }
 }
}

class TextItem : ObjectRoot
{
 private Rectangle _rect;
 private string _text;

 public Rectangle Rect
 {
  get { return _rect; }
  set { UpdateProperty("Rect", ref _rect, value); }
 }

 public string Text
 {
  get { return _text; }
  set { UpdateProperty("Text", ref _text, value); }
 }
}


В этой модели ObjectRoot предоставляет обобщенный механизм уведомлений об изменении значений свойств:
class ObjectRoot
{
 public event PropertyChanged PropertyChanged;

 protected void UpdateProperty<T>(string name, ref T holder, T newValue)
 {
  if (Equals(newValue, holder)) return;
  var oldValue = holder;
  holder = newValue;

  RaisePropertyChanged(new PropertyChangedArgs(name, oldValue, newValue));
 }

 protected void RaisePropertyChanged(PropertyChangedArgs args)
 {
  OnPropertyChanged(args);
 }

 protected virtual void OnPropertyChanged(PropertyChangedArgs args)
 {
  var handler = PropertyChanged;
  if(handler != null)
   handler(this, args);
 }
}

public delegate void PropertyChanged(object sender, PropertyChangedArgs args);

public class PropertyChangedArgs : EventArgs
{
 public PropertyChangedArgs(string name, object oldValue, object newValue)
 {
  PropertyName = name;
  OldValue = oldValue;
  NewValue = newValue;
 }

 public string PropertyName { get; private set; }
 public object OldValue { get; private set; }
 public object NewValue { get; private set; }
}


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

class NaiveObserver
{
 private readonly Page _page;
 private readonly Action<Rectangle> _invalidateHandler;

 public NaiveObserver(Page page, Action<Rectangle> invalidateHandler)
 {
  _page = page;
  _invalidateHandler = invalidateHandler;

  page.PropertyChanged += PageSizeHandler;
 }

 private void PageSizeHandler(object sender, PropertyChangedArgs args)
 {
  if (args.PropertyName == "Size")
  {
   _invalidateHandler(new Rectangle(Point.Empty, (Size) args.OldValue));
   _invalidateHandler(new Rectangle(Point.Empty, (Size) args.NewValue));
  }
 }

 public void Stop()
 {
  _page.PropertyChanged -= PageSizeHandler;
 }
}


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

Далее мы определим протокол уведомления об изменении коллекций и приступим к построению решения.