ARROW-17871: [Go] initial binary arithmetic implementation#14255
ARROW-17871: [Go] initial binary arithmetic implementation#14255zeroshade merged 11 commits intoapache:masterfrom
Conversation
| return getSSE4ArithmeticBinaryNumeric[T](op) | ||
| } | ||
|
|
||
| return getGoArithmeticBinaryOpsFloating[T](op) |
There was a problem hiding this comment.
I'm curious, why not also compile this one from C++? 1) the C++ optimizer is probably better than the Go one, 2) less code to write and maintain?
There was a problem hiding this comment.
The fallback pure-go implementation is needed for various cases and as of Go1.19, Go still can't inline assembly implemented functions. So it's worthwhile to fallback to the pure-go implementations when we aren't benefiting from the SIMD implementations to allow for whatever optimizations Go can do and so on along with portability.
There was a problem hiding this comment.
As you prefer, though you might want compare the relative performance of those different implementations :-)
| func ensureDictionaryDecoded(vals ...arrow.DataType) { | ||
| for i, v := range vals { | ||
| if v.ID() == arrow.DICTIONARY { | ||
| vals[i] = v.(*arrow.DictionaryType).ValueType |
There was a problem hiding this comment.
For the record, where does the actual dictionary decoding happen? (add a comment?)
There was a problem hiding this comment.
currently it's not implemented and will return an ErrNotImplemented before it gets here, but when I implement it i'll update this with a comment.
|
@pitrou Can you re-review when you get a chance and let me know if there's any other changes you request / if you're good with the current version? |
|
@cyb70289 any other comments or questions here? |
|
Anyone familiar enough with It looks like something is having an issue downloading the standard packages. |
|
I restarted the failed build. |
|
@pitrou looks like it still failed to load those packages via mingw which then caused the test failures. The error |
|
It looks like the current failure on the mingw64 cgo build is attributable to an existing issue with the MSYS2 mingw64 build having an issue loading libaws dlls and not something caused by the Go changes. So it is unrelated here but should likely be looked into. It's most likely related to awslabs/aws-c-io@550e319 due to the following erors:
|
|
Similar error from Windows MinGW 64 C++ job.
|
|
I think that this is related to MSYS2:
BTW... |
|
@kou If you add the mingw64 path to your System level path, reboot, and then try running an exe through the Run Dialog (windows key+R) or through file explorer, then it'll give you those error messages as popup dialog boxes. I don't know how to get it to do so from the command line unfortunately. But this worked out pretty well! 😄 |
|
@pitrou if you don't have any objections, i'll merge this tomorrow. |
|
Can we wait until after the 10.0.0 release? Or will this only be in 11.0.0? |
|
Question: is it useful to have both |
|
@pitrou The plan is that this would only go to 11.0.0, the maint-10.0.0 branch was already created right? So merges to master won't get included in the RC?
Yes, the latter is generated from the former, able to be regenerated via The latter must be kept around as it needs to be accessible when a user runs |
Oh, you're right. Nevermind. |
Thanks!!! It's what I want to know!!! |
Only implements Addition and Subtraction for integral types and float32/float64. Temporal types and others will come afterwards.