NPPS Leadership Team

["Laycock, Paul" <laycock AT bnl.gov>]

Hi Brett,

Indeed, there is always going to be some balance of sales vs real world utility.  Model optimisation for inference time should be part of the framework and could maybe be part of the R&D?  I don’t know how much the “static inference” approach (as opposed to dynamic) has been investigated in HEP, I was prompted by my training material:

https://developers.google.com/machine-learning/crash-course/static-vs-dynamic-inference/video-lecture

I openly admit to being at the bottom of the learning curve !

I like the potential of learning a representation that captures the complexity of the data more succinctly, eventually as a path to data reduction but in the first instance you may be brave enough to use it for online data quality - get feedback inference-quick, as opposed to needing to run reconstruction.  I may have spent too much time in AI sessions though :)

Paul

On 21 May 2021, at 15:54, Brett Viren <bv AT bnl.gov> wrote:

Hi Paul,

"Laycock, Paul" <laycock AT bnl.gov> writes:

There were some talks at CHEP, ...

Thanks for these two.  Creating "semantic meaning" inside AI/ML latent
space is a particularly interesting technique especially for the
GAN-as-fast-sim application.

The UCluster talk helps solidify some thoughts for me.

tl;dr: Training and inference are two very separate problem spaces and
their dichotomy should inform our strategy.

Here's my take on that dichotomy:

- Distributed training is a "one time problem".  Each network
 architecture pattern requires its own R&D.  It is suited to HPC.

UCluster's graph-NN architecture is conceptually perfect for
distribution while a more monolithic network would have very different
challenges to distribute.  Maybe the classic GAN can put the D and the G
on two separate GPUs but further distribution must attack monoliths.
This zoology of R&D makes for good job security for CSI types but at
some point it begins to look a lot like engineering (nttiawwt).

- Distributed inference is an "all the time problem". It is a more
 general and practical problem sharing space with hyper-parameter
 optimization and accelerating heuristic algorithms (eg FFT).  It is
 suited to HTC(+GPU).

I feel this second problem is more important to actually applying AI/ML
and "getting the science out" of the data.  It may be derided as "mere
engineering" by some, but without building bridges we all get wet.

So, our meta problem is how to get funding using the sexy "one-time"
problem while actually solving the "all-the-time" problem which I think
is the real bottleneck.

-Brett.