[ 
https://issues.apache.org/jira/browse/ARROW-8792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wes McKinney updated ARROW-8792:
--------------------------------
    Description: 
I'm working on a significant revamp of the way that kernels are implemented in 
the project as discussed on the mailing list. PR to follow within the next week 
or sooner

A brief list of features:

* Kernel selection that takes into account the shape of inputs (whether Scalar 
or Array, so you can provide an implementation just for Arrays and a separate 
one just for Scalars if you want)
* More customizable / less monolithic type-to-kernel dispatch
* Standardized C++ function signature for kernel implementations (rather than 
every one being a little bit special)
* Multiple implementations of the same function can coexist (e.g. with / 
without SIMD optimizations) so that you can choose the one you want at runtime
* Browsable function registry (see all available kernels and their input type 
signatures)
* Central code path for type-checking and argument validation
* Central code path for kernel execution on ChunkedArray inputs

There's a lot of JIRAs in the backlog that will follow from this work so I will 
attach those to this issue for visibility but this issue will cover the initial 
refactoring work to port the existing code to the new framework without 
altering existing features.

  was:
I'm working on a significant revamp of the way that kernels are implemented in 
the project as discussed on the mailing list. PR to follow within the next week 
or sooner

A brief list of features:

* Kernel selection that takes into account the shape of inputs (whether Scalar 
or Array, so you can provide an implementation just for Arrays and a separate 
one just for Scalars if you want)
* More customizable / less monolithic type-to-kernel dispatch
* Standardized C++ function signature for kernel implementations (rather than 
every one being a little bit special)
* Browsable function registry (see all available kernels and their input type 
signatures)
* Central code path for type-checking and argument validation
* Central code path for kernel execution on ChunkedArray inputs

There's a lot of JIRAs in the backlog that will follow from this work so I will 
attach those to this issue for visibility but this issue will cover the initial 
refactoring work to port the existing code to the new framework without 
altering existing features.


> [C++] Improved declarative compute function / kernel development framework, 
> normalize calling conventions
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: ARROW-8792
>                 URL: https://issues.apache.org/jira/browse/ARROW-8792
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: C++
>            Reporter: Wes McKinney
>            Assignee: Wes McKinney
>            Priority: Major
>             Fix For: 1.0.0
>
>
> I'm working on a significant revamp of the way that kernels are implemented 
> in the project as discussed on the mailing list. PR to follow within the next 
> week or sooner
> A brief list of features:
> * Kernel selection that takes into account the shape of inputs (whether 
> Scalar or Array, so you can provide an implementation just for Arrays and a 
> separate one just for Scalars if you want)
> * More customizable / less monolithic type-to-kernel dispatch
> * Standardized C++ function signature for kernel implementations (rather than 
> every one being a little bit special)
> * Multiple implementations of the same function can coexist (e.g. with / 
> without SIMD optimizations) so that you can choose the one you want at runtime
> * Browsable function registry (see all available kernels and their input type 
> signatures)
> * Central code path for type-checking and argument validation
> * Central code path for kernel execution on ChunkedArray inputs
> There's a lot of JIRAs in the backlog that will follow from this work so I 
> will attach those to this issue for visibility but this issue will cover the 
> initial refactoring work to port the existing code to the new framework 
> without altering existing features.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to