| 7 Mar 2017 |
 @gitter_botev:matrix.org | if you have given operator schedule | 18:41:30 |
| @gitter_botev:matrix.org | basically you know the last operation each tensor is part of | 18:41:39 |
| @gitter_botev:matrix.org | so you know that after that it can be dorpped, or even used for inplace | 18:41:49 |
| 16 Mar 2017 |
 @gitter_jonysy:matrix.org | Parenchyma 0.0.3! 🎉✌️ https://github.com/lychee-eng/parenchyma | 22:34:06 |
| @gitter_botev:matrix.org | congrats :clap: | 22:42:07 |
| 17 Mar 2017 |
| @gitter_jonysy:matrix.org | Thanks! | 01:52:47 |
| @gitter_jonysy:matrix.org | Here’s another graph-based ML library https://github.com/millardjn/alumina | 12:57:49 |
| @gitter_botev:matrix.org | that one seems mainly targeting rust | 14:19:18 |
| @gitter_jonysy:matrix.org | @botev There’s no reason the sigmoid function found in Leaf couldn’t be converted to GIR and then compiled to CUDA/OpenCL, correct? | 16:23:33 |
| @gitter_jonysy:matrix.org | (edited) ... to CUDA/OpenCL, correct? => ... to CUDA/OpenCL kernels, correct? | 16:24:14 |
| @gitter_jonysy:matrix.org | (edited) ... to CUDA/OpenCL kernels, correct? => ... to a CUDA/OpenCL kernel, correct? | 16:24:30 |
| @gitter_jonysy:matrix.org | While keeping Leaf’s API | 16:26:15 |
| @gitter_jonysy:matrix.org | @botev I checked out your arrayfire crate for GIR.. You aren’t doing any source/kernel generation, you’re simply using arrayfire Arrays instead of compiling the source to a kernel and then loading it in arrayfire. Is there a reason for that? | 16:51:51 |
| @gitter_botev:matrix.org | you can not the kernel generation in Arrayfire | 16:52:14 |
| @gitter_botev:matrix.org | the reason is arrayfire is easy to get things going, as it implements this and works on anything | 16:52:33 |
| @gitter_botev:matrix.org | I'm currently working on the opencl bit | 16:52:40 |
| @gitter_botev:matrix.org | where kernel generation will happen | 16:52:50 |
| @gitter_botev:matrix.org | Arrayfire is a nice abstraction to use, and to show how the graph works, without needing to do kernel generation | 16:53:21 |
| @gitter_jonysy:matrix.org | I understand. You’re basically creating a heavily optimized transpiler, which is a huge undertaking | 16:55:41 |
| @gitter_jonysy:matrix.org | (edited) ... optimized transpiler, which ... => ... optimized transpiler - which ... | 16:55:52 |
| @gitter_botev:matrix.org | what is transpiler? it also ilustrates how you can used the autodiff of gir in to other packages which already have numerical routines | 16:56:34 |
| @gitter_jonysy:matrix.org | You aren’t essentially transpiling Rust to CL? | 16:57:26 |
| @gitter_botev:matrix.org | is that like translating? | 16:57:37 |
| @gitter_botev:matrix.org | im sorry never came across the term | 16:57:44 |
| @gitter_jonysy:matrix.org | Yes, basically. I should probably use the word translator, anyway | 16:58:25 |
| @gitter_jonysy:matrix.org | Or compiler | 16:58:54 |
| @gitter_botev:matrix.org | then yes, however I like to think of it as a Meta-LLVM | 16:59:26 |
| @gitter_botev:matrix.org | llvm what it does is it takes some code in language X and translates it to architecture Y | 16:59:45 |
| @gitter_jonysy:matrix.org | A transpiler is a source-to-source language translator. So, it compiles (or translates, for that matter) a source to another source | 16:59:47 |
| @gitter_botev:matrix.org | (edited) ... to architecture ... => ... to binary for architecture ... | 17:00:00 |
