Re: Interaction between peach and other optimisations

[rocuinneagain]

The parallelism can only go one layer deep.

.i.ie These 2 statements end up executing the same path. In the first one the inner “peach“  can only run like an `each` as it is already in a thread:

data:8#enlist til 1000000 ts {{neg x} peach x} peach data 553 1968 ts {{neg x} each x} peach data 551 1936

For queries map-reduce still will be used to reduce the memory load of your nested queries even if run inside a “peach` even if not running the sub parts in parallel.

https://code.kx.com/q4m3/14_Introduction_to_Kdb%2B/#1437-map-reduce

Where you choose to put your `peach` can be important and change the performance of your execution.

My example actually runs better without peach due to the overhead of passing data around versus `neg` being a simple operation

ts {{neg x} each x} each data 348 91498576

.Q.fc exists to help in these cases

ts {.Q.fc[{neg x};x]} each data 19 67110432

https://code.kx.com/q/ref/dotq/#fc-parallel-on-cut

And in fact since `neg` has native multithreading and operates on vectors and vectors of vectors it is best of off left on it’s own:

ts neg each data 5 67109216 
ts neg data 5 67109104 
neg data

This example of course is extreme but does show that thought and optimisation can go in to each use-case on where to choose to iterate and place `peach“