Skip to content

Merge elementwise implementations#2920

Merged
emcastillo merged 17 commits intocupy:masterfrom
niboshi:refactor-elementwise
Mar 27, 2020
Merged

Merge elementwise implementations#2920
emcastillo merged 17 commits intocupy:masterfrom
niboshi:refactor-elementwise

Conversation

@niboshi
Copy link
Copy Markdown
Member

@niboshi niboshi commented Jan 7, 2020

Elementwise version of #2732.
Merges the logic of ElementwiseKernel and ufunc.

@niboshi niboshi force-pushed the refactor-elementwise branch 2 times, most recently from 768ab6a to 5ce38ca Compare January 7, 2020 19:52
@niboshi niboshi force-pushed the refactor-elementwise branch 10 times, most recently from bd51dfe to b746a0e Compare January 9, 2020 06:28
@niboshi
Copy link
Copy Markdown
Member Author

niboshi commented Jan 9, 2020

@emcastillo
I think refactoring on elementwise-kernels is finished. May I hear a brief comment on the last commit (b746a0e)?
Some code is still duplicated (e.g. _preprocess_args) because it's also used from reduction.pyx.
If basic idea is OK, I'll try to update reduction.pyx too.
Reconsideration may happen at that moment.

@emcastillo
Copy link
Copy Markdown
Member

Let me take a look

@asi1024 asi1024 self-assigned this Jan 9, 2020
@emcastillo
Copy link
Copy Markdown
Member

At first glance, the PR changes look fine and consistent.
But one of the things I am worried about is that with ufunc and elementwise being merged, it may complicate adding support for generalized functions since these can do reductions as well.

In numpy ufuncs are a special case of the generalized ufunc. (described by just the signature).
So I think that having a separated interface for the ufunc and argument checkings, signatures etc decoupled from the Elementwise kernel may keep things simpler. However, my knowledge of all these internals is limited and I am not sure of to what extent they can be a problem. @toslunar @asi1024 any comments on this?.

@niboshi
Copy link
Copy Markdown
Member Author

niboshi commented Jan 9, 2020

