Okay I do have some more input here 
@benwilson512 @scouten there is a second misconception here, :parallel doesn’t really batch in that sense.
If parallel: 4 then 4 processes will be spawned that all execute the same function for the given time. When these finish/the time is up 4 new processes will be spawned for the next scenario
The 4 processes just dutifully call their function for the specified :time - each as often as they can, no waiting nothing. The new scenario refers to if there’s either another input or another function being benchmarked. So there’s no “waiting” effect to account for.
At it’s core benchee uses the most naive parallel map for this:
def map(collection, func) do
collection
|> Enum.map(fn element -> Task.async(fn -> func.(element) end) end)
|> Enum.map(&Task.await(&1, :infinity))
end
And later on they are simply flat_map’ed:
run_times = Enum.flat_map(measurements, fn {run_times, _} -> run_times end)
memory_usages = Enum.flat_map(measurements, fn {_, memory_usages} -> memory_usages end)
As for how do we get to the total “throughput” - just multiplying the IPS with the number of parallel processes should be more or less okay. It will be slightly inaccurate due to different abort times but with a high enough sample size it shouldn’t matter.
If you really wanted to see your parallel throughput in my opinion you should provide the parallelism, because that’s a crucial part performance wise. Our naive implementation works for us but as I said it’s rather naive, things like Task.async_stream ore more advanced things are a better choice for all that I know 
All that said, I’m contemplating the display of a “throughput” when parallel is used in benchee now but I’m a bit torn on it. I’ll have to meditate on it, I’ll try to make the docs even clearer on the existing option. It’s powerful and was very easy to add, but seemingly sadly has sometimes done more harm than good.
) To see how it affects the sample size I still recommend 
