Just a random idea - slices have .ptr and therefor have a bunch of advantages such as SSE optimized copy routine.

Once I wrap a slice in something (anything) it looses ALL of that.
Now for instance std.container.Array!int.Range can easily provide .ptr property, together with .length it would allow us to use memcpy etc.

Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where hasRawPtr!(Range) would test for compatible .ptr and .length.

The benefit compared to manually slicing the .ptr and using that, then propagating the change back to the original range is that:
	- it's error prone
	- awkwardly replicated at each call site

So it would be much better to retain safe range interface and encapsulate speed-hacks inside of the algorithms.

Thoughts?

-- 
Dmitry Olshansky

On Monday, 5 October 2015 at 10:06:04 UTC, Dmitry Olshansky wrote:
> Just a random idea - slices have .ptr and therefor have a bunch of advantages such as SSE optimized copy routine.
>
> Once I wrap a slice in something (anything) it looses ALL of that.
> Now for instance std.container.Array!int.Range can easily provide .ptr property, together with .length it would allow us to use memcpy etc.
>
> Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where hasRawPtr!(Range) would test for compatible .ptr and .length.
>
> The benefit compared to manually slicing the .ptr and using that, then propagating the change back to the original range is that:
> 	- it's error prone
> 	- awkwardly replicated at each call site
>
> So it would be much better to retain safe range interface and encapsulate speed-hacks inside of the algorithms.
>
> Thoughts?

I'm really not sure what we want to do here (if anything), but IIRC, Andrei was suggesting stuff along these lines with an eye to supporting user-defined, ref-counted strings with stuff they were doing at Facebook. So, this sort of thing has been brought up before. I'd have to think about it in-depth to have much intelligent to say on the matter though.

- Jonathan M Davis

On Monday, 5 October 2015 at 10:06:04 UTC, Dmitry Olshansky wrote:
> Just a random idea - slices have .ptr and therefor have a bunch of advantages such as SSE optimized copy routine.
>
> Once I wrap a slice in something (anything) it looses ALL of that.
> Now for instance std.container.Array!int.Range can easily provide .ptr property, together with .length it would allow us to use memcpy etc.
>
> Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where hasRawPtr!(Range) would test for compatible .ptr and .length.
>
> The benefit compared to manually slicing the .ptr and using that, then propagating the change back to the original range is that:
> 	- it's error prone
> 	- awkwardly replicated at each call site
>
> So it would be much better to retain safe range interface and encapsulate speed-hacks inside of the algorithms.
>
> Thoughts?

Somewhat related, C++17 is going to add the concept of Contiguous Iterators. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf

On 06-Oct-2015 01:36, Brad Anderson wrote:
> On Monday, 5 October 2015 at 10:06:04 UTC, Dmitry Olshansky wrote:
>> Just a random idea - slices have .ptr and therefor have a bunch of
>> advantages such as SSE optimized copy routine.
>>
>> Once I wrap a slice in something (anything) it looses ALL of that.
>> Now for instance std.container.Array!int.Range can easily provide .ptr
>> property, together with .length it would allow us to use memcpy etc.
>>
>> Maybe generalize to isRandomAccessRange!Range + hasRawPtr!Range, where
>> hasRawPtr!(Range) would test for compatible .ptr and .length.
>>
>> The benefit compared to manually slicing the .ptr and using that, then
>> propagating the change back to the original range is that:
>>     - it's error prone
>>     - awkwardly replicated at each call site
>>
>> So it would be much better to retain safe range interface and
>> encapsulate speed-hacks inside of the algorithms.
>>
>> Thoughts?
>
> Somewhat related, C++17 is going to add the concept of Contiguous
> Iterators.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3884.pdf

I'm thinking it might be better to add support RawChunkedAccess for ranges that can offer raw pointer(s) but only in bits and peices like e.g. a typical dequeue would or more generally segmented data structure/range.

If these two cases could be unified in some satisfactory that would be a huge win.

-- 
Dmitry Olshansky