+1.
While I like slack, personally, I don't think we should treat slack as
public-archive. "everything that happens (also) happens in dev@"
Tianqi
On Fri, Apr 12, 2019 at 1:19 AM Marco de Abreu
wrote:
> I'd prefer if we keep discussions on the dev-list instead of slack - feel
> free to
I will respond in slack, so we don't derail the original thread's
topic with my points.
Looking forward to your proposal.
On Thu, Apr 11, 2019 at 1:00 PM Junru Shao wrote:
>
> I don't have idea about the following issues:
>
> 1) Reducing the abuse of inlined code moving more logic to
I don't have idea about the following issues:
1) Reducing the abuse of inlined code moving more logic to implementation
files and improve scoping which will also speed up compilation
2) Reduce runtime of some unit tests
3) Improve MXNet startup time
Will be super interested to hear about your
We have a systematic solution to go without ABI headache. I am struggling
with some errants, and will share our proposal here as soon as I could.
This will be very interesting topic to discuss. Let's work hard together
and make it perfect :-)
On Thu, Apr 11, 2019 at 12:43 PM Pedro Larroy
wrote:
Thanks Marco for raising this issue. I think we can certainly do some
improvements in modularization and build. At the same time Tianqi's
point of view is important to consider and on point. I see a high risk
of overengineering in such endeavor.
I also see increased complexity, difficulty
+1 Thanks Marco for sharing this!
It is great to see people agree with this feature and we actually have been
planning for this for a while. We would love to share this plan as soon as
possible.
On Mon, Apr 8, 2019 at 9:42 AM Tianqi Chen wrote:
> Just to clarify. I am not questioning the
Just to clarify. I am not questioning the usefulness of the separation.
Just want to highlight the technical challenges here based on our past
experiences.
Crossing DLL boundaries in C++ can create quite a lot of problems,
especially some of the dependencies used a different version of the
I think we can make some incremental progress. My thoughts were along the
lines of plugins (thinking about what happens with the VLC project). At
process launch time we could gather some information about our execution
environment (either through configuration, or by convention looking at our
While I personally like the idea. This can be something that is fairly
technical challenging and I would caution against this idea vs pushing for
good features and just allow runtime configuration.
The main problem here is due to the C++ ABI. There is no standard c++ ABI
across compilers, which
Strongly support the idea of runtime loadable components in MXNet. There's
no reason (other than perhaps engineering effort) we can't have a single
compilation of MXNet that finds dependencies and chooses execution paths
intelligently (or based on configuration) at runtime.
On Thu, Apr 4, 2019
Hello,
I'd like to start a discussion about something that I've noticed being
troublesome to maintain in the current version: Backend choices being made
at compile time.
Right now, the different backends and accelerators (CPU, cuda, mkl, AWS
elastic inference, (future) AMD, openblas,TVM, etc)
11 matches
Mail list logo