@emcastillo
I agree that elementwise kernels and reduction kernels can be unified.
However, as it's difficult to do that all at once, you can consider this PR as a first step toward that.
(currently I don't have a concrete idea how they all will be unified though.)

So I think that having a separated interface for the ufunc and argument checkings, signatures etc decoupled from the Elementwise kernel may keep things simpler.

I don't understand this point.
My hope is all the kernel implementations (ufunc, ElementwiseKernel, _SimpleReductionKernel, ReductionKernel) should be able to be generalized to some extent.
Could you elaborate why you think ufunc and ElementwiseKernel should be separate?

@emcastillo
Copy link
Copy Markdown
Member

emcastillo commented Jan 9, 2020

If reduction and elementwise are going to be unified then there is no problem at all 😄
My fear was that gufunc combines both elementwise and reduction and if these two are not unified then lots of code would need to be duplicated.

@emcastillo
Copy link
Copy Markdown
Member

This is a long one, so I just want to be sure that I am getting everything right.
What you have done here is:

  1. Rewrite the kernel argument managing logic and abstract it into several classes instead of raw tuples and module level functions.
  2. Create a base _AbstractElementwiseKernel that essentially groups all the ufunc related _kernel module functions.

I think it might be better to split this in two PRs, one with just _ArgKind, _ArgInfo and _TypeMap and another one with the rest of changes. But if you prefer to keep them as one PR I won't be against it.

@niboshi
Copy link
Copy Markdown
Member Author

niboshi commented Jan 9, 2020

@emcastillo
Thank you for a comment.
I think your suggestion is very right. I'll separate 1. as another PR while this PR is kept (I mean this PR will depend on it).

@emcastillo
Copy link
Copy Markdown
Member

Thanks!

@niboshi
Copy link
Copy Markdown
Member Author

niboshi commented Jan 9, 2020

Btw, _Args class will be classified in 2., as it's abstraction between ufunc and ElementwiseKernel.

@asi1024
Copy link
Copy Markdown
Member

asi1024 commented Jan 15, 2020

@niboshi Could you resolve conflicts?

@niboshi
Copy link
Copy Markdown
Member Author

niboshi commented Jan 15, 2020

@asi1024 I'm planning to rebase after #2918.

@asi1024 asi1024 added cat:code-fix Code refactoring that do not change behavior st:awaiting-author Awaiting response from author labels Jan 15, 2020
@asi1024 asi1024 added this to the v8.0.0b1 milestone Jan 28, 2020
@niboshi niboshi force-pushed the refactor-elementwise branch from b746a0e to 3e0f181 Compare January 30, 2020 14:31
@pfn-ci-bot
Copy link
Copy Markdown
Collaborator

Successfully created a job for commit 17bda99:

@chainer-ci
Copy link
Copy Markdown
Member

Jenkins CI test (for commit 17bda99, target branch master) failed with status FAILURE.

@asi1024
Copy link
Copy Markdown
Member

asi1024 commented Mar 25, 2020

Jenkins, test this please.

@pfn-ci-bot
Copy link
Copy Markdown
Collaborator

Successfully created a job for commit 7a7e582:

@chainer-ci
Copy link
Copy Markdown
Member

Jenkins CI test (for commit 7a7e582, target branch master) failed with status FAILURE.

@asi1024
Copy link
Copy Markdown
Member

asi1024 commented Mar 25, 2020

Jenkins, test this please.

@pfn-ci-bot
Copy link
Copy Markdown
Collaborator

Successfully created a job for commit 43720e1:

# scalar
arg = ScalarArg(obj)
return arg
if isinstance(obj, TextureObject):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @asi1024! Could you also include MemoryPointer in this category? I have an ongoing PR that would benefit having this. (I could also add this separately later.)

Suggested change
if isinstance(obj, TextureObject):
if isinstance(obj, (TextureObject, MemoryPointer)):

(need to import MemoryPointer first).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix it after your PR is merged. If this PR is merged before yours, please fix this line in your PR.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK no worries 👍 I am still preparing it...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your notification!

@asi1024 asi1024 changed the title [WIP] Merge elementwise implementations Merge elementwise implementations Mar 25, 2020
@chainer-ci
Copy link
Copy Markdown
Member

Jenkins CI test (for commit 43720e1, target branch master) succeeded!

@emcastillo
Copy link
Copy Markdown
Member

emcastillo commented Mar 27, 2020

Benchmarked ufuncs,

Consistent increase in CPU time from 10us to 20us
This PR

time_sqrt    :    CPU:   20.238 us   +/- 0.263 (min:   19.956 / max:   20.900) us     GPU:   24.029 us   +/- 0.731 (min:   23.264 / max:   25.504) us

Master

time_sqrt   :    CPU:   11.371 us   +/- 0.247 (min:   11.143 / max:   11.853) us     GPU:   14.662 us   +/- 1.109 (min:   13.984 / max:   17.888) us

This time diff holds for all ufuncs, elementwise kernels, reduction and raw kernels.

Copy link
Copy Markdown
Member

@emcastillo emcastillo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

After discussing offline, we agreed to merge this PR now, as it is a blocker of other PRs.
We will investigate the reasons behind the performance degradation and address them after merging it.

@emcastillo emcastillo added st:test-and-merge (deprecated) Ready to merge after test pass. and removed st:test-and-merge (deprecated) Ready to merge after test pass. labels Mar 27, 2020
@emcastillo emcastillo merged commit ba7caa4 into cupy:master Mar 27, 2020
@niboshi niboshi deleted the refactor-elementwise branch March 27, 2020 10:54
emcastillo pushed a commit to emcastillo/cupy that referenced this pull request Apr 21, 2020
@kmaehashi
Copy link
Copy Markdown
Member

Reverted in #3296 for performance issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cat:code-fix Code refactoring that do not change behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants