Re: anyone run a profiler on EMC?

[Fred Proctor <proctor-at-cme.nist.gov>]

Doug Fortune wrote:

> Is profiling being done on the executable to determine
> which subroutines have the greatest impact on speed?

We did some profiling with TestCenter (that's what the .tc executables
are in the emc/src/emctask/Makefile), and Tom Kramer, the G code
interpreter writer, ran profiling on the interpreter, but I'm sure there
can be some optimization. If you want (hint), run the Gnu profiler
(gprof?) and see what you come up with.

I believe that the code within each executable (emctask, emcio, emcmot)
is OK; the bottleneck is in the communication between them. This won't
show up on profiling.

In particular, I tried running contouring programs on a version of the
EMC that uses a segment queueing algorithm written by a guest
researcher. This is the emcsegmot stuff in emc/src/emcmot/Makefile. We
had to reduce the emctask cycle time to "zero", meaning run in a
full-out loop with no Unix sleeps, to get to about 300 blocks per
second. The execution sequence within emctaskmain.cc drops between
several points where the G code line is read, the preconditions are
looked at, the message is sent, the postconditions are looked at, and
the next line is read. There is undoubtedly a more efficient way to do
this, short of full-out execution with no sleeps.

The communication between emctask and emcmot also affects throughput.
It's done via shared memory using split data detection, and this affects
throughput in a nondeterministic way.

--Fred