IRC logs of #shogun for Friday, 2015-08-21

« Thursday, 2015-08-20 Index Saturday, 2015-08-22 »
--- Log opened Fri Aug 21 00:00:45 2015
shogun-buildbotbuild #1036 of nightly_default is complete: Failure [failed test notebooks]  Build details are at http://buildbot.shogun-toolbox.org/builders/nightly_default/builds/1036  blamelist: Wu Lin <yorker.lin@gmail.com>, Bj?rn Esser <bjoern.esser@gmail.com>06:07
-!- shaochuan [~shaochuan@c-50-184-81-180.hsd1.ca.comcast.net] has joined #shogun07:51
-!- shaochuan [~shaochuan@c-50-184-81-180.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds]07:55
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has joined #shogun08:17
-!- lambday [c40f1065@gateway/web/freenode/ip.196.15.16.101] has joined #shogun09:01
-!- mode/#shogun [+o lambday] by ChanServ09:01
@lambdaylisitsyn: hey09:09
lisitsynlambday: hey09:09
@lambdaylisitsyn: so I was reading up a few articles regarding reducing compilation time and many of them say that pimpl helps a lot - sometimes it even halved the time required09:10
lisitsynahh09:10
lisitsynyeah pimpl is good09:10
@lambdaylisitsyn: I am worried about the overhead - and how to fit it with the tag idea you had for getters setters09:11
@lambdaylike additional mem alloc/dealloc09:11
@lambdaylisitsyn: http://www.gotw.ca/publications/mill04.htm and http://www.gotw.ca/publications/mill05.htm says custom allocator/deallocator helps at times09:14
@lambdayherb sutter09:14
lisitsynlambday: see post in my blog :)09:14
lisitsynI have crazy solution09:14
@lambdaylisitsyn: could you please give me the link?09:15
lisitsyna sec09:15
lisitsynhttp://sergey.lisitsyn.me/2014/04/17/opaque-pointers-revisited/09:15
@lambdaythanks - checking09:16
lisitsynlambday: tldr make an assumption about pimpl size09:16
lisitsynand keep it in object directly09:16
@lambdayouter object09:17
@lambdayumm won't that be nonportable?09:17
@lambdayI am reading the whole thing anyway :D09:17
lisitsynlambday: portable but not ready for changes09:19
lisitsynyou get static assert error if you exceed provided size09:20
lisitsynyou add field09:20
lisitsynand get struct of size 48 while storage size is 3209:20
lisitsynyou have to change header09:21
lisitsynI have no idea but I don't feel its that bad09:21
@lambdayhmm.. actually herb mentioned an idea similar to yours in the article link I posted..09:25
@lambdaybut he's advising against it09:25
@lambdayhe's suggesting that use pimpl in general and use fast pimpl only if you think that all the hassle is worth taking (make some benchmarks)..09:25
@lambdaybut the result is impressive!09:27
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]09:27
lisitsynlambday: yeah I wouldn't advocate using it everywhere :)09:27
lisitsynbut I was scaried with allocator patches09:27
@lambdaylisitsyn: in shogun we do have our custom allocators/deallocators - why can't we take it one step further?09:28
lisitsynlambday: yes09:28
lisitsynthat's ok09:29
lisitsynohh09:29
lisitsynI see it has exactly the same idea09:29
@lambdayyep09:29
lisitsynpff I should have read all the article09:30
@lambdaylol that's impossible09:30
lisitsynnow I feel I presented an idea09:30
lisitsynthat was presented before my birth09:30
lisitsynor so09:31
lisitsyn:D09:31
lisitsyn199809:31
@lambday:D09:31
lisitsynwhen I was 7 okay okay09:31
@lambdayis that it?09:31
@lambdayoh ya 9809:31
@lambdaygreat minds think alike :D09:31
lisitsynidea thief09:31
lisitsyn:D09:31
lisitsynI am09:31
@lambdayso I'll toy with the idea of a fast memory allocator simialr to herb's and make some benchmarks09:36
@lambdaymaybe in shogun also it could work out for good09:36
lisitsynlambday: hmm yes lets do it09:40
lisitsyn:)09:40
@lambdaylisitsyn: did we settle with the Tag or Property<T> idea for getters/setters?09:40
lisitsynlambday: neither09:40
lisitsyncan't decide09:40
@lambdaylet me check the mail09:40
lisitsyn:D09:40
@lambdaypimpl and tag/property should go together09:41
lisitsynthey come together nicely09:41
lisitsynlambday: one thing does not09:41
lisitsyninheritance09:41
@lambdaywhy do we need inheritance :P09:42
lisitsynlambday: although you need just one pimpl to rule them all09:42
lisitsynin SGObject09:42
@lambdaylisitsyn: could you please explain that part a bit?09:42
lisitsynlambday: if you use tags09:43
lisitsynyou just have Map<Tag, Value>09:43
lisitsynin the impl09:43
lisitsynbut you need just one09:43
@lambdayyeah09:43
@lambdayjust one map you're saying09:43
@lambdayyeah09:43
lisitsynyes09:43
lisitsynwe can have other things09:43
lisitsynto handle signals and shit09:43
lisitsyneverything can be in SGObject09:44
@lambdayyes09:44
lisitsyninheritance solved09:44
lisitsyn:D09:44
@lambdayhow about serialization?09:44
lisitsynjust save that map09:45
lisitsynit is as easy as it gets09:45
@lambdayyeah09:45
@lambday:D09:45
@lambdayawesome then!09:45
lisitsynok just one thing09:45
lisitsynI don't like tags09:45
lisitsynthey don't come with plugins09:46
lisitsynhowever09:46
lisitsynno, they could be used with plugins09:46
lisitsynlambday: maybe we can support *both* get(string), get(tag)09:46
lisitsynget(string) is non typed and should be casted09:46
lisitsynget(tag) is typed09:46
lisitsynhow do you like it?09:46
@lambdaywhat do you mean by should be casted?09:47
* lambday brb09:48
lisitsynlambday: get("parameter").asInt()09:50
lisitsynlambday: till you cast it it is of some magic type09:58
lisitsynjust generic 'parameter'09:58
lisitsynif you want to use it as int/flaot/whatever please cast :)09:59
* lambday back10:07
@lambdaylisitsyn: yes it sounds good..10:08
@lambdaylisitsyn: why would we need typed get(tag) then?10:08
lisitsynfor speed10:08
@lambdayI mean, is there anything we'd miss if not that tag? apart from the fact of a bit overhead for that string comparison10:08
lisitsynand typed10:08
lisitsyntyped is the most important10:09
lisitsynsay you integrate into something high performance10:09
lisitsynyou do call getters often10:09
@lambdayyeah that's true10:09
lisitsynI think it would be better to have something typed and fast as well10:09
@lambdayyeah that's true10:09
@lambdayso SWIG-wise it would remain the same as before10:10
@lambdayactually let me dig the possible implementation from the chat history - I am not recalling the details correctly10:11
lisitsynI see no swig issue10:11
@lambdaylisitsyn: could you please help me understand it a bit? say, I have struct C { int i; float f;}; .. how many setter/getters would we have10:12
@lambdayTag get(std::string)10:13
lisitsynwhy get(std::string) is tag?10:13
lisitsynlambday: we need get(Tag<T>) for any T10:13
lisitsynT is int,float, + base classes of shogun10:14
@lambdayyou were talking about supporting both10:14
@lambdayso Tag<T> get(std::string) and T get(Tag<T>) ??10:15
@lambdayassuming Tag<T> has T asT() method ?10:15
lisitsynno10:15
lisitsynParameter get(string)10:15
lisitsynT get(Tag<T>)10:15
@lambdayokay10:15
lisitsynParameter has internal type10:16
lisitsynand has T as{T}()10:17
lisitsynif required type is not castable from the original one10:17
lisitsynyou get runtime error10:17
@lambdayokay that sounds good10:17
@lambdayso how Parameter is related to Tag10:17
lisitsynno relation10:19
lisitsynParameter is just a generic holder for some value10:19
@lambdayalright10:21
@lambdaywell, if Tag is template, how would the Map in SGObject would work?10:21
@lambdayaah I am not finding the stammtisch log10:22
@lambdayfound it10:22
lisitsynlambday: oops sorry10:29
lisitsynlambday: map would use some hash10:30
lisitsynwhatever10:30
lisitsynyou can convert Tag<T> to hash10:30
@lambdaydemangled stuff?10:30
@lambdayoh10:30
lisitsynwhy?10:30
@lambdayna nevermind10:30
lisitsynhash Tag<T> = hash of its object + hash of type T + hash of its name10:31
lisitsynlooks valid :)10:31
@lambdayyeah makes sense10:31
@lambdayname has to be there10:31
@lambdayalong with others10:31
@lambdayactually all are important10:31
lisitsynlambday: I wouldn't care about internals10:32
lisitsynit is solvable for sure10:32
@lambdayyep10:32
lisitsynthe most important is api10:32
lisitsynlambday: we can write unit-tests first maybe10:32
@lambdayyeah10:33
@lambdaylet10:33
@lambdaylet's first have these classes - and then we'll add SGObject10:33
@lambdayonce this whole thing work we'll iteratively add other classes to shogun-lite10:34
@lambdayare10:34
@lambdayaer*10:34
lisitsynlambday: can we maybe select some time10:35
lisitsynto do some real coding10:35
lisitsynis there any time that works for you tomorrow?10:36
@lambdaylisitsyn: I can devote weekends now10:36
lisitsynI mean lets take a few really intense coding sessions :D10:36
@lambdaylisitsyn: tomorrow works - so does tonight10:36
@lambdaylisitsyn: yeah10:36
lisitsynwe should be able to prototype then10:36
@lambdayI will be online more often on irc10:37
lisitsynlambday: what changed?10:37
@lambdaylisitsyn: weekend party session stopped :D friends are going to US for MS/PhD - I'm left alone here10:37
lisitsynhaha lol10:38
@lambdayI'll write GRE in a couple of months10:38
lisitsynyou going to the US as well?10:38
@lambdayno preparation yet whatsoever :D10:38
@lambdaylisitsyn: fingers crossed! Before that I want to go to UK once - maybe some internship10:39
lisitsynoh okay cool10:39
lisitsynso we have some time before you're gone10:39
lisitsyn:D10:39
@lambday1 year at least10:39
lisitsynthat happened a few times to other people10:39
@lambdayhah Heiko too is doing super busy PhD but he's there :D10:40
lisitsynlambday: ok what about tomorrow same time10:40
@lambdayso it really depends on the people10:40
lisitsynlets take tmux and write code together lol10:40
@lambdaylisitsyn: I'll be online on IRC tomorrow, say, 7:30 GMT10:41
lisitsynok cool10:41
@lambdaylisitsyn: today I'll think a bit details regarding this Tag-Parameter framework10:41
@lambdaymaybe make a small POC10:42
@lambdaywill help us in the discussion for tomorrow10:42
lisitsynI can discuss things a bit later today10:42
lisitsynI am now heading to the office10:42
@lambdaysuper10:42
@lambdayI will be free in 5-6 hrs10:42
lisitsyncool10:42
lisitsynok let me take bus and subway :D10:43
@lambdayhehe go safe!10:43
-!- lambday [c40f1065@gateway/web/freenode/ip.196.15.16.101] has quit [Quit: Page closed]11:49
-!- lambday [c40f1065@gateway/web/freenode/ip.196.15.16.101] has joined #shogun11:52
-!- mode/#shogun [+o lambday] by ChanServ11:52
lisitsynlambday: hey11:55
@lambdaylisitsyn: heya11:56
lisitsyndo you have access to hedonismbot?11:56
@lambdaynope11:56
@lambdaydon't even know what that is11:56
@besser82lambday, still there?12:11
@lambdaybesser82: yes12:11
@lambdaybesser82: how are you?12:13
@lambdaybesser82: using fedora 22 since last week - smooth! :D12:13
* lambday afk12:21
-!- lambday [c40f1065@gateway/web/freenode/ip.196.15.16.101] has quit [Quit: Page closed]13:53
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has joined #shogun13:55
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]14:03
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has joined #shogun14:04
-!- lambdday [6a3386ac@gateway/web/freenode/ip.106.51.134.172] has joined #shogun14:37
-!- mode/#shogun [+o lambdday] by ChanServ14:37
@besser82lambday, nice ^^  Have a few questions for you...14:55
@besser82lambdday, sry... been afk...14:55
@lambddaybesser82: hey...14:56
@lambddaybesser82: yeah shoot :)14:56
@besser82lambdday, I'm currently experimenting with splitting Shogun into "plugins"...14:56
@lambddaybesser82: awesome!14:57
@besser82So we can significantly reduce, e.g. memory needed for compiling swig-bindingins14:57
@lambddaylisitsyn: ^^14:57
@besser82He already knows  ;)14:57
@besser82lambdday, ^14:57
@lambddayokay.. great!14:57
@lambddayso what did you find14:57
@besser82I was thinking of making the math-part of Shogun pluginzed as well...14:58
@besser82like having a base-lib providing factory / prototypes of the methods14:58
@lambddaybesser82: yes that makes sense!14:58
@besser82and dyn-loading plugins for several backends14:58
-!- lambdday is now known as lambday14:59
@besser82like a plugin for "linalg"-impl, one for "atlas / blas" and one for openCL14:59
@besser82lambday, ^14:59
-!- shaochuan [~shaochuan@2601:647:4600:fac5:84cc:4487:f96a:1751] has joined #shogun14:59
@lambdayso linalg-impl is the base?14:59
@lambdayor it's shogun's native impl14:59
@besser82linalg is the current base-impl15:00
@lambdaybesser82: ^15:01
@besser82my plan is to have stubs as base-impl15:01
@besser82and then use the plugin, which is avail15:02
@besser82or if several are avail the one with better perdormance15:02
@besser82performance15:02
@besser82lambday, ^15:02
@lambdaybesser82: hmm.. do you think it would be better than the present header-only scenario, which we just use as more of an external lib in Shogun's cpp files?15:03
-!- shaochuan [~shaochuan@2601:647:4600:fac5:84cc:4487:f96a:1751] has quit [Ping timeout: 246 seconds]15:04
@lambdayI mean, the present functionality is more like how Eigen does it15:04
@lambdayno dynlibs15:04
@lambdaybesser82: would putting these stuffs into separate plugins help us compilation-wise or swig-wise?15:08
@besser82lambday, it would help in both cases15:10
@besser82lambday, if we have that split, we can fully hide math-impl from swig15:10
@besser82lambday, like we just have the base-lib of shogun, which just holds factory / base classes for elementary-type like CSVM, exposed to swig15:11
@besser82everything else is performed on full c++-level then15:12
@lambdaybesser82: but those things that are only used in cpp files in the implementation are also hidden from swig, isn't it? sorry I don't have much idea of how swig works..15:13
@lambdayI mean, if we don't expose any of these math things in public API, would swig bother about them?15:13
@besser82lambday, yes, what happnes in cpp-files is mostly hidden from swig15:13
@besser82lambday, but stuff in headers, like template-stuff and all needs swig to generate wrappers for15:14
@lambdaybesser82:  even if the header is only included in the cpp?15:14
@besser82lambday, not sure, but likely yes15:15
@lambdaybesser82: that's bad!!! cause in most cpp we include <Eigen/Eigen> and that's millions of lines of code!!15:15
@lambdayoh but our swig doesn't generate any wrappers for eigen types, does it?15:16
@besser82lambday, afaik, no...15:16
@besser82lambday, but it is still really big15:16
@lambdaybesser82: yeah that's true15:16
@besser82lambday, e.g. octave-bindings currently need 6+ Gigs of RAM15:17
@besser82lambday, during build15:17
@lambdayso in every file that header is included, the compiler has to go through the same pain every time? or things are saved in some cache or so?15:17
@lambdaybesser82: holy ****15:17
@besser82lambday, if one uses ccache-swig, then there is cache otherwise no15:18
@lambdayhmm15:18
@lambdayyeah that's bad!15:18
@besser82next thing is:  pluginizing math-stuff would help to write the plugins more general...15:18
@besser82like it only interfaces the lib with those stubs...15:19
@besser82which then instances the real class from plugin...15:19
@besser82lambday, ^15:19
@lambdaybesser82: yeah it sounds good15:20
@besser82so there won't be any matter inside the plugin which backend we use for maths15:20
@lambdaybesser82: so how it would work? say, I have eigen3 and viennacl both in my machine - i'd ask the factory to give me a llt solver with eigen3 backend - it then dynamically loads that plugin15:21
@besser82lambday, yes that way15:22
@lambdaybesser82: sounds great then!15:22
@besser82lambday, like my_maths = mathalicious::llt_instance("eigen3");15:23
@besser82my_maths.perform(&data)15:23
@lambdaybesser82: sweet!!15:23
@besser82lambday, =)15:24
@lambdaybesser82: so the thing is, we'd be using inheritance and overloading instead of compile time things15:24
@lambdaylike we'd have this base class derived class hierarchy15:24
@besser82lambday, right,  factory-class with polymorphics15:25
@lambdaybesser82: it might take a performance hit, but more manageable for sure15:25
@besser82lambday, performance has just a little penalty on init15:26
@lambdayand also the current template-metaprogramming thingi is tough to maintain15:26
@besser82lambday, just a bit...  we just need to turn the current stuff into generalized factories15:26
@lambdaybesser82: well, virtual calls would cost us a bit compared to compile-time scenarios but that won't be bottleneck compared to the actual operation costs15:27
@besser82okay... but that's pretty affordable I'd say15:27
@lambdaybesser82: yeah it sounds good15:27
@besser82lambday,  =)  So you think: Let's give it a shot?15:27
@lambdaybesser82: yeah sure!15:28
@lambdaybesser82: the issue is - from where we start? :D15:28
@lambdaylisitsyn has a prototype ready for the plugin framework - but it has to have a bit polishing - for the ABI compatibility issues with C++15:29
@lambdaywe thought of having a C layer and on top of it C++ layer15:29
@lambdayfor the plugin arch15:29
@besser82lambday, I'm currently writing such a nice thingie  ;)15:30
@lambdaybesser82: superb!! please share!15:30
@besser82lambday, sure, when stuff is ready for test-running  ;)15:30
@lambdaybesser82: awesome!!! :D15:30
-!- txomon|home [~txomon@unaffiliated/txomon] has quit [Read error: Connection reset by peer]15:36
-!- txomon|home [~txomon@unaffiliated/txomon] has joined #shogun15:37
@besser82lambday, my deep idea behind it is:  we keep things in seperate libs, one is shogun-baselib, one is maths and one handles plugin-stuff...15:38
@lambdaybesser82: yeah.. that would be good..15:39
@lambdaybesser82: now which parts would go into baselib15:40
@lambdaywe have to have all the base classes in the baselib, right?15:40
@besser82lambday, we need to have all shogun-classes (like CSVM, ...) in the shogun-lib...15:44
@besser82math-related factory-classes go into the math-lib and get interfaced with the shogun-plugins directly15:45
@besser82shogun-lib and math-lib interface with the pluginmanager-lib to get instances of derived classes15:46
@besser82lambday, ^15:46
@besser82in that way, we can hide all but needed shogun-classes and their methods from swig15:48
@lambdaybesser82: okay so no further granularity within shogun classes - yeah this solves one major issue15:48
@lambdaybesser82: earlier when we thought of this, it was something like, say, CMachine would be in the base-lib, but CSVM would be inside a plugin..15:49
@lambdayand then we were restricted to use only the methods in CMachine in CSVM that can be overridden15:50
@lambdaybut with this approach, we won't face that issue15:50
@besser82lambday, that would be possible, but would cause ugly API and those short-comings you just mentioned...15:50
@besser82so, yes15:50
@lambdaybesser82: yeah this way sounds better15:50
@lambdaythe one that you mentioned15:50
@lambdaycause maths takes up quite a lot of place15:51
@lambdayso shogun-algorithms are actually client code for the math-lib15:51
@besser82yes, or at least the math-functions used within them15:52
@lambdayyeah basically15:52
@lambdaythe algorithms are anyway mostly maths :D15:52
@besser82sure...  but we need to keep the algorithms general15:53
@besser82like having the algorithm is the shogun-plugin and have it called the needed maths func from math-lib15:54
@besser82so we can easily change math-backends15:54
@lambdayso it's the user who decides15:55
@lambdaybesser82: btw me and lisitsyn were discussing about rewriting SGObject using pimpl which should go well with plugin arch as well and reduce compile time further..15:56
@lambdayso all the parameter stuffs go inside SGObject itself, including mem-management..15:56
-!- txomon|home [~txomon@unaffiliated/txomon] has quit [Read error: Connection reset by peer]15:56
lisitsynlambday: ah and shogun server!15:57
lisitsynif we hide impl15:57
lisitsynwe can make remote sgobject15:57
@lambdaylisitsyn: REST API? :D15:57
lisitsynyes15:58
lisitsyninside15:58
-!- txomon|home [~txomon@unaffiliated/txomon] has joined #shogun15:58
@lambdaybesser82: can't wait to see your stuff :D let's all align our aims15:59
@besser82lambday, lisitsyn: Yeah!  Sure!  :D16:01
lisitsynlets design by commitee! :D16:02
@lambdaywould be cool if we could have had that hackathon Heiko talked about last year :D16:05
@besser82for sure!16:06
lisitsynoh no with hackathon we have a risk of aiming the same goal16:13
lisitsyn;)16:13
@lambdaylisitsyn: that's bad?16:22
@lambday:P16:22
lisitsynjk16:22
@lambday:D16:23
-!- shogun-notifier- [~irker@7nn.de] has joined #shogun17:12
shogun-notifier-shogun: Wu Lin :develop * 84c57cc / src/shogun/optimization/ (2 files): https://github.com/shogun-toolbox/shogun/commit/84c57cc3073055c349f91d55f1b35d99ede5d6fe17:12
shogun-notifier-shogun: update comments17:12
shogun-notifier-shogun: Wu Lin :develop * e7a54ad / src/shogun/optimization/ (5 files): https://github.com/shogun-toolbox/shogun/commit/e7a54ad1709cd671d857963f5c2662218bcba69d17:12
shogun-notifier-shogun: updated comments17:12
shogun-notifier-shogun: Wu Lin :develop * f3cfdfe / src/shogun/optimization/ (6 files): https://github.com/shogun-toolbox/shogun/commit/f3cfdfe94db233c2d9e93dee38a9596b8471f25417:12
shogun-notifier-shogun: Merge pull request #2896 from yorkerlin/develop17:12
shogun-notifier-shogun:17:12
shogun-notifier-shogun: update comments17:12
shogun-buildbotbuild #3476 of deb1 - libshogun is complete: Failure [failed test]  Build details are at http://buildbot.shogun-toolbox.org/builders/deb1%20-%20libshogun/builds/3476  blamelist: Wu Lin <yorker.lin@gmail.com>17:17
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]17:50
-!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout]20:12
-!- shaochuan [~shaochuan@2601:647:4600:fac5:84cc:4487:f96a:1751] has joined #shogun20:32
-!- shaochuan [~shaochuan@2601:647:4600:fac5:84cc:4487:f96a:1751] has quit [Ping timeout: 246 seconds]20:37
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has joined #shogun22:58
-!- PirosB3 [~pirosb3@host216-94-dynamic.12-79-r.retail.telecomitalia.it] has quit [Quit: PirosB3]23:43
--- Log closed Sat Aug 22 00:00:46 2015
« Thursday, 2015-08-20 Index Saturday, 2015-08-22 »

Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!