Hi, folks
We were discussing improvements for the threading engine back in May and agreed
to implement benchmarks (sorry, I've lost the original mail thread, here is the
link:
https://lists.apache.org/thread.html/c690253d0bde643a5b644af70ec1511c6e510ebc86cc970aa8d5252e@%3Cdev.arrow.apache.org%3
> From: Jed Brown [mailto:j...@jedbrown.org]
> Sent: Monday, May 6, 2019 16:35
> Nice paper, thanks! Did you investigate latency impact from the IPC counting
> semaphore? Is your test code available?
Not that deep. Basically I was looking only if its positive effect is enough to
overcome the im
Jed,
> From: Jed Brown [mailto:j...@jedbrown.org]
> Sent: Friday, May 3, 2019 12:41
> You linked to a NumPy discussion
> (https://github.com/numpy/numpy/issues/11826) that is encountering the same
> issues, but proposing solutions based on the global environment.
> That is perhaps acceptable for
Thanks for your answers,
> -Original Message-
> From: Antoine Pitrou [mailto:anto...@python.org]
> Sent: Friday, May 3, 2019 03:54
> Le 03/05/2019 à 05:47, Jed Brown a écrit :
> > I would caution to please not commit to the MKL/BLAS model in which
I'm actually talking about threading laye
he abstract.
Thanks
Wes
On Tue, Apr 30, 2019 at 9:28 PM Malakhov, Anton
wrote:
>
> Hi dear Arrow developers, Antoine,
>
> I'd like to kick off the discussion of the threading engine that Arrow can
> use underneath for implementing multicore parallelism for execution nodes,
Hi dear Arrow developers, Antoine,
I'd like to kick off the discussion of the threading engine that Arrow can use
underneath for implementing multicore parallelism for execution nodes, kernels,
and/or all the functions, which can be optimized this way.
I've documented some ideas on Arrow's Confl
