Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 28 2019 21:53

    drahnr on master

    chore/archive: add archive note (compare)

  • Dec 28 2019 21:52

    drahnr on master

    chore/archive: archive this rep… (compare)

  • Dec 28 2019 21:51

    drahnr on master

    chore/archive: closing this repo (compare)

  • Jun 18 2019 16:15
    drahnr commented #16
  • Jun 18 2019 09:44
    andreytkachenko commented #16
  • Apr 04 2019 01:41
    vadixidav opened #18
  • Dec 16 2018 13:44
    Xoronic closed #17
  • Dec 16 2018 13:44
    Xoronic commented #17
  • Dec 11 2018 17:32

    drahnr on master

    fix/README.md: remove link to s… (compare)

  • Dec 11 2018 17:16
    Xoronic edited #17
  • Dec 11 2018 17:16
    Xoronic edited #17
  • Dec 11 2018 17:15
    Xoronic opened #17
  • Aug 31 2018 16:45

    drahnr on master

    chore/version: release 0.2.1 (compare)

  • Apr 07 2018 06:19

    drahnr on master

    doc/badge: adjust path again (compare)

  • Apr 07 2018 06:17

    drahnr on master

    doc/badge: adjust path (compare)

  • Apr 06 2018 22:06

    sirmergealot on gh-pages

    doc/automatic: update (compare)

  • Apr 06 2018 22:04

    sirmergealot on gh-pages

    doc/automatic: update (compare)

  • Apr 06 2018 21:56
    drahnr commented #5
  • Apr 06 2018 21:56
    drahnr commented #5
  • Apr 06 2018 21:53

    drahnr on master

    fix/backends: prevent impl of :… (compare)

subversive-owl
@subversive-owl
and i'm not sure which Device to reference to use the read/write methods
Bernhard Schuster
@drahnr
Index ops would be neat, but difficult to implement due to the varying dimensionality
self should have a bound function called device()

macro_rules! read {
    ($x:ident, $t:ident, $slf:ident) => (
        $x.read($slf.device()).unwrap().as_slice::<$t>()
    )
}

macro_rules! read_write {
    ($x:ident, $t: ident, $slf:ident) => (
        $x.read_write($slf.device()).unwrap().as_mut_slice::<$t>()
    )
}

macro_rules! write_only {
    ($x:ident, $t: ident, $slf:ident) => (
        $x.write_only($slf.device()).unwrap().as_mut_slice::<$t>()
    )
}
in coaster-nn under src/frameworks/native/helper.rs
subversive-owl
@subversive-owl
got it, thanks
subversive-owl
@subversive-owl
ok, i have something i can start working with at https://github.com/spearow/coaster-nn/tree/wip-native
have to prep for a coding test tomorrow, but will be back to it on the weekend
Bernhard Schuster
@drahnr
Alright, I'll check it out tomorrow night
Bernhard Schuster
@drahnr
Still a bit to go, if you want I can pass you my autodiff based notes. It is a bit tedious to calculate it parametrized over the dimensions of the tensor..
subversive-owl
@subversive-owl
oh yea, please do
Bernhard Schuster
@drahnr
I'll have plenty of time tomorrow night :)
subversive-owl
@subversive-owl
:thumbsup:
az8
@AZon8
heej just so you know, the example in the readme doesn't compile.
Bernhard Schuster
@drahnr
of coaster?
@AZon8 ^^^^
az8
@AZon8
yeah . cargo import coaster = "*" , coaster-nn = "*" , and copying the example gives me the errors "SharedTensor::<f32>::new(backend.device(), &(1, 1, 3)).unwrap(); expected 1 param " and the error "no method named add_device found for type `co::SharedTensor"
Bernhard Schuster
@drahnr
I'll dig into it within the next few days
Bernhard Schuster
@drahnr
@az8 essentially add_device got replaced by read{,_only}, write{,_only}
Bernhard Schuster
@drahnr
@az8 I did a first fix, but a hardware issue prevents me from digging deeper into this right now, will have to wait until next weekend
subversive-owl
@subversive-owl
worth mentioning, if you have debian, you might run into this: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1753796
may want to avoid upgrading for a long time
Bernhard Schuster
@drahnr
sigh, why don't they use libglvnd?
I strongly recommend fedora for predictabilities sake
or centos for that sake
Mamy Ratsimbazafy
@mratsim
For pure Debian I build the nvidia driver from SVN: https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN
I have a setup with Debian as a host and Archlinux as a LXC container with GPU passthrough. So Debian has the nvidia driver and Archlinux has nvidia-smi/nvidia-utils, Cuda and Cudnn drivers and Debian must be kept in sync with Arch.
Recently released
Could someone explain how does it compare to coaster / coaster cnn ?
Coaster NN
Bernhard Schuster
@drahnr
It's more juice related
jonysy
@jonysy
@drahnr How far along are you?
Bernhard Schuster
@drahnr
@jonysy regarding what? I am about to change jobs so things are little more busy than planned
John Karasev
@j.karasev_gitlab
Are there more examples of how to use coaster?
Bernhard Schuster
@drahnr
Hi @j.karasev_gitlab well, depends at what you are aiming
do you want to implement an algorithm for an existing backend?
give more feat to an existing backend
John Karasev
@j.karasev_gitlab
I was thinking of implementing a RNN layer on a existing back end probably on the CPU for now
John Karasev
@j.karasev_gitlab
nevermind, I will just look into the examples in juice
Bernhard Schuster
@drahnr
I think that is the easiest way, try to pick something with as few macros as possible, with the cudnn backend there are quite a few macros involved for implementing over multiple datatypes
Thomas Havlik
@thavlik
Ping
Bernhard Schuster
@drahnr
Pong
John
@onFireForGod_gitlab
64 bytes from coaster: icmp_seq=0 ttl=54 time=20.941 ms
John
@onFireForGod_gitlab
What is the difference between ComputeInputGradient and ComputeParametersGradient traits
John
@onFireForGod_gitlab

for example, the linear layer has:

impl<B: IBackend + LayerOps<f32>> ComputeInputGradient<f32, B> for Linear {
    fn compute_input_gradient(&self,
                              backend: &B,
                              weights_data: &[&SharedTensor<f32>],
                              output_data: &[&SharedTensor<f32>],
                              output_gradients: &[&SharedTensor<f32>],
                              input_data: &[&SharedTensor<f32>],
                              input_gradients: &mut [&mut SharedTensor<f32>]) {
        // Gradient with respect to input data
        backend.gemm(&self.one,
                  Transpose::NoTrans,
                  output_gradients[0],
                  Transpose::NoTrans,
                  weights_data[0],
                  &self.zero,
                  input_gradients[0])
            .unwrap();
    }
}

impl<B: IBackend + LayerOps<f32>> ComputeParametersGradient<f32, B> for Linear {
    fn compute_parameters_gradient(&self,
                                   backend: &B,
                                   output_data: &[&SharedTensor<f32>],
                                   output_gradients: &[&SharedTensor<f32>],
                                   input_data: &[&SharedTensor<f32>],
                                   parameters_gradients: &mut [&mut SharedTensor<f32>]) {
        // gradient w.r.t. weights
        backend.gemm(&self.one,
                  Transpose::Trans,
                  output_gradients[0],
                  Transpose::NoTrans,
                  input_data[0],
                  &self.zero,
                  parameters_gradients[0])
            .unwrap();
    }
}

I am confused on computing gradients here since there is no derivatives of activation functions

Bernhard Schuster
@drahnr
one is with respect to the parameters or weights of layer itself
it other is regarding the input sample given
iirc
@onFireForGod_gitlab
the activation functions are modeled as separate layers in juice
as such there is no point in having them interleaved with this level