Update to official oneDPL histogram implementation

[danhoeflinger]

This PR updates the histogram implementation from a temporary feature preview to use the official oneDPL interfaces, and removes the temporary histogram code.

It also removes a size() function from device iterator which causes problems with some internals of oneDPL separating ranges and iterator implementations. This size function seems strange (size of an iterator?), and only appears in one of the device_iterator implementations.

Technically this is removing part of a public interface of device_iterator, but I'm not sure how it makes any sense, and makes usage within oneDPL problematic.

[mmichel11]

Changes LGTM

[mmichel11]

Do we need to run clang-format again here?

[danhoeflinger]

mmm, yes. Fixed.

[timmiesmith]

LGTM. Thank you.

The iterator.size() method doesn't make sense, but is likely an old workaround. It is enabling the USM-based device_iterator to be treated as a SYCL buffer backed device_iterator. If the iterator is defined over a buffer you can use it.get_buffer().size() to get the size of the input range. The USM-based device_iterator is returning *this for get_buffer() and thus needed a nonsense size method in order for that usage in an algorithm to compile.

[timmiesmith]

CI Windows failures are unrelated to the PR.

[danhoeflinger]

The iterator.size() method doesn't make sense, but is likely an old workaround. It is enabling the USM-based device_iterator to be treated as a SYCL buffer backed device_iterator. If the iterator is defined over a buffer you can use it.get_buffer().size() to get the size of the input range. The USM-based device_iterator is returning *this for get_buffer() and thus needed a nonsense size method in order for that usage in an algorithm to compile.

@timmiesmith
Hmm, this makes some sense but also sets off some alarm bells for me. I'm wondering if we should fully remove the get_buffer which returns *this as well, or if we need to replace it with some proxy which also provides the size() function to the best of its ability. Similar to the removed one here, I don't think we have access to this info in reality.

Do you know where if anywhere this functionality is actually used? Since is_hetero = std::false_type (and it is "passed directly"), I don't expect it to be used within oneDPL at all. I'm not finding any place in SYCLomatic, or the SYCLomatic-tests. There are plenty of get_buffer() calls for oneDPL buffer_wrappers (sycl_iterators), and some for device_vector, but I see none for device_pointer.