Thank you! Yes, we say your bug report, and I think Eugene will look at
adding block evaluation to fix it.

On Mon, Oct 21, 2019 at 9:34 AM William Tambellini <[email protected]>
wrote:

> Hi Rasmus,
> Thanks. If I could help (test, profil, ...), please email me. If I
> remember right, as today, these ops are still faster via Matrix vs Tensor:
> - reductions
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1614
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1628
> - gemv
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1648
> - transpose
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1627
> Kind
> W.
>
> William Tambellini | Senior Software Developer | SDL Los Angeles |
> [email protected]
> http://www.sdl.com
> <http://bit.ly/2LB1qRN>
> *Share yourfeedback with us* <https://www.surveymonkey.com/r/PYF190816>
>
> ------------------------------
> *From:* Rasmus Munk Larsen <[email protected]>
> *Sent:* Monday, October 21, 2019 9:04 AM
> *To:* eigen <[email protected]>
> *Subject:* Re: [eigen] Should we require c++11 for Eigen tensor
>
> Hi William,
>
> Eugene Zhulenev's work on the new BlockV2 evaluation framework, should
> make it a lot easier to address some of the performance issues you are
> seeing, including adding block evaluation for concat. So far, TensorFlow as
> been using a custom concat operation that does not use Eigen, so we never
> thought to address this. But if we can make it fast in Eigen and get rid of
> custom code for this op, we will.
>
> Rasmus
>
> On Sat, Oct 19, 2019 at 6:52 PM William Tambellini <[email protected]>
> wrote:
>
> Ok for me. Specially if that could ease to resolve the speed issues of the
> Tensor module.
> Kind
> WT.
>
> <http://bit.ly/2LB1qRN>
> *Share your feedback with us* <https://www.surveymonkey.com/r/PYF190816>
>
> ------------------------------
> *From:* Christoph Hertzberg <[email protected]>
> *Sent:* Friday, October 18, 2019 10:03 AM
> *To:* [email protected] <[email protected]>
> *Subject:* Re: [eigen] Should we require c++11 for Eigen tensor
>
> Hi!
>
> I think some time ago there was some opposition against that step -- in
> fact, originally C++03 was only introduced after the first versions of
> the Tensor module.
>
> I can't find a reference to that discussion at the moment, I think it
> concerned supporting Tensor for some GPU architecture. But this was a
> few years ago, and compilers likely evolved since then.
>
> So unless there is an outcry on this list, I'm not against dropping
> C++03 support of the Tensor module.
>
>
> For transitioning it would of course be nice to have a clear "latest
> working" version which still supports C++03, one possibility would be to
> make that with the 3.4 release. OTOH, this will just complicate
> maintenance and Tensors are still "unsupported" for a reason (e.g., not
> having to spend unnecessary time to support them ...)
>
> So just making a clear cut before 3.4 sounds actually better -- this
> will also simplify to maintain the upcoming 3.4 and master versions in
> parallel (I guess the 3.3.x version of the Tensor module has barely been
> touched in recent years).
>
>
> Cheers,
> Christoph
>
> On 18/10/2019 18.46, Rasmus Munk Larsen wrote:
> > Dear Eigen tensor users,
> >
> > Today, various c++11 features are in use in many parts of Eigen tensor,
> > while other parts compile with c++03 without warnings. This division is
> > rather arbitrary and primarily dictated by what parts of the code gets
> > compiled for the subset of tests that are enabled in c++03 mode:
> >
> >
> https://bitbucket.org/eigen/eigen/src/default/unsupported/test/CMakeLists.txt#lines-112
> >
> > A larger set of tests covering the majority of the code base are only
> > compiled in c++11 mode:
> >
> https://bitbucket.org/eigen/eigen/src/c4368f48fef3737ef5a48604cfc63ce946b68616/unsupported/test/CMakeLists.txt#lines-179
> >
> > I don't think a user can realistically use Eigen tensor and avoid the
> c++11
> > parts of the code. Therefore I would propose that we stop pretending that
> > Eigen tensor supports c++03 and simply guard all the code with
> > EIGEN_HAS_CXX11 or similar. This will then allow us to start cleaning up
> > the code.
> >
> > Please let me know if you have any objections to this.
> >
> > Best,
> >    Rasmus
> >
>
> --
>   Dr.-Ing. Christoph Hertzberg
>
>   Besuchsadresse der Nebengeschäftsstelle:
>   DFKI GmbH
>   Robotics Innovation Center
>   Robert-Hooke-Straße 5
>   28359 Bremen, Germany
>
>   Postadresse der Hauptgeschäftsstelle Standort Bremen:
>   DFKI GmbH
>   Robotics Innovation Center
>   Robert-Hooke-Straße 1
>   28359 Bremen, Germany
>
>   Tel.:     +49 421 178 45-4021 <+49%20421%20178454021>
>   Zentrale: +49 421 178 45-0
>   E-Mail:   [email protected]
>
>   Weitere Informationen: http://www.dfki.de/robotik
>    -------------------------------------------------------------
>    Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
>    Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
>
>    Geschäftsführung:
>    Prof. Dr. Jana Koehler (Vorsitzende)
>    Dr. Walter Olthoff
>
>    Vorsitzender des Aufsichtsrats:
>    Prof. Dr. h.c. Hans A. Aukes
>    Amtsgericht Kaiserslautern, HRB 2313
>    -------------------------------------------------------------
>
>
>
>
>
> Click here
> <https://www.mailcontrol.com/sr/ELeTgw_9Q__GX2PQPOmvUizKrmxxhcEGMKpSJFYoHVK-Z8uO7HUp62mTmkAYMGtVR8AB6krnmzENCU1_U1Tbvw==>
> to report this email as spam.
>

Reply via email to