Topic: Support for storage ordering in
Author: =?UTF-8?Q?=C5=81ukasz_Mendakiewicz?= <l.mendakiewicz@live.com>
Date: Wed, 2 Jul 2014 19:38:25 -0700 (PDT)
Raw View
------=_Part_273_19370709.1404355105213
Content-Type: text/plain; charset=UTF-8
For the record, my reasoning for the fixed ordering of array_view is as
follows: the natural ordering in C++ (inherited from C) is to focus on a 2D
case row major, and it is prevalent is language features, starting with
the "C" array. array_view guarantees the same ordering, so any interface
accepting this type knows its performance characteristics: e.g. for
efficient writes on CPUs use non-contiguous addresses to minimize false
sharing in cache, for efficient writes on GPUs use contiguous addresses to
maximize coalescing, etc.
While I can see merit in Jesse's proposal, I'm afraid that such feature
creep (the next logical step is arbitrary reordering of dimensions, fixed
sizes, etc.) would result in making a simple type complex.
Can't strided_array_view be used for the specialized cases where
interoperability with other languages/libraries is necessary? Or is the
fact that it allows any striding, not just transpose of array_view, a
blocker?
Alternatively, why couldn't this be solved by transposing one layer above
-- in the index type used to address the view?
On Wednesday, July 2, 2014 9:44:20 AM UTC-7, Jesse Perla wrote:
> The latest N4087 is very close to being usable by a large number of
> audiences, but is missing an essential feature: compile-time control of
> storage ordering for interoperability with existing libraries. Not some
> fancy dimension by dimension specification, but a global, static control.
> This isn't just an index traversal issue either, as static dispatching is
> necessary to match the algorithm to the storage order.
>
> This isn't a 2nd order issue because, as it requires a template parameter
> in several of the classes,* it cannot be added later without major
> breaking changes and potential redesigns*. So if it is left out, it is -
> in practice - preventing this class from ever having that feature. And
> since array_view becomes the LCD interface for any future multi_array
> class, it means C++ will never have the storage ordering in its standard
> library. Which means that if this is intended to make it easier to pass
> around pointers to data with bounds for doing numerical computing, then it
> will not be used by any of the major scientific libraries out there or
> interoperability with other languages such as Matlab, Python, R, or others.
> Users for many audiences will be even more confused: "why exactly can't I
> use the standard class with my favorite library?"
>
> *EVERY SINGLE* major multi-array implementation or 2-dimensional linear
> algebra library has control over storage ordering. There are performance
> reasons for huge multi-arrays depending on what traverse order each
> algorithm has, and hence cache locality and optimizations abound. But the
> main reasons are that a large number of scientific libraries (such as
> LAPACK) are intended for column-major even if they sometimes have transpose
> flags, and hence every downstream library has to support it. Who uses
> these sorts of libraries? It isn't just a niche audience of academics, and
> it is going to grow. It includes engineering, finance, statistics, image
> processing, OpenGL, optimization in industries such as airlines, anyone
> doing anything with social networks, etc.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_273_19370709.1404355105213
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>For the record, my reasoning for the fixed =
ordering of array_view is as follows: the natural ordering in C++ (inherite=
d from C) is to focus on a 2D case row major, and it is prevalent is langua=
ge features, starting with the "C" array. array_view guarantees the sa=
me ordering, so any interface accepting this type knows its performance cha=
racteristics: e.g. for efficient writes on CPUs use non-contiguous addresse=
s to minimize false sharing in cache, for efficient writes on GPUs use cont=
iguous addresses to maximize coalescing, etc.</div><div><br></div><div>Whil=
e I can see merit in Jesse's proposal, I'm afraid that such feature creep (=
the next logical step is arbitrary reordering of dimensions, fixed sizes, e=
tc.) would result in making a simple type complex.</div><div><br></div><div=
>Can't strided_array_view be used for the specialized cases where interoper=
ability with other languages/libraries is necessary? Or is the fact that it=
allows any striding, not just transpose of array_view, a blocker?</div><di=
v><br></div><div>Alternatively, why couldn't this be solved by transposing =
one layer above -- in the index type used to address the view?<br><br>On We=
dnesday, July 2, 2014 9:44:20 AM UTC-7, Jesse Perla wrote:</div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr"><div><div>The latest N4087 is very close=
to being usable by a large number of audiences, but is missing an essentia=
l feature: compile-time control of storage ordering for interoperability wi=
th existing libraries. Not some fancy dimension by dimension specific=
ation, but a global, static control. This isn't just an index travers=
al issue either, as static dispatching is necessary to match the algorithm =
to the storage order.</div><div><br></div><div>This isn't a 2nd order issue=
because, as it requires a template parameter in several of the classes,<b>=
it cannot be added later without major breaking changes and potential rede=
signs</b>. So if it is left out, it is - in practice - preventi=
ng this class from ever having that feature. And since array_view bec=
omes the LCD interface for any future multi_array class, it means C++ will =
never have the storage ordering in its standard library. Which means =
that if this is intended to make it easier to pass around pointers to data =
with bounds for doing numerical computing, then it will not be used by any =
of the major scientific libraries out there or interoperability with other =
languages such as Matlab, Python, R, or others. Users for many audien=
ces will be even more confused: "why exactly can't I use the standard class=
with my favorite library?" </div><div><br></div><div><b>EVERY SINGLE<=
/b> major multi-array implementation or 2-dimensional linear algebra librar=
y has control over storage ordering. There are performance reasons fo=
r huge multi-arrays depending on what traverse order each algorithm has, an=
d hence cache locality and optimizations abound. But the main reasons=
are that a large number of scientific libraries (such as LAPACK) are inten=
ded for column-major even if they sometimes have transpose flags, and hence=
every downstream library has to support it. Who uses these sorts of =
libraries? It isn't just a niche audience of academics, and it is goi=
ng to grow. It includes engineering, finance, statistics, image proce=
ssing, OpenGL, optimization in industries such as airlines, anyone doing an=
ything with social networks, etc.</div></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_273_19370709.1404355105213--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Wed, 2 Jul 2014 20:49:10 -0700 (PDT)
Raw View
------=_Part_339_4648439.1404359351009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=C5=81ukasz, thanks for the response.
On Wednesday, July 2, 2014 7:38:25 PM UTC-7, =C5=81ukasz Mendakiewicz wrote=
:
>
> For the record, my reasoning for the fixed ordering of array_view is as=
=20
> follows: the natural ordering in C++ (inherited from C) is to focus on a =
2D=20
> case row major, and it is prevalent is language features, starting with=
=20
> the "C" array. array_view guarantees the same ordering, so any interface=
=20
> accepting this type knows its performance characteristics: e.g. for=20
> efficient writes on CPUs use non-contiguous addresses to minimize false=
=20
> sharing in cache, for efficient writes on GPUs use contiguous addresses t=
o=20
> maximize coalescing, etc.
>
Totally makes sense. The problem is that the set of "interface(s)=20
accepting this type" is drastically reduced, to the point of it adding more=
=20
library noise and fragmentation than value for a large number of=20
applications. The semantics for array_view can easily be decoupled from=20
C-style storage. Assuming contiguous storage is essential, but which=20
dimensions go first doesn't have to be part of that requirement.
(And none of this has even discussed the massive speed differences due to=
=20
parallelization and cache locality depending on the algorithm. If a key=20
part of the algorithm takes an inner product of an enormous matrix, A, with=
=20
an enormous vector, x, then whether you are doing "A * x" vs. "x * A"=20
could make the storage ordering of A very relevant, especially when=20
vectorization and GPUs are added to the mix.)
=20
>
> While I can see merit in Jesse's proposal, I'm afraid that such feature=
=20
> creep (the next logical step is arbitrary reordering of dimensions, fixed=
=20
> sizes, etc.) would result in making a simple type complex.
>
If a feature can be added later without any trouble, then push it off. But=
=20
this is the one shot to get the feature in there.
The arbitrary reordering of dimensions is not necessary, is not a logical=
=20
step, and there is no need to worry about a slippery slope of adding=20
features. I am willing to bet 98% of the users of these sorts of libraries=
=20
choose only a single storage ordering without getting fancier, and usually=
=20
driven by interoperability with a particular library. Fixed extent=20
multi_array can come later and not break any concept you are defining here=
=20
if the storage ordering is a static toggle.
The feature doesn't have to look complex for users. Basically it is a=20
static template parameter (which defaults to C-style ordering) and nothing=
=20
more, by design. If the user is aware of the ordering anywhere else then=
=20
it is a mistake in the semantics. For implementation, the main change is=
=20
that in the traversal iterators or overloaded operators, the strides get=20
reversed. This has been done a dozen times before.
=20
Can't strided_array_view be used for the specialized cases where=20
> interoperability with other languages/libraries is necessary? Or is the=
=20
> fact that it allows any striding, not just transpose of array_view, a=20
> blocker?
>
> Alternatively, why couldn't this be solved by transposing one layer above=
=20
> -- in the index type used to address the view?
>
What you are asking is a reasonable question, but it won't work, and=20
certainly wouldn't get buy-in from library writers in these industries:
1. I want to pass something and use it with array_view semantics, as the=
=20
library intends. How the data is stored or accessed should be irrelevan=
t=20
to me. If the documentation for the finance library I am calling says=
=20
"pass data in column-major", I set that toggle and don't think about it=
=20
again. Or maybe I write my code and during optimization I flip a few of=
=20
the storage orderings to see if it has a huge speed difference without=
=20
having to go through and modify every iterator or accessor in my code.
2. For transposing a layer above, what are you suggesting that I pass to=
=20
my generic function with semantics independent of the storage ordering?=
=20
Maybe I don't understand your suggestion, but if you are recreating all=
of=20
the constructors, etc. for a strided_array_view with a static template=
=20
storage order, then why not just make it the main class?
3. It is essential to be able to statically determine the storage=20
ordering as downstream libraries have static requirements. So a dynamic=
=20
list of backwards strides doesn't work, which I think is what you are=20
asking.
Instead of listening to me, it may make sense to email the maintainers of=
=20
libraries who have to deal with multi-dimensional data: Eigen, Scipy,=20
boost::multi_array, blitz, boost::ublas, mtl4, OpenGL, Matlab, Octave, R,=
=20
CLAPACK, COIN-OR, and many, many, more... There is no cheap way around=20
this, which is why they all had to add in the toggle or deal with the=20
interoperability, and may have better advice than I am giving.
(I want to make sure that my tone is not coming off as ingratitude, but=20
rather my terrifying fear of further fragmentation and being stuck with my=
=20
industry using Fortran for the rest of my life. I love the rest of the=20
proposal and approach, and think any other additions can wait).
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_339_4648439.1404359351009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=C5=81ukasz, thanks for the response.<div><br>On Wednesday=
, July 2, 2014 7:38:25 PM UTC-7, =C5=81ukasz Mendakiewicz wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>For the record,&nbs=
p;my reasoning for the fixed ordering of array_view is as follows: the=
natural ordering in C++ (inherited from C) is to focus on a 2D case row ma=
jor, and it is prevalent is language features, starting with the "C" a=
rray. array_view guarantees the same ordering, so any interface accepting t=
his type knows its performance characteristics: e.g. for efficient writes o=
n CPUs use non-contiguous addresses to minimize false sharing in cache, for=
efficient writes on GPUs use contiguous addresses to maximize coalescing, =
etc.</div></div></blockquote><div><br></div><div>Totally makes sense.  =
;The problem is that the set of "interface(s) accepting this type" is drast=
ically reduced, to the point of it adding more library noise and fragmentat=
ion than value for a large number of applications. The semantics for =
array_view can easily be decoupled from C-style storage. Assuming con=
tiguous storage is essential, but which dimensions go first doesn't have to=
be part of that requirement.</div><div><br></div><div>(And none of this ha=
s even discussed the massive speed differences due to parallelization and c=
ache locality depending on the algorithm. If a key part of the algori=
thm takes an inner product of an enormous matrix, A, with an enormous vecto=
r, x, then whether you are doing "A * x" vs. "x * A" could make the s=
torage ordering of A very relevant, especially when vectorization and GPUs =
are added to the mix.)<br></div><div> <br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>While I can see=
merit in Jesse's proposal, I'm afraid that such feature creep (the next lo=
gical step is arbitrary reordering of dimensions, fixed sizes, etc.) would =
result in making a simple type complex.</div></div></blockquote><div><br></=
div><div>If a feature can be added later without any trouble, then push it =
off. But this is the one shot to get the feature in there.<br></div><=
div><br></div><div>The arbitrary reordering of dimensions is not necessary,=
is not a logical step, and there is no need to worry about a slippery slop=
e of adding features. I am willing to bet 98% of the users of these s=
orts of libraries choose only a single storage ordering without getting fan=
cier, and usually driven by interoperability with a particular library. &nb=
sp;Fixed extent multi_array can come later and not break any concept you ar=
e defining here if the storage ordering is a static toggle.<br></div><div><=
br></div><div>The feature doesn't have to look complex for users. Bas=
ically it is a static template parameter (which defaults to C-style orderin=
g) and nothing more, by design. If the user is aware of the ordering =
anywhere else then it is a mistake in the semantics. For implementati=
on, the main change is that in the traversal iterators or overloaded operat=
ors, the strides get reversed. This has been done a dozen times befor=
e.<br></div><div> </div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>Can't strided_array_view be used for th=
e specialized cases where interoperability with other languages/libraries i=
s necessary? Or is the fact that it allows any striding, not just transpose=
of array_view, a blocker?</div><div><br></div><div>Alternatively, why coul=
dn't this be solved by transposing one layer above -- in the index type use=
d to address the view?<br></div></div></blockquote><div><br></div><div><div=
>What you are asking is a reasonable question, but it won't work, and certa=
inly wouldn't get buy-in from library writers in these industries:</div><di=
v><ol><li>I want to pass something and use it with array_view semantics, as=
the library intends. How the data is stored or accessed should be ir=
relevant to me. If the documentation for the finance library I am cal=
ling says "pass data in column-major", I set that toggle and don't think ab=
out it again. Or maybe I write my code and during optimization I flip=
a few of the storage orderings to see if it has a huge speed difference wi=
thout having to go through and modify every iterator or accessor in my code=
..</li><li>For transposing a layer above, what are you suggesting that I pas=
s to my generic function with semantics independent of the storage ordering=
? Maybe I don't understand your suggestion, but if you are recreating=
all of the constructors, etc. for a strided_array_view with a static templ=
ate storage order, then why not just make it the main class?</li><li>It is =
essential to be able to statically determine the storage ordering as downst=
ream libraries have static requirements. So a dynamic list of backwar=
ds strides doesn't work, which I think is what you are asking.</li></ol></d=
iv><div>Instead of listening to me, it may make sense to email the maintain=
ers of libraries who have to deal with multi-dimensional data: Eigen, Scipy=
, boost::multi_array, blitz, boost::ublas, mtl4, OpenGL, Matlab, Octave, R,=
CLAPACK, COIN-OR, and many, many, more... There is no cheap way arou=
nd this, which is why they all had to add in the toggle or deal with the in=
teroperability, and may have better advice than I am giving.<br></div></div=
><div><br></div><div>(I want to make sure that my tone is not coming off as=
ingratitude, but rather my terrifying fear of further fragmentation and be=
ing stuck with my industry using Fortran for the rest of my life. I l=
ove the rest of the proposal and approach, and think any other additions ca=
n wait).</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_339_4648439.1404359351009--
.
Author: Miro Knejp <miro@knejp.de>
Date: Thu, 03 Jul 2014 08:21:46 +0200
Raw View
This is a multi-part message in MIME format.
--------------090405030604020008000407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Adding such a global flag sounds like a generally bad idea. If you use=20
two different libraries or APIs in the same application with different=20
storage layout that static flag will break one of them. A library should=20
not rely on the flag having the required state, that is just bad design.=20
If a library or API has a strict layout requirement it should announce=20
that in the public interface by defining the appropriate typedefs and=20
using them instead. These typedefs then act as a library-wide switch,=20
not global, and can be specified in/derived from a config header. Use=20
the library typedefs in your own code to ensure compatibility.
If you want to test whether your code runs faster with column- or=20
row-major layout, what speaks against creating a typedef for the=20
iterators/ranges/views and using those?
Unless I understood something wrong I don't believe a static, global=20
switch for the entire codebase is the solution. Library writers could=20
not rely on it having the proper value as it could be changed by other=20
libraries or the user and mess things up with the requirements of the=20
underlying API.
Am 03.07.2014 05:49, schrieb Jesse Perla:
> =C5=81ukasz, thanks for the response.
>
> On Wednesday, July 2, 2014 7:38:25 PM UTC-7, =C5=81ukasz Mendakiewicz wro=
te:
>
> For the record, my reasoning for the fixed ordering of array_view
> is as follows: the natural ordering in C++ (inherited from C) is
> to focus on a 2D case row major, and it is prevalent is language
> features, starting with the "C" array. array_view guarantees the
> same ordering, so any interface accepting this type knows its
> performance characteristics: e.g. for efficient writes on CPUs use
> non-contiguous addresses to minimize false sharing in cache, for
> efficient writes on GPUs use contiguous addresses to maximize
> coalescing, etc.
>
>
> Totally makes sense. The problem is that the set of "interface(s)=20
> accepting this type" is drastically reduced, to the point of it adding=20
> more library noise and fragmentation than value for a large number of=20
> applications. The semantics for array_view can easily be decoupled=20
> from C-style storage. Assuming contiguous storage is essential, but=20
> which dimensions go first doesn't have to be part of that requirement.
>
> (And none of this has even discussed the massive speed differences due=20
> to parallelization and cache locality depending on the algorithm. If=20
> a key part of the algorithm takes an inner product of an enormous=20
> matrix, A, with an enormous vector, x, then whether you are doing "A=20
> * x" vs. "x * A" could make the storage ordering of A very relevant,=20
> especially when vectorization and GPUs are added to the mix.)
>
>
> While I can see merit in Jesse's proposal, I'm afraid that such
> feature creep (the next logical step is arbitrary reordering of
> dimensions, fixed sizes, etc.) would result in making a simple
> type complex.
>
>
> If a feature can be added later without any trouble, then push it off.=20
> But this is the one shot to get the feature in there.
>
> The arbitrary reordering of dimensions is not necessary, is not a=20
> logical step, and there is no need to worry about a slippery slope of=20
> adding features. I am willing to bet 98% of the users of these sorts=20
> of libraries choose only a single storage ordering without getting=20
> fancier, and usually driven by interoperability with a particular=20
> library. Fixed extent multi_array can come later and not break any=20
> concept you are defining here if the storage ordering is a static toggle.
>
> The feature doesn't have to look complex for users. Basically it is a=20
> static template parameter (which defaults to C-style ordering) and=20
> nothing more, by design. If the user is aware of the ordering=20
> anywhere else then it is a mistake in the semantics. For=20
> implementation, the main change is that in the traversal iterators or=20
> overloaded operators, the strides get reversed. This has been done a=20
> dozen times before.
>
> Can't strided_array_view be used for the specialized cases where
> interoperability with other languages/libraries is necessary? Or
> is the fact that it allows any striding, not just transpose of
> array_view, a blocker?
>
> Alternatively, why couldn't this be solved by transposing one
> layer above -- in the index type used to address the view?
>
>
> What you are asking is a reasonable question, but it won't work, and=20
> certainly wouldn't get buy-in from library writers in these industries:
>
> 1. I want to pass something and use it with array_view semantics, as
> the library intends. How the data is stored or accessed should be
> irrelevant to me. If the documentation for the finance library I
> am calling says "pass data in column-major", I set that toggle and
> don't think about it again. Or maybe I write my code and during
> optimization I flip a few of the storage orderings to see if it
> has a huge speed difference without having to go through and
> modify every iterator or accessor in my code.
> 2. For transposing a layer above, what are you suggesting that I pass
> to my generic function with semantics independent of the storage
> ordering? Maybe I don't understand your suggestion, but if you
> are recreating all of the constructors, etc. for a
> strided_array_view with a static template storage order, then why
> not just make it the main class?
> 3. It is essential to be able to statically determine the storage
> ordering as downstream libraries have static requirements. So a
> dynamic list of backwards strides doesn't work, which I think is
> what you are asking.
>
> Instead of listening to me, it may make sense to email the maintainers=20
> of libraries who have to deal with multi-dimensional data: Eigen,=20
> Scipy, boost::multi_array, blitz, boost::ublas, mtl4, OpenGL, Matlab,=20
> Octave, R, CLAPACK, COIN-OR, and many, many, more... There is no=20
> cheap way around this, which is why they all had to add in the toggle=20
> or deal with the interoperability, and may have better advice than I=20
> am giving.
>
> (I want to make sure that my tone is not coming off as ingratitude,=20
> but rather my terrifying fear of further fragmentation and being stuck=20
> with my industry using Fortran for the rest of my life. I love the=20
> rest of the proposal and approach, and think any other additions can=20
> wait).
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------090405030604020008000407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
Adding such a global flag sounds like a generally bad idea. If you
use two different libraries or APIs in the same application with
different storage layout that static flag will break one of them. A
library should not rely on the flag having the required state, that
is just bad design. If a library or API has a strict layout
requirement it should announce that in the public interface by
defining the appropriate typedefs and using them instead. These
typedefs then act as a library-wide switch, not global, and can be
specified in/derived from a config header. Use the library typedefs
in your own code to ensure compatibility.<br>
<br>
If you want to test whether your code runs faster with column- or
row-major layout, what speaks against creating a typedef for the
iterators/ranges/views and using those?<br>
<br>
Unless I understood something wrong I don't believe a static, global
switch for the entire codebase is the solution. Library writers
could not rely on it having the proper value as it could be changed
by other libraries or the user and mess things up with the
requirements of the underlying API.<br>
<br>
<div class=3D"moz-cite-prefix">Am 03.07.2014 05:49, schrieb Jesse
Perla:<br>
</div>
<blockquote
cite=3D"mid:c10a32f7-cdd5-476a-9101-e99aa966490e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">=C5=81ukasz, thanks for the response.
<div><br>
On Wednesday, July 2, 2014 7:38:25 PM UTC-7, =C5=81ukasz
Mendakiewicz wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div>For the record,=C2=A0my reasoning for the=C2=A0fixed ord=
ering
of array_view is as follows: the natural ordering in C++
(inherited from C) is to focus on a 2D case row major,
and it is prevalent is language features, starting with
the=C2=A0"C" array. array_view guarantees the same ordering=
,
so any interface accepting this type knows its
performance characteristics: e.g. for efficient writes
on CPUs use non-contiguous addresses to minimize false
sharing in cache, for efficient writes on GPUs use
contiguous addresses to maximize coalescing, etc.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Totally makes sense. =C2=A0The problem is that the set of
"interface(s) accepting this type" is drastically reduced,
to the point of it adding more library noise and
fragmentation than value for a large number of applications.
=C2=A0The semantics for array_view can easily be decoupled from
C-style storage. =C2=A0Assuming contiguous storage is essential=
,
but which dimensions go first doesn't have to be part of
that requirement.</div>
<div><br>
</div>
<div>(And none of this has even discussed the massive speed
differences due to parallelization and cache locality
depending on the algorithm. =C2=A0If a key part of the algorith=
m
takes an inner product of an enormous matrix, A, with an
enormous vector, x, then whether you are doing =C2=A0"A * x" vs=
..
"x * A" could make the storage ordering of A very relevant,
especially when vectorization and GPUs are added to the
mix.)<br>
</div>
<div>=C2=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div><br>
</div>
<div>While I can see merit in Jesse's proposal, I'm afraid
that such feature creep (the next logical step is
arbitrary reordering of dimensions, fixed sizes, etc.)
would result in making a simple type complex.</div>
</div>
</blockquote>
<div><br>
</div>
<div>If a feature can be added later without any trouble, then
push it off. =C2=A0But this is the one shot to get the feature =
in
there.<br>
</div>
<div><br>
</div>
<div>The arbitrary reordering of dimensions is not necessary,
is not a logical step, and there is no need to worry about a
slippery slope of adding features. =C2=A0I am willing to bet 98=
%
of the users of these sorts of libraries choose only a
single storage ordering without getting fancier, and usually
driven by interoperability with a particular library. =C2=A0Fix=
ed
extent multi_array can come later and not break any concept
you are defining here if the storage ordering is a static
toggle.<br>
</div>
<div><br>
</div>
<div>The feature doesn't have to look complex for users.
=C2=A0Basically it is a static template parameter (which defaul=
ts
to C-style ordering) and nothing more, by design. =C2=A0If the
user is aware of the ordering anywhere else then it is a
mistake in the semantics. =C2=A0For implementation, the main
change is that in the traversal iterators or overloaded
operators, the strides get reversed. =C2=A0This has been done a
dozen times before.<br>
</div>
<div>=C2=A0</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div>Can't strided_array_view be used for the specialized
cases where interoperability with other
languages/libraries is necessary? Or is the fact that it
allows any striding, not just transpose of array_view, a
blocker?</div>
<div><br>
</div>
<div>Alternatively, why couldn't this be solved by
transposing one layer above -- in the index type used to
address the view?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>What you are asking is a reasonable question, but it
won't work, and certainly wouldn't get buy-in from library
writers in these industries:</div>
<div>
<ol>
<li>I want to pass something and use it with array_view
semantics, as the library intends. =C2=A0How the data is
stored or accessed should be irrelevant to me. =C2=A0If t=
he
documentation for the finance library I am calling
says "pass data in column-major", I set that toggle
and don't think about it again. =C2=A0Or maybe I write my
code and during optimization I flip a few of the
storage orderings to see if it has a huge speed
difference without having to go through and modify
every iterator or accessor in my code.</li>
<li>For transposing a layer above, what are you
suggesting that I pass to my generic function with
semantics independent of the storage ordering? =C2=A0Mayb=
e
I don't understand your suggestion, but if you are
recreating all of the constructors, etc. for a
strided_array_view with a static template storage
order, then why not just make it the main class?</li>
<li>It is essential to be able to statically determine
the storage ordering as downstream libraries have
static requirements. =C2=A0So a dynamic list of backwards
strides doesn't work, which I think is what you are
asking.</li>
</ol>
</div>
<div>Instead of listening to me, it may make sense to email
the maintainers of libraries who have to deal with
multi-dimensional data: Eigen, Scipy, boost::multi_array,
blitz, boost::ublas, mtl4, OpenGL, Matlab, Octave, R,
CLAPACK, COIN-OR, and many, many, more... =C2=A0There is no
cheap way around this, which is why they all had to add in
the toggle or deal with the interoperability, and may have
better advice than I am giving.<br>
</div>
</div>
<div><br>
</div>
<div>(I want to make sure that my tone is not coming off as
ingratitude, but rather my terrifying fear of further
fragmentation and being stuck with my industry using Fortran
for the rest of my life. =C2=A0I love the rest of the proposal
and approach, and think any other additions can wait).</div>
</div>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------090405030604020008000407--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Thu, 03 Jul 2014 11:29:45 +0200
Raw View
This is a multi-part message in MIME format.
--------------030609060707010705050508
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
As a developper of a multidimensionnal array computing science library,=20
I can only say +1 to this. Storage order customization is paramount
to a lot of performances applications. There is also a non trivial=20
familly of applications related to physics and chemistry where the most=20
optimal
code require an arbitrary succession of ordering changes.
So, yes multi_array without storage order option is doomed ot finish=20
where valarray is, the unused box.
Le 03/07/2014 08:21, Miro Knejp a =C3=A9crit :
> Adding such a global flag sounds like a generally bad idea. If you use=20
> two different libraries or APIs in the same application with different=20
> storage layout that static flag will break one of them. A library=20
> should not rely on the flag having the required state, that is just=20
> bad design. If a library or API has a strict layout requirement it=20
> should announce that in the public interface by defining the=20
> appropriate typedefs and using them instead. These typedefs then act=20
> as a library-wide switch, not global, and can be specified in/derived=20
> from a config header. Use the library typedefs in your own code to=20
> ensure compatibility.
>
> If you want to test whether your code runs faster with column- or=20
> row-major layout, what speaks against creating a typedef for the=20
> iterators/ranges/views and using those?
>
> Unless I understood something wrong I don't believe a static, global=20
> switch for the entire codebase is the solution. Library writers could=20
> not rely on it having the proper value as it could be changed by other=20
> libraries or the user and mess things up with the requirements of the=20
> underlying API.
>
> Am 03.07.2014 05:49, schrieb Jesse Perla:
>> =C5=81ukasz, thanks for the response.
>>
>> On Wednesday, July 2, 2014 7:38:25 PM UTC-7, =C5=81ukasz Mendakiewicz wr=
ote:
>>
>> For the record, my reasoning for the fixed ordering of array_view
>> is as follows: the natural ordering in C++ (inherited from C) is
>> to focus on a 2D case row major, and it is prevalent is language
>> features, starting with the "C" array. array_view guarantees the
>> same ordering, so any interface accepting this type knows its
>> performance characteristics: e.g. for efficient writes on CPUs
>> use non-contiguous addresses to minimize false sharing in cache,
>> for efficient writes on GPUs use contiguous addresses to maximize
>> coalescing, etc.
>>
>>
>> Totally makes sense. The problem is that the set of "interface(s)=20
>> accepting this type" is drastically reduced, to the point of it=20
>> adding more library noise and fragmentation than value for a large=20
>> number of applications. The semantics for array_view can easily be=20
>> decoupled from C-style storage. Assuming contiguous storage is=20
>> essential, but which dimensions go first doesn't have to be part of=20
>> that requirement.
>>
>> (And none of this has even discussed the massive speed differences=20
>> due to parallelization and cache locality depending on the algorithm.=20
>> If a key part of the algorithm takes an inner product of an enormous=20
>> matrix, A, with an enormous vector, x, then whether you are doing "A=20
>> * x" vs. "x * A" could make the storage ordering of A very relevant,=20
>> especially when vectorization and GPUs are added to the mix.)
>>
>>
>> While I can see merit in Jesse's proposal, I'm afraid that such
>> feature creep (the next logical step is arbitrary reordering of
>> dimensions, fixed sizes, etc.) would result in making a simple
>> type complex.
>>
>>
>> If a feature can be added later without any trouble, then push it=20
>> off. But this is the one shot to get the feature in there.
>>
>> The arbitrary reordering of dimensions is not necessary, is not a=20
>> logical step, and there is no need to worry about a slippery slope of=20
>> adding features. I am willing to bet 98% of the users of these sorts=20
>> of libraries choose only a single storage ordering without getting=20
>> fancier, and usually driven by interoperability with a particular=20
>> library. Fixed extent multi_array can come later and not break any=20
>> concept you are defining here if the storage ordering is a static toggle=
..
>>
>> The feature doesn't have to look complex for users. Basically it is=20
>> a static template parameter (which defaults to C-style ordering) and=20
>> nothing more, by design. If the user is aware of the ordering=20
>> anywhere else then it is a mistake in the semantics. For=20
>> implementation, the main change is that in the traversal iterators or=20
>> overloaded operators, the strides get reversed. This has been done a=20
>> dozen times before.
>>
>> Can't strided_array_view be used for the specialized cases where
>> interoperability with other languages/libraries is necessary? Or
>> is the fact that it allows any striding, not just transpose of
>> array_view, a blocker?
>>
>> Alternatively, why couldn't this be solved by transposing one
>> layer above -- in the index type used to address the view?
>>
>>
>> What you are asking is a reasonable question, but it won't work, and=20
>> certainly wouldn't get buy-in from library writers in these industries:
>>
>> 1. I want to pass something and use it with array_view semantics, as
>> the library intends. How the data is stored or accessed should
>> be irrelevant to me. If the documentation for the finance
>> library I am calling says "pass data in column-major", I set that
>> toggle and don't think about it again. Or maybe I write my code
>> and during optimization I flip a few of the storage orderings to
>> see if it has a huge speed difference without having to go
>> through and modify every iterator or accessor in my code.
>> 2. For transposing a layer above, what are you suggesting that I
>> pass to my generic function with semantics independent of the
>> storage ordering? Maybe I don't understand your suggestion, but
>> if you are recreating all of the constructors, etc. for a
>> strided_array_view with a static template storage order, then why
>> not just make it the main class?
>> 3. It is essential to be able to statically determine the storage
>> ordering as downstream libraries have static requirements. So a
>> dynamic list of backwards strides doesn't work, which I think is
>> what you are asking.
>>
>> Instead of listening to me, it may make sense to email the=20
>> maintainers of libraries who have to deal with multi-dimensional=20
>> data: Eigen, Scipy, boost::multi_array, blitz, boost::ublas, mtl4,=20
>> OpenGL, Matlab, Octave, R, CLAPACK, COIN-OR, and many, many, more...=20
>> There is no cheap way around this, which is why they all had to add=20
>> in the toggle or deal with the interoperability, and may have better=20
>> advice than I am giving.
>>
>> (I want to make sure that my tone is not coming off as ingratitude,=20
>> but rather my terrifying fear of further fragmentation and being=20
>> stuck with my industry using Fortran for the rest of my life. I love=20
>> the rest of the proposal and approach, and think any other additions=20
>> can wait).
>> --=20
>>
>> ---
>> You received this message because you are subscribed to the Google=20
>> Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it,=20
>> send an email to std-proposals+unsubscribe@isocpp.org=20
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org=20
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------030609060707010705050508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
As a developper of a multidimensionnal array computing science
library, I can only say +1 to this. Storage order customization is
paramount<br>
to a lot of performances applications. There is also a non trivial
familly of applications related to physics and chemistry where the
most optimal<br>
code require an arbitrary succession of ordering changes.<br>
<br>
So, yes multi_array without storage order option is doomed ot finish
where valarray is, the unused box.<br>
<br>
<br>
<div class=3D"moz-cite-prefix">Le 03/07/2014 08:21, Miro Knejp a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote cite=3D"mid:53B4F67A.2050701@knejp.de" type=3D"cite">
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
Adding such a global flag sounds like a generally bad idea. If you
use two different libraries or APIs in the same application with
different storage layout that static flag will break one of them.
A library should not rely on the flag having the required state,
that is just bad design. If a library or API has a strict layout
requirement it should announce that in the public interface by
defining the appropriate typedefs and using them instead. These
typedefs then act as a library-wide switch, not global, and can be
specified in/derived from a config header. Use the library
typedefs in your own code to ensure compatibility.<br>
<br>
If you want to test whether your code runs faster with column- or
row-major layout, what speaks against creating a typedef for the
iterators/ranges/views and using those?<br>
<br>
Unless I understood something wrong I don't believe a static,
global switch for the entire codebase is the solution. Library
writers could not rely on it having the proper value as it could
be changed by other libraries or the user and mess things up with
the requirements of the underlying API.<br>
<br>
<div class=3D"moz-cite-prefix">Am 03.07.2014 05:49, schrieb Jesse
Perla:<br>
</div>
<blockquote
cite=3D"mid:c10a32f7-cdd5-476a-9101-e99aa966490e@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">=C5=81ukasz, thanks for the response.
<div><br>
On Wednesday, July 2, 2014 7:38:25 PM UTC-7, =C5=81ukasz
Mendakiewicz wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:
0;margin-left: 0.8ex;border-left: 1px #ccc
solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div>For the record,=C2=A0my reasoning for the=C2=A0fixed o=
rdering
of array_view is as follows: the natural ordering in
C++ (inherited from C) is to focus on a 2D case row
major, and it is prevalent is language features,
starting with the=C2=A0"C" array. array_view guarantees t=
he
same ordering, so any interface accepting this type
knows its performance characteristics: e.g. for
efficient writes on CPUs use non-contiguous addresses
to minimize false sharing in cache, for efficient
writes on GPUs use contiguous addresses to maximize
coalescing, etc.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Totally makes sense. =C2=A0The problem is that the set of
"interface(s) accepting this type" is drastically reduced,
to the point of it adding more library noise and
fragmentation than value for a large number of
applications. =C2=A0The semantics for array_view can easily b=
e
decoupled from C-style storage. =C2=A0Assuming contiguous
storage is essential, but which dimensions go first
doesn't have to be part of that requirement.</div>
<div><br>
</div>
<div>(And none of this has even discussed the massive speed
differences due to parallelization and cache locality
depending on the algorithm. =C2=A0If a key part of the
algorithm takes an inner product of an enormous matrix, A,
with an enormous vector, x, then whether you are doing =C2=A0=
"A
* x" vs. "x * A" could make the storage ordering of A very
relevant, especially when vectorization and GPUs are added
to the mix.)<br>
</div>
<div>=C2=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:
0;margin-left: 0.8ex;border-left: 1px #ccc
solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div><br>
</div>
<div>While I can see merit in Jesse's proposal, I'm
afraid that such feature creep (the next logical step
is arbitrary reordering of dimensions, fixed sizes,
etc.) would result in making a simple type complex.</div>
</div>
</blockquote>
<div><br>
</div>
<div>If a feature can be added later without any trouble,
then push it off. =C2=A0But this is the one shot to get the
feature in there.<br>
</div>
<div><br>
</div>
<div>The arbitrary reordering of dimensions is not
necessary, is not a logical step, and there is no need to
worry about a slippery slope of adding features. =C2=A0I am
willing to bet 98% of the users of these sorts of
libraries choose only a single storage ordering without
getting fancier, and usually driven by interoperability
with a particular library. =C2=A0Fixed extent multi_array can
come later and not break any concept you are defining here
if the storage ordering is a static toggle.<br>
</div>
<div><br>
</div>
<div>The feature doesn't have to look complex for users.
=C2=A0Basically it is a static template parameter (which
defaults to C-style ordering) and nothing more, by design.
=C2=A0If the user is aware of the ordering anywhere else then
it is a mistake in the semantics. =C2=A0For implementation, t=
he
main change is that in the traversal iterators or
overloaded operators, the strides get reversed. =C2=A0This ha=
s
been done a dozen times before.<br>
</div>
<div>=C2=A0</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:
0;margin-left: 0.8ex;border-left: 1px #ccc
solid;padding-left: 1ex;">
<div dir=3D"ltr">
<div>Can't strided_array_view be used for the
specialized cases where interoperability with other
languages/libraries is necessary? Or is the fact that
it allows any striding, not just transpose of
array_view, a blocker?</div>
<div><br>
</div>
<div>Alternatively, why couldn't this be solved by
transposing one layer above -- in the index type used
to address the view?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<div>What you are asking is a reasonable question, but it
won't work, and certainly wouldn't get buy-in from
library writers in these industries:</div>
<div>
<ol>
<li>I want to pass something and use it with
array_view semantics, as the library intends. =C2=A0How
the data is stored or accessed should be irrelevant
to me. =C2=A0If the documentation for the finance libra=
ry
I am calling says "pass data in column-major", I set
that toggle and don't think about it again. =C2=A0Or
maybe I write my code and during optimization I flip
a few of the storage orderings to see if it has a
huge speed difference without having to go through
and modify every iterator or accessor in my code.</li>
<li>For transposing a layer above, what are you
suggesting that I pass to my generic function with
semantics independent of the storage ordering?
=C2=A0Maybe I don't understand your suggestion, but if
you are recreating all of the constructors, etc. for
a strided_array_view with a static template storage
order, then why not just make it the main class?</li>
<li>It is essential to be able to statically determine
the storage ordering as downstream libraries have
static requirements. =C2=A0So a dynamic list of backwar=
ds
strides doesn't work, which I think is what you are
asking.</li>
</ol>
</div>
<div>Instead of listening to me, it may make sense to
email the maintainers of libraries who have to deal with
multi-dimensional data: Eigen, Scipy,
boost::multi_array, blitz, boost::ublas, mtl4, OpenGL,
Matlab, Octave, R, CLAPACK, COIN-OR, and many, many,
more... =C2=A0There is no cheap way around this, which is w=
hy
they all had to add in the toggle or deal with the
interoperability, and may have better advice than I am
giving.<br>
</div>
</div>
<div><br>
</div>
<div>(I want to make sure that my tone is not coming off as
ingratitude, but rather my terrifying fear of further
fragmentation and being stuck with my industry using
Fortran for the rest of my life. =C2=A0I love the rest of the
proposal and approach, and think any other additions can
wait).</div>
</div>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from
it, send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposal=
s+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org=
</a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals=
/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------030609060707010705050508--
.
Author: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 3 Jul 2014 09:47:56 -0700
Raw View
Could you and the other interested folks write up exactly how you'd
like to change array_view, ideally as a set of changes proposed
against N4087? It'd also be good to include an example of the code
that'll be enabled by your change, any possible workarounds available
in the existing proposal, and an explanation of why the workarounds
aren't as good. The committee could adopt a paper proposing changes,
but it's harder to adopt general philosophical statements.
On Wed, Jul 2, 2014 at 9:44 AM, Jesse Perla <jesseperla@gmail.com> wrote:
> The latest N4087 is very close to being usable by a large number of
> audiences, but is missing an essential feature: compile-time control of
> storage ordering for interoperability with existing libraries. Not some
> fancy dimension by dimension specification, but a global, static control.
> This isn't just an index traversal issue either, as static dispatching is
> necessary to match the algorithm to the storage order.
>
> This isn't a 2nd order issue because, as it requires a template parameter in
> several of the classes, it cannot be added later without major breaking
> changes and potential redesigns. So if it is left out, it is - in practice
> - preventing this class from ever having that feature. And since
> array_view becomes the LCD interface for any future multi_array class, it
> means C++ will never have the storage ordering in its standard library.
> Which means that if this is intended to make it easier to pass around
> pointers to data with bounds for doing numerical computing, then it will not
> be used by any of the major scientific libraries out there or
> interoperability with other languages such as Matlab, Python, R, or others.
> Users for many audiences will be even more confused: "why exactly can't I
> use the standard class with my favorite library?"
>
> EVERY SINGLE major multi-array implementation or 2-dimensional linear
> algebra library has control over storage ordering. There are performance
> reasons for huge multi-arrays depending on what traverse order each
> algorithm has, and hence cache locality and optimizations abound. But the
> main reasons are that a large number of scientific libraries (such as
> LAPACK) are intended for column-major even if they sometimes have transpose
> flags, and hence every downstream library has to support it. Who uses these
> sorts of libraries? It isn't just a niche audience of academics, and it is
> going to grow. It includes engineering, finance, statistics, image
> processing, OpenGL, optimization in industries such as airlines, anyone
> doing anything with social networks, etc.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Thu, 3 Jul 2014 09:49:08 -0700 (PDT)
Raw View
------=_Part_931_12858015.1404406148480
Content-Type: text/plain; charset=UTF-8
On Thursday, July 3, 2014 2:29:53 AM UTC-7, Joel Falcou wrote:
>
> As a developper of a multidimensionnal array computing science library, I
> can only say +1 to this. Storage order customization is paramount
> to a lot of performances applications. There is also a non trivial familly
> of applications related to physics and chemistry where the most optimal
> code require an arbitrary succession of ordering changes.
>
Yes, that popped up for me once as well (needed arrays of contiguous
column-major matrices to call LAPACK). For those applications, it is
reasonable to add a variation on the strided_array (later if possible)
which allows the arbitrary reordering of the strides (as Lukasz was
suggesting for a general solution)? It seems that anyone requiring
arbitrary ordering is sophisticated enough to manually construct those
sorts of views.
> So, yes multi_array without storage order option is doomed ot finish where
> valarray is, the unused box.
>
Yup, much more succinct than I was. This is a P(1) event.
Joel, as one of the world experts in this area: is there a future proofing
with alignment issues that needs to be added in the template interface?
Maybe not getting 100% of the way there, but for 90% of the important
applications and ensure that GPU/vectorization processing is possible with
contiguous sub-arrays? It would be a shame if a design decision made it
impossible to get an array_view on Eigen, GPU-oriented, and other important
libraries (e.g.
http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html)
? I imagine this pops up the graphics/geometry world as well and wanted to
raise a flag.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_931_12858015.1404406148480
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Thursday, July 3, 2014 2:29:53 AM UTC-7, Joel Falco=
u wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
As a developper of a multidimensionnal array computing science
library, I can only say +1 to this. Storage order customization is
paramount<br>
to a lot of performances applications. There is also a non trivial
familly of applications related to physics and chemistry where the
most optimal<br>
code require an arbitrary succession of ordering changes.<br></div></bl=
ockquote><div><br></div><div>Yes, that popped up for me once as well (neede=
d arrays of contiguous column-major matrices to call LAPACK). For tho=
se applications, it is reasonable to add a variation on the strided_array (=
later if possible) which allows the arbitrary reordering of the strides (as=
Lukasz was suggesting for a general solution)? It seems that anyone =
requiring arbitrary ordering is sophisticated enough to manually construct =
those sorts of views.</div><div><br></div><div> </div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
So, yes multi_array without storage order option is doomed ot finish
where valarray is, the unused box.<br></div></blockquote><div><br></div=
><div><div>Yup, much more succinct than I was. This is a P(1) event.</div><=
div><br></div><div><span>Joel, as one of the world experts in this area: is=
there a future proofing with alignment issues that needs to be added in th=
e template interface? Maybe not getting 100% of the way there, but fo=
r 90% of the important applications and ensure that GPU/vectorization proce=
ssing is possible with contiguous sub-arrays? It would be a shame if =
a design decision made it impossible to get an array_view on Eigen, GPU-ori=
ented, and other important libraries (e.g. <a class=3D"linkclass" href=3D"h=
ttp://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html">=
http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html<=
/a>) ? I imagine this pops up the graphics/geometry world as well and=
wanted to raise a flag.</span></div></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_931_12858015.1404406148480--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Thu, 03 Jul 2014 19:47:14 +0200
Raw View
This is a multi-part message in MIME format.
--------------080703000502030002090901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 03/07/2014 18:49, Jesse Perla a =C3=A9crit :
>
> On Thursday, July 3, 2014 2:29:53 AM UTC-7, Joel Falcou wrote:
>
> As a developper of a multidimensionnal array computing science
> library, I can only say +1 to this. Storage order customization is
> paramount
> to a lot of performances applications. There is also a non trivial
> familly of applications related to physics and chemistry where the
> most optimal
> code require an arbitrary succession of ordering changes.
>
>
> Yes, that popped up for me once as well (needed arrays of contiguous=20
> column-major matrices to call LAPACK).
I'm speaking of worse. Quantic chromodynic code requiring three=20
reordering of a 5 dimensions array in 3 different ordering inside a=20
single algorithm.
LAPACK compatibility is obviously a given.
> For those applications, it is reasonable to add a variation on the=20
> strided_array (later if possible) which allows the arbitrary=20
> reordering of the strides (as Lukasz was suggesting for a general=20
> solution)? It seems that anyone requiring arbitrary ordering is=20
> sophisticated enough to manually construct those sorts of views.
Is it really a strided_array ? in NT2 we have a compile-time dimension=20
permutation option (like table<float, storage_order<3,2,1,4> >) that we use
to metaprogram the correct loop orders. Striding around large, non=20
trivial subarray may lead to cache issues too. 90% of performance issues=20
is cache and memory related, it's improtant to be able to handle those=20
right.
> Joel, as one of the world experts in this area: is there a future=20
> proofing with alignment issues that needs to be added in the template=20
> interface? Maybe not getting 100% of the way there, but for 90% of=20
> the important applications and ensure that GPU/vectorization=20
> processing is possible with contiguous sub-arrays? It would be a=20
> shame if a design decision made it impossible to get an array_view on=20
> Eigen, GPU-oriented, and other important libraries (e.g.=20
> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.htm=
l)=20
> ? I imagine this pops up the graphics/geometry world as well and=20
> wanted to raise a flag.
>
Alignment issue is either dealt with allocator for complete array (our=20
boost.SIMD library have that and NT2 use it by default)
or by trying to detect when cosntructing a subarray that you statically=20
know that your view is aligned or not. We do that by allowing
static integral_constant to be passed into the sub array constructors.
For vectorization, most post Nehalem x86 architecture have good=20
performance on unalgined access. For GPU, IIRC NVIDIA was
working on lowering those constraints. The hardware world is probably=20
goign to lessen those issues.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------080703000502030002090901
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<div class=3D"moz-cite-prefix">Le 03/07/2014 18:49, Jesse Perla a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:f9b11122-27a6-48a4-aa3e-2bfda9e2432a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
On Thursday, July 3, 2014 2:29:53 AM UTC-7, Joel Falcou wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> As a developper of a
multidimensionnal array computing science library, I can
only say +1 to this. Storage order customization is
paramount<br>
to a lot of performances applications. There is also a non
trivial familly of applications related to physics and
chemistry where the most optimal<br>
code require an arbitrary succession of ordering changes.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, that popped up for me once as well (needed arrays of
contiguous column-major matrices to call LAPACK).=C2=A0 <br>
</div>
</div>
</blockquote>
<br>
I'm speaking of worse. Quantic chromodynic code requiring three
reordering of a 5 dimensions array in 3 different ordering inside a
single algorithm.<br>
LAPACK compatibility is obviously a given.<br>
<br>
<blockquote
cite=3D"mid:f9b11122-27a6-48a4-aa3e-2bfda9e2432a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>For those applications, it is reasonable to add a variation
on the strided_array (later if possible) which allows the
arbitrary reordering of the strides (as Lukasz was suggesting
for a general solution)? =C2=A0It seems that anyone requiring
arbitrary ordering is sophisticated enough to manually
construct those sorts of views.</div>
</div>
</blockquote>
Is it really a strided_array ? in NT2 we have a compile-time
dimension permutation option (like table<float,
storage_order<3,2,1,4> >) that we use<br>
to metaprogram the correct loop orders. Striding around large, non
trivial subarray may lead to cache issues too. 90% of performance
issues is cache and memory related, it's improtant to be able to
handle those right.<br>
<br>
<blockquote
cite=3D"mid:f9b11122-27a6-48a4-aa3e-2bfda9e2432a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div><span>Joel, as one of the world experts in this area: is
there a future proofing with alignment issues that needs
to be added in the template interface? =C2=A0Maybe not gettin=
g
100% of the way there, but for 90% of the important
applications and ensure that GPU/vectorization processing
is possible with contiguous sub-arrays? =C2=A0It would be a
shame if a design decision made it impossible to get an
array_view on Eigen, GPU-oriented, and other important
libraries (e.g. <a moz-do-not-send=3D"true"
class=3D"linkclass"
href=3D"http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAsse=
rt.html">http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAss=
ert.html</a>)
? =C2=A0I imagine this pops up the graphics/geometry world as
well and wanted to raise a flag.</span></div>
</div>
<br>
</div>
</blockquote>
<br>
Alignment issue is either dealt with allocator for complete array
(our boost.SIMD library have that and NT2 use it by default) <br>
or by trying to detect when cosntructing a subarray that you
statically know that your view is aligned or not. We do that by
allowing<br>
static integral_constant to be passed into the sub array
constructors.<br>
<br>
For vectorization, most post Nehalem x86 architecture have good
performance on unalgined access. For GPU, IIRC NVIDIA was <br>
working on lowering those constraints. The hardware world is
probably goign to lessen those issues.<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------080703000502030002090901--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Thu, 3 Jul 2014 10:55:45 -0700 (PDT)
Raw View
------=_Part_995_2253362.1404410145627
Content-Type: text/plain; charset=UTF-8
On Thursday, July 3, 2014 10:47:19 AM UTC-7, Joel Falcou wrote:
>
> Is it really a strided_array ? in NT2 we have a compile-time dimension
> permutation option (like table<float, storage_order<3,2,1,4> >) that we use
> to metaprogram the correct loop orders. Striding around large, non trivial
> subarray may lead to cache issues too. 90% of performance issues is cache
> and memory related, it's improtant to be able to handle those right.
>
> If there is a single template parameter for the storage ordering with a
default, then it looks like it could initially support row vs. column, and
then could be extended in future versions to another types with some sort
of integer sequence (consistent with the dimension) without breaking the
interface?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_995_2253362.1404410145627
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Thursday, July 3, 2014 10:47:19 AM UTC-7, Joel Falc=
ou wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">Is it really a strided_array ? =
in NT2 we have a compile-time
dimension permutation option (like table<float,
storage_order<3,2,1,4> >) that we use<br>
to metaprogram the correct loop orders. Striding around large, non
trivial subarray may lead to cache issues too. 90% of performance
issues is cache and memory related, it's improtant to be able to
handle those right.<br><br></div></blockquote><div>If there is a single=
template parameter for the storage ordering with a default, then it looks =
like it could initially support row vs. column, and then could be ext=
ended in future versions to another types with some sort of integer sequenc=
e (consistent with the dimension) without breaking the interface?</div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_995_2253362.1404410145627--
.
Author: Joel Falcou <joel.falcou@gmail.com>
Date: Thu, 03 Jul 2014 20:01:59 +0200
Raw View
This is a multi-part message in MIME format.
--------------000108040205000400040703
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 03/07/2014 19:55, Jesse Perla a =C3=A9crit :
>
> On Thursday, July 3, 2014 10:47:19 AM UTC-7, Joel Falcou wrote:
>
> Is it really a strided_array ? in NT2 we have a compile-time
> dimension permutation option (like table<float,
> storage_order<3,2,1,4> >) that we use
> to metaprogram the correct loop orders. Striding around large, non
> trivial subarray may lead to cache issues too. 90% of performance
> issues is cache and memory related, it's improtant to be able to
> handle those right.
>
> If there is a single template parameter for the storage ordering with=20
> a default, then it looks like it could initially support row vs.=20
> column, and then could be extended in future versions to another types=20
> with some sort of integer sequence (consistent with the dimension)=20
> without breaking the interface?
>
multi_array<typename Type, typename Ordering>
with row_ and col_major as type for Ordering
Yes that's enough and extensible.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------000108040205000400040703
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<div class=3D"moz-cite-prefix">Le 03/07/2014 19:55, Jesse Perla a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:7afcd5f7-f083-44e7-bb87-4feb6dc7bde3@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
On Thursday, July 3, 2014 10:47:19 AM UTC-7, Joel Falcou wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">Is it really a
strided_array ? in NT2 we have a compile-time dimension
permutation option (like table<float,
storage_order<3,2,1,4> >) that we use<br>
to metaprogram the correct loop orders. Striding around
large, non trivial subarray may lead to cache issues too.
90% of performance issues is cache and memory related, it's
improtant to be able to handle those right.<br>
<br>
</div>
</blockquote>
<div>If there is a single template parameter for the storage
ordering with a default, then it looks like it could initially
support =C2=A0row vs. column, and then could be extended in futur=
e
versions to another types with some sort of integer sequence
(consistent with the dimension) without breaking the
interface?</div>
</div>
<br>
</blockquote>
<br>
multi_array<typename Type, typename Ordering><br>
<br>
with row_ and col_major as type for Ordering<br>
<br>
Yes that's enough and extensible.<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000108040205000400040703--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Thu, 3 Jul 2014 11:20:48 -0700 (PDT)
Raw View
------=_Part_1054_26889365.1404411648390
Content-Type: text/plain; charset=UTF-8
On Thursday, July 3, 2014 11:02:04 AM UTC-7, Joel Falcou wrote:
>
>
>
> Yes that's enough and extensible.
>
> Sounds perfectly reasonable (with the dimensions parameter added before
the storage ordering, of course)
The only other thing I see that may be missing is the ability to get a
pointer to the origin/underlying data for array_view and
strided_array_view. While I think you can get the pointer with &myarray[0]
or something like that for the array_view case, I don't think it works for
the strided_array case as you really need to get a pointer to something not
accessible with the strided_array itself (e.g. imagine a slice of
[2][:][:], I believe the strides need to be measured from the origin of the
original data, but maybe I am wrong? Doesn't it also need to get the
origin offset?). Apologies if I missed something. See the implementation
of http://www.boost.org/doc/libs/1_41_0/boost/multi_array/view.hpp for a
good example.
An simple and complete set of use-cases for this is to ensure it can
support something like boost numeric_bindings for the array_view and
strided_array_view. For example:
http://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/eigen/matrix.hpp,
http://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/bindings/boost/multi_array.hpp
show how it was done for other libraries (though the boost::multi_array
interface is a proof of concept that doesn't support the full ordering or
the multi_array view)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1054_26889365.1404411648390
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Thursday, July 3, 2014 11:02:04 AM UTC-7, Joel Falc=
ou wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
<br>
Yes that's enough and extensible.<br>
<br></div></blockquote><div>Sounds perfectly reasonable (with the dimen=
sions parameter added before the storage ordering, of course)</div><div><br=
></div><div><span>The only other thing I see that may be missing is the abi=
lity to get a pointer to the origin/underlying data for array_view and stri=
ded_array_view. While I think you can get the pointer with &myarr=
ay[0] or something like that for the array_view case, I don't think it work=
s for the strided_array case as you really need to get a pointer to somethi=
ng not accessible with the strided_array itself (e.g. imagine a slice of [2=
][:][:], I believe the strides need to be measured from the origin of the o=
riginal data, but maybe I am wrong? Doesn't it also need to get the o=
rigin offset?). Apologies if I missed something. See the implem=
entation of <a class=3D"linkclass" href=3D"http://www.boost.org/doc/libs/1_=
41_0/boost/multi_array/view.hpp">http://www.boost.org/doc/libs/1_41_0/boost=
/multi_array/view.hpp</a> for a good example.</span></div><div><br></=
div><div><span>An simple and complete set of use-cases for this is to ensur=
e it can support something like boost numeric_bindings for the array_view a=
nd strided_array_view. For example: <a class=3D"linkclass" href=3D"ht=
tp://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/binding=
s/eigen/matrix.hpp">http://svn.boost.org/svn/boost/sandbox/numeric_bindings=
/boost/numeric/bindings/eigen/matrix.hpp</a>, <a class=3D"linkclass" href=
=3D"http://svn.boost.org/svn/boost/sandbox/numeric_bindings/boost/numeric/b=
indings/boost/multi_array.hpp">http://svn.boost.org/svn/boost/sandbox/numer=
ic_bindings/boost/numeric/bindings/boost/multi_array.hpp</a> show how it wa=
s done for other libraries (though the boost::multi_array interface is a pr=
oof of concept that doesn't support the full ordering or the multi_array vi=
ew)</span></div><div> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1054_26889365.1404411648390--
.
Author: Vincent Reverdy <vince.rev@gmail.com>
Date: Fri, 4 Jul 2014 21:40:00 -0700 (PDT)
Raw View
------=_Part_1_3969242.1404535200686
Content-Type: text/plain; charset=UTF-8
>
> multi_array<typename Type, typename Ordering>
>
> with row_ and col_major as type for Ordering
>
> Yes that's enough and extensible
>
From the point of view of a physicist using supercomputing facilities, I
can simply say +1000 to this...
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1_3969242.1404535200686
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><blockquote style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">multi_array<typename Type, typename Ordering><br>
<br>
with row_ and col_major as type for Ordering<br>
<br>
Yes that's enough and extensible<br></blockquote><div> <br>From the point of view of a physicist using supercomputing facilities, I can simply say +1000 to this...<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_1_3969242.1404535200686--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sun, 6 Jul 2014 15:21:49 -0700 (PDT)
Raw View
------=_Part_1366_13480117.1404685309864
Content-Type: text/plain; charset=UTF-8
>
> Firstly I think that the new template parameter more appropriately should
> be of an enum type rather than a typename. Secondly I think that this opens
> up for defining the "strided" array view within the same class template:
>
enum ordering_t { row_major, col_major, any_major };
template<typename T, int dims, ordering_t ordering> array_view;
Here any_major means that both indices are multiplied by a factor before
being added together to form the offset from the view's base pointer. This
is exactly what strided_array_view does. The reason for calling this
any_major is of course
that by providing multipliers on all indices both strided arrays and
row/column-ordered arrays can be handled at runtime.
This means that non-template functions can take array_view parameters of
any of these varieties, providing different types of usability/performance
tradeoff, while if the function is a template on the ordering it can
provide even more performance for the advantageous ordering.
Constructor parameters on the any_major specialization may be used to set
the strides specifically (even to non-multiples of the element size if need
be), while it should provide constructors from the other specializations
that set up the strides appropriately. More work needed here, but the
constructors of the strided_array_view as it stands now
provides guidance.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1366_13480117.1404685309864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Firstly I think that the new template parameter more appropriately shou=
ld be of an enum type rather than a typename. Secondly I think that this op=
ens up for defining the "strided" array view within the same class template=
:</div></blockquote><div><br></div><div>enum ordering_t { row_major, col_ma=
jor, any_major };</div><div>template<typename T, int dims, ordering_t or=
dering> array_view; </div><div><br></div><div>Here any_major means =
that both indices are multiplied by a factor before being added together to=
form the offset from the view's base pointer. This is exactly what strided=
_array_view does. The reason for calling this any_major is of course</div><=
div>that by providing multipliers on all indices both strided arrays and ro=
w/column-ordered arrays can be handled at runtime.</div><div><br></div><div=
>This means that non-template functions can take array_view parameters of a=
ny of these varieties, providing different types of usability/performance t=
radeoff, while if the function is a template on the ordering it can provide=
even more performance for the advantageous ordering.</div><div><br></div><=
div>Constructor parameters on the any_major specialization may be used to s=
et the strides specifically (even to non-multiples of the element size if n=
eed be), while it should provide constructors from the other specialization=
s that set up the strides appropriately. More work needed here, but the con=
structors of the strided_array_view as it stands now</div><div>provides gui=
dance.</div><div><br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1366_13480117.1404685309864--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Sun, 6 Jul 2014 15:32:17 -0700 (PDT)
Raw View
------=_Part_948_10299001.1404685937348
Content-Type: text/plain; charset=UTF-8
On Sunday, July 6, 2014 3:21:49 PM UTC-7, Bengt Gustafsson wrote:
>
> Firstly I think that the new template parameter more appropriately should
>> be of an enum type rather than a typename. Secondly I think that this opens
>> up for defining the "strided" array view within the same class template:
>>
>
> enum ordering_t { row_major, col_major, any_major };
> template<typename T, int dims, ordering_t ordering> array_view;
>
> Here any_major means that both indices are multiplied by a factor before
> being added together to form the offset from the view's base pointer. This
> is exactly what strided_array_view does. The reason for calling this
> any_major is of course
> that by providing multipliers on all indices both strided arrays and
> row/column-ordered arrays can be handled at runtime.
>
> I haven't seen a scenario where runtime support of dimension reordering is
necessary, and many where the static information is essential for
optimization (and static dispatching). Anyone who cares enough to have a
custom ordering is going to need to squeak out as much optimization as
possible. So I think that what Joel was saying is that by leaving it a
type instead of an enumerator, future versions of the interface could
accept a compile time integer sequence in that position. It could later,
of course, use a tag which says "any_major" if that becomes a useful
feature at some point.
Also note that by having a static parameter, there is no runtime storage
necessary for the orderings. You still just need the pointner to the data
and the array of extents (whose order stays invariant between storage
orderings). In the strided version, you still just need to add in a list
of strides (and maybe an offset?)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_948_10299001.1404685937348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Sunday, July 6, 2014 3:21:49 PM UTC-7, Bengt Gustaf=
sson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Firstly I think that=
the new template parameter more appropriately should be of an enum type ra=
ther than a typename. Secondly I think that this opens up for defining the =
"strided" array view within the same class template:</div></blockquote><div=
><br></div><div>enum ordering_t { row_major, col_major, any_major };</div><=
div>template<typename T, int dims, ordering_t ordering> array_view;&n=
bsp;</div><div><br></div><div>Here any_major means that both indices are mu=
ltiplied by a factor before being added together to form the offset from th=
e view's base pointer. This is exactly what strided_array_view does. The re=
ason for calling this any_major is of course</div><div>that by providing mu=
ltipliers on all indices both strided arrays and row/column-ordered arrays =
can be handled at runtime.</div><div><br></div></div></blockquote><div>I ha=
ven't seen a scenario where runtime support of dimension reordering is nece=
ssary, and many where the static information is essential for optimization =
(and static dispatching). Anyone who cares enough to have a custom or=
dering is going to need to squeak out as much optimization as possible. &nb=
sp;So I think that what Joel was saying is that by leaving it a type instea=
d of an enumerator, future versions of the interface could accept a compile=
time integer sequence in that position. It could later, of course, u=
se a tag which says "any_major" if that becomes a useful feature at some po=
int.</div><div><br></div><div>Also note that by having a static parameter, =
there is no runtime storage necessary for the orderings. You still ju=
st need the pointner to the data and the array of extents (whose order stay=
s invariant between storage orderings). In the strided version, you s=
till just need to add in a list of strides (and maybe an offset?)</div></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_948_10299001.1404685937348--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Mon, 7 Jul 2014 07:17:45 -0700 (PDT)
Raw View
------=_Part_1711_3269039.1404742665532
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Note that the enumerator is used as a template parameter, not a constructor=
=20
parameter, so this is just a technical detail compared to it being a=20
typename template parameter.
So when I talk about supporting both orderings this is by recompiling the=
=20
function for all combinations of orderings of its incoming parameters using=
=20
template instantiation. While obviously this still will generate the=20
fastest code for the major-ordering where the CPU accesses the data=20
sequentially it will still
generate more efficient code for the other case than if the ordering was a=
=20
constructor parameter. The any_ordering provides this functionality (and=20
striding) for cases where you don't want to have multiple template=20
instantiations, maybe due to space constraints or as you don't want to=20
reveal the used alrgortihms (IP issues).
Den m=C3=A5ndagen den 7:e juli 2014 kl. 00:32:17 UTC+2 skrev Jesse Perla:
>
>
> On Sunday, July 6, 2014 3:21:49 PM UTC-7, Bengt Gustafsson wrote:
>>
>> Firstly I think that the new template parameter more appropriately shoul=
d=20
>>> be of an enum type rather than a typename. Secondly I think that this o=
pens=20
>>> up for defining the "strided" array view within the same class template=
:
>>>
>>
>> enum ordering_t { row_major, col_major, any_major };
>> template<typename T, int dims, ordering_t ordering> array_view;=20
>>
>> Here any_major means that both indices are multiplied by a factor before=
=20
>> being added together to form the offset from the view's base pointer. Th=
is=20
>> is exactly what strided_array_view does. The reason for calling this=20
>> any_major is of course
>> that by providing multipliers on all indices both strided arrays and=20
>> row/column-ordered arrays can be handled at runtime.
>>
>> I haven't seen a scenario where runtime support of dimension reordering=
=20
> is necessary, and many where the static information is essential for=20
> optimization (and static dispatching). Anyone who cares enough to have a=
=20
> custom ordering is going to need to squeak out as much optimization as=20
> possible. So I think that what Joel was saying is that by leaving it a=
=20
> type instead of an enumerator, future versions of the interface could=20
> accept a compile time integer sequence in that position. It could later,=
=20
> of course, use a tag which says "any_major" if that becomes a useful=20
> feature at some point.
>
> Also note that by having a static parameter, there is no runtime storage=
=20
> necessary for the orderings. You still just need the pointner to the dat=
a=20
> and the array of extents (whose order stays invariant between storage=20
> orderings). In the strided version, you still just need to add in a list=
=20
> of strides (and maybe an offset?)
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1711_3269039.1404742665532
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Note that the enumerator is used as a template parameter, =
not a constructor parameter, so this is just a technical detail compared to=
it being a typename template parameter.<div><br></div><div>So when I talk =
about supporting both orderings this is by recompiling the function for all=
combinations of orderings of its incoming parameters using template instan=
tiation. While obviously this still will generate the fastest code for the =
major-ordering where the CPU accesses the data sequentially it will still</=
div><div>generate more efficient code for the other case than if the orderi=
ng was a constructor parameter. The any_ordering provides this functionalit=
y (and striding) for cases where you don't want to have multiple template i=
nstantiations, maybe due to space constraints or as you don't want to revea=
l the used alrgortihms (IP issues).<br><div><br><br>Den m=C3=A5ndagen den 7=
:e juli 2014 kl. 00:32:17 UTC+2 skrev Jesse Perla:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><br>On Sunday, July 6, 2014 3:21:49 PM=
UTC-7, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">First=
ly I think that the new template parameter more appropriately should be of =
an enum type rather than a typename. Secondly I think that this opens up fo=
r defining the "strided" array view within the same class template:</div></=
blockquote><div><br></div><div>enum ordering_t { row_major, col_major, any_=
major };</div><div>template<typename T, int dims, ordering_t ordering>=
; array_view; </div><div><br></div><div>Here any_major means that both=
indices are multiplied by a factor before being added together to form the=
offset from the view's base pointer. This is exactly what strided_array_vi=
ew does. The reason for calling this any_major is of course</div><div>that =
by providing multipliers on all indices both strided arrays and row/column-=
ordered arrays can be handled at runtime.</div><div><br></div></div></block=
quote><div>I haven't seen a scenario where runtime support of dimension reo=
rdering is necessary, and many where the static information is essential fo=
r optimization (and static dispatching). Anyone who cares enough to h=
ave a custom ordering is going to need to squeak out as much optimization a=
s possible. So I think that what Joel was saying is that by leaving i=
t a type instead of an enumerator, future versions of the interface could a=
ccept a compile time integer sequence in that position. It could late=
r, of course, use a tag which says "any_major" if that becomes a useful fea=
ture at some point.</div><div><br></div><div>Also note that by having a sta=
tic parameter, there is no runtime storage necessary for the orderings. &nb=
sp;You still just need the pointner to the data and the array of extents (w=
hose order stays invariant between storage orderings). In the strided=
version, you still just need to add in a list of strides (and maybe an off=
set?)</div></div></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1711_3269039.1404742665532--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Mon, 7 Jul 2014 08:56:53 -0700 (PDT)
Raw View
------=_Part_522_2613273.1404748613550
Content-Type: text/plain; charset=UTF-8
On Monday, July 7, 2014 7:17:45 AM UTC-7, Bengt Gustafsson wrote:
>
> Note that the enumerator is used as a template parameter, not a
> constructor parameter, so this is just a technical detail compared to it
> being a typename template parameter.
>
Besides being brittle to changes, an enumeration parameter (as opposed to a
type parameter) cannot hold a list of compile-time integers. So if there
is an "any_order" enumeration, then either runtime storage is required for
the orderings (even for column or row major orders where it is ignored) and
meta-programming optimizations are not possible, or an additional type
template parameter for a compile-time integer array is required. The
alternative is having a type parameter with the tag structs passed as
parameters, which allows the same flexibility as an enumeration as well as
the ability to pass in a list of static integers at some point in the
future.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_522_2613273.1404748613550
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, July 7, 2014 7:17:45 AM UTC-7, Bengt Gustafsson=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Note t=
hat the enumerator is used as a template parameter, not a constructor param=
eter, so this is just a technical detail compared to it being a typename te=
mplate parameter.</div></blockquote><div><br></div><div>Besides being britt=
le to changes, an enumeration parameter (as opposed to a type parameter) ca=
nnot hold a list of compile-time integers. So if there is an "any_ord=
er" enumeration, then either runtime storage is required for the orderings =
(even for column or row major orders where it is ignored) and meta-programm=
ing optimizations are not possible, or an additional type template paramete=
r for a compile-time integer array is required. The alternative is ha=
ving a type parameter with the tag structs passed as parameters, which allo=
ws the same flexibility as an enumeration as well as the ability to pass in=
a list of static integers at some point in the future.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_522_2613273.1404748613550--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 8 Jul 2014 02:54:44 -0700 (PDT)
Raw View
------=_Part_47_25275895.1404813284564
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Well, I was thinking of specializing on the enum value. Sorry for not=20
pointing that out explicitly.
Actually I have a problem of interpreting your comment. Now you talk about=
=20
compile-time integers which seems to be related to fixed size arrays, which=
=20
you previously seemed uninterested in. The second sentence with a type=20
parameter taking "the" tag struct I don't understand at all. Maybe a code=
=20
sample would make things easier to understand.
I think this still boils down to the question of use case: Is the=20
array_view to be a non-template parameter of a function with external=20
linkage. In that case there are only two possibilities: Going with the=20
strided_array_view or my equivalent array_view<any_order> or locking the=20
caller to a perticular storage order. Hiding templated code behind a=20
non-templated facade is also possible of course, but in that case it seems=
=20
that a plain if on the first or last index having a stride of 1 seems to be=
=20
the best choice as it allows speed up of also the general=20
strided_array_view case if it "happens" to have a stride of one in a=20
particular call. A GetOrdering() method would not catch this case...
The other case is that the array_view parameter is templated, in which case=
=20
I don't really see the point of array_view at all except as a way to=20
reorganize the underlying (such as a std::vector or just a memory block) in=
=20
a way so that a standardized indexing operator is available inside the=20
instantiated function. Adaptation of matrix classes from third part=20
libraries are usually not necessary and if APIs mismatch you can easily=20
write your own wrapper. array_view becomes more a concept than a real class=
..
I have been advocating for unifying this with the (one dimensional) range=
=20
concept before, and it still seems appealing to try to generalize ranges to=
=20
multiple dimensions rather than inventing a parallel concept with the same=
=20
features. This points towards seeing array_view as something to use in a=20
non-templated function call, and I think this was the intention of the=20
original proposers. The original proposers included two cases and used two=
=20
names for them: array_view and strided_array_view. Many have suggested that=
=20
a third option is needed (and I agree to that). Following in the tracks of=
=20
the original proposers this could be a third name such as=20
fortran_array_view or row_major_array_view but I think that an extra=20
template parameter would be more appropriate as it clutters the std::=20
namespace up less. I don't think that mixing the methods so that we have=20
two names in the name spaces whereof one has two variations controlled by a=
=20
template parameter is the right way to go.
Whether the new template parameter is a 'typename' or 'enum' parameter may=
=20
be less important, but as long as we talking about the non-template use=20
case we can't support an infinite number of variations but basically use=20
the different array_view variants to limit what type of data can be sent to=
=20
the function, forcing a compile time error if the data is inappropriately=
=20
organized.
Den m=C3=A5ndagen den 7:e juli 2014 kl. 17:56:54 UTC+2 skrev Jesse Perla:
>
> On Monday, July 7, 2014 7:17:45 AM UTC-7, Bengt Gustafsson wrote:
>>
>> Note that the enumerator is used as a template parameter, not a=20
>> constructor parameter, so this is just a technical detail compared to it=
=20
>> being a typename template parameter.
>>
>
> Besides being brittle to changes, an enumeration parameter (as opposed to=
=20
> a type parameter) cannot hold a list of compile-time integers. So if the=
re=20
> is an "any_order" enumeration, then either runtime storage is required fo=
r=20
> the orderings (even for column or row major orders where it is ignored) a=
nd=20
> meta-programming optimizations are not possible, or an additional type=20
> template parameter for a compile-time integer array is required. The=20
> alternative is having a type parameter with the tag structs passed as=20
> parameters, which allows the same flexibility as an enumeration as well a=
s=20
> the ability to pass in a list of static integers at some point in the=20
> future.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_47_25275895.1404813284564
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well, I was thinking of specializing on the enum value. So=
rry for not pointing that out explicitly.<div><br></div><div><span style=3D=
"font-size: 13px;">Actually I have a problem of interpreting your comment. =
Now you talk about compile-time integers which seems to be related to fixed=
size arrays, which you previously seemed uninterested in. The second sente=
nce with a type parameter taking "the" tag struct I don't understand at all=
.. Maybe a code sample would make things easier to understand.</span><br></d=
iv><div><span style=3D"font-size: 13px;"><br></span></div><div><span style=
=3D"font-size: 13px;">I think this still boils down to the question of use =
case: Is the array_view to be a non-template parameter of a function with e=
xternal linkage. In that case there are only two possibilities: Going with =
the strided_array_view or my equivalent array_view<any_order> or lock=
ing the caller to a perticular storage order. Hiding templated code behind =
a non-templated facade is also possible of course, but in that case it seem=
s that a plain if on the first or last index having a stride of 1 seems to =
be the best choice as it allows speed up of also the general strided_array_=
view case if it "happens" to have a stride of one in a particular call. A G=
etOrdering() method would not catch this case...</span></div><div><span sty=
le=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-size: 13p=
x;">The other case is that the array_view parameter is templated, in which =
case I don't really see the point of array_view at all except as a way to r=
eorganize the underlying (such as a std::vector or just a memory block) in =
a way so that a standardized indexing operator is available inside the inst=
antiated function. Adaptation of matrix classes from third part libraries a=
re usually not necessary and if APIs mismatch you can easily write your own=
wrapper. array_view becomes more a concept than a real class.</span></div>=
<div><span style=3D"font-size: 13px;"><br></span></div><div><span style=3D"=
font-size: 13px;">I have been advocating for unifying this with the (one di=
mensional) range concept before, and it still seems appealing to try to gen=
eralize ranges to multiple dimensions rather than inventing a parallel conc=
ept with the same features. This points towards seeing array_view as someth=
ing to use in a non-templated function call, and I think this was the inten=
tion of the original proposers. The original proposers included two cases a=
nd used two names for them: array_view and strided_array_view. Many have su=
ggested that a third option is needed (and I agree to that). Following in t=
he tracks of the original proposers this could be a third name such as fort=
ran_array_view or row_major_array_view but I think that an extra template p=
arameter would be more appropriate as it clutters the std:: namespace up le=
ss. I don't think that mixing the methods so that we have two names in the =
name spaces whereof one has two variations controlled by a template paramet=
er is the right way to go.</span></div><div><span style=3D"font-size: 13px;=
"><br></span></div><div>Whether the new template parameter is a 'typename' =
or 'enum' parameter may be less important, but as long as we talking about =
the non-template use case we can't support an infinite number of variations=
but basically use the different array_view variants to limit what type of =
data can be sent to the function, forcing a compile time error if the data =
is inappropriately organized.</div><div><span style=3D"font-size: 13px;"><b=
r></span></div><div><br>Den m=C3=A5ndagen den 7:e juli 2014 kl. 17:56:54 UT=
C+2 skrev Jesse Perla:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Monday, July 7, 2014 7:17:45 AM UTC-7, Bengt Gustafsson wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Note that the enume=
rator is used as a template parameter, not a constructor parameter, so this=
is just a technical detail compared to it being a typename template parame=
ter.</div></blockquote><div><br></div><div>Besides being brittle to changes=
, an enumeration parameter (as opposed to a type parameter) cannot hold a l=
ist of compile-time integers. So if there is an "any_order" enumerati=
on, then either runtime storage is required for the orderings (even for col=
umn or row major orders where it is ignored) and meta-programming optimizat=
ions are not possible, or an additional type template parameter for a compi=
le-time integer array is required. The alternative is having a type p=
arameter with the tag structs passed as parameters, which allows the same f=
lexibility as an enumeration as well as the ability to pass in a list of st=
atic integers at some point in the future.</div></div></blockquote></div></=
div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_47_25275895.1404813284564--
.
Author: Jesse Perla <jesseperla@gmail.com>
Date: Tue, 8 Jul 2014 09:52:25 -0700 (PDT)
Raw View
------=_Part_533_30054011.1404838345964
Content-Type: text/plain; charset=UTF-8
On Tuesday, July 8, 2014 2:54:44 AM UTC-7, Bengt Gustafsson wrote:
>
> Well, I was thinking of specializing on the enum value. Sorry for not
> pointing that out explicitly.
>
> Actually I have a problem of interpreting your comment. Now you talk about
> compile-time integers which seems to be related to fixed size arrays, which
> you previously seemed uninterested in. The second sentence with a type
> parameter taking "the" tag struct I don't understand at all. Maybe a code
> sample would make things easier to understand.
>
> The storage ordering and the fixed extent versions are orthogonal. I am
100% sure that a fixed extent version of this will come down the pipe
eventually, but it isn't necessary in the first release. To expand on what
Joel was proposing.
*For the initial proposal:*
struct column_major_order{}; //tag structs, allow for the standard
dispatching pattern in an implementation.
struct row_major_order{};
multi_array_view<typename T, int N = 1, typename Ordering =
std::row_major_order>
requires DimensionCompatibleOrdering<N, Ordering> //or whatever. see
the note at the bottom of this page. Need some way to ensure consistency
of ordering and dimension when they get fancier.
{
T* data_;
std::size_t[N] extents_;
//NOTE: NO NEED FOR ANY RUNTIME STORAGE TO HANDLE ORDERING. EVER.
//In a strided_multi_array_view, would also need to a std::size_t[N]
strides_; and a T* origin_, but that is independent of the storage ordering.
}
*Usage:*
multi_array_view<double>
multi_array_view<double, 2>
multi_array_view<double, 2, std::column_major_order>
*Eventually, in the future based on the sorts of optimizations that Joel is
talking about:*
template<int Order...>
struct storage_order : std::integer_list<Order...> {}; //or whatever it
ends up being, I have always just used MPL.
Which allows things like:
multi_array_view<double, 3, std::storage_order<1,3,2>>
No changes to the interface or storage requirements of the class, just
changes in the internal dispatching of how items are accessed with
dispatching based on the StorageOrder parameter.
This design us everything we want, except for runtime changes in the
storage ordering, which is a reasonable compromise to make. If you have
such a crazy algorithm that you need to change ordering on the fly within
the same object, then you are on your own. The only thing I am imagine for
this is a cheap transpose operation where you can cheat by changing from
column_major to row_major without moving data and if you reverse the
extents then you now transposed. But you could also just have an externtal
"cheap_transpose" function which generates a new array_view by pointing at
the same underlying data and then reversing the extents.
*Fixed Size Extents for some future proposal:*
fixed_multi_array_view<typename T, int Extents..., typename Ordering =
std::row_major_order> //(alternatively, may want to have the list of
extents passed in as a static integer_list as well to avoid the variadic
templates.).
{
T* data_;
//No longer need extents, can access them statically.
//Even in the fixed_strided_multi_array_view, the strides and offset
should be stored as passed in as static parameters. No reason for this to
hold anything other than a pointer.
}
*Usage* (for a 12x1, 12x20 vector and 12x40
fixed_multi_array_view<double, 12>
fixed_multi_array_view<double, 12, 20, std::column_major_order>
fixed_multi_array_view<double, 12, 20, 40, std::column_major_order>
fixed_multi_array_view<double, 12, 20, 40, std::storage_order<1,3,2>>
*DimensionCompatibleOrdering*
After future extensions happen, will need to check that the extents are
compatible with the dimension:
template<typename T, int N>
concept DimensionCompatibleOrdering
{
return std::equal<T, std::column_major> //Pseudocode below
|| std::equal<T, std::row_major>
|| std::equal<mpl::sort<T>, std::integer_sequence<N>> //i.e. make sure
that a sorted version of the ordering is identical to 1,2,....N
}
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_533_30054011.1404838345964
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Tuesday, July 8, 2014 2:54:44 AM UTC-7, Bengt Gusta=
fsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">W=
ell, I was thinking of specializing on the enum value. Sorry for not pointi=
ng that out explicitly.<div><br></div><div><span style=3D"font-size:13px">A=
ctually I have a problem of interpreting your comment. Now you talk about c=
ompile-time integers which seems to be related to fixed size arrays, which =
you previously seemed uninterested in. The second sentence with a type para=
meter taking "the" tag struct I don't understand at all. Maybe a code sampl=
e would make things easier to understand.</span><br></div><div><br></div></=
div></blockquote><div>The storage ordering and the fixed extent versions ar=
e orthogonal. I am 100% sure that a fixed extent version of this will=
come down the pipe eventually, but it isn't necessary in the first release=
.. To expand on what Joel was proposing.</div><div><br></div><div><b>F=
or the initial proposal:</b></div><div>struct column_major_order{}; //tag s=
tructs, allow for the standard dispatching pattern in an implementation.</d=
iv><div>struct row_major_order{};<br></div><div><br></div><span style=3D"fo=
nt-family: arial, sans-serif; font-size: 12.727272033691406px;">multi_array=
_view<typename T, int N =3D 1, typename Ordering =3D std::row_major_orde=
r></span><div><font face=3D"arial, sans-serif"> requires Di=
mensionCompatibleOrdering<N, Ordering> //or whatever. see the n=
ote at the bottom of this page. Need some way to ensure consistency o=
f ordering and dimension when they get fancier.<br></font><div><font face=
=3D"arial, sans-serif">{</font></div><div><font face=3D"arial, sans-serif">=
T* data_;</font></div><div><font face=3D"arial, sans-serif">&n=
bsp; std::size_t[N] extents_;</font></div><div><font face=3D"arial, s=
ans-serif"><br></font></div><div><font face=3D"arial, sans-serif"> &n=
bsp;//NOTE: NO NEED FOR ANY RUNTIME STORAGE TO HANDLE ORDERING. EVER.=
</font></div><div><font face=3D"arial, sans-serif"> //In a stri=
ded_multi_array_view, would also need to a std::size_t[N] strides_; and a T=
* origin_, but that is independent of the storage ordering.</font></div><di=
v><font face=3D"arial, sans-serif">}</font></div><div><font face=3D"arial, =
sans-serif"><br></font></div><div><b style=3D"font-family: arial, sans-seri=
f;">Usage:</b><br></div><div><span style=3D"font-family: arial, sans-serif;=
">multi_array_view<double></span><font face=3D"arial, sans-serif"><b>=
<br></b></font></div><div><span style=3D"font-family: arial, sans-serif;">m=
ulti_array_view<double, 2></span><font face=3D"arial, sans-serif"><br=
></font></div><div><span style=3D"font-family: arial, sans-serif;">multi_ar=
ray_view<double, 2, std::column_major_order></span><span style=3D"fon=
t-family: arial, sans-serif;"><br></span></div><div><div><br style=3D"font-=
family: arial, sans-serif; font-size: 12.727272033691406px;"><b>Eventually,=
in the future based on the sorts of optimizations that Joel is talking abo=
ut:</b></div><div>template<int Order...></div><div>struct storage_ord=
er : std::integer_list<Order...> {}; //or whatever it ends up b=
eing, I have always just used MPL.</div><div><br></div><div>Which allows th=
ings like:</div><div>multi_array_view<double, 3, std::storage_order<1=
,3,2>></div><div><br></div><div>No changes to the interface or storag=
e requirements of the class, just changes in the internal dispatching of ho=
w items are accessed with dispatching based on the StorageOrder parameter.<=
/div><div><br></div><div><div><font face=3D"arial, sans-serif">This design =
us everything we want, except for runtime changes in the storage =
ordering, which is a reasonable compromise to make. If you =
have such a crazy algorithm that you need to change ordering on the fly wit=
hin the same object, then you are on your own. The only thing I am im=
agine for this is a cheap transpose operation where you can cheat by changi=
ng from column_major to row_major without moving data and if you reverse th=
e extents then you now transposed. But you could also just have an ex=
terntal "cheap_transpose" function which generates a new array_view by poin=
ting at the same underlying data and then reversing the extents.</font></di=
v></div><div><font face=3D"arial, sans-serif"><br></font></div><div><br></d=
iv><div><b><u>Fixed Size Extents for some future proposal:</u></b></div><di=
v><span style=3D"font-size: 12.727272033691406px;">fixed_</span><span style=
=3D"font-size: 12.727272033691406px; font-family: arial, sans-serif;">multi=
_array_view<typename T, int Extents..., typename Ordering =3D std::row_m=
ajor_order> //</span><span style=3D"font-family: arial, sans-serif;">(al=
ternatively, may want to have the list of extents passed in as a static int=
eger_list as well to avoid the variadic templates.).</span></div><div><span=
style=3D"font-family: arial, sans-serif;">{</span></div><div><span style=
=3D"font-family: arial, sans-serif;"> T* data_;</span></div><di=
v><span style=3D"font-family: arial, sans-serif;"> //No longer =
need extents, can access them statically.</span></div><div><font face=3D"ar=
ial, sans-serif"> //Even in the fixed_strided_multi_array_view,=
the strides and offset should be stored as passed in as static parameters.=
No reason for this to hold anything other than a pointer.</font></di=
v><div><span style=3D"font-family: arial, sans-serif;">}</span><br></div><d=
iv><div><br></div><div><font face=3D"arial, sans-serif"><b>Usage</b> (for a=
12x1, 12x20 vector and 12x40</font></div><div><span style=3D"font-family: =
arial, sans-serif;">fixed_multi_array_view<double, 12></span><font fa=
ce=3D"arial, sans-serif"><b><br></b></font></div><div><span style=3D"font-f=
amily: arial, sans-serif;">fixed_</span><span style=3D"font-family: arial, =
sans-serif;">multi_array_view<double, 12, 20, std::column_major_order>=
;</span></div></div></div><div><span style=3D"font-family: arial, sans-seri=
f;">fixed_</span><span style=3D"font-family: arial, sans-serif;">multi_arra=
y_view<double, 12, 20, 40, std::column_major_order></span><span style=
=3D"font-family: arial, sans-serif;"><br></span></div><div><span style=3D"f=
ont-family: arial, sans-serif;">fixed_</span><span style=3D"font-family: ar=
ial, sans-serif;">multi_array_view<double, 12, 20, 40, std::storage_orde=
r<1,3,2>></span><span style=3D"font-family: arial, sans-serif;"><b=
r></span></div><div><br></div><div><span style=3D"font-family: arial, sans-=
serif;"><br></span></div><div><b><u><span style=3D"font-family: arial, sans=
-serif;">DimensionCompatibleOrdering</span></u></b><br></div></div><div><sp=
an style=3D"font-family: arial, sans-serif;">After future extensions happen=
, will need to check that the extents are compatible with the dimension:</s=
pan></div><div><span style=3D"font-family: arial, sans-serif;">template<=
typename T, int N></span></div><div><span style=3D"font-family: arial, s=
ans-serif;">concept DimensionCompatibleOrdering</span></div><div><span styl=
e=3D"font-family: arial, sans-serif;">{</span></div><div><font face=3D"aria=
l, sans-serif">return std::equal<T, std::column_major> //Pseudocode b=
elow</font></div><div><span style=3D"font-family: arial, sans-serif;"> =
; || std::equal<T, std::row_major></span></div><div><span styl=
e=3D"font-family: arial, sans-serif;"> || std::equal<mpl::so=
rt<T>, std::integer_sequence<N>> //i.e. make sure that a sor=
ted version of the ordering is identical to 1,2,....N</span></div><div><spa=
n style=3D"font-family: arial, sans-serif;">}</span><br></div><div><span st=
yle=3D"font-family: arial, sans-serif;"><b><br></b></span></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_533_30054011.1404838345964--
.
Author: phdofthehouse@gmail.com
Date: Fri, 14 Nov 2014 13:32:21 -0800 (PST)
Raw View
------=_Part_754_624679614.1416000742153
Content-Type: text/plain; charset=UTF-8
This is actually what I've been looking for out of the array_view proposal.
I had actually separated mine into buffer_view for the runtime version, and
array_view for the compile-time version. The only thing I haven't done is
the storage_order bits, which look like they would help fantastically.
I hope this is added to the proposal.
On Tuesday, July 8, 2014 12:52:26 PM UTC-4, Jesse Perla wrote:
>
>
> On Tuesday, July 8, 2014 2:54:44 AM UTC-7, Bengt Gustafsson wrote:
>>
>> Well, I was thinking of specializing on the enum value. Sorry for not
>> pointing that out explicitly.
>>
>> Actually I have a problem of interpreting your comment. Now you talk
>> about compile-time integers which seems to be related to fixed size arrays,
>> which you previously seemed uninterested in. The second sentence with a
>> type parameter taking "the" tag struct I don't understand at all. Maybe a
>> code sample would make things easier to understand.
>>
>> The storage ordering and the fixed extent versions are orthogonal. I am
> 100% sure that a fixed extent version of this will come down the pipe
> eventually, but it isn't necessary in the first release. To expand on what
> Joel was proposing.
>
> *For the initial proposal:*
> struct column_major_order{}; //tag structs, allow for the standard
> dispatching pattern in an implementation.
> struct row_major_order{};
>
> multi_array_view<typename T, int N = 1, typename Ordering =
> std::row_major_order>
> requires DimensionCompatibleOrdering<N, Ordering> //or whatever. see
> the note at the bottom of this page. Need some way to ensure consistency
> of ordering and dimension when they get fancier.
> {
> T* data_;
> std::size_t[N] extents_;
>
> //NOTE: NO NEED FOR ANY RUNTIME STORAGE TO HANDLE ORDERING. EVER.
> //In a strided_multi_array_view, would also need to a std::size_t[N]
> strides_; and a T* origin_, but that is independent of the storage ordering.
> }
>
> *Usage:*
> multi_array_view<double>
> multi_array_view<double, 2>
> multi_array_view<double, 2, std::column_major_order>
>
> *Eventually, in the future based on the sorts of optimizations that Joel
> is talking about:*
> template<int Order...>
> struct storage_order : std::integer_list<Order...> {}; //or whatever it
> ends up being, I have always just used MPL.
>
> Which allows things like:
> multi_array_view<double, 3, std::storage_order<1,3,2>>
>
> No changes to the interface or storage requirements of the class, just
> changes in the internal dispatching of how items are accessed with
> dispatching based on the StorageOrder parameter.
>
> This design us everything we want, except for runtime changes in the
> storage ordering, which is a reasonable compromise to make. If you have
> such a crazy algorithm that you need to change ordering on the fly within
> the same object, then you are on your own. The only thing I am imagine for
> this is a cheap transpose operation where you can cheat by changing from
> column_major to row_major without moving data and if you reverse the
> extents then you now transposed. But you could also just have an externtal
> "cheap_transpose" function which generates a new array_view by pointing at
> the same underlying data and then reversing the extents.
>
>
> *Fixed Size Extents for some future proposal:*
> fixed_multi_array_view<typename T, int Extents..., typename Ordering =
> std::row_major_order> //(alternatively, may want to have the list of
> extents passed in as a static integer_list as well to avoid the variadic
> templates.).
> {
> T* data_;
> //No longer need extents, can access them statically.
> //Even in the fixed_strided_multi_array_view, the strides and offset
> should be stored as passed in as static parameters. No reason for this to
> hold anything other than a pointer.
> }
>
> *Usage* (for a 12x1, 12x20 vector and 12x40
> fixed_multi_array_view<double, 12>
> fixed_multi_array_view<double, 12, 20, std::column_major_order>
> fixed_multi_array_view<double, 12, 20, 40, std::column_major_order>
> fixed_multi_array_view<double, 12, 20, 40, std::storage_order<1,3,2>>
>
>
> *DimensionCompatibleOrdering*
> After future extensions happen, will need to check that the extents are
> compatible with the dimension:
> template<typename T, int N>
> concept DimensionCompatibleOrdering
> {
> return std::equal<T, std::column_major> //Pseudocode below
> || std::equal<T, std::row_major>
> || std::equal<mpl::sort<T>, std::integer_sequence<N>> //i.e. make sure
> that a sorted version of the ordering is identical to 1,2,....N
> }
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_754_624679614.1416000742153
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is actually what I've been looking for out of the arr=
ay_view proposal. I had actually separated mine into buffer_view for the ru=
ntime version, and array_view for the compile-time version. The only thing =
I haven't done is the storage_order bits, which look like they would help f=
antastically.<br><br>I hope this is added to the proposal.<br><br>On Tuesda=
y, July 8, 2014 12:52:26 PM UTC-4, Jesse Perla wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><br>On Tuesday, July 8, 2014 2:54:4=
4 AM UTC-7, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">Well, I was thinking of specializing on the enum value. S=
orry for not pointing that out explicitly.<div><br></div><div><span style=
=3D"font-size:13px">Actually I have a problem of interpreting your comment.=
Now you talk about compile-time integers which seems to be related to fixe=
d size arrays, which you previously seemed uninterested in. The second sent=
ence with a type parameter taking "the" tag struct I don't understand at al=
l. Maybe a code sample would make things easier to understand.</span><br></=
div><div><br></div></div></blockquote><div>The storage ordering and the fix=
ed extent versions are orthogonal. I am 100% sure that a fixed extent=
version of this will come down the pipe eventually, but it isn't necessary=
in the first release. To expand on what Joel was proposing.</div><di=
v><br></div><div><b>For the initial proposal:</b></div><div>struct column_m=
ajor_order{}; //tag structs, allow for the standard dispatching pattern in =
an implementation.</div><div>struct row_major_order{};<br></div><div><br></=
div><span style=3D"font-family:arial,sans-serif;font-size:12.72727203369140=
6px">multi_array_view<typename T, int N =3D 1, typename Ordering =3D std=
::row_major_order></span><div><font face=3D"arial, sans-serif"> &n=
bsp; requires DimensionCompatibleOrdering<N, Ordering> //or whatever.=
see the note at the bottom of this page. Need some way to ensu=
re consistency of ordering and dimension when they get fancier.<br></font><=
div><font face=3D"arial, sans-serif">{</font></div><div><font face=3D"arial=
, sans-serif"> T* data_;</font></div><div><font face=3D"arial, =
sans-serif"> std::size_t[N] extents_;</font></div><div><font fa=
ce=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-se=
rif"> //NOTE: NO NEED FOR ANY RUNTIME STORAGE TO HANDLE ORDERIN=
G. EVER.</font></div><div><font face=3D"arial, sans-serif"> &nb=
sp;//In a strided_multi_array_view, would also need to a std::size_t[N] str=
ides_; and a T* origin_, but that is independent of the storage ordering.</=
font></div><div><font face=3D"arial, sans-serif">}</font></div><div><font f=
ace=3D"arial, sans-serif"><br></font></div><div><b style=3D"font-family:ari=
al,sans-serif">Usage:</b><br></div><div><span style=3D"font-family:arial,sa=
ns-serif">multi_array_view<double></span><font face=3D"arial, sans-se=
rif"><b><br></b></font></div><div><span style=3D"font-family:arial,sans-ser=
if">multi_array_view<double, 2></span><font face=3D"arial, sans-serif=
"><br></font></div><div><span style=3D"font-family:arial,sans-serif">multi_=
array_view<double, 2, std::column_major_order></span><span style=3D"f=
ont-family:arial,sans-serif"><br></span></div><div><div><br style=3D"font-f=
amily:arial,sans-serif;font-size:12.727272033691406px"><b>Eventually, in th=
e future based on the sorts of optimizations that Joel is talking about:</b=
></div><div>template<int Order...></div><div>struct storage_order : s=
td::integer_list<Order...> {}; //or whatever it ends up being, =
I have always just used MPL.</div><div><br></div><div>Which allows things l=
ike:</div><div>multi_array_view<double, 3, std::storage_order<1,3,2&g=
t;></div><div><br></div><div>No changes to the interface or storage requ=
irements of the class, just changes in the internal dispatching of how item=
s are accessed with dispatching based on the StorageOrder parameter.</div><=
div><br></div><div><div><font face=3D"arial, sans-serif">This design us&nbs=
p;everything we want, except for runtime changes in the storage orderi=
ng, which is a reasonable compromise to make. If you have s=
uch a crazy algorithm that you need to change ordering on the fly within th=
e same object, then you are on your own. The only thing I am imagine =
for this is a cheap transpose operation where you can cheat by changing fro=
m column_major to row_major without moving data and if you reverse the exte=
nts then you now transposed. But you could also just have an externta=
l "cheap_transpose" function which generates a new array_view by pointing a=
t the same underlying data and then reversing the extents.</font></div></di=
v><div><font face=3D"arial, sans-serif"><br></font></div><div><br></div><di=
v><b><u>Fixed Size Extents for some future proposal:</u></b></div><div><spa=
n style=3D"font-size:12.727272033691406px">fixed_</span><span style=3D"font=
-size:12.727272033691406px;font-family:arial,sans-serif">multi_array_view&l=
t;<wbr>typename T, int Extents..., typename Ordering =3D std::row_major_ord=
er> //</span><span style=3D"font-family:arial,sans-serif">(alternatively=
, may want to have the list of extents passed in as a static integer_list a=
s well to avoid the variadic templates.).</span></div><div><span style=3D"f=
ont-family:arial,sans-serif">{</span></div><div><span style=3D"font-family:=
arial,sans-serif"> T* data_;</span></div><div><span style=3D"fo=
nt-family:arial,sans-serif"> //No longer need extents, can acce=
ss them statically.</span></div><div><font face=3D"arial, sans-serif"> =
; //Even in the fixed_strided_multi_array_<wbr>view, the strides and =
offset should be stored as passed in as static parameters. No reason =
for this to hold anything other than a pointer.</font></div><div><span styl=
e=3D"font-family:arial,sans-serif">}</span><br></div><div><div><br></div><d=
iv><font face=3D"arial, sans-serif"><b>Usage</b> (for a 12x1, 12x20 vector =
and 12x40</font></div><div><span style=3D"font-family:arial,sans-serif">fix=
ed_multi_array_view<double, 12></span><font face=3D"arial, sans-serif=
"><b><br></b></font></div><div><span style=3D"font-family:arial,sans-serif"=
>fixed_</span><span style=3D"font-family:arial,sans-serif">multi_array_view=
<double, 12, 20, std::column_major_order></span></div></div></div><di=
v><span style=3D"font-family:arial,sans-serif">fixed_</span><span style=3D"=
font-family:arial,sans-serif">multi_array_view<double, 12, 20, 40, std::=
column_major_order></span><span style=3D"font-family:arial,sans-serif"><=
br></span></div><div><span style=3D"font-family:arial,sans-serif">fixed_</s=
pan><span style=3D"font-family:arial,sans-serif">multi_array_view<double=
, 12, 20, 40, std::storage_order<1,3,2>></span><span style=3D"font=
-family:arial,sans-serif"><br></span></div><div><br></div><div><span style=
=3D"font-family:arial,sans-serif"><br></span></div><div><b><u><span style=
=3D"font-family:arial,sans-serif">DimensionCompatibleOrdering</span></u></b=
><br></div></div><div><span style=3D"font-family:arial,sans-serif">After fu=
ture extensions happen, will need to check that the extents are compatible =
with the dimension:</span></div><div><span style=3D"font-family:arial,sans-=
serif">template<typename T, int N></span></div><div><span style=3D"fo=
nt-family:arial,sans-serif">concept DimensionCompatibleOrdering</span></div=
><div><span style=3D"font-family:arial,sans-serif">{</span></div><div><font=
face=3D"arial, sans-serif">return std::equal<T, std::column_major> /=
/Pseudocode below</font></div><div><span style=3D"font-family:arial,sans-se=
rif"> || std::equal<T, std::row_major></span></div><div>=
<span style=3D"font-family:arial,sans-serif"> || std::equal<=
mpl::sort<T>, std::integer_sequence<N>> //i.e. make sure tha=
t a sorted version of the ordering is identical to 1,2,....N</span></div><d=
iv><span style=3D"font-family:arial,sans-serif">}</span><br></div><div><spa=
n style=3D"font-family:arial,sans-serif"><b><br></b></span></div></div></bl=
ockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_754_624679614.1416000742153--
.