Re: plan of deep learning team for next stable release?
Hi Norbert,
Thanks for the quick reply.
On Wed, Nov 25, 2020 at 11:15:53AM +0900, Norbert Preining wrote:
> I remember there was some connection requests from Tensorflow devs
> searching for Debian devs ... did that get any followup from any side? I
> haven't seen anything.
Nothing new on my side, neither.
> Looking at https://www.khronos.org/sycl/ and the part on
> SYCL Implementations
> I am not really sure which way one would go? ComputeCpp?
There are many implementations of SYCL. I'd personally wait for Intel's
implementation to be merged into LLVM:
https://github.com/intel/llvm
Nvidia focuses on CUDA, while AMD focuses on ROCm. As Intel is about to
sell its discrete graphics card, I think Intel will hold a serious
attitude towards the quality of their own implementation. Besides, well
you know, since it's a future component of LLVM, the corresponding
preparation works are actually offloaded to the llvm team ;-)
ComputeCpp may be one way to go but I'm afraid it will introduce
considerable extra workload for us to maintain a complete "toolchain",
and the volunteers may lack enough hardware resources to test.
> > ROCm gave us a bad impression through its documentations. And I think
> > we're out of man power to deal with it.
>
> I have worked to build packages for 3.9 and that did progress, but there
> are simply too many packages and not enough man power. Also, I don't see
> ROCm in a stage that it can be reasonably used for machine learning with
> GPU acceleration (unless through jump through several loops). I am
> following the github issues on these topics, and will try to bring the
> ROCm stack forward sooner or later, but this is **for**sure** not for
> this stable release (unless someone jumps forward and contributes lots
> of time and energy and knowledge).
Agreed. Given the limited time frame and man power before the release,
ROCm does not look like something for stable+1 at all.
> I just thought to add Julia here, which is not within debian-ai, but
> still somehow related. Here I am planning to ship the latest julia, and
> we are currently discussion about shipping two independent julia, one is
> julia-latest and one is julia-lts, but I am not sure that this will come
> to fruition before the freeze.
Indeed, Julia community is quite active in terms of developing machine
learning and deep learning libraries in place of the popular python
software stacks.
As for shipping julia-lts and julia-latest simultaneously, I doubt
whether it is necessary given the current popcon record? The embedded
openblas is also something remains to remove. (I still have no idea
why libopenblas64-julia does not work)
Reply to: