You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Andrew Pilloud <ap...@google.com> on 2022/06/13 19:22:44 UTC
Beam Java DoFn Performance (and Auto-Vectorization)
I ran some experiments with our existing DoFn API trying to get the Java
JIT to Auto-Vectorize DoFn ProcessContext calls. Unfortunately that was
unsuccessful, it appears we will need a new Returning DoFn API to support
Auto-Vectorization (in addition to coder and runner changes).
I also found that function calls through Java interfaces can be relatively
expensive and will not work with many optimizations supported by the Java
JIT. Our DoFn calling convention involves several layers of these interface
calls. I am proposing we add an interface to Beam Core to generate
flattened DoFn calls to concrete types, which would reduce our calling
overhead and allow the JIT to perform inlining optimization across DoFns.
Please take a look and provide feedback:
https://docs.google.com/document/d/12XkHLcE0HpOS0fs0FekDzh68fMPCEZ5uGCh00kPZf0I/edit
(If you are interested in this, it is one of the topics we will discuss at
our Beam Summit talk "Relational Beam: Process columns, not rows!"
<https://2022.beamsummit.org/sessions/relational-beam/>. Hope to see
everyone there!)
Andrew
Re: Beam Java DoFn Performance (and Auto-Vectorization)
Posted by Kenneth Knowles <ke...@apache.org>.
Love it. Seems like there are some serious barriers to getting likely
benefit for a random pipeline, but for a user who knew and wanted to be
sure they got the benefit it could be really good (basically by programming
Java like it is garbage collected C :-)
Really useful to see how counters are a huge cost, probably bigger than
needed. And the takeaway that choosing the more general case of "multiple
outputs per input and multiple receivers of those outputs" adds a lot of
overhead that could be avoided.
Kenn
On Tue, Jun 21, 2022 at 2:35 PM Robert Bradshaw <ro...@google.com> wrote:
> This looks like some great analysis. Commented on the doc.
>
> On Mon, Jun 13, 2022 at 12:54 PM Robert Burke <ro...@frantil.com> wrote:
> >
> > Fascinating!
> >
> > I ran through a similar exercise for the Go SDK when I was fixing the
> batch Load Tests, but optimizing some specialized DoFn execution nodes
> calls for DoFns that don't observe windows, or return
> >
> > For comparison, the Go SDK already has a Returning DoFn as you call it,
> but I found that emitting was lower overhead than Returning. That could
> change as we use Go Generics and the Go Compiler to enable similar technics
> for simple DoFns as you've described in your doc for Java's JIT. All the
> necessary abstraction adds up.
> >
> >
> > On Mon, Jun 13, 2022, 12:23 PM Andrew Pilloud <ap...@google.com>
> wrote:
> >>
> >> I ran some experiments with our existing DoFn API trying to get the
> Java JIT to Auto-Vectorize DoFn ProcessContext calls. Unfortunately that
> was unsuccessful, it appears we will need a new Returning DoFn API to
> support Auto-Vectorization (in addition to coder and runner changes).
> >>
> >> I also found that function calls through Java interfaces can be
> relatively expensive and will not work with many optimizations supported by
> the Java JIT. Our DoFn calling convention involves several layers of these
> interface calls. I am proposing we add an interface to Beam Core to
> generate flattened DoFn calls to concrete types, which would reduce our
> calling overhead and allow the JIT to perform inlining optimization across
> DoFns.
> >>
> >> Please take a look and provide feedback:
> https://docs.google.com/document/d/12XkHLcE0HpOS0fs0FekDzh68fMPCEZ5uGCh00kPZf0I/edit
> >>
> >> (If you are interested in this, it is one of the topics we will discuss
> at our Beam Summit talk "Relational Beam: Process columns, not rows!". Hope
> to see everyone there!)
> >>
> >> Andrew
>
Re: Beam Java DoFn Performance (and Auto-Vectorization)
Posted by Robert Bradshaw <ro...@google.com>.
This looks like some great analysis. Commented on the doc.
On Mon, Jun 13, 2022 at 12:54 PM Robert Burke <ro...@frantil.com> wrote:
>
> Fascinating!
>
> I ran through a similar exercise for the Go SDK when I was fixing the batch Load Tests, but optimizing some specialized DoFn execution nodes calls for DoFns that don't observe windows, or return
>
> For comparison, the Go SDK already has a Returning DoFn as you call it, but I found that emitting was lower overhead than Returning. That could change as we use Go Generics and the Go Compiler to enable similar technics for simple DoFns as you've described in your doc for Java's JIT. All the necessary abstraction adds up.
>
>
> On Mon, Jun 13, 2022, 12:23 PM Andrew Pilloud <ap...@google.com> wrote:
>>
>> I ran some experiments with our existing DoFn API trying to get the Java JIT to Auto-Vectorize DoFn ProcessContext calls. Unfortunately that was unsuccessful, it appears we will need a new Returning DoFn API to support Auto-Vectorization (in addition to coder and runner changes).
>>
>> I also found that function calls through Java interfaces can be relatively expensive and will not work with many optimizations supported by the Java JIT. Our DoFn calling convention involves several layers of these interface calls. I am proposing we add an interface to Beam Core to generate flattened DoFn calls to concrete types, which would reduce our calling overhead and allow the JIT to perform inlining optimization across DoFns.
>>
>> Please take a look and provide feedback: https://docs.google.com/document/d/12XkHLcE0HpOS0fs0FekDzh68fMPCEZ5uGCh00kPZf0I/edit
>>
>> (If you are interested in this, it is one of the topics we will discuss at our Beam Summit talk "Relational Beam: Process columns, not rows!". Hope to see everyone there!)
>>
>> Andrew
Re: Beam Java DoFn Performance (and Auto-Vectorization)
Posted by Robert Burke <ro...@frantil.com>.
Fascinating!
I ran through a similar exercise for the Go SDK when I was fixing the batch
Load Tests, but optimizing some specialized DoFn execution nodes calls for
DoFns that don't observe windows, or return
For comparison, the Go SDK already has a Returning DoFn as you call it, but
I found that emitting was lower overhead than Returning. That could change
as we use Go Generics and the Go Compiler to enable similar technics for
simple DoFns as you've described in your doc for Java's JIT. All the
necessary abstraction adds up.
On Mon, Jun 13, 2022, 12:23 PM Andrew Pilloud <ap...@google.com> wrote:
> I ran some experiments with our existing DoFn API trying to get the Java
> JIT to Auto-Vectorize DoFn ProcessContext calls. Unfortunately that was
> unsuccessful, it appears we will need a new Returning DoFn API to support
> Auto-Vectorization (in addition to coder and runner changes).
>
> I also found that function calls through Java interfaces can be relatively
> expensive and will not work with many optimizations supported by the Java
> JIT. Our DoFn calling convention involves several layers of these interface
> calls. I am proposing we add an interface to Beam Core to generate
> flattened DoFn calls to concrete types, which would reduce our calling
> overhead and allow the JIT to perform inlining optimization across DoFns.
>
> Please take a look and provide feedback:
> https://docs.google.com/document/d/12XkHLcE0HpOS0fs0FekDzh68fMPCEZ5uGCh00kPZf0I/edit
>
> (If you are interested in this, it is one of the topics we will discuss at
> our Beam Summit talk "Relational Beam: Process columns, not rows!"
> <https://2022.beamsummit.org/sessions/relational-beam/>. Hope to see
> everyone there!)
>
> Andrew
>