London Lambdas Hackday: Performance and Parallelism

[Richard Warburton]

>> They didn't profile, they guessed what the bottleneck in their program
>> was.  This will definitely happen in real life development scenarios,
>> and I don't think many people even have sensible rules of thumb.  With
>> hindsight I should have surveyed the room to find out what percentage
>> of developer's knew what Amdahl's Law was, but nevermind.  They key
>> point is that when you make parallelism easy to obtain people will
>> attempt it without considering the consequences of their actions.
>
> This is definitely true.  Our goal here is make it easy to collect the
> low-hanging fruit; get 80% of the benefit for 5% of the work.  But, you
> still have to do *some* work -- you have to know something about the
> collection that is the source of your data, for example.

Hmm, a lot of the effort in this kind of work is measuring and
identifying what you need to change within the code.  I'd fear that
without tackling this part of the problem that you won't achieve it
being 5% of the work.  Of course that might not be work within the
scope of this JSR.

>> 2. What is the decomposition model of parallel()?
>>
>> This isn't obvious from the documentation.  Is there a cost model for
>> splitting things up?  Can people easily figure out a computational
>> cost budget between different components and work out at what point
>> there's a benefit to parallelism?
>
> Each collection should document something about its decomposition behavior,
> just as it does its iteration behavior.  The default decomposition will be
> pretty bad; we'll be lucky to not get negative speedup from parallelism on,
> say, a LinkedList.  Specific collection classes like ArrayList or TreeSet
> will provide a better decomposition.

Excellent.

>> 3. Readability of Profiling
>>
>> If you profile for execution time then you may hit a scenario where a
>> lot of your CPU time is begin eaten by a lambda.  In the build 45
>> implementation these were being compiled as anonymous inner classes,
>> which won't be the final strategy but it meant I couldn't really
>> experiment with profiling.  What will a lambda method look like when
>> displayed in a profiler?  Have you figured out a method naming
>> convention?
>
> It will be a method in the capturing class named lambda$nnn.

Hmm, that does mean that in order to find the lambda in question you
would need to count all the lambda instances within the class, which
is a potential drawback over anonymous inner classes when profiling.
It might be a drawback when debugging as well, unless you have debug
information in the compiled code that you're using in production -
which not everyone will.  Is there no chance that the name could
involve an easier reference back into the code, for example
lambda$capturingMethodName$nnn?

regards,

  Richard