Цифирь, которой не было у Блейзера в абстракте(
http://www.isp.uni-luebeck.de/kps07/fil ... laeser.pdf ), но в основной работе(
http://e-collection.ethbib.ethz.ch/view/eth:30090 с.182) присутствует:
Table 7-1. Zurich simulation, runtimes in minutes, one processor (in minutes)
Zurich traffic simulation-----------Component-C++-----------C#
----------------------------------------system----(sequential)--(concurrent)
1,000 cars------------------------------0.03------140-----------19
10,000 cars-----------------------------0.5-------140-----------out of memory
100,000 cars----------------------------12--------190-----------out of memory
260,000 cars----------------------------67--------210-----------out of memory
Table 7-2. Zurich simulation, runtimes in minutes, six processors (in minutes)
Zurich traffic simulation-----------Component-C++-----------C#
----------------------------------------system----(sequential)--(concurrent)
1,000-cars------------------------------0.04-------140------------33
10,000-cars-----------------------------0.6--------140------------out-of-memory
100,000-cars----------------------------13---------190------------out-of-memory
260,000-cars----------------------------76---------210------------out-of-memory
особо отмечены 3 момента:
1. практически линейная зависимость времени от числа машин для компонентной реализации.
2. классическая реализация сильно зависима от протяжённости маршрута
и максимального времени в пути.
3. потоки в С# реализованы отнюдь не лучшим образом
Но масштабируемость-то у классической реализации(С++) намного лучше - при увеличении количества симулируемых объектов на 2 порядка, время расчёта увеличивается менее чем в 2 раза! В то время как у компонентной системы время расчёта возрастает в 2000 раз. Ежели экстраполировать тенденцию, то для ~600,000 машин получим примерно равное время расчёта. Далее компонентная система начнёт проигрывать классической реализации.
Есть предположение, что такое поведение связано с чрезмерной иерархичностью компонентной модели, имеющей мало общего с моделью вычислителя. Избавившись от сборщика мусора(и потерь времени на него) за счёт жёсткой иерархии объектов, похоже уткнулись в реальную модель вычислителя. В кеш процессора хорошо ложатся повторно используемые объекты, а в реализации на Композите их слишком мало.
Кто, что думает?