| --- Log opened Sun Jul 21 00:00:40 2013 | ||
| -!- travis-ci [~travis-ci@ec2-23-20-93-32.compute-1.amazonaws.com] has joined #shogun | 00:13 | |
| travis-ci | [travis-ci] it's Sergey Lisitsyn's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9309885 | 00:13 |
|---|---|---|
| -!- travis-ci [~travis-ci@ec2-23-20-93-32.compute-1.amazonaws.com] has left #shogun [] | 00:13 | |
| -!- thoralf [~thoralf@37-5-32-132-dynip.superkabel.de] has joined #shogun | 00:29 | |
| thoralf | Hey. | 00:30 |
| lisitsyn | thoralf: hey | 00:33 |
| thoralf | lisitsyn: Hey last man standing. ;) | 00:34 |
| lisitsyn | thoralf: haha | 00:35 |
| lisitsyn | thoralf: I start to think I won't be forgiven for my disappearance | 00:36 |
| thoralf | lisitsyn: In which timezone are you right now? iow: What's your time now? | 00:38 |
| lisitsyn | thoralf: +4 utc | 00:38 |
| lisitsyn | so 02:38 | 00:38 |
| thoralf | lisitsyn: Oh. | 00:38 |
| thoralf | lisitsyn: You will be forgiven. ;) | 00:38 |
| thoralf | 0:38 here | 00:39 |
| lisitsyn | thoralf: yeah I know berlin timezone now ;) | 00:40 |
| lisitsyn | thoralf: what is the weather in berlin? | 00:43 |
| lisitsyn | ;) | 00:43 |
| thoralf | lisitsyn: Have to check my weather app. One second. ;) | 00:44 |
| lisitsyn | haha | 00:44 |
| lisitsyn | thoralf: where are you then? | 00:44 |
| thoralf | In Berlin. ;) | 00:44 |
| thoralf | 19 degree at night, that's good. | 00:45 |
| thoralf | 28 degree yesterday, no rain. | 00:45 |
| lisitsyn | thoralf: oh you have that calm day tomorrow | 00:45 |
| lisitsyn | I was a bit surprised | 00:45 |
| thoralf | What do you mean with "calm day"? Sunday? | 00:46 |
| thoralf | What exactly did surprise you? | 00:46 |
| lisitsyn | thoralf: no shops etc | 00:47 |
| lisitsyn | thoralf: we had to go to hauptbahnhof :D | 00:47 |
| thoralf | I see. | 00:47 |
| thoralf | Yes. | 00:47 |
| lisitsyn | that's my bad I didn't check such features | 00:47 |
| lisitsyn | thoralf: I already asked heiko - have you been to einstein stammhaus? | 00:48 |
| lisitsyn | on kurfuerstenstr. just near to einemstr. | 00:49 |
| thoralf | I know einstein caf?s, but what's special about this one? | 00:50 |
| thoralf | Stammhaus could mean something like "main house". | 00:50 |
| thoralf | It's probably bigger than others? | 00:50 |
| lisitsyn | thoralf: no idea if it is really special but we liked it a lot | 00:50 |
| lisitsyn | where are others? | 00:50 |
| lisitsyn | I have seen one near to checkpoint | 00:50 |
| lisitsyn | iirc | 00:51 |
| lisitsyn | thoralf: it is pretty big indeed and has some garden | 00:51 |
| lisitsyn | thoralf: the worst place we've been is 'FBI' near potsdamer platz :D | 00:54 |
| lisitsyn | oh sh it is awful | 00:54 |
| thoralf | Oh, I was wrong. | 00:54 |
| lisitsyn | thoralf: about what? | 00:54 |
| thoralf | http://www.einstein-kaffee.de/ is different from Einstein Stammhaus. | 00:54 |
| thoralf | Different companies. | 00:54 |
| lisitsyn | thoralf: oh I see | 00:55 |
| lisitsyn | everything is einstein in germany | 00:55 |
| lisitsyn | thoralf: what do they say when asking to leave a train? | 00:55 |
| lisitsyn | well I don't really recognize all the words but something similar to einstein agai | 00:55 |
| thoralf | Yeah. | 00:56 |
| thoralf | You can't protect Einstein. | 00:56 |
| thoralf | So everyone uses it. Sounds good. :) | 00:57 |
| lisitsyn | thoralf: but what do they say? | 00:57 |
| lisitsyn | in trains | 00:57 |
| thoralf | Einsteigen bitte. | 00:58 |
| lisitsyn | einsteigen haha! | 00:58 |
| lisitsyn | einstein everywhere | 00:58 |
| thoralf | Didn't realize it sounds so similar. | 00:59 |
| thoralf | But you're right. | 00:59 |
| thoralf | Einstein bitte. | 00:59 |
| thoralf | Danke. | 00:59 |
| lisitsyn | haha | 00:59 |
| lisitsyn | thoralf: well I was in train and they said that | 00:59 |
| lisitsyn | I tried to understand but what I heard was | 00:59 |
| lisitsyn | einstein bitte | 01:00 |
| lisitsyn | exactly how you said | 01:00 |
| lisitsyn | well not that but einstei*** | 01:00 |
| thoralf | :) | 01:00 |
| lisitsyn | thoralf: we also met ticket control twice | 01:01 |
| lisitsyn | :D | 01:01 |
| lisitsyn | good we bought fahrausweis | 01:01 |
| thoralf | Something different: How do you cast strings to integers in c++? I know atoi, but that's for (char*). Do you know something similar? | 01:01 |
| lisitsyn | thoralf: just cast it to char*? | 01:02 |
| lisitsyn | boost has lexical_cast | 01:02 |
| thoralf | Yeah, that's no problem. | 01:02 |
| lisitsyn | but atoi(str.c_str()) is ok too | 01:02 |
| lisitsyn | thoralf: you may read it to stream | 01:02 |
| thoralf | I can do string.c_str() and get (char*). | 01:02 |
| lisitsyn | like form a stringstream from your string | 01:03 |
| lisitsyn | and then | 01:03 |
| lisitsyn | int << str; | 01:03 |
| thoralf | lisitsyn: atoi does not handle any error. | 01:03 |
| lisitsyn | yeah that's the worst part of C++ I believe | 01:03 |
| lisitsyn | not atoi but IO in general | 01:04 |
| thoralf | Yeah. | 01:04 |
| thoralf | Awful. | 01:04 |
| lisitsyn | thoralf: you may try streams thing I think there is a way to customize that stuff | 01:04 |
| thoralf | I just re-discovered strtol(). | 01:05 |
| thoralf | For you information. | 01:05 |
| lisitsyn | thoralf: haha I didn't know about it | 01:05 |
| thoralf | "a way to customize that stuff" <-- Sounds to complicated for 1:00 am. ;) | 01:05 |
| lisitsyn | thoralf: well there is always a way to customize in C++ - that's a nice thing | 01:06 |
| lisitsyn | thoralf: for example I was tired with %d etc so I wrote that: https://github.com/lisitsyn/formatting | 01:06 |
| thoralf | lol. | 01:07 |
| thoralf | python2cpp | 01:07 |
| lisitsyn | haha that's pretty neat atoi goes crazy | 01:08 |
| lisitsyn | in case of any emergency | 01:08 |
| lisitsyn | undefined behaviour in case of any trouble haha really cool | 01:08 |
| lisitsyn | I vote for more undefined behaviour | 01:08 |
| lisitsyn | the next great step would be random undefined behaviour | 01:09 |
| lisitsyn | ok thoralf may the force be with you I am powering myself off ;) | 01:12 |
| thoralf | undefined behaviour does not hurt most of the time | 01:13 |
| thoralf | but worst cast behaviour would ;) | 01:13 |
| thoralf | Pleasant night :) | 01:14 |
| -!- thoralf [~thoralf@37-5-32-132-dynip.superkabel.de] has quit [Quit: Konversation terminated!] | 01:27 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 02:29 | |
| -!- nube [~rho@49.244.111.142] has joined #shogun | 02:49 | |
| shogun-buildbot | build #399 of nightly_all is complete: Failure [failed compile] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_all/builds/399 | 03:08 |
| -!- foulwall [~user@2001:da8:215:503:dc0e:86e6:8a74:2a68] has joined #shogun | 04:18 | |
| shogun-buildbot | build #464 of nightly_default is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/nightly_default/builds/464 | 04:20 |
| gsomix | woo-hoo, csv reader finally works | 06:57 |
| gsomix | but unittests are needed | 06:57 |
| gsomix | so, good morning | 07:16 |
| -!- foulwall [~user@2001:da8:215:503:dc0e:86e6:8a74:2a68] has quit [Remote host closed the connection] | 07:47 | |
| -!- gsomix [~gsomix@80.234.28.235] has quit [Ping timeout: 246 seconds] | 08:47 | |
| -!- nube [~rho@49.244.111.142] has quit [Quit: Leaving.] | 08:59 | |
| -!- gsomix [~gsomix@95.67.172.110] has joined #shogun | 08:59 | |
| -!- iglesiasg [~Fernando@c83-251-227-64.bredband.comhem.se] has joined #shogun | 11:32 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 11:32 | |
| @iglesiasg | good morning! | 11:32 |
| @sonney2k | gsomix, good morning! | 12:31 |
| @sonney2k | gsomix, if you know that it works than unit test are simple :) | 12:43 |
| @sonney2k | iglesiasg, did you read thoralfs PR? | 12:57 |
| @iglesiasg | sonney2k: the one for the makefile? yes | 12:57 |
| @sonney2k | iglesiasg, what do you think should we use the lib in shogun/src when we run make check-examples etc? | 12:57 |
| @sonney2k | or the one that is installed? | 12:57 |
| @iglesiasg | sonney2k: mmm | 12:58 |
| @sonney2k | besides hmmhh :P | 12:58 |
| @iglesiasg | sonney2k: the one in shogun/src makes sense to me too | 12:58 |
| @iglesiasg | was thinking :) | 12:58 |
| @sonney2k | ok then please vote for it in the PR | 12:59 |
| @sonney2k | we should have a way then to check if an install is good too though | 12:59 |
| @sonney2k | no idea how but we should have this | 12:59 |
| @iglesiasg | sonney2k: can we give an option to make check-examples? | 13:00 |
| @iglesiasg | default is the one in shogun/src, if another one is given then use that other one | 13:00 |
| @sonney2k | iglesiasg, I would assume that one wants to run make check-examples from the src dir | 13:04 |
| @sonney2k | to check the local code | 13:04 |
| @sonney2k | and maybe run sth from the installed directory | 13:04 |
| @iglesiasg | it makes sense | 13:06 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 13:42 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 942ce10 / src/ (10 files): https://github.com/shogun-toolbox/shogun/commit/942ce10efb90300ad42baba53e3fa174fb0f48a7 | 13:42 |
| shogun-notifier- | shogun: add cxx11 support | 13:42 |
| shogun-notifier- | shogun: | 13:42 |
| shogun-notifier- | shogun: - fix compile errors when compiling with -std=c++11 | 13:42 |
| shogun-notifier- | shogun: - use atomic int for referenced data (no memory overhead + faster) | 13:42 |
| shogun-notifier- | shogun: - use templated new's for SGMatrix(-List) | 13:42 |
| -!- travis-ci [~travis-ci@ec2-107-21-158-112.compute-1.amazonaws.com] has joined #shogun | 13:48 | |
| travis-ci | [travis-ci] it's Soeren Sonnenburg's turn to pay the next round of drinks for the massacre he caused in shogun-toolbox/shogun: http://travis-ci.org/shogun-toolbox/shogun/builds/9320717 | 13:48 |
| -!- travis-ci [~travis-ci@ec2-107-21-158-112.compute-1.amazonaws.com] has left #shogun [] | 13:48 | |
| -!- gsomix [~gsomix@95.67.172.110] has quit [Remote host closed the connection] | 13:54 | |
| shogun-buildbot | build #1489 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1489 blamelist: Soeren Sonnenburg <sonne@debian.org> | 13:58 |
| -!- iglesiasg [~Fernando@c83-251-227-64.bredband.comhem.se] has quit [Quit: Leaving] | 14:16 | |
| -!- shogun-notifier- [~irker@7nn.de] has quit [Quit: transmission timeout] | 16:42 | |
| -!- nube [~rho@49.244.123.105] has joined #shogun | 17:30 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has joined #shogun | 17:57 | |
| -!- pickle27 [~Kevin@d67-193-243-174.home3.cgocable.net] has quit [Quit: Leaving] | 18:26 | |
| -!- gsomix [~gsomix@95.67.172.110] has joined #shogun | 19:02 | |
| gsomix | good evening | 19:02 |
| gsomix | another hard day is done | 19:02 |
| gsomix | well that weekend is ended | 19:03 |
| gsomix | coding session! | 19:03 |
| -!- nube [~rho@49.244.123.105] has quit [Remote host closed the connection] | 19:48 | |
| -!- nube [~rho@49.244.123.105] has joined #shogun | 20:21 | |
| @sonney2k | lisitsyn, c++11 needed quite a bit of changes w/i shogun | 21:17 |
| lisitsyn | sonney2k: what kind of? | 21:18 |
| lisitsyn | sonney2k: I have compilation issue with new now | 21:21 |
| lisitsyn | I guess that's related | 21:21 |
| @sonney2k | lisitsyn, new what? | 21:23 |
| lisitsyn | sonney2k: operator new | 21:24 |
| @sonney2k | interesting | 21:24 |
| lisitsyn | lib/memory.cpp:83:31: error: declaration of 'void* operator new(size_t)' has a different exception specifier | 21:24 |
| lisitsyn | In file included from ../shogun/lib/common.h:67:0, | 21:24 |
| lisitsyn | from lib/memory.cpp:12: | 21:24 |
| lisitsyn | ../shogun/lib/memory.h:26:7: error: from previous declaration 'void* operator new(std::size_t) throw (std::bad_alloc)' | 21:24 |
| @sonney2k | lisitsyn, haha the opposite of what I was getting | 21:25 |
| @sonney2k | which g++ version? | 21:25 |
| lisitsyn | 4.7 | 21:25 |
| @sonney2k | here too | 21:25 |
| @sonney2k | and with c++11 enabled? | 21:25 |
| lisitsyn | 4.7.3 to be precise | 21:25 |
| @sonney2k | 4.7.2-5 here :D | 21:25 |
| lisitsyn | sonney2k: I just reconfigured | 21:25 |
| @sonney2k | c++11 on? | 21:26 |
| lisitsyn | sonney2k: let me check | 21:26 |
| lisitsyn | sonney2k: I think it was off and now on | 21:26 |
| lisitsyn | yes now it is enabled for sure | 21:26 |
| lisitsyn | and no error | 21:26 |
| @sonney2k | shogun-buildbot, force build 'rpm1 - libshogun' | 21:28 |
| shogun-buildbot | build forced [ETA 7m43s] | 21:28 |
| shogun-buildbot | I'll give a shout when the build finishes | 21:28 |
| @sonney2k | lets try a bot with old gcc | 21:28 |
| @sonney2k | lisitsyn, it sucks big time that all builds are red due to the change of wiking/Heiko | 21:28 |
| gsomix | sonney2k, hey. I'm close to finish with csv. Now implementing some buffered writing stuff. Next I'll add it to CSVFile. | 21:28 |
| @sonney2k | now we don't know if stuff fails due to their or other changes :/ | 21:30 |
| @sonney2k | gsomix, stop | 21:30 |
| @sonney2k | gsomix, please send PR's as often as possible | 21:30 |
| @sonney2k | small pieces | 21:30 |
| @sonney2k | gsomix, if you can send a daily PR | 21:30 |
| @sonney2k | with a small but tested change | 21:30 |
| gsomix | sonney2k, ok | 21:30 |
| @sonney2k | lisitsyn, I am currently thinking that we don't need all these K_LOG, K_BESSEL whatever enums in shogun specifying kernel/feature class /type | 21:31 |
| lisitsyn | sonney2k: yes of course they are not needed | 21:32 |
| gsomix | sonney2k, btw, what do you think about interface for CFile like this? http://pastebin.com/DtwAdZRd | 21:32 |
| @sonney2k | lisitsyn, how to do it differently? | 21:32 |
| gsomix | there is no many usage of CFile in shogun it seems. so, no many changes. | 21:32 |
| lisitsyn | sonney2k: let me check where they are used | 21:32 |
| @sonney2k | gsomix, yes very much appreciated | 21:32 |
| lisitsyn | sonney2k: so it is like instanceof here, right? | 21:33 |
| @sonney2k | lisitsyn, also I would rather want to have a virtual print function of the kernel | 21:33 |
| @sonney2k | lisitsyn, yeah | 21:33 |
| @sonney2k | lisitsyn, but with cases ... | 21:33 |
| @sonney2k | lisitsyn, currently we have a print_kernel function or sth | 21:34 |
| shogun-buildbot | build #744 of rpm1 - libshogun is complete: Success [build successful] Build details are at http://www.shogun-toolbox.org/buildbot/builders/rpm1%20-%20libshogun/builds/744 | 21:34 |
| @sonney2k | that does an enum switch over all kernels | 21:34 |
| @sonney2k | totally crappy | 21:34 |
| @sonney2k | lisitsyn, hmmhh the buildbot built for some old master revision | 21:35 |
| @sonney2k | *sigh* | 21:35 |
| lisitsyn | sonney2k: well we use RTTI so we can use things like typeid and dynamic cast | 21:36 |
| @sonney2k | typeid is not helpful though or is it? | 21:37 |
| gsomix | sonney2k, wwhere can I store data for unit-tests? | 21:37 |
| -!- naywhayare [~ryan@spoon.lugatgt.org] has quit [Ping timeout: 264 seconds] | 21:41 | |
| -!- naywhayare [~ryan@128.61.149.136] has joined #shogun | 21:55 | |
| @sonney2k | I mean it returns some random compiler dependent name | 21:55 |
| -!- shogun-toolbox [~shogun@7nn.de] has quit [Ping timeout: 263 seconds] | 21:55 | |
| --- Log closed Sun Jul 21 21:55:24 2013 | ||
| --- Log opened Sun Jul 21 21:59:27 2013 | ||
| -!- shogun-toolbox [~shogun@94.23.237.10] has joined #shogun | 21:59 | |
| -!- Irssi: #shogun: Total of 8 nicks [2 ops, 0 halfops, 0 voices, 6 normal] | 21:59 | |
| -!- Irssi: Join to #shogun was synced in 63 secs | 21:59 | |
| @sonney2k | gsomix, or alternatively just create a string yourself that you write/read to some tmpname | 22:00 |
| -!- naywhayare [~ryan@spoon.lugatgt.org] has joined #shogun | 22:00 | |
| -!- iglesiasg [~Fernando@83.179.44.135] has joined #shogun | 22:08 | |
| -!- mode/#shogun [+o iglesiasg] by ChanServ | 22:08 | |
| @iglesiasg | good evening guys | 22:10 |
| @sonney2k | iglesiasg, evening! | 22:45 |
| @sonney2k | lisitsyn, so who is gonna get rid of the EkernelType FeatureClass/FeatureType? | 22:47 |
| lisitsyn | sonney2k: we should decide how first | 22:48 |
| @sonney2k | lisitsyn, btw do we have more than that? | 22:48 |
| lisitsyn | sonney2k: yeah I think there are some more | 22:48 |
| @sonney2k | lisitsyn, well how I would say a) add rtti check to configure and then use dynamic_cast | 22:48 |
| -!- thoralf [~thoralf@37-5-32-132-dynip.superkabel.de] has joined #shogun | 22:49 | |
| @sonney2k | thoralf, so do it in $DEITY's name | 22:50 |
| thoralf | Hey :) | 22:52 |
| @sonney2k | thoralf, what is your g++ version? | 22:54 |
| thoralf | sonney2k: g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 | 22:55 |
| thoralf | Why? | 22:55 |
| @sonney2k | thoralf, I added a test for c++11 support and now I don't know if stuff works on old compilers (that dont' have it) | 22:56 |
| thoralf | Which c++11 features do you want to use? | 23:01 |
| @sonney2k | thoralf, we are using atomic<int> now | 23:02 |
| @sonney2k | for SGReferencedData | 23:02 |
| thoralf | Would gcc 4.5.2 help? | 23:02 |
| @sonney2k | thoralf, yes | 23:02 |
| thoralf | sonney2k: What shall I do? | 23:03 |
| @sonney2k | just try to compile | 23:03 |
| @sonney2k | if it works all good | 23:04 |
| -!- FSCV [~FSCV@216-230-229-167-colo.oplink.net] has joined #shogun | 23:09 | |
| @iglesiasg | sonney2k, lisitsyn : how should the DOXYGEN_SHOULD_SKIP_THIS be used? | 23:11 |
| lisitsyn | iglesiasg: #ifndef DOXYGEN_SHOULD_SKIP_THIS ... your stuff ... #endf | 23:12 |
| lisitsyn | *#endif | 23:12 |
| @iglesiasg | lisitsyn: why ifndef? | 23:12 |
| lisitsyn | doxygen scans source files | 23:12 |
| @iglesiasg | I saw that in some files, but it confuses me | 23:12 |
| lisitsyn | and it defines DOXYGEN_SHOULD_SKIP_THIS | 23:12 |
| lisitsyn | so when it is defined the thing inside #ifndef is skipped | 23:12 |
| thoralf | sonney2k: I'm getting a compile error in memory.h | 23:12 |
| @iglesiasg | lisitsyn: understood, thanks! | 23:13 |
| lisitsyn | thoralf: reconfigure | 23:13 |
| @iglesiasg | lisitsyn: does it make sense to put it in cpp files? I thought doxygen only scans heades | 23:13 |
| thoralf | lisitsyn: It's a fresh clone on a machine that never saw shogun before. ;) | 23:13 |
| @iglesiasg | headers* | 23:13 |
| lisitsyn | thoralf: ohh that's interesting then | 23:13 |
| lisitsyn | iglesiasg: no should not | 23:13 |
| @iglesiasg | lisitsyn: there are some cpp files with it, that's why I wonder | 23:14 |
| lisitsyn | iglesiasg: but may be I am wrong | 23:16 |
| @iglesiasg | who knows | 23:17 |
| @sonney2k | thoralf, ok so show us the error | 23:17 |
| @sonney2k | iglesiasg, no only .h files are scanned by doxygen | 23:17 |
| @iglesiasg | sonney2k: then these #ifndef DOXYGEN_SHOULD_SKIP_THIS ... #endif in cpp files make no sense | 23:18 |
| @sonney2k | iglesiasg, yes where are those? | 23:18 |
| @iglesiasg | sonney2k: quite a few places CombinedKernel, tapkee/defines/methods.cpp, shogun_libsvm.cpp, etc | 23:20 |
| @iglesiasg | grep and see | 23:20 |
| @sonney2k | lisitsyn, btw I just did some speed comparison of std::vector resize vs. realloc increasing a memory block by 100 ints each time | 23:20 |
| lisitsyn | sonney2k: and what you got? | 23:21 |
| @sonney2k | lisitsyn, std::vector does a lot *less* reallocations it seems but is much slower | 23:21 |
| thoralf | lib/memory.cpp: In function 'void* operator new(size_t)': | 23:21 |
| @sonney2k | as in 20 times slower | 23:21 |
| thoralf | lib/memory.cpp:83:31: error: declaration of 'void* operator new(size_t)' throws different exceptions | 23:21 |
| lisitsyn | sonney2k: std::vector does copy | 23:21 |
| thoralf | ../shogun/lib/memory.h:26:7: error: from previous declaration 'void* operator new(size_t) throw (std::bad_alloc)' | 23:21 |
| thoralf | lib/memory.cpp:114:33: error: declaration of 'void* operator new [](size_t)' throws different exceptions | 23:21 |
| thoralf | ../shogun/lib/memory.h:30:7: error: from previous declaration 'void* operator new [](size_t) throw (std::bad_alloc)' | 23:21 |
| @sonney2k | thoralf, ok let me attempt a fix | 23:21 |
| lisitsyn | sonney2k: it doesn't use realloc | 23:21 |
| @sonney2k | lisitsyn, yeah but how can it be slower | 23:21 |
| lisitsyn | well you used std::vector wrong way | 23:21 |
| lisitsyn | :D | 23:22 |
| @sonney2k | it needed 22 reallocs | 23:22 |
| @sonney2k | and realloc 127 | 23:22 |
| @sonney2k | lisitsyn, v.resize(size) | 23:22 |
| @sonney2k | ? | 23:22 |
| @sonney2k | how else would you do it? | 23:22 |
| lisitsyn | sonney2k: yes that's true I mean it is not well suited for multiple resizes | 23:22 |
| @sonney2k | lisitsyn, well just 22 | 23:22 |
| @iglesiasg | sonney2k: I think there is one method to change the capacity but not the size | 23:22 |
| lisitsyn | yes reserve | 23:23 |
| @sonney2k | realloc came up with 127 different memory allocs | 23:23 |
| @iglesiasg | that one, you should go with that one | 23:23 |
| lisitsyn | sonney2k: when you do resize you fill with 0 | 23:23 |
| @sonney2k | lisitsyn, that doesn't explain it | 23:23 |
| lisitsyn | sonney2k: realloc does no filling | 23:23 |
| @sonney2k | iglesiasg, lisitsyn how do I specify reserve | 23:24 |
| @sonney2k | lisitsyn, yes but filling is too cheap | 23:24 |
| @iglesiasg | sonney2k: vector.reserve(int) | 23:24 |
| lisitsyn | sonney2k: it is not that cheap I think | 23:24 |
| @sonney2k | iglesiasg, and then it will be a reserve per slot? | 23:24 |
| lisitsyn | it is not just memcpy | 23:24 |
| lisitsyn | err | 23:24 |
| lisitsyn | memset | 23:25 |
| @sonney2k | lisitsyn, well I am using an int | 23:25 |
| @sonney2k | just 1 million objects | 23:25 |
| lisitsyn | sonney2k: it is generic still | 23:25 |
| lisitsyn | reserve will be much faster I am sure | 23:25 |
| @iglesiasg | sonney2k: it will reserve space (called capacity) not changing the effective size, so you can push_back as many times as you wish without going over that capacity and no realloc will be needed | 23:25 |
| @iglesiasg | lisitsyn: yes, sure | 23:26 |
| @iglesiasg | I think the concept is similar to the matlab one. Memory pre-allocate, even if you don't know the exact size | 23:27 |
| lisitsyn | well if you constantly resize it you may need a list | 23:27 |
| @sonney2k | iglesiasg, but it is not doing that for future resizes right? | 23:27 |
| @sonney2k | iglesiasg, I mean consider that I reach the reserve | 23:28 |
| @sonney2k | then the next resizes are expensive? | 23:28 |
| lisitsyn | sonney2k: it resizes when you reach the reserve | 23:28 |
| @sonney2k | crap then | 23:28 |
| lisitsyn | sonney2k: why? | 23:28 |
| @sonney2k | why not do it the same way like dynarray does? | 23:28 |
| @sonney2k | lisitsyn, well consider you give it 100k reserve | 23:28 |
| @sonney2k | but you grow over 1MB | 23:28 |
| lisitsyn | not get it | 23:29 |
| @sonney2k | then 100k ... 1MB is expensive | 23:29 |
| thoralf | sonney2k: Just tell me when I can checkout you fix. | 23:29 |
| @iglesiasg | well then you should be reserving 1MB :) | 23:29 |
| @sonney2k | it will resize all te time | 23:29 |
| lisitsyn | why? | 23:29 |
| @sonney2k | iglesiasg, but if I don't know? | 23:29 |
| @sonney2k | thoralf, ok let me do it right away | 23:29 |
| @iglesiasg | sonney2k: how does dyn array makes it better in that case? | 23:29 |
| lisitsyn | I don't see the difference | 23:30 |
| @iglesiasg | sonney2k: I think that at least you should have a rough estimate. The diff between 100k and 1MB goes beyond a rough estimate | 23:30 |
| @sonney2k | thoralf, please try! | 23:32 |
| thoralf | sonney2k: On develop? | 23:32 |
| @sonney2k | thoralf, yes | 23:32 |
| -!- shogun-notifier- [~irker@7nn.de] has joined #shogun | 23:33 | |
| shogun-notifier- | shogun: Soeren Sonnenburg :develop * 3df0dd0 / src/shogun/lib/memory.cpp: https://github.com/shogun-toolbox/shogun/commit/3df0dd08b54f6d268dde752dc9177bf77fba17bb | 23:33 |
| shogun-notifier- | shogun: fix compile error occurring with non-c++11 compilers | 23:33 |
| @sonney2k | lisitsyn, iglesiasg why not give it a granularity like dynarray has? then whenever you reach a block you still have the same slack for the next block | 23:33 |
| lisitsyn | again I don't get | 23:33 |
| lisitsyn | sonney2k: granularity like how to resize? | 23:34 |
| lisitsyn | well I don't like that's hidden too | 23:35 |
| @sonney2k | lisitsyn, iglesiasg it is still 10 times slower with reserve | 23:35 |
| @sonney2k | and 0 realloc's | 23:35 |
| thoralf | sonney2k: memory.cpp.o did compile. The complete build will take a few minutes... | 23:36 |
| lisitsyn | sonney2k: so what do you do exactly | 23:36 |
| lisitsyn | realloc and reserve? | 23:36 |
| shogun-buildbot | build #1490 of deb1 - libshogun is complete: Failure [failed test] Build details are at http://www.shogun-toolbox.org/buildbot/builders/deb1%20-%20libshogun/builds/1490 blamelist: Soeren Sonnenburg <sonne@debian.org> | 23:37 |
| @sonney2k | lisitsyn, so it must be initing the memory | 23:39 |
| lisitsyn | sonney2k: that's implementation specific I don't know exaclty | 23:40 |
| lisitsyn | ahh it says it has linear complexity | 23:41 |
| lisitsyn | when reallocation happens | 23:41 |
| thoralf | sonney2k: Done. Check the subdirectories for binaries. :) | 23:41 |
| @sonney2k | thoralf, thanks. now if your make check-examples would run the local stuff we would know if stuff is ok ;) | 23:42 |
| @sonney2k | lisitsyn, https://gist.github.com/sonney2k/6050121 https://gist.github.com/sonney2k/6050125 | 23:49 |
| lisitsyn | sonney2k: so you first reserve then resize? | 23:49 |
| @sonney2k | sure | 23:49 |
| lisitsyn | makes no sense to me | 23:49 |
| lisitsyn | why? | 23:50 |
| @sonney2k | ? | 23:50 |
| @sonney2k | don't get it | 23:50 |
| lisitsyn | sonney2k: well once you call reserve | 23:50 |
| @sonney2k | yes? | 23:50 |
| lisitsyn | it allocates that 1000000000 memory chunk | 23:50 |
| lisitsyn | then once you resize | 23:50 |
| lisitsyn | it shrinks it again | 23:50 |
| lisitsyn | to the size you provide | 23:50 |
| @sonney2k | no | 23:50 |
| @sonney2k | it does 0 reallocations in the background | 23:51 |
| @sonney2k | it just sets the size to the value I give it | 23:51 |
| lisitsyn | ahh yes | 23:51 |
| @sonney2k | so that part is very cheap | 23:51 |
| lisitsyn | then you just fill it with zeros | 23:51 |
| @sonney2k | but it fills the memory with 0 I guess | 23:51 |
| lisitsyn | yes with int() | 23:51 |
| @sonney2k | with real objects that doesn't matter | 23:52 |
| @sonney2k | creating those is probably orders of magnitude more expensive | 23:52 |
| lisitsyn | yes but you measure different things | 23:52 |
| @sonney2k | but it is the memory filling | 23:52 |
| @sonney2k | resizing is still slow though when they have to be done | 23:52 |
| lisitsyn | realloc doesn't filling | 23:53 |
| lisitsyn | vector does | 23:53 |
| @sonney2k | lisitsyn, if I fill at the end and don't do reserve() it is still 2 times faster | 23:53 |
| @sonney2k | btw memset is slower than a for loop clearing the memory | 23:53 |
| @iglesiasg | lol that about memset is funny | 23:54 |
| lisitsyn | what memset implementation is called btw? | 23:54 |
| lisitsyn | there is vectorized memset iirc | 23:54 |
| lisitsyn | anyway | 23:54 |
| lisitsyn | sonney2k: once you do filling it is not 10x already | 23:55 |
| @sonney2k | lisitsyn, yes it is same speed | 23:55 |
| @sonney2k | lisitsyn, how do I find which one it is? | 23:55 |
| lisitsyn | it could be that std::vector uses new/delete | 23:55 |
| lisitsyn | sonney2k: gdb | 23:55 |
| @sonney2k | lisitsyn, it certainly does | 23:56 |
| lisitsyn | sonney2k: it could be the reason to slow things down too | 23:56 |
| thoralf | sonney2k: 9 examples are failing. Details will follow. | 23:57 |
| lisitsyn | but 2x is already not worth it | 23:57 |
| lisitsyn | I wouldn't use realloc in my code because of that I mean | 23:57 |
| @sonney2k | lisitsyn, depends where you have to use it. | 23:58 |
| lisitsyn | sonney2k: the best example of useless realloc usage is v_array | 23:58 |
| @sonney2k | thoralf, hmmhh | 23:58 |
| lisitsyn | 1) it makes covertree a bit faster but it is still slower than balltree most of the times | 23:58 |
| thoralf | sonney2k: One second, data files are missing. | 23:59 |
| lisitsyn | 2) it DIES on windows | 23:59 |
| lisitsyn | :D | 23:59 |
| --- Log closed Mon Jul 22 00:00:27 2013 | ||
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!