Skip to content

Fp16 print fix #2784

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 25, 2020
Merged

Fp16 print fix #2784

merged 2 commits into from
Mar 25, 2020

Conversation

syurkevi
Copy link
Contributor

@syurkevi syurkevi commented Mar 4, 2020

Adds missing print in array_to_string.
Also checks if half type is supported during array creation in cuda backend.

!isHalfSupported(getActiveDeviceId())) {
AF_ERROR("Half precision not supported", AF_ERR_NO_HALF);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

I think we should move this to src/backend/common or src/api/c since this can be used from other locations too.

Also, Don't we need similar checks in create*Array helpers in others backends too ?

Copy link
Member

Choose a reason for hiding this comment

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

This is already done in the OpenCL backend. It was not done in this backend because I intended to support half on older hardware and forgot to put it back in once I abandoned that idea.

Copy link
Member

Choose a reason for hiding this comment

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

In that case, lets try to move this check into src/api/c/ a more common location is perhaps af_create_array ?

Copy link
Member

Choose a reason for hiding this comment

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

lots of functions create arrays. for example randu. I think implementing it in the common namespace is sufficient.

Copy link
Member

Choose a reason for hiding this comment

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

Whichever location makes sense most.

Copy link
Contributor

@WilliamTambellini WilliamTambellini left a comment

Choose a reason for hiding this comment

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

Warning: this could easily kill perf for users creating thousand of small arrays per secs : have you checked the impact of checkTypeSupported on perf ?
Example:

  • in a for loop, just create arrays of random shapes (to bypass the GC buffer, or turn off GC)
  • track the time to do all these creations
  • compare with and without this checkTypeSupported
    ?

@9prady9
Copy link
Member

9prady9 commented Mar 9, 2020

Warning: this could easily kill perf for users creating thousand of small arrays per secs : have you checked the impact of checkTypeSupported on perf ?
Example:

* in a for loop, just create arrays of random shapes (to bypass the GC buffer, or turn off GC)

* track the time to do all these creations

* compare with and without this checkTypeSupported
  ?

I am not sure if these checks are avoided for fp16 for the reasons @WilliamTambellini mentioned. Having said that, some sort of check is required at some location I would think. @umar456 Can you please confirm if this is intentional or if check is done else where ?

@umar456
Copy link
Member

umar456 commented Mar 9, 2020

I don't think this check is going to be very expensive but it may be a good idea to memoize the result of the call for each device.

@@ -236,9 +236,17 @@ bool isDoubleSupported(int device) {
}

bool isHalfSupported(int device) {
auto prop = getDeviceProp(device);
Copy link
Member

Choose a reason for hiding this comment

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

Isn't getDeviceProp inexpensive ?

Copy link
Member

Choose a reason for hiding this comment

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

Yes but this will be slightly faster.

@umar456 umar456 merged commit cd3c107 into arrayfire:master Mar 25, 2020
@9prady9 9prady9 deleted the fp16_print_fix branch March 25, 2020 05:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants