You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by "Lupesko, Hagay" <lu...@gmail.com> on 2017/12/04 21:54:45 UTC
Re: [RFQ] Deprecate amalgamation
JavaScript is not the only use case for Amalgamation - I’m familiar with a few users that use the amalgamation to build Android and iOS apps.
If we take out Amalgamation, unless we provide target builds for these platforms, these users and use cases will be left out.
Hagay
On 11/21/17, 11:50, "Pedro Larroy" <pe...@gmail.com> wrote:
Anybody against removing amalgamation then? emscripten build is
already using CMake.
On Tue, Nov 21, 2017 at 9:22 AM, Tianqi Chen <tq...@cs.washington.edu> wrote:
> Yes, you can call emscripten from CMake
>
> Tianqi
>
> On Mon, Nov 20, 2017 at 5:42 PM, Pedro Larroy <pe...@gmail.com>
> wrote:
>
>> I like the idea of amalgamation, I have used it in SQLite as it makes
>> very easy to just drop one header file and one source file in another
>> project to use the library.
>>
>> But SQLite is often used as a library embedded in platforms / other
>> libraries.
>>
>> What's the use case of amalgamation in MXNet when we can build the
>> binary library for all the platforms with MXNet's build system? Who
>> is using MXNet as an embedded library that can't use the shared
>> library + headers or specific language bindings?
>>
>> Can't we call emscripten from CMake? I'm not familiar with our JS
>> bindings, but I don't see why we can't compile for emscripten as for
>> any other platform.
>>
>> Pedro.
>>
>> On Mon, Nov 20, 2017 at 11:59 PM, Tianqi Chen <tq...@cs.washington.edu>
>> wrote:
>> > We could resort to a middle ground. Instead of having an amalgamation
>> > script that generates a single file, simply have a file that includes
>> > everything and compiles that one. Which should also work.
>> >
>> > The javascript port can likely be superseded with some form of support in
>> > nnvm compiler, which transpires and generate likely more efficient code
>> > than current version. We can enable that feature now except that there
>> is
>> > no dedicated developer on it yet. We can talk about full deprecation
>> after
>> > this
>> >
>> >
>> > Tianqi
>> >
>> > On Mon, Nov 20, 2017 at 2:47 PM, Pedro Larroy <
>> pedro.larroy.lists@gmail.com>
>> > wrote:
>> >
>> >> Hi all
>> >>
>> >> Given that we have working builds for ARM, Android, TX2 and the main
>> >> architectures, and after considering how amalgamation is done. I would
>> >> like to propose that we deprecate and remove amalgamation.
>> >>
>> >> I don't think the cost of maintaining this feature and how it's done
>> >> justifies the ROI, given that we can now produce binary builds for
>> >> embedded platforms in a comfortable way. It's also consuming build &
>> >> test resources.
>> >>
>> >> We should strive to simplify our build system and development process.
>> >>
>> >> Pedro.
>> >>
>>
Re: [RFQ] Deprecate amalgamation
Posted by Marco de Abreu <ma...@googlemail.com>.
Would you be able to us in touch with some customers who are using
amalgamation? That way we'd be able to gather some requirements and provide
them with a seamless replacement as part of our docker_multiarch
https://github.com/apache/incubator-mxnet/tree/master/docker_multiarch .
On Mon, Dec 4, 2017 at 10:54 PM, Lupesko, Hagay <lu...@gmail.com> wrote:
> JavaScript is not the only use case for Amalgamation - I’m familiar with a
> few users that use the amalgamation to build Android and iOS apps.
> If we take out Amalgamation, unless we provide target builds for these
> platforms, these users and use cases will be left out.
>
> Hagay
>
> On 11/21/17, 11:50, "Pedro Larroy" <pe...@gmail.com> wrote:
>
> Anybody against removing amalgamation then? emscripten build is
> already using CMake.
>
> On Tue, Nov 21, 2017 at 9:22 AM, Tianqi Chen <tq...@cs.washington.edu>
> wrote:
> > Yes, you can call emscripten from CMake
> >
> > Tianqi
> >
> > On Mon, Nov 20, 2017 at 5:42 PM, Pedro Larroy <
> pedro.larroy.lists@gmail.com>
> > wrote:
> >
> >> I like the idea of amalgamation, I have used it in SQLite as it
> makes
> >> very easy to just drop one header file and one source file in
> another
> >> project to use the library.
> >>
> >> But SQLite is often used as a library embedded in platforms / other
> >> libraries.
> >>
> >> What's the use case of amalgamation in MXNet when we can build the
> >> binary library for all the platforms with MXNet's build system? Who
> >> is using MXNet as an embedded library that can't use the shared
> >> library + headers or specific language bindings?
> >>
> >> Can't we call emscripten from CMake? I'm not familiar with our JS
> >> bindings, but I don't see why we can't compile for emscripten as for
> >> any other platform.
> >>
> >> Pedro.
> >>
> >> On Mon, Nov 20, 2017 at 11:59 PM, Tianqi Chen <
> tqchen@cs.washington.edu>
> >> wrote:
> >> > We could resort to a middle ground. Instead of having an
> amalgamation
> >> > script that generates a single file, simply have a file that
> includes
> >> > everything and compiles that one. Which should also work.
> >> >
> >> > The javascript port can likely be superseded with some form of
> support in
> >> > nnvm compiler, which transpires and generate likely more
> efficient code
> >> > than current version. We can enable that feature now except that
> there
> >> is
> >> > no dedicated developer on it yet. We can talk about full
> deprecation
> >> after
> >> > this
> >> >
> >> >
> >> > Tianqi
> >> >
> >> > On Mon, Nov 20, 2017 at 2:47 PM, Pedro Larroy <
> >> pedro.larroy.lists@gmail.com>
> >> > wrote:
> >> >
> >> >> Hi all
> >> >>
> >> >> Given that we have working builds for ARM, Android, TX2 and the
> main
> >> >> architectures, and after considering how amalgamation is done. I
> would
> >> >> like to propose that we deprecate and remove amalgamation.
> >> >>
> >> >> I don't think the cost of maintaining this feature and how it's
> done
> >> >> justifies the ROI, given that we can now produce binary builds
> for
> >> >> embedded platforms in a comfortable way. It's also consuming
> build &
> >> >> test resources.
> >> >>
> >> >> We should strive to simplify our build system and development
> process.
> >> >>
> >> >> Pedro.
> >> >>
> >>
>
>
>
>