www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Generalize .ptr to RawPtr ranges?

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Oct 05 2015
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Oct 05 2015
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
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
Oct 05 2015
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Oct 05 2015