[kepler-dev] best practices for minimizing process start-up latency?

Christopher Brooks cxh at eecs.berkeley.edu
Fri Jan 10 09:20:56 PST 2014


Hi Rich,

My responses are below.

On 1/9/14 6:26 PM, Rich Morin wrote:
> I have some programs (eg, PDE solvers, FEM tools) that I'm interested
> in using as part of a Kepler application.  Looking in the Kepler docs,
> it appears that I can use fairly arbitrary command-line programs as
> actors, either for control or processing.  Works for me!
>
> However, I'm not sure what behavior and features I can depend on.  I
> am an old hand at Unix, but quite new to Java and its ecology, aside
> from playing around with Clojure.  (Any other Clojurists here? :-)
>
> More generally, I'm hoping that many of the things I'll need to do are
> covered by best practices, helpers, etc.  So, if anyone here can offer
> advice, caveats, pointers, or other comments, please do!
>
> -r
>
>
> The following questions all have to do with the facility that allows
> command-line programs (etc) to be run as actors.
>
> Q:  Is it based on something like the system(2) call?
>
>      If so, the command string cannot use shell extensions
>      (eg, aliases, functions, shell variables, wildcards).
The Ptolemy Exec actor invokes Java's Runtime.exec(), which is documented at
http://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#exec%28java.lang.String,%20java.lang.String[],%20java.io.File%29

I'm not sure how java.lang.Runtime.exec() is implemented, but it 
probably calls system(2) on Mac OS X and Linux.  Under Windows, it 
probably calls something equivalent.  One thing to do is to invoke the a 
shell program like bash
>
> Q:  Can shell scripts be used as actors?
>
>          :
>          echo 'Hello from Bash'
I'm not sure if invoking a shell script that has a first line that like 
#!/bin/sh would work.
It should be possible to have an actor that invokes /bin/bash myShellScript.
>
> Q:  Can interpreted (eg, shebang-based) scripts be used as actors?:
>
>          #!/usr/bin/env ruby
>          puts 'Hello from Ruby'
>
>      FWIW, a quick test using time(1) on a 2.8 MHz Mac Pro indicates
>      that the above script takes 0.137 seconds on the first run, but
>      only 0.007 seconds thereafter.
I think the actor would need to invoke ruby and then pass in the 
filename.   It could be that "/bin/bash myRubyScript" would work.

Timing Java can be tricky.  I use
java -classpath $PTII ptolemy.actor.gui.MoMLSimpleStatisticalApplication 
Foo.xml

Typically, the first runtime is longer because the Java process is 
getting paged in.  Successive runs are faster.  Running without the 
graphical display is important.
>
> Q:  Is MoML all that is needed (in general) to specify the command
>      name, parameters, I/O mappings, etc?
The ptolemy.actor.lib.Exec actor should be sufficient, but there are 
probably limitations somewhere.
>
> The following questions have to do with the inter-actor "piping"
> and best practices for command debugging and optimization.
>
> Q:  Can I add recording and/or archiving as attributes to a pipe?
>
>      So, for example, could I tell Kepler to turn on recording for
>      particular pipes, without needing to explicitly add an actor?
>      (This could be used for "tracing" key paths in an app.)

I don't know of an actor that has access to pipes.  It sounds like an 
interesting actor.  I'm not sure how to get access to a pipe from within 
Java.  A quick search for "java named pipes" shows some possibilities.
>
> Q:  What is the Best Practice for using a server (farm)?
>
>      If a command has a substantial internal start-up time, I may
>      want to run it on a server, but still access it as an actor.
>
>      At the PII conference, there was a talk about using REST to
>      access servers.  Is this the current Best Practice?  FWIW,
>      a Ruby script could also interrogate a daemon, but there may
>      be some built-in (eg, MoML) facility I'm simply missing.

Yes, we are using REST to access servers.  This is our current choice.

We are working with models that are web services.  One limitation is 
that the web service model needs to have access to a display if the 
model is graphical.  Under Linux, I use Xvfb to create a headless X11 
display.  The Web Services chapter of the Ptolemy book 
(http://ptolemy.eecs.berkeley.edu/books/Systems/chapters/WebInterfaces.pdf) 
discusses the details.

There are XMPP actors in org/ptolemy/ptango/lib/xmpp

We have models that read data from an XMPP source.  For example 
org/ptolemy/ptango/demo/SensorAndrew/SensorAndrew.xml reads sensor data 
from a web service.


> Q:  If you have read this far, you are probably fairly expert at
>      Kepler and/or Ptolemy.  If this is the case, and you are open
>      to occasional consulting, please drop me a line, offlist.

Thanks, I'm happy to answer questions on line, but my plate is full.

_Christopher
>
>   --
> http://www.cfcl.com/rdm           Rich Morin           rdm at cfcl.com
> http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841
>
> Software system design, development, and documentation
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev


-- 
Christopher Brooks, PMP                       University of California
Academic Program Manager & Software Engineer  US Mail: 337 Cory Hall
CHESS/iCyPhy/Ptolemy/TerraSwarm               Berkeley, CA 94720-1774
cxh at eecs.berkeley.edu, 707.332.0670           (Office: 545Q Cory)



More information about the Kepler-dev mailing list