[kepler-dev] Re: [Ptolemy] largest number of actors in a Ptolemy II model

Edward A Lee eal at eecs.berkeley.edu
Fri Aug 6 05:31:45 PDT 2004


While I think we aren't doing too badly here, given how little attention
we have put into scaling up these models, I should point out that
people at The Mathworks tell me they are grappling with handling their
first million-block Simulink models...

The actor-oriented class mechanism and the higher-order components
make it much easier to create large models, and we could start seeing
serious performance issues if we don't put some attention into optimizing
for scalability.

Edward


At 03:33 PM 8/5/2004 -0700, Christopher Brooks wrote:
>Well, I hacked up actor/lib/test/Ramp.tcl to create
>
>Ramp -> Scale0 -> ScaleN ... -> Recorder models
>
>Below are the run times on a Dell Precision 650 with 4Gb of memory and
>two 3.06Ghz CPUs running Linux
>
>For each test, I created N+1 Scale actors
>
>I report the time in microseconds that ptjacl reports the model
>creation took.  Ignore the 'per iteration to create', this
>comes from the ptjacl time command.  In the first example,
>it took 21000 microseconds or 21 milliseconds to create the
>5 actor model
>
>Each model is a sdf model run for 5 iterations.
>Then I run the model 4 times to take advantage of the JIT.
>
>5 actors
>21000 microseconds per iteration to create
>29 ms. Memory: 1984K Free: 895K (45%)
>17 ms. Memory: 1984K Free: 715K (36%)
>15 ms. Memory: 1984K Free: 537K (27%)
>13 ms. Memory: 1984K Free: 866K (44%)
>
>50 actors
>136000 microseconds per iteration to create
>136 ms. Memory: 1984K Free: 439K (22%)
>108 ms. Memory: 2340K Free: 841K (36%)
>73 ms. Memory: 2340K Free: 931K (40%)
>69 ms. Memory: 2340K Free: 611K (26%)
>
>500 actors
>7825000 microseconds per iteration to create
>849 ms. Memory: 6648K Free: 2031K (31%)
>517 ms. Memory: 8504K Free: 3614K (42%)
>405 ms. Memory: 8504K Free: 1696K (20%)
>466 ms. Memory: 8504K Free: 2668K (31%)
>
>750 actors
>35645000 microseconds per iteration to create
>1035 ms. Memory: 11180K Free: 1467K (13%)
>703 ms. Memory: 13420K Free: 3248K (24%)
>696 ms. Memory: 16872K Free: 6560K (39%)
>598 ms. Memory: 16872K Free: 4178K (25%)
>
>1000 actors
>117586000 microseconds per iteration to create
>1263 ms. Memory: 19480K Free: 3484K (18%)
>952 ms. Memory: 25160K Free: 9982K (40%)
>807 ms. Memory: 25160K Free: 6203K (25%)
>807 ms. Memory: 25160K Free: 878K (3%)
>
>
>The model creation time is rather poor:
>
>21000/5      =     4200 microseconds/actor
>135000/50    =     2700 microseconds/actor
>7863000/500  =    15726 microseconds/actor
>35645000/750 =    47526 microseconds/actor
>117586000/1000 = 117586 microseconds/actor
>
>Perhaps the increase in time was because ptjacl is not very good at
>loops.
>
>Exporting the 500 actor model as moml and
>then running it using MoMLSimpleApplication:
>
>time $PTII/bin/ptinvoke ptolemy.actor.gui.MoMLSimpleApplication 500.xml
>
>yields the following results:
>
>820 ms. Memory: 6080K Free: 1925K (32%)
>2.690u 0.070s 0:03.34 82.6%     0+0k 0+0io 2985pf+0w
>
>This is a 3.34 second total runtime to parse a 500 actor model
>and then run it.  This is reasonably close to the 7.825 seconds
>necessary to create the model under ptjacl.
>
>I hacked up a 1000 actor model by splicing two 500 actor models
>together, and it took 6.29 seconds to open and run, so this is not too
>bad, it is quite a bit better than the 117 seconds reported by ptjacl.
>I'm not totally sure about my 1000 actor model, more work could be
>done here.
>
>It would be interesting to check this by trying something with
>higher order components.
>
>The runtimes do not look so bad though.  The are roughly 0(N)
>
>We can now claim that a model with 1000 actors has been run.
>
>You can download my 500 actor model from:
>http://ptolemy.eecs.berkeley.edu/~cxh/tmp/models/500.xml
>
>Opening it in Vergil is a little painful, but it works
>
>
>-Christopher
>
>--------
>
>     Steve beat me to it, but here are my thoughts:
>
>     Well, to paraphrase Mark Twain, who attributed the quote to Disraeli:
>     "There are lies, damn lies and Ptolemy statistics"
>
>     As a quick hack, I counted the number of "<entity" strings in some
>     models.  This is not a perfect measure, but it is a start.
>
>     It looks like one of the models that we do not distribute has 711
>     entities.  The counts for that model and others are below:
>
>      711 
> ./ptolemy/domains/wireless/demo/MACProtocolModel/MACProtocolModel.xml
>      276 
> ./ptolemy/domains/gr/lib/experimental/demo/InverseKinematics/InverseKi
>    nematics.xml
>      196 ./ptolemy/domains/gr/lib/experimental/demo/pickstates/pickstates.xml
>      175 ./ptolemy/domains/gr/lib/experimental/IKsimple.xml
>      148 ./ptolemy/domains/gr/lib/experimental/demo/RobotArm/RobotArm.xml
>      135 ./ptolemy/domains/gr/lib/experimental/lynxArm.xml
>      120 ./ptolemy/domains/gr/lib/experimental/demo/microwave/microwave.xml
>
>     We don't distribute the models above in the release, but the models
>     below are shipped:
>
>      102 ./ptolemy/domains/gr/demo/StickyMasses/StickyMasses.xml
>      100 ./ptolemy/domains/gr/demo/FurutaPendulum/FurutaPendulum.xml
>       96 ./ptolemy/domains/hde/test/auto/SOC_Sobel_FSM_HDE.xml
>
>
>     ptolemy/apps has some largish models as well:
>      571 ptolemy/apps/etherealSting/E2/classifierNchannels.xml
>      570 ptolemy/apps/etherealSting/E2/classifierNchannelsWithOutput.xml
>      565 ptolemy/apps/etherealSting/E2/classifierNchannelsNoPlots.xml
>      348 ptolemy/apps/anytimecontrol/CompareControllers.xml
>      236 ptolemy/apps/crazyboard/crazyboardModelLQRGiotto.xml
>      229 ptolemy/apps/crazyboard/crazyboardModelDE4.xml
>      228 ptolemy/apps/crazyboard/crazyboardModelModalLQR.xml
>      224 ptolemy/apps/crazyboard/crazyboardModelLQRWithGraphicImage.xml
>      223 ptolemy/apps/crazyboard/crazyboardModelLQRWithGraphics.xml
>      221 ptolemy/apps/crazyboard/crazyboardModelLQR.xml
>
>     To get these numbers, I used
>     find . -xdev -name "*.xml" -exec ls -s {} \; > /tmp/f2
>     grep "<entity" `awk '{print $2}' /tmp/f2` | gawk -F : '{print $1}' > 
> /tmp/e
>    ntity2
>     uniq -c /tmp/entity2 | sort -nr | head
>
>     The number of actors could get a little strange when we consider
>     classes and such.
>
>     I think it would be fairly straightforward to automatically construct
>     large trivial models that used lots of actors using
>     Ramp -> Scale -> Scale ... ->Display
>     However, I'm not sure what such a model would prove, since it is an
>     artificial measurement.
>
>     I seem to remember that this paper:
>     Jozsef Ludvig, James McCarthy, Stephen Neuendorffer, and Sonia
>     R. Sachs, "Reprogrammable Platforms for High-speed Data Acquisition,"
>     Thirty-Fifth Asilomar Conference on Signals, Systems, and Computers,
>     Asilomar Hotel Conference Grounds, November 4-7, 2001.
>     http://ptolemy.eecs.berkeley.edu/publications/papers/01/Asilomar/
>     had some really big models.
>
>     I've seen models of around 2Mb in size, though this was before the
>     class mechanism was implemented, so the size would likely be smaller
>     now.
>
>
>     -Christopher
>
>     --------
>
>
>         Hi:
>
>         Can anyone give me an estimate about the largest model (#actors) in a
>         Ptolemy II model that has been done? (maybe with reference)
>
>         thanks!
>
>         Bertram
>         _______________________________________________
>         Ptolemy maillist  -  Ptolemy at chess.eecs.berkeley.edu
>         http://chess.eecs.berkeley.edu/ptolemy/listinfo/ptolemy
>     --------
>     _______________________________________________
>     Ptolemy maillist  -  Ptolemy at chess.eecs.berkeley.edu
>     http://chess.eecs.berkeley.edu/ptolemy/listinfo/ptolemy
>--------
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal




More information about the Kepler-dev mailing list