| --- Log opened Wed May 25 00:00:10 2016 | ||
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 250 seconds] | 00:09 | |
| -!- sanuj [~sanuj@117.203.19.130] has joined #shogun | 08:05 | |
| -!- sanuj [~sanuj@117.203.19.130] has quit [Ping timeout: 244 seconds] | 09:00 | |
| -!- sanuj [~sanuj@117.203.19.130] has joined #shogun | 09:24 | |
| -!- Saurabh7 [Saurabh7@gateway/shell/panicbnc/x-qkwwseokbysimqpf] has quit [Ping timeout: 260 seconds] | 09:59 | |
| @wiking | buuuyaaaa | 10:12 |
|---|---|---|
| @wiking | where are all the gsoc slaves? :D | 10:16 |
| sanuj | wiking, hello | 10:17 |
| sanuj | :P | 10:17 |
| @wiking | whatsup | 10:18 |
| @wiking | how's the tagging going? | 10:18 |
| sanuj | i fixed a cookbook bug yesterday | 10:19 |
| sanuj | sending pr for that | 10:19 |
| @wiking | cook | 10:19 |
| @wiking | *cool | 10:19 |
| @wiking | have you encountered any problems with the PR bot? | 10:19 |
| sanuj | i need to make shogun support new tags and parameter | 10:19 |
| sanuj | merge it in develop | 10:19 |
| @wiking | mmm | 10:20 |
| @wiking | i would do that first in a feature branch | 10:20 |
| @wiking | plz | 10:20 |
| sanuj | yes feature branch of course | 10:20 |
| sanuj | then merge it | 10:20 |
| @wiking | do you have a feature branch for that? | 10:20 |
| sanuj | that's first priority as OXPHOS needs to do serialization for that | 10:20 |
| @wiking | dont see one | 10:21 |
| sanuj | no | 10:21 |
| @wiking | ok i'll start a feature branch | 10:21 |
| sanuj | yes :) | 10:21 |
| @wiking | so you can pr to that one | 10:21 |
| sanuj | thanks | 10:21 |
| @wiking | ok | 10:23 |
| @wiking | there it is | 10:23 |
| @wiking | feature/tags | 10:23 |
| sanuj | cool | 10:23 |
| lisitsyn | BOOYAAA | 10:24 |
| sanuj | lisitsyn, are you in office? | 10:25 |
| lisitsyn | not yet | 10:25 |
| sanuj | okay | 10:25 |
| lisitsyn | why? | 10:25 |
| sanuj | just asking | 10:25 |
| lisitsyn | I see :) | 10:25 |
| sanuj | when does it snow in moscow | 10:26 |
| sanuj | :P | 10:26 |
| lisitsyn | sanuj: deffs not now :D | 10:26 |
| sanuj | haha | 10:26 |
| lisitsyn | sanuj: well a few times in october usually | 10:26 |
| sanuj | it's 40 degree C here | 10:26 |
| sanuj | hot hot hot | 10:26 |
| lisitsyn | then it is all covered with snow in mid of november | 10:26 |
| sanuj | ohkay | 10:26 |
| lisitsyn | and finally in early april it is gone | 10:27 |
| @wiking | SAMARA FOR LIFE :) | 10:27 |
| lisitsyn | it is unusually cold now - like 16C | 10:27 |
| sanuj | nice | 10:27 |
| @wiking | lisitsyn: ^ :> | 10:27 |
| sanuj | okay | 10:27 |
| lisitsyn | wiking: well, moscow :D | 10:27 |
| @wiking | but you are not from mosco | 10:27 |
| @wiking | w | 10:27 |
| @wiking | :P | 10:27 |
| lisitsyn | nor from samar | 10:27 |
| lisitsyn | a | 10:27 |
| lisitsyn | :D | 10:27 |
| sanuj | there are many good sport coders from russia | 10:27 |
| @wiking | lisitsyn: loool? | 10:27 |
| @wiking | where then? | 10:27 |
| sanuj | lisitsyn, are you also one of them? ;) | 10:28 |
| lisitsyn | wiking: https://en.wikipedia.org/wiki/Tolyatti | 10:28 |
| lisitsyn | sanuj: nah | 10:28 |
| @wiking | oblast smara! | 10:28 |
| lisitsyn | sanuj: don't like it at all | 10:28 |
| @wiking | there you go | 10:28 |
| lisitsyn | wiking: hah yes | 10:28 |
| sanuj | lisitsyn, we need to do it here for job interviews :P | 10:28 |
| lisitsyn | sanuj: sure | 10:28 |
| lisitsyn | sanuj: actually not for me I think | 10:29 |
| lisitsyn | I mean | 10:29 |
| sanuj | even i don't do it on my own | 10:29 |
| lisitsyn | if I was to change my job it would be quite stupid to ask me to rotate a tree | 10:29 |
| sanuj | haha | 10:29 |
| lisitsyn | as I am leading a team of 6 now | 10:29 |
| lisitsyn | :D | 10:29 |
| sanuj | great! | 10:29 |
| @wiking | lisitsyn: hahahah | 10:30 |
| @wiking | lisitsyn: they still do ask me that :) | 10:30 |
| lisitsyn | wiking: yeah totally stupid | 10:30 |
| @wiking | last time i told the guy | 10:30 |
| @wiking | look man | 10:30 |
| @wiking | i worked with this shit for the last 4 years writing my phd thesis | 10:31 |
| @wiking | i think i know what i was doing | 10:31 |
| @wiking | they took my answer personally :P | 10:31 |
| lisitsyn | wiking: well I don't mind if they ask puzzles | 10:32 |
| lisitsyn | wiking: but not like in that ACM | 10:33 |
| @wiking | ah no it wans't a puzzle | 10:33 |
| @wiking | it was like | 10:33 |
| @wiking | what is an avl-tree | 10:33 |
| @wiking | and how it works | 10:33 |
| @wiking | :))) | 10:33 |
| lisitsyn | haha ok | 10:34 |
| lisitsyn | well | 10:34 |
| @wiking | or same for kd-tree | 10:34 |
| @wiking | and it was clear for me | 10:34 |
| lisitsyn | well it is not that bad | 10:34 |
| @wiking | that they guy who asked me the question | 10:34 |
| lisitsyn | it would be terrible if they asked you this type of problem | 10:34 |
| lisitsyn | like | 10:34 |
| @wiking | had no clue what is a kd-tree | 10:34 |
| lisitsyn | nah I don't know | 10:34 |
| @wiking | because he used only psql's function to find the nearest points | 10:34 |
| @wiking | :) | 10:34 |
| lisitsyn | hah | 10:34 |
| @wiking | so i was a bit asshole when i answered obviously | 10:34 |
| @wiking | but then i realised that i really dont even wanna work with them :) | 10:35 |
| sanuj | wiking, you have 2 phds!? | 10:36 |
| sanuj | i saw your linkedin :P | 10:37 |
| lisitsyn | oh I have a story about linkedin | 10:37 |
| lisitsyn | I've deleted mine | 10:37 |
| lisitsyn | :D | 10:37 |
| sanuj | haha | 10:37 |
| @wiking | sanuj: ahahhah no | 10:37 |
| sanuj | the less stories the better | 10:37 |
| @wiking | sanuj: i've just started my phd somewhere | 10:37 |
| @wiking | and finsihed somewhere else | 10:38 |
| @wiking | lisitsyn: man i wanted to do that | 10:38 |
| @wiking | how did you do it?! | 10:38 |
| sanuj | wiking, so you will be having 2 phds after a few years | 10:38 |
| lisitsyn | wiking: well clicked somewhere in help | 10:38 |
| @wiking | sanuj: hahah i'll not finish taht first one :( | 10:39 |
| @wiking | and one is more than enough for me trust me | 10:39 |
| sanuj | for anyone i guess | 10:39 |
| sanuj | :) | 10:39 |
| sanuj | wiking, you work with medical images? | 10:40 |
| @wiking | sanuj: used to | 10:41 |
| sanuj | okay | 10:41 |
| @wiking | as my research yes | 10:41 |
| sanuj | cool | 10:42 |
| sanuj | wiking, lisitsyn i think both of you have blogs | 10:42 |
| lisitsyn | yeah but I fail to continue that | 10:43 |
| lisitsyn | :D | 10:43 |
| lisitsyn | I've found some will to post a few things | 10:43 |
| sanuj | lisitsyn, why do you blog | 10:43 |
| sanuj | i need inspiration to do that | 10:43 |
| sanuj | okay | 10:43 |
| @wiking | lisitsyn: i'll start pinging you on my blog | 10:43 |
| @wiking | and maybe you'll start answering | 10:43 |
| @wiking | :DDD | 10:43 |
| @wiking | i think the last time i wrote a blog was ages ago | 10:43 |
| @wiking | anyhow | 10:43 |
| @wiking | fuuuuuuuuuuuck | 10:44 |
| @wiking | arianepaola: hey | 10:44 |
| @wiking | so we need to setup benchmarking bots | 10:44 |
| lisitsyn | sanuj: well it helps to write things | 10:47 |
| lisitsyn | like a defrag for your brain | 10:48 |
| sanuj | okay | 10:48 |
| shogun-buildbot | build #2873 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2873 blamelist: Viktor Gal <viktor.gal@maeth.com> | 10:55 |
| lisitsyn | wiking: that's gonna help the humanity | 10:56 |
| lisitsyn | two useful blogs | 10:56 |
| @wiking | :>>>. | 10:57 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 11:11 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 11:11 | |
| -!- Saurabh7 [~Saurabh7@59.96.102.84] has joined #shogun | 11:13 | |
| sanuj | time for food | 11:15 |
| -!- sanuj [~sanuj@117.203.19.130] has quit [Ping timeout: 276 seconds] | 11:22 | |
| shogun-buildbot | build #11 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/11 blamelist: Viktor Gal <viktor.gal@maeth.com> | 11:23 |
| -!- Saurabh7- [Saurabh7@gateway/shell/panicbnc/x-tkhunxevfgkzzhnq] has joined #shogun | 11:25 | |
| -!- leagoetz [~leagoetz@host-92-0-162-192.as43234.net] has joined #shogun | 11:40 | |
| -!- travis-ci [~travis-ci@ec2-174-129-185-139.compute-1.amazonaws.com] has joined #shogun | 11:44 | |
| travis-ci | it's Viktor Gal's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/132773374 | 11:44 |
| -!- travis-ci [~travis-ci@ec2-174-129-185-139.compute-1.amazonaws.com] has left #shogun [] | 11:44 | |
| -!- leagoetz [~leagoetz@host-92-0-162-192.as43234.net] has quit [] | 11:57 | |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has joined #shogun | 12:04 | |
| -!- mode/#shogun [+o lambday] by ChanServ | 12:04 | |
| -!- sonne|osx [~sonne@x4db48e9e.dyn.telefonica.de] has joined #shogun | 12:11 | |
| -!- sanuj [~sanuj@117.203.19.130] has joined #shogun | 12:24 | |
| -!- sonne|osx [~sonne@x4db48e9e.dyn.telefonica.de] has quit [Quit: sonne|osx] | 12:24 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 264 seconds] | 12:30 | |
| -!- sonne|osx [~sonne@x4db48e9e.dyn.telefonica.de] has joined #shogun | 12:34 | |
| -!- Saurabh7 [~Saurabh7@59.96.102.84] has quit [Quit: Leaving] | 12:44 | |
| -!- HeikoS [~heiko@nat-206-247.internal.eduroam.ucl.ac.uk] has joined #shogun | 13:39 | |
| -!- mode/#shogun [+o HeikoS] by ChanServ | 13:39 | |
| sanuj | HeikoS, there? | 14:11 |
| sanuj | lisitsyn, there? | 14:11 |
| lisitsyn | sanuj: yes | 14:12 |
| sanuj | Int is working now in cookbook | 14:12 |
| sanuj | but Int num_components = 3 | 14:12 |
| sanuj | is translated to | 14:12 |
| sanuj | double num_components = 3; | 14:12 |
| sanuj | which gives error | 14:12 |
| sanuj | in java | 14:12 |
| sanuj | lisitsyn, i checked java.json | 14:13 |
| sanuj | looks fine | 14:13 |
| -!- sanuj [~sanuj@117.203.19.130] has quit [Remote host closed the connection] | 14:22 | |
| rcurtin | HeikoS: you were looking for me yesterday | 14:27 |
| @wiking | rcurtin: do you guys maybe have | 14:30 |
| @wiking | a server to share for the benchmark project ?:) | 14:30 |
| @wiking | rcurtin: currenlty i'm planning to put openstack on our machines | 14:32 |
| @wiking | and setup benchmarking like that | 14:32 |
| @wiking | (and yeah aws instances are super slow :P) | 14:33 |
| rcurtin | wiking: I have one machine that we have used in the past | 14:33 |
| rcurtin | is that enough for your needs? | 14:33 |
| rcurtin | it's not incredibly powerful or fast, just a desktop with an i5 and 16GB RAM | 14:34 |
| @wiking | rcurtin: yeah i mean if you would like to contribute :P | 14:34 |
| @wiking | but i dont know if that actually would work | 14:34 |
| @wiking | having 3 different machines | 14:34 |
| @wiking | but then again | 14:35 |
| @wiking | if the (dataset+model) from different libs are running on the same machine | 14:35 |
| @wiking | it should be fine | 14:35 |
| rcurtin | I dunno what you mean, do you mean you want me to give the system to the shogun project? | 14:35 |
| @wiking | nono | 14:35 |
| @wiking | i meant that we setup an openstack | 14:35 |
| @wiking | and run benchmarks on that openstack | 14:35 |
| @wiking | https://www.openstack.org/ | 14:36 |
| rcurtin | hang on, I have to step out | 14:36 |
| @wiking | kk | 14:36 |
| @wiking | no worries | 14:36 |
| rcurtin | let me get back to you later | 14:36 |
| @wiking | this was just an idea | 14:36 |
| @wiking | still wondering about stuff | 14:36 |
| @wiking | how to do the benchmarking | 14:36 |
| rcurtin | yeah I just need to do a little reading | 14:36 |
| rcurtin | I will get back to you :) | 14:37 |
| @wiking | because now we more or less moved | 14:37 |
| @wiking | our stuff on aws | 14:37 |
| @wiking | so we've got our machines freed up for benchmarks | 14:38 |
| @wiking | arianepaola: pong pong pooooooooooooong | 14:40 |
| @wiking | Saurabh7-: yoyoyo | 14:40 |
| -!- Saurabh7 [~Saurabh7@1.39.96.25] has joined #shogun | 14:42 | |
| -!- sanuj [~sanuj@117.203.19.130] has joined #shogun | 14:47 | |
| @wiking | Saurabh7: ping? | 14:48 |
| Saurabh7 | wiking, hi ! | 14:49 |
| @wiking | Saurabh7: how's thing going with the thread safetly | 14:50 |
| @wiking | *safe | 14:50 |
| @wiking | changes | 14:50 |
| @wiking | do you need any hadn help? | 14:50 |
| Saurabh7 | wiking, I am trying to use the features copy constructors for now | 14:51 |
| Saurabh7 | for DenseFeatures it looks good but i dont knwo how to generalize | 14:51 |
| @wiking | ? | 14:51 |
| @wiking | copy ctr? | 14:51 |
| @wiking | for what? | 14:52 |
| @wiking | i mean how? | 14:52 |
| @wiking | if you can share a code | 14:52 |
| @wiking | i can help | 14:52 |
| @wiking | any code | 14:52 |
| Saurabh7 | hm | 14:52 |
| @wiking | just to understand | 14:54 |
| @wiking | what happens with the code | 14:54 |
| Saurabh7 | CDenseFeatures feat =features | 14:54 |
| Saurabh7 | feat->add_subset() | 14:54 |
| Saurabh7 | something like this | 14:54 |
| Saurabh7 | when we want to add multiple subsets | 14:55 |
| @wiking | mmm | 14:55 |
| @wiking | so feat->add_subset() would return a CDenseFeatures | 14:55 |
| @wiking | ? | 14:55 |
| Saurabh7 | no it just adds subset to subsetstack | 14:55 |
| Saurabh7 | feat is copy of features | 14:56 |
| lisitsyn | make it immutable!!! | 14:56 |
| @lambday | Saurabh7: may I ask what are you working on regarding features? | 14:56 |
| lisitsyn | :D | 14:56 |
| @lambday | Saurabh7: you want to create a shallow copy? | 14:56 |
| Saurabh7 | lambday, yes | 14:56 |
| @wiking | Saurabh7: yeah as lisitsyn said and we said yesterday | 14:57 |
| @wiking | immutable | 14:57 |
| @wiking | so just const | 14:57 |
| @wiking | Saurabh7: you are about to eliminate CSubsetStack | 14:57 |
| @wiking | ? | 14:57 |
| Saurabh7 | ok | 14:57 |
| Saurabh7 | wiking, no | 14:57 |
| @lambday | Saurabh7: so for dense features, you want that the underlying feature matrix is the same, but the subsets are copied only? | 14:57 |
| Saurabh7 | just create a copy and add another subset right ? | 14:57 |
| Saurabh7 | lambday, yes | 14:58 |
| Saurabh7 | lambday, and adding different new ones | 14:58 |
| @lambday | Saurabh7: https://github.com/shogun-toolbox/shogun/blob/feature/bigtest/src/shogun/statistical_testing/internals/FeaturesUtil.cpp#L46 | 14:58 |
| @lambday | I added a similar thing here.. | 14:58 |
| @wiking | huh | 14:58 |
| @wiking | lambday: why did you do this ? | 14:58 |
| @wiking | :) | 14:59 |
| @lambday | Saurabh7: maybe this can be of any use? | 14:59 |
| @wiking | i mean why do we have FeaturesUtil | 14:59 |
| @wiking | ? | 14:59 |
| @wiking | should have been part of CFeatures | 14:59 |
| @lambday | wiking: I needed this to create blocks of features (for testing things blockwise) with just different subsets on | 14:59 |
| @wiking | yeah | 14:59 |
| @lambday | although the underlying matrix is same | 14:59 |
| Saurabh7 | lambday, hmm yes | 14:59 |
| @wiking | but why not part of CFeatures? | 14:59 |
| @wiking | as a simple static function of it? :) | 14:59 |
| Saurabh7 | is that only or denseFeatures ? | 14:59 |
| Saurabh7 | for* | 14:59 |
| @lambday | wiking: well, I could add it there.. but I just temporarily added it only for dense | 14:59 |
| @wiking | lambday: yeah as we learned | 15:00 |
| @wiking | if you put a code temporary | 15:00 |
| @wiking | it'll be permanent :D | 15:00 |
| @lambday | wiking: would something like this be useful for CFeatures in general? | 15:00 |
| @lambday | not sure! | 15:00 |
| @wiking | well | 15:00 |
| @wiking | it's part of CFeatures | 15:00 |
| @wiking | so why not | 15:00 |
| @lambday | wiking: alright then.. | 15:01 |
| @wiking | i mean if it's only working for | 15:01 |
| @wiking | DenseFeature | 15:01 |
| @wiking | just add it there | 15:01 |
| @wiking | :) | 15:01 |
| @lambday | alright I'll do that | 15:01 |
| @wiking | thnx | 15:01 |
| @lambday | wiking: would we like to have it in develop right now? | 15:02 |
| @lambday | cause I'm working on this feature branch.. and it's all there for now | 15:02 |
| @wiking | lambday: it will not break anything or? | 15:02 |
| @lambday | wiking: hopefully not.. | 15:02 |
| @wiking | aaah | 15:02 |
| @wiking | if this is not yet in develop | 15:02 |
| @wiking | then it's fine | 15:02 |
| @wiking | just move it in your feature branch | 15:02 |
| @lambday | wiking: so, in CFeatures, we provide this API.. and keep it SGNOTIMPLEMENTED.. and only implement it for DenseFeatures for now.. | 15:03 |
| Saurabh7 | lambday, isnt it similar to this https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/features/DenseFeatures.cpp#L29 | 15:03 |
| @lambday | Saurabh7: I think the other one shares the same subsetstack object as well.. | 15:04 |
| @lambday | Saurabh7: not sure though... can you confirm? | 15:04 |
| @wiking | lambday: yeah sounds good | 15:05 |
| @wiking | although | 15:05 |
| @wiking | i hate SGNOTIMPLEMENTED placeholders :P | 15:05 |
| @wiking | but yeah i know it would take an effort now | 15:05 |
| @lambday | wiking: hehe but we can't just run away from it | 15:05 |
| @HeikoS | jojojo | 15:05 |
| @wiking | to get that implemented everywhere | 15:05 |
| @wiking | lambday: = 0 | 15:05 |
| @wiking | and then just implement it every derived class | 15:05 |
| @wiking | :D | 15:05 |
| @wiking | Saurabh7: can help in that | 15:06 |
| @wiking | :> | 15:06 |
| @wiking | i mean | 15:06 |
| @wiking | if yo udont mind | 15:06 |
| @wiking | he could copy this | 15:06 |
| @wiking | in his branch | 15:06 |
| @lambday | wiking: yeah but does subset make sense for all the feature subclasses? not sure :/ | 15:06 |
| @wiking | and then you'll just rebase and cherrypick his branch for yours | 15:06 |
| @wiking | lambday: imho it shouldn't matter of the type | 15:06 |
| @wiking | i mean why not? | 15:06 |
| @wiking | any feature set should be slicable | 15:06 |
| @wiking | in any ways | 15:06 |
| @wiking | HeikoS: standup: 0/1 ? | 15:07 |
| @lambday | wiking: alright.. this needs some investigation then :D | 15:07 |
| @wiking | lambday: which part? | 15:07 |
| @HeikoS | wiking: I like it, would keep it to the mentor student pair though, otherwise it is hard to track | 15:07 |
| @HeikoS | so "getting in touch daily" +1 | 15:07 |
| @wiking | HeikoS: doesn't need to be sync | 15:07 |
| @wiking | it can be async | 15:07 |
| @lambday | wiking: to check if all the features are subset-able | 15:07 |
| @wiking | that's why i said just to dump here the stuff | 15:07 |
| @HeikoS | wiking: good then | 15:07 |
| @HeikoS | we only have 4 | 15:07 |
| @wiking | and we can look at the logs | 15:07 |
| @HeikoS | so easy to keep track | 15:07 |
| @wiking | lambday: well make it | 15:07 |
| @wiking | :) | 15:07 |
| @HeikoS | sanuj, Saurabh7 Saurabh7- jojo | 15:08 |
| @wiking | i mean this is comptures | 15:08 |
| @wiking | you can do any fucking thing you want | 15:08 |
| @wiking | :) | 15:08 |
| @HeikoS | OXPHOS: jo | 15:08 |
| @HeikoS | discussing linalg? | 15:08 |
| sanuj | hi | 15:08 |
| @wiking | lambday: just add a pure virtual | 15:08 |
| sanuj | HeikoS, i have a question | 15:08 |
| @wiking | and then worst case where it's not supported | 15:08 |
| @wiking | you add a not supported | 15:08 |
| @lambday | wiking: yeah.. gonna take some time though.. but I'll do that | 15:08 |
| @wiking | time? | 15:08 |
| @HeikoS | sanuj: shoot | 15:08 |
| @wiking | give it to Saurabh7 | 15:08 |
| sanuj | HeikoS, Int is working in cookbook now | 15:08 |
| sanuj | HeikoS, but for Java | 15:09 |
| @wiking | lambday: i mean he needs this | 15:09 |
| @lambday | wiking: as in, I want to make it work for those it is supposed to work | 15:09 |
| @wiking | lambday: but why dont you pass this to Saurabh7 ? | 15:09 |
| @lambday | wiking: oh.. then let me start with this | 15:09 |
| @lambday | umm yeah that's also an idea | 15:09 |
| @wiking | he'll make good use of it | 15:09 |
| sanuj | HeikoS, Int component_num = 1 | 15:09 |
| @wiking | and he can finetune it for you | 15:09 |
| sanuj | HeikoS, is converted to | 15:09 |
| @lambday | wiking: that sounds cool! | 15:09 |
| @HeikoS | sanuj: I saw, this is defined throught the json file | 15:09 |
| sanuj | HeikoS, json is fine | 15:10 |
| @lambday | Saurabh7: ^ | 15:10 |
| sanuj | HeikoS, json has "Int": "int", | 15:10 |
| @lambday | Saurabh7: can you confirm that the copy ctor actually uses the same underlying stack? | 15:10 |
| @HeikoS | sanuj: but the json defines the text to text replacement | 15:10 |
| @HeikoS | if it translates to double, then there is a mistake | 15:10 |
| @HeikoS | cant really be | 15:10 |
| Saurabh7 | weee | 15:10 |
| Saurabh7 | lambday, it should be same right? lemme check | 15:11 |
| @lambday | Saurabh7: I meant same object.. | 15:11 |
| @lambday | I want to add different subsets to each of these shallow copies | 15:11 |
| @lambday | without affecting the other | 15:11 |
| @HeikoS | sanuj: lets talk private | 15:11 |
| @lambday | and still want to share the same underlying feature matrix | 15:12 |
| Saurabh7 | lambday, https://github.com/shogun-toolbox/shogun/blob/develop/src/shogun/features/SubsetStack.cpp#L42 | 15:12 |
| Saurabh7 | it createsa copy with same subsets | 15:12 |
| Saurabh7 | so i think it should be good to add new ones onto it | 15:13 |
| @lambday | Saurabh7: doesn't it add the same CSubset* objects? | 15:14 |
| @lambday | Saurabh7: not sure whether that would be a problem | 15:14 |
| @lambday | Saurabh7: don't worry about this.. if the copy ctor serves your purpose.. go ahead with it | 15:15 |
| @lambday | Saurabh7: I'll check once again if it serves my purpose.. | 15:16 |
| @lambday | if not, maybe we can add the shallow copy thing .. I'll create an issue | 15:16 |
| Saurabh7 | lambday,ok i will try to check with yours too whats the difference | 15:16 |
| @lambday | Saurabh7: cool! let me know | 15:16 |
| Saurabh7 | brb | 15:16 |
| @wiking | btw | 15:16 |
| @wiking | anybody has idea how we should patch cmake so that it realises that omp is available in clang 3.8? | 15:17 |
| @wiking | mmm | 15:25 |
| @wiking | we eliminated the use of lp solve? :) | 15:25 |
| @wiking | HeikoS: that pr | 15:26 |
| @wiking | is no goodie | 15:26 |
| @wiking | :) | 15:26 |
| @wiking | not every int | 15:26 |
| @wiking | is a int32_t | 15:26 |
| @wiking | i mean yes on your machine probable | 15:26 |
| @wiking | but shogun runs on other things than x86 | 15:26 |
| @HeikoS | wiking: I see | 15:28 |
| @HeikoS | the point is to have it defined somewhere | 15:29 |
| @HeikoS | for meta examples | 15:29 |
| @HeikoS | it needs to be visible in the ctags | 15:29 |
| @HeikoS | any idea how to get that otherwise? | 15:29 |
| @HeikoS | lisitsyn: ^ | 15:29 |
| @wiking | well it's in stdint.h | 15:30 |
| @wiking | which is included in common.h | 15:30 |
| @wiking | mmm HeikoS we really dont use lpsolve anymore | 15:31 |
| @wiking | anywhere | 15:31 |
| @wiking | i'll remove the dependency check ok? | 15:31 |
| @HeikoS | please do | 15:31 |
| @wiking | i did a git grep USE_LPSOLVE | 15:31 |
| @wiking | and it's only defined | 15:31 |
| @wiking | in config.h.in | 15:31 |
| @wiking | but nowhere is being used | 15:31 |
| @HeikoS | probably forgotting to be guarded | 15:31 |
| @HeikoS | maybe grep for something where it might be used | 15:32 |
| @wiking | mmm tried differnt lp functions | 15:33 |
| @wiking | but if guarding would be a problem | 15:34 |
| @wiking | then it would have errored | 15:34 |
| @wiking | on my machine | 15:34 |
| @wiking | as it didn't detect lpsolve | 15:34 |
| @wiking | on my machine | 15:34 |
| @wiking | still it managed to compile everyting | 15:34 |
| @wiking | so i think we removed lp solve dependency | 15:36 |
| @wiking | :D | 15:36 |
| @wiking | HeikoS: you reckon we wanna have that back ever? | 15:37 |
| @wiking | woah | 15:38 |
| @wiking | they just released a new version | 15:38 |
| @wiking | after 5 years | 15:38 |
| @wiking | ;D | 15:38 |
| rcurtin | wiking: so I am still not sure what you mean | 15:39 |
| rcurtin | it is definitely possible to run the benchmark system on an openstack machine | 15:39 |
| rcurtin | but I am not sure how we could be helpful with that | 15:40 |
| rcurtin | I don't have any openstack setup | 15:40 |
| rcurtin | all I have are a handful of identical desktops we do benchmarking on | 15:40 |
| @wiking | ok so what i thought | 15:40 |
| @wiking | that we join our mahcine forces | 15:40 |
| @wiking | using openstack | 15:40 |
| rcurtin | another consideration is that openstack will give you Vms | 15:40 |
| rcurtin | so timings may have high variance | 15:41 |
| @wiking | yeah but it's kvm | 15:41 |
| @wiking | so it's barebone | 15:41 |
| @wiking | machine | 15:41 |
| @wiking | the only difference could be | 15:41 |
| @wiking | if you run for example | 15:41 |
| @wiking | kmeans on one machine | 15:41 |
| rcurtin | (on the train and on a phone, slow responses) | 15:41 |
| @wiking | scikit-learn kmeans on one machine | 15:41 |
| @wiking | and then mlpack kmeans on another machine | 15:41 |
| @wiking | but if it's running on the same openstack instance | 15:42 |
| -!- Saurabh7 [~Saurabh7@1.39.96.25] has quit [Ping timeout: 240 seconds] | 15:43 | |
| @wiking | so if we run 1 algo but all it's different versions (mlpack, shogun, scikit-learn) in the same openstack instance | 15:43 |
| @wiking | then the timing will be the same | 15:43 |
| @wiking | i mean it will not vary | 15:43 |
| @wiking | although | 15:44 |
| @wiking | and this is the shitty part | 15:44 |
| @wiking | that we are not only interested in relative diff | 15:44 |
| @wiking | but absolute diff | 15:44 |
| @wiking | :( | 15:44 |
| rcurtin | but still this is running on a VM and so if any other VMs are running on the same hardware you get slowdown | 15:45 |
| @wiking | rcurtin: openstack | 15:45 |
| @wiking | i mean it will not give you more machines | 15:45 |
| @wiking | than it is avaialble on that node | 15:45 |
| @wiking | i.e there will not be any race condition for cpu/memory | 15:45 |
| rcurtin | yes but what I am saying is when you have more than one Vm on a physical host your timings are no longer accurate | 15:46 |
| rcurtin | if you are saying that openstack is one Vm per physical host | 15:46 |
| rcurtin | then this is different | 15:46 |
| @wiking | no | 15:46 |
| @wiking | but why would it be the timing different | 15:46 |
| rcurtin | I am not intricately familiar with openstack | 15:46 |
| @wiking | i mean if you take | 15:46 |
| @wiking | n instances on the machine | 15:46 |
| arianepaola | using openstack will just add more complexity | 15:46 |
| @wiking | that fits into the machine | 15:47 |
| @wiking | they will not cause timing problems | 15:47 |
| arianepaola | you can even run docker in openstack on top of vagrant.... | 15:47 |
| @wiking | arianepaola: but i just want to have a way to be able to share resources | 15:47 |
| @wiking | for that we need some sort of resource managment | 15:47 |
| rcurtin | wiking: if you can prove tht variability of runs is not larger than with a single non Vm I will believe you | 15:47 |
| arianepaola | every layer brings down performance | 15:47 |
| @wiking | to know where resource i available if any | 15:47 |
| rcurtin | but at the moment I do not | 15:48 |
| rcurtin | I think that a better way to collaborate | 15:48 |
| @wiking | rcurtin: this is not a belief | 15:48 |
| @wiking | :) | 15:48 |
| @wiking | i mean this is being used in many places :D | 15:48 |
| rcurtin | is to have shared setup scripts or something like this | 15:48 |
| @wiking | like rackspace | 15:48 |
| @wiking | but then again | 15:48 |
| @wiking | it was just an idea | 15:48 |
| @wiking | if you dont believe in it it's fine | 15:48 |
| @wiking | i'm not going to spend time to prove something that is know to be working | 15:48 |
| @wiking | sorry | 15:48 |
| rcurtin | wiking: that does not mean variance in timing runs is not higher than with a physical host :) | 15:49 |
| @wiking | do you know what's kvm? | 15:49 |
| @wiking | or xen for that matter? | 15:49 |
| @wiking | either of them | 15:49 |
| @wiking | will make sure that you are actually running the actual instruction | 15:49 |
| @wiking | on your cpu | 15:49 |
| @wiking | it's not vm | 15:49 |
| rcurtin | yes | 15:50 |
| rcurtin | but you still have limited disk Io | 15:50 |
| @wiking | and we care about disk io perfomance in case of kmeans? | 15:50 |
| rcurtin | if you are benchmarking data load time also then yes | 15:50 |
| rcurtin | and that is currently what the benchmark scripts do | 15:51 |
| @wiking | ok so you cannot separate data loading time | 15:51 |
| @wiking | from the actual modeling method? | 15:51 |
| @wiking | because in that case i suppose the best way to beat the benchmarking is | 15:51 |
| rcurtin | ah I need to think about that | 15:51 |
| rcurtin | there are ways but they can be complex | 15:51 |
| @wiking | that you write a fully threadable read IO | 15:51 |
| @wiking | and:) | 15:51 |
| rcurtin | so I need to revisit the code and get back to ou | 15:51 |
| @wiking | no worries | 15:52 |
| @wiking | i'm just trying to figure out | 15:52 |
| @wiking | how both of us can benefit | 15:52 |
| @wiking | because having this benchmarks | 15:52 |
| @wiking | would be great for all of us | 15:52 |
| @wiking | not just shogun or mlpack | 15:52 |
| rcurtin | yes absolutely | 15:52 |
| rcurtin | but we should keep in mind that the sustem is (or should be) easy to deploy and run | 15:52 |
| @wiking | yeah | 15:52 |
| @wiking | other option is to use mesos :P | 15:53 |
| @wiking | and docker images | 15:53 |
| rcurtin | so it should not be 100% nevessary to run on the same hardware | 15:53 |
| @wiking | yep | 15:53 |
| @wiking | i just want to be able to run this | 15:53 |
| rcurtin | docker might be useful here because getting the roght dependencies can be a pain | 15:53 |
| @wiking | on more than one machine | 15:53 |
| @wiking | yeah | 15:53 |
| @wiking | true | 15:53 |
| @wiking | i have packer.io configs for having the build deps for shogun | 15:53 |
| @wiking | it took me a good day | 15:53 |
| rcurtin | it would be easy to write a dockerfile for this, maybe I will do this sometime | 15:54 |
| @wiking | to define that for fedora, centos, debian,ubuntu | 15:54 |
| @wiking | rcurtin: i would highly advise to use packer.io for this | 15:54 |
| rcurtin | I have other setup to do with our build server first though :( | 15:54 |
| @wiking | that way you can generate a docker image | 15:54 |
| @wiking | as well as aws ami | 15:54 |
| @wiking | as well as virtualbox image | 15:54 |
| @wiking | etc. | 15:54 |
| @wiking | ;) | 15:54 |
| @wiking | so it's a good tool for such things | 15:54 |
| @wiking | so once you define your packer.io config | 15:54 |
| @wiking | you are golden | 15:55 |
| @wiking | for any type of 'instance' | 15:55 |
| rcurtin | possibly | 15:55 |
| rcurtin | though I will not lie, I have little excitement about learning a new tool :) | 15:55 |
| @wiking | yeah i can understand | 15:56 |
| @wiking | but this way you can hit more birds with 1 stone | 15:56 |
| @wiking | :P | 15:56 |
| shogun-buildbot | build #12 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/12 blamelist: Viktor Gal <viktor.gal@maeth.com> | 15:56 |
| rcurtin | that is true | 15:56 |
| shogun-buildbot | build #2874 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2874 blamelist: Viktor Gal <viktor.gal@maeth.com> | 15:56 |
| @wiking | rcurtin: do you guys use eigne? | 15:56 |
| rcurtin | back to the original question, what can I do to help with openstack? | 15:57 |
| rcurtin | no, we use armadillo | 15:57 |
| @wiking | rcurtin: i'm still investigating | 15:57 |
| rcurtin | I don't want to commit to using openstack o produce pur benchmarks | 15:57 |
| @wiking | i was just wondering if you'd be interested | 15:57 |
| @wiking | in this type of collaboration | 15:57 |
| rcurtin | *to produce our | 15:57 |
| rcurtin | but I do want to help | 15:57 |
| rcurtin | and if we can share our configurations this I think would be a good way to go | 15:58 |
| @wiking | k | 15:58 |
| rcurtin | the thing to keep in mind is, it is very likely at some point we will disagree on how the benchmarks should be done | 15:59 |
| rcurtin | there is already an issue by the elki maintainer to this matter | 16:00 |
| rcurtin | hang on | 16:00 |
| rcurtin | getting off the train | 16:00 |
| rcurtin | will finish the thought shortly | 16:00 |
| @wiking | :) | 16:00 |
| @wiking | hehehe ok | 16:00 |
| -!- leagoetz [~leagoetz@nat-214-50.internal.eduroam.ucl.ac.uk] has joined #shogun | 16:03 | |
| -!- sanuj [~sanuj@117.203.19.130] has quit [Ping timeout: 272 seconds] | 16:06 | |
| OXPHOS | HeikoS: sry I didn't log out last night | 16:08 |
| rcurtin | so as more libraries become inteested in this more people will have opinions and resolving disputes will become intractable | 16:08 |
| rcurtin | disputes like "do we include I/O" or "what do we set the parameters to for these datasets" | 16:09 |
| OXPHOS | HeikoS wiking: linalg: https://gist.github.com/OXPHOS/0eaa17411e00936f1ed61388ec5c0af6 | 16:09 |
| rcurtin | because these little questions can make big differences for which library looks best | 16:09 |
| rcurtin | so I think we should try to avoid these altogether by taking the approach of "you should set this system up yourself and run it in your own setting!" and this should help avoid a lot of long discussions | 16:09 |
| rcurtin | wiking: what do you think? | 16:09 |
| @wiking | just a sec | 16:12 |
| @wiking | was doing some other shit | 16:12 |
| rcurtin | sure, no hurry. I am at my office now so I can type a little faster :) | 16:12 |
| @wiking | heheh | 16:12 |
| @wiking | yep sounds reasonable | 16:12 |
| rcurtin | https://github.com/zoq/benchmarks/issues/9 is an example of what I mean | 16:13 |
| rcurtin | it started as a simple request and discussion, then suddenly turned into "you should be doing your k-means benchmarking completely differently" | 16:14 |
| @wiking | ah fuck | 16:15 |
| @wiking | ok nerd war | 16:15 |
| @wiking | :) | 16:15 |
| rcurtin | yeah basically that is what it was, I want to avoid more of those where possible :) | 16:15 |
| rcurtin | it sounds to me, like maybe what would be most useful might be a packer.io config (I guess I will learn it...) that generates images with the benchmarking system installed? | 16:16 |
| rcurtin | this way you can just deploy one of these images on openstack, and I can deploy them on my antiquated desktops and live in the past :) | 16:16 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has joined #shogun | 16:17 | |
| @lambday | OXPHOS: hello | 16:17 |
| rcurtin | I think that at some point I would like to compare the variability of runs on openstack and on my desktop, but that should be pretty easy once the system is set up... just run some benchmark ten times or so over a week or something like this, then compare variance | 16:17 |
| @lambday | OXPHOS: how's it going? | 16:17 |
| rcurtin | and if the variance is very small I will shut up and maybe move to openstack :) | 16:18 |
| OXPHOS | lambday Hey! I add something here: https://gist.github.com/OXPHOS/0eaa17411e00936f1ed61388ec5c0af6 | 16:19 |
| OXPHOS | lambday: I have tested the base-derived class in shogun independent module and I'm now writing dot test case | 16:19 |
| @lambday | OXPHOS: yeah it would be awesome to have a running demo :) | 16:21 |
| @wiking | OXPHOS: what happens if you dont have HAVE_VIENNACL ? | 16:22 |
| @lambday | OXPHOS: BTW I was thinking that the thing that wiking suggested, would have been easily doable if we'd have used CUDA | 16:22 |
| @wiking | i mean the problem here is that | 16:22 |
| @lambday | I was wondering whether we can do the same with opencl+viennacl but I am afraid we cannot | 16:22 |
| @wiking | this thing will be part of the modular fw | 16:22 |
| @wiking | and that case you dont care HAVE_VIENNACL | 16:22 |
| @wiking | because either you have it or dont | 16:23 |
| @wiking | that means if you dont = you dont have the .so for doing that | 16:23 |
| @wiking | and actually the most interesting part | 16:24 |
| @wiking | about the gpu backand | 16:24 |
| @wiking | will we have | 16:24 |
| @lambday | wiking: without viennacl, there is no way we can define a memory in GPU, that, when viennacl **IS** present, can utilize | 16:24 |
| @wiking | viennacl_cuda | 16:25 |
| @wiking | and viennacl_opencl .so? | 16:25 |
| @lambday | wiking: with CUDA we could have a simply int* gpu_vec... | 16:25 |
| @wiking | lambday: but you dont get it right? | 16:25 |
| @wiking | you dont care about that | 16:25 |
| @lambday | with viennacl it is not possible, cause it uses cl_mem | 16:25 |
| @wiking | you dont need that ifdef | 16:25 |
| @wiking | it should be an opaq pointer | 16:25 |
| @wiking | not used in the header | 16:25 |
| @wiking | because either you can do shit with it | 16:26 |
| @wiking | because you have the backend | 16:26 |
| @wiking | and then you compile | 16:26 |
| @HeikoS | lisitsyn: around? | 16:26 |
| @wiking | or you dont have the backend | 16:26 |
| @wiking | and then you dont have the .so | 16:26 |
| @wiking | or you have the .so | 16:26 |
| @wiking | but it throws back a | 16:26 |
| @wiking | 'fuck i dont have a gpu/opencl compatible shit' | 16:26 |
| @lambday | wiking: I agree.. this of course should be a pimpl | 16:27 |
| @wiking | GPUptr | 16:27 |
| @wiking | should be an opaque pointer | 16:27 |
| @wiking | that is only actually used | 16:27 |
| @wiking | in .cpp | 16:27 |
| @lambday | wiking: agreed! | 16:27 |
| @wiking | ok i'm back to debugging fucking qemu | 16:27 |
| @lambday | OXPHOS: you got the idea? | 16:27 |
| OXPHOS | lambday: the GPUvector subclass need a opaque pointer? | 16:28 |
| @lambday | OXPHOS: yep! | 16:28 |
| @wiking | lambday: and actually | 16:28 |
| @wiking | think about how we are gonna support | 16:28 |
| @HeikoS | wiking: got another question | 16:28 |
| @HeikoS | typedef double float64_t; | 16:28 |
| @HeikoS | so this is fine? | 16:28 |
| @wiking | different gpu pointers | 16:29 |
| @wiking | HeikoS: not at all | 16:29 |
| @wiking | :) | 16:29 |
| @HeikoS | it is in common.h | 16:29 |
| @wiking | HeikoS: then remove it | 16:29 |
| @wiking | :) | 16:29 |
| @HeikoS | can you pls check? | 16:29 |
| @HeikoS | there is more of that kind | 16:29 |
| @lambday | wiking: actually we're trying to solve a problem that viennacl guys did already.. they already work with (1) cpu memory (2) opencl gpu memory and (3) cuda memory.. | 16:29 |
| @HeikoS | wiking: the reason I touched this is kind of totally unrelated to the sense or nonsense of such definitions | 16:29 |
| @lambday | their vectors and matrices work with all | 16:30 |
| @lambday | we're trying to solve the same problem.. | 16:30 |
| @HeikoS | so I kind of want to sidestep getting into that for now, but just make the meta examples work | 16:30 |
| @wiking | lambday: yep, buuuut how you wanna solve | 16:30 |
| @wiking | when somebody implements | 16:30 |
| @HeikoS | so I wonder, shall we put this as an issue, resolve all of them at once at some point? | 16:30 |
| @wiking | a magma based linalg backend? :) | 16:30 |
| @wiking | that should be a reasonable idea no? :) | 16:30 |
| @lambday | wiking: have a different subclass that does the thing.. | 16:30 |
| @wiking | subclass :P | 16:30 |
| -!- c4goldsw [5da420e6@gateway/web/cgi-irc/kiwiirc.com/ip.93.164.32.230] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] | 16:30 | |
| @lambday | wiking: and then have the factory return **that** type when asked for a gpu type | 16:31 |
| @wiking | i mean of GPUVector? | 16:31 |
| @wiking | because yeah subclass of gpu backend | 16:31 |
| @wiking | yes yes | 16:31 |
| @wiking | but i mean | 16:31 |
| @wiking | the interface | 16:31 |
| @wiking | since we want to be opaque like this | 16:31 |
| @wiking | that GPUBackend | 16:31 |
| @wiking | = whichever | 16:31 |
| @wiking | and it'll have the right types | 16:31 |
| @wiking | HeikoS: looking aroudn | 16:31 |
| @lambday | wiking: I think subclasses of GPUVectors would have to do then.. | 16:32 |
| @lambday | or maybe, have the impl class use the #ifdef's | 16:32 |
| @lambday | but then in a platform where multiple of these are available, then we can only use a single one.. so... not good idea! | 16:33 |
| @wiking | lambday: but no | 16:33 |
| @wiking | again | 16:33 |
| @wiking | you dont care if multiples are avaialb | 16:33 |
| @wiking | e | 16:33 |
| @wiking | you will have n different .so | 16:34 |
| @wiking | that implement a gpu backend | 16:34 |
| @wiking | the user will define it | 16:34 |
| @wiking | which one you wanna use | 16:34 |
| @wiking | and in worst case that backend will | 16:34 |
| @wiking | throw a runtime exception | 16:34 |
| @wiking | on registration | 16:34 |
| @wiking | when it checks that actually that shared library | 16:34 |
| @wiking | can access the right hw or not that it requires to run properly | 16:35 |
| @wiking | see what i mean? | 16:35 |
| @wiking | and actually this is why we would like to have a config file now for shoung | 16:36 |
| @wiking | where you can define these globals | 16:36 |
| @wiking | like: where are all the shared libraries | 16:37 |
| @wiking | or what's the gpu/cpu backend you wanna use | 16:37 |
| @wiking | etc | 16:37 |
| @wiking | which of course you can override at runtime | 16:37 |
| @wiking | just having a default via a conf would be good | 16:37 |
| @lambday | wiking: can you please clarify what we're supposed to do in registration? | 16:38 |
| @lambday | does it sort of specify that -- this is the *.so that we wanna use | 16:38 |
| @wiking | yes | 16:38 |
| @wiking | this is the .so you will use | 16:38 |
| @wiking | and that should be loaded | 16:38 |
| @lambday | (shogun_gpu_impl_XXX.so) [XXX=viennacl] | 16:38 |
| @lambday | and so on | 16:39 |
| @lambday | alright.. | 16:39 |
| @wiking | yeah | 16:39 |
| @wiking | and then you dlopen that | 16:39 |
| @wiking | register it in your linalg backend | 16:39 |
| @wiking | etc | 16:39 |
| @wiking | i mean you can do this | 16:39 |
| @HeikoS | wiking: whats your thoughts on common.h? | 16:39 |
| @wiking | while you do init_shogun() | 16:39 |
| @wiking | because we have that shit anyways | 16:39 |
| @wiking | :) | 16:39 |
| @wiking | HeikoS: yeah i'm looking | 16:39 |
| @wiking | HeikoS: about the float | 16:40 |
| @wiking | the ctags i dont know | 16:40 |
| @wiking | but dont do what you did in your pr | 16:40 |
| @HeikoS | yeah sure | 16:40 |
| @wiking | because that's not true | 16:40 |
| @HeikoS | looking for a better way | 16:40 |
| @lambday | wiking: alright.. so about implementing it this way, we got to have different subclasses of GPUVectors I assume.. the ones that uses viennacl will be compiled and dumped into that shogun_gpu_impl_viennacl.so and so on | 16:41 |
| @lambday | and for that, we have to keep the GPUvector generic.. no impl dependency | 16:41 |
| @lambday | wiking: is that what you mea | 16:41 |
| @lambday | mean* | 16:41 |
| @wiking | lambday: why do you have to have different subclass? | 16:42 |
| @wiking | you can just have different implementation of it | 16:42 |
| @lambday | wiking: okay I see what you mean | 16:42 |
| @wiking | because if you use GPUVector of viennacl backend | 16:43 |
| @wiking | that linalg backend will implement the gpu 'interface' | 16:43 |
| @wiking | and the backend will know what the opaque pointer actually stands for | 16:43 |
| @wiking | right? | 16:43 |
| @lambday | wiking: yeah | 16:44 |
| @wiking | but yeah each gpu backend should have it's own gpuvector | 16:44 |
| @wiking | and these are not interchangable | 16:44 |
| @lambday | wiking: yeah and that's what the different impls will have to take care of | 16:44 |
| @wiking | but the interface (header) should be the same | 16:44 |
| @wiking | yep yep | 16:44 |
| @lambday | wiking: yeah I totally agree | 16:44 |
| @lambday | cool! | 16:45 |
| @lambday | OXPHOS: ^ :) | 16:45 |
| OXPHOS | lambday: trying to understand | 16:45 |
| @lambday | OXPHOS: see the main thing here is to develop this architecture.. | 16:45 |
| @lambday | and dot is our lab-rat | 16:45 |
| @lambday | OXPHOS: so the idea is - GPUVector should be more of an interface of how we communicate with gpu vectors of different impls | 16:46 |
| OXPHOS | lambday: it seems the idea of *GPUbackend in linalg class can stays the same - and the GPUvector will be like GPUbackend | 16:47 |
| @wiking | lambday: my only concern is a bit that branch in the dot() function | 16:47 |
| @wiking | :() | 16:47 |
| @lambday | wiking: what do you mean? | 16:47 |
| @wiking | well you know that part | 16:48 |
| OXPHOS | lambday: I was thinking users can specify what GPUbackend they want to use by passing different instance of GPUbackend | 16:48 |
| OXPHOS | lambday: but realized now GPUbackend ONLY works for ViennaCL | 16:48 |
| @wiking | where you check the SGVectors type,.... where it is stored | 16:48 |
| @wiking | lambday: it might be a good idea to have for the dot function | 16:49 |
| @wiking | a flag | 16:49 |
| @wiking | like | 16:49 |
| @wiking | dot(vectorA, vectorB, type) | 16:50 |
| @wiking | where type is | 16:50 |
| @wiking | = AUTO | 16:50 |
| @wiking | = GPU | 16:50 |
| @wiking | = CPU | 16:50 |
| @wiking | and by default the type is AUTO | 16:50 |
| @wiking | this way you can avoid that branching in the code | 16:50 |
| @wiking | i mean i know it's just couple of instructions | 16:51 |
| @wiking | but we were bithching about the overhead of virtual | 16:51 |
| @wiking | :P | 16:51 |
| @lambday | wiking: actually I thought of handling it via virtuals yesterday :D | 16:51 |
| @lambday | wiking: by a way that the vector impls *know* how to do dot on themselves | 16:51 |
| @lambday | but then we won't need the linalg::dot(...) method at all.. | 16:52 |
| @lambday | because one can always do | 16:52 |
| @lambday | auto a = factory::getgpuinstance(a) | 16:52 |
| @lambday | a->dot(b) | 16:52 |
| @lambday | where a is the base class of the vector type | 16:53 |
| @wiking | yep | 16:53 |
| @lambday | a is *of | 16:53 |
| @lambday | wiking: that eliminates the branching | 16:54 |
| @lambday | but the downside is, all linalg operations are member methods now | 16:54 |
| @lambday | kinda like the linearoperator, linearsolver and eigensolver interface we have | 16:54 |
| @lambday | wiking: if having it this way is okay API-wise, then we can have this instead | 16:55 |
| @lambday | I mean, eigen does it anyway | 16:55 |
| @lambday | a.dot(b) | 16:55 |
| @lambday | m.doshit(a) | 16:55 |
| @lambday | wiking: what do you think? ^^ | 16:57 |
| @wiking | just a sec | 16:58 |
| @wiking | trying to figure out why the hell qemu is shit on jessie | 16:58 |
| @lambday | haha | 16:58 |
| OXPHOS | lambday: how can we have different implement in the same GPUVector(class)? (Just generally asking) | 17:01 |
| @lambday | OXPHOS: we have have that using pimpls | 17:02 |
| @lambday | OXPHOS: say, for example, for viennacl type of vectors, we need an array of vcl::opencl::mem_handle to store the vector | 17:02 |
| @lambday | OXPHOS: and for CUDA, we store it with simple T* | 17:02 |
| @lambday | but in the header, we don't declare shit | 17:03 |
| @lambday | :D | 17:03 |
| @lambday | we just say, here, have a pointer to an impl.. which knows how to do all those stuff | 17:03 |
| @lambday | and then we define the impl in the cpp, not in *.h | 17:03 |
| @lambday | so.. in the cpp, based on different flags, we write code.. | 17:04 |
| OXPHOS | so we have a pointer unique_ptr<GPUV> pt, but GPUV can be different based on flags in GPUV .cpp | 17:04 |
| @lambday | when we compile, we can have different *.o based on those flags | 17:04 |
| @lambday | OXPHOS: precisely :) | 17:05 |
| OXPHOS | lambday: so we still need flags - maybe for the whole class - thought about sth fancier :P | 17:05 |
| @lambday | OXPHOS: yes but we push the flags to the cpp | 17:05 |
| @lambday | OXPHOS: the header is flag free | 17:05 |
| OXPHOS | lambday: got it | 17:06 |
| @lambday | and, inside the header, we don't have to say how to store it.. because the storage is different | 17:06 |
| @lambday | so that solves the problem :) | 17:06 |
| OXPHOS | lambday: and the same idea for the GPUBackend class? | 17:07 |
| @lambday | OXPHOS: let me check what we had in there | 17:09 |
| @lambday | OXPHOS: actually, this class can just have a bunch of static methods I think | 17:11 |
| @lambday | umm but yeah maybe we need the pimpl there also | 17:12 |
| OXPHOS | lambday: yes seems it can ONLY support one type of GPU module | 17:12 |
| @lambday | I mean, we won't implement anything in the header anyway | 17:12 |
| @lambday | yeah this would need some polishing | 17:12 |
| @lambday | but let me hear wiking on having it the other way we discussed yesterday... that is, the linalg operations are a part of the vector/matrix classes thmselves.. | 17:13 |
| OXPHOS | lambday: sure | 17:13 |
| @lambday | a->dot(b) instead of dot(a, b) | 17:13 |
| @lambday | I am trying to think of operations where this type of API can pose problems | 17:14 |
| @lambday | we already have eigensolver and linear solver that works with this type of interface | 17:15 |
| OXPHOS | it looks ugly.. | 17:16 |
| OXPHOS | but nevermind :) | 17:17 |
| @lambday | OXPHOS: haha the a.dot(b) thing? | 17:21 |
| OXPHOS | lambday: yeah..[feels like] all methods are in SGVector class. But since a, b here are specifically designed for linalg, I guess it's fine.. XD | 17:24 |
| @lambday | yeah a and b are not SGVector/SGMatrix at all | 17:25 |
| @lambday | but yeah i see what you mean | 17:26 |
| -!- sanuj [~sanuj@117.203.19.130] has joined #shogun | 17:26 | |
| @lambday | we just want to see whether the if-else in every linalg call is a good idea or not.. | 17:26 |
| @lambday | cause if we have it this way, then we save the branching | 17:26 |
| shogun-buildbot | build #247 of deb1 - libshogun - PR is complete: Failure [failed git] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun%20-%20PR/builds/247 blamelist: karlnapf | 17:31 |
| @HeikoS | sanuj: I think I ixed it | 17:32 |
| @HeikoS | sanuj: see my pr | 17:32 |
| sanuj | okay | 17:32 |
| sanuj | checking | 17:32 |
| @HeikoS | sanuj: I now forbid the use of "Int" "Real", but rahter use "int" "real" | 17:34 |
| @HeikoS | these are basic types and no include path is checked for them | 17:34 |
| @HeikoS | so no problems with ctags | 17:34 |
| @HeikoS | sanuj: waiting for travis | 17:35 |
| sanuj | HeikoS, how does it find stuff if you include nothing? | 17:37 |
| @wiking | HeikoS: dunno wtf is happening with git | 17:38 |
| @wiking | fatal: Could not parse object 'f5adee722739e5a892ee968bc51461c5b907236a'. | 17:38 |
| @wiking | fatal: Couldn't find remote ref refs/pull/3205/head | 17:38 |
| shogun-buildbot | build #248 of deb1 - libshogun - PR is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun%20-%20PR/builds/248 | 17:39 |
| sanuj | lisitsyn, where to add 'any' in shogun? | 17:44 |
| lisitsyn | sanuj: lib | 17:44 |
| sanuj | cool | 17:45 |
| @HeikoS | wiking: yeah git is delayed | 17:46 |
| @HeikoS | wiking: when I pushedto my fork | 17:46 |
| @HeikoS | it didnt show up on the page for a few mins | 17:46 |
| @HeikoS | thats why I closed and re-opened old PR | 17:46 |
| @HeikoS | sanuj: sorry what? | 17:54 |
| @HeikoS | sanuj: I now just treat basic types as such, so no include lookup is being done in c++ | 17:54 |
| sanuj | i see | 18:06 |
| sanuj | HeikoS, i'll update my pr once you merge yours | 18:07 |
| @HeikoS | sanuj: had to change something and restart travis | 18:07 |
| @HeikoS | but should do it now | 18:07 |
| @HeikoS | sanuj: only thing you need to change is to use lower case basic type names | 18:08 |
| sanuj | yes and rebase | 18:08 |
| @HeikoS | yep exactly | 18:08 |
| @HeikoS | sanuj: how are things going with the tags? | 18:08 |
| sanuj | shifting them into shogun, couldn't do much | 18:09 |
| sanuj | doing it now | 18:09 |
| sanuj | and i'm reading sergey's tags implementation from aer | 18:10 |
| sanuj | it has better code | 18:10 |
| lisitsyn | it has the best code ever | 18:12 |
| lisitsyn | :D | 18:12 |
| lisitsyn | because it is written by the boss | 18:12 |
| lisitsyn | :D | 18:12 |
| sanuj | lisitsyn, ;) | 18:12 |
| @HeikoS | lisitsyn: ^ | 18:13 |
| @HeikoS | lisitsyn! | 18:13 |
| @HeikoS | lisitsyn dance | 18:14 |
| @HeikoS | mmh | 18:14 |
| @HeikoS | doesnt work | 18:14 |
| @HeikoS | ;) | 18:14 |
| sanuj | hahaha | 18:14 |
| @HeikoS | thought you might say sorry | 18:14 |
| lisitsyn | sorry | 18:15 |
| lisitsyn | autosorry | 18:15 |
| sanuj | lisitsyn, shall i put Tag also in lib? | 18:20 |
| lisitsyn | autosorry | 18:20 |
| lisitsyn | sanuj: yeah probably | 18:20 |
| sanuj | cool | 18:20 |
| lisitsyn | the difference between base and lib is vague | 18:21 |
| lisitsyn | but probably it's lib | 18:21 |
| sanuj | okay | 18:21 |
| sanuj | lisitsyn, any is in aer::impl::any | 18:26 |
| sanuj | any reason for impl? | 18:26 |
| lisitsyn | no not really | 18:26 |
| sanuj | shall i just keep shogun::any | 18:26 |
| lisitsyn | yeap | 18:30 |
| sanuj | oh actually its a bit different | 18:30 |
| sanuj | the policies are in impl | 18:31 |
| sanuj | any is in shogun itself | 18:31 |
| sanuj | so no problem | 18:31 |
| lisitsyn | yeah feel free to flatten namespaces | 18:32 |
| sanuj | lisitsyn, and the comment stuff that is there in every code file | 18:32 |
| sanuj | the licensing part | 18:33 |
| lisitsyn | what comment stuff? | 18:33 |
| sanuj | and written copyright etc | 18:33 |
| lisitsyn | what license is it? | 18:33 |
| lisitsyn | bsd? | 18:33 |
| sanuj | other shogun code has gpl | 18:33 |
| lisitsyn | keep it bsd | 18:36 |
| sanuj | okay | 18:36 |
| sanuj | HeikoS, build is failing | 18:40 |
| sanuj | https://travis-ci.org/shogun-toolbox/shogun/builds/132882156 | 18:40 |
| @HeikoS | checking | 18:40 |
| sanuj | knn failed | 18:41 |
| sanuj | the integration tests | 18:41 |
| sanuj | HeikoS, we'll have to change the data | 18:42 |
| @HeikoS | I think thats it | 18:43 |
| @HeikoS | might have to change more than that | 18:43 |
| @HeikoS | since I changed types | 18:43 |
| @HeikoS | checking locally | 18:43 |
| @HeikoS | make test worked for me a bit earlier | 18:43 |
| sanuj | cool | 18:45 |
| @HeikoS | yeah its the data | 18:47 |
| sanuj | fine then | 18:47 |
| @HeikoS | sanuj: updated | 18:51 |
| @HeikoS | the others should also fail | 18:51 |
| @HeikoS | though maybe not | 18:52 |
| @HeikoS | no "Int" definitions were in them | 18:52 |
| @HeikoS | but lets wait for travis | 18:52 |
| sanuj | HeikoS, others didn't fail last time | 18:53 |
| @HeikoS | better wait, you never know what might go wrong :) | 18:53 |
| @HeikoS | dont wanna break the build in gsoc | 18:53 |
| sanuj | correct :) | 18:53 |
| sanuj | haha | 18:53 |
| @HeikoS | annoying for everyone | 18:53 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 18:59 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 18:59 | |
| sanuj | HeikoS, for BSD what comment do i need to add in the beginning of a new code file | 19:03 |
| @wiking | sanuj: check this file: src/shogun/ensemble/CombinationRule.h | 19:04 |
| @wiking | as an example | 19:04 |
| sanuj | okay | 19:04 |
| @HeikoS | https://gist.github.com/karlnapf/24763634d5142f92f5213d282cf67e0f | 19:05 |
| @HeikoS | add you name | 19:05 |
| @HeikoS | ^ this one has encoding, as suggested by besser82 | 19:05 |
| @wiking | ah yeah | 19:05 |
| @wiking | that one was actually a shitty one | 19:05 |
| @wiking | that was gpl | 19:05 |
| @wiking | sanuj: sorry | 19:05 |
| sanuj | okay thanks | 19:05 |
| sanuj | i'm adding sergey's name too | 19:09 |
| sanuj | lisitsyn, what email | 19:12 |
| -!- leagoetz [~leagoetz@nat-214-50.internal.eduroam.ucl.ac.uk] has quit [] | 19:14 | |
| lisitsyn | sanuj: lisitsyn.s.o@gmail.com | 19:19 |
| @HeikoS | sanuj: merged | 19:25 |
| sanuj | okay | 19:26 |
| sanuj | i'll rebase and update | 19:26 |
| shogun-buildbot | build #3745 of deb1 - libshogun is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3745 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:26 |
| shogun-buildbot | build #661 of trusty - libshogun - viennacl is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/661 blamelist: Heiko Strathmann <heiko.strathmann@gmail.com> | 19:27 |
| @HeikoS | gnaaa | 19:28 |
| @HeikoS | build broken | 19:28 |
| shogun-buildbot | build #662 of trusty - libshogun - viennacl is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/trusty%20-%20libshogun%20-%20viennacl/builds/662 | 19:28 |
| @HeikoS | deb1 - libshogun wasnt broken by my commit actually | 19:31 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 260 seconds] | 19:32 | |
| @HeikoS | shogun-buildbot: force build --branch=develop 'deb1 - libshogun' | 19:36 |
| shogun-buildbot | build forced [ETA 12m53s] | 19:36 |
| shogun-buildbot | I'll give a shout when the build finishes | 19:36 |
| shogun-buildbot | build #3746 of deb1 - libshogun is complete: Success [build successful] Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3746 | 19:38 |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 19:50 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 19:50 | |
| -!- sanuj [~sanuj@117.203.19.130] has quit [Ping timeout: 240 seconds] | 20:05 | |
| -!- HeikoS [~heiko@nat-206-247.internal.eduroam.ucl.ac.uk] has quit [Quit: Leaving.] | 20:31 | |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 252 seconds] | 20:34 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 20:41 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 20:41 | |
| -!- lambday [8028b10a@gateway/web/freenode/ip.128.40.177.10] has quit [Ping timeout: 250 seconds] | 20:56 | |
| @wiking | \o/ we have a f23 aarch64 bot | 21:38 |
| arianepaola | :-) | 21:41 |
| arianepaola | wiking: I would like to try to integrate the nightly rpm build into that bot | 21:42 |
| @wiking | ok | 21:42 |
| @wiking | what do you need from me/ | 21:42 |
| @wiking | we have 2 fedora bots | 21:43 |
| @wiking | one is f22 the other is f23 | 21:43 |
| @wiking | and now this aarch64 f23 | 21:43 |
| arianepaola | wiking: if you have a base config, I can merge the snippet that I posted to the fedora issue | 21:44 |
| @wiking | oh those steps | 21:45 |
| @wiking | i can try to add | 21:45 |
| @wiking | can you give me the pr | 21:45 |
| @wiking | link | 21:45 |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has quit [Quit: buildmaster reconfigured: bot disconnecting] | 21:55 | |
| -!- shogun-buildbot [~shogun-bu@7nn.de] has joined #shogun | 21:55 | |
| @wiking | shogun-buildbot: force build --branch=develop 'FC23 - libshogun - aarch64' | 21:56 |
| shogun-buildbot | build #0 forced | 21:56 |
| shogun-buildbot | I'll give a shout when the build finishes | 21:56 |
| @wiking | lets see | 21:56 |
| arianepaola | wiking: https://github.com/shogun-toolbox/shogun/issues/3131 | 21:57 |
| @wiking | okey | 21:58 |
| @wiking | lemme see | 21:58 |
| shogun-buildbot | build #0 of FC23 - libshogun - aarch64 is complete: Failure [failed compile] Build details are at http://buildbot.shogun-toolbox.org/builders/FC23%20-%20libshogun%20-%20aarch64/builds/0 | 22:04 |
| -!- besser82 [~besser82@fedora/besser82] has quit [Ping timeout: 264 seconds] | 22:25 | |
| -!- besser82 [~besser82@fedora/besser82] has joined #shogun | 22:26 | |
| -!- mode/#shogun [+o besser82] by ChanServ | 22:26 | |
| -!- thoralf [~thoralf@ip5b4189cf.dynamic.kabel-deutschland.de] has joined #shogun | 22:34 | |
| -!- mode/#shogun [+o thoralf] by ChanServ | 22:34 | |
| @thoralf | Hey * | 22:34 |
| @wiking | ho | 22:35 |
| shogun-buildbot | build #13 of xenial - libshogun is complete: Failure [failed test] Build details are at http://buildbot.shogun-toolbox.org/builders/xenial%20-%20libshogun/builds/13 blamelist: Viktor Gal <viktor.gal@maeth.com> | 22:37 |
| shogun-buildbot | build #2875 of bsd1 - libshogun is complete: Failure [failed configure] Build details are at http://buildbot.shogun-toolbox.org/builders/bsd1%20-%20libshogun/builds/2875 blamelist: Viktor Gal <viktor.gal@maeth.com> | 22:38 |
| arianepaola | bye everyone, see you all tomorrow | 22:52 |
| -!- travis-ci [~travis-ci@ec2-54-166-247-85.compute-1.amazonaws.com] has joined #shogun | 23:10 | |
| travis-ci | it's Heiko Strathmann's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: https://travis-ci.org/shogun-toolbox/shogun/builds/132913670 | 23:10 |
| -!- travis-ci [~travis-ci@ec2-54-166-247-85.compute-1.amazonaws.com] has left #shogun [] | 23:10 | |
| --- Log closed Thu May 26 00:00:12 2016 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!