<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 4, 2017 at 3:40 PM, Filippo Leonardi <span dir="ltr"><<a href="mailto:filippo.leon@gmail.com" target="_blank">filippo.leon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_-8343239131867875909gmail_msg">I had weird issues where gcc (that I am using for my tests right now) wasn't vectorising properly (even enabling all flags, from tree-vectorize, to mavx). According to my tests, I know the Intel compiler was a bit better at that.</div></div></blockquote><div><br></div><div>We are definitely at the mercy of the compiler for this. Maybe Jed has an idea why its not vectorizing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_-8343239131867875909gmail_msg">I actually did not know PETSc was doing some unrolling himself. On my machine, PETSc aligns the memory to 16 bytes, that might also be a cause. However, I have no idea on the ability of the different compilers to detect and vectorize codes, even when those are manually unrolled by the user. I see PETSc unrolls the loop for MAXPY up 4 right hand side vectors. Just by coincidence, the numbers I reported are actually for this latter case. </div><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div><div class="m_-8343239131867875909gmail_msg">I pushed my code to a public git repository. However let me stress that the code is extremely ugly and buggy. I actually feel shame in showing you the code :) :</div><div class="m_-8343239131867875909gmail_msg"><a href="https://bitbucket.org/FilippoL/petscxx/commits/branch/master" target="_blank">https://bitbucket.org/<wbr>FilippoL/petscxx/commits/<wbr>branch/master</a><br></div><div class="m_-8343239131867875909gmail_msg"><br></div><div class="m_-8343239131867875909gmail_msg">If you want to look at the API usage, you can find it in the file "/src/benchmarks/bench_vector.<wbr>cpp" after line 153.</div><div class="m_-8343239131867875909gmail_msg"><br></div><div class="m_-8343239131867875909gmail_msg">If you want the expressions generating the kernels you have to look at the file "/src/base/vectorexpression.<wbr>hpp", specifically the "evalat" members.</div></div></div></blockquote><div><br></div><div>I looked. I guess it it a matter of taste whether this seems simpler, or unrolling and putting in an intrinsic call. The automation is undeniable.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote m_-8343239131867875909gmail_msg"><div dir="ltr" class="m_-8343239131867875909gmail_msg">On Tue, 4 Apr 2017 at 21:39 Matthew Knepley <<a href="mailto:knepley@gmail.com" class="m_-8343239131867875909gmail_msg" target="_blank">knepley@gmail.com</a>> wrote:<br class="m_-8343239131867875909gmail_msg"></div><blockquote class="gmail_quote m_-8343239131867875909gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="gmail_extra m_-8343239131867875909gmail_msg"><div class="gmail_quote m_-8343239131867875909gmail_msg">On Tue, Apr 4, 2017 at 1:19 PM, Filippo Leonardi <span dir="ltr" class="m_-8343239131867875909gmail_msg"><<a href="mailto:filippo.leon@gmail.com" class="m_-8343239131867875909gmail_msg" target="_blank">filippo.leon@gmail.com</a>></span> wrote:<br class="m_-8343239131867875909gmail_msg"><blockquote class="gmail_quote m_-8343239131867875909gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="m_-8343239131867875909gmail_msg">You are in fact right, it is the same speedup  of approximatively 2.5x (with 2 ranks), my brain rounded up to 3. (This was just a test done in 10 min on my Workstation, so no pretence to be definite, I just wanted to have an indication).</div></blockquote><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div></div></div></div><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="gmail_extra m_-8343239131867875909gmail_msg"><div class="gmail_quote m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg">Hmm, it seems like <span style="font-family:menlo;font-size:11px" class="m_-8343239131867875909gmail_msg">PetscKernelAXPY4() </span>is just not vectorizing correctly then. I would be interested to see your code.</div></div></div></div><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="gmail_extra m_-8343239131867875909gmail_msg"><div class="gmail_quote m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div><blockquote class="gmail_quote m_-8343239131867875909gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg">As you say, I am using OpenBLAS, so I wouldn't be surprised of those results. If/when I use MKL (or something similar), I really do not expect such an improvement).</div><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div><div class="m_-8343239131867875909gmail_msg">Since you seem interested (if you are interested, I can give you all the details): the comparison I make, is with "petscxx" which is my template code (which uses a single loop) using AVX (I force PETSc to align the memory to 32 bit boundary and then I use packets of 4 doubles). Also notice that I use vectors with nice lengths, so there is no need to "peel" the end of the loop. The "PETSc" simulation is using PETSc's VecMAXPY.</div></div></blockquote><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div></div></div></div><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="gmail_extra m_-8343239131867875909gmail_msg"><div class="gmail_quote m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg">Thanks,</div><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div><div class="m_-8343239131867875909gmail_msg">   Matt</div></div></div></div><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="gmail_extra m_-8343239131867875909gmail_msg"><div class="gmail_quote m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg"> </div><blockquote class="gmail_quote m_-8343239131867875909gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-h5 m_-8343239131867875909gmail_msg"><div class="gmail_quote m_-8343239131867875909gmail_msg"><div dir="ltr" class="m_-8343239131867875909gmail_msg">On Tue, 4 Apr 2017 at 19:12 Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" class="m_-8343239131867875909gmail_msg" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br class="m_-8343239131867875909gmail_msg"></div><blockquote class="gmail_quote m_-8343239131867875909gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
  MAXPY isn't really a BLAS 1 since it can reuse some data in certain vectors.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> On Apr 4, 2017, at 10:25 AM, Filippo Leonardi <<a href="mailto:filippo.leon@gmail.com" class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg" target="_blank">filippo.leon@gmail.com</a>> wrote:<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> I really appreciate the feedback. Thanks.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> That of deadlock, when the order of destruction is not preserved, is a point I hadn't thought of. Maybe it can be cleverly addressed.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> PS: If you are interested, I ran some benchmark on BLAS1 stuff and, for a single processor, I obtain:<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> Example for MAXPY, with expression templates:<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY/8 38 ns 38 ns 18369805<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY/64 622 ns 622 ns 1364335<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY/512 281 ns 281 ns 2477718<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY/4096 2046 ns 2046 ns 349954<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY/32768 18012 ns 18012 ns 38788<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY_BigO 0.55 N 0.55 N<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_petscxx_MAXPY_RMS 7 % 7 %<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> Direct call to MAXPY:<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY/8 33 ns 33 ns 20973674<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY/64 116 ns 116 ns 5992878<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY/512 731 ns 731 ns 963340<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY/4096 5739 ns 5739 ns 122414<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY/32768 46346 ns 46346 ns 15312<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY_BigO 1.41 N 1.41 N<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> BM_Vector_PETSc_MAXPY_RMS 0 % 0 %<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> And 3x speedup on 2 MPI ranks (not much communication here, anyway). I am now convinced that this warrants some further investigation/testing.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> On Tue, 4 Apr 2017 at 01:08 Jed Brown <<a href="mailto:jed@jedbrown.org" class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg" target="_blank">jed@jedbrown.org</a>> wrote:<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> Matthew Knepley <<a href="mailto:knepley@gmail.com" class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg" target="_blank">knepley@gmail.com</a>> writes:<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> BLAS. (Here a interesting point opens: I assume an efficient BLAS<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> implementation, but I am not so sure about how the different BLAS do<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> things<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> internally. I work from the assumption that we have a very well tuned BLAS<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> implementation at our disposal).<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> ><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > The speed improvement comes from pulling vectors through memory fewer<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > times by merging operations (kernel fusion).<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> Typical examples are VecMAXPY and VecMDot, but note that these are not<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> xGEMV because the vectors are independent arrays rather than single<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> arrays with a constant leading dimension.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> call VecGetArray. However I will inevitably foget to return the array to<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> PETSc. I could have my new VecArray returning an object that restores the<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> array<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> when it goes out of scope. I can also flag the function with [[nodiscard]]<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> to<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >> prevent the user to destroy the returned object from the start.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> >><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> ><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > Jed claims that this pattern is no longer preferred, but I have forgotten<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > his argument.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > Jed?<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> Destruction order matters and needs to be collective.  If an error<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> condition causes destruction to occur in a different order on different<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> processes, you can get deadlock.  I would much rather have an error<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> leave some resources (for the OS to collect) than escalate into<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> deadlock.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > We have had this discussion for years on this list. Having separate names<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > for each type<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > is really ugly and does not achieve what we want. We want smooth<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > interoperability between<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > objects with different backing types, but it is still not clear how to do<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> > this.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
><br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> Hide it internally and implicitly promote.  Only the *GetArray functions<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> need to be parametrized on numeric type.  But it's a lot of work on the<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
> backend.<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg">
<br class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail-m_733047757541465532gmail_msg m_-8343239131867875909gmail_msg"><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div></div></div></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr" class="m_-8343239131867875909gmail_msg"><div class="gmail_extra m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909gmail_msg"><br class="m_-8343239131867875909gmail_msg"></div>-- <br class="m_-8343239131867875909gmail_msg"><div class="m_-8343239131867875909m_-8553106827438043431m_-5789170363833804039gmail_signature m_-8343239131867875909gmail_msg">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br class="m_-8343239131867875909gmail_msg">-- Norbert Wiener</div>
</div></div></font></span></blockquote></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>