Re: On the Removal of src:tensorflow
Hi Steffen,
I'm wondering who will read it. In the past I broadcasted some bits
I learned to the public mailing lists and people responded, but
nobody had ever asked me any detail about anything related.
I dislike the mediawiki markup. If you think it's important to
document these insights, could you please help me start a template
and submit it to ML-Policy[1] as a PR/issue? We could create a
page on wiki.d.o and point it to salsa (or paste pandoc conversion
result there).
[1] https://salsa.debian.org/lumin/ml-policy/
On 2019-09-04 07:47, Steffen Möller wrote:
> Hi Mo,
>
> Would you mind creating a wiki.d.o page that collects your insights? Or
> shall I start and you fill in the gaps?
>
> Best,
> Steffen
>
> On 26.08.19 04:04, Mo Zhou wrote:
>> Hi -devel,
>>
>>
>> I've just filed an RM(#935769) bug against src:tensorflow and I believe
>> this is the most appropriate choice at this stage. For packages that
>> would easily draw attention from the media, not providing them would be
>> much better than providing something much inferior than the users
>> expected (Recall "difficulty ... DL framework" and "conda ...").
>>
>>
>> A number of packages in our archive have referenced tensorflow:
>>
>> https://codesearch.debian.net/search?q=tensorflow&perpkg=1
>>
>> Or even called its C API (ffmpeg calls tensorflow for its super
>> resolution filter. ffmpeg package maintainers have disabled the
>> --enable-libtensorflow configure option). At this point, for good wish
>> some contributors may hope to put a little bit more effort to save the
>> package and at least keep its C/C++ interface available. To me avoiding
>> the Bazel build (the only build system for tensorflow) is costly, and
>> the yield isn't worth the cost. The most practical recommendation to
>> tensorflow users is "pip or conda".
>>
>>
>> Deep learning (DL) framework is NOT something too complex to be
>> implemented from scratch by a single person. A fundamental DL framework
>> can be implemented with the following functionalities:
>> 1) data loading, e.g. a CSV reader
>> 2) linear operations, e.g. matrix multiplication, convolution
>> 3) element-wise non-linear functions, e.g. max(x,0), exp(x), ln(x)
>> 4) the computation graph (sort of directed acyclic graph)
>> 5) automatic (of manual) differentiation (computing the gradient)
>> 6) first-order gradient-based optimization (network training)
>>
>> That means tensorflow's complexity doesn't come from the theoritical
>> side, but engineering especially performance optimization. On the other
>> hand, it's easy for the users to find an alternative to tensorflow if
>> they don't heavily rely on some portion of its functionality.
>>
>>
>> Based on the following facts, I believe removing src:tensorflow is the
>> most appropriate choice at the current stage, and I DISCOURAGE any
>> effort trying to save or re-introduce it.
>>
>> 1) TensorFlow's only well-supported build system, i.e. Bazel is
>> hopeless to enter Debian.
>> 2) Maintaining an alternative build system (cmake, or any self-made
>> one) could be costly.
>> 3) Even if somebody conquered the build system issue at a cost,
>> it's only possible to upload the low-performance version to our main
>> archive (out of SIMD acceleration due to our ISA baseline,
>> out of CUDA acceleration or OpenCL acceleration).
>> 4) To mitigate the performance issue one could upload a CUDA version
>> to contrib section, but I promise that dealing with nvidia stuff
>> once anything went wrong is a painful experience to free distro
>> developer.
>> 5) To mitigate the performance issue with OpenCL one could also try
>> AMD's fully open-source ROCm/HIP software stack (AMD's opensource
>> counterpart to the nvidia CUDA). However the usage of AMD graphics
>> for machine learning is still not common, and none of the
>> related software has been packaged yet.
>>
>> With that said, I still encourage people who care about such topic to
>> maintain building block packages (I'm maintaining some of these) for
>> DL frameworks, or some alternative DL frameworks if you see appropriate.
>>
Reply to: