--- Log opened Fri Apr 27 00:00:19 2012 | ||
-!- n4nd0 [~nando@188.Red-2-137-0.dynamicIP.rima-tde.net] has quit [Quit: leaving] | 00:34 | |
-!- av3ngr [av3ngr@nat/redhat/x-fdgjejyzjtxwmlhd] has joined #shogun | 02:30 | |
-!- vikram360 [~vikram360@117.192.187.42] has quit [Ping timeout: 260 seconds] | 03:01 | |
-!- PhilTillet [~Philippe@vir78-1-82-232-38-145.fbx.proxad.net] has quit [Ping timeout: 260 seconds] | 04:17 | |
-!- vikram360 [~vikram360@117.192.172.17] has joined #shogun | 06:10 | |
-!- gsomix [~gsomix@188.168.5.45] has quit [Read error: Operation timed out] | 08:37 | |
CIA-64 | shogun: Soeren Sonnenburg master * r4574712 / (3 files in 2 dirs): | 08:43 |
---|---|---|
CIA-64 | shogun: don't do SG_FREE on varray.begin | 08:43 |
CIA-64 | shogun: This is now handled in the destructor of v_array and additional free's | 08:43 |
CIA-64 | shogun: only cause double free bugs. - http://git.io/r81grA | 08:43 |
shogun-buildbot | build #739 of cmdline_static is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/cmdline_static/builds/739 | 09:05 |
-!- vikram360 [~vikram360@117.192.172.17] has quit [Ping timeout: 250 seconds] | 09:10 | |
-!- magicfly [c07c1afb@gateway/web/freenode/ip.192.124.26.251] has quit [Quit: Page closed] | 09:21 | |
-!- av3ngr [av3ngr@nat/redhat/x-fdgjejyzjtxwmlhd] has quit [Remote host closed the connection] | 09:32 | |
-!- av3ngr [~av3ngr@60-241-222-244.static.tpgi.com.au] has joined #shogun | 09:55 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 10:40 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 10:41 | |
-!- av3ngr [~av3ngr@60-241-222-244.static.tpgi.com.au] has quit [Quit: That's all folks!] | 11:12 | |
sonne|work | wiking: looks like we are the lone rangers today... | 11:15 |
wiking | hehehe people went on holidays or what? :) | 11:15 |
sonne|work | looks like | 11:16 |
sonne|work | I would have wanted to talk to pluskid again about these new sgvector developments but hey | 11:16 |
wiking | what's the final decision on that? | 11:16 |
sonne|work | there is no final decision | 11:16 |
sonne|work | I start to agree with blackburn, i.e., have a very simple rudimentary SGVector that is only used to pass around ptrs (not for long term usage) | 11:17 |
sonne|work | and some other class that has more overhead, like GC | 11:18 |
sonne|work | maybe derive one from the other | 11:18 |
sonne|work | and the SGIVector (I == interface) | 11:18 |
wiking | mmm | 11:18 |
wiking | so basically you are ending up with the shared_pointer concept | 11:18 |
sonne|work | is then only stuff to be used from the outside for long term | 11:19 |
sonne|work | no | 11:19 |
wiking | i mean if you are doing interfacing of SGVector | 11:19 |
wiking | and such | 11:19 |
wiking | you'll have the same thing going on | 11:19 |
sonne|work | what I mean is we have just double* and int for sgvector | 11:19 |
sonne|work | no more | 11:19 |
sonne|work | no overhead | 11:19 |
wiking | yep | 11:19 |
wiking | so no reference counter there i guess | 11:20 |
sonne|work | we use this whenever possible | 11:20 |
sonne|work | but for internal class storage of (bigger) sgvectors we use sth like SGIVector | 11:20 |
sonne|work | that can be shared and passed around | 11:20 |
sonne|work | with reference counts and stuff | 11:20 |
wiking | yeah | 11:21 |
wiking | well that is exactly what i meant about SGIVector will mimic the shared_ptr concept of boost | 11:21 |
sonne|work | yes true | 11:21 |
sonne|work | more or less :) | 11:21 |
wiking | hehe ok | 11:21 |
wiking | sounds reasonable | 11:21 |
wiking | for | 11:21 |
wiking | me | 11:21 |
wiking | :) | 11:21 |
wiking | damn too many enters | 11:22 |
wiking | (doing a ubuntu lts upgrade in the background) | 11:22 |
sonne|work | this needs to be discussed with pluskid, blackburn and n4nd0 ... | 11:22 |
sonne|work | no idea whether they all attempted to upgrade ubuntu yesterday | 11:22 |
sonne|work | and now are gone :P | 11:22 |
wiking | hahahahah yeah | 11:22 |
wiking | maybe they've all done that and now trying to fix it... i'm just doing it on a server so worst case it's going to crash :P | 11:23 |
wiking | if that works out | 11:23 |
wiking | then i should the same with all my cluster nodes ;P that'll be fun for sure :) | 11:23 |
wiking | btw do u know any industrial application of shogun? | 11:24 |
sonne|work | rumor has it that it is used | 11:25 |
wiking | oh cool | 11:25 |
wiking | i wonder what environment | 11:25 |
sonne|work | no idea | 11:25 |
wiking | i'd be interested testing shogun's performance on some embedded device | 11:26 |
wiking | whether it's feasable | 11:26 |
wiking | at least small parts of it | 11:26 |
sonne|work | heh, we ran it on gunnars iphone a while ago :D | 11:26 |
wiking | how was it? draining battery? :) | 11:26 |
sonne|work | just for fun | 11:26 |
wiking | i might be able to try on a raspberry pi when i finally receive it :) | 11:26 |
sonne|work | no applications... | 11:26 |
sonne|work | certainly all the linear methods are fast enough for embedded | 11:27 |
wiking | yes | 11:27 |
wiking | that's what i've thought | 11:27 |
wiking | maybe we should create a build file for andro and iOS :) | 11:27 |
wiking | just for the fun of it | 11:27 |
wiking | it could even be | 11:27 |
wiking | that it only contains only the 'classification' parts | 11:28 |
wiking | that it can load up the model | 11:28 |
wiking | and then just classify it | 11:28 |
wiking | in case of classifiers... since learning u can do in a cloud as well :) | 11:28 |
wiking | and then just download the learned model | 11:29 |
sonne|work | I would say just libshogun | 11:29 |
sonne|work | and the static cmdline interface | 11:29 |
wiking | damn the shipping date is still 15th of august for my raspberry pi | 11:30 |
wiking | anyhow once i have it i'll give it a go and do some benchmarking ;) | 11:34 |
wiking | should be fun | 11:34 |
sonne|work | toys are supposed to be fun :D | 11:36 |
wiking | heheh my wife just won an award :) | 11:36 |
sonne|work | good idea to spend it on toys ;-) | 11:38 |
sonne|work | which one? | 11:39 |
sonne|work | btw | 11:39 |
wiking | ah it's a local artist award from our hometown | 11:39 |
wiking | i think there's no money with it only 'fame' :) | 11:40 |
sonne|work | heh, that reminds me we still need a cool logo :) | 11:40 |
wiking | ahahhahaha | 11:40 |
sonne|work | wiking: btw are you still in touch with alex? | 11:44 |
sonne|work | wiking: ahh and do you remember what I wanted to discuss with vojtech? I totally forgot to talk to him | 11:44 |
sonne|work | ahh | 11:45 |
sonne|work | food | 11:45 |
wiking | sonne|work: yeah i'm in touch with him, I'm just finishing now a big chunk of the latent svm code, so when it's committed i'll have another big discussion with him about how to go further... and whether or not he is satisfied with the outcome | 11:47 |
wiking | sonne|work: mmm vojtech? YES i know! about adding stuff to libqp | 11:48 |
wiking | like pr_loqo | 11:48 |
wiking | sonne|work: so yeah get hold of him and talk about that (pr_loqo and i think it was tron? to libqp) | 11:50 |
-!- PhilTillet [~Philippe@vir78-1-82-232-38-145.fbx.proxad.net] has joined #shogun | 12:33 | |
wiking | PhilTillet: hey! r u still planning to do the patches for opencl in shogun? | 12:33 |
PhilTillet | hello wiking :p | 12:34 |
wiking | PhilTillet: or it should be picked up by somebody else | 12:34 |
PhilTillet | absolutely, i've spent the last 4 days reading litterature about svm | 12:34 |
wiking | ? | 12:34 |
wiking | you wanna opencl svm | 12:34 |
PhilTillet | yes | 12:34 |
wiking | i must say that you'll have problems with that | 12:34 |
wiking | a lot of people tried various ways to extend svm parallel | 12:34 |
PhilTillet | why? there has been a lot of paper succeeding! | 12:35 |
wiking | and there are some ways of course | 12:35 |
wiking | but neither is a silver bullet | 12:35 |
PhilTillet | i've already done a prototype on classification (not learning) , and the improvement was something like seven-fold or eight-fold :p | 12:36 |
wiking | yeah learning is a hard part | 12:36 |
PhilTillet | but I have some paper who parallelized smo with success | 12:36 |
wiking | yeah smo | 12:36 |
PhilTillet | improving performances by 20x :p | 12:36 |
wiking | you have one from google as well | 12:36 |
wiking | psvm | 12:36 |
wiking | it's using mpi | 12:36 |
PhilTillet | well mpi and opencl are completely different :p | 12:37 |
wiking | yeah i know | 12:37 |
PhilTillet | cuSVM would be more of an example ^^ | 12:37 |
PhilTillet | anyway, I need to go to eat :p | 12:37 |
PhilTillet | cya | 12:37 |
wiking | :( | 12:37 |
wiking | shit since i just wanted to say | 12:37 |
wiking | something | 12:37 |
wiking | but let me know when u r back | 12:37 |
PhilTillet | wiking, i'm back | 12:56 |
PhilTillet | :p | 12:56 |
wiking | ok | 12:56 |
wiking | just a sec i've fucked up something on my server | 12:56 |
wiking | :))) | 12:56 |
PhilTillet | good job! :D | 12:56 |
wiking | hahah fixed | 12:58 |
PhilTillet | :p | 12:58 |
wiking | i wonder if this works now | 12:58 |
wiking | brb | 12:58 |
wiking | oh no i cannot test it yet | 12:58 |
wiking | so anyhow have u taken a look at libqp? | 12:58 |
wiking | if that could be opencl-ized | 12:59 |
PhilTillet | hmmm not at all :p | 12:59 |
-!- karlnapf [~heiko@host86-182-161-144.range86-182.btcentralplus.com] has joined #shogun | 12:59 | |
wiking | that'd be great though | 13:00 |
PhilTillet | actually i'm not very familiar yet with constrained optimization (that's why i need to read a bit of litterature :D) | 13:00 |
* wiking is just testing mosh | 13:00 | |
PhilTillet | I just know that SMO has been successfully cuda-ized :p | 13:01 |
wiking | The implemented solver (libqp_splx.c) is a generalization of the method proposed in [1, 2]. It is based on the Sequential Minimal Optimization (SMO) algorithm with an improved working set selection strategy. | 13:01 |
PhilTillet | well then I guess yess :p | 13:01 |
PhilTillet | does Shogun relies on libqp for training? | 13:02 |
wiking | well more and more things will | 13:02 |
wiking | but like svmocas is one example | 13:03 |
PhilTillet | hmmm | 13:03 |
wiking | and most probably 2 gsoc project this year | 13:04 |
wiking | is going to use libqp | 13:04 |
PhilTillet | i see :p | 13:04 |
wiking | even 3 | 13:04 |
wiking | ;) | 13:04 |
PhilTillet | then I should more focus on a generic implementation of libqp that could be re-used for svm? | 13:05 |
wiking | well check this | 13:05 |
wiking | src/shogun/lib/external/libqp_splx.cpp | 13:05 |
wiking | 410 src/shogun/lib/external/libqp_splx.cpp | 13:05 |
wiking | 410 lines | 13:05 |
wiking | so it's not that big | 13:05 |
PhilTillet | well indeed it's not that big :p | 13:10 |
sonne|work | PhilTillet: that is not the bottleneck | 13:11 |
sonne|work | the bottleneck is the thing I gave you :) | 13:11 |
PhilTillet | what do you mean? :p | 13:12 |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 13:13 | |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 13:13 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 13:13 | |
wiking_ | woah this mosh works great :) | 13:13 |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 252 seconds] | 13:15 | |
-!- wiking_ is now known as wiking | 13:15 | |
PhilTillet | sonne|work : I have thought about a cleaner way to implement OpenCL without #ifdef everywhere :p making the functions not #ifdef'ed in the .h, and make another .cpp to implement them, and if USE_OPENCL is not defined, just return an error message like "No OpenCL support" | 13:18 |
sonne|work | PhilTillet: this \sum_i alpha_i K(x,x_i) is the operation that kills time | 13:19 |
sonne|work | all the rest is almost insignificant | 13:19 |
PhilTillet | training is insignifiant? :o | 13:19 |
sonne|work | this operation is what takes most of the time in training | 13:19 |
-!- karlnapf [~heiko@host86-182-161-144.range86-182.btcentralplus.com] has quit [Quit: Leaving.] | 13:19 | |
PhilTillet | oh, yes | 13:20 |
PhilTillet | well I'll keep on reading more and try to come up with an implementation :p | 13:20 |
PhilTillet | but a lot of guys have succeeded so i'm sure that it's possible :p | 13:22 |
-!- Priyans [~Priyans@115.248.130.148] has joined #shogun | 13:24 | |
PhilTillet | It will just take some time :D | 13:27 |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 13:32 | |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 13:32 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 13:32 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Read error: Connection reset by peer] | 13:32 | |
-!- wiking_ is now known as wiking | 13:32 | |
-!- PhilTillet [~Philippe@vir78-1-82-232-38-145.fbx.proxad.net] has quit [Remote host closed the connection] | 13:59 | |
--- Log closed Fri Apr 27 14:18:08 2012 | ||
--- Log opened Fri Apr 27 14:28:58 2012 | ||
-!- shogun-toolbox [~shogun@7nn.de] has joined #shogun | 14:28 | |
-!- Irssi: #shogun: Total of 9 nicks [1 ops, 0 halfops, 0 voices, 8 normal] | 14:28 | |
-!- Irssi: Join to #shogun was synced in 6 secs | 14:28 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Remote host closed the connection] | 14:29 | |
-!- wiking [~wiking@vpna052.ugent.be] has joined #shogun | 14:29 | |
-!- wiking [~wiking@vpna052.ugent.be] has quit [Changing host] | 14:29 | |
-!- wiking [~wiking@huwico/staff/wiking] has joined #shogun | 14:29 | |
-!- blackburn1 [~qdrgsm@188.168.2.179] has joined #shogun | 14:42 | |
-!- Priyans [~Priyans@115.248.130.148] has quit [Quit: Leaving] | 15:43 | |
-!- blackburn1 [~qdrgsm@188.168.2.179] has quit [Ping timeout: 260 seconds] | 15:57 | |
-!- henri [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has joined #shogun | 16:24 | |
henri | hi there | 16:24 |
henri | I have a problem of memory desallocation | 16:25 |
henri | I use opencv for computer vision apps, and I initialize shogun matrix from cv::Mat object like this : | 16:25 |
henri | cv::Mat cvmat(100,100,CV_32FC1,cv::Scalar(0.0)); | 16:25 |
henri | SGMatrix<float> sgmatrix((float*)cvmat.data, cvmat.rows, cvmat.cols); | 16:25 |
henri | problem is when for example I do SG_UNREF(svm), then I got *** glibc detected *** /home/(...): double free or corruption (out): 0x0000000000a2f1c0 *** | 16:26 |
sonne|work | henri: where do you put this matrix? | 16:29 |
sonne|work | into SimpleFeatures<float> ? | 16:29 |
henri | yes | 16:29 |
sonne|work | henri: argh yes that explains it | 16:29 |
henri | this could be written like that : CSimpleFeatures<float>* features =new CSimpleFeatures<float>((float*)samples.data,samples.rows,samples.cols); | 16:29 |
sonne|work | we currently assume to 'own' the memory | 16:29 |
henri | samples is cv::Mat struture | 16:29 |
sonne|work | so when the simple feature object is destroyed it will SG_FREE the matrix | 16:30 |
sonne|work | and I guess opencv does the same | 16:30 |
henri | indeed | 16:30 |
sonne|work | wiking, blackburn -> that is why we need the new sgvector stuff ... | 16:30 |
sonne|work | henri: we have some plans to avoid copying but that hasn't been done yet | 16:31 |
sonne|work | henri: so for now you will have to feed a copy of the opencv matrix into shogun | 16:32 |
sonne|work | gsomix: are you around? | 16:32 |
wiking | heheheh :) | 16:32 |
henri | I don't understand why I get this error from shogun because opencv free the matrix after shogun | 16:33 |
henri | I tried to add ref to the matrix but same error | 16:33 |
henri | sonne|work: Wekk ok, should I go this way ? :: SGMatrix<float> sgmatrix = new SGMatrix<float>((float*)cvmat.data, cvmat.rows, cvmat.cols); | 16:35 |
wiking | mm | 16:35 |
henri | + * | 16:35 |
wiking | henri: u should copy the cvmat.data | 16:35 |
henri | wiking: ok tx | 16:35 |
wiking | otherwise you'll end up freeing twice the float array | 16:35 |
wiking | henri: can we ask u what's your application? | 16:36 |
henri | sure, I try to recognize video events | 16:37 |
wiking | ah cool | 16:37 |
wiking | which svm are u using in shogun? | 16:37 |
henri | for now I used linear kernel on bow features | 16:39 |
henri | but its just a beginning | 16:39 |
wiking | and how is it working out for you? | 16:39 |
wiking | ah ok | 16:39 |
wiking | if u use BOW and linear kernel | 16:39 |
wiking | i might suggest to test HomogeneousKernelMap preprocessor on your features | 16:39 |
wiking | you'll have better classification results | 16:40 |
henri | what is it ? | 16:40 |
henri | My main goal is to keep time information which are lost in BOW features | 16:41 |
wiking | it's based on this paper: http://www.robots.ox.ac.uk/~vgg/publications/html/vedaldi10-abstract.html | 16:41 |
henri | I am gonna use strings kernels or kind of fisher kernel to do that | 16:41 |
wiking | it basically allows you to have similar accuracy when u use histogram intersection kernel or jensen-shannon kernel on your histogram features but using linear svm | 16:42 |
wiking | it's pretty cool | 16:42 |
henri | problem is that strings kernel in shogun handle only a short alphabet | 16:42 |
henri | I will provide advancement information if you want to | 16:43 |
wiking | yeah sure | 16:43 |
wiking | since i use shogun for image processing as well | 16:43 |
henri | Are you one of the shogun developpers , | 16:43 |
henri | ? | 16:43 |
wiking | well i'm doing now gsoc for shogun | 16:44 |
wiking | but for example this homogeneous kernel mapping trick has been ported by me to shogun | 16:44 |
henri | on what part ? | 16:44 |
wiking | as i needed linear svm but with the similar accuracy as if i'd use jensenshannon kernel | 16:44 |
wiking | i'm implementing the latent svm module for shogun | 16:45 |
wiking | henri: u use this as your research for uni? | 16:45 |
henri | yes | 16:46 |
henri | And I would help shogun with pleasure | 16:47 |
henri | If I can | 16:47 |
wiking | cool! anyhow if u have a data set where u wanna apply latent svm let me know since i'm just trying to build several scenarios where it could be applied. i.e. if u not only want to label an even in the video but you wanna give e.g. a bounding box for where that event happened that could be done via latent svm | 16:48 |
henri | I can try, what data base have you already processed ? Thans for the article I am reading it ! | 16:53 |
henri | =) | 16:53 |
wiking | well currently i'm testing with mammal identification in an image | 16:54 |
henri | wiking: allright, I have to go now, I will be back next week. | 17:00 |
wiking | alright! | 17:00 |
wiking | cya | 17:01 |
henri | wiking: the name is not henri but I will try to make you remember me, even with a different name ^^ cya | 17:01 |
wiking | hehehe ok :) | 17:01 |
-!- henri [2e1fd566@gateway/web/freenode/ip.46.31.213.102] has quit [Quit: Page closed] | 17:02 | |
gsomix | sonney2k, sonne|work hey | 17:25 |
gsomix | sonney2k, sonne|work just write me. I'm ready to go. :) | 17:33 |
sonne|work | gsomix: do you see blackburn today? | 17:33 |
sonne|work | I am thinking simplifying SGVector to only be double* and int | 17:34 |
sonne|work | not refcount or anything | 17:34 |
sonne|work | and then have a derived SGIVector (I == interface) | 17:34 |
sonne|work | which we use only for returning things to the outside which keeps proper refernce counts and everything | 17:34 |
sonne|work | so we have zero overhead when using SGVector | 17:35 |
sonne|work | and can afford quite some for SGIVector | 17:35 |
gsomix | sonne|work, I saw him at the uni, but he escaped. | 17:35 |
sonne|work | gsomix: while wiking likes this I would prefer to discuss this with blackburn, n4nd0, pluskid | 17:36 |
sonne|work | but that would be the plan | 17:36 |
wiking | mailing list? | 17:36 |
sonne|work | gsomix: maybe you can start to create some draft implementation | 17:36 |
wiking | it might be more efficient to discuss it there | 17:36 |
sonne|work | true | 17:36 |
sonne|work | gsomix: e.g. create an SGIVector which has refcounts in the same way like SGObject but with some boolean that it refcounts for this thing are not needed) | 17:37 |
wiking | oh fucking hell | 17:37 |
sonne|work | and simplify the sgvector class | 17:37 |
sonne|work | wiking: ?! | 17:37 |
wiking | may 8 ... kdd deadline! :( | 17:37 |
wiking | another day of paperworks for me it seems:D | 17:38 |
sonne|work | work wiking work! | 17:38 |
wiking | well it's just gonna be copy paste first | 17:38 |
wiking | and then add some extra graphs | 17:38 |
wiking | as i'm sure my last submission is going to be refused :D | 17:38 |
wiking | but i'll get the notification tomorrow ;) | 17:44 |
gsomix | sonne|work, we plan to use SGIVector as pointer, right? | 17:55 |
-!- blackburn1 [~qdrgsm@188.168.13.62] has joined #shogun | 17:58 | |
blackburn1 | sonne|work: sonney2k bounce | 18:01 |
blackburn1 | sonney2k: I'd like to mimic or use valarray in the lightweight SGVector | 18:03 |
sonne|work | gsomix: no | 18:04 |
sonne|work | gsomix: the same way as before | 18:04 |
sonne|work | blackburn1: new day new idea: | 18:05 |
blackburn1 | sonne|work: no old idea | 18:05 |
blackburn1 | wiking suggested it before | 18:05 |
wiking | yes | 18:05 |
wiking | i've already given u an implementation yesterday | 18:05 |
sonne|work | blackburn1: I am talking about the 'new' sgvector plan I have today | 18:05 |
wiking | ahhaha | 18:05 |
blackburn1 | ahh | 18:05 |
wiking | :> | 18:06 |
wiking | evolving day-by-day | 18:06 |
sonne|work | blackburn1: lets have a SGVector and SGIVector | 18:06 |
blackburn1 | lol | 18:06 |
sonne|work | (one for interface and one w/o) | 18:06 |
sonne|work | blackburn1: like you suggested | 18:06 |
blackburn1 | sonne|work: we can use it by same interface I think | 18:06 |
sonne|work | so we even remove the do_free flag from SGVector | 18:06 |
blackburn1 | or do you prefer explicit? | 18:06 |
sonne|work | and we only use this to exchange vectors/matrices that *never* have to be freed | 18:07 |
sonne|work | otherwise we use the SGIStuff | 18:07 |
blackburn1 | yes it is the idea I came with *proudly* | 18:07 |
blackburn1 | :D | 18:07 |
sonne|work | zero overhead | 18:07 |
sonne|work | blackburn1: this is not put in stone yet | 18:08 |
blackburn1 | sonne|work: yes and my suggestion is to mimic or use valarray | 18:08 |
-!- emrecelikten [~Anubis@92.44.165.109] has joined #shogun | 18:08 | |
sonne|work | so migration plan could be to rename all SGVector -> SGIVector | 18:08 |
sonne|work | then introduce SGVector with minimal functionality | 18:08 |
blackburn1 | afaik it avoids memory alignment and SSE/SSE2/someothershit optimized | 18:08 |
sonne|work | and derive SGIVector from that | 18:08 |
sonne|work | then add the SGObject stuff we had before | 18:09 |
sonne|work | refcounting | 18:09 |
blackburn1 | works for me | 18:09 |
sonne|work | and a I_don't_use_refcounting flag | 18:09 |
wiking | and the day has come to use crossval of shogun ;) | 18:10 |
sonne|work | then we gradually have to check each and every occurrence of SGIVector and use SGVector if it does just sth like compute matrix | 18:10 |
sonne|work | kernel matrix | 18:10 |
sonne|work | and getting elements to vector | 18:10 |
blackburn1 | wiking: lasst xmas I used to xval | 18:10 |
wiking | how did it feel? :) | 18:10 |
blackburn1 | but the very next day it gave segfault me away | 18:10 |
blackburn1 | (I am singing) | 18:10 |
wiking | hah :) | 18:10 |
blackburn1 | this sounds like a gay song though | 18:11 |
blackburn1 | I should double-check if it is allright | 18:11 |
wiking | i have a new data set and no train/test split so gotta try | 18:11 |
sonne|work | if we recognize there is no single use for SGVector any longer then we rename SGIVector back and end of discussion | 18:11 |
blackburn1 | wiking: yes and teach me how to use it | 18:11 |
wiking | heheheh :) | 18:11 |
blackburn1 | sonne|work: sounds like a good plan actually | 18:11 |
sonne|work | blackburn1: OK? | 18:11 |
blackburn1 | sonne|work: painful but makes sense probably | 18:12 |
blackburn1 | however why not to hide realization stuff? | 18:12 |
blackburn1 | SGVector can be an interface | 18:12 |
sonne|work | and? | 18:13 |
blackburn1 | sonne|work: do we really need to know whether it is do_free vector or not? | 18:13 |
blackburn1 | in code | 18:14 |
sonne|work | no | 18:14 |
sonne|work | but I am not sure what you want to tell me | 18:14 |
blackburn1 | sonne|work: http://yuml.me/diagram/scruffy;/class///%20Cool%20Class%20Diagram,%20%5BSGVector%5D-%5BSGInternalVector%5D,%20%5BSGVector%5D-%5BSGInterfaceVector%5D.png | 18:15 |
blackburn1 | but rather not http://yuml.me/diagram/scruffy;/class///%20Cool%20Class%20Diagram,%20%5BSGVector%5D-%5BSGInterfaceVector%5D.png | 18:16 |
sonne|work | blackburn1: why that? | 18:17 |
sonne|work | all the functions like add / subset etc are in SGVector | 18:17 |
sonne|work | so Internal would be the same as SGVector | 18:18 |
blackburn1 | sonne|work: hmm I think it would be more extensible | 18:19 |
blackburn1 | who knows may be we will come with LazyVector :D | 18:19 |
sonne|work | blackburn1: recall that we cannot have a single virtual function | 18:20 |
sonne|work | (in SGVector) | 18:20 |
blackburn1 | why? | 18:20 |
sonne|work | huge overhead | 18:20 |
sonne|work | vtable needs to be stored... | 18:20 |
blackburn1 | sonne|work: but how would you like to handle interface vector? | 18:21 |
sonne|work | IVec will have virtual functions and overhead crap | 18:21 |
blackburn1 | sonne|work: hmm but will be independent from vec? | 18:21 |
sonne|work | no | 18:23 |
blackburn1 | sonne|work: what will they share then? | 18:23 |
sonne|work | all functions | 18:23 |
blackburn1 | okay got you | 18:24 |
blackburn1 | sonne|work: I know you do some java - you should understand why I want some inheritance there ;) | 18:24 |
blackburn1 | recall how rich Collection is | 18:25 |
blackburn1 | IndirectList is a great example how good is to have general interface | 18:25 |
sonne|work | blackburn1: I know | 18:26 |
sonne|work | but this is all about saving every single bit possible :) | 18:26 |
blackburn1 | yeah | 18:26 |
sonne|work | otherwise we could just use java | 18:26 |
sonne|work | and no problems like we have now but only with GC :D | 18:26 |
blackburn1 | sonne|work: yeah it would be much easier to handle design and GC in java | 18:28 |
* sonne|work is happy to not have to use java at times | 18:29 | |
sonne|work | I am fighting with overoverover head here | 18:30 |
blackburn1 | sonne|work: really? I used to work on soft that would be infeasible in C++ so I don't really know the overhead | 18:30 |
sonne|work | a double[] is huge compared to what we have with sgvector | 18:31 |
blackburn1 | it should be not much slower | 18:32 |
sonne|work | objects have a huge overhead | 18:32 |
sonne|work | *HUGE* | 18:32 |
blackburn1 | 1.5x? | 18:32 |
sonne|work | not speed | 18:32 |
blackburn1 | overhead in memory means? | 18:32 |
sonne|work | yes | 18:32 |
sonne|work | it is all only about that | 18:32 |
sonne|work | speed wise java is mostly ok | 18:32 |
sonne|work | (nowadays) | 18:32 |
sonne|work | and if you don't have time critical stuff | 18:32 |
sonne|work | (GC ...) | 18:32 |
blackburn1 | sonne|work: I have no idea, how big is double[] for N elements? | 18:33 |
sonne|work | for N=1 is what is relevant here | 18:33 |
sonne|work | it has some name, refernce count, whatnot | 18:34 |
sonne|work | there is no sizeof() in java for a reason :P | 18:34 |
blackburn1 | sonne|work: there is a way still - I thought you measured ;) | 18:34 |
blackburn1 | 8 bytes for the type pointer.4 bytes for the array length.8 bytes for each element in the array (these are pointers to the actual objects). | 18:35 |
blackburn1 | via stackoverflow | 18:35 |
blackburn1 | sonne|work: not that bad | 18:35 |
sonne|work | no way | 18:35 |
sonne|work | there is more | 18:36 |
sonne|work | otherwise GC could not work | 18:36 |
sonne|work | gtg | 18:36 |
sonne|work | cu | 18:36 |
-!- sonne|work [~sonnenbu@194.78.35.195] has left #shogun [] | 18:36 | |
blackburn1 | oh the thing I forgot is to eat something | 18:39 |
blackburn1 | that shouldn't happen | 18:39 |
blackburn1 | wiking: I didn't know you are married | 18:39 |
blackburn1 | ;) | 18:39 |
wiking | ok | 19:03 |
wiking | i've ran a benchmarking between | 19:03 |
wiking | valarray and float vector dot product | 19:03 |
wiking | ok it's biased i'm redoing it | 19:04 |
-!- PhilTillet [~Philippe@2001:660:3203:402:9c89:60e6:842d:5044] has joined #shogun | 19:08 | |
blackburn1 | wiking: would be interesting to see results | 19:37 |
blackburn1 | sonney2k: we discussed a little | 19:45 |
blackburn1 | sonney2k: I think we need leading dimension stuff like in blas | 19:47 |
blackburn1 | with it we can support to slice rows and cols of matrices | 19:49 |
blackburn1 | i.e. vector containing elements one by one | 19:49 |
blackburn1 | and with skip of 10 | 19:49 |
-!- karlnapf [~heiko@host86-182-161-144.range86-182.btcentralplus.com] has joined #shogun | 19:56 | |
wiking | lol | 20:02 |
wiking | i've been invited for being a chair of a session on a conference | 20:02 |
blackburn1 | wiking: congrats ;) | 20:02 |
emrecelikten | Like this? http://26.media.tumblr.com/tumblr_ls3g7yjipZ1qegu8do1_500.png :P | 20:05 |
wiking | now let's get back to that benchmarking... i was cooking till now | 20:05 |
wiking | blackburn1: hehehe and yes i'm married... i'm old man :P | 20:05 |
wiking | emrecelikten: :DDD | 20:05 |
wiking | exactly | 20:05 |
emrecelikten | :D | 20:06 |
wiking | is there an easy way to flush cache? :) | 20:06 |
PhilTillet | wiking, god.my_computer.cache.flush() ; :p | 20:08 |
wiking | :)) | 20:08 |
PhilTillet | #include <god> | 20:08 |
PhilTillet | XD | 20:08 |
PhilTillet | that would be so convenient | 20:08 |
wiking | cacheflush | 20:08 |
wiking | on linux apparently | 20:08 |
blackburn1 | sonney2k: we stuckeed | 20:11 |
blackburn1 | why do we need SGIVector? | 20:11 |
blackburn1 | it always has been copied and there is no need to handle references | 20:11 |
-!- gsomix [~gsomix@188.168.5.102] has quit [Ping timeout: 252 seconds] | 21:30 | |
-!- PhilTillet [~Philippe@2001:660:3203:402:9c89:60e6:842d:5044] has quit [Ping timeout: 245 seconds] | 21:35 | |
-!- PhilTillet [~Philippe@157.159.47.30] has joined #shogun | 21:51 | |
-!- gsomix [~gsomix@83.234.54.138] has joined #shogun | 22:38 | |
wiking | mmm right where was is? :) | 22:51 |
wiking | *i | 22:51 |
wiking | :> | 22:51 |
-!- karlnapf [~heiko@host86-182-161-144.range86-182.btcentralplus.com] has quit [Ping timeout: 276 seconds] | 22:57 | |
-!- gsomix [~gsomix@83.234.54.138] has quit [Ping timeout: 265 seconds] | 23:00 | |
@sonney2k | blackburn1, to be able to share vectors / matrices | 23:03 |
blackburn1 | sonney2k: hmmm what is the case? | 23:03 |
@sonney2k | blackburn1, e.g. returning the label vector multiple times | 23:03 |
blackburn1 | oh | 23:04 |
@sonney2k | or the SGMatrix of simplefeatures | 23:04 |
blackburn1 | finally I understand | 23:04 |
@sonney2k | etc | 23:04 |
blackburn1 | sonney2k: but what to do in case like | 23:04 |
blackburn1 | kernel method | 23:04 |
blackburn1 | where we get vector | 23:04 |
@sonney2k | currently we can return it once but have to assume that the object still exists when using it | 23:05 |
@sonney2k | blackburn1, in kernel method we usually get a column vector from some sgmatrix | 23:05 |
@sonney2k | so it is just a ptr into sgmatrix and no interface | 23:05 |
@sonney2k | everything stored as member variable should probably be sgivector | 23:06 |
blackburn1 | sonney2k: btw do you like idea of that loop increment? | 23:06 |
@sonney2k | such that it can be returned | 23:06 |
@sonney2k | loop increment? | 23:06 |
blackburn1 | sonney2k: recall blas ddot | 23:06 |
@sonney2k | you mean slicing? | 23:07 |
blackburn1 | ddot(N,x,1,y,1) typically right? | 23:07 |
blackburn1 | but if we need column row | 23:07 |
blackburn1 | we currently copy | 23:07 |
@sonney2k | so slicing | 23:07 |
blackburn1 | when we can use these 'skips' | 23:07 |
blackburn1 | slicing sounds inconvenient but you get me | 23:07 |
blackburn1 | it costs one more integer though | 23:08 |
@sonney2k | the a[:,i] thing in python numpy | 23:08 |
@sonney2k | not good for core sgvector then | 23:08 |
blackburn1 | if memory is like 1 2 3 4 5 6 7 8 9 | 23:08 |
blackburn1 | column is array+i | 23:09 |
blackburn1 | and row is array+3i | 23:09 |
@sonney2k | I got you but still | 23:09 |
@sonney2k | no overhead in sgvector | 23:09 |
@sonney2k | I am certainly ok having some fat sgivector supporting that | 23:09 |
@sonney2k | btw, there are still some problems | 23:09 |
blackburn1 | sonney2k: that would enable us to use column rows efficiently | 23:10 |
@sonney2k | simplefeatures don't have to be in memory | 23:10 |
@sonney2k | and they have preprocessors | 23:10 |
@sonney2k | so get_feature_vector() | 23:11 |
@sonney2k | could potentially return a processed copy that needs to be freed | 23:11 |
blackburn1 | yes who handles it? | 23:11 |
@sonney2k | we used to have a free_feature_vector() function | 23:11 |
@sonney2k | that is to be called | 23:11 |
blackburn1 | yes | 23:12 |
blackburn1 | what is our plan then? | 23:12 |
@sonney2k | it would have been better to have that done via some SG_UNREF(vector) | 23:12 |
@sonney2k | but then we would need SGIVector here | 23:12 |
@sonney2k | so we would have quite a bit of overhead if the matrix is in memory and there are no preprocessors | 23:13 |
blackburn1 | sonney2k: we would need SGIVector everywhere | 23:13 |
@sonney2k | why that? | 23:13 |
blackburn1 | what is the case w/o SGI? | 23:13 |
@sonney2k | I can imagine that we have two functions returning once the sgvector | 23:13 |
@sonney2k | and once sgivector | 23:13 |
@sonney2k | depending on what you intend to do | 23:13 |
* sonney2k runs out of battery | 23:13 | |
blackburn1 | sonney2k: okay lets continue tomorrow or so | 23:14 |
@sonney2k | 3 minutes left | 23:14 |
blackburn1 | do you have some indication of that? | 23:14 |
@sonney2k | blackburn1, you mean we don't need some efficient sgvector? | 23:14 |
@sonney2k | only sgivector stuff? | 23:15 |
-!- gsomix [~gsomix@188.168.13.227] has joined #shogun | 23:15 | |
blackburn1 | sonney2k: I don't know the case we can use it | 23:15 |
blackburn1 | at some point we need some interfacing and badaboom | 23:15 |
@sonney2k | blackburn1, well for example one could use it for simple features | 23:15 |
@sonney2k | and jsut to access labels | 23:15 |
@sonney2k | etc | 23:15 |
blackburn1 | yes but only a few cases and it looks like we can have overhead there | 23:16 |
blackburn1 | I am only afraid of get_feature_vector and similar methods overhead | 23:16 |
@sonney2k | I don't know - if you want to compute kernel matrix it can become costly | 23:16 |
@sonney2k | if you just have 2d vectors | 23:16 |
@sonney2k | but have to increment refcount, and set some other variables | 23:17 |
blackburn1 | sonney2k: yes but how can we use it here? | 23:17 |
@sonney2k | just return SGVector | 23:17 |
blackburn1 | but who will handle memory things? | 23:17 |
blackburn1 | it looks like currently it is in a working state | 23:17 |
blackburn1 | free_feature_vector | 23:17 |
@sonney2k | and require a call to simplefeatures->free_feature_vector | 23:17 |
@sonney2k | (which is usually a nop) | 23:18 |
blackburn1 | hmm yes I agree here | 23:18 |
blackburn1 | but the separation could be hard | 23:18 |
@sonney2k | of course it would be nicer if the free* stuff would be done by the vector itself | 23:18 |
blackburn1 | I mean we need get_feature_vector for interface | 23:18 |
@sonney2k | blackburn1, well one always has to copy sgvectors in interface | 23:19 |
@sonney2k | since one cannot rely on it | 23:19 |
@sonney2k | have to leave train | 23:19 |
@sonney2k | cu | 23:19 |
blackburn1 | ah train | 23:19 |
blackburn1 | okay see you | 23:19 |
blackburn1 | I am probably heading to bed | 23:20 |
-!- PhilTillet [~Philippe@157.159.47.30] has quit [Ping timeout: 265 seconds] | 23:25 | |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has joined #shogun | 23:28 | |
-!- wiking_ [~wiking@78-23-189-112.access.telenet.be] has quit [Changing host] | 23:28 | |
-!- wiking_ [~wiking@huwico/staff/wiking] has joined #shogun | 23:28 | |
-!- wiking [~wiking@huwico/staff/wiking] has quit [Ping timeout: 260 seconds] | 23:32 | |
-!- wiking_ is now known as wiking | 23:32 | |
-!- blackburn1 [~qdrgsm@188.168.13.62] has quit [Quit: Leaving.] | 23:33 | |
@sonney2k | Re | 23:37 |
@sonney2k | hmmhh | 23:38 |
gsomix | good night guys | 23:50 |
-!- PhilTillet [~Philippe@npasserelle10.minet.net] has joined #shogun | 23:53 | |
--- Log closed Sat Apr 28 00:00:17 2012 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!