Hi Richard,
We have an SDF model that has the following size.
     AtomicEntities: 12920
     CompositeEntities: 1642
     Relations: 22415
     Attributes: 65331
so, it is possible to build large models in Ptolemy II.  I think this
model got up to about 19k AtomicEntities. 

However, it takes quite a bit of time in to open the model and in
prefire() because the model uses level crossing links.

The bottom of ptII/ptolemy/actor/lib/test/Ramp.tcl includes 
some tests that create 500 scale actors in a SDF model and then run the
model.  In that case, the 500 actor model takes about 12 seconds
to build a less than two seconds to run the first time

A 1000 actor model takes 97 seconds to build and again about two
seconds to run the first time. 


To replicate this, use these commands:
  cd $PTII/ptolemy/actor/lib/test
  $PTII/bin/ptjacl
  source Ramp.tcl
  manyScales 500 1.00000001
  manyScales 1000 1.00000001

Which gives us this output:

% manyScales 500 1.00000001
500 actors
12270000 microseconds per iteration to create
877 ms. Memory: 84544K Free: 51413K (61%)
143 ms. Memory: 84544K Free: 47201K (56%)
129 ms. Memory: 84544K Free: 42990K (51%)
131 ms. Memory: 84544K Free: 37374K (44%)
0.0 1.0000049900124 2.0000099800248 3.0000149700372 4.0000199600496

% manyScales 1000 1.00000001
1000 actors
97404000 microseconds per iteration to create
1928 ms. Memory: 107136K Free: 88163K (82%)
283 ms. Memory: 107136K Free: 77968K (73%)
273 ms. Memory: 107136K Free: 69473K (65%)
273 ms. Memory: 107136K Free: 59231K (55%)
0.0 1.0000099900498 2.0000199800996 3.0000299701494 4.0000399601992

So, it would appear that we have a problem, it would be nice if
the 1000 actor model took 2x the time of the 500 actor model.
Interestingly, the runtime is very well behaved, after the first
run, the 1000 actor run is just over 2x the time of 500 actor run.

See also ptII/doc/coding/performance.htm

I suspect that the problem is with the DE domain.  I can take a look
at replicating this, but it might be a day or two.

If you have a test case, then that would help.

_Christopher
--------

      Hi, folks.  I'm trying to create a model in the DE domain with 
    thousands of actors.

    I'm creating the model, and running it, by writing Java code; I'm
    not doing anything graphical at all.  All the actors are instances
    of the same Java class that extends DEActor.  Each actor has one
    input and one output, each with about four channels connecting to
    other actors (except for a few actors at the "beginning edge" and
    "ending edge" of the graph, which have no input channels and no
    output channels, respectively).
    
      What confuses me and alarms me is that, while the code (step 1)
    to instantiate the actors and the code (step 3) to run the model
    executes in a reasonable amount of time, the code (step 2) to wire
    together all the actors' inputs and outputs takes an amazing
    amount of time!  I'm trying my program with a steadily larger and
    larger number of actors, and doubling the number of actors causes
    the time for Step 2 to multiply 8 times!  For example, with 1,000
    actors, it took 186 milliseconds to instantiate them, 9 minutes
    and 35 seconds to wire them, and 2 minutes to run the simulation.
    
      I've stepped through my own code, and the Ptolemy code, trying
    to find which code might be taking a long time during link-wiring,
    and I've gotten some glimpses.  For one thing, every time you add
    one new link to a model, Ptolemy does a lot of rechecking of the
    graph topology and model integrity--that makes me wish there were
    a version of method CompositeEntity.connect( ComponentPort,
    ComponentPort ) that would take a bunch of links, add them all in,
    <I>then</i> check model integrity.  Also, it looks to me like some
    of the checking may be related to checking the model's safety for
    modification while it's running.  I don't want to modify it while
    it's running; is there a way for me to configure something to
    signify that, so that Ptolemy won't check the model so thoroughly?
    
      About the only other glimpse I've gotten is that method
    DEDirector._computePortDepth() seems to take up a lot of time.
    
      Of course I will appreciate any information or advice you can give me
    and how to make linking take less time.
    
         Respectfully,
    
         Richard Ware
    
    
    ---------------------------------------------------------------------------
   -
    Posted to the ptolemy-hackers mailing list.  Please send administrative
    mail for this list to: [EMAIL PROTECTED]
--------

----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Reply via email to