Re: Module maintainers proposal

Am 9. Januar 2018 18:25:50 MEZ schrieb Mu Li : >We should encourage to contract a specific contributor for issues and >PRs. My head translates "encourage to contact specific contributor" into "encourage to contact specific contributors inbox". This translated version is

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

This is what I was asking about: https://www.unix.com/man-page/POSIX/3posix/random/ POSIX standard stating that given a seed, the output must be deterministic. On Tue, Jan 9, 2018 at 7:58 AM, kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Sorry if I'm misunderstanding your question

Re: Module maintainers proposal

Hi Isabel, Thanks for the suggestions, they are quite useful. By module maintainer I mainly mean: - The default PR reviewer for a module - The default person answering questions regarding a module We should encourage to contract a specific contributor for issues and PRs. But if it is not clear,

MXNet Thread Safety for Inference

I re-opened this issue that bulk closed a few months ago https://github.com/apache/incubator-mxnet/issues/3946 and I think issue still remains is a blocking one for users. >From the conversation I gather that MXNet expects that only 1 thread communicate with an executor. This would serialize all

Re: Module maintainers proposal

Another two side notes: Even if there are maintainers, if for instance there's a security issue in module X the entire PMC will be held accountable for fixing it. So for instance the maintainer being offline is no excuse for not taking care of it. "That's not my issue" is not a valid answer.

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

The issue is tricky. Number generators should return deterministic sets of numbers as Chris said, but that usually only applies to non-distributed systems. And to some extend, we have already a distributed system as soon as one cpu and one gpu is involved. For the usual setup like distributed

Re: CUDA Support [DISCUSS]

+1 for testing CUDA8 and CUDA9 (i.e. at least one version backward). I personally had worked recently on functionalities in the linalg-namespace where I was not  aware that I introduced CUDA 8 only dependencies that break immediately every CUDA7.5 build. I only happened to know this as Jenkins

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

Thanks Asmus, yes this is also the approach I would be in favour of. I think we should optionally allow the user to specify if they want deterministic behaviour independent of the GPU they run on. If MXNet is going to support more arbitrary linear algabra operations I could see a lot of use

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

I think the convention is that random generators in most modern languages are always seeded, and always deterministic. If a user seed isn't supplied, implementations generally provide their own seed, which they attempt to make unique. Often they generate a seed that takes into account the

Re: [DISCUSS] Seeding and determinism on multi-gpu systems.

wait wait — i don’t think that random number generators should return deterministic lists of numbers. i’m asking if something says it’s supposed to. i know they tend to, but my understanding is that they tend to because of the challenge of generating true random numbers from hardware. IMHO the