apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aditya gholba <adi...@datatorrent.com>
Subject Re: Image processing library
Date Mon, 15 May 2017 04:45:37 GMT
Hi Anath, thanks for showing interest in my project.

Currently I do not have any concrete latency measurements available but in
most cases its 1sec or lower while testing it locally on my laptop.
As you mentioned, the processing calls (overriding process method from
Toolkit ) are time consuming but none of the operators exceed the default
time out for processing an image.

Except the ASASSN operator, which is used in the telescope use case. This
operator uses a self made algorithm for image classification and hence has
high latency(trying to optimize it further) . In this scenario I have
extended the processing time for this operator using  TIMEOUT_WINDOW_COUNT
attribute as mentioned by Munagala.

Thank you for your inputs,

On 13-May-2017 9:00 AM, "Munagala Ramanath" <amberarrow@yahoo.com.invalid>

The injunction that tuple processing should be "as fast as possible" is
based on anassumption and a fact:
1. In most cases, users want to maximize application throughput.2. If a
callback (like beginWindow(), process(), endWindow(), etc.) takes too
long,   the platform deems the operator hung and restarts it.
Neither imposes a hard constraint: If, for a particular class of
applications,it is OK to sacrifice throughput to allow some CPU intensive
computations to occur,that is certainly possible; the constraint of (2) can
be relaxed by simply increasingthe TIMEOUT_WINDOW_COUNT attribute, for some
or all operators.
Secondly, nothing prevents an operator from starting worker threads that
asynchronouslyperform CPU intensive computations. Naturally, careful
synchronization will be necessarybetween the main and worker threads to
ensure correctness and timelydelivery of results.

    On Friday, May 12, 2017 6:38 PM, Ananth G <ananthg.apex@gmail.com>

  I guess the use cases as documented look really compelling. There might
be more comments from code review perspective and below is more from a use
case perspective only.

I was wondering if you have any latency measurements for the tests you ran.

If the image processing calls ( in the process function overridden from the
Toolkit class ) are time consuming it might not be an ideal use case for a
streaming engine? A very old "blog" (2012)  talks about latencies anywhere
between tens of milliseconds to almost a second depending on the use case
and image size. Of course there were hardware improvements and those
numbers might no longer hold good and hence the question (of course the
latencies depend on hardware being used as well )

This brings me to the next question in general about Apex to the community
: what is considered an acceptable tolerance level in terms of latencies
for streaming compute engine like Apex. Is there a way to tune the
acceptable tolerance level depending on the use case ? I keep reading from
the mailing lists that the aspect of tuple processing is part of the main
thread and hence should be as fast as possible.


> On 12 May 2017, at 9:05 pm, Aditya gholba <aditya@datatorrent.com> wrote:
> Hello,
> I have been working on an image processing library for Malhar and few of
> the operators are ready. I would like to merge them in Malhar contrib. You
> can read about the operators and the applications I have created so far
> here.
> <https://docs.google.com/document/d/19OrqHJ_QzbuB0XZ4bzdQ9yj
> Link to my GitHub <https://github.com/adiv2/imIO4>
> All suggestions and opinions are welcome.
> Thanks,
> Aditya.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message